Exploiting a Vulnerable Service in a Legal Training Lab

This lesson walks through the shape of a complete exploitation attempt, from the first idea to a documented, reproducible result, using the deliberately vulnerable machines of a legal training platform as the example. The focus is on the process you follow, not on any specific product, since the whole point of training labs is that they already provide safe, documented targets for you to practise against.

Choosing your training environment

For this kind of exercise, use one of the environments explicitly built for it: a downloaded deliberately vulnerable virtual machine image running inside your own isolated lab, or a machine hosted by a platform such as TryHackMe or HackTheBox, whose entire purpose is to let you attack their machines within their rules. These platforms typically provide their own walkthrough material and hints for each machine, which is the right place to look for the specific technical steps of any given exercise, rather than this course, which focuses on the surrounding method.

Step 1: reconnect the dots from earlier chapters

Before touching anything new, re-read your own notes: the open ports and services from chapter 2, the candidate weaknesses from chapter 3, and your exploitation plan from the previous lesson. A common beginner mistake is to restart reconnaissance from scratch inside the exploitation phase, wasting time re-discovering what was already documented.

Step 2: confirm the exact, narrow condition

A specific weakness usually depends on precise conditions: an exact feature being enabled, a specific configuration, sometimes a specific version range. Before attempting exploitation, use what you learned about banner grabbing and manual interaction (chapter 2) to confirm, as closely as you reasonably can, that the condition described by your chosen module or technique actually matches what you observe on the target. This step turns a hopeful guess into a targeted attempt, and it is what separates a tester who understands their tools from one who is only clicking buttons.

Step 3: attempt in a controlled, observable way

Run the attempt once, in a quiet moment where you can watch both your own console and, if possible, the target's behaviour (for example by having a second terminal open on the target machine, in your own lab, to watch its logs or resource usage). Note the exact time. If it succeeds, you typically get some form of interactive access or a clear proof, such as reading a specific marker file that the training platform asks you to find (often called a "flag" in these training exercises) to confirm the exercise is complete.

Step 4: verify you actually have what you think you have

A common mistake is to assume success too quickly. If you believe you have command execution on a target, confirm it with simple, safe commands that reveal information without changing anything: for example, asking the system to report its own identity, its current user, or its version information, exactly the kind of commands that training-platform walkthroughs typically suggest as a first check. Do not jump straight into more invasive actions before this basic confirmation.

# Example of safe, read-only confirmation commands
# (run only on a machine from your own authorised lab or training platform)
whoami
hostname
id

These three commands are harmless information requests, useful to confirm exactly what level of access you have obtained before deciding on any next step.

Step 5: document before you do anything else

As soon as you have confirmed access, stop and write it down, in detail, in your journal: exact target, exact time, exact module or technique, exact commands used, and exact output observed, together with a screenshot if your evidence folder structure from chapter 1 calls for one. This discipline matters for two reasons: first, you may need to reproduce the exact same result later for the client or for a retest; second, if anything goes wrong afterwards, this is the record that shows precisely what you did and when.

Common reasons an attempt fails

Exploitation does not always work on the first try, even against a genuinely vulnerable target, and understanding why helps you avoid wasted time:

• A slightly different configuration than what the module or technique expects, which your careful confirmation in step 2 should have flagged.
• A protective control already in place, such as a firewall rule, an intrusion prevention system, or a patch applied after the public weakness was disclosed, which is in itself a useful, positive finding worth reporting.
• A timing or network issue, especially over virtual networks, which is usually solved by re-checking basic connectivity (something you already practised with simple tools in chapter 2).

When something fails, resist the urge to immediately try many different modules or techniques at random. Go back to step 2, confirm your understanding of the actual target more carefully, and only then try a different, specifically justified approach.

What a professional never does at this stage

• Never attempt a technique against anything outside the authorised scope, even "just quickly", even if it looks easy.
• Never use a destructive payload (one that deletes data or disables a service) unless the client has explicitly agreed to that specific risk in writing.
• Never leave an open access path (such as an added account or an open listening port created during the test) on the target without recording it and removing it before the engagement closes, which is exactly the kind of clean-up a careful tester plans for.

Your fil rouge: one confirmed finding for Lighthouse Labs

Pick the training-platform machine or lab VM you used for your exploitation plan in the previous lesson, follow that platform's own official, legitimate material to work through one vulnerable service, and apply steps 1 to 5 above exactly as described: reconnect your notes, confirm the condition, attempt once, verify with safe commands, and write a complete, dated entry in your journal. This single, carefully documented entry is the model you will reuse for every later finding in this course and, eventually, in real engagements.

Your turn: write a documentation entry

Imagine you successfully obtained command execution on a lab machine at 192.168.56.22 through a weak, outdated service on port 21, at 15:42 on a given day, and confirmed it by running whoami, which returned a non-administrative username. Write the journal entry you would file for this, following the five-step structure of this lesson.

See a solution

A reasonable entry: "2026-01-14 15:42 — Target 192.168.56.22, lab VM. Attempted exploitation of the outdated service on port 21, previously flagged as a high-priority candidate in the chapter 3 priority list (confidence: high, cross-checked banner and behaviour). Single attempt via [module/technique name from the training platform's own material]. Result: command execution obtained. Verified with whoami, returning a non-administrative username, confirming low-privilege access only. No destructive action taken. Next step: proceed to privilege escalation testing in chapter 6, and note this finding for the report as medium-to-high priority pending privilege analysis." This entry reconnects to earlier notes, states exactly what was done and confirmed, and sets up the next phase, exactly the habit this lesson is meant to build.

Once you have a foothold on a system, the next lesson introduces the idea of a shell and how it becomes the tester's main working interface on a compromised machine.