Choosing and Organising Your Tools

A beginner often asks "which hacking tool should I learn?". Professionals ask a different question: "which method am I following, and which tool serves each step?". In this lesson you will learn to think in methodology first, and to build a tidy, safe and reproducible working environment.

In the previous lessons you set the legal framework, chose a type of test and wrote your authorisation. Now you prepare the workshop. A good workshop does three things: it keeps the tools you need within reach, it records what you do, and it protects the client's data and yours.

Methodology before tools

Tools change every year. Methods last. Several public frameworks describe how to run a penetration test, and you should know their names:

• PTES (Penetration Testing Execution Standard): a community description of the phases of a test, from pre-engagement to reporting.
• OWASP Web Security Testing Guide: a detailed catalogue of web application checks, available on owasp.org.
• NIST SP 800-115: a technical guide to information security testing and assessment, published by NIST.
• MITRE ATT&CK: a knowledge base of adversary tactics and techniques, useful to structure your findings. See attack.mitre.org.

They all agree on a similar sequence, which is also the structure of this course:

1. Preparation: authorisation, scope, tools (chapter 1).
2. Reconnaissance: collecting information (chapter 2).
3. Vulnerability analysis: finding likely weaknesses (chapter 3).
4. Exploitation: proving that a weakness is real (chapter 4), including access to credentials (chapter 5).
5. Post-exploitation: understanding the real impact (chapter 6).
6. Reporting: communicating results and recommendations (chapter 7).

Think of it as a doctor's workflow: interview, examination, diagnosis, treatment plan, report. A doctor does not start with a scalpel because it is the most exciting tool.

The tool categories you will use

Instead of memorising a long list, learn the categories and a few reliable examples of each. All the tools below are free or have free editions, and are used in the profession:

Need	Category	Examples
Working environment	Security-oriented Linux distribution	Kali Linux
Discover hosts and services	Network scanner	Nmap
Understand traffic	Packet analyser	Wireshark
Test web applications	Intercepting proxy	Burp Suite
Exploit known weaknesses	Exploitation framework	Metasploit
Check password strength	Password auditing tools	covered in chapter 5
Take notes and evidence	Note-taking and screenshots	any text-based notes system

You do not need to master all of them. You need to know what each category is for, so that when a step requires something, you know where to look.

Building your lab

A safe lab has these properties:

• Isolation: the vulnerable machines live on a virtual network that cannot reach the internet or your home network. In VirtualBox or VMware, this is usually called a "host-only" or "internal" network.
• Snapshots: before you attack a machine, take a snapshot. If you break it, you restore it in seconds.
• Separate roles: one attacker machine (Kali Linux), and one or more targets.
• Reasonable resources: a modern laptop with enough memory can run an attacker and one or two targets at a time. Start small.

For targets, use only machines designed to be attacked: lab images offered by training projects, DVWA, OWASP Juice Shop, and the hosted rooms and machines of TryHackMe and HackTheBox, plus the labs of the PortSwigger Web Security Academy for web topics. Read each platform's rules and follow them.

Organising an engagement folder

Professionals work in a predictable structure so that they, and their colleagues, can find anything months later. Here is a simple one you can create from your Kali terminal:

mkdir -p ~/engagements/lighthouse/{00-admin,01-recon,02-vuln,03-exploit,04-post,05-evidence,06-report}
cd ~/engagements/lighthouse
ls

Put the signed authorisation in 00-admin. Each later step has its own folder, and screenshots and raw tool output go into 05-evidence.

Keep a log of everything

You will need to prove what you did, when and from which address, and you will need exact details to write your report. Two habits help:

1. A running journal: a plain text or Markdown file where you write the time, the action, the command and what you observed. Write it as you go, not afterwards.
2. Saved tool output: most tools can write results to a file, and the terminal can be recorded. For example:

script -a ~/engagements/lighthouse/05-evidence/terminal-session.log

This records everything displayed in the terminal until you type exit. Remember that logs may contain sensitive information, so protect them as described below.

Protect your own workstation and the evidence

A tester's laptop is a very attractive target for criminals, because it contains vulnerability details about many clients. Basic precautions:

• Full-disk encryption on the machine where evidence is stored.
• A strong, unique password and, where possible, multi-factor authentication for every account you use.
• Keep your operating system and tools up to date, using official updates.
• Back up your notes, and never mix several clients' data in the same folder.
• Delete client data when the retention period ends, as agreed in the contract.

Your fil rouge: set up Project Lighthouse

By the end of this lesson, your lab should contain an attacker machine and at least one target, isolated from the internet, with snapshots taken, and an engagement folder containing your authorisation and an empty journal. Chapter 2 starts with the first real activity: reconnaissance.

Your turn: your starter kit

1. Create the folder structure from this lesson (in your attacker virtual machine).
2. Create a file 00-admin/journal.md and write the first entry: date, time, "lab prepared", and the version of your attacker distribution as displayed by the system.
3. Take a snapshot of every virtual machine and name it "clean-start".
4. Check that your target cannot reach the internet: from the attacker VM, a request to a public address should fail or be unreachable.

See a solution

For step 2, a possible first entry is: 2026-01-10 14:05 - Lab prepared. Attacker VM and one target on host-only network. Snapshots named clean-start created. To read the distribution name for the journal, you can run cat /etc/os-release. For step 4, a failed or timed-out request such as a ping to a public address confirms isolation. If it succeeds, your network is bridged or in NAT mode: switch the adapter to host-only before going on.

You are ready. In the next chapter you will start Project Lighthouse for real, beginning with the art of finding out what is publicly known about a target.