Quickly read and re-read a blog post at MDSec: Categorisation is not a security boundary. The post itself is nice and talks about evading web page category blocking in a few different ways for red teams looking to get phishing attack success.

My problem is the title doesn’t match the content. Nowhere does the post itself back up this title. Yes, you can evade web categories, but I’m not sure anyone is truly saying that web category blocking is insurmountable. Does it protect from a dedicated attacker? No. Does it protect against some 2-month-old watering hole location? Yeah, probably. It helps protect against known things, and probably is more useful to controlling productivity and things you should block for regulation or legal issues, but the control itself isn’t dead. Which is how I read that title. The author even says that, “Domain categorisation can often prove a thorn in the side of many red teams…”

It’s a minor thing, but I also don’t see any alternative solution. (I imagine the alternative somoene would give is deep inspection with magic rather than a domain-matching category allow/deny.) In security, we can poke holes in probably 99% of all controls (often due to the poor implementation of good controls!), but that doesn’t mean we go to the CSO and say these solutions are worthless.

If I wanted to get a little more specific, I don’t think “security boundary” is the proper term to use. I think it’s more of a “line of defense.”

Need some inspiration or just some new ideas or thoughts? Red Teaming Tips by Vincent Yiu is an amazing list of tips and hints and tricks and links for both red and blue teams (but mostly red). I have no idea how I’m going to consume all of these… This is the sort of list you could read one of every week and learn what he means, and still never run out of new ideas. Seriously, I need a way to do that and stick to it!

I really wish I had seen a blog post like, “Upgrading simple shells to fully interactive TTYs,” back when I was still actively taking the PWK/OSCP lab. The scenario of having a non-interactive shell is already maddeningly annoying, but it’s even more frustrating when accidentally killing or otherwise messing up the shell when using a poorly chosen command. I’ll need to set up a box or two to test some of these out on. Maybe grab something compatible off vulnhub.

This is from last year, but it’s the first I’ve seen it. This blog post at TunnelsUp shows the contents of two physical pen tester backpacks.

Want to check out some malware traffic, but don’t have the gear (or bravery) of hosting your own lab and executing the malware yourself? This sounds like an advertisement, but it’s not. I just happened upon some sample traffic and analysis on the WannaCry malware at malware traffic analysis. This is excellent stuff to check out for curiosity, to possibly better test your own network alarms, learn a bit more about traffic analysis, or study up for malware analysis itself or response. Heck, it might even be useful for those that create malware for phishing red team exercises.

An absolutely excellent post about penetration testing by maderas: Shared thoughts after 6+ years in Pentesting. The insight provided is astounding. I kept reading and thinking, “I love this quote and need to pull it out,” but I kept thinking that just about every 2-3 sentences or so.

One of my favorites, though, is this line about the process of pen testing an environment: “Always be advancing your position(s).” I love this quote, and while I haven’t thought this exactly myself, it fits. There were are times in a lab looking at a system or already having access, where I’m feeling stuck. The author makes a chess analogy, and while I like his better, I also in my mind make one: “What is my next goal, and what steps can I take to get there?” Imagine what success looks like (capturing a Queen, getting root on this system), and start going through the permutations of how to get there, while at the same time fending off other attacks, mistakes, and not giving away the goal to an opponent).

I really like this post, and I really like the attitude of the author. Prefers knowing the surgical, underlying tools rather than the paid commercial stuff (Hack Naked!). Towards the end, there are some links for further study in anonymization and tools.

Honestly, I really might just snag that whole post as text and put it into a folder for reading when I need some inspiration or perspective.

I didn’t know there was a Damn Vulnerable Raspberry Pi for IoT either!

Star Trek’s Kobayashi Maru; a starship captain is given an unwinnable exercise during academy training, but protagonist James T. Kirk cheats and beats the system through outside-the-box thinking. In the paper, Embracing the Kobayashi Maru: Why You Should Teach Your Students to Cheat (pdf), Greg Conti describes the ways students cheat on an exam, and why this lessons matters.

We’ve always been taught to color inside the lines, stick to the rules, and never ever cheat, but in seeking cybersecurity, we must drop that mindset. It’s difficult to defeat a creative and determined adversary who must find only a single flaw among myriad defensive measures to be successful. We must not tie our hands — and our intellects — at the same time. If we truly wish to create the best possible information security professionals, being able to think like an adversary is an essential skill.

Just read an article from SmartBrief: Learn-gevity: Enhancing your ability to learn, perform and succeed over time. Not sure I would have normally read this article, but it came across with this hook:

“The half-life of technical skills continues to shrink. According to Josh Bersin, the half-life of a technical skill is just 2 years.”

I mostly agree with this. I’ve been in IT for 15 years. Even something as large as an OS change is a problem for us. I knew Windows 2000 and XP really well, and thankfully the latter hung on for quite some time. But these days, my XP knowledge doesn’t serve me much at all; everything is moved around in modern OS. I remember when we installed our first Windows Server 2012 box and half of us couldn’t figure out how to log out of the damn initial interface! This remains true for other topics such as how we manage things (devops!) and location (cloud!). I think 2 years half-life for IT skills is really liberal, though. I’d push that to 3-4 years, with how most companies operate.

That aside, I love the points about learning. It’s not just about learning, but having a proper mindsight for the rest of my career. I especially take to heart a few of the points the author makes: stop think about being an expert, be inquisitive, stay social, set personal habits around learning.

But I would add one point of my own: Embrace failure. One thing I’ve learned from my previous job experience is to be risk-averse. But that hurts, and I struggle with that on a weekly basis. I want to learn things and get better, but we get better with practice, and not all practice yields success. We have to make mistakes, we have to fall down, we have to get errors and miss things. Doing this on the job is stressful for others, but this needs to be part of the process for learning. It’s part of the scientific process, and it’s part of growing. It’s easy to fail on your own time and get better. But it needs to at least not be overbearingly suppressed in the workplace as well.

You can’t be on social media in security without hearing about the “cybersecurity talent shortages.” I really like Michael Santarcangelo’s CSO article: Are new security specialists starting at a disadvantage?

“Nowadays, most junior security professionals come right out of college with a baseline security foundation as they enter the workforce – but lack that foundational and practitioner knowledge of the networking side of things. This trend is causing real-world challenges for security operations center (SOC) teams.”

True! And while it’s good advice to recommend looking at candidates from other areas of IT, the problem becomes one of pay when that security job is a slight step down in terms of pay for a candidate that is “new” to security, but established in their IT field. This is one of several problems swirling around our state of hiring and talent today. (For example, the IT boom of 1999-2000 producing many new IT practitioners, but now cloud services and general 15+ year boredom are fueling experimentation into security, but security isn’t ready to support them.)

Attackers can do so much in memory these days and not touch the disk, especially with things like PowerShell to abuse. In walks a talk to help combat that: Taking Hunting to the Next Level Hunting in Memory by Jared Atkinson and Joe Desimone. And the code released to do it: Get-InjectedThread.ps1. Talk was also given in May at SANS Threat Hunting and Incident Response Summit 2017, and while I don’t have a video link for it, the PDF of the slides is available. If some of this sounds familiar, one of the presenters is from Endgame which is where I recently linked another similar blog post from.

I’ve recently started looking into getting casually involved in CTF competitions in the infosec space. And a common question I hear is: What’s the point of doing them? Often these competitions have almost trivia-like questions that involve knowledge, some meatspace social engineering or lock picking, radio manipulation, pcap analysis, malware analysis, image analysis, decoding/decryption, reverse engineering, network service fuzzing, and so on. Sometimes, you either know it or you don’t, and if you learn it on the fly, you’ve eaten up your time to do the rest.

Well, the answer isn’t a direct one. Do you learn key infosec skills? Probably not directly.

But you do learn how to do things you sort of already know faster and better. Like knowing a bit of Python and then banging out a few snippets for some challenges. +2 to Python skill!

You also pick up the ability to do cheap, quick little things like that you can emulate in the day-job to analyze (quickly) some new exploit code that is released, or troubleshoot something quickly at work, or manipulate and fuzz a new app for a project.

It’s about practice, and in a sort of intense time-bound moment.

It’s about exposure to a few new concepts and skills that can be picked up.

It’s about meeting others and sharing some notes to get better and pick up those new skills easier.

But, if I had to just give one answer, it’s the common answer for those that desire to be an expert in something: practice, practice, practice.

BHIS has a build post for an updated hashcat password cracking workhorse system. Pretty cool! It almost makes me sad to think about building a system and not use it for gaming, but it certainly makes sense if you need to crack hashes on a very regular basis. For less needy setups, the main goal is Ubuntu 16.04 + NVidia + Hashcat appearing to all work together with no fuss at all. From there, just slap together what you can afford or need or fit into your space, casewise. For me, I’ve built gaming systems for almost 15 years, all with water cooling, so I would continue to make that a necessary build piece for the quieter operation. Though, to be honest, GPU fans these days (that I’ve heard) are surprisingly quiet when new. And the all-in-one CPU cooling loops are super convenient.

Any time I’m building a system, I honestly still spend some months researching on the HardOCP forums. Been a member for so long, and it’s still a great community to ask questions of.