Network Security Assessment: A Practitioner’s Handbook

1.1

Why an assessor must understand the network first

A scanner produces a list. Only an engineer who understands the network can say which items matter, which are false, and which point at a deeper structural weakness the scanner never named. Three questions run through every engagement, each a networking question before it is a security one: Where does the traffic go? (topology and routing) · Who may talk to whom? (segmentation and firewalls) · What is listening, and does it prove its identity? (services, authentication, encryption).

1.2

The devices on a network, and what each means to a tester

Every network is a small set of device types repeated. Learn these and you can read any topology diagram - each in plain terms, then in terms of why the assessor cares.

Beyond these sit endpoints (workstations/servers, assessed from the inside by the host toolkit) and network-only assets (printers, NAS, cameras, OT - no host agent, assessed gently over the network because active probing can disrupt them; tagged NetworkOnly).

1.3

How machines are addressed - MAC, IP, ports, NAT

• MAC address - a permanent hardware address (a4:83:e7:2b:19:c0), used within one local segment by the switch; it does not cross a router.
• IP address - a logical address that does cross routers (10.20.4.15); what discovery and scanning work with.

Private vs public, and CIDR. RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are private - reused inside every organisation, not routable on the internet. 10.20.4.0/24 is the 256 addresses .0-.255; scanning it means “this whole subnet.” Ports (0-65535) say which service a packet is for (443 HTTPS, 445 SMB, 3389 RDP). NAT lets many private hosts share one public address, which is why the external view is far smaller than the internal one.

Reading a subnet - the one calculation to master

The /24 in 10.20.4.0/24 is the prefix length: how many of the 32 bits are the fixed network part; the rest are host addresses. A smaller number after the slash = a bigger network. Two addresses in every subnet are reserved - the first (network) and the last (broadcast) - so a /24 gives 254 usable hosts, not 256.

Worked read: 10.20.4.0/26 is 64 addresses (.0-.63), with .0 the network, .63 the broadcast, and .1-.62 usable; the next subnet starts at .64. Reading this correctly lets you size a scan range and spot when a client’s “one subnet” is really several.

1.4

How data actually moves - the layered model, with one packet’s journey

Networking is layered so each layer solves one problem. Five ideas matter to a tester (a frame is the parcel on the local wire, a packet is it once it is being routed between networks):

A worked example - you type a hostname and press enter

1. DNS (L7) turns intranet.corp.local into 10.20.4.15.
2. Routing (L3) decides on-segment or across a router, and the next hop.
3. ARP (L2) finds the MAC of that next hop for physical delivery.
4. TCP (L4) opens the connection with the three-way handshake: SYN → SYN-ACK → ACK.
5. TLS (L6) negotiates encryption and checks the server certificate.
6. HTTP (L7) finally carries the request and response.

Every scanning technique is a deliberate manipulation of one of these steps. A port scan is just sending the SYN to many ports and watching which answer SYN-ACK (open), which answer RST (closed), and which stay silent (filtered by a firewall).

1.5

The protocols an assessor meets constantly

A protocol is just an agreed language two machines use to do one job - asking for a web page, logging in, looking up a name. Each one below has a port (the numbered door it listens on) and a security angle. The words in that last column repeat all through this book, so learn them once here:

Kerberos vs NTLM recur throughout Part VII. Kerberos is modern Windows login: prove identity once to the domain controller, receive time-limited tickets; it needs correct DNS and the machine’s FQDN - an IP cannot be a Kerberos identity. NTLM is the older method still used with bare IPs and in workgroups; it is weaker and is the mechanism behind “relay” attacks, where an attacker who poisoned name resolution forwards a victim’s authentication to another server.

1.6

Segmentation and zones - the backbone of internal security

Segmentation is the most important structural control on an internal network. Divide it into zones (guest, corporate, servers, management, OT) and permit only the traffic the business needs. A well-segmented network means a compromised guest laptop cannot reach a domain controller. Zones are built with VLANs on switches and enforced with firewall/ACL rules. Testing segmentation is not a scan - it is deliberate reachability tests from a representative position in each source zone (§4.7).

1.7

IPv6, the DMZ, and modern architecture

IPv6 is the newer addressing scheme - 128-bit, written in hex (fe80::1c2b:…; hex just means counting with the digits 0-9 and a-f). Link-local addresses (ones only valid on the local wire) begin fe80::, and hosts auto-configure themselves via SLAAC (the IPv6 way of getting an address with no DHCP server). It matters to a tester for one blunt reason: most networks run dual-stack (IPv4 and IPv6 at once) but monitor and firewall only the IPv4 side, leaving IPv6 an unwatched parallel surface - the basis of the mitm6 attack (§4.3). Include or exclude IPv6 explicitly in the signed scope; never silently assume IPv4-only.

Three architecture words to hold: a DMZ (demilitarised zone) is a buffer segment for public-facing services (web, mail), isolated so a compromise there cannot reach the internal network. Defense-in-depth is layering controls so no single failure is fatal. Zero-trust is the modern stance that trust is never granted by network location - every request is authenticated and authorised regardless of origin - which raises the bar for segmentation and identity and is increasingly what a mature client is measured against.

2.1

Scan, assessment, penetration test, red team - the spectrum

These four words are not synonyms. They differ in human involvement, in whether weaknesses are exploited, and in the authorisation each needs.

The host assessment toolkit performs a credentialed vulnerability assessment - the middle of the spectrum, where accuracy is highest and authorisation lightest, because nothing is exploited. Exploitation is separately authorised and never the toolkit’s default.

2.2

The five domains of a network assessment, on one page

Everything the programme delivers - network, wireless, web/API, cloud and directory - is one discipline sliced three ways: by vantage (external / internal), by technique family (NIST §3 review / §4 analysis / §5 validation), and by domain. Wireless is its own domain (NIST §4.4), a peer of the others, not a sub-task.

2.3

The standards landscape

Professional testing follows published methodologies so results are comparable and defensible. Two axes must never be confused: methodologies describe how you tested (800-115, PTES, WSTG); control catalogues describe what a finding violates (800-53, ISO 27001, CIS).

Where each applies - matching the standard to the situation

2.4

The engagement lifecycle

1. Pre-engagement

   Scope, authorised CIDRs, no-scan assets, timing windows, rules of engagement, emergency-stop contact, evidence handling. Nothing starts until signed.

2. Intelligence gathering

   Passive/open-source collection about the target without touching it aggressively.

3. Discovery

   Find live hosts within authorised ranges. §4.1

4. Enumeration

   Identify open ports, services, versions, OS. §4.2

5. Vulnerability identification

   Match to known weaknesses by uncredentialed scan, credentialed scan, or config review. §3.4 + §4.3 assessment stops here

6. Exploitation / validation

   Prove selected weaknesses under authorisation, show impact. §5 separately authorised

7. Reporting

   Turn validated evidence into a control-mapped, defensible deliverable.

2.5

Authorisation and scope - the spine that must never bend

• Exact architecture before production - sites, authorised CIDRs, VLANs/zones, routing/firewalls, AD, management/security platforms, intended segmentation, critical/no-scan assets, evidence handling, emergency stop.
• Stay inside authorised ranges. Discovering more surface is a finding to report, never authorisation to scan it.
• Unknown assets are not auto-escalated - recorded Discovered-Unmapped, not subjected to deep testing.
• Fragile assets get a safe profile - printers, medical and OT devices get passive/config-only or an owner-approved window.
• Credentials are scoped and vaulted - temporary identities, validated on a pilot, never Domain Admin for convenience, stop on repeated auth failures (lockout).
• Evidence is client-confidential from collection - encrypted storage/transfer, explicit retention and destruction.

2.6

Test types, threat modeling, and the human layer

Before a technique is chosen, the knowledge model is agreed - it changes coverage and cost.

Threat modeling (PTES phase 3) precedes the technical work: identify the assets that matter, the plausible threat agents, and the attack surface, then prioritise testing by business impact rather than testing everything equally. A crown-jewel database earns more effort than a marketing page.

3.1

The testing environment - cloud preferred, testing machine as fallback

We operate one testing environment, keep it ready, and point it at authorised targets. External work reaches the client over the internet; internal work connects through the client VPN to a jump-box inside their network.

Cloud environment (preferred)

A small always-on cloud environment holds two VMs behind one public IP: a Kali Linux VM (primary scanning and tooling) and a Windows VM (Windows/AD work and any tool that runs best on Windows). One shared public IP gives the client a single address to whitelist and us one clean source. Because it is always on, scheduled scans run on a timer with no manual start. It is built once and reused for every client (starting cost ~US$25/month).

Fallback from an testing machine

If the cloud is not approved or not yet ready, the same work runs from a testing Kali machine: external work scans from the machine; internal work connects through the client VPN, or logs into the client jump-box and runs the tools there. This works, but the machine must stay on for scheduled scans and the build-once benefit is lost.

3.2

How external testing connects

Our environment and the client’s external systems are both public, so traffic goes straight over the internet from our address to theirs. We give the client our source IP first so their team allows it instead of blocking an unknown source. External targets are the internet-facing systems: web, mail, DNS and remote-access (VPN) gateways.

3.3

How internal testing connects - VPN and jump-box

Internal systems use private addresses (10.x / 192.168.x) the internet cannot reach. The client provides VPN access, building an encrypted tunnel across the internet so both ends behave as one local network: our environment receives a private address inside the client range and routes to internal systems through the tunnel, which the client gateway decrypts on the far side. Routed scanning runs over the VPN.

Work that must sit on the same local segment - Apple and media discovery (mDNS / Bonjour) and certain Layer-2 techniques - runs from a jump-box inside the client network. A jump-box (bastion) is a single hardened host we route through, giving controlled, logged in-network presence; evidence is pulled back to our side and the report is produced there. On a client jump-box, all tools are removed at close or the VM is reverted. “VPN monitoring” means logging our own testing traffic so it can never be mistaken for a real attack and so we hold an audit trail.

3.4

Cloud region and source IP

• US client - host in a US or EU region so the source IP is readily accepted.
• Data-residency requirement - use a Pakistan region only when data must stay in-country.
• Always - avoid regions with weak data-protection rules. Same environment, region chosen per engagement.

3.5

Scheduled scanning and the wrapper scripts

A small script set wraps the tools into a repeatable run. Each reads one config file and writes structured output, so runs are consistent and re-runnable on a schedule:

Scheduled scanning runs on a timer (cron) on the always-on environment, scheduled inside the agreed testing windows and kept out of client blackout windows. Internal scheduled scans route through the VPN; external ones run directly. This is how recurring scanning is delivered without manual effort, adding a regular change summary between formal test windows.

3.6

Platform security and data handling

The environment holds client scan data and credentials, so it is locked down: key-only access, host firewall on, encrypted storage, activity logging, and each client’s data kept separate. Credentials are removed at the end of every engagement. We hold our own platform to the standard we recommend to clients - the same discipline as the evidence contract in Part VII: raw evidence encrypted in transit and at rest, explicit retention and destruction.

3.7

Advantages of this architecture

3.8

The delivery programme - the actual plan

Everything elsewhere in this handbook is the generic field - how network assessment is done anywhere. This section is the specific plan: what we actually deliver, and where our method differs from the textbook. Read the rest as knowledge; read this as the operating model.

What we deliver - five service lines, one platform

Our method vs the field - where we are different

The field runs scans and writes them up. We add three things that make the work defensible and cheap to run:

• Evidence integrity. On the host plane, collection and judgement are separate programs and every artifact is sealed at collection - so a finding traces to a control and a tamper-evident file, and the operator cannot influence the verdict (§8.2). Most scanners cannot claim this.
• Off-host patch truth, for free. Windows patch state is derived from the exact build+UBR against Microsoft’s free MSRC feed and CISA KEV - no Windows scanner purchase required (§7.7).
• One always-on platform, credentialed two-pass, senior-validated. One environment serves every service line (§4); every engagement runs unauthenticated then authenticated (§4.1); every important finding is confirmed by a senior before it ships (§10.1).

3.9

Engagement types & network types

“Network penetration test” is not one thing. The network’s shape and the engagement’s type decide the vantage, the tools and the method. First, the three network shapes you will meet:

And the engagement types, each with its vantage, tools and this method:

4.1

The two-pass methodology

Every network engagement runs in two passes. The first models the outside attacker with no credentials; the second logs in with read-only credentials and reads the truth. The authenticated pass finds materially more real issues - commonly several times as many - so credentials are requested early.

4.2

External methodology, end to end

The external assessment models a stranger on the internet. The goal is to enumerate the exposed surface completely and identify its weaknesses.

Phase A - Passive OSINT (no aggressive contact)

• DNS footprint - whois, dig, DNSDumpster, dnsrecon. Records: A/AAAA, MX, NS, TXT (SPF/DMARC/DKIM leak infra), CNAME (SaaS → subdomain-takeover candidates).
• Subdomain enumeration - passive (amass -passive, subfinder, crt.sh, SecurityTrails) and active (amass -active, puredns, ffuf vhost).
• Certificate Transparency - crt.sh, certspotter reveal subdomains issued certs, including staging/dev names accidentally certed.
• Internet-scan datasets - Shodan / Censys by org, ASN, cert or favicon hash; reveals exposed services and shadow IT.
• ASN / netblock discovery - whois → org → asnmap / bgp.he.net maps the full owned surface.
• Leak & content OSINT - theHarvester (username format), waybackurls/gau (old endpoints), trufflehog/gitleaks (exposed secrets, .git, buckets).

Phase B-D - Discovery, enumeration, identification

Bounded to authorised ranges: nmap -sn / masscan / fping for liveness (external hosts often drop ICMP, so “no ping” ≠ down), then masscan for breadth and nmap -sV for accuracy, then TLS (testssl.sh), tech-detection (httpx, whatweb), and any web app handed to Part VI. Common external findings: weak/expired TLS, exposed management interfaces (RDP, SSH, DB, Jenkins, iLO/iDRAC, Citrix/Fortinet/Pulse VPNs), missing patches on internet-facing services, subdomain takeover, information disclosure (.git/.env/backups, stack traces), email-security gaps (SPF/DMARC), open SNMP/resolvers.

4.3

Internal methodology and the Active Directory attack primitives

The internal assessment models an attacker already inside, or assesses the estate from a management position. Positioning matters - a drop on a flat user VLAN sees far more than one in a segmented DMZ; record the source VLAN, it defines what “reachable” means. On-subnet discovery uses ARP (arp-scan, nmap -sn which auto-uses ARP on-subnet), which is authoritative and cannot be firewalled at Layer 2.

An assessor must understand the classic techniques even where the engagement only identifies the exposure - because the host toolkit’s checks exist to find the conditions that enable them. Format: what it is · what enables it · what the defender checks.

Naming these to a client - “this LLMNR setting is what enables credential relay on your network” - is the difference between reporting a checkbox and explaining a risk. Enumeration tooling: netexec/enum4linux-ng (shares, sessions, users, policy), certipy (ADCS ESC1-ESC16), BloodHound to map who can reach tier-0.

4.4

Nmap in depth

Timing -T0--T5 (paranoid→insane); -T3 default, -T4 typical internal. -T5 externally drops probes and causes false negatives. NSE categories: use safe/default/discovery/version in a VA scope; avoid brute, dos, exploit, intrusive unless the ROE permits - dos can crash services.

# 1. Fast internal host discovery (ARP on-subnet), no port scan
nmap -sn 10.10.10.0/24
# 2. Thorough TCP: all ports, version + default scripts, save all formats
nmap -sS -p- -sV -sC -T4 -oA scans/internal_full 10.10.10.5
#   -p- all 65535 ports   -oA writes .nmap/.gnmap/.xml for re-parsing
# 3. Targeted UDP on high-value services (never all UDP - too slow)
nmap -sU -p 53,69,123,161,500 --open -T4 10.10.10.5
# 4. SMB-signing posture (relay exposure) via NSE
nmap -p 445 --script smb2-security-mode 10.10.10.0/24

Junior errors: forgetting -p- and missing a service on 8443/9000; not saving -oA (no re-parseable evidence); trusting an OS guess made through a filter.

4.5

The tool catalogue - open-source vs commercial

* Directory attack-path analysis (BloodHound) is a future workstream; the toolkit collects directory configuration only (§7.8). Junior errors: calling netexec enumeration “exploitation” (its module runner is, its enum is not); Hydra brute in AD triggers lockouts - prefer kerbrute enum + policy-aware spray.

4.6

Scoring and prioritisation - CVSS, EPSS, KEV, CWE

The CVSS vector, not just the number, must be read and the score computed mechanically (Roundup, not ordinary rounding). v3.1 base metrics: AV (Network/Adjacent/Local/Physical), AC (external prerequisites, not exploit difficulty), PR (None/Low/High), UI, Scope (Changed only when a different security authority is impacted - the most-misused metric), and C/I/A impacts. So AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = an unauthenticated remote attacker, no interaction, full impact → 9.8 Critical. Fix-first stack: in KEV → immediate; else high EPSS + high CVSS → next; else high CVSS/low EPSS → schedule; cluster fixes by CWE. Severity ≠ risk ≠ likelihood (EPSS) ≠ confirmed exploitation (KEV) - keep the four distinct.

4.7

Segmentation testing - the reachability matrix

The goal is to prove whether traffic from zone A can reach zone B from a source position representative of a real host in zone A. Build an N×N matrix (source zone → destination zone), each cell recording which ports/protocols are reachable vs blocked; the matrix maps to the intended policy (e.g. PCI: CDE isolated from non-CDE). Test with nmap -sS -Pn -p <policy ports> (use -Pn because you are testing the firewall, not host liveness) plus -sU and ICMP as the policy requires; hping3 confirms a single rule.

4.8

The configuration and passive evidence planes

Not every fact is best learned by active scanning. Network-configuration analysis: where a client will not grant interactive switch/firewall access, they export device configs and Batfish models routing/ACL/firewall reachability across Cisco, Palo Alto and other platforms - modelled/static evidence, correlated with live tests. Passive evidence (preferred order): existing firewall/session logs → DNS/DHCP and flow (NetFlow/IPFIX) → SIEM/NDR/EDR → client PCAP or a SPAN/TAP sensor only when justified; Zeek parses traffic at an authorised point into structured connection/DNS/Kerberos/LDAP logs. A sensor sees only what is visible at its position (absence ≠ blocked), and structured metadata is always preferred over raw payload capture on sensitive networks.

4.9

Media and Apple environments

Media-heavy and Apple-based environments (common in content clients) need extra care. Device discovery relies on mDNS / Bonjour, which is link-local - it does not cross routing boundaries, so that discovery must run from the same local segment (the jump-box), not over the routed VPN. Content networks also carry sensitive material, so structured metadata is preferred over payload capture and content-protection guidelines apply to evidence handling.

4.10

Service enumeration cheat-sheet

Once a port is open, each service is enumerated for what it leaks before any credential attack. All of the below is identification (safe in a VA scope); spraying/brute is not.

A null session (unauthenticated SMB/LDAP that still returns data), an anonymous LDAP bind, and a default SNMP community are themselves findings - they leak the target’s structure to any unauthenticated attacker.

4.11

Pivoting, tunnelling & password attacks

Reaching deeper - pivoting and tunnelling

Internal networks are segmented, so a position in one zone often cannot route to another directly. Pivoting uses an authorised foothold or the jump-box as a relay to reach otherwise-unreachable segments. The common mechanisms: an SSH dynamic tunnel (ssh -D) fronted by proxychains, or purpose-built tunnellers (chisel, ligolo-ng, sshuttle). In an assessment scope this is legitimate reach through the client-approved jump-box, correlated with the segmentation matrix (§4.7) - not exploitation; it is also how a probe in one zone is made to test from a representative position in another.

Password attacks - three kinds, and the lockout rule

Always establish the account-lockout policy first. Enumerate usernames with kerbrute (no lockout on enumeration), then spray low-and-slow within the threshold and reset window. A careless spray locks out a client’s staff - a real operational incident. Default and vendor credentials on exposed devices are identified as a matter of course.

5.1

802.11 fundamentals

Bands & channels: 2.4 GHz (only channels 1/6/11 non-overlapping; congested), 5 GHz (many channels, some DFS that must yield to radar), 6 GHz (Wi-Fi 6E/7; mandates WPA3/OWE, uses out-of-band discovery, and monitor/injection support is still immature). A 2.4-GHz-only survey misses most modern corporate infrastructure.

SSID vs BSSID: the SSID is the network name (not unique, can be hidden but leaks in probes - hiding is not security); the BSSID is a specific AP radio’s MAC. You attack a BSSID, you enumerate by SSID. Frame classes: management (beacons, probes, auth/assoc, deauth), control, data. Management frames were historically unauthenticated - the root of deauth and evil-twin attacks; 802.11w (Protected Management Frames) authenticates them and is mandatory in WPA3 and 6 GHz, defeating classic deauth. Beacons (~10/sec) carry the RSN Information Element - the cipher/AKM/PMF posture you fingerprint passively. Probe requests can leak a device’s saved-network list (the basis of KARMA/known-beacon).

5.2

The handshake, PMKID, and the encryption generations

The 4-way handshake (WPA/WPA2) derives fresh session keys after association without transmitting the password: both sides already share the PMK (from PSK+SSID via PBKDF2, or from the enterprise EAP exchange). Capturing it gives an offline oracle - you recompute the key for each password guess and check the MIC. It does not reveal the password or decrypt traffic; success is entirely a function of password entropy. Messages 1+2 (or 2 of 4) with matching replay counters are typically enough - mixing frames from different handshakes yields an uncrackable capture, so verify on-site. PMKID is an optional value some APs volunteer in EAPOL message 1: HMAC-SHA1(PMK, …) - you associate yourself, read it, and crack offline with no connected client and no deauth. Not all APs include it, so both techniques stay in the kit.

5.3

The three layers of a wireless assessment

5.4

Wireless attacks and checks

1. Reconnaissance / survey (passive)

   Monitor-mode capture across all bands: BSSIDs, SSIDs (incl. hidden), channels, encryption/AKM/PMF from the RSN IE, connected clients. Non-disruptive; do it first and log neighbour (out-of-scope) networks explicitly since RF crosses property lines.

2. Deauthentication

   Spoofed deauth forces a client to reconnect so the handshake can be captured - active, disruptive, a DoS; targeted single-client preferred. Defeated by 802.11w/PMF - then pivot to PMKID or wait for a natural join. You do not always need a deauth.

3. Handshake / PMKID capture

   Lock airodump to the channel/BSSID and confirm “WPA handshake”; or use hcxdumptool for a client-free PMKID. Verify the capture is crackable on-site.

4. Offline cracking

   Dictionary + rules + mask in hashcat (mode 22000; 16800/2500 are legacy) or aircrack-ng. The finding is “weak PSK.”

5. WPS / Pixie-Dust

   The 8-digit WPS PIN collapses to ~11,000 guesses; Pixie-Dust recovers it offline in seconds from weak nonces, then the AP hands over the PSK regardless of its strength. Always check WPS is disabled - it bypasses “use a strong password” entirely.

6. Evil twin / KARMA / captive portal

   Clone the SSID on a stronger signal (hostapd-mana/eaphammer/wifiphisher) for credential capture (personal), rogue RADIUS (enterprise), or captive-portal PSK phishing. KARMA/known-beacon/MANA exploit saved-network probing.

7. Segmentation test (no RF)

   Join the guest SSID legitimately and test whether corporate/internal ranges, management interfaces or other clients are reachable - client isolation, DNS/DHCP leakage, lateral routes. Needs only network access; often the highest-severity finding (“guest Wi-Fi routes to the production LAN”).

5.5

The wireless toolkit and the adapter

The adapter: wireless work needs monitor mode (hear all raw frames, not just your own network) and packet injection (transmit crafted frames). These depend on the chipset + driver, not the brand - “Alfa” is a vendor, not a guarantee; verify with aireplay-ng --test. Known-good: Atheros AR9271 (2.4 GHz only, rock-solid; note TP-Link TL-WN722N v1 only - v2/v3 changed chip and lost injection), MediaTek MT7612U (dual-band, mainline mt76 driver - the recommended modern choice), Realtek RTL8812AU (dual-band, out-of-tree driver). A 2.4-GHz-only card silently misses the 5/6 GHz estate; 6 GHz monitor/injection support is still poor.

# WPA2-PSK handshake capture + crack (authorized)
airmon-ng check kill; airmon-ng start wlan0
airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w capture wlan0mon
aireplay-ng --deauth 5 -a AA:BB:CC:DD:EE:FF -c <CLIENT> wlan0mon   # force reconnect
hcxpcapngtool -o hash.22000 capture.cap
hashcat -m 22000 hash.22000 wordlist.txt -r rules/best64.rule

5.6

Standards and the remote limit

Wireless anchors to NIST SP 800-115 §4.4 (passive scanning for rogue/AP enumeration and encryption posture; active scanning against discovered devices; wireless device location). 800-115 (2008) predates WPA3/6 GHz/PMF, so pair it with NIST SP 800-153 (WLAN hardening), the Wi-Fi Alliance specs (WPA3/OWE/PMF), and - for cardholder environments - PCI DSS Req 11 (quarterly rogue-AP scanning). Frame the work as survey → posture from the RSN IE → targeted validation → impact via segmentation → report, with the standing rule that the finding is almost always a configuration or password-entropy weakness (weak PSK, WPS enabled, PMF off, no server-cert validation, flat guest VLAN), not “the encryption is broken.”

5.7

Beyond Wi-Fi - Bluetooth, BLE and rogue devices

The wireless domain extends past 802.11. NIST SP 800-115 §4.4 explicitly includes Bluetooth / BLE, assessed with bluetoothctl, Ubertooth and btlejack for discovery, pairing security and sniffing; mature programmes also consider Zigbee and other RF, and rogue-device detection - unauthorised APs, beacons and drop-boxes on or near the estate (a PCI DSS requirement in cardholder environments). The same hard rule holds: RF is local, so this is on-site work requiring the right radio within range.

6.1

Web application testing

Human-driven analysis of an application’s logic, following the OWASP WSTG (the methodology) - not a scan. The OWASP Top 10 (2021) is an awareness/reporting list, not a coverage standard: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection (incl. XSS), A04 Insecure Design, A05 Security Misconfiguration (incl. XXE), A06 Vulnerable Components, A07 Auth Failures, A08 Software/Data Integrity, A09 Logging/Monitoring Failures, A10 SSRF. WSTG phases run information-gathering → config → identity → authentication → authorization → session → input validation → errors → crypto → business logic → client-side.

The Burp Suite Professional workflow

Proxy (MITM backbone) → Target/site map (scope tightly to the ROE) → Repeater (manual single-request tampering - where IDOR/BOLA, authz and injection are confirmed by hand) → Intruder (parameterised fuzzing: Sniper/Battering-ram/Pitchfork/Cluster-bomb) → Scanner (crawl-and-audit). curl captures clean copy-pasteable PoCs; Python handles multi-step logic. The high-value triad is authentication (enumeration, MFA bypass, reset-token strength), session (cookie flags, fixation, token entropy via Sequencer), and access control (a role matrix with ≥2 accounts per role; the cleanest PoC is “same request, victim’s object ID, attacker’s session → 200 + victim’s data”).

6.2

API testing

The OWASP API Security Top 10 (2023) is dominated by authorization: API1 BOLA (swap an object ID, get another tenant’s object - the #1 API risk), API2 Broken Authentication, API3 Broken Object Property Level Authorization (excessive data / mass assignment, e.g. injecting "role":"admin"), API4 Unrestricted Resource Consumption, API5 BFLA (reach a function above your role), API6 Sensitive Business Flows, API7 SSRF, API8 Misconfiguration, API9 Improper Inventory (shadow/zombie APIs), API10 Unsafe Consumption.

Authorization dominates because APIs expose object identifiers directly and are consumed by clients the server can’t trust - every object reference is an authz decision the server must re-make on every call, and UI restrictions mean nothing. With RBAC via token claims (roles in a JWT), three test classes define the engagement: BOLA/BFLA per role/endpoint/verb; cross-role/cross-tenant (an N×endpoints matrix; a 7-role engagement is combinatorially authz-heavy); and JWT tampering (alg:none, RS256→HS256 confusion, unverified signature, edited role/tenant claims, stripped exp). Tools: Burp (Repeater, Intruder to sweep IDs, Authorize extension to diff a low-priv vs high-priv session, JWT Editor), Postman (import OpenAPI to build the inventory and per-role token environments), Python (drive the full matrix), curl (PoC). Postman/Swagger give the inventory; the authorization verdict is always manual replay - and always test API9 for endpoints the spec omits.

6.3

Cloud assessment

Cloud is predominantly a credentialed configuration and identity review, not remote exploitation: usually authenticated read-only tenant access, almost entirely via provider APIs, governed by the provider’s rules of engagement. Findings are public storage buckets, over-permissive IAM (*:*), missing MFA on privileged/root accounts, unencrypted storage, exposed management ports in security groups/NSGs, disabled logging (CloudTrail/Activity Log), stale credentials, conditional-access gaps.

What the customer owns - and therefore what we assess - depends on the service model. This is the shared-responsibility split:

6.4

Mobile, containers & the wider surface

• Mobile applications - a separate workstream under OWASP MASVS / MASTG: static analysis (insecure storage, hardcoded secrets, weak crypto), dynamic analysis (certificate pinning, runtime), and the API backend - which is the API testing of §6.2. The client app is fully attacker-controlled, so the server remains the enforcement boundary.
• Containers & Kubernetes - a config-review discipline against the CIS Kubernetes Benchmark: exposed dashboards/kubelet, over-broad RBAC, privileged pods, image vulnerabilities (kube-bench, kube-hunter, Trivy). Cloud-adjacent, mostly identity and configuration.
• OT / ICS / SCADA - industrial control systems are passive-only: active probing can disrupt physical processes, so these are assessed by configuration review and passive observation under a strict safe profile, never active scanning on production.

7.1

Product shape - one workflow, several planes

The toolkit is software implemented as scripts and modules, not a single script. Its architecture decision is deliberate: one topology-aware, evidence-first internal assessment toolkit - not one giant vulnerability script, and not a permanent endpoint agent as the default.

7.2

Design philosophy - why it is defensible

The value over a black-box scanner is not more checks; it is evidence integrity, produced by three principles.

Collect and judge are separate programs (the operator cannot influence the verdict); evidence is sealed at collection (a tampered file makes the analyzer refuse); credentialed, from the inside (reads the exact registry value and build - the most accurate position, almost no false positives). Every result carries the four fields: the control tested, the evidence and its hash, the method used, the outcome - so any finding traces back to a control and a tamper-evident artifact.

7.3

The collector and its transport

1. Transport: WinRM (WS-Management)

   Built-in Windows remote management (5985 plain / 5986 TLS), the channel PowerShell Remoting uses. Nothing new is enabled on the client; WinRM/firewall are never auto-enabled to get in.

2. Authentication: Kerberos (domain) / validated HTTPS (workgroup)

   Domain: DNS/FQDN + Kerberos - never an IP literal as a Kerberos identity. Workgroup: validated HTTPS with the real certificate and explicit credentials - never wildcard TrustedHosts or disabled cert validation.

3. Execution: the script text runs in the remote session

   The collector’s text is sent down the session and executed in memory (Invoke-Command -FilePath). No file copied, no service installed, no agent left; evidence returns through the same session - sidestepping the second-hop delegation problem.

4. Invocation: non-interactive

   In production, started by Configuration Manager, Intune, RMM (remote monitoring and management), Group Policy or a scheduled task (-NonInteractive -File) - never a human console. Two defects were found that appear only under non-interactive invocation, which is why it is tested that exact way.

Collection profiles bound what is gathered: Minimal (identity + selected controls/listeners), Standard (+ bounded service/software/update inventory), Deep (+ targeted hardening/role evidence). Collection must be justified by an objective and constrained by per-host size budgets.

7.4

The 45 evidence sources

Grouped with what each reveals. Each records a status and a plain caveat; only whether an auto-logon password exists is recorded - never the value.

Identity, inventory & build

Exposure - listeners, connections, accounts

Security configuration (the rule surface)

Active Directory (domain-joined only)

Wireless configuration (host side, see Part V)

The six directory sources read through libraries on every Windows host - no RSAT, no ActiveDirectory module. On a workgroup host all six record Not Applicable. The three domain-level sources (policy, privileged groups, Kerberos policy) are read once from the domain controller; a member host collected through a remote session records them as Not Applicable with the reason, because a remote session cannot bind the directory on the host's behalf (the credential second hop).

7.5

Evidence integrity and result semantics

Four evidence layers, strictly bounded: Raw (change-evident once hashed), Derived (regenerable Evidence.json/Tests.csv/Coverage.csv), Manual (verification + notes, each hashed), Report (only after validation). Sealing: every raw file is SHA-256-hashed at collection; the analyzer re-hashes - match proceeds, mismatch stops with zero results. Raw evidence is never edited; a correction is a new run.

The coverage denominator comes from the approved inventory, not only hosts that returned evidence - so “zero findings” can never hide missing assets - and a CVE is never inferred from a missing KB, a port, or an unverified banner.

7.6

The analyzer and the 45 configuration rules

45 rules across nine categories. It is a lab reference profile, explicitly not a certification: a Fail is a configuration observation requiring analyst review against the client’s approved baseline before it becomes a finding. Severity is never assigned by the rule set.

Rule anatomy - a worked example

// CRED02 - LSA runs as a protected process
source: "lsa"   field: "RunAsPPL"
type:   "int_any"   expected: [1, 2]      // 1 and 2 both enable protection
absent_means: { result: "Fail" }         // no value → LSASS exposed
control_refs: [ SC-39 Process Isolation, IA-5 Authenticator Mgmt ]

Comparisons go beyond equality - an accepted set (int_any) and numeric_max/min/between - because LSA protection 2 is as valid as 1, and a lockout threshold of 0 disables lockout (weaker than any positive value, so PWD02 declares the range 1-5). absent_means interprets a missing value only when the rule states what its absence means: CRED01 (WDigest) is version-dependent, so an absent value reports Unknown with the dependency stated, not a false Pass. Every rule carries its 800-53 control references - the first of the four fields.

7.7

Patch determination - finding real vulnerabilities without a Windows scanner

1. Record the exact servicing level

   Build + update revision (UBR) together, e.g. 10.0.26200.9457, read from HKLM\…\CurrentVersion - the unambiguous patch state.

2. Compare against Microsoft’s free feed

   The MSRC CVRF data publishes, per CVE, the fixed build per product - free, no API key. Build lower than the fix → the vulnerability is present. An unidentifiable product is Unknown, never patched.

3. Report with the vendor’s severity, overlay CISA KEV

   Each item carries Microsoft’s CVSS vector and the update required; KEV marks which are exploited now → “fix these first.”

Performed off-host against vendor data - a §4.3 assessment, never an exploit. A validation lesson: a three-month window hid 15 of 16 exploited CVEs a twelve-month window found, so the default is twelve months with a truncation warning.

7.8

Active Directory evidence

On a domain-joined host, the six directory sources populate automatically - no separate script, they switch on by themselves, reading through libraries present on every Windows host (no RSAT). One check to teach specifically: MachineAccountQuota - an AD default of 10 lets any authenticated user join ten computers to the domain, a known attack primitive.

7.9

Deployment, evidence return, and scale

One evidence model, several execution adapters tried in order - a pre-engagement decision, not a script’s guess.

Evidence return is designed separately from execution. A console status channel is often too small - ConfigMgr Run Scripts output truncates at 4 KB, Intune scripts have a 30-minute limit - so full evidence is staged and collected separately while the console carries compact status. The package never creates a share or service account on its own. Scale: the lab harness is a 1-20 sequential runner, not the 1,000-endpoint scheduler; use the client’s fleet management first, or an optional temporary ansible-core controller over WinRM/PSRP; prove scale only with a representative pilot (runtime, evidence size, endpoint load, auth-failure behaviour), never a synthetic 1,000-row plan. Failure modes are named and answered by an alternate adapter - never by weakening a control (blocked WinRM is not auto-enabled; WDAC blocking the toolkit is recorded and worked with, never evaded).

7.10

The findings register and the GRC layer

A findings register is drafted from the rule results and the outstanding-update result: outstanding updates collapse into one finding per host; an undeterminable patch state is a coverage gap, never silently dropped; judgement fields are explicit analyst-required markers; and no proof-of-concept text is generated (a PoC is only transcribed from a real capture). Baseline + overlay: map checks once to the neutral NIST SP 800-53 baseline, then apply a per-engagement overlay re-labelling them to the client’s regime (PCI/ISO/SOC 2/HIPAA) - test once, map many. Non-public framework IDs are transcribed by an assessor, never guessed.

7.11

Capability and maturity

The toolkit is a complete pipeline: it collects 45 sealed evidence sources from a Windows host, evaluates 45 control-mapped configuration rules, determines outstanding Microsoft patches off-host against the free MSRC feed with CISA-KEV prioritisation, and drafts a findings register - all under the collect-vs-judge integrity model. The host side has now been validated end to end in a six-machine virtual lab; what remains is field coverage for the planes that need equipment or a real client environment. A defensible programme states both plainly.

The lab exposed fourteen defects, every one caught by the evidence rather than by a client: two under non-interactive invocation (script-relative defaults in param(); strict-mode failure when the network block is absent), the patch engine's product matching and release ordering, an empty build number on older servers, directory reads through a remote session, an empty privileged-group list, wireless wrongly reported present on servers, a segmentation result that could only ever be inconclusive, and a local account policy that could only be read in English. All are fixed and covered by tests. It is an internal R&D build; production sign-off follows the gates in §7.12. The Windows capability is proven end to end in the lab; the remaining items need equipment or a client environment, not code.

7.12

Production and licensing gates

• Code trust. Signed and hash-pinned, integrated with client App Control/WDAC. Execution policy is not a security boundary; Bypass, wildcard TrustedHosts and disabling app control are never prerequisites.
• Evidence. Win32_Product prohibited for routine inventory; hotfix list is inventory only; third-party CVE applicability comes from a maintained engine, never a home-grown match.
• Lifecycle. Exact edition/build/LTSC/ESU/support recorded; a generic “Windows 10” label is insufficient; lifecycle is distinct from patch status.
• Licensing. Microsoft baselines are the default free reference; CIS content needs SecureSuite; OpenSCAP is not a Windows candidate; the Greenbone Community Feed carries no completeness warranty (record edition/date); Nmap redistribution in a proprietary product needs a licensing decision.
• Confidentiality. Client-approved encrypted storage/transfer, explicit retention and destruction; hashes prove later change, not original truthfulness.

8.1

Methodology and senior validation

Two passes (unauthenticated then authenticated, §4.1); segmentation recorded as a reachability matrix (§4.7); configuration reviewed for open rules, exposed management, missing logging, weak settings and unsupported firmware. Senior validation is a fixed step: every important finding is confirmed by a senior team member before it enters the report - the tool flags, the person decides. Work follows PTES and NIST SP 800-115; findings are scored with CVSS (from the vector, mechanically).

8.2

Deliverables, scheduled scanning and retest

The deliverable is a report with an executive summary for management and detailed findings for the technical team - each with affected systems, risk, evidence, and a prioritised fix. Scheduled scanning adds a regular change summary between formal windows. A retest is offered after fixes are applied - and a finding is only marked Fixed on direct retest evidence, never on correspondence, an implementation statement, an inaccessible endpoint, or a risk acceptance.

8.3

What we need from the client before we start

Nothing is scanned until these are in place:

• Signed authorisation naming the exact systems in scope.
• In-scope asset list: domains/IPs for external, internal ranges for internal.
• Agreed testing window and any blackout periods.
• For internal work, VPN access and jump-box details.
• Read-only credentials for the authenticated pass, where in scope.
• Configuration exports if firewall/system/endpoint review is included.
• A notification destination and an emergency contact who can stop the work at any time.

8.4

Compliance mapping - one baseline, many client views

Findings and control coverage map once to NIST SP 800-53 Rev 5 (the richest superset, with published crosswalks), then overlay each client’s framework rather than re-mapping from scratch: 800-53 → SOC 2 TSC, 800-53 → ISO 27001 Annex A, 800-53 → CSF function; PCI DSS requirement numbers where a cardholder environment is in scope; GDPR Art. 32 where EU personal data is exposed; content-protection guidelines for media environments. Emit coverage in an OSCAL-compatible shape so the mapping is reusable. Crosswalks are approximate - a mapping is “related,” rarely 1:1 - so edge cases are reviewed, not trusted blindly.

8.5

Writing a finding

A finding is only as good as its write-up. Each carries the same anatomy, and each element has a rule behind it learned the hard way.

8.6

Pre-engagement operational checklist

Nothing is scanned until every box is ticked - the go/no-go gate before the first packet.

9.1

External web + API - a multi-role SaaS portal

9.2

Internal network + AD - a corporate HQ

9.3

Segmentation validation - a cardholder (PCI) environment

9.4

Cloud posture - an Azure / Entra tenant

9.5

Wireless - a branch office

10.1

Ports and protocols

10.2

Tool matrix - open-source vs commercial

10.3

Standards crosswalk

10.4

Glossary

Switch / Router

Connects devices within one network (L2, by MAC) / connects different networks (L3, by IP). segmentation vs reachability

VLAN / zone

A logical division separating traffic; the basis of segmentation. guest vs corporate

MAC / IP · CIDR · NAT

Local vs routable address; range notation (/24); many private hosts sharing one public address. IP ≠ identity

TCP 3-way handshake

SYN → SYN-ACK → ACK; port scanning manipulates it. open/closed/filtered

Jump-box / bastion

A single hardened host routed through for controlled, logged in-network presence. internal delivery

VPN tunnel

Encrypted path making two ends behave as one local network; how internal testing reaches private ranges. Part III

Two-pass method

Unauthenticated (attacker view) then authenticated (read-only creds, exact state). §4.1

NIST SP 800-115 / PTES

The technique guide (assessment vs exploitation line) / the seven-phase lifecycle. methodology

NIST 800-53 / CIS / ISO 27001

Control catalogue (baseline) / hardening settings / client audit regime. what a finding violates

CVE / CVSS / EPSS / KEV / CWE

Flaw ID / severity vector / exploit probability / exploited-now list / weakness class. scoring stack

Credentialed scan

Logs in and reads the truth rather than guessing; verify auth actually succeeded. accuracy

WinRM / Kerberos / NTLM

Windows remote mgmt (5985/6) / domain ticket auth (needs FQDN) / older relay-prone auth. Windows plumbing

SMB signing

Session integrity; required (not merely enabled) blocks relay. SMB02/03

LLMNR / NBT-NS · Responder

Legacy name fallbacks, poisonable to capture credentials. NET01/02

Kerberoasting / AS-REP / PtH / DCSync

Offline-crack SPN tickets / pre-auth-disabled accounts / auth with a hash / replicate secrets from a DC. AD primitives

LSA / WDigest / LAPS / Credential Guard

Credential store / cleartext-cache legacy protocol / per-host admin-password mgmt / VBS credential isolation. CRED rules

MachineAccountQuota

AD default letting any user join 10 machines. domainpolicy

Servicing level (UBR) / MSRC CVRF

Build+revision = exact patch state / Microsoft’s free per-CVE fixed-build feed. patch engine

SHA-256

One-way file fingerprint; the evidence seal. integrity

802.11 / SSID / BSSID / PMF

Wi-Fi standard / network name / AP-radio MAC / 802.11w protected management frames (defeats deauth). wireless basics

4-way handshake / PMKID

The PSK key exchange (an offline oracle) / a handshake-free value some APs volunteer. capture then crack

WPA2 / WPA3-SAE / 802.1X-EAP

Shared-key AES / current PAKE (no offline crack) / per-user enterprise (hinges on cert validation). encryption

WPS / Pixie-Dust

The PIN feature; recovers the PSK regardless of its strength - check it’s disabled. one-shot compromise

Monitor-mode adapter

Chipset+driver (not brand) that hears all frames and injects; RF work needs it, on-site. the field card

BOLA / BFLA

Reach another user’s object / a function above your role - the dominant API risks, manual to find. API Top 10

Shared responsibility

Provider secures the cloud; customer secures what’s in it - cloud assessment targets the customer’s half. §6.3

Baseline + overlay

Map once to 800-53, overlay each client’s framework via crosswalks. test once, map many

Batfish / Zeek

Model device configs (static) / parse traffic to structured logs (passive). quiet planes

Non-interactive

Started by a deployment tool, not a person - the path that matters, where subtle defects hide. how it runs

Black / grey / white-box

No prior knowledge / partial knowledge or creds / full knowledge. Grey-box is the usual choice. §2.6

Threat modeling

Prioritising testing by asset value and plausible threat before technical work. PTES phase 3

Phishing / social engineering

Testing the human layer; §5, separately authorised, never bolted onto a technical engagement. §2.6

IPv6 / SLAAC / dual-stack

128-bit addressing; auto-config; running v4+v6 at once leaves v6 an often-unmonitored surface. §1.7

DMZ / zero-trust

Isolated buffer for public services / never trust by network location - verify every request. architecture

Pivoting / tunnelling

Using a foothold or jump-box to reach otherwise-unroutable segments (proxychains, chisel, ligolo). §4.11

Password spraying

One common password against many accounts, slowly - evades lockout; know the policy first. §4.11

Null session / anonymous bind

Unauthenticated SMB/LDAP that still leaks structure - itself a finding. §4.10

SPN

“Service Principal Name” - the label that ties a service (like a database) to the account running it. Asking for its ticket and cracking it offline is Kerberoasting. AD service accounts

gMSA

A “group managed service account” - Windows generates and rotates a long random password for a service, so it can't be Kerberoasted. The fix for weak service passwords. remediation

EPA / channel binding · coercion · PetitPotam

Extra login checks that tie an authentication to the exact connection, defeating relay / an attacker forcing a server to log in to them (PetitPotam is one such trick). relay defence & abuse

golden / silver ticket · krbtgt · Pass-the-Ticket

Forged Kerberos tickets: a “golden” one (from the domain's master krbtgt key) impersonates anyone; a “silver” one targets a single service; Pass-the-Ticket reuses a stolen ticket. Total-compromise territory. domain dominance

ADCS / ESC1-ESC16 · certipy

Active Directory Certificate Services - the in-house system that issues login certificates. Misconfigured templates (the “ESC” issues) let a low user mint an admin certificate; certipy is the tool that finds them. privilege escalation

BloodHound / tier-0

A tool that maps “who can reach admin” as a graph. “Tier-0” means the crown-jewel systems (domain controllers) that must never be reachable from ordinary machines. attack-path mapping

mitm6 / DHCPv6 · RA Guard

An attack that answers a Windows machine's automatic IPv6 requests to become its DNS, then relays logins. The switch-level fix is RA Guard / DHCPv6 Guard - not disabling IPv6. the unwatched second stack

PBKDF2

The slow “stretching” maths that turns a Wi-Fi password into its key; WPA2 uses a weak 4,096 rounds with the network name as salt, which is why a strong passphrase matters. why WPA2 is crackable

RSN IE / AKM · hashcat 22000

The chunk of a Wi-Fi beacon that advertises its security (cipher and login method) - you read it passively. hashcat mode 22000 is the setting that cracks captured WPA handshakes/PMKIDs. wireless fingerprint & crack

802.1X-EAP / RADIUS · PEAP-MSCHAPv2 · EAP-TLS

Enterprise Wi-Fi where each user logs in to a central server (RADIUS). PEAP-MSCHAPv2 is crackable if the client doesn't check the server's certificate; EAP-TLS (certificates both ways) is the safe option. the enterprise trap

WPA3-SAE transition mode · Dragonblood (a WPA3-SAE flaw) · KRACK (a WPA2 handshake flaw)

WPA3's modern login (SAE); “transition mode” also accepts WPA2 and can be forced down to it. Dragonblood/KRACK are named implementation flaws (mostly patched), not password weaknesses. config exposure

JWT · alg:none · RS256→HS256

A signed login token an app trusts (JSON Web Token). Classic bugs: getting the app to accept an unsigned token (alg:none) or one signed with the public key it published (RS256→HS256 confusion). API auth

IDOR / SSRF / XXE

Reach another user's data by changing an ID (IDOR/BOLA) / make the server fetch a URL you choose (SSRF) / abuse XML parsing to read files (XXE). Common high-impact web bugs. OWASP

CORS

The browser rule for which other sites may read a response. Set too loosely, it lets a malicious site read a victim's data through their logged-in session. web misconfig

IMDSv1 / IMDSv2 · service principal · PIM / Conditional Access

The cloud metadata service a server queries for its own keys (v2 is the hardened form) / a non-human cloud identity for an app / just-in-time admin and login conditions in Azure. cloud identity

MASVS / MASTG

OWASP's mobile security standard and testing guide - the mobile equivalent of the web ASVS/WSTG. mobile

NetFlow / IPFIX · SPAN / TAP

Summaries of “who talked to whom” a network keeps (NetFlow) / ways to copy live traffic to a sensor (a switch SPAN port or a physical TAP). Passive evidence sources. §4.8

CIM / PSRP · second-hop

Windows management interfaces the collector can use (CIM/WMI, PowerShell Remoting). The “second-hop” problem is that a remote login can't automatically re-use its credentials to jump onward. collector transport

RID · PPL (RunAsPPL) · PrintNightmare

The numeric tail of a Windows account ID (survives a rename) / a protection that stops tools reading the credential store / a print-spooler flaw class fixed by restricting driver installs. host rules

WDAC / AppLocker · code-signing certificate · OSCAL / POA&M

Windows controls that only allow approved programs to run (our tool needs a signing certificate to pass them) / a machine-readable format for controls and a “plan of action & milestones” for open gaps. running at mature clients

ADCS · AKM · OWE

Active Directory Certificate Services, a Windows PKI often abused for privilege escalation / the authentication-and-key-management method a Wi-Fi client negotiates / Opportunistic Wireless Encryption, which encrypts an otherwise-open Wi-Fi network.

Roundup (CVSS)

CVSS always rounds a score up to one decimal - score it mechanically from the vector, never by eye. §4.6

10.5

The first hour - a command reference

The exact commands a junior reaches for in the first hour of an internal engagement, in order. Every one is identification - safe in a vulnerability-assessment scope; nothing here exploits. Run them quietly from the jump-box, and save everything (-oA) so it becomes re-checkable evidence.

# 1 · Live hosts on this subnet - ARP, which cannot be firewalled at Layer 2
arp-scan --localnet
nmap -sn 10.10.10.0/24

# 2 · The four-port “is this soft?” check across the whole subnet
nmap -sS -sU -p T:88,445,3389,U:161 --open 10.10.10.0/24   # 161 is UDP: without -sU it is never tested

# 3 · Full TCP on a target: all ports, versions, default scripts, save every format
nmap -sS -p- -sV -sC -T4 -oA scans/host1 10.10.10.5

# 4 · Targeted UDP on the high-value services (never scan all UDP - too slow)
nmap -sU -p 53,161,123,500 --open -T4 10.10.10.5

# 5 · Is SMB signing required? (the relay-exposure question)
nmap -p 445 --script smb2-security-mode 10.10.10.0/24
netexec smb 10.10.10.0/24            # shares, signing, null sessions

# 6 · Directory: does it allow an anonymous (no-login) read?
ldapsearch -x -H ldap://10.10.10.10 -s base namingcontexts

# 7 · The host plane: credentialed read over WinRM (CONFIRM auth actually succeeded)
#     run the collector with the client's read-only admin account

10.6

Common findings and their one-line fixes

The recurring findings on almost every internal engagement, with the severity they usually carry and the single change that closes each. Severity is always confirmed from the CVSS vector against the client's real exposure (§4.6) - treat this as a memory aid, not a scoreboard.

10.7

Reading a CVSS vector at a glance

A CVSS score is not typed by hand - it is calculated from a vector string, and the score always rounds up (§4.6). Learn to read the string and you can sanity-check any tool's number in seconds. Each letter is one question about how the vulnerability behaves.

Worked read of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  =  9.8, Critical: reachable over the network, easy, needs no login and no user action, with high impact to confidentiality, integrity and availability all at once. You can see it is severe without a calculator - which is exactly the point of learning to read the string.

10.8

The engagement at a glance

The whole lifecycle on one line each - what you do at every phase, the tools you reach for, and what comes out the other end. If you can hold this table in your head, you can run an engagement.

11.1

Scoping without regret

An engagement is won or lost before you send a single packet. A vague scope wastes days and creates real legal risk. When a client says “just test everything,” that is not a scope - it is a trap, because “everything” always turns out to include a system you were never allowed to touch. Pin the boundaries down, in writing, before you agree to start.

1. Exact targets

   The precise IP ranges, domains and URLs - not “the network.” A range you cannot read back to the client is not scoped.

2. Explicit exclusions

   Which systems, accounts and techniques are off-limits. Fragile kit, production databases, anything third-party-hosted.

3. Window and time zone

   When testing may run, in whose clock. “Business hours” without a time zone is how you scan at 2 a.m. and wake the on-call team.

4. Emergency stop

   A named person and number to reach instantly if something breaks, and the agreement that you will call.

5. What “done” looks like

   The deliverable and the definition of success, agreed up front, so there is no argument at the end.

11.2

The pre-engagement conversation

Before any testing, have a real conversation - not just a signed form. Ten minutes here saves a day of firefighting later, and it is where you learn what the engagement is actually about.

11.3

First, do no harm

The fastest way to lose a client forever is to knock something over. A finding you didn't get is recoverable; an outage you caused is not. Default to the gentlest technique that answers the question, and earn the right to be louder only with written permission.

• Start slow and quiet; raise intensity only as needed, never by reflex.
• Never run “denial-of-service,” “brute” or “intrusive” tooling without an explicit written yes - some of it crashes services by design.
• Warn the client's security team before you begin, so your test isn't fought as a real attack.
• On fragile equipment - factory/OT gear, medical devices, old printers - look, don't poke. Passive only.
• Keep the emergency-stop contact open the whole time, and actually use it the moment something looks wrong.

11.4

Reading between the scan lines

The scanner is a junior assistant, not the tester. It finds the obvious and misses the interesting: the two low-risk issues that chain into a serious one, the business-logic flaw no tool understands, the dull “informational” note that is really the way in. Your job begins where the scan ends.

11.5

Prioritising what actually matters

A client handed 300 findings fixes none of them. Your value is telling them the handful that matter this week, in their language. Order the work by real-world risk, not raw severity (see §4.6): anything being exploited in the wild first, then high-likelihood and high-impact, then everything else on a sensible schedule.

11.6

Writing findings that get fixed

A report is not written for another hacker to admire; it is a stack of work orders for a tired engineer at 5 p.m. Write for that person. Two layers cover every reader: one plain sentence an executive understands, and the technical detail an engineer needs to make the change.

1. What is wrong

   One clear sentence, no jargon in the headline.

2. Where

   The exact host, URL or account - so no one has to hunt for it.

3. Proof

   The real request and response, copied from the evidence, never described from memory. If it isn't in the evidence, it doesn't go in the report.

4. The smallest fix

   The specific, cheapest change that closes it - and a link to the vendor's own guidance where one exists.

11.7

Talking to clients and executives

You will spend nearly as much time explaining as testing. Executives care about risk and money, not packets. Translate everything into what could happen to the business and what it would cost - that is the language decisions are made in.

• Lead with impact, not mechanism: what an attacker could reach, and why that hurts.
• Never use fear to upsell. Overstating risk gets you one contract and no second one.
• Say plainly what you did not test, and why. Honesty about gaps is what makes the rest believable.
• Be calm about bad news. You are the person who found the problem, not the person who caused it - act like it.

11.8

The mistakes everyone makes once

Every tester collects these scars. The goal is to make each mistake once, write it down, and never repeat it - and, better, to borrow the ones below so you skip them entirely.

11.9

How to keep learning - a skill ladder

Nobody starts expert. The path is well-worn, and the fundamentals you learn early (Part I) outlast every tool and trend. Climb it in order; skipping rungs is how people end up running tools they don't understand.

1. Fundamentals

   Own the networking and methodology in this handbook cold - Part I especially. Everything else is built on it.

2. Build a home lab

   A few virtual machines and a test Windows domain. Break things where breaking is free; you learn ten times faster with your hands on it.

3. Practise on real methodology

   Structured labs and capture-the-flag exercises that follow the phases in Part II, not random tool-running.

4. Shadow senior work

   Watch how an experienced tester scopes, decides and writes. Judgement is caught more than taught.

5. Own small engagements end to end

   Scope, test, validate, write, present. Owning the whole loop is where a tester is actually made.

6. Specialise

   Then go deep in one area - Active Directory, cloud, wireless or web. Certificates open doors; a lab and real curiosity make the tester.

12.1

The setup - the scope call

Your first internal assessment. A 200-person company wants to know how far an attacker could get from a laptop plugged into their office. On the scope call you nail down the essentials (§11.1): the exact subnets (10.10.0.0/16), what is off-limits (the payroll server, the CCTV VLAN), the window (this week, business hours, their time zone), and an emergency contact. You ask the four questions (§11.2) - they are worried about ransomware spreading, a past test “found nothing,” and yes, they will warn their security team. You send your jump-box's IP to be allow-listed (§3.2). Nothing starts until the rules of engagement are signed (§2.5).

12.2

Getting in and looking around

Day one. You connect to the jump-box on their user VLAN (§3.3) and start quietly. First, who is here: arp-scan and nmap -sn map the live hosts on the local subnet (§4.4) - no need to be loud, because ARP cannot be firewalled at Layer 2 (§1.4). You spot a domain controller (port 88 answering, §1.5), a dozen servers, and a flat network where the workstation VLAN can reach the server VLAN - a segmentation smell you note for later (§4.7). Then the four-port glance (§1.5): 445 is open with signing not required across the board. That one line already tells you the network is soft.

12.3

Running the toolkit and reading results

The client has given you read-only admin credentials (§8.3). You point the collector at the in-scope hosts over WinRM (§7.3), confirm authentication actually succeeded on each one (§4.1 - the empty-report trap), and let it read the real state: patch level, configuration, accounts (§7.4). It seals the evidence (§7.5), and the analyzer scores it against the 37 rules (§7.6) and Microsoft's patch feed (§7.7). Out come real findings: a dozen servers months behind on patches (two on the KEV list), SMB signing not required, and WDigest still caching cleartext passwords on the older boxes. Remember - a “Fail” is not yet a finding; you review each against the client's own baseline before it counts.

12.4

One finding, start to finish

Take the SMB-signing result. What it is (§4.3): signing is not required, so an attacker who poisons name resolution can relay a login to another server without cracking anything. Where: the whole server VLAN. Proof: you do not run the relay - that is exploitation, and it is out of scope - you record the exact setting from the sealed evidence and name the enabling condition. The fix: require SMB signing by Group Policy. You score it mechanically from the CVSS vector (§4.6, Roundup - never by eye), and because it pairs with the flat network you rank it high. You write it in four parts (§11.6): what, where, proof, smallest fix - one sentence an executive understands, the detail an engineer needs.

12.5

The debrief

You prioritise for them (§11.5): “An attacker on any user PC could reach and take over your servers - here are the five changes that break that chain this week.” You tie it to their actual fear: ransomware spreads through exactly this path. You say plainly what you did not test (the CCTV VLAN was out of scope). You do not oversell. They fix the top five; you retest and confirm each one actually fails now (§8.2), not because they said so. And they book you again next year.

12.6

When something looked wrong

Halfway through, a server stopped responding and your stomach drops - did you break it? You check calmly (§11.3): your scan was not touching that host at that moment, and the emergency contact confirms it was a scheduled reboot. Panic over. But notice why it stayed calm: because you had told their security team you were testing (§11.2), they never blamed your traffic; and because you had an emergency contact, you got an answer in two minutes. Without those two habits, a routine reboot becomes an hour of accusations and a damaged relationship.

12.7

What the report looked like

The deliverable was two things, not one. A one-page executive summary - “a laptop on your user network could take over your servers; five fixes close the main path” - and a detailed section with each finding written in the four parts (§11.6). It named only the real tools you drove by hand, never a scanner that ran unattended (§8.5). Every claim was backed by sealed, hashed evidence (§7.5), so anything could be shown on request. Nothing dramatic, nothing overstated - which is precisely why they believed it and acted on it.

13.1

How to read any protocol

You do not memorise protocols by rote. You read each one against the same six questions, and after a dozen protocols the pattern becomes automatic. Every entry below answers exactly these:

13.2

Layer 2 and 3: Ethernet, ARP, IP and ICMP

These are the protocols that get a packet from one machine to another. They were designed in an era of trust, so most have no authentication at all, which is why the local network is such fertile ground for an attacker who is already inside.

ARP (Address Resolution Protocol)

Job: on a local segment, machines talk by MAC address, but applications know only IP addresses. ARP is the lookup that answers “who has IP 10.0.0.5? tell me your MAC.” No transport, no ports, no authentication; it is Layer 2 broadcast. Spec: RFC 826.

How it is abused: because any host can answer any ARP query and hosts believe the last answer, an attacker sends forged replies (ARP spoofing / ARP cache poisoning) claiming to be the gateway. Traffic then flows through the attacker, who can read and alter it. This is the classic on-path (man-in-the-middle) attack and the engine behind tools like bettercap and ettercap.

What we check: is the segment flat (one broadcast domain for everything)? Are there dynamic ARP inspection (DAI) and port security on the switches? On an internal assessment, an unprotected segment where ARP can be poisoned is a real finding, because one compromised host then endangers every conversation on that VLAN.

IP and ICMP

IP (RFC 791 for IPv4, RFC 8200 for IPv6) is the addressing and routing layer: it carries a packet from a source IP to a destination IP across routers, best-effort, with no delivery guarantee. ICMP (RFC 792) is IP's status-message channel: ping (echo request/reply) and traceroute both ride it. Assessors use ICMP for host discovery; defenders sometimes rate-limit or block it, which only slows discovery, it does not hide a host. IPv6 matters even when “nobody uses it”: it is often on by default, unmonitored, and can offer a parallel unfiltered path to the same host.

13.3

Transport: TCP and UDP

TCP (RFC 9293) sets up a connection with the three-way handshake (SYN, SYN-ACK, ACK) shown in Part I, tracks every byte, retransmits what is lost, and tears down cleanly with FIN. Those control bits, the flags, are what a port scanner manipulates to learn a port's state without completing a full connection.

UDP (RFC 768) has no handshake and no flags, which makes UDP scanning slow and ambiguous: silence can mean open or filtered. But many high-value services are UDP only (DNS 53, SNMP 161, NTP 123, IKE/VPN 500), so skipping UDP misses them. UDP services are also the classic amplifiers in reflection DDoS, because a small request can trigger a large reply to a spoofed victim.

13.4

Naming and addressing: DNS and DHCP

These two services quietly run every network. Because everything trusts them, poisoning either is one of the most productive moves an internal attacker has.

DNS (Domain Name System)

Job: turn names people can remember (intranet.example.com) into IP addresses machines can route to. Runs on UDP 53 for lookups and TCP 53 for large answers and zone transfers. Classically cleartext (DNS-over-TLS and DNS-over-HTTPS are the encrypted successors). Spec: RFC 1035.

How it is abused: a misconfigured server allows a zone transfer (AXFR), handing you the entire internal name list at once. DNS cache poisoning feeds a resolver a false answer so users go to the attacker's address. On Windows networks, when normal DNS fails, clients fall back to LLMNR and NBT-NS broadcasts, which an attacker answers to harvest credentials (see Part XIV). What we check: is AXFR restricted to authorised secondaries; is the resolver patched against poisoning; is LLMNR/NBT-NS disabled.

DHCP (Dynamic Host Configuration Protocol)

Job: hand a newly connected device its IP address, subnet mask, gateway and DNS server automatically. UDP ports 67 (server) and 68 (client). No authentication. Spec: RFC 2131. The exchange is four steps, remembered as DORA.

How it is abused: a rogue DHCP server races the legitimate one to answer, then gives victims the attacker's machine as their gateway and DNS. DHCP starvation floods the server with fake requests until it runs out of addresses, denying service. What we check: is DHCP snooping enabled on the switches (it drops offers from unauthorised ports)?

13.5

The web trio: HTTP, HTTPS and TLS

HTTP (RFC 9112, semantics in RFC 9110; HTTP/2 in RFC 9113) is the request-and-response protocol of the web, on TCP 80. A client sends a method and a path; the server returns a status code and a body. HTTPS is the same HTTP wrapped in TLS (RFC 8446) on TCP 443, which adds encryption (nobody on the path can read it), integrity (nobody can change it undetected) and identity (the certificate proves you reached the real server).

What we check on TLS: the protocol version (TLS 1.2 and 1.3 good; SSLv3, TLS 1.0 and 1.1 are findings), the cipher suites, and the certificate (expiry, trust chain, hostname match, key strength). A weak or expired certificate, or an old protocol still enabled, is one of the most common external findings because it is easy to test and easy to prove. Deeper web methodology is Part VI; the definitive testing reference is the OWASP Web Security Testing Guide and the OWASP Top 10 (2025).

13.6

The Windows enterprise stack: SMB, NTLM, Kerberos, LDAP, RDP

An internal Windows network runs on a small family of protocols. Understanding them is the difference between reading an Active Directory assessment and guessing at it.

SMB (Server Message Block)

Job: Windows file and printer sharing, and a transport for other services, on TCP 445 (legacy NetBIOS on 137-139). Open spec: MS-SMB2. How it is abused: the infamous EternalBlue (MS17-010) rode SMBv1; unsigned SMB enables relay attacks (Part XIV); readable shares leak data and credentials. What we check: is SMBv1 disabled; is SMB signing required (not just enabled); can a null or guest session list shares; are share permissions least-privilege.

NTLM and Kerberos (authentication)

These are the two ways a Windows identity is proven. NTLM is the old challenge-response scheme: it works without a domain controller but is vulnerable to relay and to offline cracking of captured hashes. Kerberos (RFC 4120) is the modern default: the domain controller issues time-limited tickets so the password never crosses the wire. Kerberos is stronger, but its ticket design opens specific attacks (Kerberoasting, AS-REP roasting) covered in Part XIV.

LDAP, RDP, WinRM and MS-RPC

LDAP (RFC 4511, TCP 389, or 636 for LDAPS) is how you query Active Directory: users, groups, computers, policies. An anonymous bind that returns data is a finding, because it hands the directory to an unauthenticated attacker. RDP (TCP 3389) is remote desktop; exposed to the internet it is a top ransomware entry point, so we check for network-level authentication and whether it is reachable externally at all. WinRM (TCP 5985/5986) is remote PowerShell management. MS-RPC (TCP 135 plus dynamic ports) underlies much of Windows' internal machinery. What we check across all of them: are they exposed beyond where they need to be, are they patched, and do they enforce encryption and strong authentication.

13.7

Management and remote access: SSH, Telnet, SNMP, NTP

13.8

File, mail and voice: FTP, SMTP, SIP

FTP (RFC 959, TCP 21) transfers files in cleartext, credentials included, and often allows anonymous access; prefer SFTP (over SSH) or FTPS. SMTP (RFC 5321, TCP 25, plus 587/465 for submission) moves email between servers; assessors check for an open relay (a server that will send mail for anyone, abused for spam and spoofing) and for the anti-spoofing records SPF, DKIM and DMARC. Companion mailbox protocols are IMAP (143/993) and POP3 (110/995). SIP (RFC 3261, UDP/TCP 5060, 5061 for TLS) sets up VoIP calls; check for exposed PBX interfaces, default extensions and toll-fraud exposure.

13.9

Windows and Linux on the same wire

13.10

The protocol quick card

One table to scan before an engagement. If a service is cleartext or authenticates weakly, it earns a closer look.

14.1

How to think about attacks

14.2

Interception: poisoning, relay and man-in-the-middle

ARP spoofing (§13.2) is the classic, but on a Windows network the most productive interception attack is LLMNR and NBT-NS poisoning, mapped by MITRE as T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay).

How it works: when a Windows machine cannot resolve a name through DNS (a typo, a dead share, a stale mapping), it does not give up; it shouts to the whole local segment over LLMNR and NBT-NS: “does anyone know where fileserv is?” These fallback protocols have no authentication, so an attacker running a listener simply answers “yes, that is me”. The victim then tries to authenticate to the attacker, sending its NTLM challenge-response, which the attacker either cracks offline to recover the password, or immediately relays to another machine that does not require SMB signing, authenticating as the victim without ever knowing the password.

What we check (the controls): is LLMNR disabled by Group Policy; is NBT-NS disabled on adapters; is SMB signing required (this alone defeats the relay); is the segment monitored for rogue responders. Related interception attacks and their controls: DNS spoofing (patched resolvers, DNSSEC), rogue DHCP (DHCP snooping, §13.4), and SSL stripping (HSTS, redirect all HTTP to HTTPS).

14.3

Credential attacks: getting a login without the password

14.4

Active Directory and Kerberos attacks

Active Directory runs the Windows enterprise, so its trust model is the prize. These attacks abuse how Kerberos issues tickets (§13.6). They are the reason the toolkit collects AD configuration: to find the conditions that make them possible before an attacker does.

The end-to-end attack path, foothold to domain dominance, is drawn in §4.3. The toolkit's role is upstream of all of it: identify the roastable accounts, the stale krbtgt, the excessive privileges, and the missing signing, so the chain never starts.

14.5

Service exploitation: CVEs, defaults and misconfiguration

Not every attack is clever. Many are simply an exposed service that is unpatched, left on a default password, or misconfigured.

• Known-CVE exploitation (T1210): a public vulnerability with a working exploit. The most dangerous are the ones on the CISA KEV catalogue, meaning attackers are using them right now. EternalBlue (MS17-010) against SMBv1 is the textbook example. We identify the missing patch and its KEV status; the fix is patching.
• Default and shared credentials: the printer on admin/admin, the switch on public, the app with the vendor's demo login. Fast to find, embarrassing to leave. Check every management interface.
• Misconfiguration: an exposed database with no authentication, a management port open to the internet, an anonymous file share, directory listing enabled. No exploit required; the door is simply open.

14.6

Layer 2 attacks: abusing the switch

Segmentation lives on the switch (§1.6). These attacks try to defeat it from a single connected port.

14.7

Denial of service and amplification

A denial-of-service attack does not steal data; it removes availability, one of the three pillars alongside confidentiality and integrity. We do not run DoS in an assessment (it is destructive and out of scope by default); we identify the exposure.

What we check: is any internal service reachable from the internet as an open amplifier (open DNS resolver, NTP with monlist, exposed memcached)? Those are real findings, because the client's own infrastructure can be turned into a weapon against others, and against themselves.

14.8

The web and application vulnerabilities, in one place

Web and API testing has its own methodology in Part VI; this is the orientation so the names are familiar. The authority is the OWASP Top 10 (2025), with the API Security Top 10 for APIs and the OWASP Cheat Sheet Series for defences.

14.9

The attack-to-control map

Every attack in this part is stopped by a control you can verify. This table is the whole part in one view: read the attack, know the control, and you know what to check.

15.1

Where a database belongs

15.2

The database quick reference

Learn the ports. On a scan, these numbers tell you a data store is present, and each has a signature weakness.

15.3

How databases are reached and abused

• Exposed with no authentication: the NoSQL classic. Connect to the port, read everything. No exploit, no credentials.
• Default or weak credentials: sa with a blank or guessable password on SQL Server; root with nothing on MySQL.
• Unencrypted connections: if the app-to-database traffic is cleartext, an on-path attacker (§14.2) reads queries and results, credentials included.
• SQL injection at the application: the database is reached through the web app when input is treated as query code (§14.8). This is an application finding whose blast radius is the whole database.
• Feature abuse for host access: SQL Server's xp_cmdshell, PostgreSQL's programmable functions, or a writable Redis instance can turn database access into operating-system access.
• Exposed backups: a .bak, .sql or dump file on an open share is the whole database with none of the access controls.

15.4

What we check

16.1

How to think about tooling

16.2

Discovery and scanning: Nmap

Nmap is the one tool to master. It finds live hosts, open ports, the service and version behind each port, and (with the scripting engine) a great deal more. Deep coverage is in §4.4; here is the working shape.

# discover live hosts on a subnet, no port scan
nmap -sn 10.20.4.0/24
# full TCP port + service/version, saved in every format
nmap -sS -p- -sV -oA scans/internal 10.20.4.0/24
# the top UDP services people forget
nmap -sU --top-ports 50 10.20.4.10
# safe, non-intrusive scripts for a host
nmap -sV --script "default and safe" 10.20.4.10

masscan scans enormous ranges fast when you need a first sweep, then you confirm with Nmap. The rule: sweep wide, confirm deep. Never trust a single fast scan's port list as final.

16.3

Capture and analysis: Wireshark and tcpdump

Wireshark (graphical) and tcpdump (command line) record and decode the actual packets on the wire. They are how you prove a protocol is cleartext, watch a handshake, or confirm what a device is really doing. In an assessment you capture your own traffic and broadcast traffic to characterise the segment; you do not intercept others' traffic without explicit authorisation.

# capture on an interface to a file for later analysis
tcpdump -i eth0 -w capture.pcap
# see cleartext credentials cross the wire (your own test login)
# open capture.pcap in Wireshark, filter: http.request or ftp or telnet

16.4

Windows and Active Directory enumeration

16.5

Credential and hash tooling

Hashcat (GPU) and John the Ripper (flexible) recover passwords from captured hashes offline. In an assessment their purpose is to demonstrate password weakness: a hash that cracks in seconds proves the policy is inadequate. You report that a percentage cracked and how fast, never the plaintext passwords themselves in the deliverable.

16.6

Web and API tooling

16.7

Wireless tooling

Covered in method in Part V. The staples: Aircrack-ng (the suite for capturing and testing Wi-Fi encryption) and hcxdumptool (efficient PMKID and handshake capture). Both require a wireless adapter that supports monitor mode and packet injection, which is why wireless is an on-site, not a remote, assessment.

16.8

Vulnerability scanners and reference databases

Where a broad automated network scan is in scope, the established engines are Nessus, Greenbone / OpenVAS and Nuclei. They cast a wide net and always need a human to confirm what is real. For host-level depth, the toolkit performs credentialed assessment from the inside (Part VII), which is more accurate than unauthenticated scanning. Keep these reference databases open while you work:

16.9

The tool selection map

17.1

The zone model of an enterprise network

17.2

Segmentation, micro-segmentation and zero-trust

The zones only mean something if the doors are enforced. Segmentation is the coarse version: firewalls and VLANs between zones. Micro-segmentation pushes policy down to the individual workload, so even two servers in the same datacenter cannot talk unless a rule says so; this is what contains east-west movement. Zero-trust (NIST SP 800-207) is the principle behind it: never trust by location, authenticate and authorise every request. Its three logical parts are the Policy Engine (decides), the Policy Administrator (enacts), and the Policy Enforcement Point (the door that actually blocks or allows).

17.3

Banking and regulated networks

Banks are the most heavily segmented networks you will meet, because overlapping mandates require it and the assets are high value. You do not need a real bank's map; you need the control requirements that shape every one of them.

17.4

When there is OT: the Purdue model

Banks, utilities and manufacturers often run operational technology (building management, industrial control) alongside IT. These are organised by the Purdue model: Level 0 (sensors and actuators), Level 1 (controllers, PLCs), Level 2 (supervisory HMI/SCADA), Level 3 (site operations), a Level 3.5 IT/OT DMZ, and Levels 4 and 5 (business IT). IEC 62443 adds the zones-and-conduits model: group assets into zones, allow traffic only through defined, secured conduits. The assessor's rule for OT is caution: these systems are fragile and safety-critical, so testing is gentle, often passive, and only with explicit sign-off. Active probing that is routine on IT can halt a physical process.

17.5

How a tester actually gets in

There is no single way. The access method is chosen to match the question the engagement is answering, and it is written into the rules of engagement.

17.6

Inside versus outside, and the reachability matrix

The outside attacker sees only what the perimeter exposes: public IPs, DMZ services, the VPN portal, published APIs, and any accidental exposure. The inside foothold reaches whatever segmentation allows, and then pursues lateral movement toward the high-value zones. The gap between the two is the whole point: a strong perimeter can hide a flat, soft interior.

The reachability matrix (introduced in §4.7) is how you prove it. From representative points in each zone, you test what can open connections to what, source zone against destination zone against allowed ports, and you produce a grid. Every cell that allows a path which policy says should be blocked is a segmentation finding. This is the concrete test behind PCI's “confirm segmentation is effective” and behind any micro-segmentation claim.

17.7

The engagement, on the ground

• Before: the ROE is signed, the scope and IP ranges are fixed, an emergency contact is named, and your testing source is whitelisted (§11.1, §11.2).
• Arrival: confirm scope and timing face to face, collect the access method (port, VPN profile, or credentials), and tell the security team you are starting so your traffic is not mistaken for a real attack (§11.3).
• During: work the methodology (Parts IV to VI), stay strictly inside scope, capture evidence as you go, and give a short daily status. If something looks like it broke, stop and call the contact (§12.6).
• After: remove any dropbox or test accounts, hold an out-brief in the client's language (§12.5), and deliver findings backed by sealed evidence (§7.5). Then retest the fixes rather than taking “done” on trust (§8.2).

18.1

Discovery and recon

18.2

Internal and Active Directory

18.3

Segmentation and Layer 2

18.4

Configuration and services

18.5

Web, cloud and wireless

18.6

Judgement and professionalism

19.1

Standards and methodology

19.2

Protocol specifications

The primary sources for Part XIII. When behaviour is disputed, the RFC settles it.

19.3

Vulnerability intelligence

19.4

Web and application

19.5

Tool homepages

Always download from the official source. Full treatment is in Part XVI.

19.6

Technique references and learning

19.7

A self-study path

1. Weeks 1-2, foundations. Re-read Parts I and XIII until addressing, layers and the protocol quick card are automatic. Build the home lab from §11.9.
2. Weeks 3-4, the attacks. Work Part XIV against your own lab (never a live network). Watch each attack in Wireshark so you see what it looks like on the wire.
3. Weeks 5-6, the web. Work through the PortSwigger Academy labs alongside Part VI; broken access control first.
4. Weeks 7-8, the method. Run the full pipeline of Parts IV to VIII against the lab, and write a real report from it using §8.5.
5. Ongoing. When any new tool or attack appears, trace it back to the basics here. It is always an address, a port, a login, or a trust.