I mentioned in a previous blog post, that having a good process to follow is one of the most important tools to have in your pentesting arsenal. I received numerous requests to write a guide on how to develop this process, while I definitely do not consider myself the most qualified to do so, I have just gone through this process and I can empathise with people starting out who don’t know where to begin. So I will try my best to provide something of value to anyone in this position.

What is a Pentesting Process?

So first of all, what do I mean by a pentesting process? A pentesting process is a defined set of steps to follow in order to fully enumerate a target and find any low-hanging fruit on the target. It is essential that you have a process to follow ensuring that you are not investing too much time into one area of the penetration test or missing out possible vulnerabilities. It is important to remember that the process is malleable and needs to be adapted as you go along in order to stay relevant and grow with you as your skills develop.

Why is it so important?

I have spoken a little on this already but I think it is a point that can’t be stressed enough. When performing a penetration test, you are dealing with high volumes of information that needs to be gathered from multiple sources and it can be incredibly easy to get lost or overwhelmed by all the data, this can lead to missing out on crucial information that could be vital to the success of the penetration test. Something common that happens during penetration tests and especially CTF’s, is that you can easily get off track or go down rabbit holes and get frustrated that you are not finding a foothold in the target. Having a defined process keeps your enumeration landscape broad and keeps you from focusing on a single potential entry point, such as spending hours trying to brute force ssh or locating a weakness in a web application.

How do I develop a pentest process?

This is an incredibly hard question to answer and unfortunately I do not think there is a “one size fits all” explanation that will work for everyone, however I can offer some suggestions as to the kind of things you should include in your process and the kinds of information your process could contain. So let’s start with the most basic skeleton we can:

• Port scan
• Review ports
• Check what service is running on each ports
• Enumerate service versions
• Check if the services matched with the versions have any known vulnerabilities

Most of you will recognise this to some degree and some may even use this as a mental process to follow when starting to enumerate a target, however using just this is can lead to running around like a headless chicken trying to “Hack all the things” and getting nowhere. Although this process is lacking, it is a good starting point to expanding each stage and start to flesh out our process. I shall begin with showing you an example flow diagram for a simple process:

This process flow diagram is a very high level overview to give you an idea of the kind of things that we will need to include in our process, this flow diagram is still however incomplete and far too high level. For example, I could have created a much larger diagram focusing purely on web services but this is more representative of how you could plan out your process. The thought process of this flow diagram illustrates how to enumerate and not go off down a rabbit hole, this is something you need to plan for when building your process. You don’t want to spend 5 hours enumerating http when there is anonymous read access of the users private key on the ftp server. You could for instance build your process in stages, if that’s what helps you stay organised then list things you need to check for each service and check for basic weaknesses for each service first i.e:

Stage 1 –

• Port Scan
• Check service versions for each service
• Check exploitdb for each service version
• Check for default credentials on each service

Stage 2 –

• Check for sensitive files on each service
• Check if any sensitive directories can be written to
• Check source code of web services for left comments

Stage 3 –

• Brute force common credentials for services that require authentication
• Run Directory brute force to find hidden web services
• Check for common web application vulnerabilities ( i.e sqli, csrf, css )

This simple process, while high level, could keep most beginners on the right path that didn’t have a process from making simple mistakes or running down rabbit holes. You can then just add to the process as you go along, for instance, you might find that at stage 2 you want to add an additional check for robots.txt, this might provide an insight in to which directories exist on the web server and what where to start enumerating. This is the most important part of developing the process, ensuring you are continually improving, refining and adapting your process. Run through the process end to end when you start a test, when you get to a point where you have missed something obvious or spent too long on one service, update your process to remedy the issue and continue.

Another kind of process you might want to consider is driven by the tools that you use and when to use them. This is similar kind of process to the previous one, in a sense that you break it up into stages but you decide which tools to run at each stage. For example:

Stage 1 –

• ping
• nmap port scan with version check
• host

Stage 2 –

If port 21 is open:

• Nmap ftp scripts
• ftp login anonymous

If port 22 is open:

• nc ssh port

If port 80/443 is open:

• Nikto
• curl robots.txt
• Browser view homepage

If port 139/445 is open:

• smbclient anonymous
• enum4linux
• nbtscan

Stage 3 –

If port 21 is open:

• FTP brute force
• wget -m ftp://username:password@ip (Get all files from ftp server)

If port 22 is open:

• ssh check authentication type

If port 80/443 is open:

• dirbuster
• brute force application credentials

If port 139/445 is open:

• smbclient enumerate files
• smbclient upload files

This can be a good way to organise your process so that you know exactly what kinds of information you are going to get each time, but there are still issues with this. Our tools that take the longest time to run, such as dirbuster, only start running in stage three meaning we have to wait for them to complete. We might want to kick off dirbuster as soon as we know that port 80 is open and manually enumerate while it is running. These are the kind of tweaks you need to make in order to make sure that your process works for you. You will not have a fully comprehensive perfect process developed for every possible port combination, but over time you can develop something comprehensive enough to save time and make sure that you have not overlooked anything or forgot to check something.

Why can’t you just give me your process to follow?

This is a question I have received far to often when I try to explain what a process should contain but there are numerous reasons why this wouldn’t be beneficial. For starters, I don’t think my process is anywhere near the quality I would like it to be at, I am still changing it all the time and constantly making additions or tweaks (as you should be!). Aside from this, I learned an incredible amount by developing my own process. I learned what tools work best for me, what tools present the information in a way I find useful, what order I like to start enumerating things and much more. It is personalised and does things in the way I like and suits the way my brain works, which I guarantee will not be the same way you like your process. That is the beauty of it, it works for you and is tailored for your own performance, management and optimisation. It does take time, but anything worth doing always does.

What recommendations do you have?

Again, you will have a very different way of working to me, but I will try and provide some tips I would have found useful when developing my process and hopefully give you something useful you can take away from this. So here is a list of considerations/tips/recommendations that work for me:

• Build it, test it, adapt it
• Your process is a guide not an instruction manual
• Follow your process
• Again, follow your process. I can’t count the amount of times I went off piste and got lost.
• Try not to make the process so rigid that it only fits a specific OS or environment
• Your process can always be more efficient
• I have two processes, one for initial shell and one for privilege escalation if needed.
• When you written a decent process, consider automating it to save you time.
• Always make time and efficiency the primary objectives of your process
• If it works for you, don’t worry about some people doing it differently
• On the contrary, look at how other people do things, it might help improve your process.

Summary

I hope this helped give you an idea of what a process is and how to get started on one. I know it can be daunting but I promise you that the payoff is huge, once you get started and have something to work from, it just becomes at matter of continually improving it as you go along. Let me know if you have any questions or would like a Hacking how-to on a different topic.