Three things I learned my first week as a Penetration Tester

This summer, I am enjoying the incredible experience of working at Security Innovation in Seattle as a Security Engineer Intern. That means I get to work with people way smarter than me, hacking real web applications, IoT devices and internal infrastructures for all kinds of clients together. Although at the time of writing I've only been on board for a week, I've already learned three valuable lessons to share here.

1: Take notes (it won't slow you down)

Properly working for clients (as opposed to sitting hunched over my computer at 2 am trying to figure out a problem on Hack The Box) has meant a great deal of changes to my workflow. One of them: incessantly taking notes.

In a CTF, a rooted box is a rooted box. After getting a flag, no one really cares how you did it only that you did. That, of course, doesn't fly at work (nor should it). The obvious reason for taking notes is of course that the client isn't paying you to break their product, but to explain to them how to break it so that they, in turn, can fix it. Less obvious, to me at least, was the incredible benefit to my own productivity that came from note taking, when I begrudgingly had expected it to slow me down. The methodology of writing down your work becomes a very useful scaffold for when you find yourself lost and also as a constant reminder of what you're working towards on the engagement.

Personally, I keep a mindmap and a markdown file open during my engagements. The mindmap is excellent for keeping track of the different components of the product I'm working on, such as ports, the filesystem and API endpoints, whereas the markdown file is better for storing tool output (such as nmap scans and testssl.sh output) as well as for detailing vulnerabilities and exploits. Currently I use XMind Zen (although I would kill for a viable open source alternative) for mind-mapping and MacDown for editing markdown files.

2: Ask questions (no one knows everything)

An extremely refreshing realization after my first week is that, while everyone in my office knows more than me, no one knows everything. Equally important, no one expects anyone else to know everything.

While I urge everyone reading this to muster an honest attempt at solving any problem they encounter before asking about it, there is definitely no shame in realizing there are other people with expertise that differs from your own. With security being such an organic and crazy field, there will be some people who become really good at reversing and reading android APKs, whereas their colleague across their desk might be an enumeration wizard.

Slack is on your desktop for a reason, and can save you from wasting hours messing around with the wrong tool for the job or trying to re-invent the wheel.

3: Not every problem report leads to root access (but some do)

I'm exaggerating a little bit, but coming from CTFs it is easy to fall into the trap of discounting vulnerabilities that don't feel particularly sensational. After reading hundreds of awesome bug bounty disclosures detailing spectacular business logic faults that lead to arbitrary account takeovers or, indeed, a root reverse shell, it is easy to forget that the most common exploits are probably due to things like lazy password requirements or bad default configurations.

Of course, one of the most gratifying feelings in penetration testing is when you're able to string together three decent vulnerabilities to get that superuser access, but don't expect to get there on every single engagement. More importantly, don't think you're bad at your job just because you don't get that root shell.