NMAP Simulator

What you're practicing: real Nmap syntax and — just as importantly — reading real scan output, on a fully offline, fictional 6-host lab network. Nothing here touches a real network; every host, port, and service is simulated. This is the expanded version of this lab: a deeper look at anatomy of the output, a guided tour of all six hosts, and more practice per command.

🌐 The lab network

Type targets any time to see the full list. There are six hosts, all in 10.10.10.0/24, each playing a different real-world role. Part of this lab is simply getting used to scanning a range and noticing that every machine looks different — a skill that matters far more in real recon work than memorising flags does.

📖 Glossary — skip if these are familiar

• Port — a numbered "door" a service listens on (e.g. port 22 for SSH, port 80 for web traffic).
• Service — the actual program answering on that port (ssh, http, smtp, and so on).
• State (open) — every port shown in this lab is open, meaning something is actively listening there. In real Nmap you'd also see closed/filtered, but this lab only ever shows open ports to keep the output focused for now.
• Version detection (-sV) — asks each open port what software and version it's running, not just what service type it is.
• OS detection (-O) — attempts to identify the operating system of the target based on how it responds.
• Aggressive scan (-A) — a shortcut flag that turns on version detection, OS detection, and default vulnerability scripts all at once.
• Latency — the "Host is up (0.0Xs latency)" line reports how long the target took to respond; in a real scan this hints at network distance, here it's simulated but still worth reading.

🔬 Anatomy of a scan report

Before scanning everything, slow down and understand every line a report gives you, using this example structure:

• Line 1 — the Nmap version and the exact time the "scan" started. In a real audit, timestamps matter for your report.
• Line 2 — "Nmap scan report for <hostname> (<ip>)" — confirms exactly which machine you're looking at.
• Line 3 — "Host is up" plus latency — confirms the target responded at all, before you even look at ports.
• The port table — PORT / STATE / SERVICE (and VERSION if you used -sV or -A) — the actual findings.
• OS details (only with -O or -A) — a best-guess operating system line.
• Final line — "Nmap done" plus a summary of hosts scanned and how long it took.

Get in the habit of reading top to bottom in that order every time, rather than jumping straight to the port list — real analysts confirm the host is even up before trusting anything below it.

🛠️ Step-by-step

1. Click "Open" to launch the terminal. Read the banner at the top — it already shows you three example commands and how to list the lab range.
2. Type targets and press Enter. Write down how many hosts you see and their names — you'll be comparing them as you go.
3. Run a basic scan on the first host: nmap 10.10.10.5. Read the output slowly, top to bottom, using the "Anatomy of a scan report" structure above as your checklist.
4. Checkpoint: can you point to (or say out loud) which line confirmed the host was up, before you even looked at the ports? If not, scroll back and find it before moving on.
5. Before scanning again, predict: if you add -sV to the same command, what new column do you expect to appear, and roughly how much longer do you expect the output to be?
6. Run nmap -sV 10.10.10.5 and check both predictions against the new VERSION column and the extra line length.
7. Try an intentionally wrong target, like nmap 10.10.10.99, and read the "Host seems down" message carefully — this is what a real Nmap looks like when nothing answers, and it's a normal, expected result, not an error in your typing.
8. Run help and read every line, even the ones you think you already know — note which flag you haven't tried yet.
9. Guided host tour — scan each remaining host with a plain nmap <ip> first, before any flags, and answer one question per host as you go (see the table below).
10. Now re-scan at least three of those hosts with -sV added, and compare: does knowing the exact software version change or confirm your earlier guess about what the machine does?
11. Try nmap -A 10.10.10.20 — the aggressive scan — and count how many extra lines of information appeared compared to your plain scan of the same host.
12. Try narrowing a scan: nmap -p 22,80 10.10.10.5. Compare the output length to your original full scan of that host, and note which ports were left out.
13. Deliberately type nmap with no target at all and press Enter. Read the usage message it gives you — this is what you'll see any time you forget to add a target, so it's worth seeing on purpose once.
14. Once you've scanned the full range at least once each, and used -sV, -O (or -A), and -p at least once each, click Save and keep your session.

🗺️ Guided host tour — one question per host

• 10.10.10.5 — after a plain scan, which two ports suggest this is a public-facing web server?
• 10.10.10.10 — three of this host's ports relate to the same general purpose. What is it, and which port is the odd one out?
• 10.10.10.15 — this host's OS description (try -O) hints at something. What word in the OS line suggests this machine might be neglected?
• 10.10.10.20 — this is the only Windows host in the range. Which single port number is the strongest giveaway of that, even before reading the OS line?
• 10.10.10.25 — one port here is unusual for a production server and much more common on a developer's own machine. Which one, and why?
• 10.10.10.30 — this host's service description (with -sV) contains a warning most of the others don't. What does it say, and why should it worry a real network defender?

🎯 Practice tasks

1. Guess before you look. For each of the six hosts, run a plain scan first and try to guess what the machine's job is from the open ports alone — before adding -sV to confirm.
2. Find the odd one out. One host in this range is clearly not a typical office server — identify which one and explain in one sentence what gave it away.
3. Narrow your view, twice. Try -p with a single port on one host, then with three ports on a different host, and compare how much each narrows the output relative to a full scan.
4. Full picture, one command. Run -A against any host and list all three things it added compared to a plain scan.
5. Compare two hosts side by side. Pick any two hosts, scan both with -sV, and write one sentence comparing what kind of machine each one most likely is, based only on their services.

🧯 Common mistakes

• "Host seems down" on every scan — double-check the IP is exactly one from targets; a typo'd last octet (like .05 instead of .5) won't match.
• "command not found" — every scan must start with the word nmap — typing just an IP address on its own isn't a valid command here, same as in a real terminal.
• Not reading the whole output — it's tempting to just glance at the port list and move on; the "Host is up" line, the timing line, and (with -O/-A) the OS details line all carry real information too.
• Confusing "service" with "version" — ssh is the service; OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (only shown with -sV or -A) is the version. Beginners often treat these as the same thing.
• Assuming more flags always means a better scan — -A is convenient, but a real analyst still reads a plain scan first; jumping straight to the heaviest command every time skips the habit of noticing what's unusual before you're flooded with detail.
• Skimming the "Nmap done" line — it's easy to ignore, but it's a quick way to confirm your scan actually completed and scanned the host you meant to.

✅ Before you save, check:

• You've run at least one scan against every host in the range, not just one or two
• You've used -sV, -O (or -A), and -p each at least once, and can explain what each one changed
• You correctly predicted at least one result before running the command
• You tried an invalid target and a missing-target command on purpose, and understood both messages rather than assuming something broke
• You answered all six guided-tour questions
• Your saved title describes what you actually did, not just "NMAP Practice"

💭 Reflection (a sentence or two, before you save)

Which of the six hosts took the longest to correctly guess its purpose, and what finally gave it away — a specific port, the service version, or the OS line?

💡 Tip: real recon work is less about memorising flags and more about reading output carefully and asking "what does this port tell me about this machine?" — get that habit solid here, on a completely safe fictional range, before Lab 2 introduces scan timing, stealth, and combining flags the way a real engagement does.

# Lab: Network Recon with Nmap (Intermediate) — Expanded Edition **Tool:** NMAP Simulator (Practice Sandbox) **Level:** Intermediate — you should already know what a port scan is and have completed a basic "scan one host" exercise before this one **Environment:** Fully offline, simulated network — `10.10.10.0/24` **Time:** 60–75 minutes **Format:** 9 parts + final report + save-and-submit --- ## Before you start Launch the NMAP Simulator from your dashboard. Type `targets` to see every host in the lab range, and `help` at any time to see the full command list. ``` targets ``` You should see six hosts. Nothing here touches a real network — it's safe to try anything, break things, and re-run commands as many times as you want. ## Learning objectives By the end of this lab you will be able to: 1. Run and interpret a baseline scan, a version-detection scan, and an OS-detection scan 2. Scope scans to specific ports and explain why a real pentester would do that 3. Run and read a vulnerability check, and explain both the risk and the fix 4. Recognize security weaknesses that don't come with a CVE (misconfigurations, default credentials, outdated OS) 5. Profile every host on a network by role (web server, mail server, file server, domain controller, dev box, IoT device) 6. Prioritize a full network's hosts by risk and produce a short written recon report, the way a junior pentester would hand off findings to a lead --- ## Quick reference — commands you'll use in this lab | Command | What it does | |---|---| | `nmap ` | Basic port/service state scan | | `nmap -sV ` | Adds version detection | | `nmap -O ` | Adds OS detection | | `nmap -A ` | Aggressive scan (version + OS + default scripts) | | `nmap -p ` | Scan only the ports you list, e.g. `-p 22,80` | | `nmap --script vuln ` | Check for known vulnerabilities | | `targets` | List every host in the lab range | | `clear` | Clear the terminal | --- ## Part 1 — Map the network before you scan anything Before running a single `nmap` command, run `targets` and just look at the IP list and hostnames. **Task:** Based on hostnames alone (`web-01`, `mail-01`, `fileserver-01`, `dc-01`, `dev-01`, `iot-cam-01`), guess what role each host plays and what ports you *expect* to find open on each, before you scan. Write this down — you'll compare it to your real findings later. This is a habit real pentesters build: forming a hypothesis before you touch the target. ## Part 2 — Baseline sweep: the web server ``` nmap 10.10.10.5 ``` **Task:** List every open port and service name. This is `web-01` — does the port list match what you'd expect from a public-facing website? ## Part 3 — Version detection: the mail server ``` nmap -sV 10.10.10.10 ``` **Task:** Write down the exact software and version behind each port on `mail-01`. Version strings matter because they're how a real analyst would cross-check a service against a CVE database later. Which of these mail protocols normally transmit credentials in plain text if not configured with encryption? ## Part 4 — OS detection: the domain controller ``` nmap -O 10.10.10.20 ``` Then follow up with: ``` nmap -sV 10.10.10.20 ``` **Task:** What OS is `dc-01` running? Look at the port list from your `-sV` run — name at least two services here that are specific to Active Directory environments, and explain in one sentence why an exposed domain controller is a higher-value target than a random workstation. ## Part 5 — Targeted port scan: the file server You don't always want every port. Scan **only** ports 22 and 445 on `fileserver-01`: ``` nmap -p 22,445 10.10.10.15 ``` **Task:** Why would a real pentester narrow a scan like this instead of always running a full sweep? Think about scan noise (detectability), time, and the fact that you may already know from a previous engagement which ports matter on this type of host. ## Part 6 — Vulnerability check: the file server Run a full vulnerability-aware scan against the same host: ``` nmap -A 10.10.10.15 ``` or ``` nmap --script vuln 10.10.10.15 ``` **Task:** - Name the vulnerability that comes back and its CVE identifier. - In one sentence, explain *why* it's dangerous — what could an attacker actually do with it? - In one sentence, explain the fix a real admin would apply. - This vulnerability is old and well-known. Why do vulnerabilities like this still show up on real networks years after a patch exists? ## Part 7 — Spot the weak link that isn't a CVE: the IoT camera ``` nmap -sV 10.10.10.30 ``` **Task:** Nothing here will show up as a CVE — but read the version/service string carefully. What's the actual security problem with this device? Why do automated vulnerability scanners often miss issues like this, even though they're some of the easiest things to exploit in the real world? Name one reason IoT devices in particular tend to accumulate problems like this. ## Part 8 — Full profile: the dev server ``` nmap -A 10.10.10.25 ``` **Task:** `dev-01` looks different from the other hosts — it's running services you wouldn't expect on production infrastructure. List what's exposed, and explain why a development server sitting on the same network segment as production hosts (like the domain controller) is itself a risk, independent of whatever software version it's running. ## Part 9 — Compare your hypothesis to reality Go back to your notes from Part 1. **Task:** For each of the six hosts, write one line comparing what you *guessed* before scanning to what you actually *found*. Where were you right? Where were you surprised? This step matters more than it looks — the gap between assumption and evidence is exactly what real recon is for. --- ## Final report Write a short recon summary (8–12 lines) covering the **whole 10.10.10.0/24 range**. Include: 1. **Priority target** — which host would you attack first if you were a penetration tester, and why (cite specific scan evidence, not a guess) 2. **Highest-impact fix** — which single change across the network would most reduce overall risk 3. **CVE-based finding** — the vulnerability from Part 6, stated with its CVE ID 4. **Non-CVE finding** — the IoT weakness from Part 7, and why it wouldn't show up on a vulnerability scanner's report 5. **One thing you'd tell the network owner to check manually** — something scan output alone can't fully confirm (e.g. "are these default credentials actually still in use, or already changed?") ### Grading rubric (what a reviewer will check) | Criteria | What "meets expectations" looks like | |---|---| | Command accuracy | Correct flags used for each part; scan output actually referenced, not paraphrased from memory | | Technical accuracy | CVE ID correct; OS/service/version details match your own scan output | | Reasoning, not just reporting | Each answer explains *why*, not just *what* — "this matters because…" | | Non-CVE thinking | Part 7 and the "non-CVE finding" show you understand risk beyond automated vuln scanners | | Prioritization | Final report picks one clear priority target with evidence, not a list of everything | --- ## Common mistakes to avoid - **Treating `-A` as the only command that matters.** Real engagements often start narrow (`-p`) before going aggressive — jumping straight to `-A` on every host skips the reasoning this lab is testing. - **Copying version strings without reading them.** The IoT camera task (Part 7) is designed to catch students who skim output instead of reading it. - **Picking a "priority target" without evidence.** "dc-01 because it sounds important" is not a finding. Cite the actual open ports/vulnerability that justifies the choice. - **Skipping Part 1.** The hypothesis-before-scan habit is the actual skill this lab teaches — the scanning itself is secondary. ## Glossary - **CVE** — Common Vulnerabilities and Exposures; a public ID for a specific, documented vulnerability - **Service/version detection (`-sV`)** — identifying not just that a port is open, but what software and version is listening on it - **Aggressive scan (`-A`)** — a scan mode that combines version detection, OS detection, and default vulnerability scripts in one pass - **Attack surface** — everything exposed on a network that could potentially be targeted - **False sense of security** — believing a system is safe because an automated scanner didn't flag anything, even though real risks (like default credentials) exist outside what the scanner checks for --- ## Submit your work Click **💾 Save This Session as a Project** inside the simulator before you close it — this saves every command you ran and its output. Title it clearly, e.g. `"Nmap Lab — Full Range Recon (Expanded)"`, and attach your Part 9 comparison and Final Report as a separate write-up. ## Stretch goals (optional) 1. Re-run Part 6 and Part 7 back to back, then explain in 3–4 sentences why a single automated scan (like `--script vuln`) is not enough on its own — using the IoT camera as your example. 2. Without re-reading your Part 1 notes, try to recall all six hosts and their roles from memory. This tests whether the lab actually built retention, not just command familiarity. 3. If you were only allowed **one** scan command against the entire `10.10.10.0/24` range instead of one per host, what would you run and why? (There isn't a "correct" answer graded here — this is meant to make you think about trade-offs between thoroughness and stealth/time.)

# Lab: Network Recon with Nmap — Expert Edition ## Simulated External Recon Engagement: 10.10.10.0/24 **Tool:** NMAP Simulator (Practice Sandbox) **Level:** Expert — you should have completed the Beginner and Intermediate Nmap labs first. This lab assumes you're comfortable with `-sV`, `-O`, `-A`, `-p`, and `--script vuln` without needing them explained. **Environment:** Fully offline, simulated network — `10.10.10.0/24` **Time:** 2–3 hours (can be split across sessions — your saved project preserves every command) **Format:** You are not "doing exercises." You are running a mock engagement and producing the deliverables a real client would receive. --- ## The scenario You've been engaged as an external penetration tester by a fictional company running six hosts on `10.10.10.0/24`. You have no prior documentation, no network diagram, and no credentials. Your job is to run **black-box reconnaissance**, build your own picture of the network from scratch, identify risk, and hand off a professional report — the same structure a real client-facing pentest report follows: **executive summary → methodology → findings → risk ranking → remediation plan.** This lab does not walk you through each host one at a time and tell you what to expect. You decide your own scan order, your own depth per host, and you have to justify every decision in your final report. That's the difference between "intermediate" and "expert" here: intermediate labs told you what to run. This one asks you what you'd run, and to defend why. Nothing in this lab touches a real network. Type `targets` and `help` at any point if you need a refresher on the command set — but the structure and reasoning below is now on you. --- ## Learning objectives By the end of this lab you will be able to: 1. Run a full reconnaissance engagement from zero information to a complete network profile, without being told the scan order 2. Justify scan choices in terms of stealth, time, and information yield — not just "because the lab said so" 3. Distinguish CVE-based findings from configuration/design-based findings, and score both for risk 4. Build an attack path across multiple hosts, not just a single-host vulnerability 5. Separate a technical finding from its business impact, and write both an executive summary and a technical appendix 6. Prioritize a remediation plan under the assumption the client can only fix **three things** before their next audit 7. Critically evaluate the limits of what a scanning tool like this can and can't tell you --- ## Phase 0 — Rules of engagement (write this first) Before running a single command, write a short **rules of engagement** note for yourself, as if a client had actually authorized this work: - Scope: `10.10.10.0/24` — nothing outside this range - Objective: identify all live hosts, profile each host's role, identify vulnerabilities and misconfigurations, and rank overall network risk - Constraint: assume this is a scoped external test — you don't know in advance how many hosts exist or what they do This isn't busywork. In a real engagement, scope and rules of engagement are a legal document. Writing it here builds the habit of never scanning a live target without a defined, agreed scope. ## Phase 1 — Discovery (no assumptions) Run: ``` targets ``` **Task:** Before doing anything else, write down every IP and hostname exactly as returned — this is your asset inventory. Do not guess at roles yet. A real engagement often starts with far less clarity than a clean hostname list, so treat even these names as a hint, not a fact, until you verify with a scan. ## Phase 2 — Triage sweep (breadth before depth) Run a **plain baseline scan** — no flags — against every single host in the range, one at a time: ``` nmap 10.10.10.5 nmap 10.10.10.10 nmap 10.10.10.15 nmap 10.10.10.20 nmap 10.10.10.25 nmap 10.10.10.30 ``` **Task:** For each host, record just the open ports — nothing else yet. This is your **triage pass**. In a real engagement, you sweep broad before you go deep on any single host, because the host that *looks* boring at a glance might turn out to be your priority target once you know what everything else looks like. Build a simple table: | IP | Hostname | Open Ports | |---|---|---| ## Phase 3 — Service and version enumeration Now go host by host and run `-sV` on each: ``` nmap -sV ``` **Task:** Expand your table with software + version for every port. Flag (★) any version string that looks outdated to you, based on general knowledge of typical release cadences — even before you run a vulnerability check. This is a skill real analysts build: spotting "that version is old" on sight, before a tool confirms it. ## Phase 4 — OS fingerprinting and role classification Run `-O` on every host that looks like infrastructure rather than an appliance (you decide which — justify it in your report if you skip one): ``` nmap -O ``` **Task:** For each host, write a one-line role classification: e.g. "web front-end," "internal mail relay," "domain controller," "developer sandbox," "IoT/embedded appliance." Base this on the combination of OS + open ports + service names, not on the hostname alone — hostnames can be wrong or misleading in a real environment, and this lab's names are a convenience, not something you should rely on as evidence in your final write-up. ## Phase 5 — Vulnerability sweep Run an aggressive scan **or** an explicit vuln script scan against every host: ``` nmap -A ``` ``` nmap --script vuln ``` **Task:** Only one host in this range returns a scripted vulnerability finding. For that host: - Record the CVE ID - Look up (from what you already know, or general security knowledge) roughly what year this vulnerability became public - Explain why a vulnerability that old, with a patch that's existed for years, still commonly shows up on real networks For every *other* host: explicitly state "no scripted vulnerability returned" in your notes. **This is not the same as "this host is secure."** You'll need that distinction for Phase 7. ## Phase 6 — Scoped re-verification Pick the **two hosts you consider most sensitive** from your Phase 4 role classifications. For each, run a **targeted port scan** limited to just the ports that matter for that host's role: ``` nmap -p ``` **Task:** Justify your port selection in one sentence per host. Then explain, in general terms, why a real engagement would re-verify sensitive hosts with a narrower, more deliberate scan rather than relying only on the earlier broad sweep — think about noise, IDS/IPS detection likelihood, and the value of a second, more careful look at what matters most. ## Phase 7 — Non-CVE risk analysis This is the phase that separates an expert from someone who only knows how to read a vulnerability scanner's output. **Task:** Go back through every host's `-sV` output. For each host that returned **no CVE**, ask: *is this host actually safe, or does it just not have a scripted vulnerability check written for its specific problem?* At least one host in this range has a serious real-world risk that will **never** show up in a `--script vuln` result, because the risk isn't a software bug — it's a configuration/design choice. Find it. Explain: - What the risk actually is - Why an automated scanner structurally cannot detect it - What you would need to do (outside of nmap) to actually confirm whether this risk is exploitable in practice ## Phase 8 — Attack path construction You now have a full profile of the network. Stop thinking host-by-host and start thinking like an attacker. **Task:** Construct a plausible **multi-hop attack path** using at least three of the six hosts. Example structure (do not copy this — build your own from your actual findings): > "An attacker starts at [host], because [reason it's the easiest initial entry point]. From there, they could pivot to [host] because [relationship between the two — same subnet, credential reuse potential, trust relationship, etc.]. Their final objective would be [host], because [why it's the highest-value target on this network]." This is the step most junior analysts skip — they report a list of individual findings instead of connecting them into a story of *how a real breach would actually unfold across a network.* A CVE on an isolated dev box matters far less than a CVE on a host that's one hop from your domain controller. ## Phase 9 — Risk scoring and remediation prioritization You have findings from Phase 5, Phase 7, and a path from Phase 8. Now prioritize. **Task:** Score each distinct finding (CVE-based and non-CVE) on two axes, High/Medium/Low: - **Likelihood** — how easy is this to find and exploit? - **Impact** — what's the actual consequence if it's exploited? Build a simple risk matrix: | Finding | Host | Likelihood | Impact | Overall Priority | |---|---|---|---|---| Then — the hard constraint that makes this an expert exercise, not a checklist — **the client can only act on three findings before their next compliance audit.** Pick the three. Defend your choice in 3–4 sentences, explicitly explaining what you're *not* fixing and why that's an acceptable short-term trade-off. --- ## Deliverable: Full Engagement Report Structure your final write-up exactly like a real external pentest report would be structured. This is the actual point of the "expert" version of this lab — translating technical scan output into something a non-technical decision-maker and a technical remediation team can both use. ### 1. Executive Summary (4–6 sentences, no jargon) Written for someone who has never heard of Nmap. Answer: how exposed is this network, in plain language, and what's the single most urgent risk? ### 2. Scope & Methodology (short paragraph) What you tested, what tooling/technique you used at each stage, referencing your Phase 0–6 approach at a high level (not command-by-command). ### 3. Asset Inventory Your completed table from Phases 2–4: every host, its role, its OS, and its notable open services. ### 4. Findings (Technical Appendix) One entry per finding from your Phase 9 risk matrix. Each entry needs: affected host, description, evidence (reference your actual scan output — quote the relevant line), likelihood, impact, and recommended fix. ### 5. Attack Path Narrative Your Phase 8 write-up, cleaned up into 1–2 short paragraphs. ### 6. Remediation Priorities Your top-3 from Phase 9, with the trade-off justification for what's deferred. ### 7. Limitations of This Assessment Every real pentest report includes a section like this. In 3–5 sentences: what could this engagement **not** tell you, given that it was a scan-only assessment with no credentials, no manual verification, and no social-engineering component? This section matters — it's what separates a professional report from an over-claiming one. --- ### Grading rubric | Criteria | What "expert level" looks like | |---|---| | Independent scan planning | You chose scan order and depth yourself, with stated reasoning — not just following a fixed sequence | | Non-CVE finding identified correctly | Phase 7's design/config risk is correctly identified and explained, not confused with a scripted vuln | | Attack path is plausible and evidence-based | Phase 8 references actual scan findings to justify each hop, not generic pentesting tropes | | Prioritization under constraint | Top-3 choice in Phase 9 is defended with real trade-off reasoning, not just "these seemed worst" | | Report separates audiences | Executive Summary is genuinely non-technical; Technical Appendix is genuinely detailed. Reviewers will check these are actually different in tone and depth, not the same paragraph twice | | Limitations section is honest | You correctly state what a scan-only, no-credential assessment cannot claim to have verified | --- ## Common mistakes at this level - **Treating this like the intermediate lab with more steps.** The point isn't running more commands — it's the reasoning connecting them. A report that's just "here's what I found on each host" in order has missed the assignment. - **Confusing "no CVE returned" with "no risk."** This is the single most common real-world reporting failure this lab is designed to catch (see Phase 7). - **An attack path that's just a list, not a narrative.** "Host A has X, Host B has Y, Host C has Z" is not an attack path. An attack path explains *how* an attacker moves from one to the next. - **An executive summary full of technical terms.** If it mentions a port number, a CVE ID, or a flag like `-sV`, it belongs in the Technical Appendix, not the Executive Summary. - **Overclaiming certainty.** A scan-only assessment cannot prove something is *not* exploitable — only that a particular check didn't flag it. Your Limitations section should reflect that honestly. ## Glossary (expert terms used in this lab) - **Black-box testing** — testing with no prior knowledge of the target beyond what's in scope - **Rules of engagement** — the documented scope, boundaries, and authorization for a security test - **Triage pass** — a fast, broad initial scan used to prioritize where to spend deeper effort - **Attack path / attack chain** — a sequence of individual weaknesses chained together into a realistic route to a high-value target - **Likelihood vs. impact** — the two axes used in most professional risk-scoring models (this is a simplified stand-in for frameworks like CVSS) - **False negative (in scanning)** — when a real vulnerability exists but the tool doesn't flag it, because it isn't a check the tool knows to run --- ## Submit your work Click **💾 Save This Session as a Project** before closing the simulator — every command and its output is preserved. Title it `"Nmap Lab — Expert Engagement Report"` and attach your full 7-section report (Executive Summary through Limitations) as a separate write-up alongside it. ## Stretch goals (optional, for going beyond the lab) 1. Rewrite your Executive Summary as if the client's CEO will read only that section and nothing else — no analyst follow-up call. Does it still communicate the right level of urgency? 2. Re-run Phase 9's risk matrix, but this time assume the client can fix **only one** finding. Does your answer change? Defend it. 3. In 4–5 sentences: if this had been a real engagement instead of a simulation, what's the very first thing you'd ask the client for permission to do next (credentialed scanning, manual verification, social engineering, etc.), and why is that the logical next step after a scan-only assessment?