You can be amazing at sniffing out application vulnerabilities, social engineering, or recon and still be basically useless in a real life pentesting engagement. It’s a hard truth. Without a solid methodology, you are much likelier to waste time, miss critical vulnerabilities, and write an absolutely terrible report. A bad report means an unhappy client, and, more importantly, the inability to secure an environment.

So, what can you do to change things up and get on a path to success? Outline the process you want to follow and stick to it religiously. Now, that’s not to say that you can never revise it. You should revise it. It should be a living document that gets more mature with every engagement. Refine your process until it’s a work of art, but make sure you aren’t switching things up every time you hit the field.

That’s all easy to say, and much harder to implement. This article will cover the stages of a pentesting engagement and offer up a basic outline that can serve as a launchpad for your own standard operating procedure. Let’s jump into it.

Recon: the lost art of learning things

Anyone who doesn’t spend a good portion of the engagement (or pre-engagement) researching their target is jumping into the pool blindfolded. Sure, you can still swim, but navigating the waters will be unnecessarily difficult. Recon allows us to get an idea of what a client’s environment might entail before we dip our toe in the water.

Doing proper reconnaissance can reveal things like company vendors (and thus hardware/software resources), valuable intel on employees through social profiles and/or a company directory, and even application infrastructure. Imagine the head-start you’ll have with social engineering if you spend some time learning who’s who in the company, or all of the exploit research you could do beforehand if you know some of their business critical software.

The moral is this: recon will never hurt your process. It is an obvious value-add, and will pay off tenfold in time saved and knowledge gained.

Discovery and Enumeration

You’ve made it onto the field, and you’re ready to play ball. The first thing you need to do out of the gate is take inventory. Break out Nmap, ZenMap, WireShark, or whatever tools you’d like and start cataloging devices and services. If you’re outside the network looking in, start collecting traffic with AiroDump-NG / Kismet / etc, and identifying entry points.

There’s no truly standard tooling or method for discovery. It’s whatever works best for you. Just make sure to be as full-spectrum as possible. You don’t want to miss an obvious SMB exploit because you were only scanning for HTTP/S ports.

This is a great time to mention another critical component that has no singular place in the process: documentation. I say it has no single place because you should be doing it the whole time. From pre-engagement recon until the last stroke of your keyboard in the engagement, you should be taking notes, screenshots, and logs of everything you do. It’s critical for your report, and serves as evidence should something go awry.

Back to discovery/enumeration: it’s time to organize things. Start a running list of devices/services you intend to test and spend some time ‘fingerprinting’ everything you can (web portals, network shares, etc.). This is a huge time saver and will help you formalize your attack plan.

Exploitation: Research, Development, Execution

Now that you have your neat, organized list, it’s time to start the magic. Never start this process trying to discover a new vulnerability. Instead, you should be scouring resources like ExploitDB and Sploitus for currently known exploits relating to the device or service you’re attacking. Make good use of your fingerprinting notes, and search for services by name and version.

What I like to do is grab links to exploits and put them in my notes under each device/service. I make my way through this entire list before I start actually attempting exploits. In doing so, I identify the possibly low-hanging fruit. These are the devices/services that are probably the easiest to exploit in terms of time and labor. In situations where time is a major limiting factor, this process is a life saver.

After you’ve plucked all of this low-hanging fruit, you can spend time manually researching new vulnerabilities and exploits. When doing research for new exploits in an engagement setting, I find it helpful to group a few targets together. I then set a timer for myself (somewhere between 20 minutes and an hour) and switch between targets. This process keeps your mind fresh, and prevents you from falling into time-sucking rabbit holes.

Post-Exploitation

Although it may sound like it, this stage is not the end of the engagement. In fact, this stage often loops back to Exploitation, or even Discovery and Enumeration. Under this umbrella, you have privilege escalation, persistent access (backdoors, etc), lateral movement, and more.

You may very well find yourself jumping back a few steps to scope out a new subnet you have access to after you cracked a new box. In this scenario, you would restart at the discovery stage, list out the new devices, and proceed to researching exploits again. This process ends when you’ve either exhausted the list of devices, gone out of scope, or ran out of time.

Reporting

This is the step that separates the hackers from the engineers. Anyone with some infosec know-how can exploit an application, or break into a network. The real value of a pentesting engagement is learning what is vulnerable, and having the ability to recreate those conditions and mitigate further risk.

Without proper reporting, you’re basically just saying “it’s vulnerable, trust me”. That is practically useless to an organization. Take all of that invaluable documentation you’ve been collecting: the logs, screenshots, notes, and anything else relevant (hint: it all is), and distill it down to something anyone can digest.

This brings me to my next point: using tech jargon without explanation is not only unprofessional, it’s another roadblock for the organization to overcome to mitigate their security issues. You don’t have to give them a collegiate lecture on how the exploit works, you just need to explain what it is, how you exploited it, and what can be done to fix it. That’s it.

Conclusion

To really fill the process out, you might add something like a Debriefing stage to the end, where you actually present your findings to the client and discuss the engagement in depth. But, that’s completely up to you and your client. Sometimes all that is required is a nice report.

Hopefully this has shed some light on how to structure your pentesting process. Don’t take this article as the gospel truth, the process you should use is the one that gets results and is sustainable for you. Feel free to use this as a starting point, though.

Need help getting your process together? Feel free to reach out to me.