Exploiting an exposed service

Objective 4.1 in this course covers network attacks — VLAN hopping, on-path attacks and service exploitation. This is the third, and it is the applied lab for the objective. The target is a deliberately weak service on a machine you built, in the lab from lesson 2.

Why this matters

This is the step the whole first half of the course has been building towards, and it is where the discipline established in Domain 3 pays off: you have a service, a version, and a candidate vulnerability, and the question is whether it is real.

It is also the most dangerous thing in the course. Running exploit code is running someone else's program with your privileges against someone else's system, and both halves of that deserve more caution than they usually get.

The lesson

From version to candidate vulnerability to proof

The chain from Domain 3, made concrete:

1. A service and a version, from lesson 10 — remembering that the version is inference and lesson 18's backporting caveat applies.
2. Candidate vulnerabilities for that version, from a vulnerability database. This is a list of possibilities.
3. Applicability, which is the step most often skipped. Does the vulnerability apply to this platform, this build, this configuration? Many require a non-default setting, a specific module, or a particular architecture.
4. Proof, per lesson 18's ladder: observe the condition, demonstrate on your own replica, a safe subset on the target, or a full exploit with explicit permission.

The discipline that matters: know which step you are on when you write the finding. "Version 1.2.3 is affected by CVE-XXXX" is step 2 and is not a finding. "We confirmed the vulnerable configuration is present and demonstrated the flaw against an identical build in our lab" is a finding.

Reading an exploit before running it, every line

The rule from lessons 12 and 14, stated at its strongest, because this is where it matters most.

Public exploit code is written by strangers, published on public sites, and frequently copied without review. Before running anything:

• What does it connect to? Look for hardcoded addresses. Exploits have shipped with code reporting the target back to a third party.
• What is the payload, exactly? Encoded, obfuscated or downloaded-at-runtime payloads are the ones to be most suspicious of. A payload you cannot read is a program you are running blind on a client's machine.
• What does it do to the target? Overwriting memory, dropping files, or restarting a service each have different consequences, and some crash the service as a side effect.
• Is it reversible? What does it leave behind, and can you remove it? That answer goes straight into the cleanup list, which lesson 39 covers — written down now rather than at the end.
• Does it match the CVE it claims? Proof-of-concept code is sometimes mislabelled, and occasionally is simply malware wearing a CVE number.

If you cannot read it — compiled, obfuscated, or in a language you do not know — you cannot run it on a client's system. Test it in the lab, or do not use it.

Public exploit code and the payload you did not notice

Worth its own section, because it is a recurring way that testers hurt clients.

The pattern: an exploit is downloaded, it is long, the interesting part is at the top, and somewhere below is a line that fetches and executes something from a remote host. It runs; the exploit works; something else also ran.

Defences:

• Read the whole file, including the part after the interesting bit.
• Be suspicious of long encoded blobs. Decode them before running.
• Prefer maintained frameworks for common exploits, where the code has had many eyes on it.
• Run unknown code in the lab first, on a snapshot you can roll back (lesson 2), with traffic capture on so you can see what it contacts.
• Never run unreviewed exploit code on a client's system because it worked in the lab. The lab run is what tells you it is safe to consider.

The professional stake: if you introduce a compromise while testing, you caused the incident you were hired to prevent, and the authorisation letter will not help you.

Exploiting a deliberately weak service in your lab

The applied lab for objective 4.1, and the shape of the exercise:

1. Stand up a service with a known flaw on a lab VM — an old version of something, installed deliberately, with no route to anything real.
2. Snapshot before you touch it, so the whole exercise is repeatable. This is the habit from lesson 2 earning its place.
3. Scan it as in lesson 12, and identify the service and version from the outside as though you did not already know.
4. Find the candidate vulnerability, and read what it actually requires.
5. Read the exploit, using the checklist above, before running anything.
6. Capture traffic while it runs, per lesson 13. Seeing what the exploit puts on the wire is the single most instructive part of the exercise.
7. Run it, observe what you get, and note what broke — services often crash.
8. Look at the target's logs, which is what makes you able to write the defender's half of the report.
9. Roll back to the snapshot and do it again, more carefully.

The point of steps 6 and 8 is the one people skip. Anyone can follow an exploit to a shell. Knowing what it looked like on the wire and in the logs is what makes you able to write lesson 40's attack narrative and lesson 41's remediation.

Recording exactly what you ran, for the report and the cleanup

Two obligations start the moment an exploit succeeds, and both are easier if you prepared for them.

For the report, per lesson 6: the exact command or module and its options, the target, the timestamp, the output, and what access it produced. A finding that cannot be reproduced by the client's engineer is a finding they cannot verify or confirm fixed.

For the cleanup, which lesson 39 covers: a running list, written as you go, of everything the exploit changed — files dropped, processes started, accounts created, configuration altered, connections opened. Reconstructing it at the end of an engagement from memory is how testers leave things behind, and leaving an access mechanism behind on a client's system is the worst outcome in this course.

The habit that makes both work: keep the cleanup list open in a second window and add to it at the moment you cause the change, not afterwards. It costs seconds and it is the difference between a professional engagement and an embarrassing email six months later.

What to take into the exam

• Version to candidate to applicability to proof — know which step you are on when you write the finding.
• Read exploit code fully before running: what it connects to, the exact payload, what it changes, whether it is reversible, whether it matches its CVE.
• Unreadable code cannot run on a client's system.
• Capture traffic and read the target's logs during the lab exercise; that is what makes the defender's half of the report possible.
• Record the exact invocation for reproduction, and add to the cleanup list at the moment you cause each change.