How to Organize Your Tools by Pentest Stages

With all of the bare-bones setup out of the way in our Mac for Hackers series, your Apple machine should be ready to run a significant amount of pentesting tools. We can pull tools from GitHub and compile them, we can pull dependencies or tools from Homebrew, we have both Python and Ruby. Everything is ready to go and now it's time to start building a toolbox on our local host.
Part of building a toolbox is the organizational aspect. Anything we pull down with Homebrew will be installed in its own path, and anything we compile from source will either install to the system or remain in the folder where it was compiled. It's very easy to end up with tools scattered all over your machine, and unless you absolutely remember everything you've pulled down or installed, it can become difficult to select the proper tool for the proper scenario—especially tools or PoCs (proof of concepts) that you rarely use.

Kali Linux handles this with a set of menus built into the window manager. In our case, we will be using the old standard of a ~/pentest directory. There's a variety of ways to organize the tools within this directory tree, and eventually you will find an organization standard that works for you.
I like to organize tools based on the phases of a pentest. Then, in each directory, I will symlink to the tool itself (if it's a tool I don't use often), unless I built the tool from source in that directory. With tools installed via Homebrew or from a .pkg, it can help to maintain a copy of the readme file in the directory with the tool named something like $toolname.readme. This will help with more obscure tools, and it can also help by giving you a place to note things about the tool.

Phase 1: Reconnaissance

This is the information gathering stage, and can be either active or passive. The whole purpose of this phase is to learn—the more information you can gather on a target before the actual attack, the better.

Image by Juan Pablo Gonzalez/123RF

Some examples of important information:

• What is the target?
• How do they operate?
• What IP ranges do they have allocated?
• What do they do for mail?
• What do their DNS records show?
• What subdomains do they have?
• What's going on in their company?
• Who works there?
• How do they assign login names?
• What's their password policy?
• What do their networks look like?
• Are any of the people who work there vulnerable to social engineering?
• What are there valuable assets?
• Where do they store valuable assets?

All of these are important questions, and it's just the tip of the iceberg. The more information you have going into the attack, the better off you are. Of course, the more information you gather, the more time you will have to spend analyzing it—unless you are working with a team, in which case you can divide the efforts. I keep OSINT (open-source intelligence) gathering tools here, as well as active recon tools. Some examples of tools that you might find in my ~/pentest/recon directory are:

• theHarvester
• birdwatcher
• Nmap

Depending on how unwieldy the directory becomes, I might divide the tools into two categories: active and passive. Active recon tools actually send packets to the target, where as passive tools gather information without interacting with the target system(s).

Phase 2: Scanning & Enumeration

If we did Phase 1 properly, we should have a wealth of information, IP addresses, employee names and e-mail addresses, etc. The next phase is to begin scanning.
Not all of the information gathered will be fruitful, so we have to narrow down and hone into certain targets. We examine perimeter and internal network devices looking for weaknesses, and learn more about the systems they have in place, as well as the services those systems are running. We see what ports are open, look for firewalls, locate vulnerabilities, and detect operating systems.

Image by Takashi Honma/123RF

Some examples of tools that fit this category:

• Nmap
• Nikto
• WPScan

You'll notice that I've included Nmap in both Phase 1 and 2—there will be some intersection of tools in these phases.

Phase 3: Gaining Access

In this phase, we put the previous steps' information to use. We will have lots of data on our targets and some ideas on which hosts we'll be focusing on. We've researched out-of-date services and checked for vulnerabilities. We might launch a social engineering campaign and target some known vulnerable services on a host.

Image by serezniy/123RF

Some examples of tools that fit this category:

• THC Hydra
• Nmap
• Armitage
• Metasploit
• SET (Social Engineering Toolkit)

Once again, Nmap make our list due to its scripting engine; it's a highly flexible tool. I included a brute-force tool even though we don't really want to be brute-forcing due to time constraints. Of course, it doesn't hurt to run brute-force in the background throughout the test, providing you can afford that level of noise on the target system.

Phase 4: Maintaining Access

Once we've compromised something, we want to maintain access to gather even more information. Stealth will play a roll here since we don't want to be discovered acting on the target host(s). This phase involves privilege escalation, RATs (remote access tools), root kits, etc. The goal is to be able to access the system whenever we want.

Image by mtkang/123RF

Some tools that might be in the maintaining access folder:

• Metasploit
• Shellter
• Webshells

Metasploit makes the list again here, though really, it could be included in every phase of this list.

Phase 5: Covering Your Tracks

This can cover a wide variety of tools and actions. We want to alter (possibly corrupt) log files, delete any files we're not using on the system, clear our history, hide our maintaining access tools, etc. We don't want to leave any trace that we were there.

Image by Wichapol Polpitakchai/123RF

Making mistakes on a contracted pentest is just bad business. If you are accessing a system illegally, it can be even worse. Equation group actually messed up covering their tracks and their custom tools were put up for sale on the web. We'll want to keep our infected hosts to a minimum, use varied malware, and try to stay one step ahead of potential incident responders.

We could use Metasploit or ClearLogs to clear event logs, or we can just delete them with a simple text editor. We could also erase our commands history and shred the history file. For more information, make sure to check out the following guide.

Stay Organized

If we keep our tools organized, it will be easier to conduct a pentest in a reasonable amount of time. It is extremely important to be able to quickly evaluate what we need to use and when. In some cases, when attacks haven't been added to a tool yet, it maybe important to maintain a separate PoC folder, though many of these can be quickly located on the Exploit Database. By keeping our tools associated to phases, we're also able to transition through phases in a smooth fashion.