Hacker Tradecraft · Volume 11

Hacker Tradecraft Volume 11 — The Red Hat: The Aggressor

Sanctioned adversary emulation, C2 frameworks, MITRE ATT&CK, AD attack tooling, and physical-entry RF/HID staging — with the triple disambiguation of 'red hat' carried up front and the boundary against the black hat held by the same paperwork that holds the white hat

Contents

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

About this volume. Volume 11 is the aggressor’s volume. It treats the red hat as the field actually uses the term in 2026 — the sanctioned adversary emulator: the operator who runs a multi-week assumed-breach campaign against a client’s environment, replicating a specific threat actor’s documented techniques to test whether the blue team (Vol 10) can detect and respond. The volume’s load-bearing structural point is that the red hat shares its authorization model with the white hat (Vol 6) — both operate under written scope and signed contract — and differs from the black hat (Vol 7) on exactly that authorization, not on technique. The same Cobalt Strike Beacon that an authorized red-team operator carries is the cracked Beacon that a ransomware affiliate uses; the discriminator is the SOW and the legal-and-ethical envelope around it. The triple-disambiguation of “red hat” — engagement-role aggressor, vigilante (largely dead vocabulary), Red Hat Linux corporation (unrelated) — appears in §1 because Vol 5 §5.4 promised it would. The cross-tool connection to the Hack Tools hub is the physical-entry RF/HID staging layer where the WiFi Pineapple, the Flipper Zero, the Proxmark3, and the Hak5 implant family (Ducky Script deep dive) all sit; §3.6 walks the working set. The reader (tjscientist, 45+-year EE/SW engineer) is not a working red-team operator, but the engineering instincts that the role rewards — careful instrumentation, threat-model fidelity, the discipline of running an experiment under contract rather than under impulse — map directly onto how an EE thinks about a structured engagement.


1. Definition and boundary

The red hat is the sanctioned aggressor: the practitioner whose authorized work is emulating an adversary against a client’s environment, with the engagement objective of testing the client’s detection and response capability against a specific threat-actor profile. The authorization that makes the white hat (Vol 6) white-hat is shared with the red hat — both operate under a signed Statement of Work, a scope document, a Rules of Engagement document, and (when the engagement includes physical entry) a Get-Out-Of-Jail letter — but the engagement role is different. The white-hat-pentester’s role is exhaustive vulnerability discovery within scope; the red-hat operator’s role is emulation of a specific adversary’s TTPs against the same scope. Both sit on the authorized side of Axis 1 (Vol 5 §6.1); both share the offensive position on Axis 2 (Vol 5 §6.2). The distinction is in scope shape, engagement duration, and deliverable. The hats are siblings, not opposites; the red hat is white-hat-on-Axis-1, offensive-engagement-role-on-Axis-2.

The popular shorthand “red team is the offensive team, blue team is the defensive team” is correct as far as it goes but loses two important things. First, both teams are white-hat on Axis 1 in any legitimate engagement — they are both operating under organizational authorization, and the apparent adversarial framing of “red versus blue” is structural fiction, not actual conflict. Second, the engagement-role color (red vs blue vs purple) is orthogonal to the ethical stance hat (white vs black vs grey vs green); a single individual can be a white-hat-red-teamer on Monday’s adversary-emulation engagement, a white-hat-blue-teamer in Tuesday’s SOC shift, and a white-hat-purple-teamer in Wednesday’s collaborative threat-emulation exercise. The hat changes with the activity, not with the person. Vol 12 (purple hat) treats the explicit-integration practice that combines red and blue in real time; this volume treats the offensive engagement role as a primary subject of its own.

A second clarification — load-bearing, and the reason Vol 5 §5.4 promised it — is that “red hat” in 2026 has three live meanings, and exactly one of them is the primary subject of this volume. The three are:

(a) The modern red-team operator — the sanctioned adversary emulator. The primary meaning in industry usage as of 2026: in job postings (“Senior Red Team Operator, financial services”), in conference programming (DEF CON Red Team Village, founded 2018; substantial red-team content at Black Hat USA, BSides, X33fcon, RingZer0; the SANS Pen Test HackFest red-team track), in vendor product positioning (Cobalt Strike, Brute Ratel, Mythic, Sliver as “red-team platforms”), and in trade-press writing. This volume is primarily about this meaning.

(b) The older “red hat as vigilante” framing — the late-1990s and early-2000s trade-press use of “red hat” to describe an unauthorized actor attacking other unauthorized actors (a “hacker who hacks hackers”; an unauthorized actor “fighting back” against ransomware operators or other threat groups). The framing was popular-trade-press-coined, was never adopted by community-internal vocabulary (Eric Raymond’s Jargon File never used it), and is essentially dead in 2026 professional vocabulary. It appears in older texts and occasional non-expert sources. This volume treats it as a one-paragraph historical artifact in §2.3 and otherwise carries the modern engagement-role meaning.

(c) The Red Hat Inc. corporate brand — Red Hat Inc., the commercial Linux distribution and enterprise-software company founded 1993 by Marc Ewing and Bob Young, acquired by IBM in 2019 for $34 billion. The corporate name derives from Ewing’s red lacrosse cap at Carnegie Mellon; the brand is structurally unrelated to either security-hat sense1. The naming collision is a recurring source of confusion in casual usage (“Are you a red hat?” can mean do you do red-team work or do you work at Red Hat Inc. depending entirely on context). This volume covers this meaning in one line: it is unrelated, and the reader should disambiguate by surrounding context.

The legal-and-ethical boundary for the red-hat meaning (a) is the same boundary the white-hat shares: the engagement is authorized by a signed contract that establishes the testing organization’s permission to attack the client’s environment, with a defined scope, a defined working window, and a defined set of permitted techniques. Without that authorization stack, the same activity is described by Vol 7 (black hat) — not by this volume. The vigilante framing (b) is unauthorized access regardless of the attacker’s purported justification; the argument “we just wanted to hit back at a ransomware group” does not survive case-law examination in the United States, the United Kingdom, the EU member states, or substantially any other jurisdiction. The legal posture for hack-back was treated in Vol 10 §8.3 from the defender’s side; Vol 19 §6 will walk the full statutory framing.

The red team is not the black hat — load-bearing callout. A red-team operation is sanctioned, authorized, scope-bound. The legal frame is identical to the white-hat pentest (Vol 6 §1) — the same SOW, scope document, ROE, and (when physical entry is in scope) GOJL — and the discriminator from the black hat (Vol 7) is the authorization stack, not the technique. The same Cobalt Strike Beacon that a sanctioned red-team operator deploys is the same cracked Beacon a ransomware affiliate uses. The Mimikatz invocation that runs under an authorized red-team engagement runs against the same LSASS-memory data structures as the Mimikatz invocation that runs in a Conti affiliate’s post-exploitation phase. The wire traffic looks the same; the legal status is opposite. Authorization is what separates red-team from criminal activity. Without the paperwork stack, the same work is described by a different volume — Vol 7 (black hat), Vol 8 (grey hat), or Vol 19 (legal line). This callout reappears throughout the volume.

1.1 What separates red-team work from pentest work

The red-hat / white-hat-pentest boundary is the boundary internal to authorized work — not the boundary against unauthorized activity (which is Vol 7’s discussion). Three structural dimensions distinguish a red-team engagement from a pentest engagement:

Scope duration. Pentest engagements run days to weeks — a typical external network pentest is five business days; an internal AD pentest might be two weeks; a comprehensive application pentest might be four weeks. Red-team engagements run weeks to months — a typical “long-form” red-team engagement is six to twelve weeks, with the longest engagements (particularly those embedded inside large enterprise security programs) running continuously across a fiscal quarter or longer. The duration difference is structural to the work: the red-team operator is replicating an adversary who plans, recons, gains access, persists, moves laterally, and works toward a specific objective across an extended timeline. Compressing that timeline into a week reduces the engagement to a pentest in red-team vocabulary.

Engagement objective. A pentest’s objective is exhaustive vulnerability discovery within the in-scope assets — the deliverable is a comprehensive list of vulnerabilities with severity ratings and remediation guidance. A red-team engagement’s objective is demonstrating a specific outcome via a specific adversary’s TTPs — “Could a Conti-affiliate-equivalent operator have exfiltrated the customer-PII database within six weeks?” or “Could an APT29-equivalent operator have persisted in the executive-staff endpoint fleet for ninety days without detection?” The pentest answers what is vulnerable; the red-team answers whether this specific scenario succeeds. The two questions are different in shape; the engagement structures that answer them are differently shaped.

Deliverable structure. A pentest report is a vulnerability list — findings indexed by severity, with CVSS scores, technical proof of concept, remediation guidance, and engineering-team-targeted detail. A red-team report is a narrative of compromise — the story of how the engagement progressed from initial access through the kill chain to objective achievement, with detection-and-response gaps named explicitly. The audience is different: the pentest report’s primary audience is the engineering team that will remediate the findings; the red-team report’s primary audience is the CISO, the security operations leadership, and the detection-engineering team who will use the engagement as input to the detection-coverage roadmap. The red-team report’s companion artifact — increasingly standard in 2026 mature engagements — is the MITRE ATT&CK Navigator layer showing which TTPs were exercised and which the blue-team caught (the purple-team artifact that Vol 12 will treat at depth).

The three dimensions reinforce each other. A six-week engagement that produces a vulnerability list is just an expensive pentest; a five-day engagement that claims to be a red-team is just compressing the work too far. The discipline of running an engagement as a red-team engagement requires the duration, the objective shape, and the deliverable structure to all match the role.

1.2 The authorization envelope — same paperwork stack as white-hat

The red-team authorization paperwork is structurally identical to the white-hat-pentest paperwork stack walked in Vol 6 §1:

  • A Statement of Work (SOW) — the contractual document between the testing firm and the client (or, for in-house red teams, the equivalent internal-authorization charter). The SOW captures the engagement’s term, price, deliverables, and the legal-clause stack (consent-to-test, indemnification, IP and confidentiality, limitation of liability). The consent-to-test clauses for a red-team engagement are typically broader than a pentest’s — covering “the entire production network” rather than a specific subnet — but the structural elements are the same.
  • A scope document that names the systems, IP ranges, applications, physical locations, and personnel populations that are in scope. The red-team scope document is often broader than a pentest’s (the engagement is enterprise-wide) and with more named exclusions (specific systems too production-critical to test; specific executive personnel excluded from social-engineering; third-party hosted services where collateral impact is plausible). The negative list is as load-bearing as the positive list.
  • A Rules of Engagement (ROE) document covering work hours (red-team engagements typically run 24/7 to replicate adversary persistence; some have business-hours-only constraints for operational reasons), escalation channels, deconfliction-with-the-SOC arrangements (see below), and the permitted-technique inventory (phishing, physical entry, OSINT, lateral-movement scope, post-exploitation depth).
  • A Get-Out-Of-Jail letter (GOJL) signed by the client’s authorized officer, naming the testing personnel and the engagement window. The GOJL is more consequential for red-team work than for pentest work because red-team engagements more often involve physical-entry components — the operator may need to produce the letter to a security officer or law enforcement during the engagement.

The structural extension that red-team engagements add on top of the white-hat-pentest stack is the transparency tier — how much the blue team knows about the engagement. Three working levels are conventional:

  • White-box (also called “transparent”): the blue team knows the engagement is running, knows when it’s running, and knows roughly what the red-team’s objectives are. This is the purple-team mode (Vol 12) — the engagement is structured as a joint exercise.
  • Grey-box (also called “semi-transparent”): the CISO and a small number of senior security leaders know the engagement is running; the SOC analysts, IR responders, and detection engineers do not. The engagement tests the SOC’s response as if the engagement were a real adversary; the senior leaders maintain the deconfliction channel.
  • Black-box (also called “blind” or “double-blind”): only a small number of named individuals (the CISO and the engagement-coordinator) know. The SOC, the IR team, and substantially the entire security organization is unaware that an exercise is running. The engagement tests the full incident-response path — including the executive-escalation path — as if the adversary were real.

The transparency tier is decided at scoping and is part of the engagement design. Black-box engagements are the rarest because the coordination overhead is high (the engagement-coordinator has to be available 24/7 to defuse situations where the SOC is about to call law enforcement); grey-box is the modal industry pattern; white-box (purple-team integration) is the rising mode in mature 2026 enterprise practice.

1.3 The boundary tested by hard cases

Three hard cases that test the red-hat boundary, with the working answer for each:

  • The “tip-over” point where active red-team engagement creates real risk. A red-team operator with established Beacon C2 in a production environment is, by construction, in a position to cause real harm — accidental Active-Directory damage, accidental denial-of-service, accidental data corruption. The discipline is the same as the white-hat-pentest discipline (Vol 6 §4.6): proof of impact without causing it. A Beacon that has Domain Admin can demonstrate the privilege; it does not need to actually delete the AD database to prove the point. The engagement’s value is the demonstration, not the damage; the discipline is the working line between the two.
  • Cross-organization implications during physical entry. A red-team operator running an authorized physical-entry engagement at the client’s headquarters discovers that the building shares its lobby with a different organization (a partner organization; a SaaS vendor co-located; an unrelated tenant). The operator’s authorization extends to the client’s tenant space; it does not extend to the unrelated organization’s space. The discipline is the same as the white-hat-pentest out-of-scope-discovery (Vol 6 §1.2): document the finding (“the shared-lobby reception desk has visibility into your tenant entrance”), do not pivot. Cross-tenant exploration during physical engagements is one of the more delicate single boundaries in red-team work.
  • The “deconfliction call” during an active phase. Mid-engagement, the operator is moving laterally through the production environment. The SOC has detected unusual activity and is escalating — the on-call IR analyst is paging executives, the SOC is preparing to call the incident-response retainer firm. The operator’s path is to not tip the engagement (which destroys the engagement’s value as a real-world test) but also to escalate to the deconfliction contact when the SOC’s response is about to spend client resources unnecessarily (e.g., they’re about to call the FBI). The judgment call is the engagement-coordinator’s, made in real time, with the operator providing the context. There is no universally correct answer; the senior engagement-coordinator’s discipline is to weigh the engagement’s value against the cost of the SOC’s response and make the call deliberately rather than reflexively.

These cases reappear throughout the volume — the tip-over discipline in §4’s lifecycle, the cross-tenant discipline in §5’s physical-entry composite, the deconfliction call in §5’s mid-engagement composite.


2. Origin and how the term is actually used

“Red team” as engagement-vocabulary has two parallel etymologies that converged into modern industry usage. Both are worth keeping separate because they map onto different parts of the term’s working meaning today, and because the convergence of the older “red hat” sense with the newer “red team” sense in industry vocabulary around 2010 is the reason the modern term carries the institutional weight it does.

2.1 The military adversary-emulation lineage

The first etymology is military and substantially older than the cybersecurity meaning. The U.S. Department of Defense formalized “red team” as the structured-adversary-emulation practice during the Cold War — the canonical reference points are the SAIC red-team work for the DoD across the late 1960s and the broader war-gaming practice across the 1960s through the 1990s, with the 1990s SAIC contracts representing the consolidation of red-teaming into a named professional discipline within defense contracting2. “Red team” in that vocabulary is the adversary role in a war game — the team representing the threat (Soviet/adversary in Cold War scenarios; generic adversary in the post-Cold-War era; specific named threat actors in the modern threat-informed-defense framework). “Blue team” in the same vocabulary is the friendly defender role; “white team” is the exercise-control function (referees, scoring, scenario design); “green team” is the exercise-support function (logistics, communications). The cybersecurity field inherited the red and blue terms in commercial usage; white-team and green-team survive in some military and federal-government exercise contexts but are rare in commercial vocabulary.

U.S. Army leaders briefing during the Allied Spirit I multinational war-gaming exercise at the Joint Multinational Readiness Center, Hohenfels, Germany, January 2015. The war-gaming format — advers…
U.S. Army leaders briefing during the Allied Spirit I multinational war-gaming exercise at the Joint Multinational Readiness Center, Hohenfels, Germany, January 2015. The war-gaming format — adversary force ("red") engaging friendly force ("blue") under exercise-control oversight — is the structural ancestor that 1990s defense-contracting work translated into cybersecurity adversary emulation. The vocabulary migration from military exercise to commercial cybersecurity carried the role colors with it; modern red-team and blue-team practice inherits the engagement structure from this lineage. Photo: File:Allied Spirit I, War Gaming Brief 150120-A-EM105-483.jpg by Sgt. William Tanner. License: Public domain. Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AAllied%20Spirit%20I%2C%20War%20Gaming%20Brief%20150120-A-EM105-483.jpg).

Figure 11.1 — U.S. Army war-gaming brief during Allied Spirit I, January 2015. File:Allied Spirit I, War Gaming Brief 150120-A-EM105-483.jpg by Sgt. William Tanner. License: Public domain. Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AAllied%20Spirit%20I%2C%20War%20Gaming%20Brief%20150120-A-EM105-483.jpg).

The migration from military exercise to commercial cybersecurity accelerated through the 1990s and 2000s as enterprise security organizations began adopting formal adversary-emulation practices. Vol 5 §5 walked the broader chronology; the consolidation point worth naming here is that the 2000s-decade convergence of (a) the L0pht-and-aftermath generation of senior practitioners moving into commercial consulting roles (Vol 3 §4 walked the L0pht/@stake/Symantec acquisition; Vol 4 §2 walked the consultancy-consolidation wave), (b) the maturing internal-threat-intelligence functions at large enterprises and (c) the post-Mandiant-APT1-2013 (Vol 4 §4) industry recognition that nation-state adversaries were running long-form intrusion campaigns against commercial targets produced the institutional appetite for commercial red-team services. By approximately 2010, “red team” in commercial cybersecurity vocabulary meant authorized adversary emulation engagement in a way it had not in 2000.

2.2 The commercial-security adoption — Mandiant Red Team and the consultancy generation

The commercial red-team practice’s institutional founders are a small set of firms whose adversary-emulation work in the 2005-2015 window established the modern engagement model:

  • Mandiant’s Red Team (Mandiant founded 2004 by Kevin Mandia; acquired by FireEye in 2013; FireEye → Trellix split in 2022 with Mandiant going to Google in 2022 for $5.4 billion as part of Google Cloud) is the canonical commercial red-team practice. Mandiant’s red-team consultancy work in the late 2000s and early 2010s established the engagement format (long-form, threat-actor-emulation, narrative-of-compromise deliverable) and the operational rhythm (multi-week engagements with explicit ATT&CK-mapped TTP execution). The Mandiant red-team’s published methodology documents and conference presentations across the 2010s are reference material for the field’s working practice.
  • FireEye (post-Mandiant-acquisition, 2013-2022) integrated the red-team consultancy with FireEye’s broader threat-intelligence and detection-engineering products; the integration’s value was the loop between red-team engagement findings and FireEye’s product detection updates.
  • CrowdStrike Services (CrowdStrike founded 2011 by George Kurtz, Dmitri Alperovitch, and Gregg Marston; the Services arm runs adversary-emulation engagements alongside the better-known Falcon EDR product line) is the second canonical commercial red-team practice. CrowdStrike’s Global Threat Report annual publication carries the threat-intelligence framing that the Services red-team work builds on.
  • IBM X-Force Red (launched 2016 as IBM’s dedicated adversary-emulation practice under Charles Henderson’s leadership) is the third major commercial red-team consultancy, with particular depth in industrial-control-system and IoT red-team engagements alongside the broader enterprise practice.
  • NCC Group, Bishop Fox, Trustwave SpiderLabs, WithSecure (formerly F-Secure Consulting), Rapid7, and the broader second-tier consultancy market round out the commercial red-team practice as of 2026. Each has firm-specific strengths and a customer profile; the market is competitive enough that no single firm dominates the way Mandiant did in the 2010s.

The in-house red-team practice — the corporate-employed red team operating against its own employer’s environment — emerged as a distinct career path through the same 2010-2020 window. Major tech companies (Google, Microsoft, Meta, Apple, Amazon, Netflix), major financial-services firms (the Big Four banks, the major investment banks, the largest insurance carriers), major government contractors, and the federal government itself (the DoD’s USCYBERCOM; the various agency-internal red teams) maintain in-house red-team functions whose scale rivals the consultancy practices. The career path of in-house red-team operator → in-house red-team lead → in-house red-team program manager is a distinct senior-defender-adjacent track that §6 will walk.

2.3 The “red hat as vigilante” framing — historical artifact

The older “red hat” framing — describing an unauthorized actor attacking other unauthorized actors — appears in some 1990s and early-2000s trade-press writing and has essentially died in 2026 professional vocabulary. The framing is worth naming once because a reader encountering “red hat” in an older text (a 2002 trade-press article; a 1998 conference talk transcript) might be reading the vigilante sense rather than the modern engagement-role sense. Eric Raymond’s Jargon File never adopted “red hat” in the vigilante sense; the framing was always trade-press-popular rather than community-internal3. In 2026 professional vocabulary, “I do red-team work” unambiguously means I run sanctioned adversary-emulation engagements — the vigilante sense is essentially absent. The legal-and-ethical posture of vigilante activity is unauthorized access regardless of the actor’s purported justification (the “hack-back” callout in Vol 10 §8.3 covered the legal framing from the defender’s side; Vol 19 §6 will walk the full statutory case).

The Red Hat Inc. corporate brand is, again, structurally unrelated to either security-hat sense. Most working practitioners distinguish by context without conscious effort; “I work at Red Hat” essentially always means the corporation, “I do red-team work” essentially always means the engagement role, and the disambiguation is rarely needed. The collision is mostly a problem in writing aimed at non-technical executive audiences where the corporate brand is the more familiar referent.

2.4 The Threat-Informed Defense framework and the 2015+ vocabulary stabilization

The vocabulary stabilization point for the modern red-team meaning is MITRE’s public release of the ATT&CK framework in January 20154. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is the canonical adversary-behavior taxonomy — a structured catalog of the techniques real-world threat actors use, organized into tactics (the high-level adversary objectives: initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration, command and control, impact) and techniques (the specific implementations within each tactic: spear-phishing attachment, scheduled-task abuse, LSASS memory dumping, etc.). ATT&CK gave the field a shared vocabulary for talking about adversary behavior; a red-team engagement after 2015 could specify “the engagement will exercise T1003.001 (LSASS memory) for credential access, T1055.012 (process hollowing) for defense evasion, T1078.002 (domain accounts) for persistence” in a way that was simply not possible before.

The Threat-Informed Defense framework, articulated through MITRE’s Center for Threat-Informed Defense (founded 2019; an industry-funded MITRE-operated research center pulling together CrowdStrike, JPMorgan Chase, Microsoft, AttackIQ, Verizon, and many others), formalized the practitioner-language around ATT&CK-driven red-team work5. The framework’s premise — that red-team engagements should emulate specific named threat actors whose TTPs are documented in ATT&CK against the client’s threat model, rather than abstract “generic adversary” work — is the methodological underpinning of modern commercial red-team practice. The 2026 mature red-team engagement is threat-informed: the scoping conversation includes “which threat-actor profile are we emulating?” as a first-order question, and the engagement’s TTP catalog is selected from the named actor’s ATT&CK-documented behaviors.

By 2026 the vocabulary is mature enough to support a 21-volume reference work like this one; the active discussion is at the engagement-structure level (purple-team integration; assumed-breach starting conditions; the role of automated adversary-emulation tooling alongside operator-driven engagement) rather than at the term-meaning level.

TermMeaningOriginTypical 2026 usage
Red team (lowercase, two words)The sanctioned adversary emulator — engagement roleMilitary war-gaming, 1990s commercial migrationJob postings, conference village names (Red Team Village), engagement-vocabulary
Red-team operatorSpecific role; the practitioner running the engagementIndustry coinage, ~2010 onwardStandard job-title pattern
Red-team leadSenior operator; engagement-coordination roleIndustry coinageStandard job-title pattern
Red hatThree meanings (see below); modern primary is the engagement-roleMultiple lineages convergingLess common than “red team” in 2026 usage; appears in some self-identification
Adversary emulationEngagement-objective vocabulary for what red-team work isMITRE / DoD vocabularyThe methodologically-precise term
Adversary simulationSynonym, with slightly different methodology connotationIndustry coinageSome vendors prefer this term for marketing reasons
Offensive security operatorBroader role term, encompassing red-team and other offensive workIndustry coinageCommon job-title pattern
Red Hat (capital, two words)Red Hat Inc., the Linux distribution corporationMarc Ewing’s red lacrosse cap, 1993Unrelated to security taxonomy; corporate brand only
Red hat (vigilante sense)Unauthorized actor attacking unauthorized actorsLate-1990s trade-press, dead by 2026Historical artifact; should not appear in 2026 professional writing

Table 11.1 — Red-team-related vocabulary in 2026 industry usage. The “Red team” and “Red-team operator” rows are the load-bearing primary meanings. The “Red Hat” (capital) row is the corporate-brand disambiguation. The “Red hat (vigilante sense)” row is the historical-artifact disambiguation. The remaining rows are the role-and-engagement-vocabulary that practitioners use in 2026.


3. Tools of the trade

The red-team operator’s toolchain is structured around the C2 framework as the central operational instrument, with a layered set of supporting tools for initial access, Active-Directory attack, lateral movement, persistence, and (where the engagement includes physical entry) RF and HID staging. The section walks each layer with representative tools and the working-context discussion the operator needs to choose between them. Engineering depth on individual tools lives in Vol 16 (computer-hacking tradecraft, pending Phase 3 authoring) and in the cross-tool deep dives the Hack Tools hub carries for the physical-entry layer. This section is the contour map.

A core principle restated from Vol 6 §3, Vol 7 §3, and Vol 10 §3: the red hat, the black hat, and the white-hat pentester all operate on the same hardware and most of the same software. The Beacon implant that a sanctioned red-team operator deploys is the same Beacon code that a cracked-Cobalt-Strike-deploying ransomware affiliate uses. The Mimikatz invocation that a red-team operator runs against an authorized engagement target is the same Mimikatz invocation that a Conti affiliate runs against a compromised production environment. The wire signature is identical; the legal status is opposite. The discriminator is, again, posture and authorization, not gear. Nothing in this section is red-team-exclusive; the same tools appear in Vol 7’s criminal-economy treatment and Vol 6’s white-hat-pentest treatment. The hat is on the operator, not on the device.

3.1 The C2 framework layer — the operator’s central instrument

The Command-and-Control (C2) framework is the heart of modern red-team operations. The C2 framework deploys implants (also called agents, beacons, or payloads depending on the framework’s vocabulary) onto compromised endpoints; the implants check in to a team server (also called the C2 server or the operator controller); the operator drives the engagement through the team server’s interface, issuing commands to implants, receiving results, and orchestrating the multi-host operation. The C2 framework is the engagement’s persistent operational state — it remembers which hosts the engagement has access to, what credentials have been collected, what lateral-movement opportunities exist, and what objectives have been achieved.

The 2026 C2 framework market is structured around two commercial leaders, a growing open-source alternative cluster, and a long tail of legacy and niche frameworks:

  • Cobalt Strike (originally Raphael Mudge / Strategic Cyber LLC, first release 2012; sold to HelpSystems in 2020; HelpSystems rebranded to Fortra in November 2022) is the commercial industry standard. 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. The framework’s commercial pricing has risen over time; as of early 2026 the per-operator-per-year license is approximately $5,9006. Cobalt Strike requires verified-buyer enrollment (corporate identity, payment by company check), which constrains the legitimate user population to commercial security organizations. Cracked copies of Cobalt Strike circulate extensively in the criminal-tool market — the same Beacon code that an authorized red-team operator deploys is the cracked Beacon that ransomware affiliates use, and the EDR detection signatures that catch one catch the other. Vol 6 §3.3 and Vol 7 §3 walked the dual-use treatment.
  • Brute Ratel C4 (Chetan Nayak, Dark Vortex; launched 2020 as a commercial Cobalt-Strike alternative) is the second commercial C2 framework. Nayak founded Dark Vortex in 2020 after working at Mandiant and CrowdStrike (he left CrowdStrike in January 2022 to pursue Brute Ratel development full-time)7; Brute Ratel positions itself as the commercial alternative to Cobalt Strike with a focus on evasion against modern EDR detection. Pricing is approximately $2,500 per operator per year as of early 2026, less than Cobalt Strike. Brute Ratel had a notable operational-security incident in September 2022 when a cracked version appeared in criminal-economy channels, raising the same dual-use concerns the Cobalt Strike ecosystem has long carried. As of 2026 the framework continues active development; the 2.4 “Odyssey” and 2.5 releases (late 2025) extended the badger implant’s evasion capabilities and operator-interface customization.
  • Sliver (Bishop Fox; first public release 2019; Go-based; open-source under GPL-3.0)8 is the open-source-and-growing C2 framework. Sliver’s implant supports C2 over mutual TLS, WireGuard, HTTP(S), and DNS; the agent compiles dynamically per-binary with per-binary asymmetric encryption keys; the cross-platform support (macOS, Windows, Linux server and implant targets) is broader than Cobalt Strike’s. Sliver’s commercial license terms (open-source) and its growing community of contributors have made it the principal open-source alternative for organizations that cannot or will not adopt Cobalt Strike. Bishop Fox’s stewardship of the project — including formal documentation, regular releases, and active security maintenance — distinguishes it from many open-source C2 frameworks that have been dormant for years.
  • Mythic (Cody Thomas / @its-a-feature; open-source; Python + Docker; first public release 2018)9 is the modular-agent open-source C2 framework. Mythic’s architecture is agent-agnostic — the framework provides the operator interface, agent orchestration, and reporting infrastructure, and individual agents (Apollo, Athena, Apfell for macOS, Poseidon, Medusa, and many community-contributed others) are independent projects that plug into the Mythic controller. The modular structure makes Mythic particularly attractive to red-team teams who want to develop custom agents for specific engagement requirements without re-implementing the controller infrastructure. Mythic is the canonical open-source choice for teams with engineering depth to build on top of it.
  • Havoc (open-source; first public release 2022) is the modern open-source C2 with rising adoption. Havoc’s demon implant is positioned similarly to Cobalt Strike’s Beacon (stealthy long-running operator-driven implant); the framework’s UI is comparatively polished for an open-source project. Adoption has grown through 2023-2026.
  • Empire / PowerShell Empire (originally a community project (harmj0y / sixdub lineage); the original repository was archived in 2019; BC Security has maintained Empire (4.x onward) since ~2019, with Starkiller as their web-based GUI frontend) is the historically-influential PowerShell-era C2 that has lost market share to the modern alternatives. Empire still appears in some engagements, particularly where PowerShell-Windows-only execution is the only available channel.

A subsidiary observation worth flagging: the legacy “exploitation framework” tools — Metasploit Framework, Core Impact, Immunity Canvas — sit adjacent to the modern C2 framework category rather than within it. Metasploit’s Meterpreter payload is functionally a C2 implant; the framework’s modular exploit-then-payload-then-post-module structure is operator-driven; the engagement model is short-form-burst (exploit, get shell, do post-exploitation work, move on) rather than the long-form-persistent model the modern C2 frameworks are built around. Metasploit remains in heavy use for short-form work and for the exploit-development side of red-team operations; the modern red-team’s C2 framework runs alongside Metasploit rather than replacing it.

3.2 The Active-Directory attack layer

Modern enterprise red-team work almost always traverses Active Directory or Azure AD / Entra ID. The AD-attack toolchain is its own subdomain with deep specialization:

  • BloodHound (originally Andy Robbins / Will Schroeder / Rohan Vazarkar at Veris Group; first public release 2016; subsequently SpecterOps’s BloodHound CE — Community Edition — since 2022, with BloodHound Enterprise as the commercial-defensive-posture product) uses graph database semantics (Neo4j) to map Active Directory relationships and visualize attack paths from low-privilege footholds to Domain Admin. BloodHound CE is the open-source continuation; BloodHound Enterprise is the commercial defensive product (SpecterOps’s revenue model is the defensive-posture product, with the offensive-side CE as the community baseline). The 2025-2026 BloodHound roadmap has expanded coverage beyond Active Directory to broader identity-platform graph analysis (Azure AD / Entra ID via AzureHound; cloud identity providers via OpenGraph; the 2026 releases support general identity-platform graph modeling). For red-team work, BloodHound is the canonical tool for asking “what’s the shortest path from this user to Domain Admin?” — a question that is brittle to ask of AD’s native interfaces and tractable to ask of a graph database.
  • Mimikatz (Benjamin Delpy, gentilkiwi; French-language development from approximately 2007, widely-circulated English-language public release 2011) is the canonical credential-extraction tool. The 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; kerberos::golden and kerberos::silver produce forged Kerberos tickets. Defensive caveat: Mimikatz is detected by virtually every EDR product. The mature 2026 red-team operator uses Mimikatz with awareness that the invocation will alert — sometimes the engagement objective is to demonstrate the alert (the blue team should catch it), and sometimes the engagement requires alternative credential-extraction techniques (Mimikatz-equivalent functionality via custom code, BOFs running inside the C2 framework’s implant rather than as standalone Mimikatz binaries, or memory-resident credential-extraction techniques that don’t drop the canonical Mimikatz signature).
  • Rubeus (Will Schroeder / SpecterOps) is the canonical Kerberos-attack tool — Kerberoasting (cracking Service-Principal-Name-associated account passwords offline), AS-REP roasting (exploiting accounts with Kerberos preauthentication disabled), unconstrained-delegation abuse, S4U2self / S4U2proxy attacks (constrained-delegation abuse), Golden Ticket / Silver Ticket / Diamond Ticket / Sapphire Ticket forgery. Rubeus’s range of Kerberos-protocol attacks is the working set for the modern AD red-team operator; the tool’s documentation (and Schroeder’s broader Kerberos-attack-research output) is reference material for the field.
  • ADExplorer (Sysinternals / Mark Russinovich, originally; now part of the Sysinternals suite Microsoft acquired) provides passive Active-Directory enumeration — a snapshot-based read-only view of the AD structure that doesn’t generate the kind of authenticated-LDAP-query traffic that BloodHound’s SharpHound ingestor produces. ADExplorer snapshots are a lower-detection-footprint reconnaissance tool that some red-team operators favor for the initial-recon phase against alert-sensitive environments.
  • Impacket (originally Alberto Solino at CORE Security; now community-maintained under Fortra (via the CORE Security acquisition lineage; repository at github.com/fortra/impacket); Python library suite implementing the Windows network protocols) — the canonical Windows-protocol toolkit. psexec.py, secretsdump.py, wmiexec.py, smbexec.py for lateral movement; GetUserSPNs.py for Kerberoasting; GetNPUsers.py for AS-REP roasting; ntlmrelayx.py for NTLM-relay attacks; getTGT.py and getST.py for Kerberos ticket manipulation. The Impacket toolkit is the Python-side AD-attack reference; nearly every AD red-team engagement involves Impacket invocations somewhere.

3.3 The initial-access layer

The initial-access phase — getting code execution on the first compromised host — is increasingly the highest-friction phase of modern red-team engagements as endpoint protection has matured. The working toolchain:

  • Evilginx2 (Kuba Gretzky; open-source, the public canonical fork of the earlier Evilginx) is the canonical MITM phishing framework. Evilginx2 stands up an attacker-controlled reverse-proxy that sits between the victim and the legitimate authentication service (Microsoft 365 login; Okta; Google Workspace; etc.), captures session cookies after successful multi-factor authentication, and lets the operator hijack the authenticated session. Evilginx2 has been the canonical “MFA bypass via session-cookie capture” tool since the 2018 release of the v2 codebase; the engagement-realistic use of Evilginx2 against an authorized client’s authentication infrastructure is one of the more sensitive single tools in the modern red-team kit (the engagement-coordination overhead is substantial because the target users may briefly see attacker-controlled domain content).
  • GoPhish (Jordan Wright; open-source) is the canonical bulk phishing campaign framework — building, launching, tracking, and reporting on phishing campaigns at scale. GoPhish handles the campaign-management side (target lists, email templates, landing pages, click tracking, credential capture) but does not handle the MFA-bypass session-cookie capture that Evilginx2 specializes in; the two are complementary.
  • Social-engineering frameworks — SET (Social-Engineer Toolkit; Dave Kennedy / TrustedSec); the broader social-engineering ecosystem. Less in modern use than Evilginx2 and GoPhish for the campaign-execution work; SET’s pretexting and phishing-template generation remain useful as building-block tools.

The 2026 reality is that initial access has moved further upstream. Direct exploitation of internet-facing services remains a viable initial-access vector (the major 2024-2026 vulnerabilities — Citrix Bleed, Ivanti Connect Secure, MOVEit Transfer, Fortinet VPN, the various ScreenConnect / ConnectWise vulnerabilities, the broader edge-device exploitation pattern) but is less reliably available than the social-engineering-driven access. The mature red-team engagement plans for multiple initial-access vectors and probes which is least-resistance for the specific engagement.

3.4 The lateral-movement and persistence layer

Once initial access is established, the engagement’s persistence and lateral-movement work uses a combination of the C2 framework’s built-in capabilities and adjunct tooling:

  • Impacket’s psexec.py / wmiexec.py / smbexec.py family for code execution on lateral targets via service-installation, WMI invocation, or SMB-named-pipe abuse. The three are the working set for credentialed lateral movement.
  • CrackMapExec / NetExec (NetExec is the actively-maintained fork; the original CME was archived in 2023 due to maintainer-time constraints and reborn as NetExec under new maintainership) for credentialed enumeration and authentication probing across SMB, LDAP, WinRM, RDP, MSSQL, SSH, FTP, and other protocols at scale. NetExec is the canonical tool for “I have credentials; spray them across the network and see what they get me.”
  • WinRM tooling (evil-winrm; the Impacket WinRM utilities) for credentialed remote-PowerShell access.
  • The C2 framework’s own persistence primitives — Cobalt Strike’s staging primitives, Sliver’s persistence modules, Mythic’s per-agent persistence capabilities — for installing the implant in a manner that survives reboot. Persistence capability includes scheduled-task creation (T1053), WMI event-subscription (T1546.003), service installation (T1543.003), Windows registry Run-key modification (T1547.001), and the broader catalog of MITRE ATT&CK persistence techniques. The mature red-team operator selects persistence mechanisms based on the engagement’s detection-posture-test objective: the engagement may want to test specific persistence-detection coverage, in which case the persistence technique is chosen to exercise that coverage.

The C2 framework, the AD attack tools, the initial-access tools, and the lateral-movement-and-persistence tools form an integrated working set. The mature red-team operator carries this entire stack across engagements; the engagement-specific customization is in which tools get used and when, not in the underlying toolkit composition.

3.5 The post-exploitation and data-collection layer

The post-exploitation phase — what the engagement does with the access it has — varies by engagement objective. Common working tools:

  • PowerView (originally Will Schroeder; now part of the broader PowerSploit family) — PowerShell-based AD enumeration. PowerView’s Get-NetUser, Get-NetGroup, Get-NetComputer, Invoke-EnumerateLocalAdmin, and broader enumeration cmdlets are the PowerShell counterpart to BloodHound’s graph queries. PowerView is detected by EDR; the modern alternative is BOFs running inside the C2 framework’s implant.
  • Seatbelt (Will Schroeder / SpecterOps) — Windows enumeration tool focused on host-level recon (installed software, security products, network configuration, user-and-group context, common credential-storage locations). Seatbelt is C# (compiled to a .NET binary or run via in-memory load); the BOF-compatible version runs inside the C2 framework’s implant.
  • SharpHound — the BloodHound ingestor for AD environments. The C# binary executed against a domain-joined host collects the AD relationship data BloodHound needs.
  • Custom data-exfiltration scaffolding — the engagement-specific code that demonstrates the engagement’s objective. If the objective is “exfiltrate the customer-PII database,” the custom code is the database-query-and-transfer logic. The mature red-team operator carries a library of engagement-templates and customizes per-engagement.

3.6 The physical-entry RF/HID staging layer — where Vol 11 connects to the Hack Tools hub

This is where the red-hat volume connects directly to the Hack Tools hub’s RF and physical-security coverage. When a red-team engagement’s scope includes physical-entry or RF components, the same hardware that black-hats use is the same hardware red-hats use — the discriminator is the SOW, not the gear. The substantive working set:

A lock-picking set in working configuration — tension wrenches, single-pin picks, rake picks, and the broader physical-bypass toolkit that supports the red-team's physical-entry layer. Modern red-t…
A lock-picking set in working configuration — tension wrenches, single-pin picks, rake picks, and the broader physical-bypass toolkit that supports the red-team's physical-entry layer. Modern red-team engagements with physical entry in scope frequently include lock-bypass capability alongside the badge-cloning, USB-implant, and Wi-Fi-staging tools. The lock-picking sub-specialty is its own discipline (ALOA / The Open Organization Of Lockpickers / TOOOL community) and is typically a complementary skill to the broader RF and HID toolkit. The lock-picking toolkit shown here is one example; modern red-team operators often carry a more compact engagement-specific subset. Photo: File:Lockpicking-Set.jpg by GeoTrinity. License: CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ALockpicking-Set.jpg).

Figure 11.2 — A lock-picking set: the physical-bypass toolkit that complements the RF and HID staging tools in modern red-team engagements. File:Lockpicking-Set.jpg by GeoTrinity. License: CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ALockpicking-Set.jpg).

  • WiFi Pineapple — rogue-AP staging. WiFi Pineapple (Hak5; Mark VII / Mark VII + AC Tactical / Pager / Enterprise as the four current models, ~$200 to ~$2,500 depending on model). The Pineapple is the engagement-realistic tool for rogue-AP / KARMA-style / evil-twin Wi-Fi attacks against an authorized engagement target. The Pineapple’s twenty-one-volume deep dive in the Hack Tools hub covers the platform at full engineering depth; the Vol 10 §8.5 cross-reference covered the defender’s complement (rogue-AP detection via WIDS, Kismet, or the Pineapple’s own configuration as a defensive instrument). For red-team use, the Pineapple’s role is staging the wireless adversary the blue team is supposed to detect.
  • Flipper Zero — badge cloning + sub-GHz key-fob capture. 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). For red-team work the Flipper consolidates badge-cloning (under authorized engagement scope with the badge population’s consent), key-fob capture, and short-range RF reconnaissance onto a single handheld. The Flipper’s value to red-team engagements is the integration — a single device covers what previously required multiple specialist tools. Vol 15 (RFID, NFC, access control — pending Phase 3 authoring) and the Flipper deep dive treat the engineering depth.
  • Proxmark3 RDV4 — high-frequency RFID/NFC badge research. Proxmark3 RDV4 (DigiKey / Proxmark.org / RfidResearchGroup; ~$300; LF 125 kHz and HF 13.56 MHz operations). When an engagement requires deeper credential-cryptography research than the Flipper handles at higher-level abstraction (iClass, MIFARE DESFire, proprietary credential formats), the Proxmark is the lab-grade tool. The Proxmark deep dive in the Hack Tools hub is aspirational as of early 2026.
  • Hak5 implant family — physical drop and HID injection. Ducky Script and the Hak5 HID family — USB Rubber Ducky, Bash Bunny, Key Croc, and the O.MG Cable/Plug/Adapter family. The Hak5 implants are the physical-entry red-team’s working set for “drop a USB device on the office floor and see what happens when an employee picks it up” engagements, for “plug a keystroke-injection device into the executive’s unlocked workstation” engagements, and for the broader HID-injection / physical-implant tradecraft. The eighteen-volume Ducky Script deep dive (the companion in the Hak5 family to the WiFi Pineapple deep dive) covers the DuckyScript language at 1.0 / 2.0 / 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 deviceVol 14 of the Ducky Script deep dive treats the combined workflow at depth. The Hak5 family is the canonical red-team physical-entry implant family.
  • HackRF One — wideband SDR for RF reconnaissance. HackRF One (Michael Ossmann, Great Scott Gadgets; ~$300; 1 MHz to 6 GHz transmit-and-receive; half-duplex). For red-team engagements that require sub-GHz / 2.4-GHz / cellular-band RF research (assessing the spectrum environment around the target facility; capturing-and-replaying specific protocol traffic for authorized testing; building custom RF payloads), HackRF is the wideband reference. The PortaPack H2+ add-on turns the HackRF into a portable handheld for in-field reconnaissance.

3.7 The substantive tools table

CategoryToolLicense modelApprox 2026 costDetection difficultyCross-reference
C2 frameworkCobalt StrikeCommercial, per-operator~$5,900/yrHighly detected (signatures everywhere); operator stealth depends on Malleable C2 + custom BOFsVol 6 §3.3, Vol 7 §3, this §3.1
C2 frameworkBrute Ratel C4Commercial, per-operator~$2,500/yrModerately detected; positioned for evasionThis §3.1
C2 frameworkSliverOpen-source GPL-3.0FreeGrowing detection coverage; less mature than Cobalt StrikeThis §3.1
C2 frameworkMythicOpen-source BSD-3FreePer-agent detection variesThis §3.1
C2 frameworkHavocOpen-sourceFreeGrowing adoption; growing detectionThis §3.1
C2 frameworkEmpire / StarkillerOpen-sourceFreePowerShell-era detection matureThis §3.1
AD attackBloodHound CEOpen-source Apache-2FreeSharpHound ingestor is detected; ADExplorer alternative for low-footprintThis §3.2
AD attackMimikatzOpen-source CC-BYFreeDetected by virtually every EDR; alternatives needed for stealthThis §3.2
AD attackRubeusOpen-source BSD-3FreeDetected at execution; BOF version for in-implant executionThis §3.2
AD attackImpacketOpen-source Apache-1.1FreeNetwork-side signatures vary; widely detectedThis §3.2
Initial accessEvilginx2Open-source BSD-3FreeDomain-level; defender countermeasures include FIDO2 hardware keysThis §3.3
Initial accessGoPhishOpen-source MITFreeDomain-level; defender countermeasures via DMARC/DKIM/SPFThis §3.3
Lateral movementNetExec / CrackMapExecOpen-source BSD-2FreeNetwork-side signatures; authentication-spike detectionThis §3.4
Lateral movementImpacket lateral toolsetOpen-source Apache-1.1Freepsexec.py / wmiexec.py / smbexec.py heavily detectedThis §3.4
Post-exploitationSeatbeltOpen-source BSD-3FreeBOF version for in-implant execution; .NET standalone detectedThis §3.5
Post-exploitationPowerViewOpen-source GPL-3.0FreePowerShell-era detection matureThis §3.5
Physical RFWiFi PineappleCommercial Hak5$200-$2,500WIDS detection; specific Pineapple signatures knownPineapple deep dive; this §3.6
Physical RFFlipper ZeroCommercial Flipper Devices~$170Short-range; physical-proximity detectionFlipper deep dive; this §3.6
Physical RFIDProxmark3 RDV4Commercial RRG~$300Physical-proximity detectionthis §3.6
Physical HIDHak5 Rubber Ducky / Bash Bunny / Key Croc / O.MGCommercial Hak5~$80-$200 eachPhysical-handling detection; HID-enumeration alerts on some EDRDucky Script deep dive; this §3.6
SDRHackRF OneCommercial Great Scott Gadgets~$300Passive RX is undetectable; TX is range-detectedHackRF deep dive; this §3.6

Table 11.2 — The red-team operator’s toolchain working set, organized by category. Cost figures are early-2026 reference points. Detection difficulty is a working estimate; specific engagement-time detection coverage depends on the target’s EDR, network monitoring, and detection-engineering maturity. The cross-references point into the Hack Tools hub deep dives (Pineapple, Flipper, Ducky Script, HackRF) and to the relevant §3 subsections of this volume. None of these tools is red-team-exclusive — the discriminator is authorization, not gear.

3.8 A representative ATT&CK technique reference and an Aggressor Script snippet

To ground the abstract toolchain discussion: a concrete example of how a modern red-team operator references the MITRE ATT&CK technique catalog in engagement planning and Cobalt Strike’s Aggressor Script in engagement execution.

The ATT&CK technique reference for LSASS credential extraction (Vol 10 §3.1’s defensive complement):

Tactic:       TA0006 — Credential Access
Technique:    T1003.001 — OS Credential Dumping: LSASS Memory
Description:  Adversaries dump credentials from LSASS process memory via
              tools like Mimikatz, ProcDump, Task Manager (right-click
              "Create Dump File"), comsvcs.dll MiniDump, or in-implant
              memory-read techniques.
Detection:    Process-access events to lsass.exe with PROCESS_VM_READ +
              PROCESS_QUERY_INFORMATION access masks (Vol 10 §3.1 Sigma
              rule). Sysmon EventID 10 is the primary telemetry source.
Mitigation:   Credential Guard (Windows 10+), LSA Protected Process Light
              (LSA-PPL), restricted SeDebugPrivilege, EDR detection rules.
Engagement use:  Demonstrate credential-extraction capability for the
                 engagement's credential-access objective; expect the blue
                 team to detect (the detection rule is canonical).

The 2026 mature red-team engagement plan references ATT&CK technique IDs throughout — the scoping conversation says “we will exercise T1003.001 for credential access, T1059.001 for execution, T1055 for defense evasion, T1078.002 for lateral movement,” and the engagement’s deliverable maps the exercised techniques onto the ATT&CK Navigator visualization showing what was tried and what the blue team caught.

A representative Cobalt Strike Aggressor Script snippet (capability-level, not operational):

# Aggressor Script — illustrative example of operator workflow customization
# Aggressor Script is Cobalt Strike's scripting language for extending the
# client UI, defining keyboard shortcuts, adding custom commands, and
# integrating with external tooling. This snippet adds a "shortcut" alias
# that runs a recurring host-enumeration BOF and exports the results
# to the operator's engagement-notes file.

alias host-recon {
    local('$bid $note');
    $bid = $1;
    blog($bid, "Running host-recon BOF (engagement enumeration sweep)");
    # bof_seatbelt is a BOF wrapper around Seatbelt's enumeration
    # checks; the BOF runs inside the Beacon implant context rather
    # than as a standalone .NET binary (lower detection surface).
    bof_seatbelt($bid, "AllChecks");
    # bnote sets a per-Beacon note that the operator UI displays
    # in the Beacon list — useful for engagement-tracking.
    $note = "Host-recon completed " . formatDate("yyyy-MM-dd HH:mm:ss");
    bnote($bid, $note);
}

# Bind the alias to an operator-keyboard shortcut for quick invocation
# during engagement work.
bind beacon_top "Ctrl+R" {
    host-recon($1);
}

The snippet illustrates the engagement-customization the modern red-team operator routinely builds on top of the base framework. Aggressor Script is the Cobalt Strike-specific scripting language; Sliver has its own armory (extension catalog) and Lua-script extensions; Mythic has per-agent Python customization; the underlying point is that the modern C2 framework is programmable, and the mature operator builds engagement-specific workflows on top of it.


4. Methods and tradecraft — the engagement lifecycle

A red-team engagement is structured. Like the pentest engagement Vol 6 §4 walked, the red-team engagement has a defined start, defined intermediate phases, and a defined end. The shape is different from the pentest — longer duration, narrower objective, narrative-of-compromise deliverable — but the structural rigor is the same.

4.1 The engagement lifecycle in one diagram

                        PRE-ENGAGEMENT                                                    ENGAGEMENT (6-12 weeks typical)                                                       POST-ENGAGEMENT
   ┌───────────────────────────────────────────────────────────┐    ┌───────────────────────────────────────────────────────────────────────────────────────────────┐    ┌────────────────────────────────────────┐
   │                                                           │    │                                                                                               │    │                                        │
   │  SCOPING ─► THREAT-ACTOR ─► SOW ─► SCOPE ─► ROE ─► TIER   │    │  RECON ──► INITIAL ──► FOOTHOLD ──► PRIVILEGE ──► LATERAL ──► PERSISTENCE ──► OBJECTIVE  │    │  ENGAGEMENT REPORT ─► PRESENT ─► PURPLE  │
   │            PROFILE                       (W/G/B)          │    │   │       ACCESS    ESTABLISHED   ESCALATION   MOVEMENT                       ACHIEVEMENT   │    │   ↓                                ↓     │
   │     ▼                                            ▼        │    │   │                                                                                          │    │  Narrative + ATT&CK Navigator      │     │
   │  Adversary emulation                 Deconfliction        │    │   │                                                                                          │    │  + detection-gap analysis +        │     │
   │  scenario (APT29 /                   contact + GOJL       │    │   │                                                                                          │    │  remediation prioritization        │     │
   │  Conti / FIN7 / etc.)                                     │    │   │                                                                                          │    │                                    ▼     │
   │                                                           │    │   │                                                                                          │    │  Detection-engineering              │     │
   │  Authorization envelope                                   │    │   │                            CLEANUP (uninstall implants, remove                            │    │  collaboration: failed-detection-   │     │
   │  established + transparency tier set                      │    │   │                              persistence, restore environment) ◄───────────────────────────┤   │  to-Sigma-rule conversion           │     │
   │                                                           │    │   │                                                                                          │    │                                          │
   └───────────────────────────────────────────────────────────┘    │   │                                                                                          │    └────────────────────────────────────────┘
                                                                    │   ▼                                                                                          │
                                                                    │  CONTINUOUS DECONFLICTION with engagement coordinator                                        │
                                                                    │  (escalation when blue-team response approaches real cost)                                   │
                                                                    │                                                                                              │
                                                                    └──────────────────────────────────────────────────────────────────────────────────────────────┘

Figure 11.3 — The red-team engagement lifecycle. Pre-engagement (scoping → threat-actor profile selection → SOW → scope document → ROE → transparency tier) establishes the authorization envelope and the engagement design. The engagement itself (recon → initial access → foothold → privilege escalation → lateral movement → persistence → objective achievement → cleanup) is the multi-week technical work; the engagement runs against a defined kill-chain progression with the threat-actor profile as the methodological frame. Continuous deconfliction with the engagement coordinator runs throughout. Post-engagement (report → presentation → purple-team handoff) delivers the narrative-of-compromise plus the ATT&CK Navigator layer plus the detection-gap analysis, with the rising-in-2026 purple-team handoff converting failed-detection findings into Sigma rules that close the gap.

4.2 Threat-informed scenario design — picking the adversary to emulate

The engagement-planning conversation that distinguishes a red-team engagement from a pentest is the threat-actor profile selection. The conversation typically opens “Which adversary do we want to test against?” and proceeds through:

  • Client threat model. What threat actors are plausibly targeting the client? A regional bank in the US Midwest faces FIN7 / Conti-affiliate / various ransomware-as-a-service operators as the modal threat; a defense contractor faces APT28 / APT29 / Volt Typhoon / Mint Sandstorm-class nation-state actors; a healthcare provider faces ransomware operators plus the rising healthcare-vertical-focused nation-state interest; a critical-infrastructure utility faces Sandworm-class operators alongside ransomware. The threat model is the input to the actor-selection conversation.
  • Public TTP documentation. The selected threat actor must have documented TTPs — the public reporting from threat-intelligence firms (Mandiant, CrowdStrike, Microsoft MSTIC, Recorded Future, Trellix), the MITRE ATT&CK group mappings (each major threat actor has an ATT&CK Group page listing the techniques the group is documented to use), the academic literature, and the broader threat-intelligence community’s coverage. The engagement’s TTP catalog is drawn from this documentation.
  • Engagement scope match. The threat actor’s documented TTPs must map onto the engagement’s scope. A threat actor whose documented TTPs are heavily cellular-network-focused (Salt Typhoon-class operations) is hard to emulate in an engagement scoped to enterprise IT only; the engagement scope needs to extend to where the actor operates, or a different actor needs to be selected.
  • Capability honesty. The emulating team must have or be able to develop the capability to execute the threat actor’s TTPs. A small red-team consultancy emulating Equation Group’s documented capabilities is going to fail to be convincing; the emulation has to be honest about what the team can and cannot execute. The mature engagement-design conversation includes the team’s capability inventory.

Common adversary-emulation choices in 2026 enterprise red-team engagements:

  • APT29 / Cozy Bear / Midnight Blizzard (Russia-aligned; Russian SVR; the SolarWinds / Hafnium / Midnight Blizzard / many other operations; characteristic emphasis on stealth, long persistence, supply-chain compromise) — common emulation choice for financial services, government contractors, and tech firms with cross-border operations.
  • APT28 / Fancy Bear / Forest Blizzard (Russia-aligned; Russian GRU Unit 26165; the DNC hack, the Olympic Destroyer, and many others; characteristic emphasis on credential phishing, password spraying, and platform-specific zero-day exploitation) — common emulation for political organizations, defense contractors, and high-profile public figures.
  • FIN7 (financial-crime-focused; documented to use spear-phishing → Carbanak / Bateleur / BlackMatter-adjacent capabilities → POS / payment-processing-environment compromise; the canonical commercial-financial-crime emulation choice for retail and hospitality clients).
  • Conti / Black Basta / RaaS-affiliate (ransomware-as-a-service affiliate emulation; documented Cobalt Strike / Brute Ratel C4 deployments; characteristic emphasis on rapid lateral movement, AD compromise, large-scale data exfiltration before encryption; common emulation for any enterprise that’s a plausible ransomware target — which is most of them).
  • Volt Typhoon / Mint Sandstorm / industrial-targeting nation-state (China-aligned Volt Typhoon’s documented critical-infrastructure pre-positioning; Iran-aligned Mint Sandstorm’s various ICS-and-OT-adjacent operations; the broader industrial-targeting nation-state landscape) — emulation choice for critical-infrastructure utilities and industrial operators.

4.3 The MITRE ATT&CK framework as the engagement’s structural backbone

The MITRE ATT&CK framework is the operational substrate of modern red-team engagements. The framework’s organization — 14 tactics (TA0001-TA0043, with some skipped numbers) each comprising tens to hundreds of techniques — provides the vocabulary for talking about what the engagement will exercise. The engagement-planning ATT&CK Navigator layer is a JSON document specifying which techniques the engagement intends to exercise, color-coded by priority and source-attribution; the post-engagement ATT&CK Navigator layer shows which of the planned techniques the engagement actually exercised and which the blue team caught.

The Navigator’s three-color convention common in 2026 engagements:

  • Green — technique exercised and the blue team detected. Detection coverage validated.
  • Yellow — technique exercised and the blue team detected partially (alerted but did not escalate; alerted but the alert was dismissed; alerted on a related technique but not the specific one).
  • Red — technique exercised and the blue team did not detect. The detection-gap findings — the engagement’s most actionable single deliverable. Each red technique becomes a detection-engineering work item.

The post-engagement Navigator layer is the artifact that the detection-engineering team (Vol 10 §3.5) takes as input for the next-sprint detection-rule authoring work. The purple-team integration practice (Vol 12) makes this loop explicit and continuous; the modal 2026 engagement makes it deliberate-after-the-fact.

4.4 Long-form persistent operations — the “assumed breach” starting condition

A consequential distinction between red-team engagements and pentests is the assumed-breach starting condition. A pentest typically starts from external recon — the engagement assumes the attacker has no foothold and works to establish one. A red-team engagement frequently starts from an assumed-breach condition — the engagement scope says “Day 1, the operator has the access an APT29-equivalent operator would have after Week 1 of their actual campaign.” The assumed-breach condition is given; the engagement work focuses on what happens after initial access.

The rationale for assumed-breach is compression. The actual initial-access phase of a real APT campaign takes weeks (target reconnaissance, spear-phishing campaign, payload-development iteration, victim engagement). A six-week red-team engagement that spent the first four weeks trying to land initial access would have two weeks left for the post-access work — which is where the engagement’s value lies, because the post-access detection-coverage assessment is what the client most wants to test. Assumed-breach gives the engagement the time-budget to do the work that matters.

The assumed-breach starting condition is scoped explicitly in the engagement design. Common starting conditions:

  • Phishing-success assumed. The engagement starts with a deployed C2 implant on an arbitrary user-population endpoint, as if the user had clicked a phishing-payload that succeeded.
  • Insider-credential assumed. The engagement starts with an arbitrary user-population credential set (a username and password for a typical employee account), as if the credential had been acquired via prior phishing or third-party-breach data.
  • Insider-physical assumed. The engagement starts with physical access to a user-population workstation, as if the operator had social-engineered physical entry past reception.
  • Supply-chain assumed. The engagement starts with code execution on a build-pipeline server, as if a SolarWinds-style supply-chain compromise had succeeded.

The starting-condition specification is part of the engagement scope document. Each starting condition produces a different engagement shape; the engagement coordinator selects the condition that best matches the threat-actor profile.

4.5 Pentest vs. Red Team vs. Black Hat — the three-axis comparison

The structural comparison across the three engagement modes:

AxisPentest (Vol 6)Red Team (this volume)Black Hat (Vol 7)
AuthorizationYes — SOW + scope + ROE + GOJLYes — SOW + scope + ROE + GOJL (often broader scope, transparency-tier specified)No — unauthorized access regardless of attacker’s purported justification
ObjectiveExhaustive vulnerability discovery within scopeSpecific scenario demonstration (“Could threat-actor-X succeed?”) via threat-actor TTP emulationAdversary’s own objective (financial, espionage, ideological, sabotage)
DurationDays to weeks (typical 5 days externally, 2-4 weeks internally)Weeks to months (typical 6-12 weeks; sometimes continuous)Adversary’s own timeline (weeks to years; APT campaigns multi-year)
DeliverableVulnerability list with severity ratings + remediation guidanceNarrative of compromise + ATT&CK Navigator layer + detection-gap analysisNone to client; impact realized as ransom payment / data theft / disruption
Starting conditionExternal recon typicallyAssumed-breach commonly; external recon sometimesReal-world initial-access activity (phishing, exploitation, supply-chain)
TransparencyEngineering team typically awareWhite/grey/black-box tiers (grey-box modal)None — defender is unaware
CleanupRequired; implants removed, environment restoredRequired; implants removed, environment restoredNone — adversary maintains or destroys access per objective
Wire signatureSame tooling, same techniques as red-team and black-hatSame tooling, same techniques as pentest and black-hatSame tooling, same techniques as pentest and red-team
Legal statusAuthorizedAuthorizedUnauthorized (CFAA, CMA, equivalents)
Discriminator from black-hatAuthorization stackAuthorization stackNone — defining condition of the role

Table 11.3 — The three-axis comparison: pentest vs. red-team vs. black-hat. The pentest and the red-team are siblings on the authorization axis (both signed SOWs); the pentest and the black-hat differ on the same axis (one signed SOW; the other not). The red-team and the black-hat differ only on authorization — the technique catalog, the wire signature, the tooling, and substantially the day-to-day operational rhythm are all identical between the two; the difference is the legal-and-ethical envelope around the work. This is the load-bearing point of §1’s “the red team is not the black hat” callout. NIST SP 800-115 provides the federal-framework vocabulary that commercial work largely follows.10

4.6 The engagement-coordination function and deconfliction

A specific operational function that distinguishes red-team engagements from pentests is the engagement coordinator — the senior individual on the testing-firm side (or, for in-house red-teams, the embedded program-management function) who manages the engagement’s day-to-day deconfliction with the client. The coordinator’s responsibilities:

  • The deconfliction call channel. The coordinator maintains a private communication channel (signal, dedicated phone line, encrypted email) with the client’s named deconfliction contact (typically the CISO or the head of security operations, plus their designated alternate). The channel is for “the SOC has detected your engagement and is escalating; do we tip them or let them proceed?” decisions and for “we just accidentally tripped a brittle production system; please help us coordinate the incident-response” decisions.
  • The engagement coordinator’s go/no-go authority. The coordinator has the authority to pause or terminate the engagement when the engagement’s risk profile exceeds the ROE’s bounds. The authority is structural — the coordinator’s seniority within the testing firm is high enough that the operator cannot override the coordinator’s decision. Senior coordinators have terminated engagements mid-engagement when the operator’s activity was about to cause real harm; the discipline is to do so deliberately rather than reflexively.
  • The end-of-engagement debrief coordination. The coordinator owns the post-engagement transition — scheduling the client debrief, coordinating the report delivery, managing the purple-team handoff (Vol 12 / §4.7 below).

The coordinator function is what makes red-team work engagement work rather than one-person-operator work. A solo operator without a coordinator is exposed to single-points-of-failure (an arrest during physical entry, a critical-incident escalation during off-hours, a deconfliction decision the operator is too close to make objectively). The coordinator’s presence is the structural feature that makes red-team work a team activity even when the operator is working solo on the technical engagement.

4.7 The purple-team transition — when the engagement loop closes

The rising 2026 pattern in mature enterprise red-team engagements is the purple-team transition — the post-engagement workflow where the red-team’s documented findings (the detection-gap items from the ATT&CK Navigator layer) become inputs to the blue-team’s detection-engineering work, with the red-team and blue-team collaborating on the detection-rule authoring to close each gap. The transition has three working modes:

  • Sequential. The red-team engagement completes; the report is delivered; some time later (weeks to months), the detection-engineering team picks up the findings and builds detections. The transition is real but slow; the institutional memory of the engagement may have faded by the time the detection work begins.
  • Continuous. The red-team engagement runs alongside an ongoing blue-team detection-engineering function; the engagement’s findings become weekly work-items for the detection team during the engagement. The transition is faster but requires the blue team to be aware of the engagement (grey-box or white-box transparency tier).
  • Integrated (the purple-team practice). The red-team and blue-team operate as a single feedback loop, with the red-team’s TTP execution and the blue-team’s detection-rule authoring happening in deliberate alternation. The engagement model is exercise-as-collaboration rather than exercise-as-adversary-emulation; Vol 12 will treat the practice at full depth.

The purple-team transition is where the red-team engagement’s value is operationally realized. An engagement that produces a beautiful narrative of compromise but does not feed back into the detection-engineering pipeline has produced an artifact, not an improvement. The mature 2026 engagement-program treats the purple-team transition as the engagement’s actual deliverable, with the report and the Navigator layer as supporting artifacts.

4.8 The Hak5 implant workflow — physical-entry red-team operations

When the engagement scope includes physical-entry, the Hak5 implant workflow (cross-link to Ducky Script deep dive §14 for the combined-workflow treatment11) is the canonical working pattern. The workflow has three structural phases:

Identifying physical-access vectors. The pre-engagement reconnaissance identifies where physical access is plausible. Common vectors: the public-facing lobby with reception (tailgating, badge clone of the receptionist, lost-USB-drop near the entrance); the parking lot (lost-USB-drop near employee parking; vehicle-mounted Wi-Fi staging from a parked car); the loading dock (delivery-personnel pretext); the executive-assistant area (after-hours pretext); the shared-tenant building common areas (shared-lobby reception, shared-restrooms). Each vector has a different engagement-risk profile and a different vetting requirement.

Deploying implants. The implant deployment is the moment of actual physical risk. A “lost USB” pretext drops a Bash Bunny or USB Rubber Ducky in the parking lot or near the entrance, where a curious employee picks it up and plugs it in; an O.MG Cable replaces a real cable in the executive-assistant area, where the cable’s HID-injection payload runs the next time the executive plugs in a phone or peripheral; a Key Croc replaces or supplements a keyboard, with the inline keylogger capturing all keystrokes for retrieval. The implant deployment is the engagement’s most-watched single moment — the operator is on-camera, on-site, with the implant in hand, and the GOJL needs to be in the operator’s pocket in case challenged.

Retrieving data. Some implants exfiltrate over their own out-of-band channel (the O.MG Cable’s Wi-Fi C2; the Bash Bunny’s USB-storage exfiltration that requires re-acquisition); some require physical retrieval (the Key Croc’s stored keystrokes; the implant-as-evidence retrieval). The retrieval pass is the engagement’s second moment of physical risk and the engagement’s actual data-collection moment.

This is treated at capability level here — the engagement-realistic operational walkthrough is in Vol 14 of the Ducky Script deep dive, which has the operational depth the Hak5 family deserves and the legal-posture detail the field requires.


5. A day in the life

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

5.1 Engagement Day 12 of a 6-week red-team operation

7:00 AM. The operator — call him David — is at his desk in his home office with coffee, opening his laptop. He’s twelve days into a six-week red-team engagement against a Fortune-1000 financial-services client. The engagement is grey-box: the CISO and the head of detection-engineering know the engagement is running; the SOC and the broader security organization do not. The engagement’s adversary-emulation profile is “Conti-affiliate-class operator” — ransomware-affiliate TTPs, with the engagement objective “exfiltrate a copy of the customer-PII production database within six weeks without being detected.”

David’s morning routine is the engagement check-in. He opens his C2 framework (Cobalt Strike, in this engagement; the client’s vendor relationship covers it) and reviews the overnight Beacon callbacks. Seven Beacons checked in over the night — five on the user-workstation segment David established access to during Week 1, one on the application-server segment David moved laterally to during Week 2, and one on the database-tier segment David accessed yesterday for the first time. The database-tier Beacon is the most-consequential single asset of the engagement — it’s the proximity to the customer-PII database that the engagement objective targets.

8:00 AM. David’s day’s plan: continue the database-tier reconnaissance to find the specific PII-store location, prepare the data-exfiltration scaffolding, and begin the exfiltration in small chunks over a slow timeline to avoid bandwidth-detection. He opens his engagement notes (a Cherrytree document with per-day entries; the firm’s standard format) and reviews yesterday’s progress.

9:00 AM. The team’s standing morning call: David, his engagement lead (the senior operator coordinating the engagement; call her Aisha), and the engagement coordinator (a separate senior individual managing the client-side deconfliction; call him Marcus). The call is 30 minutes — David walks through yesterday’s work, discusses today’s plan, and surfaces decisions the team needs to make. Today’s decision: the database-tier Beacon’s exfiltration channel. David has identified that the database-tier segment has restricted outbound network access — direct C2 to the operator’s external infrastructure isn’t possible. The options are (a) tunnel the exfiltration through the user-workstation segment David already controls (slower, more hops, more chances to be detected); (b) use the engagement’s WireGuard pivot Beacon mode to establish a more-direct route (cleaner, but tips the engagement if the WireGuard tunnel pattern is detected); (c) abandon the database-tier work and try a different angle. The team picks option (a) — the slower path with the established access.

10:00 AM. David begins the database-tier reconnaissance. The Beacon’s local-enumeration BOF runs first — what’s on the host, what’s installed, what credentials are cached. The host is a database administration jumpbox; it has SQL Server Management Studio installed; the operator who logged in last left credentials in a .config file in his profile. David exfiltrates the credentials, queries them through the user-workstation pivot, and confirms they grant database-tier query access.

12:00 PM. Lunch break. David walks away from the keyboard for thirty minutes. The discipline of stepping away during a long-form engagement is real — the engagement’s cognitive load is high, and operator-error increases when the operator is tired or focused too long.

12:30 PM. David returns to the engagement work. He spends the afternoon constructing the data-exfiltration scaffolding — a custom PowerShell module that queries the customer-PII table in chunks, encrypts each chunk with the engagement’s per-engagement key, and stages each chunk in a file on the database-tier jumpbox. The exfiltration timing is over the next two engagement days — slow enough that bandwidth-detection doesn’t trigger.

4:00 PM. David updates the engagement journal — a Cherrytree document that the engagement team uses to track all engagement activity for the eventual report. The journal entry for today: the database-tier reconnaissance, the credential discovery, the exfiltration scaffolding construction, the planned exfiltration timeline. Every command, every file path, every captured screenshot, every credential — logged. The discipline is that the report depends on this; the operator’s defense if anything goes wrong also depends on this.

5:00 PM. End of engagement day. David closes the C2 client (the team server runs continuously; the operator’s individual client disconnects), checks his Beacons are queued for overnight check-in, and walks away. Tomorrow’s plan is to begin the actual exfiltration runs.

5.2 A physical-entry day during an authorized engagement

6:30 AM. The operator — call her Mei — is in a parking lot two blocks from a client’s headquarters. The engagement is a separate red-team engagement from David’s; the client is a regional bank. The scope includes a physical-entry component that Mei is executing this morning. The engagement’s GOJL is in Mei’s jacket pocket, signed by the bank’s Chief Security Officer, with the CSO’s mobile number and the firm’s engagement-coordinator’s mobile number on the bottom. Mei has a folder with the engagement scope document, the ROE specifying the physical-entry techniques permitted (tailgating yes; impersonation of law enforcement no; lock-picking yes for unlocked-look doors; destructive entry no), and her firm’s business cards.

7:00 AM. Mei walks toward the building. The plan: “lost USB” pretext drop in the parking lot near the employee entrance. The pretext is that an arriving employee will see the USB on the ground, pick it up, and plug it into their workstation when they get inside. The USB is a Hak5 Bash Bunny, configured to enumerate as a HID device, drop a payload that establishes a C2 callback to the engagement’s external infrastructure, and immediately delete the staging files. The Bash Bunny is also configured to not deploy if the host is a personal device (filtering for the bank’s standard corporate-image software stack) — the engagement is specifically scoped to the bank’s environment.

7:15 AM. Mei drops the Bash Bunny in the parking lot near the employee entrance, where the morning arrivals will see it. She walks back to her parked car (two blocks away, out of camera view), drinks coffee, and waits. The engagement-coordinator (Marcus, same engagement-coordinator role as in §5.1) is reachable on Signal if anything comes up.

8:30 AM. The C2 callback arrives. An employee picked up the Bash Bunny, plugged it into their workstation, and the payload deployed. Mei pushes a brief acknowledgment notification to Marcus and to her engagement lead — “callback received, exfiltration scaffolding running on victim host.” The engagement’s user-workstation foothold is established.

9:30 AM. Mei executes the second half of the morning plan: tailgating entry through the same employee entrance. The pretext is that she’s a vendor visiting for a meeting; her business cards establish the cover story; her cover identity has been pre-arranged with the engagement coordinator. She enters the building behind a group of three arriving employees, none of whom challenge her. She walks to the second floor (the executive-assistant area, per the engagement scope) and conducts a brief social-engineering pass — handing a business card to the executive assistant of one of the bank’s senior officers, with a pretext about a vendor meeting that was supposedly scheduled. The pretext fails (the executive assistant has no record of the meeting, doesn’t have the meeting listed in the officer’s calendar, asks Mei to wait at reception). The engagement scope said “test the executive-area tailgating and challenge-response; failure to advance is itself a successful test”; Mei thanks the assistant, walks back to reception, and leaves the building.

10:30 AM. Mei is back in her car, debriefing with Marcus over Signal. The morning’s work: one successful Bash Bunny drop (engagement objective achieved at the workstation tier); one successful tailgating entry (engagement objective partially achieved — entry succeeded but the executive-area progression was challenged). Marcus updates the client-side deconfliction contact (“our engagement entered the lobby this morning; the executive-area challenge response worked correctly”). The engagement coordinator’s documentation captures the morning’s work for the eventual report.

11:00 AM. Mei drives back to the firm’s office for the afternoon’s debrief. The engagement’s physical-entry component is largely complete; the next phase shifts to the C2 work that the Bash Bunny established.

5.3 Post-engagement debrief week — the report and purple-team handoff

Week 7 of the same engagement David has been running. The engagement’s six weeks of active operations completed last Friday; this week is the report-writing and purple-team handoff. David and the engagement lead (Aisha) are working in the firm’s reporting tool (a Markdown-based collaborative authoring environment that renders to the firm’s branded PDF template).

Monday-Tuesday: the technical write-up. Each day’s engagement work from the engagement journal is converted to the report’s narrative-of-compromise structure. The narrative is chronological — Week 1 initial access, Week 2 lateral movement, Week 3 privilege escalation, Week 4 database-tier access, Week 5 exfiltration scaffolding, Week 6 staged exfiltration. Each section has screenshots, captured commands, captured network traffic, and the ATT&CK technique IDs that were exercised.

Wednesday: the ATT&CK Navigator layer. Aisha builds the post-engagement Navigator layer — color-coding each exercised technique green (detected) / yellow (partially detected) / red (not detected). The red-colored techniques are the engagement’s detection-gap findings. There are 14 red techniques in this engagement — 14 cases where David exercised an ATT&CK technique and the blue team did not detect it. Each becomes a detection-engineering work item.

Thursday: the executive summary. The executive summary is two pages aimed at the client’s CISO, CFO, board members. The narrative is non-technical — what was tested, what succeeded, what failed, what the business risk is, what the recommended remediation priorities are. The executive summary is the only thing many of the readers will read; it has to stand alone.

Friday: the client presentation. The engagement lead Aisha walks the client’s CISO, head of detection-engineering, and head of incident-response through the report findings. The 90-minute presentation covers the executive summary, the high-severity detection-gap findings, the recommended remediation priorities, and the purple-team transition plan. The purple-team transition is the conversation about what happens next — the firm’s detection-engineering team will collaborate with the client’s detection-engineering team across the next four weeks to build Sigma rules for the 14 red-colored techniques and validate the rules against the blue team’s SIEM. The transition is the engagement’s actual deliverable from the client’s perspective; the report is the document that the transition rests on.

Next two weeks: the purple-team handoff. David is rotated off the engagement; a separate firm consultant (a senior detection engineer) joins the conversation; the client’s detection engineering team’s two senior engineers join. The four-person purple-team works through the 14 detection-gap findings one at a time, building Sigma rules, validating them, deploying them, confirming the next-engagement exercise of the same technique catches the alert. Each closed gap is documented; the engagement’s final supplementary deliverable is the purple-team handoff completion report.


6. How they get hired

The red-team career path is structured. Unlike pentest (Vol 6 §6) which has both an external-consulting and a bug-bounty path, and unlike blue-team (Vol 10 §6) which has an entry-level on-ramp through SOC tier-1 work, the red-team path is more uniformly professional-track — entry-level red-team positions exist but are rare; the modal path is pentest practitioner → red-team operator. The career cert ladder, the typical progression, the specialization paths, and the Hak5 physical-implant operator sub-track are walked below.

6.1 The red-team cert ladder

The certification landscape for red-team work has matured significantly since approximately 2020 when Zero-Point Security’s CRTO course began to define the role-specific cert for red-team operations:

CertificationIssuing organizationApproximate cost (2026)FocusCareer stage
CRTO — Certified Red Team OperatorZero-Point Security (Daniel Duggan)12~$500 (course + 4-month lab + exam attempt)Cobalt Strike operations + AD attack + the engagement-realistic red-team workflowMid-level — the canonical red-team-specific cert
CRTP — Certified Red Team ProfessionalPentester Academy / Altered Security13~$300Active Directory attack specializationMid-level — the canonical AD-red-team cert
CRTE — Certified Red Team ExpertAltered Security (next step from CRTP)~$500Advanced AD attack including forest attacksSenior — depth specialization
OSEP — OffSec Experienced Penetration Tester (PEN-300)Offensive Security14~$2,500Evasion techniques + advanced post-exploitationSenior — depth and evasion
OSCE3 — OffSec Certified Expert (OSEP + OSED + OSWE)Offensive SecurityPer-cert (~$2,500 each)Combined red-team / web-app / exploit-developmentSenior — combined-domain specialization
CRTL — Certified Red Team LeadZero-Point Security15~$1,200 (course + lab + exam)Red-team leadership + engagement-coordination + program managementSenior — leadership track
GIAC GPEN — Penetration TesterSANS GIAC16~$2,000 (cert only); SANS SEC560 course ~$8,000Network pentest fundamentalsEntry-to-mid — broad pentest baseline
GIAC GXPN — Exploit Researcher and Advanced Penetration TesterSANS GIAC~$2,000 (cert only); SANS SEC660 course ~$8,000Advanced exploitation including custom exploit-developmentSenior — depth specialization
GIAC GRTP — Red Team ProfessionalSANS GIAC (newer cert; launched ~2023)~$2,000Adversary emulation methodology and threat-informed defenseMid-to-senior — the SANS-track red-team cert
CEH — Certified Ethical HackerEC-Council~$1,200Multiple-choice exam covering broad ethical-hacking conceptsEntry-level; widely considered weaker than practical alternatives

Table 11.4 — The red-team cert ladder, with approximate 2026 costs. The CRTO is the role-specific canonical cert; the CRTP/CRTE are the AD-specialization track; the OSEP/OSCE3 cluster is the OffSec advanced track; the CRTL is the leadership track. The GIAC family is the SANS-formal track; the CEH is the entry-level broad-strokes cert (with the caveat that practical-exam-based alternatives are widely considered stronger in the working-practitioner population). The cost figures are early-2026 reference points; specific course costs are checked against the issuing organization’s current site.

6.2 The typical progression from pentest to red-team

The modal career path: 3-5 years pentest → red-team operator → red-team lead → red-team program manager. The transitions are gradual and overlap; a working consultant doesn’t transition cleanly from “pentester” to “red-team operator” on a specific date but rather accumulates engagement experience that becomes increasingly red-team-shaped over time.

Typical progression milestones:

Year 0-2: Entry pentest associate / consultant. The early-career consultant runs externally-scoped pentest engagements under senior supervision. Engagement structure is days-to-weeks; the work is breadth-first vulnerability discovery; the deliverable is the standard pentest report. The cert profile is OSCP plus the firm’s internal credential structure.

Year 2-4: Senior pentest consultant. The senior pentester runs engagements independently, leads engagements with junior consultants, and begins to take on longer-form engagements where the work shape starts to look red-team-adjacent. The cert profile adds CRTP (AD specialization) and possibly OSEP (the next-step OffSec advanced cert).

Year 4-6: Red-team operator. The transition is typically a firm-internal role-change — the consultant moves from the “pentest” practice to the “red-team” practice. The engagement structure is multi-week; the deliverable is the narrative-of-compromise; the cert profile adds CRTO. The first year as a red-team operator is dominated by learning the engagement-coordination function and the threat-informed-scenario design conversation.

Year 6-9: Senior red-team operator. The senior operator runs complex engagements with multiple supporting operators, defines engagement designs for high-stakes clients, and develops the firm’s working practice through internal training and external community contribution. The cert profile reaches its mature state; specialization paths begin to differentiate.

Year 9+: Red-team lead → Red-team program manager. The leadership track. The lead manages the operator population, owns the firm’s red-team methodology, represents the firm in client-facing senior-level conversations, and (at the program-manager level) owns the practice’s P&L and growth. The CRTL cert maps onto this transition.

The progression is not universal — some practitioners stay at the senior-operator level by deliberate choice (the operator work is the work they want to do; the management track is not the destination); some practitioners transition out of red-team work back into pentest or into purple-team (Vol 12) or into detection-engineering (Vol 10) at any point in the progression. The modal pattern is the one walked above; the actual variation across the field’s senior practitioners is wide.

6.3 The five specialization paths within senior red-team work

Senior red-team practitioners typically specialize. The five canonical specialization paths:

SpecializationWhat it isTypical employer patternMid-career US comp band (2026 reference)
AD red-team — the modal pathWindows enterprise Active Directory attack as the primary specialization; BloodHound + Rubeus + Impacket + Mimikatz-equivalent depthMajor consultancies (Mandiant, CrowdStrike Services, IBM X-Force Red, Bishop Fox) + major enterprise in-house red teams$180k-$280k base + bonus
Cloud red-team — growingAWS / Azure / GCP cloud-environment attack as primary specialization; cloud-IAM-and-network depth; AWSGoat / AzureGoat lab work as foundationCloud-native and cloud-adjacent consultancies; tech-firm in-house red teams$200k-$320k base + bonus (the rising-comp specialization)
Physical red-teamSocial-engineering plus physical-entry as primary specialization; the Hak5 implant family operator track (see §6.4); lock-picking and physical-bypass skillFirms with physical-engagement practice (rarer; not all consultancies run physical work); some federal-government roles$170k-$260k base + bonus (often lower than network red-team due to smaller market)
Social-engineering red-teamPhishing campaign design + execution + the broader social-engineering scope (vishing, pretexting, executive-impersonation); often paired with physicalSpecialized social-engineering consultancies (Social-Engineer LLC; some general consultancies’ specialty practice)$160k-$240k base + bonus
Adversary-emulation / purple-team practitionerThe integrated red+blue practice; ATT&CK Navigator and detection-engineering integration as primary mode; sometimes a hybrid role spanning red-team and detection-engineeringMajor enterprise in-house programs; major MSSPs with mature purple-team offerings; specialized purple-team consultancies$180k-$290k base + bonus

Table 11.5 — Five red-team specialization paths at the senior career level. The modal path is the AD red-team specialization; the rising-attention specialization is the cloud red-team (driven by enterprise cloud adoption and the relative scarcity of senior cloud red-team operators). The physical and social-engineering paths are smaller markets with their own dynamics. The purple-team specialization is the integration-practice path that Vol 12 will treat at depth. Compensation bands are early-2026 US-coast-and-major-metro reference points; the actual range varies by employer scale, geography, equity component, and specific role-and-title structure.

6.4 The Hak5 “physical implant operator” track — a sub-specialty within physical red-team

The Hak5 implant family (Ducky Script deep dive) defines a small-but-distinct sub-specialty within physical red-team work: the physical implant operator whose primary engagement role is the deployment, monitoring, and retrieval of physical-entry implants. The sub-specialty’s working set:

  • USB Rubber Ducky (the canonical HID-injection device; ~$80; the foundation tool of the family).
  • Bash Bunny (multi-payload USB-form-factor implant; ~$120; the engagement-realistic working horse).
  • Key Croc (inline keylogger with HID-injection; ~$200; the persistent-physical-access implant).
  • O.MG Cable / Plug / Adapter (the malicious-cable family; ~$120-$200 each; the covert implant family where the implant masquerades as an innocuous accessory).

The sub-specialty pairs the Hak5 implant family with the broader physical red-team skill set (tailgating; social-engineering pretexting; lock-picking; the engagement-coordination skill of working under-pretext in the client’s environment). The career profile is rarer than the AD-red-team specialization — the consultancies that run physical-engagement practice are a subset of the broader red-team consultancy market, and the engagements themselves are higher-stakes (the operator is on-camera, on-site, with the engagement’s legal-and-physical risk concentrated in single moments). The senior physical-implant operators are a small population.

Cross-reference: the DEF CON Physical Security Village (founded 2017) is the field’s institutional anchor for physical red-team content; the village’s annual program is the closest single artifact for “what physical red-team thinking looks like” at any point in time. The TOOOL — The Open Organization Of Lockpickers community is the canonical lock-picking community, with chapters at major hacker conferences and a strong educational mission.

6.5 Vol 18 forward-reference

Vol 18 (Careers, pending Phase 3 authoring) will treat the red-team career synthesis alongside the white-hat, blue-hat, and green-hat career synthesis at full depth. This §6 is the red-team-specific cut; Vol 18 will walk the full picture.


7. Famous figures

A short roster of red-team practitioners whose work has shaped the field. The selection emphasizes people whose impact is broad rather than narrow — researchers and tool-authors whose work changed how red-team practice is done, not just the engagements they ran. The intent is not exhaustive coverage of the field’s notable red-team figures; that’s well beyond a single volume’s reach. The intent is to ground the discussion of red-team practice in real people whose careers and decisions exemplify what red-team contribution 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 Raphael Mudge — Cobalt Strike originator

Raphael Mudge is the canonical figure for modern commercial red-team C2 frameworks. Working independently in the early 2010s, Mudge developed Armitage (2010, a graphical front-end for Metasploit) and then Cobalt Strike (2012, the commercial red-team C2 framework that would become the industry standard)17. Mudge ran his company Strategic Cyber LLC as a single-founder operation through the 2010s, growing Cobalt Strike from an experimental project into the canonical commercial red-team platform. Strategic Cyber LLC was acquired by HelpSystems in 2020; HelpSystems rebranded to Fortra in November 2022 (matching the framing carried in Vol 6 §3.3 and Vol 7 §3). Mudge stayed on through 2020-2021 to ensure transition continuity, then took a hiatus from the cybersecurity industry beginning in 2021.

As of early 2026, Mudge has returned to the security community through the Adversary Fan Fiction Writers Guild blog (launched 2025), where he publishes posts on leadership and advocacy in technical professions, red-team C2 technical topics, and broader industry observations18. His more recent technical effort is the Tradecraft Garden project, a public collection of self-contained evasion-tradecraft modules designed to integrate with any C2 framework — positioned as a community contribution separate from any commercial relationship. He is not at Fortra in 2026; the Cobalt Strike framework continues under Fortra’s stewardship without his ongoing involvement.

Why he matters for this volume: Mudge exemplifies the tool-author whose contribution defined an industry category. Cobalt Strike’s commercial success and operational influence shaped what commercial red-team work looks like — the framework’s Beacon implant’s operator-driven long-running engagement model, the Malleable C2 customization, the Aggressor Script extensibility — these are the engineering choices that the modern red-team operator’s working day is structured around. The dual-use complexity that Cobalt Strike’s success carried (cracked copies in criminal hands; the EDR detection-and-response arms race around Beacon) is the industry-shaping complication that Vol 7 §3 walked. Mudge’s career arc — single-founder commercial success, acquisition, hiatus, return to community contribution — is recognizable in several other founders’ careers in the security tool-author population.

7.2 Will Schroeder (@harmj0y) — the AD red-team practitioner-and-tool-author

Will Schroeder is the canonical figure for Active-Directory red-team work. As harmj0y (his long-running community handle and Medium pseudonym), Schroeder has been a working AD-red-team practitioner since approximately 2014, with substantial contributions across the AD-attack toolchain. He is one of the three co-creators of BloodHound (with Andy Robbins / @_wald0 and Rohan Vazarkar / @CptJesus) — the graph-based AD attack-pathing tool that has become the canonical AD red-team instrument since its 2016 DEF CON 24 presentation19. He is the author of Rubeus — the canonical Kerberos attack tool (Kerberoasting, AS-REP roasting, ticket forgery, delegation abuse). He co-authored the canonical AD-certificate-services attack research “Certified Pre-Owned” (2021, with Lee Christensen) that documented the AD CS attack surface in depth and gave the field the ESC1-ESC14 enumeration of AD CS attack paths.

As of early 2026, Schroeder is Principal Security Researcher at SpecterOps20, the consultancy founded in 2017 from the broader Veris Group offensive-security team. His current research focus has shifted toward machine learning applied to offensive development and the broader operational-tradecraft frontier; his Medium publication “Posts By SpecterOps Team Members” carries the ongoing work. The 2025-2026 BloodHound roadmap — OpenGraph extending the framework beyond Active Directory and Azure AD to broader identity-platform graph analysis — reflects SpecterOps’s continued investment in the graph-based-attack-pathing direction Schroeder co-founded the field on.

Why he matters for this volume: Schroeder exemplifies the practitioner-and-tool-author whose contributions are structural to the field’s working toolset. BloodHound + Rubeus + the broader PowerSploit-era toolkit (Schroeder was an early contributor) + the “Certified Pre-Owned” AD-CS attack research are the working canon for modern AD red-team operations. The career arc — community-contributor → tool-author → research-focused senior practitioner — is recognizable in many other senior offensive figures and is the dominant pattern for the practitioners whose names appear repeatedly in conference programs across the 2010s and 2020s.

7.3 Cedric Owens (@cedowens) — the macOS red-team specialist

Cedric Owens is the canonical figure for macOS-focused red-team work. His self-description is “red teamer with blue team roots” — a working pattern of approaching offensive work with the defensive instinct of “what will the blue team see?” baked into the tradecraft. He has been a working red-team practitioner for over a decade with a specific specialization in macOS post-exploitation — a niche that has grown from peripheral to critical as macOS endpoints have become more common in enterprise environments. Owens has authored SwiftBelt (a macOS enumeration tool inspired by Schroeder’s Windows-based Seatbelt), MacShellSwift (a macOS post-exploitation proof-of-concept written in Swift), the macOS Attack Defense project (a community resource for macOS detection development), and substantial conference content including the well-cited DEF CON 29 talk “Gone Apple Pickin’: Red Teaming MacOS Environments in 2021”21.

As of early 2026, Owens’s current employer is not unambiguously documented in public sources (LinkedIn profiles attributable to him show roles at ServiceNow at one point, with subsequent transitions; some sources reference Meta as a more recent role)22. The career arc has been red-team / offensive-security engineering across multiple major tech employers; the macOS specialization is the consistent thread. Verify current employer against his LinkedIn before relying on this for outreach — the career has moved through several roles since 2021 and his current employment may have changed again.

Why he matters for this volume: Owens exemplifies the deep-specialist red-team career — the practitioner whose contribution is structured around a specific technical domain (macOS) rather than a generalist red-team practice. The specialty has gotten more important as enterprise environments have become more heterogeneous (the classic “Windows everywhere, macOS for developers” pattern has expanded to substantial macOS production-environment footprints at many tech firms). The tooling and detection-engineering content he has produced is reference material for macOS red-team work, with the additional valuable property of including the defender’s perspective by deliberate framing.

7.4 Jake Williams (@malwarejake) — the former-government-now-private arc

Jake Williams is the canonical figure for the “former-government red-team practitioner now in commercial-and-research roles” career arc. Williams’s background is the U.S. National Security Agency’s Tailored Access Operations (TAO) organization — the publicly-disclosed NSA team that develops and operates the offensive-cyber capabilities at the heart of the agency’s mission. The NSA TAO affiliation is publicly disclosed by Williams himself across multiple conference talks and interviews; the specific operational work is classified, but the broader career context — military veteran, IC operator, transitioned to commercial security work — is the canonical “former-government practitioner” arc23.

After leaving NSA, Williams co-founded Rendition Infosec (a security consultancy he ran from approximately 2014 through 2021) and was a senior SANS instructor and course author for substantial time, contributing significant course material across the SANS pen-test and DFIR curriculum. The Rendition Infosec firm was sold; Williams co-founded BreachQuest in 2021 as CTO (the firm emerged from stealth that August with $4.4M seed funding from Slow Ventures + Tinder/Lookout founders), then served briefly as SCYTHE Director of Cyber Threat Intelligence in 2022, and is currently VP of R&D at Hunter Strategy, an IANS Research faculty member, and an independent security consultant with research focus on the intersection of AI/ML and cybersecurity24. His social-media handle @malwarejake (on X / Twitter, later on Mastodon at infosec.exchange) is one of the more-followed defender-and-red-team voices in the field, with substantial commentary on threat-intelligence, IR, and the broader cybersecurity industry.

Why he matters for this volume: Williams exemplifies the former-government-now-private career arc that is a recognizable pattern in the senior red-team population. Many senior offensive practitioners came from the IC or military offensive-cyber organizations (NSA, CIA, US Army Cyber Command, AFCYBER, the equivalent organizations in allied nations); the transition to commercial work brings the operational depth of the government training but requires the cultural adjustment to commercial engagement structure and disclosure norms. Williams’s combination of substantive technical credibility, public-facing community contribution, and the visible-from-the-outside government-to-private arc is the model.

7.5 Chetan Nayak — Brute Ratel C4 author

Chetan Nayak is the canonical figure for the modern commercial-C2-framework alternative-to-Cobalt-Strike position. Working as the paranoidninja handle (and @NinjaParanoid on X / Twitter), Nayak founded Dark Vortex as an offensive-security blog and training platform, then released Brute Ratel C4 as the commercial C2 framework that has become the principal Cobalt-Strike-alternative in the post-2020 market. His prior career included roles at Mandiant and CrowdStrike (the latter of which he left in January 2022 to pursue Brute Ratel development full-time)25. As of early 2026, Nayak is the founder of Dark Vortex and the author of Brute Ratel C4, operating the framework as an independent commercial venture rather than working for a traditional corporate employer.

The Brute Ratel C4 framework has had a notable industry trajectory. The September 2022 incident in which a cracked copy of Brute Ratel appeared in criminal-economy channels brought the same dual-use complexity Cobalt Strike has carried for years — the framework’s operational stealth (the badger implant’s evasion focus) makes it valuable to legitimate red-team operators and equivalently valuable to criminal actors. Nayak’s response — engineering changes to the framework’s licensing and operational structure, additional anti-cracking measures, continued legitimate-customer focus — has tracked the broader vendor-side response to the cracked-tool problem. The framework continues active development; the 2025-2026 releases (2.4 “Odyssey” and 2.5) have continued the framework’s evolution.

Why he matters for this volume: Nayak exemplifies the independent commercial-tool-author career arc — the practitioner whose contribution is a single framework that defines an industry position. Brute Ratel’s existence as a credible Cobalt-Strike alternative has changed the commercial C2 market structure; the framework’s adoption among red-team consultancies has provided the industry with an alternative to Cobalt Strike’s dominant market position. The career arc — engineering depth at major consultancies, then independent venture, then sustained framework development as the primary professional focus — is rare in the offensive-security space (most tool authors maintain primary employment elsewhere and develop their tools as a side project) and is the model for the small population of senior practitioners who have made independent framework development their full-time work.

7.6 The five-figure summary

FigureRole / employer (early 2026)SpecialtyCanonical contributionArc type
Raphael MudgeIndependent — Adversary Fan Fiction Writers Guild + Tradecraft Garden; not at Fortra (verify18)Commercial red-team C2 framework architectureCobalt Strike (2012-2020 as Strategic Cyber LLC founder); industry-defining framework for the modern red-team operatorFounder → acquired-and-departed → hiatus → community-returned
Will Schroeder (@harmj0y)Principal Security Researcher, SpecterOps (verify20)Active-Directory red-team practice and toolingBloodHound co-creation; Rubeus; “Certified Pre-Owned” AD CS attack research; PowerSploit-era contributionsPractitioner-and-tool-author; community-contributor → research-focused senior
Cedric Owens (@cedowens)Current employer not unambiguously documented (verify22)macOS red-team specializationSwiftBelt; MacShellSwift; DEF CON 29 “Gone Apple Pickin’”; ongoing macOS post-exploitation contentDeep-specialist practitioner; the macOS-red-team niche-defining figure
Jake Williams (@malwarejake)VP of R&D at Hunter Strategy + IANS Research faculty + independent security consultant24 (prior: Rendition co-founder 2014-21; BreachQuest co-founder/CTO 2021+; SCYTHE Dir. of CTI briefly in 2022)Former-government offensive operator turned commercial security practitionerRendition Infosec founding; SANS course authorship; @malwarejake community voice; ongoing IR and threat-intel work; AI/ML × cyber research at Hunter StrategyFormer-NSA-TAO → commercial consultancy founder → senior community voice
Chetan NayakFounder, Dark Vortex; Brute Ratel C4 author (verify25)Modern commercial C2 framework as Cobalt-Strike alternativeBrute Ratel C4 (2020-present); independent commercial framework developmentEngineering-track at major consultancies → independent venture → sustained framework development

Table 11.6 — The five-figure roster in shorthand. Each entry is a practitioner whose work has shaped substantial parts of the red-team community’s working practice; the selection covers commercial C2 framework architecture (Mudge), AD red-team tooling (Schroeder), macOS specialization (Owens), the former-government arc (Williams), and the modern commercial alternative C2 (Nayak). The roster is not exhaustive — many other figures (Dave Kennedy on social-engineering and TrustedSec; Chris Nickerson on physical and the Tiger Team television-show era; Deviant Ollam on lock-picking and physical security; Daniel Duggan on red-team training via Zero-Point Security; Andy Robbins and Rohan Vazarkar as Schroeder’s BloodHound co-creators; many others) belong in a longer roster. The five chosen here span the principal flavors of the senior red-team career.


8. Callouts and cross-references

The red-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 load-bearing callouts and the cheatsheet bullets that will end up in Vol 20.

8.1 The red team is not the black hat — load-bearing callout (restated)

The red team is not the black hat. A red-team operation is sanctioned, authorized, scope-bound. The legal frame is identical to the white-hat pentest (Vol 6 §1) — the same SOW, scope document, ROE, and (when physical entry is in scope) GOJL — and the discriminator from the black hat (Vol 7) is the authorization stack, not the technique. The same Cobalt Strike Beacon that a sanctioned red-team operator deploys is the same cracked Beacon a ransomware affiliate uses. The Mimikatz invocation that runs under an authorized red-team engagement runs against the same LSASS-memory data structures as the Mimikatz invocation that runs in a Conti affiliate’s post-exploitation phase. The wire traffic looks the same; the legal status is opposite. Authorization is what separates red-team from criminal activity. Without the paperwork stack, the same work is described by a different volume — Vol 7 (black hat), Vol 8 (grey hat), or Vol 19 (legal line). This is restated from §1 because it is the volume’s load-bearing rhetorical anchor.

8.2 The purple team is the integration — look here for the integration practice

Where to read next. For the explicit collaborative-integration practice — where red-team TTPs become the blue-team’s test cases, the detection-engineering function uses the red team’s emulation to validate rules, and the two teams operate as a single feedback loop — Vol 12 (Purple hat) is the canonical reference. The 2026 mature red-team engagement increasingly closes its loop through purple-team integration rather than ending at report delivery; the purple-team transition pattern walked in §4.7 is the foreshadowing of Vol 12’s full treatment. The relationship between red, blue, and purple is complementary engagement roles within the same security organization, not adversarial roles — Vol 10 §8.2 made the same point from the blue-team side. The mature 2026 enterprise security practice treats red, blue, and purple as an integrated triad.

8.3 Cross-references within this series

The red-hat treatment sits on the offensive engagement-role side of Axis 2 (Vol 5 §6.2); the rest of the taxonomy is treated in:

  • Vol 1 §3 — the decision graph for navigating the series; the hat-spectrum table from which Vol 11’s position derives.
  • Vol 5 §5.4 — the red-hat triple disambiguation (engagement-role / vigilante legacy / Red Hat Linux corp) that §1 of this volume expanded. The triple-disambiguation is the load-bearing structural feature of Vol 11’s opening.
  • Vol 5 §6 — the two-axis problem that locates the red-hat label on Axis 2 (engagement-role offensive) while leaving the Axis 1 (ethical stance) free to combine with white-hat-on-Axis-1 in the modal modern usage.
  • Vol 5 §8 — the master taxonomy diagram that locates the red-hat alongside the blue-hat and the purple-hat together on Axis 2 within the broader seven-color taxonomy.
  • Vol 6 (White hat) — the white-hat practice that shares the authorization model with the red-hat. The engagement-paperwork-stack discussion in Vol 6 §1 is structurally identical to the red-hat authorization envelope of §1.2 of this volume.
  • Vol 7 (Black hat) — the adversary the red-team emulates. Vol 7 §3 walks the criminal-economy toolchain at category level; the red-team’s toolkit substantially overlaps with the black-hat’s, with authorization as the discriminator.
  • Vol 8 (Grey hat) — the unauthorized / constructive case. The vigilante-framing of red-hat (§1’s meaning (b)) is structurally adjacent to the grey-hat boundary; in modern usage the vigilante framing is essentially absent.
  • Vol 9 (Green hat) — the newcomer / on-ramp; not the typical entry point for red-team work (the modal red-team progression starts from pentest experience per §6.2).
  • Vol 10 (Blue hat) — the defender side of the red/blue dichotomy. The red-team’s engagement is what the blue-team is structured to detect against; the relationship is complementary, not adversarial. The Vol 10 §8.2 callout pointed forward to this volume; the symmetric pointer back is in §8.2 above.
  • Vol 12 (Purple hat) — the collaborative integration practice. The §4.7 purple-team transition is the foreshadowing; Vol 12 will treat the integration practice at full depth.
  • Vol 16 (Computer-hacking tradecraft) — pending Phase 3 authoring; the engineering depth on the offensive-tooling stack (Cobalt Strike, AD attack tools, the lateral-movement toolchain) lives there.
  • Vol 17 (Social engineering tradecraft) — pending Phase 3 authoring; the social-engineering attack surface that phishing-driven initial access operates through, plus the physical-engagement social-engineering layer that §4.8 referenced.
  • Vol 18 (Careers) — pending; the career synthesis across all the hats. This volume’s §6 is the red-team-specific cut; Vol 18 will walk the full picture.
  • Vol 19 (The legal line and ethics) — pending; the CFAA-and-international legal framing for the authorization envelope, the hack-back / vigilante-framing exclusion §1 referenced, and the engagement-paperwork legal detail.

8.4 Cross-tool references — the physical-entry RF/HID staging layer

The physical-entry RF/HID staging layer (§3.6) connects this volume directly to the Hack Tools hub. The cross-tool paths resolve from Hacker Tradecraft/03-outputs/HackerTradecraft_Complete.html:

  • Ducky Script — the Hak5 implant family. ../../Ducky Script/03-outputs/DuckyScript_Complete.html. The 18-volume Ducky Script deep dive treats the Hak5 family — USB Rubber Ducky, Bash Bunny, Key Croc, O.MG Cable/Plug/Adapter — at engineer depth; Vol 14 of that deep dive covers the combined-workflow patterns where a Pineapple stages a Wi-Fi attack and a Bash Bunny delivers the post-exploitation payload, which is the canonical physical-entry red-team combined workflow.
  • WiFi Pineapple — rogue-AP staging. ../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html. The 21-volume Pineapple deep dive covers the platform at engineer depth across the four current models (Mark VII, Mark VII + AC Tactical, Pager, Enterprise); the red-team use is the rogue-AP / KARMA / evil-twin engagement work.
  • Flipper Zero — badge cloning and sub-GHz. ../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html. The Flipper deep dive covers the device family; the red-team use is the integrated handheld for badge cloning, key-fob capture, and short-range RF reconnaissance under authorized engagement scope.
  • Proxmark3 RDV4 — high-frequency RFID research. ../../Proxmark3 RDV4/ (deep dive aspirational as of early 2026; the project directory carries the CLAUDE.md placeholder). The Proxmark is the lab-grade tool for badge-credential cryptography research deeper than the Flipper’s higher-level abstraction.
  • HackRF One — wideband SDR for RF reconnaissance. ../../HackRF One/03-outputs/HackRF_One_Complete.html. The HackRF deep dive treats the platform at engineer depth; the red-team use is the wideband RF reconnaissance and custom-payload-development that goes alongside the physical-entry engagement work.

8.5 Cheatsheet bullets — Vol 20 candidates

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

  • The red-hat operator’s posture is white-hat on Axis 1, offensive on Axis 2. The red-team shares authorization with the white-hat-pentest; the engagement role is what differs.
  • The three meanings of “red hat” are different. Modern engagement-role red-team operator (the primary subject); older vigilante framing (essentially dead in 2026); Red Hat Inc. (the corporation; unrelated). Disambiguate by context.
  • The red team is not the black hat. Same gear; same techniques; opposite legal status. Authorization is the discriminator.
  • Red-team is distinguished from pentest on three axes. Duration (weeks-to-months vs days-to-weeks); objective (specific scenario via threat-actor emulation vs exhaustive vulnerability discovery); deliverable (narrative-of-compromise + ATT&CK Navigator vs vulnerability list).
  • The C2 framework is the operational central instrument. Cobalt Strike is the commercial industry standard ($5,900/yr/operator); Brute Ratel is the alternative ($2,500/yr); Sliver / Mythic / Havoc are the open-source choices.
  • Cobalt Strike’s ownership history is: Strategic Cyber LLC (Mudge, 2012-2020) → HelpSystems (2020) → Fortra (2022). Match this framing across volumes.
  • MITRE ATT&CK is the engagement’s structural vocabulary. Plan the engagement against named techniques; document the engagement against the Navigator layer; the post-engagement Navigator is the canonical detection-gap deliverable.
  • The assumed-breach starting condition is the engagement-time compression mechanism. Don’t spend half the engagement landing initial access when the engagement objective is the post-access work.
  • The transparency tier is decided at scoping. White-box / grey-box / black-box has different operational and detection-test value; grey-box is modal in 2026.
  • The engagement coordinator is the team function that pentest doesn’t typically have. Owns deconfliction, owns go/no-go authority, owns the post-engagement transition.
  • The purple-team transition is where the engagement’s value is operationally realized. The detection-gap findings become detection-engineering work items; the loop closes.
  • The Hak5 implant family is the canonical physical-entry working set. Rubber Ducky + Bash Bunny + Key Croc + O.MG family; cross-tool ref is the Ducky Script deep dive (18 volumes, the Hak5 family at full depth).
  • The CRTO is the role-specific cert. The CRTL is the leadership cert. The CRTP/CRTE pair is the AD-specialization track. The OSEP/OSCE3 cluster is the OffSec advanced track.
  • The modal red-team progression is 3-5 years pentest → red-team operator → red-team lead → red-team program manager. Entry-level direct-to-red-team is rare.

9. Resources

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

Cross-volume references (the load-bearing structural anchors):

Cobalt Strike and the commercial C2 framework lineage:

MITRE ATT&CK and Threat-Informed Defense:

AD attack tooling references:

Famous-figure primary sources:

Certification course references:

Military and consultancy historical references:

NIST and federal framework references:

Combined-workflow and physical-entry references:

Cross-volume references (this series):

  • Vol 4 §2 — consultancy professionalization (Mandiant founding 2004, acquisition by FireEye 2013, FireEye/Trellix split 2022, Mandiant to Google 2022 for $5.4B). Foundation for §2.2.
  • Vol 4 §4 — MITRE ATT&CK framework public release (January 2015); APT taxonomy. Foundation for §2.4 and §4.3.
  • Vol 5 §5.4 — the red-hat triple disambiguation. Load-bearing for §1.
  • Vol 5 §6 — the two-axis problem. Foundation for §1 (the red-hat-on-Axis-2 placement).
  • Vol 5 §8 — master taxonomy diagram. Foundation throughout.
  • Vol 6 §1 — white-hat authorization-paperwork stack. Foundation for §1.2.
  • Vol 6 §3 — white-hat toolchain, including Cobalt Strike and the dual-use treatment. Foundation for §3 (dual-use principle).
  • Vol 6 §4 — engagement lifecycle. Structural template for §4.
  • Vol 7 §3 — black-hat toolchain. Foundation for §3 (the same tools / opposite authorization).
  • Vol 8 §1 — grey-hat boundary. Cross-ref for §1 (vigilante framing).
  • Vol 10 §3 — blue-hat defender toolchain. Cross-ref for §3 (defensive complement).
  • Vol 10 §4 — detect/triage/respond/hunt loop. Foundation for §4.7 (purple-team transition; the loop closes via detection-engineering).
  • Vol 10 §8.2 — the red and purple complement look-here callout from the blue side. Symmetric pointer that §8.2 of this volume answers.
  • Vol 10 §8.3 — hack-back legal callout. Foundation for §1’s vigilante-framing exclusion.
  • Vol 12 — purple hat, pending. Cross-ref §4.7 and §8.2.
  • Vol 16 — computer-hacking tradecraft, pending. Cross-ref for engineering depth on offensive tooling.
  • Vol 17 — social engineering tradecraft, pending. Cross-ref for phishing-driven initial access and physical-engagement social engineering.
  • Vol 18 — careers, pending. Cross-ref for full career-path synthesis.
  • Vol 19 — legal line and ethics, pending. Cross-ref for CFAA framing, authorization-in-practice, hack-back legal posture, and the engagement-paperwork legal detail.

Footnotes

  1. See Vol 5 §6.4 and the Vol 5 footnote redhat-corp for the Red Hat Inc. corporate-brand framing. Vol 5 also walked the chronological emergence of the engagement-role and vigilante meanings at depth; this volume’s §1 carries the triple-disambiguation forward as the structural opening.

  2. U.S. DoD red-team and blue-team practice formalization across the 1960s through 1990s; SAIC’s defense-contracting red-team practice. Vol 5 §5 walked the chronological emergence at depth, including the SAIC contracts of the 1960s and 1990s and the broader DoD war-gaming lineage. Commercial cybersecurity adoption through the 2000s and 2010s is documented in the broader cybersecurity-history literature; Mandiant’s 2004 founding and subsequent acquisition trajectory walked in Vol 4 §2.

  3. See Vol 5 §6.4 and the Vol 5 footnote red-hat-vigilante. The “red hat as vigilante” framing appears in occasional 1990s and early-2000s trade-press usage but never stabilized in either community-internal or mainstream professional vocabulary. Essentially dead in 2026.

  4. MITRE ATT&CK framework public release: January 2015. ATT&CK home: https://attack.mitre.org. ATT&CK Navigator: https://mitre-attack.github.io/attack-navigator/. Initial framework development was internal at MITRE beginning approximately 2013; the public release made the catalog and the Navigator infrastructure available to the field. Vol 4 §4 walked the framework’s emergence in the broader nation-state-actor public-attribution context; Vol 10 §3.5 and §4.7 built on the framework from the defender’s side.

  5. MITRE Center for Threat-Informed Defense, founded 2019 as an industry-funded MITRE-operated research center. Project home: https://ctid.mitre.org. The Center’s working publications and research output are the canonical reference for the Threat-Informed Defense framework that this volume’s §2.4 referenced.

  6. Cobalt Strike commercial pricing as of early 2026: approximately $5,900 per operator per year. Product home: https://www.cobaltstrike.com/. The Strategic Cyber LLC original founding (2012), HelpSystems acquisition (2020), and HelpSystems → Fortra rebrand (November 2022) lineage match the framing carried in Vol 6 §3.3 and Vol 7 §3. Mudge’s Advanced Threat Tactics training course (free, video form) is the canonical reference for the platform’s tradecraft; archived at https://www.cobaltstrike.com/training/.

  7. Brute Ratel C4 product home: https://bruteratel.com/. Chetan Nayak’s Dark Vortex site: https://0xdarkvortex.dev/. The “About” page at https://0xdarkvortex.dev/about/ carries the founder narrative. Pricing approximately $2,500 per operator per year as of early 2026.

  8. Sliver project home: https://github.com/BishopFox/sliver. Bishop Fox tool-page: https://bishopfox.com/tools/sliver. The framework’s public release at SummerCon 2019 is documented in the project README and Bishop Fox’s introductory blog post: https://bishopfox.com/blog/sliver. License: GPL-3.0.

  9. Mythic project home: https://github.com/its-a-feature/Mythic. Cody Thomas / @its-a-feature is the framework’s author and maintainer; the framework is open-source under the BSD-3 license. The Mythic documentation site: https://docs.mythic-c2.net.

  10. National Institute of Standards and Technology, Technical Guide to Information Security Testing and Assessment (NIST SP 800-115, September 2008). Authors: Scarfone, Souppaya, Cody, Orebaugh. Canonical reference for the pentest / red-team distinction at the federal-framework level. https://csrc.nist.gov/publications/detail/sp/800-115/final. The framework’s distinction between vulnerability assessment, penetration testing, and the broader security testing activities provides the federal-government vocabulary that commercial work largely follows.

  11. See [Ducky Script deep dive Vol 14](../../Ducky%20Script/03-outputs/DuckyScript_Complete.html#vol14) (combined workflows) for the canonical physical-entry red-team workflow combining WiFi Pineapple staging with Bash Bunny HID-injection delivery. The cross-tool reference at <../../Ducky Script/03-outputs/DuckyScript_Complete.html>.

  12. 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. Approximate cost ~$500 as of early 2026.

  13. Pentester Academy / Altered Security, Certified Red Team Professional (CRTP) course: https://www.alteredsecurity.com/adlab. AD-specialization focused; approximate cost ~$300 as of early 2026.

  14. Offensive Security, OSEP — OffSec Experienced Penetration Tester (PEN-300): https://www.offsec.com/courses/pen-300/. Approximate cost ~$2,500 as of early 2026 for the Learn One bundle.

  15. Zero-Point Security, Certified Red Team Lead (CRTL) course: https://training.zeropointsecurity.co.uk/courses/red-team-lead. Senior-track leadership and engagement-coordination focused; approximate cost ~$1,200 as of early 2026.

  16. SANS Institute and GIAC certifications: https://www.giac.org/certifications/. The GPEN (Penetration Tester), GXPN (Exploit Researcher and Advanced Penetration Tester), and GRTP (Red Team Professional) certifications are the SANS-track red-team-relevant certifications; each is associated with a corresponding SANS course (SEC560, SEC660, SEC565 respectively in the current SANS catalog).

  17. Raphael Mudge’s history with Cobalt Strike. The Cobalt Strike “Profile” page on the Fortra site carries the founder-history narrative: https://www.cobaltstrike.com/profile/raphael-mudge. Mudge’s archived Strategic Cyber LLC blog posts are at https://blog.cobaltstrike.com/author/rsmudge/. Vol 4 §7 and Vol 7 §3 walked the framework’s broader industry trajectory.

  18. Raphael Mudge’s current activity as of early 2026: Adversary Fan Fiction Writers Guild blog (launched 2025) covering leadership, advocacy, red-team C2 technical topics, and broader industry observations; Tradecraft Garden project (a public collection of evasion-tradecraft modules). Not affiliated with Fortra in 2026; hiatus from Cobalt Strike work began in 2021. Verify current activity via his GitHub (https://github.com/rsmudge) and the Adversary Fan Fiction Writers Guild content. Current-role claims carry “as of early 2026” qualifier. 2

  19. BloodHound co-creators: Andy Robbins (@_wald0), Will Schroeder (@harmj0y), Rohan Vazarkar (@CptJesus). Original DEF CON 24 presentation, 2016: archived at https://www.youtube.com/watch?v=ftnvZpzfMTw (DEF CON official channel). Current project home: https://github.com/SpecterOps/BloodHound. SpecterOps stewardship of BloodHound Community Edition (CE) and BloodHound Enterprise: https://specterops.io/bloodhound.

  20. Will Schroeder at SpecterOps, current role as of early 2026: Principal Security Researcher. Verify via SpecterOps Author page (https://specterops.io/blog/author/will-schroeder/), his Medium publication (https://harmj0y.medium.com/), and LinkedIn (https://www.linkedin.com/in/willschroeder/). The “Certified Pre-Owned” AD CS attack research (2021): https://posts.specterops.io/certified-pre-owned-d95910965cd2. Current-role claims carry “as of early 2026” qualifier. 2

  21. Cedric Owens, DEF CON 29 (2021), “Gone Apple Pickin’: Red Teaming MacOS Environments in 2021.” Archived presentations and slides available via the DEF CON 29 program and Owens’s Medium publication (https://cedowens.medium.com/). SwiftBelt project: https://github.com/cedowens/SwiftBelt. MacShellSwift project: https://github.com/cedowens/MacShellSwift.

  22. Cedric Owens, current employer as of early 2026: not unambiguously documented in public sources. Verify against his LinkedIn (multiple profiles attributable to him exist; check current) and Twitter / X (@cedowens). Career has moved through multiple employers including roles attributed to ServiceNow and (possibly) Meta in the post-2021 window; the deep-specialist macOS-red-team focus is the consistent thread. Current-role claims carry “as of early 2026” qualifier and should be verified before relying on this for outreach. 2

  23. Jake Williams, public biographical material: NSA TAO affiliation is publicly disclosed by Williams across multiple conference talks; the broader career context (military veteran, IC operator, transitioned to commercial security work) is the canonical “former-government practitioner” arc. SANS instructor profile: https://www.sans.org/profiles/jake-williams. DC3 Digital Forensics Challenge two-time winner (publicly documented).

  24. Jake Williams, current roles as of early 2026: VP of R&D at Hunter Strategy, IANS Research faculty member, and independent security consultant; research focus on the intersection of AI/ML and cybersecurity. Prior roles include Rendition Infosec co-founder (~2014-2021), senior SANS instructor and course author, BreachQuest co-founder/CTO (2021+, $4.4M seed Aug 2021; operational status post-2022 archival rather than current), SCYTHE Director of Cyber Threat Intelligence (briefly, 2022). Verify against IANS Research faculty page (https://www.iansresearch.com/home/jake-williams) and his Mastodon presence at infosec.exchange (@malwarejake). Current-role claims carry “as of early 2026” qualifier. 2

  25. Chetan Nayak, current role as of early 2026: Founder of Dark Vortex; author of Brute Ratel C4. Verify against Dark Vortex site (https://0xdarkvortex.dev/) and X / Twitter (@NinjaParanoid). Left CrowdStrike in January 2022 to pursue Brute Ratel development full-time. Prior career included roles at Mandiant and CrowdStrike. Current-role claims carry “as of early 2026” qualifier. 2