retesting and notetaking

Good blog read from pentesterlab.com about retesting in regards to pen tests and report writing. I like the points made about keeping detailed notes, from keeping Burp requests and application-specific output/input to keeping tool-agnostic notes and recreation steps so someone with their own tools can quickly verify/validate.

During my time in the PWK labs, note-taking was highly important. Most of the time, it is done in order to reroot a box later on or to provide detailed information for the lab report that can accompany the exam report. I approached my reports with a few goals.

First, I wanted to be able to follow my own notes to re-root a box 2 days or 2 months from the time those notes were taken. I did end up redoing every box in the labs at least once through my notes alone. Second, I want there to be enough detail to create whatever report I need to create, or help those who have questions about a box in my social media circles. Third, I wanted to create a report that I would be just as good giving to a client as to the OffSec admins for grading. And part of that is making sure that next year when the test is repeated (either by me, a teammate, or a competitor), validation can be done quickly and accurately.

As a consumer of pen test reports, I really want to be able to understand the issue, which requires giving me very clear notes and evidence. And hopefully enough information that I can verify the issue, and validate a fix post-implementation. I also want to make sure my non-technical boss can consume the issue using summaries and higher level language for impact and criticality.

Heck, pen testing isn’t the only place I practice this. During my many years of being a systems admin doing support tickets, I try my best to put as much detail into tickets as I can. I want to make sure if I need to check the ticket again in 8 months, I have everything I need without needing to respend time learning something that is hazy. I want to make sure anyone else who reads the ticket can also piece details together without spending time. And I usually want to help educate whomever submitted the ticket so they can either do better, know what to reference in the future, or maybe just have an idea of what I do for them. 🙂

This is really about three things: documentation skills, communication skills, and empathy to put yourself into a reader’s shoes.

web categorization is just another line of defense

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.”

endless supply of red team tips by vincent yiu

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!

upgrading to fully interactive shells

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.

generation x or a millenial or a xennial?

I was born in 1977. This technically tends to make me part of Generation X, but I have never identified with that at all. I’ve identified more with Millenials, though I would have grown up, gone through highschool, and graduated college well before I had a cell phone of any type in hand. So, I found this article interesting, as I think it makes a good point about this little gap of time between Gen X and Millenials that I greatly identify with: There’s Now a Name for the Micro Generation Born Between 1977-1983. I really like the identifier of having an analog childhood and digital adulthood. Definitely agree with that, as I got my first computer around midway through high school (for writing papers, learning, but mostly I got into Doom), and while video games were a huge part of my childhood, I wouldn’t call that digital to any degree. It was probably not until around late high school that I started “getting online,” and then it was just myself and not part of a social thing with other kids I knew. I hadn’t heard this term before, and just needed to capture it down for future reference.

eternalblue pcap sample and analysis blog

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.

the pentesting state of an experienced mind

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.

thinking like an adversary and the kobayashi maru

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.

learning over a career in information technology

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.

catalyst on the state of junior security hires

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.)

hunting in memory with powershell

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.

ctf skills for life

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.