Step 343. The Integrated Intrusion Scenario — Operating Your Full Capability: From a List of Techniques to an Operation

Level 4 — Professional | Difficulty ★★★★★ | Estimated time: 2 days (half a day of scenario design + 8 hours of execution + half a day for the report)

Prerequisites: Step 272’s intrusion playbook v1.0, Step 264’s credential table and network map, Step 278’s live-fire check experience. This chapter’s lab-build script and intrusion outputs were measured in this book’s lab (WSL, Ubuntu 24.04, Nmap 7.94, Python 3.12).

What you need: a local lab (WSL or a bundle of virtual machines), Step 272’s playbook, a timeline note, and a timer. This chapter is "one-person red team — a full intrusion scenario against the local lab."
Caution: this chapter’s measurement validated a scaled-down scenario on 127.0.0.1 (one web server + one internal API). If your lab has a web server, workstation, and domain connected, extend the same procedure to the full lab — the procedure and recording method are identical.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Every target today is a local lab you launched yourself.

A real penetration test is not "finding vulnerabilities" — it’s "a goal-achievement scenario." A client’s engagement document reads like this: "Starting from the outside, exfiltrate the confidential file from the internal document server." Not a test of individual techniques, but the work of weaving recon, web attacks, initial access, privilege escalation, lateral movement, evidence collection, and the report into a single operation.

Everything you’ve learned so far merges into one chain today. The experience of individual techniques turning into an "operation" — that is the professional’s final puzzle. Today you design that operation against a local lab, execute it, and complete it through to the deliverable.

1. Learning Objectives

By the end of this chapter, you will be able to:

Define an intrusion scenario with the three elements of goal, starting point, and rules
Build an operation plan containing the expected path and per-stage candidate techniques
Record the entire process as a timeline while amending the plan on the spot when it breaks
Build a "chain" with the credential table and asset map to reach the goal
Write an integrated report: intrusion-path summary, per-stage evidence, timeline, remediation recommendations

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Linux shell (WSL), Python 3 (lab build), nmap, curl, a timeline note
Today’s command	`nmap -sV target -p range` · `curl -si URL` · `curl -u user:password URL`
Concepts needed	Scenario-based intrusion, operation planning, credential reuse, asset maps, timeline recording
Today’s deliverable	A scenario definition + an operation plan + an execution timeline + 1 integrated report

2-1. Scenario-Based Intrusion — The Engagement Document Is the Exam Paper

The difference between machine-solving and a real penetration test lies in "the shape of the goal." A machine’s goal is fixed answers called user.txt and root.txt, but a real operation’s goal is one sentence in an engagement document — "prove the feasibility of exfiltrating the confidential file," "show the path to domain-admin privileges."

This difference changes everything. With no fixed answer, the judgment of "solved" is mine to make, and the form of the proof (evidence, path, report) is part of the deliverable. Which is why today’s first task is not attacking but scenario definition — fixing the three elements of goal, starting point, and rules into a document.

2-2. Today’s Scenario — The lab-corp Scaled-Down Version

Here’s the scenario this chapter executes hands-on. If your lab is larger, extend this skeleton as-is.

Scenario definition (for this chapter's measurement):
- Background: fictional company lab-corp. One public web server outside, one API server inside
- Goal: obtain /flag.txt from the internal API server (proof of confidential-file exfiltration)
- Starting point: external — only the public web server's address is known
- Rules: no time limit (reproduction training); targets are only the lab on 127.0.0.1
- Verdict: print the flag's contents to screen; the full path must be reproducible from the timeline

A scenario example for extending to a full lab looks like this — "Starting knowing only the external public web server, obtain a specific file from the domain controller. Time limit 8 hours." Only the goal’s depth changes; the definition’s format is the same.

2-3. Chain Thinking — Solve Not Individual Machines but Connections

The point where practitioners get stuck most is this chapter’s core theme — "I can solve individual machines, but the connection doesn’t work." What makes a chain is not technique — it’s two maps.

① The credential table (Step 264) — add every credential you find during exploitation (IDs, passwords, keys, tokens) to the table the moment you find it. Columns: "credential / where found / where tried." ② The asset map — connect discovered hosts, services, and document paths into a graph. A chain is testing, one by one, the product of "credentials not yet tried × assets not yet visited" on these two maps. Stuckness comes not from running out of technique but from an un-updated map.

2-4. Timeline Recording — The Operation’s Black Box

The recording format during scenario execution has four columns — time / action / result / information gained.

Timeline format (screen example):
| time | action | result | information gained |
| 13:00 | nmap full port scan | 8080, 9000 open | internal services presumed to exist |

This record becomes three things — during execution, the positional sense of "how far have I come"; when stuck, a list of branch points to return to; after the end, the report’s skeleton. In an 8-hour operation, memory blurs within an hour. The record is the proof.

3. Follow Along

3-1. Building the Target Lab — Measured

Build the scaled-down lab yourself. Two machines — a public web server (8080) and an internal API (9000, Basic auth) — and the connecting link is "a config backup carelessly left on the web server." Create the files under ~/lab343/.

The public web server’s documents. ~/lab343/web/index.html:

<!DOCTYPE html>
<html>
<head><title>lab-corp public server</title></head>
<body>
<h1>Welcome to lab-corp</h1>
<p>This site is a dummy service for local-lab training.</p>
<!-- TODO(dev): clean up /backup/ before deployment. The config backup is still up there -->
</body>
</html>

~/lab343/web/robots.txt:

User-agent: *
Disallow: /backup/

~/lab343/web/backup/config.bak:

# lab-corp deploy config (OLD - rotate me)
internal_api_url=http://127.0.0.1:9000/
internal_api_user=deploy
internal_api_pass=Sp-ring2026!

The internal API server ~/lab343/internal_server.py and the goal file ~/lab343/internal/flag.txt:

# internal_server.py — internal API behind Basic auth (lab use)
from http.server import BaseHTTPRequestHandler, HTTPServer
import base64, os

USER, PW = "deploy", "Sp-ring2026!"

class H(BaseHTTPRequestHandler):
    def do_GET(self):
        auth = self.headers.get("Authorization", "")
        ok = auth == "Basic " + base64.b64encode(f"{USER}:{PW}".encode()).decode()
        if not ok:
            self.send_response(401)
            self.send_header("WWW-Authenticate", "Basic realm="lab-internal"")
            self.end_headers()
            self.wfile.write(b"401 Unauthorizedn")
            return
        if self.path == "/flag.txt":
            body = open(os.path.expanduser("~/lab343/internal/flag.txt"), "rb").read()
            self.send_response(200); self.end_headers(); self.wfile.write(body)
        else:
            self.send_response(200); self.end_headers()
            self.wfile.write(b"lab-corp internal api v0.3 - endpoints: /flag.txtn")
    def log_message(self, *a):
        pass

HTTPServer(("127.0.0.1", 9000), H).serve_forever()

Save flag.txt with the contents flag{ch4in_0f_c0nfi6_l3ak}, and launch the two servers (set them to terminate automatically via timeout when training ends):

timeout 300 python3 -m http.server 8080 --bind 127.0.0.1 -d ~/lab343/web &
timeout 300 python3 ~/lab343/internal_server.py &
sleep 1

3-2. The Operation Plan — Draw the Path Before Executing

Before launching the servers (in your lab, before scanning), build the operation plan. A plan is not a prediction — it’s a branch table.

Operation plan (screen example):
Expected path: recon (port scan) → public-web enumeration → check for exposed configs/backups
             → obtain credentials → reuse on internal assets → obtain the goal file
Per-stage candidate techniques:
  recon     : nmap -sV all ports
  web enum  : read the index source (including comments), robots.txt, common paths
  auth bypass: reuse of discovered credentials (reuse is the chain's basic assumption)
Stuck branch: if the web yields nothing → full-port rescan + top UDP
             → playbook (Step 272) 08 stuck-response tree

3-3. Execution 1 — Recon (Measured)

Start the timer and begin the operation. The first command is exactly the playbook’s recon card.

nmap -sV 127.0.0.1 -p 1-10000

Here’s the measured output:

Not shown: 9998 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
8080/tcp open  http    SimpleHTTPServer 0.6 (Python 3.12.3)
9000/tcp open  http    BaseHTTPServer 0.6 (Python 3.12.3)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.27 seconds

How to read it: two HTTP services are visible. 8080 is the public web server (the starting point), and 9000 is a second service not in any document — "besides what’s public, what else is there?" is recon’s only question. Record this one line as the timeline’s first row: 13:00 | nmap -sV full ports | 8080, 9000 open | internal service exists.

3-4. Execution 2 — Web Enumeration and Finding the Clue (Measured)

Read the public web server. An intruder’s "reading" is not viewing the page — it’s viewing the source.

curl -s http://127.0.0.1:8080/
curl -s http://127.0.0.1:8080/robots.txt
curl -s http://127.0.0.1:8080/backup/config.bak

Here’s the measured output:

<!DOCTYPE html>
<html>
<head><title>lab-corp public server</title></head>
<body>
<h1>Welcome to lab-corp</h1>
<p>This site is a dummy service for local-lab training.</p>
<!-- TODO(dev): clean up /backup/ before deployment. The config backup is still up there -->
</body>
</html>

User-agent: *
Disallow: /backup/

# lab-corp deploy config (OLD - rotate me)
internal_api_url=http://127.0.0.1:9000/
internal_api_user=deploy
internal_api_pass=Sp-ring2026!

How to read it: three clues linked into a single chain. ① The developer memo in the HTML comment reveals /backup/‘s existence, ② robots.txt confirms the same path (the classic mistake of hiding from search engines while informing attackers), and ③ config.bak hands over the internal API’s address and credentials wholesale. Record in the timeline and add to the credential table immediately — deploy / Sp-ring2026! / found: config.bak / tried: not yet.

3-5. Execution 3 — Credential Reuse and Goal Obtained (Measured)

First knock on the internal API unauthenticated (for the record), then go back with the discovered credentials.

curl -si http://127.0.0.1:9000/ | head -8
curl -s -u deploy:Sp-ring2026! http://127.0.0.1:9000/
curl -s -u deploy:Sp-ring2026! http://127.0.0.1:9000/flag.txt

Here’s the measured output:

HTTP/1.0 401 Unauthorized
Server: BaseHTTP/0.6 Python/3.12.3
WWW-Authenticate: Basic realm="lab-internal"

401 Unauthorized

lab-corp internal api v0.3 - endpoints: /flag.txt

flag{ch4in_0f_c0nfi6_l3ak}

How to read it: the unauthenticated request’s 401 is information that "this door opens with credentials," and the WWW-Authenticate: Basic header tells you what kind. And two steps later — one row of the credential table becomes the flag. This is the chain: recon opened the asset, enumeration opened the credential, reuse opened the goal. Not one of these stages is a "vulnerability exploit," but the connected whole is a complete intrusion.

3-6. The Integrated Report — The Deliverable’s Shape

After the operation ends, write the report. Exactly the shape of a real penetration-test deliverable.

Integrated report skeleton (screen example — based on this chapter's measurement):
1. Overview — scenario goal, scope, period, result in one line
2. Intrusion-path summary — one paragraph: "Obtained internal-API credentials via an exposed
   config backup on the public web; reuse succeeded in exfiltrating the confidential file"
3. Per-stage detail — each stage: evidence (command + output), information gained, link to the next stage
4. Timeline — the full record in 2-4's format
5. Remediation recommendations — remove config backups from the web root, rotate credentials,
   review path exposure in robots.txt, network-separate the internal API
6. Appendix — all commands used, the lab configuration file list

Don’t take item 5’s recommendations lightly — what the client pays for is not the intrusion but the recommendations. The intrusion is the process that creates the recommendations’ grounds, which is why every recommendation must connect 1:1 with a stage in item 3. If a recommendation is a generality that could have been written without the intrusion ("apply the latest patches"), that report is a failure.

4. Missions & Exercises

Mission — Completing the Scenario and the Integrated Report

Write a scenario definition fitting your lab in 2-2’s format — the four items of goal, starting point, rules, and verdict are mandatory.
Check/build the scaled-down lab (or your existing full lab) referencing 3-1.
Build an operation plan in 3-2’s format, down to the stuck branches.
Start the timer and execute — record the entire process as a timeline (time/action/result/information gained), and update the credential table and asset map in real time.
Complete one integrated report with 3-6’s skeleton — the remediation recommendations must connect 1:1 with intrusion stages.

Exercises

Exercise 1. Explain the difference between machine-solving and scenario-based intrusion through "the shape of the goal," and explain what effect this difference has on the judgment of "solved" and on the deliverable.

Exercise 2. Explain the cause of the situation "I can solve individual machines but can’t connect them" from the perspective of the credential table and asset map, and summarize the procedure for making a chain in one sentence.

Exercise 3. Explain the principle by which robots.txt becomes a clue for attackers in 3-4, and answer what the defender’s correct attitude is.

Exercise 4. Explain why a report’s remediation recommendations must connect 1:1 with intrusion stages, from the perspective of "what the client pays for."

5. Model Answers & Completion Criteria

Mission Model Answer

Check against these verification criteria.

Completeness of the definition: are the four items — goal, starting point, rules, verdict — present, and is the verdict in a verifiable form (not "hack it" but "print the flag + reproduce the timeline")?
The plan’s branches: are stuck branches written, not just the expected path — is the behavior for "when the plan was wrong" in the document?
Timeline continuity: does the execution record have no gaps, and does each row’s "information gained" connect as the next row’s grounds?
Map realtimeness: does the credential table show traces (timestamps) of being updated at the moment of discovery?
1:1 connection of recommendations: does every remediation recommendation in the report point to a concrete intrusion stage as its grounds?

Exercise Answers

Answer 1. A machine’s goal is fixed answer files (user.txt, root.txt), so the judgment of "solved" belongs to the platform; a scenario’s goal is one sentence in an engagement document ("prove the feasibility of exfiltrating the confidential file"), so the judgment belongs to the performer. This difference has two effects. First, you must document the definition of completion yourself — unless you fix in advance what counts as "achieved" in the scenario definition’s verdict item, the operation never ends. Second, the deliverable must include evidence and path — an answer file is evidence in itself, but "feasibility of exfiltration" is proven only through an accumulation of timeline, command outputs, and screens. Which is why in scenario-based intrusion, records are not a byproduct — they’re the main product.

Answer 2. The cause of failed connection is mostly not running out of technique but abandoning information — if you don’t immediately put credentials and assets discovered during exploitation onto the maps, "a password I saw somewhere" evaporates from your brain and the chain’s link breaks. The procedure for making a chain, in one sentence — test, one by one, the product of credentials not yet tried × assets not yet visited. For that multiplication to be possible, the two maps must be updated in real time — which is why the credential table’s "where tried" column is the key: a chain is ultimately the work of exhausting the list of untested combinations.

Answer 3. robots.txt is a request to search engines saying "don’t index this path" — but its syntax reveals the path’s existence itself; it’s like writing "the list of things I want hidden" in a public file. In an attacker’s directory enumeration, robots.txt is always the first thing checked, and in the measurement too, Disallow: /backup/ was the intrusion path’s second link. The defender’s correct attitude is two things. ① Don’t mistake robots.txt for a secrecy device — protect sensitive paths with authentication and access control, and use robots.txt for index control only. ② Don’t leave config backups in the web root — if there’s nothing to hide, robots.txt has nothing to reveal.

Answer 4. What the client pays for is not the intrusion’s success but the answer to "what do we fix" — the intrusion is the process that creates that answer’s grounds. When recommendations connect 1:1 with intrusion stages, each recommendation becomes a concrete measure closing "a path that was actually breached" — "remove config.bak from the web root" cuts a link actually used in this operation. By contrast, a generality recommendation ("keep patches current") is a sentence that could have been written without the intrusion, so the client finds no reason to pay intrusion costs for that report. And the 1:1 connection also enables defense verification — after the fix, retrying the same chain and showing it blocked becomes the proof that the recommendation was implemented.

Completion Criteria Checklist

[ ] I wrote the scenario definition (goal · starting point · rules · verdict)
[ ] I built/checked the scaled-down lab or the full lab
[ ] I wrote the operation plan down to the stuck branches
[ ] I recorded the entire execution as a timeline
[ ] I updated the credential table and asset map in real time
[ ] I obtained the goal (flag) and left the output as evidence
[ ] I completed one integrated report, with recommendations connecting 1:1 to stages

6. Common Pitfalls & Fixes

Wall 1. I launched the servers but curl refuses the connection

Symptom: this message appears.

curl: (7) Failed to connect to 127.0.0.1 port 9000: Connection refused

Cause: suspect three things in order. ① The server process never came up or died — the timeout elapsed. ② It came up on a different port. ③ A server from a previous run is holding the port and the new server failed with Address already in use.

Fix: check listening ports with ss -tln | grep -E '8080|9000'. If a previous server remains, kill it and relaunch. Right after launching servers in the background, add sleep 1 to wait for startup — during this chapter’s own measurement, a port collision caused one failure that was resolved by relaunching. Record lab failures in the timeline too — "environment issue, 10 minutes" is also part of the operation.

Wall 2. The flag.txt request returns 200 but the body is empty

Symptom: authentication worked, yet the response body comes back empty.

Cause: the flag path the server script reads differs from the file’s actual location — it especially happens when home-directory expansion (~) varies by the executing user (this actually occurred while building this chapter’s lab — a mismatch between /root/... and ~/...).

Fix: check the server log (standard error), and fix the script’s path to match the execution environment, like os.path.expanduser("~/lab343/internal/flag.txt"). The lesson is one — before suspecting your attack commands, first confirm the lab works correctly. In scenario training, half of what "doesn’t work" is not attack failure but lab misconfiguration.

Wall 3. nmap doesn’t show the port — but the server is clearly up

Symptom: nmap -sV 127.0.0.1 (no port specification) doesn’t show 9000.

Cause: nmap’s default scan looks only at "the common 1000 ports" — port 9000 is outside the default range.

Fix: per the playbook’s rule, the second scan is all ports — this chapter used -p 1-10000, and in a live lab you use -p- (all 65535). "Not in the default scan" ≠ "doesn’t exist" — it means "not looked at yet." This one nuance was a habit in machine-solving, but in a scenario it decides the scenario’s success or failure — internal services always love non-standard ports.

Wall 4. The plan broke mid-execution — the expected path doesn’t work

Symptom: stage 2 of the operation plan yields no clues at all.

Cause: a plan is not a prediction but a branch table — breaking is normal, which is why you wrote the stuck branches in advance.

Fix: move to the branch table’s next row without emotional involvement — full-port rescan, top UDP, the playbook 08 stuck-response tree. And an important rule — when amending the plan on the spot, record the amendment in the timeline too: 13:40 | plan amended: gave up web-path enumeration -> full-port rescan | reason: no clues. Only with this record does the report avoid becoming a false document that "pretends everything went per plan." A real operation’s report honestly includes the difference between plan and execution.

Wall 5. I got the flag, but the report reads like a "diary"

Symptom: the report came out as a chronological list of "I did X, so then I did Y."

Cause: you mistook the timeline for the report — the timeline is material; the report is a document reorganized in the order of the reader’s (the client’s) questions.

Fix: keep 3-6’s skeleton order — the overview (result in one line) first, the path summary next; the timeline is item 4’s evidence material. The reader’s first question is "so, was it breached?", the second is "how?", and the third is "what do we fix?" A chronological list ignores this question order. After writing, check — can an executive who reads only the first page learn the result and the recommendations? That is the report’s passing line.

7. Summary

Today’s Concepts

Concept	One-line explanation
Scenario-based intrusion	The goal is one sentence in an engagement document — judgment and proof are the performer’s share
Scenario definition	Fix the operation with the four items: goal · starting point · rules · verdict
Operation plan	Expected path + stuck branches — designed on the premise it will break
Credential table	Record at the moment of discovery — the "where tried" column makes the chain
Asset map	A graph of hosts, services, document paths — unvisited places are the next targets
Timeline recording	Time/action/result/information gained — the operation’s black box and the report’s skeleton
1:1 recommendations	Every remediation recommendation is grounded in a real intrusion stage — what the client buys is the recommendations

Today’s Tools & Commands

Tool/command	What it does
`nmap -sV target -p range`	Recon — sees services beyond the default 1000 ports
`curl -s URL`	Reading web source — the three clues: comments, robots, backups
`curl -si URL`	Checking response headers — the 401 and WWW-Authenticate hints
`curl -u user:password URL`	Credential reuse — the chain’s connecting link
`ss -tln`	Confirming lab services are listening — first diagnosis of lab failures
Timeline format	4-column record: time/action/result/information gained

The Core Instinct

Every technique used in today’s scenario was learned earlier in this book — port scanning, reading source, checking headers, reusing credentials. Not a single new technique. Yet the moment these simple techniques moved inside the frame of "goal → plan → record → report," they were no longer practice problems — they were an operation.

The point where individual techniques turn into an operation comes not from technical depth but from operational structure. The scenario sets the goal, the maps make the chain, the timeline preserves judgment, and the report converts it into value. Today you put these four frames into your hands — what remains is repeating them onto larger labs and longer operations, and that repetition is precisely the professional’s everyday.

Once every box is checked, Step 343 is complete.