Cyber Knowledge · Domain 02 of 11 · Practitioner field guide

Red Team & Offensive Security

A fourteen-module field reference for authorized security testing: engagement design, reconnaissance, vulnerability validation, web and API testing, cloud and Kubernetes, identity, clients, human-layer exercises, adversary emulation, AI/MCP workflows, operator infrastructure, laboratories, evidence, reporting, and program governance. The goal is defensible security improvement—not “getting a shell” without context.

Version 1.0 Published 27 Jun 2026 Source review: 27 Jul 2026 Status: maintained practitioner guide Maintained by Andrey Pautov Editorial policy and corrections

Authorized environments only

Use these methods only on systems you own or are explicitly authorized to assess. Written scope, rules of engagement, data-handling requirements, emergency contacts, and stop conditions come before tooling.

Open authorized labs → ← Back to Cyber Knowledge

How to use this guide

This is an engagement-oriented curriculum, not a catalogue of commands. Read Modules 1–3 before selecting a specialist path, use Modules 4–13 according to the approved target and technique classes, then return to Modules 8, 10, and 14 to connect the technical result to detection, reporting, governance, and retesting. Every practical exercise should produce evidence that another authorized reviewer can reproduce without relying on the operator’s memory or an AI-generated narrative.

Foundation track

Modules 1–3 establish authority, objectives, reconnaissance, validation discipline, and evidence. They are mandatory even when a specialist performs only web, cloud, or identity testing.

Specialist tracks

Modules 4–7 and 11–13 cover applications, infrastructure, cloud, identity, clients, human-layer testing, privilege, movement, and operator infrastructure. Select only the paths authorized by the engagement and supported by the laboratory or target environment.

Validation track

Module 8 converts relevant adversary behavior into observable, reversible tests. It separates prevention, telemetry, analytic coverage, alert handling, and response outcomes.

Assistance and delivery

Modules 9, 10, and 14 define when AI and MCP can assist, how tools are constrained, how labs are designed, and how evidence becomes a report, defensive handoff, governance decision, and retest.

Required engagement record

Maintain one record containing authorization and ROE, target inventory, objective-to-test mapping, operator timeline, tool versions and configuration, raw outputs, evidence references, changes made, cleanup confirmation, findings, detection observations, reviewer decisions, limitations, and retest state. A result that cannot be traced to this record remains a lead, not a defensible conclusion.

Technical foundations — what the operator must understand before tooling

5 deep references

Tools compress protocol behavior into convenient labels. Professional testing requires the operator to reconstruct what actually happened at the network, application, identity, operating-system, and control-plane layers—and to know which parts remain unproven.

Networks, DNS, TLS, and HTTP: interpret the path, not only the endpoint

A hostname is not a server, an IP address is not necessarily an owned asset, an open port is not automatically an application, and an HTTP response is not proof of the complete request path. Modern services commonly traverse recursive DNS, authoritative DNS, content-delivery networks, anycast addresses, load balancers, web application firewalls, reverse proxies, service meshes, gateways, and origin workloads. Each layer may have a different owner, log source, policy, and failure mode. Record the observation point and route before attributing behavior to the application team.

DNS reasoning

Separate the queried name, record type, returned value, CNAME chain, authoritative zone, resolver, TTL, DNSSEC state, and collection time. Historical records are discovery leads, not proof of current ownership. Wildcards can fabricate plausible-looking subdomains; split-horizon DNS can produce different answers internally and externally; and shared SaaS or hosting domains must not be imported into scope merely because a customer-specific name points to them.

Transport reasoning

TCP state reflects a conversation from one source at one time. A filtered result can mean an access-control device, local firewall, asymmetric route, rate limit, unavailable host, or dropped probe. UDP often requires protocol-aware requests and careful timing. Preserve source address, route, timing policy, probe type, retries, and packet evidence when the distinction matters.

TLS reasoning

Record SNI, certificate chain, subject alternative names, issuer, validity, negotiated version and cipher, client trust result, redirect behavior, and whether a proxy terminated TLS. A valid certificate proves that a trusted issuer bound a key to names under its policy; it does not prove application ownership, authorization quality, or absence of an origin exposure.

HTTP reasoning

Capture method, scheme, host, path, query, relevant headers, identity state, request body, response status, response headers, body, timing, redirects, cache behavior, and resulting server-side state. Compare authenticated and unauthenticated paths, but never interpret a single status code as the security decision. A 404 can conceal authorization; a 200 can contain an error; and a cached response can bypass the origin entirely.

Minimum protocol questions

Which component answered, and what evidence distinguishes edge, proxy, gateway, and origin?
Which identifier was used for routing: IP, hostname, SNI, Host header, tenant, API key, session, or workload identity?
Which controls were expected on this path, and where should their telemetry appear?
Could the result be explained by shared infrastructure, caching, network policy, stale data, or a scanner artifact?

Scanning a CDN address and reporting every co-hosted domain as an asset.
Calling port 443 “HTTPS confirmed” without a successful TLS and application-layer exchange.
Inferring a vulnerable version from a banner that a proxy can rewrite.
Reporting absent response headers without recording the exact endpoint, redirect chain, and response that was evaluated.

Foundation acceptance: given one browser request and one network scan result, the learner can draw the request path, label confirmed and inferred components, explain alternative interpretations, name the relevant logs, and produce a bounded next test without claiming ownership or vulnerability prematurely.

1200km path: Nmap guide series · OSINT and reconnaissance · Nmap analysis with an LLM

Identity, authentication, authorization, and session state

Authentication establishes or asserts an identity; authorization decides whether that identity may perform a specific action on a specific object under current policy; session management carries state across requests; federation transfers assertions between trust domains; and auditing records a representation of the decision. These are related controls, not synonyms. A successful login does not prove appropriate object access, and a denied user-interface action does not prove the server denied the underlying API operation.

Identity vocabulary

Distinguish human users, service accounts, workloads, devices, API clients, groups, roles, claims, credentials, tokens, sessions, keys, certificates, and recovery identities. Preserve immutable IDs in addition to display names. Names can be recycled; group membership and claims can change; tokens can outlive the policy state that issued them.

Authorization model

Document the subject, action, object, tenant or boundary, policy source, contextual conditions, and final decision. Role-based, attribute-based, relationship-based, discretionary, and policy-engine decisions fail differently. Test effective behavior rather than assuming the application implements the model described in documentation.

Token and session model

Record issuer, audience, subject, scopes or claims, issue and expiry times, binding, storage location, refresh behavior, revocation, step-up requirements, device context, and server-side session state. Do not place live credentials or reusable tokens into screenshots, reports, source control, or remote-model prompts.

Trust transitions

A useful identity graph labels each transition: password or key use, federation, impersonation, delegation, group nesting, ACL control, role assumption, workload identity, certificate enrollment, support reset, recovery, or administrative consent. A graph edge is a hypothesis until its preconditions and effective permission are validated.

Build an authorization matrix before mutation

Create controlled identities for the relevant roles and tenants. List representative objects and operations: view, list, create, update, delete, approve, export, administer, share, or impersonate. Record the expected outcome and the authoritative policy source. Capture a baseline request, change one security-relevant element at a time, observe both the response and persistent state, then correlate the audit record. This exposes horizontal object access, vertical privilege escalation, tenant-boundary failures, hidden administrative APIs, inconsistent bulk operations, and workflow bypasses without relying on blind fuzzing.

Changing many headers, identifiers, and parameters at once, making the successful condition impossible to isolate.
Testing with an administrator and assuming the same transaction represents a standard user.
Treating a client-side hidden button as an authorization control.
Reporting decoded token contents as verified truth without validating signature, issuer, audience, server behavior, and current policy.
Collecting real credentials when synthetic accounts could prove the same control.

Foundation acceptance: the learner can explain the difference between authentication and authorization, draw the identity and session lifecycle, construct a subject–action–object matrix, prove one server-side decision with paired requests and audit evidence, and cleanly revoke all test credentials and sessions.

Primary: OWASP ASVS · 1200km path: Identity Threat Detection and Response

Operating systems, processes, privileges, and persistence

A host result must be interpreted through the operating system’s security model. On Windows, relevant boundaries include access tokens, integrity levels, privileges, services, scheduled tasks, registry and file ACLs, named pipes, remote-management interfaces, credential protection, application control, and endpoint telemetry. On Linux and Unix-like systems, consider real and effective IDs, groups, capabilities, sudo policy, set-user-ID behavior, services, cron and timers, namespaces, mandatory access controls, mounts, sockets, environment, and package provenance.

Model each privilege path as a sequence of state transitions. Record the starting principal, current privileges, controlled object, exact right, execution context, prerequisite, target principal, security boundary, visible side effects, defensive events, and rollback. “Writable service” is incomplete: which file or configuration is writable, by which identity, which trusted process consumes it, under what trigger, and with what resulting privilege?

Process and execution context

Record parent and child processes, executable or interpreter, arguments, working directory, user, integrity or privilege state, environment, loaded content, network connections, start time, exit result, and target change. The same command can have different security meaning under a different parent, user, host role, or administrative workflow.

Configuration and trust

Evaluate file and directory permissions, search paths, service definitions, library or module loading, scheduled execution, policy, secrets, and update channels. Confirm both write control and a reliable privileged consumption path; a writable unused file is not a privilege escalation.

Credential restraint

Prefer proofs that avoid extracting reusable secrets: metadata, access checks, controlled test identities, synthetic markers, or owner-observed validation. When credential access is explicitly required, define types, locations, minimization, encryption, rotation, retention, and emergency exposure handling before collection.

Cleanup as a technical phase

Track files, accounts, groups, keys, certificates, services, tasks, packages, processes, sessions, routes, firewall rules, persistence mechanisms, test data, and log artifacts. Verify authoritative state after cleanup; deleting the visible file does not prove a service, token, snapshot, or cloud-side record was removed.

Minimum-impact proof pattern

Confirm the relevant configuration using native or read-only inspection.
Verify the starting identity and the exact permission enabling the transition.
Choose a reversible synthetic target or marker approved in the ROE.
Execute the smallest action that crosses the intended boundary.
Collect host, identity, endpoint, and application evidence around the same UTC window.
Restore the baseline and independently verify the state and credential disposition.

Foundation acceptance: the learner can decompose a privilege finding into principal, controlled object, right, trigger, privileged consumer, proof, telemetry, and rollback, and can reject a candidate where one required edge is absent.

Cloud, containers, and Kubernetes: separate control planes from workloads

Cloud assessment requires explicit tenant and provider context. A public IP may belong to a provider edge; a resource name may exist in several projects; a role name may resolve to different permissions; and an effective authorization decision may combine organization policy, account policy, resource policy, identity policy, session restriction, boundary, deny rule, and contextual condition. Capture immutable tenant, subscription, account, project, resource, principal, and event identifiers rather than relying on names.

Cloud identity path

Trace the starting principal, credential type, authentication context, role or service-account assumption, effective permissions, resource policy, data or control-plane action, and recorded provider event. Keep “permission exists,” “permission is effective,” “resource is reachable,” and “action succeeded” as separate states.

Workload boundary

Distinguish image, container, pod, node, cluster, namespace, service account, network, metadata service, registry, secrets store, and cloud identity. Container root is not automatically host root. A pod permission is not automatically cluster administration. A cluster credential is not automatically cloud control-plane access.

Kubernetes authorization

Record the subject, group, service account, namespace, verb, resource, resource name, role or cluster role, binding, admission decision, and audit event. Evaluate token projection and rotation, pod security, network policy, secret access, workload identity, admission controls, and node trust as different boundaries.

Cost and state

Testing can create resources, snapshots, images, functions, queues, logs, API calls, network egress, and retention costs. Define budgets, regions, tags, expiration, teardown ownership, and a post-test provider inventory. Deleting a workload may leave keys, images, snapshots, events, or external resources.

Evidence hierarchy

Prefer provider API responses and audit events tied to immutable IDs, followed by configuration exports and policy simulation, then console screenshots as supporting context. Preserve before-and-after state for changed policy. Treat third-party CSPM and scanner findings as hypotheses until the effective path and environment context are confirmed.

Reporting a broad policy string without showing that the tested principal receives it after all denies and conditions.
Calling a public provider IP an owned host or adding unrelated co-tenants to inventory.
Assuming a container escape because a process runs as root inside the container.
Ignoring cloud event IDs, leaving the defensive team unable to correlate the test.
Closing the assessment before reconciling resources, secrets, sessions, images, and cost.

Foundation acceptance: the learner can draw the control-plane and workload boundaries, prove one effective permission with an immutable identity and audit event, distinguish namespace/cluster/node/cloud impact, and reconcile all created resources and credentials.

1200km path: Black-box Kubernetes testing playbook · Cloud identity scenario

Telemetry, evidence, uncertainty, and the claim ladder

Technical testing produces observations under defined conditions. Reporting turns those observations into claims. The rigor of the report depends on preserving the steps between them. Use a claim ladder: source lead identifies something worth checking; observation records what a tool or system returned; corroboration confirms it through another source or layer; reproduction demonstrates the behavior under controlled conditions; impact evidence shows the authorized security consequence; and conclusion explains the decision with limitations and confidence.

Raw evidence

Preserve original scan output, request and response records, audit events, logs, packet captures where justified, command transcripts, configuration exports, screenshots with context, file hashes, test-artifact versions, and time-source information. Raw does not mean unprotected: classify, encrypt, minimize, and restrict access.

Derived evidence

Parsed tables, graphs, ATT&CK mappings, AI summaries, risk scores, timelines, and dashboards are derived artifacts. Link each item back to raw evidence and record parser, query, model, rules, and version. Reprocessing must not overwrite the original.

Confidence and limitations

Confidence describes support for the conclusion, not severity. State collection gaps, untested platforms, assumed versions, blocked probes, unavailable logs, shared infrastructure, sample limits, model uncertainty, and time sensitivity. “Unresolved” is a valid state when the evidence is insufficient.

Defensive correlation

Align operator actions and defensive events to a common time reference. Record source and target, identity, test ID, procedure, expected event, observed event, ingestion delay, normalization, analytic, alert, route, analyst decision, and response. Absence from a dashboard is not proof that telemetry was never generated.

Example claim decomposition

Weak: “The server is vulnerable to CVE-X.” Reviewable: “The authenticated inventory reports component A version B on asset C. Vendor advisory D states that this build is affected when condition E is enabled. A read-only check confirmed E at time F; protective control G blocked the authorized proof before impact. Disposition: affected configuration with compensating prevention observed, impact not demonstrated, medium confidence, retest after upgrade.” The second form shows which facts were observed, which came from a source, what was blocked, and what remains uncertain.

Foundation acceptance: the learner can take a scanner, proxy, identity, or AI-generated claim and separate source, observation, corroboration, reproduction, impact, inference, confidence, and limitation; every accepted statement links to evidence another reviewer can inspect.

Module 1 — Mission, authorization, and methodology

6 topics

The engagement contract is a security control. A technically successful test can still be a failed engagement if it exceeds authority, disrupts production, mishandles data, or cannot explain business impact.

Red team vs. penetration test vs. vulnerability assessment

A vulnerability assessment identifies and prioritizes likely weaknesses. A penetration test validates whether selected weaknesses are exploitable and what access or impact follows. A red-team engagement evaluates whether people, process, technology, and detections can resist a threat-informed objective across a realistic attack chain. These activities overlap, but they do not have interchangeable success criteria.

Choose the least intrusive assessment capable of answering the stakeholder’s question. If the question is “which internet-facing services need remediation,” start with exposure and vulnerability validation. If it is “can a realistic actor reach a protected business process without being contained,” a controlled red-team or purple-team exercise may be appropriate.

1200km path: PT Tools & Techniques · CTI to detection · AdversaryGraph vs. Atomic Red Team

Scope, authorization, and rules of engagement

NIST defines rules of engagement as detailed constraints established before a security test that give the team authority to conduct defined activities. A professional ROE names in-scope assets and identities, permitted techniques, test windows, third-party dependencies, source addresses, data handling, notification paths, incident handling, stop conditions, and the authority that may resume a paused test.

Use explicit asset identifiers; “the company domain” is not enough when SaaS, CDN, or shared hosting is involved.
Separate permitted discovery, validation, exploitation, persistence, social engineering, denial-of-service, and data-access actions.
Record emergency contacts and a verifiable kill switch before intrusive testing.
Obtain additional authorization for cloud tenants, managed providers, or other third-party infrastructure.

Boundary: public visibility is not authorization. A Shodan result, exposed login page, bug-bounty listing, or discovered IP does not grant permission beyond the applicable program policy and written scope.

Primary reference: NIST SP 800-115 · Site: 1200km data-handling policy

Objectives, threat model, and success criteria

Start with a business decision and a threat model, not a favorite exploit. Define the protected process, likely adversaries, assumed starting position, target actions, control hypotheses, and acceptable proof. Threat intelligence can provide known behaviors, but the plan must be tailored to the environment’s telemetry and defensive objectives.

A useful objective is measurable: “test whether a standard external user can obtain access to restricted billing data and whether identity, endpoint, and SIEM controls detect or contain the path.” “Compromise the network” is too broad to guide safe execution or meaningful reporting.

1200km path: PIRs and decision requirements · Public ATT&CK workspace

Operational security, deconfliction, and safety

Engagement OPSEC protects both the client and the integrity of the test. Use dedicated infrastructure and accounts, prevent test data from escaping the scope, log operator actions, and coordinate with a small white team that can distinguish exercise activity from a real incident without pre-alerting every defender.

Deconfliction is not concealment at any cost. Real malicious activity, unexpected sensitive data, production instability, or a scope ambiguity should trigger the documented pause-and-escalate process. Safety takes priority over scenario realism.

Evidence, reproducibility, and chain of custody

Decide before testing what evidence is required to prove each objective: timestamps, tool versions, commands or requests, target identifiers, screenshots, relevant logs, observed controls, and cleanup confirmation. Store evidence in the approved location with access control and retention limits.

Every finding should distinguish observation, reproduction, inference, and impact. A scanner alert is an observation; a controlled reproduction is validation; a claim that the flaw enables business-process compromise is an inference until the authorized path is demonstrated or otherwise supported.

Applied workflow — design an engagement that can be defended

The first deliverable is not a scan: it is a signed, testable agreement between the sponsor, system owner, white team, operators, and evidence consumers. The following workflow turns a broad request such as “red team our environment” into bounded decisions and observable outcomes.

Translate the request into a business decision. Identify what the sponsor needs to decide after the engagement: accept a risk, fund a control, validate a response process, compare detection capability, or approve a release.
Name the protected operation. Describe the business process, sensitive action, data class, critical identities, trust boundaries, and unacceptable outcomes. This prevents the assessment from becoming an infrastructure-only exercise.
Define the assumed starting point. External unauthenticated, standard workforce user, compromised endpoint, contractor identity, or cloud workload are different tests. State which access, knowledge, and credentials the operator receives.
Build the authority matrix. Map each target class to discovery, authentication testing, exploitation, social engineering, persistence, data access, movement, impact simulation, and cleanup permissions. Mark prohibited actions explicitly.
Write objective-level success and stop criteria. Define the minimum evidence that answers each objective and the event that stops further action. Reaching a synthetic marker may be sufficient; accessing real customer records rarely is.
Perform a technical and safety dry run. Verify source infrastructure, time synchronization, logging, emergency communication, test identities, target allowlists, backups, snapshots, rate limits, and cleanup procedures in a lab or staging environment.
Open the evidence ledger before execution. Assign identifiers to objectives, actions, artifacts, findings, and changes so every screenshot, scan, request, and defensive observation can be traced to a reviewed decision.
Close formally. Confirm cleanup, revoke test access, inventory residual artifacts, transfer evidence, document limitations, and obtain owner acknowledgement before treating the engagement as complete.

Minimum artifacts

Authorization letter and signed ROE
Objective and success-criteria matrix
Asset, identity, provider, and exclusion list
Contact, escalation, pause, and resume plan
Evidence, retention, and data-destruction plan
Change and cleanup ledger

Safe lab exercise

Create two fictional engagement briefs for the same vulnerable lab: one vulnerability assessment and one threat-informed red-team exercise. Compare authority, success criteria, evidence, test depth, defensive participation, and reporting. The technical target stays unchanged; the mission changes the work.

Example scenario

A SaaS provider wants to know whether a compromised standard account can reach restricted billing exports without prevention or a triaged alert. The authorized proof is access to a synthetic record and a correlated defensive timeline—not downloading the production dataset.

AI assistance boundary

An assistant may compare the ROE with a proposed test plan, identify ambiguity, draft checklists, and normalize notes. It must not expand scope, infer permission, select a real target, or approve an intrusive action. Only the named authority can change the engagement.

Evidence gate: do not begin active collection until each target can be tied to written authority, a named owner, a permitted action class, an evidence requirement, a stop condition, and a cleanup owner.

Module 2 — Reconnaissance and attack-surface mapping

5 topics

Reconnaissance should produce a scoped, attributed asset model—not an unreviewed pile of domains, ports, and screenshots.

Passive vs. active reconnaissance

Passive reconnaissance uses existing public or authorized data—DNS history, certificate transparency, repositories, documentation, exposure indexes, and supplied inventories—without directly probing the target. Active reconnaissance sends traffic to in-scope systems to confirm hosts, services, technologies, and reachable paths.

Passive sources can be stale, shared, or misattributed; active results can affect production and alert defenders. Label the collection method and timestamp, preserve the source, and validate ownership before moving an observation into the target inventory. The HexStrike OSINT exposure-map article demonstrates how a seed can expand while still requiring analyst review.

1200km path: OSINT & Reconnaissance · Shodan with HexStrike

Build an attributed asset and identity model

For each candidate asset, record ownership confidence, hostname or cloud resource ID, address, environment, business service, exposure, authentication boundary, technology evidence, and source. Treat wildcard DNS, CDN endpoints, shared cloud addresses, abandoned records, subsidiaries, and third-party SaaS as attribution problems rather than automatic scope additions.

Identity is part of the attack surface: test accounts, service principals, APIs, federation, exposed credentials, and support workflows can matter more than ports. Keep discovered identities and secrets out of notes or AI prompts unless the engagement’s handling rules explicitly permit them.

Network discovery, service enumeration, and Nmap

Network enumeration progresses from host discovery to port state, service fingerprinting, protocol-aware checks, and manual confirmation. Rate, timing, UDP coverage, source location, and network controls all affect what a scan can observe. “Closed,” “filtered,” and “no response” are different evidence states.

The four-part Nmap guide series covers core scanning, service and OS detection, firewall behavior, and NSE. Use safe scripts first, pin tool versions, save machine-readable output, and never equate a service banner or automated version match with a confirmed vulnerability.

Articles: Nmap Part 1 · Part 2 · NSE scripts

Turn recon into hypotheses

Prioritize paths using business criticality, exposure, authentication, likely attack preconditions, observed defensive controls, and the objective—not merely the number of open ports. A mature recon output is a reviewed attack-surface map plus questions to validate, such as whether an exposed management service is truly internet reachable or belongs to a shared provider.

AI can summarize large scan results or correlate naming patterns, but it must not invent asset ownership, product versions, or exploitability. Keep the original scan artifacts and require each AI-produced claim to cite the underlying host, port, request, or source record.

Applied workflow — build an attributed attack-surface map

Effective reconnaissance is an evidence-reconciliation process. It joins supplied inventory with public observations and carefully controlled active validation, while preventing shared infrastructure, stale DNS, acquired companies, and third-party services from silently entering scope.

Normalize the seed set. Import approved domains, CIDRs, cloud accounts, applications, APIs, mobile backends, identity providers, repositories, subsidiaries, and third parties. Preserve the system of record and owner for every seed.
Collect passive observations by source. Record DNS and certificate names, registration data, public documents, code references, storage endpoints, exposure-engine observations, and historical records with collection time and source URL.
Resolve attribution before expansion. Use DNS chains, certificates, organization data, application content, cloud identifiers, supplied inventory, and owner confirmation. Assign confidence and status: confirmed, likely, ambiguous, shared-provider, third-party, or excluded.
Plan active validation. Group targets by risk and protocol; define source address, scan rate, timing, TCP/UDP coverage, retry policy, safe probes, and expected monitoring. Start narrow and increase breadth only when results and system health justify it.
Fingerprint at multiple layers. Separate network reachability, protocol behavior, TLS and HTTP characteristics, product evidence, authentication boundary, and application identity. Do not let one banner populate all fields.
Correlate identities and trust. Record federation endpoints, exposed administrative interfaces, service principals, API documentation, password-reset flows, support channels, and machine identities without collecting real credentials unnecessarily.
Convert observations into hypotheses. Examples include an orphaned DNS record, an internet-reachable management plane, a legacy authentication path, an exposed artifact repository, or a version that requires confirmation.
Review deltas with owners. Distinguish new assets from newly observed assets, document uncertainty, and route confirmed inventory gaps to the accountable team before vulnerability testing.

Asset record fields

Canonical identifier and aliases
Owner, business service, environment, and criticality
DNS, address, cloud, CDN, and provider relationships
Exposure, ports, protocols, and authentication
Technology evidence and confidence
Source, first/last seen, scope, and review state

Tool roles

Use DNS and certificate tools for naming evidence, Shodan/Censys-style indexes for historical exposure leads, Nmap for controlled network validation, HTTP and TLS clients for application-layer evidence, and Wireshark for protocol confirmation. Each tool answers a narrower question than “is this vulnerable?”

Safe lab exercise

Build a three-host private lab with a reverse proxy, one intentionally stale DNS entry, and one shared service. Start with only the parent domain and supplied inventory. Produce an attributed map that correctly separates confirmed, ambiguous, and out-of-scope observations.

1200km worked path

Follow the Nmap-assisted analysis guide, the Shodan + HexStrike workflow, and the OSINT exposure-map case study. Treat every enrichment result as a reviewable lead.

Evidence gate: an asset may enter active testing only when its attribution, scope state, owner or responsible provider, resolution path, collection time, and permitted probe class are recorded.

Module 3 — Vulnerability discovery and validation

5 topics

A finding becomes defensible when the affected component, version, preconditions, reproducibility, control context, and impact are supported by evidence.

Scanner output is a lead, not a verdict

Automated scanners provide breadth and repeatability, but banners, heuristic matches, generic checks, and incomplete authentication create false positives and false negatives. Preserve the plugin or template ID, evidence, request, response, confidence, and scanner version; then validate the exact deployed product and affected condition.

Use multiple tools only when they answer different questions. Duplicating five scanners does not replace manual validation. The PT Tools library separates discovery, web testing, credential auditing, and exploitation tools so the method drives selection rather than the other way around.

Manual validation and minimum necessary proof

Validate with the least harmful action that proves the condition. Confirm the request path, affected identity, required privileges, response difference, and repeatability. Prefer a benign marker, read-only query, or test object over sensitive-data access, destructive modification, or persistence.

Document why the proof is sufficient and where testing stopped. A report should never imply that code execution, privilege escalation, lateral movement, or data access occurred if only a version banner or scanner signature was observed.

CVE and exploit research

Correlate vendor advisories, NVD records, CISA KEV, exploit references, EPSS, product configuration, and deployment context. Public proof-of-concept code may be incomplete, unsafe, modified, or irrelevant to the installed version. Review source, isolate it, understand side effects, and test against a lab replica before any authorized production validation.

The Vulnerability Research field guide covers root-cause and exploit-development concepts; the threat–vulnerability–risk distinction explains why a CVE score alone does not determine priority.

Exploitability, reachability, and business impact

Prioritize using evidence: affected version, reachable path, authentication requirements, privilege gained, exploit maturity, known exploitation, compensating controls, asset importance, and blast radius. CVSS communicates severity characteristics; it is not proof that an organization is exposed or compromised.

1200km guide: CVSS v4.0 Practical Field Guide · CVE/CVSS intelligence workflow

Applied workflow — turn a scanner lead into a validated finding

Validation connects a technical observation to the exact affected component, reachable condition, authorized proof, and business consequence. The objective is not to maximize exploit execution; it is to reduce uncertainty with the minimum necessary change to the target.

Preserve the original lead. Save the scanner engine and version, policy, template or plugin ID, target, timestamp, request and response evidence, confidence, severity, and any authentication state.
Confirm asset identity. Verify that the responding service is the scoped asset rather than a CDN, WAF, proxy, shared address, honeypot, or redirected third party. Record the exact hostname, address, virtual host, route, and tenant context.
Identify the deployed component. Correlate vendor metadata, package or image inventory, authenticated configuration, software bill of materials, protocol behavior, headers, and owner knowledge. Treat banners as evidence with limited confidence.
Evaluate the affected condition. Read the vendor advisory and primary vulnerability record. Check fixed and affected versions, configuration prerequisites, platform, authentication, privileges, attack vector, mitigations, and whether the vulnerable code path is enabled and reachable.
Design minimum proof. Define a reversible request or state change that distinguishes vulnerable from non-vulnerable behavior without accessing unrelated data, executing destructive code, creating persistence, or increasing blast radius.
Validate controls and telemetry. Record WAF, EDR, identity, segmentation, runtime, and logging behavior. A compensating control may reduce exploitability without removing the underlying vulnerable condition; report both.
Determine consequence and confidence. Trace the validated primitive to realistic privilege, data, service, or attack-path impact. Separate demonstrated impact from plausible impact and assign confidence to each conclusion.
Stop, clean up, and retest safely. Remove test data or accounts, restore state, notify the owner, provide a remediation test, and retain the original evidence so closure can be compared with the same condition.

Finding evidence packet

Affected asset, component, version, and configuration
Primary advisory and vulnerability references
Preconditions and authorized reproduction
Sanitized request/response or state evidence
Observed controls, impact, confidence, and limitations
Cleanup and remediation-validation procedure

Decision sources

Vendor advisories establish the affected condition; NVD and CVSS describe standardized characteristics; CISA KEV records known exploitation for listed vulnerabilities; EPSS estimates exploitation probability; local inventory, reachability, controls, and asset context determine organizational exposure and priority.

Safe lab exercise

Scan an intentionally vulnerable Ubuntu or Metasploitable host, select three alerts, and build evidence packets. Confirm one, reject one false positive, and leave one unresolved because version or configuration evidence is missing. Explain why uncertainty is an acceptable result.

AI assistance boundary

AI may compare version ranges, summarize advisories, cluster duplicate alerts, and draft validation questions. It may not declare exploitability from a CVE match, choose or execute proof-of-concept code, or convert probability scores into factual compromise claims.

Evidence gate: promote a lead to a finding only when the scoped asset, affected component and condition, reproduction evidence, impact statement, confidence, control context, and cleanup state are independently reviewable.

Module 4 — Web applications and APIs

5 topics

Use a repeatable testing model that covers architecture, identity, authorization, sessions, input handling, business logic, APIs, clients, and deployment—not just an automated crawl.

Map the application before testing it

The OWASP Web Security Testing Guide provides a structured framework for application and web-service testing. Begin with architecture, entry points, trust boundaries, roles, data flows, technologies, and environment differences. Record a versioned test inventory so omissions and retests are visible.

For each test, define the identity used, request, expected security property, observed behavior, evidence, and cleanup. Avoid reporting generic missing headers or version strings as high-impact vulnerabilities without a credible path and context.

Primary: OWASP WSTG · 1200km: Secure Code / Application Security

Authentication, session, and authorization testing

Test registration, recovery, MFA, session lifecycle, token handling, role definitions, object-level authorization, and administrative workflows. The central question is whether each server-side action enforces the intended identity and permission—not whether the user interface hides a button.

Build a role–action–object matrix and test allowed and denied paths with controlled accounts. Preserve evidence without retaining real user tokens or data. Reauthentication and step-up controls should be evaluated for sensitive operations.

Input handling and business-logic abuse

Injection, cross-site scripting, request forgery, file handling, deserialization, path traversal, and server-side request forgery require context-specific validation. Business-logic flaws often arise from valid operations used in an unintended sequence, at an unintended frequency, or under the wrong identity.

Fuzzing can expand coverage, but manual reasoning is required to understand state, invariants, and impact. Rate-limit tests and workflow manipulation must stay within the ROE to avoid availability or financial effects.

Burp Suite, ZAP, browser tools, and evidence

An intercepting proxy supports request capture, replay, comparison, and controlled mutation; browser developer tools reveal client behavior; scanners add breadth; command-line tools support repeatability. The Burp Scanner guide and Burp interface-testing tutorial show how to turn proxy observations into structured evidence.

For an AI-assisted lab workflow, see Cursor + HexStrike + Burp MCP. Treat the model as a planning and interpretation layer; the proxy history remains the authoritative record.

Applied workflow — test one business transaction end to end

The strongest web assessment follows data and authority through a complete transaction. It tests the browser or client, edge controls, application, API, identity provider, asynchronous workers, storage, and audit trail as one system instead of producing disconnected endpoint findings.

Model architecture and trust. Identify public and internal origins, reverse proxies, CDNs, WAFs, identity providers, APIs, queues, storage, administrative planes, mobile clients, webhooks, and third-party integrations.
Create controlled identities and data. Use at least two standard users from separate tenants or organizations plus an approved privileged role. Seed synthetic records with unique markers so cross-user and cross-tenant access can be proven safely.
Capture a valid baseline. Record the complete transaction, including redirects, tokens, cookies, headers, object identifiers, API calls, state changes, background jobs, notifications, and resulting audit entries.
Build the authorization matrix. For every action, compare unauthenticated, own-object, other-user, other-tenant, lower-role, expired-session, and administrative contexts. Validate on the server side; client-side restrictions are not authorization evidence.
Test session and token lifecycle. Evaluate issuance, storage, rotation, expiry, logout, revocation, device changes, MFA and recovery, step-up authentication, refresh behavior, and replay within the allowed accounts.
Test input and state transitions. Exercise type, size, encoding, sequence, concurrency, file, URL, and object-reference boundaries. Define rate and cost limits before automation, and stop when a test could affect availability or external systems.
Trace server-side effects. Verify where data is stored, whether jobs or webhooks execute, what permissions they use, how errors are handled, and whether security-relevant events reach an audit or detection pipeline.
Reproduce and minimize. Reduce each candidate to the smallest request sequence that proves the violated security property, sanitize secrets, preserve both allowed and denied comparisons, clean synthetic data, and retest the fix.

Coverage inventory

Roles, tenants, objects, actions, and expected decisions
Authentication, recovery, MFA, and session states
Web, REST, GraphQL, WebSocket, and webhook surfaces
Uploads, downloads, exports, and asynchronous jobs
Administrative and support workflows
Security logging, notifications, and response behavior

Evidence pattern

Preserve a sanitized baseline request, one controlled mutation, the response and resulting state, identity and tenant context, timestamps, proxy history reference, server or audit event where available, expected behavior, observed behavior, and cleanup confirmation.

Safe lab exercise

Use an intentionally vulnerable web lab with two tenants. Select one export or object-update transaction, build the role–action–object matrix, validate an authorization weakness using synthetic records, then add a server-side check and demonstrate the denied retest.

Tools and interpretation

Use Burp Suite or ZAP for history and controlled replay, browser tools for client state, API clients for reproducible collections, and application logs for server confirmation. AI may compare flows and suggest untested states; it cannot prove a server-side effect absent evidence.

Evidence gate: report a web or API finding only when the tested identity, tenant, object, action, expected security property, observed result, downstream effect, and reproducible sanitized evidence are explicit.

Module 5 — Cloud, containers, and Kubernetes

5 topics

Cloud testing combines provider authorization, identity, control-plane APIs, workload exposure, data paths, and audit evidence. A hostname scan alone is not a cloud assessment.

Provider policy, tenant boundaries, and shared responsibility

Confirm the cloud provider’s current testing policy, tenant and subscription IDs, regions, managed-service restrictions, and prohibited actions. Distinguish customer configuration from provider infrastructure, and do not treat shared service endpoints as owned targets.

Map internet exposure, control-plane permissions, workload identities, secrets, storage, network policy, logging, and cross-account trust. Use resource IDs and audit timestamps rather than ambiguous IP-only attribution.

Cloud identity and privilege paths

Review users, groups, roles, service accounts, managed identities, federation, OAuth grants, API keys, conditional access, and permission boundaries. Effective privilege is the combination of direct grants, inherited roles, trust relationships, and the ability to modify another identity or workload.

The GCP penetration-testing guide provides a platform-specific workflow. Pair it with the identity attack-surface model so permissions are analyzed as paths, not isolated findings.

Kubernetes and container assessment

Assess exposed control planes, authentication, RBAC, admission, workload identities, service accounts, secrets, network policy, image provenance, host mounts, privileged workloads, and escape paths. A cluster is both an API authorization system and a workload runtime.

The Black-Box Kubernetes Penetration Testing Playbook organizes discovery and validation while preserving a black-box evidence boundary. Use disposable lab clusters for intrusive container and privilege tests.

Cloud evidence, cost, and cleanup

Capture provider audit events, resource diffs, identity decisions, and relevant requests. Tag test resources, set budgets and expiry, rotate temporary credentials, delete created objects, restore policy changes, and verify cleanup through the control plane. Report residual risk if a created token, snapshot, role, or public object cannot be conclusively removed.

Applied workflow — analyze a cloud privilege path without losing tenant context

Cloud assessments should be resource- and identity-aware from the first API call. The same public IP can represent provider infrastructure for many customers, while a low-visibility permission on one role can control a sensitive workload. Resource IDs, effective permissions, trust, and audit events are stronger evidence than network appearance alone.

Establish the authorized control plane. Record organization, tenant, account, subscription, project, region, cluster, provider policy, test identity, allowed services, cost limits, and prohibited provider-layer actions.
Build a resource and ownership graph. Inventory public endpoints, workloads, storage, databases, functions, registries, secrets, networks, clusters, CI/CD identities, SaaS integrations, and accountable teams using immutable provider identifiers.
Calculate effective identity. Trace direct and inherited roles, groups, resource policies, federation, workload identity, service-account impersonation, permission boundaries, conditions, delegated administration, OAuth consent, and cross-account trust.
Map reachable data and execution paths. Ask which identity can read secrets, alter code or images, attach a role, modify a policy, create a key, invoke a workload, access metadata, change logging, expose storage, or move into another account.
Review workload boundaries. For containers and Kubernetes, connect RBAC, service accounts, admission, security context, host access, network policy, secret mounts, image provenance, node permissions, and cloud workload identity.
Validate with reversible actions. Prefer policy simulation, read-only inventory, denied requests, synthetic objects, short-lived tagged resources, and test identities. Any permission change or resource creation requires a documented rollback and owner.
Observe the defensive path. Correlate cloud audit, identity, network, workload, Kubernetes audit, runtime, and SIEM events. Verify event latency, actor attribution, source context, rule behavior, and analyst routing.
Reconcile and clean up. Delete tagged resources, revoke sessions and temporary keys, restore policies, confirm logging, check costs, compare inventory with the pre-test baseline, and retain provider event IDs as evidence.

Cloud evidence packet

Tenant/account/project and immutable resource ID
Test principal and effective permission chain
Policy, trust, condition, and workload context
Sanitized API request and provider event ID
Before/after state and defensive observations
Cost, expiry, credential, and cleanup confirmation

Identity references

Use the AWS IAM overview, Entra ID overview, Google Cloud IAM guide, and Kubernetes RBAC guide to interpret provider-specific objects without collapsing them into one generic “cloud role.”

Safe lab exercise

Create a disposable cloud project with a public test service, private storage, one intentionally over-permissioned workload identity, audit logging, budget alerts, and an expiry tag. Demonstrate the privilege relationship with a synthetic object, confirm the audit trail, remediate the policy, and prove cleanup.

Worked material

Use the GCP testing guide, Kubernetes playbook, and AdversaryGraph cloud investigation case study as complementary offensive, platform, and evidence perspectives.

Evidence gate: a cloud finding must identify the exact tenant, resource, principal, effective-permission chain, reachable action, provider evidence, business consequence, defensive signal, and cleanup state.

Module 6 — Active Directory and identity attack paths

5 topics

Identity testing is relationship analysis: users, machines, services, certificates, policies, trusts, and delegated rights combine into paths that single-object reviews miss.

Directory and trust enumeration

Build a model of domains, forests, trusts, organizational units, privileged groups, service accounts, local administration, sessions, delegation, certificate services, and identity synchronization. Review collection permissions and protect directory datasets because graph exports can reveal sensitive attack paths.

1200km reference: Active Directory overview · AD trusts · Authorized AD lab setup

Kerberos and credential-service attack paths

Understand tickets, service principal names, delegation, preauthentication, credential material, and the difference between a protocol feature and a risky configuration. Kerberoasting, AS-REP roasting, ticket abuse, and replication-related paths each require distinct preconditions and produce different defensive evidence.

Use the Kerberoasting attack reference alongside Kerberoasting detection guidance. Offensive validation is incomplete if it cannot tell defenders which logs and observable behaviors should have existed.

ADCS, delegation, ACLs, and control relationships

Certificate templates, enrollment endpoints, object permissions, resource-based delegation, Group Policy, and replication rights can create privilege paths without a software vulnerability. Validate the exact principal, right, template condition, and reachable service; avoid generic “ADCS vulnerable” conclusions.

The ADCS primer, ESC1 reference, and controlled HexStrike ADCS ESC8 lab connect architecture, evidence, and a lab-only AI-assisted workflow.

Identity laboratory progression

Start with an isolated AD domain, then add certificate services, Linux identity, Entra ID, and a logging stack. Snapshot each stage, use synthetic identities, document normal traffic, and validate one attack path plus its detection before chaining scenarios.

Labs: Lab architecture · Entra ID · Linux identity · Domain compromise scenario

Applied workflow — prove one identity control path and its detection

Identity environments are graphs of authority. A standard user may influence a service account, group, certificate template, application, device, or synchronized cloud identity that ultimately controls a protected resource. The assessment should explain the complete path and the conditions that break it.

Define identity tiers and protected actions. Identify workforce, service, device, application, privileged, emergency, and external identities; authentication systems; trust boundaries; and the business operations that require stronger protection.
Collect the directory model with minimum privilege. Record domains, forests, tenants, trusts, OUs, groups, roles, sessions, SPNs, delegation, certificate services, synchronization, local administration, policies, and object-control rights.
Normalize control relationships. Distinguish membership, ownership, write rights, delegation, impersonation, certificate enrollment, password or key reset, consent, session control, local execution, and policy modification. “Can reach” is not the same as “can control.”
Select a path tied to an objective. Prioritize paths from the assumed starting identity toward a protected action using preconditions, current sessions, control reliability, operational impact, and expected telemetry—not graph length alone.
Validate each edge independently. Confirm the exact principal, target, permission, protocol, service state, authentication condition, and resulting authorization decision. Use test objects and reversible changes where possible.
Observe protocol and control evidence. Correlate directory changes, Kerberos, LDAP, certificate, endpoint, cloud identity, and SIEM events. Note which edge was prevented, merely logged, detected, or investigated.
Remediate the relationship. Remove unnecessary rights, redesign delegation, harden templates, isolate tiers, rotate affected credentials, reduce standing privilege, and validate that required administration still works.
Retest path closure. Re-run the same edge with the same test identity, confirm the denial and logs, then recalculate whether an alternate path remains.

Path record

Starting identity and authentication assurance
Each principal, object, permission, and protocol edge
Required service, session, template, or policy state
Authorized proof and before/after evidence
Expected and observed telemetry per edge
Remediation owner and alternate-path review

Protocol study path

Start with Kerberos, LDAP, AD trusts, and ADCS. Then study attack and detection pairs such as Kerberoasting and its detection guide.

Safe lab exercise

Deploy the AD lab with synthetic users, one service account, a deliberately risky delegation or certificate relationship, endpoint logging, directory auditing, and a SIEM. Validate one edge, observe the events, remediate it, and prove the path is closed.

Hybrid extension

Add an Entra ID lab and trace one synchronized or federated identity path. Keep on-premises object rights, cloud roles, OAuth grants, conditional access, device state, and token lifecycle as distinct evidence layers.

Evidence gate: an identity path is validated only when every edge has a named principal, controlled object, effective right, protocol or service condition, resulting action, telemetry record, and remediation decision.

Module 7 — Privilege, lateral movement, and controlled impact

5 topics

Post-exploitation proves paths and defensive visibility with the minimum necessary action. It is not permission to collect everything reachable.

Privilege escalation as a path, not a checklist

Review service configuration, file and registry permissions, scheduled tasks, tokens, kernel or application exposure, cloud metadata, local groups, delegated rights, and secrets. Tie every candidate to the current identity, platform, version, precondition, and expected privilege transition.

Use a lab replica when an exploit risks a crash or state corruption. The ATT&CK exploitation-for-privilege-escalation page provides behavioral context; the report still needs target-specific evidence.

Credential access and secret handling

Credential testing may involve password policy, exposed secrets, hashes, tokens, cookies, keys, service credentials, or memory access. Define whether collection, cracking, replay, and storage are authorized separately. Prefer synthetic accounts and test secrets wherever possible.

Password-recovery tooling has legitimate uses but creates sensitive artifacts. The HexStrike hub includes ZIP, Office, and PDF recovery labs; apply them only to authorized recovery samples and keep hashes, wordlists, and recovered material within the evidence policy.

Pivoting and lateral movement

Pivoting changes the network vantage point; lateral movement changes the accessed system or identity. Before either, define approved routes, target tiers, protocols, source addresses, credential use, and segmentation expectations. Log each hop so defenders can reconstruct the path.

The single-target to subnet-compromise lab illustrates AI-assisted chaining in a controlled environment. Its lesson is the path and telemetry—not permission to automate movement in a production network.

Impact simulation, persistence, and cleanup

Use reversible proof: a benign marker, test record, synthetic file, controlled account, or pre-agreed simulation. Denial of service, destructive actions, ransomware-like encryption, production persistence, bulk data access, and safety-system interaction require exceptional explicit authority and often should be represented rather than executed.

Maintain a change ledger and remove payloads, users, keys, tasks, services, files, rules, tunnels, cloud resources, and test data. Verify cleanup independently and disclose anything that cannot be confirmed.

Applied workflow — validate a post-exploitation path with minimum impact

Post-exploitation answers a bounded question about privilege, reachability, trust, or defensive response. It should not become open-ended collection. Every transition needs a reason, a permitted proof, a telemetry expectation, and a cleanup action before execution.

Reconfirm the current state. Record the controlled identity, host or workload, integrity or privilege level, network vantage point, acquired capability, evidence source, and the objective that requires another step.
Enumerate locally before acting. Review platform, patch and configuration evidence, execution boundaries, services, permissions, scheduled activity, secrets locations, network routes, and defensive controls. Avoid broad collection unrelated to the objective.
Rank privilege transitions. Prefer configuration and delegated-right paths that can be proven reversibly. Evaluate required version, access, interaction, stability, likely side effects, and telemetry before considering exploit-based transitions.
Control credential handling. Use synthetic or engagement-specific credentials when possible. If collection of real material is authorized, minimize fields, encrypt evidence, restrict access, prohibit reuse, rotate promptly, and document destruction.
Plan each pivot. Identify source, destination, protocol, port, credential or token, expected segmentation decision, defensive signal, transfer requirement, and rollback. Do not use a newly reachable subnet as automatic permission to scan it.
Demonstrate controlled impact. Use a unique marker, synthetic record, harmless test file, approved account, or pre-staged canary. Record the proof and stop at the objective instead of collecting additional data.
Pair execution with observation. Capture endpoint, identity, network, application, cloud, and SIEM evidence. Note prevention, logging, alert creation, enrichment, analyst triage, containment, and communication separately.
Perform independent cleanup verification. Remove accounts, keys, tokens, tasks, services, files, routes, listeners, tunnels, firewall rules, payloads, cloud objects, and test records; then have a second reviewer compare the change ledger with actual state.

Transition record

Objective and reason for continuing
Source identity, asset, privilege, and capability
Destination and approved protocol or action
Preconditions, expected result, and stop point
Operator and defensive timestamps
Changes, artifacts, secrets, and cleanup owner

When to simulate

Represent rather than execute actions that could interrupt service, encrypt or delete data, affect safety, trigger financial transactions, send external messages, expose regulated records, create durable persistence, or make recovery uncertain. The report must state that impact was simulated.

Safe lab exercise

Use the isolated subnet-compromise lab to document one privilege transition and one approved pivot. Replace unrestricted compromise goals with a synthetic marker, a route allowlist, a change ledger, and a second-person cleanup review.

Defensive handoff

For each transition, provide the exact behavior, ATT&CK mapping, affected control, available data source, observed event, analytic result, false-positive considerations, containment opportunity, and retest procedure. Tool names alone are not detection requirements.

Evidence gate: continue beyond the current foothold only when the next transition is explicitly in scope, necessary for an objective, reversible, observable, assigned a cleanup action, and supported by a defined stop point.

Module 8 — Threat-informed adversary emulation and purple teaming

5 topics

Threat-informed testing asks whether relevant behaviors are prevented, observed, detected, investigated, and contained—not merely whether an operator can run a tool.

Build an ATT&CK-based emulation plan

MITRE’s adversary-emulation plans use public threat reporting and ATT&CK to model representative behavior. Select techniques supported by current evidence and relevant to the organization, document assumptions and substitutions, then map each action to a defensive hypothesis and expected telemetry.

ATT&CK is not a linear checklist and matrix coverage is not equivalent to security. Use the ATT&CK working guide and Threat Matrix to build an actor-informed layer without claiming unvalidated coverage.

Primary: MITRE adversary-emulation plans

Atomic tests, CALDERA, and scenario chains

Atomic tests isolate a technique for repeatable control validation; CALDERA and other emulation platforms can sequence post-compromise behaviors. Start with one observable action, verify telemetry and cleanup, then expand into a chain. Automation does not remove the need for ROE, target controls, or human approval.

1200km path: AdversaryGraph Attack Simulation · Attack–Defense Simulation Framework

Purple-team feedback loop

A purple-team exercise pairs operator actions with defensive observation. For every step, record prevention, telemetry availability, analytic behavior, alert routing, analyst interpretation, containment, and recovery. Share ATT&CK technique IDs as a common language, but preserve the exact procedure and environment-specific evidence.

The Operation Desert Hydra project shows a CTI-to-detection pipeline where behavior mapping becomes validated analytics instead of a report-only artifact.

From test execution to defensible coverage

Separate “rule exists,” “telemetry exists,” “test executed,” “alert fired,” and “analyst responded.” Each is a different maturity state. Record the test artifact, data source, time window, rule version, result, false-positive considerations, owner, and retest date.

A failed detection is useful evidence when the execution was valid and reproducible. Route it into a telemetry, analytic, workflow, or control backlog rather than hiding it behind an aggregate coverage percentage.

Applied workflow — run a threat-informed purple-team validation

A defensible emulation links source-backed adversary behavior to a relevant organizational hypothesis, a safe procedure, expected telemetry, analytic logic, analyst action, and a retest. It does not copy an actor name onto a generic tool sequence or claim “coverage” because a technique appears in a matrix.

Define the decision and protected process. State which prevention, telemetry, detection, triage, or response capability the exercise will validate and why the behavior matters to this environment.
Build a source-backed behavior set. Use current threat reporting, ATT&CK procedure examples, incident evidence, and local context. Record source date, confidence, platform, identity, software, and procedure—not only technique IDs.
Translate behavior into a safe test. Preserve the observable properties required by the hypothesis while replacing destructive payloads, real targets, sensitive data, and uncontrolled infrastructure with benign equivalents.
Write the telemetry contract. For each action, name the endpoint, identity, network, application, cloud, or audit events expected; required fields; time synchronization; collection path; retention; and query used to confirm ingestion.
Validate atomically first. Execute one bounded procedure, confirm target state, evidence, telemetry, and cleanup, and only then combine tested procedures into a scenario chain.
Observe the complete defensive lifecycle. Record control prevention, raw telemetry, enrichment, analytic evaluation, alert creation, routing, analyst interpretation, escalation, containment, and recovery as separate outcomes.
Classify the gap accurately. Distinguish missing telemetry, malformed fields, delayed ingestion, logic failure, excessive noise, disabled rule, routing failure, playbook weakness, analyst-context gap, or containment limitation.
Improve and retest the same procedure. Version the data source, analytic, test artifact, environment, expected result, and acceptance criteria. Re-execute under comparable conditions and retain both failed and successful evidence.

Validation record

Source behavior, procedure, and ATT&CK mapping
Environment relevance and hypothesis
Test artifact, inputs, target, and cleanup
Expected data sources, fields, and timing
Prevention, telemetry, analytic, alert, and response results
Gap owner, change, acceptance criteria, and retest

Tool selection

Use Atomic Red Team for narrow repeatable procedures, CALDERA or a controlled framework for sequenced emulation, custom scripts when exact behavior or safety needs it, and AdversaryGraph for mapping scenarios to ATT&CK, detections, evidence, and validation results. The procedure—not the platform name—is the unit of evidence.

1200km case-study path

Study Operation Desert Hydra, then use the Attack–Defense Simulation Framework and AdversaryGraph Attack Simulation guide to build a source-to-test-to-detection evidence chain.

Safe lab exercise

Select one behavior relevant to the lab platform, create an ATT&CK Navigator layer, implement a benign atomic test, define expected logs, execute it, query raw events, validate or improve one analytic, record analyst actions, clean up, and rerun the identical versioned test.

Evidence gate: never mark a technique “covered” without a versioned procedure, successful controlled execution, confirmed required telemetry, an evaluated analytic or control, documented analyst/response outcome, and an environment-specific limitation statement.

Module 9 — AI-assisted offensive security and MCP

6 topics

AI can accelerate interpretation and orchestration, but it also adds a non-deterministic planner, new data flows, tool permissions, prompt-injection risk, and supply-chain trust to the engagement. Use the AI Security adversarial-testing model to define repeatable evaluations, evidence, and human decision gates.

Appropriate roles for an offensive-security assistant

Useful low-risk roles include summarizing authorized scan output, normalizing evidence, explaining protocols, proposing test cases, comparing requests, drafting reproducible notes, mapping observed behavior to ATT&CK, and suggesting questions for human review. Higher-risk roles include selecting targets, invoking exploit tools, changing infrastructure, moving laterally, or handling credentials.

Treat output as a hypothesis. Models can hallucinate options, misread banners, conflate products, invent CVEs, or omit side effects. The Complete Guide to AI-Driven Penetration Testing places AI inside a reviewable modern workflow rather than presenting autonomy as evidence.

Hub: AI in Offensive Security · The AI Revolution in Offensive Security

MCP, tool orchestration, and HexStrike

Model Context Protocol can expose tools and resources to an AI client. That creates a powerful separation between a reasoning interface and execution services, but the client trusts configured servers and a local server runs with the access available to its process. Tool descriptions are not authorization controls.

HexStrike is the site’s practical research hub for MCP-based offensive workflows. Start with installation and MCP configuration, then study the isolated Kali/Ubuntu/Ollama architecture before attempting a lab scenario.

Project: HexStrike repository · HexStrike documentation

Guardrails for AI-connected security tools

Run tools in a dedicated lab or constrained execution container with least privilege and explicit egress rules.
Allowlist targets and operations at the tool layer; do not rely on the system prompt to enforce scope.
Require human confirmation for network changes, exploitation, credential use, file writes, persistence, lateral movement, and external communication.
Separate secrets from prompts and logs; use short-lived scoped credentials and redact evidence sent to remote models.
Record the model, prompt context, proposed action, tool call, parameters, result, reviewer, and final decision.
Assume retrieved web pages and tool output may contain indirect prompt injection.

OWASP identifies prompt injection and excessive agency as material risks, and the MCP security model places responsibility on clients, servers, and operators to implement access controls, consent, input validation, trusted-server selection, and sandboxing.

Primary: OWASP Prompt Injection · MCP trust model

Testing LLM applications and agents

AI-system red teaming extends application testing with prompt injection, indirect instructions, sensitive-information disclosure, unsafe output handling, retrieval poisoning, excessive agency, tool misuse, identity and privilege boundaries, memory, cross-agent trust, and unbounded resource consumption.

Test the complete system—not only the model. Trace input through retrieval, prompts, policy, tools, authorization, data stores, output rendering, audit, and human approval. The Practical Attacks Against LLM Agents article provides a dedicated lab-oriented treatment.

Primary: OWASP Agentic Security Initiative

Validate AI output and preserve provenance

Keep raw tool output separate from model summaries. Every claim should point to a request, response, scan record, log, screenshot, source document, or reproduced observation. Record uncertainty and discarded suggestions; do not silently convert model confidence into finding severity.

The Nmap meets ChatGPT and Burp Suite with LLMs guides are best used as assisted-analysis patterns: the authoritative evidence remains the scan or proxy record.

Applied workflow — operate an AI + MCP assessment stack safely

An AI-connected offensive toolchain is a privileged automation system. Its risk is determined by the combined model, client, prompts, retrieved content, MCP servers, tool schemas, credentials, execution host, network reach, approval design, and logs. A persuasive chat response is never a substitute for deterministic tool evidence.

Draw the trust and data-flow diagram. Identify the user, client, local and remote models, MCP servers, tool processes, secrets, retrieved sources, target network, storage, logs, and every boundary where assessment data leaves the controlled environment.
Classify tools by effect. Separate read-only interpretation, passive retrieval, active discovery, authentication, file write, code execution, exploitation, credential use, privilege change, persistence, movement, data transfer, and external communication. Assign a default-deny policy to higher-impact classes.
Constrain at the execution layer. Enforce target allowlists, network egress, filesystem mounts, process limits, command or argument validation, timeouts, rate limits, credential scope, sandboxing, and disposable runtime state outside the prompt.
Design explicit approvals. Show the operator the selected target, tool, normalized arguments, expected effect, data being sent, rollback, and evidence location. Require fresh confirmation for state-changing or credential-bearing actions; do not approve an opaque multi-step plan.
Validate schemas and responses. Tool inputs should use narrow types and enumerations, reject unknown fields, normalize identifiers, and return structured status, observations, artifact references, errors, and side effects. Free-form model prose must not become an executable argument without validation.
Assume tool output is untrusted. Web content, repository text, scan banners, documents, and MCP resources may contain indirect instructions. Keep data distinct from system policy and prevent retrieved content from authorizing a tool call.
Record provenance end to end. Log the request ID, user, model and version, system/policy version, prompt context reference, provider, tool server/version, approved call, normalized arguments, raw result hash, parsed result, reviewer decision, and resulting finding or discarded lead.
Test failure and abuse cases. Exercise unavailable servers, malformed schemas, timeouts, duplicate calls, prompt injection, over-broad targets, path traversal, secret leakage, approval bypass, stale context, tool-result spoofing, and partial cleanup before using the stack in an engagement.
Keep the human analytical gate. Independently verify asset attribution, scope, product and version, command safety, CVE relevance, ATT&CK mapping, finding severity, evidence quality, and remediation before acceptance.

HexStrike learning path

Approval record

Objective, scope reference, user, and target
Model proposal and cited source artifacts
Tool name, server version, and normalized arguments
Effect class, data disclosure, and rollback
Human approval or rejection with timestamp
Raw result, parser result, evidence hash, and review state

Safe lab exercise

Deploy the AI client and HexStrike server in separate constrained containers or VMs connected only to an isolated vulnerable lab. Allow read-only discovery first. Add one active tool behind an approval gate, then test target rejection, argument validation, timeout, prompt injection in tool output, audit completeness, and teardown.

When not to use AI

Avoid remote models when evidence cannot leave the environment, provenance cannot be retained, targets or authority are ambiguous, output cannot be independently checked, tool effects cannot be constrained, the operator lacks protocol expertise, or the task is deterministic and safer as a reviewed script.

Example assistant contract

The assistant may propose a scoped plan, explain why each step answers the objective, cite source artifacts, and prepare one normalized tool call at a time. It must display uncertainty, refuse out-of-scope targets, never treat retrieved text as authorization, never fabricate successful execution, preserve raw results, and wait for explicit approval before any active or state-changing call.

Evidence gate: no AI-produced observation becomes a finding until an authorized human can trace it to scoped deterministic evidence, reproduce the result, verify the interpretation, and account for every tool effect and disclosed data element.

Module 10 — Laboratories, tool discipline, and reporting

6 topics

Practice should be isolated, observable, reproducible, and tied to defensive learning. Reporting is part of the technical work, not an administrative afterthought.

Design a safe offensive-security laboratory

Use dedicated virtualization or cloud accounts, host-only or tightly controlled networks, synthetic data, snapshots, known-vulnerable targets, central logging, and resource limits. Prevent accidental routing to production or the public internet, and make teardown repeatable. Do not place malware or vulnerable services on a bridge without explicit containment.

The 1200km Lab Work index includes network, web, identity, malware, cloud, and attack-simulation environments. A practical starting point is the vulnerable Ubuntu lab with a full HexStrike walkthrough; Metasploitable is covered in the HexStrike + Codex lab.

Lab rule: use private address space, disable unintended egress, snapshot before exploitation, and verify that no test credentials or payloads are reused outside the lab.

Choose tools by evidence need

Recon and network: Nmap, Masscan where rate is explicitly controlled, DNS and certificate tools, Wireshark.
Web and API: Burp Suite, OWASP ZAP, browser developer tools, API clients, content discovery and carefully scoped fuzzers.
Vulnerability validation: vendor checks, Nuclei templates under review, vulnerability scanners, Metasploit in labs or explicitly authorized validation.
Identity: native directory tools, BloodHound-style relationship analysis, Kerberos and certificate assessment tools in controlled environments.
Emulation: Atomic Red Team, CALDERA, and scenario-specific scripts with deterministic cleanup.
AI orchestration: HexStrike and approved MCP servers inside constrained execution boundaries.

Tools age; methodology and evidence requirements persist. Record versions, configuration, scope, rate, templates or modules, and raw output so results can be reproduced and challenged.

Libraries: PT Tools & Techniques · HexStrike · AI Offensive Security

Write findings that engineering teams can act on

Each finding should include affected scope, security property, preconditions, reproducible evidence, impact, likelihood and confidence, relevant attack path, observed controls, remediation options, validation notes, and cleanup status. Separate root cause from symptom and business impact from generic severity labels.

The engagement report should also answer the original objective: which paths succeeded, which were prevented or detected, where testing stopped, what remains unknown, and what should be prioritized. Include a technical appendix and a consumer-specific executive summary without changing the underlying judgment.

Remediation, detection handoff, and retest

A retest verifies the same affected condition and plausible bypasses after remediation. Record code, configuration, identity, or architectural changes; confirm the security property; and update rather than erase the original evidence. If a compensating control is accepted, state what it prevents or detects and what residual path remains.

Map validated behavior to telemetry and detection work. The CTI-to-detection module and Detection Engineering Techniques provide the blue-team handoff.

Recommended learning order

Networking, operating systems, HTTP, identity, scripting, version control, and evidence handling.
Authorization, ROE, lab isolation, reconnaissance, and manual validation.
Web and API testing with an intercepting proxy and OWASP methodology.
Windows/Linux privilege concepts, Active Directory, cloud identity, containers, and Kubernetes.
ATT&CK-based adversary emulation paired with logging and detection validation.
AI assistance and MCP only after you can independently verify the underlying tool, protocol, command, and result.

A strong portfolio shows reproducible lab design, bounded testing, clear evidence, defensive relevance, and honest limitations. Start with the Basic Toolkit for Penetration Testing, then use the lab index and local article archive to deepen one domain at a time.

Capstone workflow — deliver a reviewable attack–defense assessment

The capstone joins the entire guide into one controlled engagement. The quality measure is not the number of tools or exploits used; it is whether authority, evidence, technical reasoning, defensive value, cleanup, and communication remain intact from the first hypothesis through the retest.

Build the laboratory. Use isolated networks or accounts, synthetic identities and data, snapshots or infrastructure as code, time synchronization, endpoint and identity logging, network visibility, a SIEM, resource limits, and verified teardown.
Write the engagement pack. Define sponsor decision, objective, assumed access, scope, exclusions, permitted techniques, test window, data policy, contacts, stop conditions, expected telemetry, success criteria, and cleanup plan.
Establish a normal baseline. Record expected services, identities, application workflows, cloud resources, logs, alerts, and performance before testing. A lab without known normal state cannot explain what changed.
Map and validate the attack surface. Reconcile inventory, perform controlled discovery, attribute observations, select one reachable hypothesis, and validate only the conditions needed for the objective.
Execute a short scenario. Chain two or three previously validated reversible procedures, maintaining action IDs, evidence references, defensive timestamps, approval gates, and cleanup tasks.
Measure defense at every layer. Record prevention, raw telemetry, analytic behavior, alert enrichment, routing, analyst understanding, containment, and recovery. Do not compress these states into one pass/fail label.
Report for multiple consumers. Produce an executive decision summary, objective result, attack-path narrative, prioritized findings, technical evidence appendix, detection gaps, remediation backlog, limitations, and residual risk.
Remediate and retest. Change the vulnerable condition or control, rerun the same versioned proof under comparable conditions, verify business functionality and telemetry, and retain before/after evidence.
Close and archive responsibly. Verify teardown, revoke credentials, destroy or retain evidence according to policy, disclose unresolved artifacts, capture lessons, and preserve only the sanitized portfolio material approved for publication.

Recommended capstone variants

External service → validated web authorization gap
Standard identity → risky directory-control path
Cloud workload → excessive identity privilege
Threat report → ATT&CK scenario → detection retest
AI + MCP → constrained lab tool orchestration

Quality rubric

Authority and scope are unambiguous
Every claim points to preserved evidence
Impact and uncertainty are stated honestly
Actions are reversible and cleanup is verified
Defensive observations are reproducible
Retest proves the changed security property

Report architecture

Use a decision summary; engagement authority and limitations; objective results; attack-path timeline; finding records; control and telemetry observations; ATT&CK mappings with procedures; remediation plan; retest criteria; cleanup attestation; and a technical appendix containing sanitized evidence references.

Portfolio publication

Publish only synthetic lab targets and explicitly approved evidence. Remove customer names, real addresses, credentials, internal architecture, unpublished vulnerabilities, and operational details that create avoidable risk. Link the write-up to the relevant 1200km lab, tool guide, and defensive outcome.

Completion gate: the assessment is complete only after every objective has a supported result or stated limitation, every change has a verified cleanup state, findings have owners and retest criteria, and the sponsor receives a decision-ready summary.

Module 11 — Mobile and thick-client security

5 topics

A client assessment covers locally executed code, operating-system boundaries, local data, update and distribution, inter-process communication, network behavior, remote APIs, and business logic. The client and backend must be scoped and reported separately.

Architecture, build provenance, and assessment scope

Record the application name, package or bundle identifier, version, build number, platform and supported OS versions, distribution channel, signing identity, architecture, third-party frameworks, update mechanism, backend environments, deep links or custom protocols, local integrations, and user roles. Confirm whether source code, symbols, test accounts, devices, and backend access are available.

Distinguish the client security claim from the service security claim. A mobile binary may securely store a token while the API authorizes objects incorrectly; a desktop client may verify updates correctly while a local privileged service exposes an unsafe interface. Each layer needs its own requirements and evidence.

Primary: OWASP MASVS · OWASP TCASVS · OWASP ASVS for the backend

Local data, cryptography, privacy, and platform interaction

Map sensitive values from entry to storage, memory, logs, notifications, screenshots, backups, clipboard, caches, databases, preferences, key stores, crash reports, analytics, and deletion. Verify that platform-provided storage and cryptographic APIs are used appropriately, keys are not equivalent to encrypted data stored beside them, and logout or account removal produces the intended lifecycle.

Review exported components, URL schemes and universal links, intents, IPC, document and file handlers, extensions, accessibility, embedded browsers, permissions, biometric gating, background execution, and interactions with other applications. Resilience controls such as obfuscation, integrity checks, and anti-debugging are defense-in-depth; they do not replace server authorization or secure key management.

Network communication, authentication, and backend trust

Inventory every destination, protocol, certificate-validation path, proxy behavior, WebSocket or push channel, telemetry endpoint, feature flag, and third-party SDK. Test the same authentication, session, object-level authorization, tenant isolation, rate, and business-logic properties required of a web API while preserving the mobile or desktop client’s state and device context.

Certificate pinning can add identity assurance for endpoints under the developer’s control, but its design must account for rotation, failure handling, and operational recovery. Bypassing a laboratory client control may help observe authorized traffic; it does not prove a production vulnerability by itself. The report should state the assumed device state and whether the test required a debug build, modified device, instrumentation, or source changes.

Static and dynamic analysis, update security, and supply chain

Static review identifies embedded secrets, endpoints, unsafe APIs, debug features, third-party components, signing configuration, and high-risk code paths. Dynamic review observes file access, process behavior, inter-process communication, network requests, library loading, permission use, update checks, and state changes. Neither mode is complete alone.

Verify package and update authenticity, transport, rollback behavior, version policy, code-signing and entitlement checks, privileged helper installation, dependency provenance, build configuration, debug artifacts, and release-channel separation. Preserve artifact hashes, signer information, build identifiers, tool versions, and analysis environment so the assessed binary can be identified later.

Applied workflow — assess a mobile or desktop client with traceable coverage

Use requirements to define coverage before selecting instrumentation. OWASP MASVS and MASTG provide mobile control and test mappings; TCASVS addresses locally executed desktop software. Tailor the requirements to the client’s threat model and record exclusions rather than claiming generic “full coverage.”

Freeze the test artifact. Hash the exact build, record source and signer, preserve installation and update packages, and identify backend environment and test identities.
Model architecture and data. Map sensitive values, local stores, processes, privileged helpers, IPC, platform APIs, remote endpoints, third-party SDKs, authentication, update, and trust boundaries.
Select versioned requirements. Build a MASVS/MASTG, TCASVS, and backend ASVS coverage matrix appropriate to the client. Mark not applicable, out of scope, and untested distinctly.
Establish controlled devices. Use dedicated emulators, simulators, VMs, or test devices with snapshots, synthetic accounts, network capture, instrumentation, and no personal data.
Perform static and dynamic review. Correlate code and configuration observations with actual runtime behavior; preserve raw artifacts and avoid equating a suspicious string with a reachable weakness.
Test data and identity lifecycles. Observe installation, first use, authentication, normal operation, backgrounding, offline use, token refresh, logout, account deletion, backup, restore, device change, and application removal.
Validate the backend independently. Replay authorized requests with controlled identities, test object and tenant authorization, and distinguish client-only restrictions from server-enforced decisions.
Review update and distribution. Validate signing, channel trust, version and rollback decisions, privileged installation behavior, and recovery from update failure without distributing modified production packages.
Report by security property. State affected artifact, platform, configuration, identity, requirement, evidence, business effect, assumed device state, remediation, and regression test.

Minimum evidence

Build hash, signer, version, and source
Architecture and sensitive-data flow
Versioned requirement and test identifier
Device/runtime state and instrumentation
Static observation plus runtime confirmation
Backend request, decision, and cleanup state

Safe lab exercise

Use a deliberately vulnerable mobile training application or a small self-built client connected to a local API. Seed synthetic secrets, capture normal behavior, verify one storage and one authorization property, change the implementation, and rerun the same requirement-linked tests.

Evidence gate: a client finding must identify the exact binary, platform and state, violated requirement, reachable behavior, backend dependence, observed impact, and reproduction that does not rely solely on a modified or rooted laboratory environment unless that is the stated threat model.

Module 12 — Human-layer and physical testing

5 topics

Social-engineering and physical exercises can affect real people, privacy, employment relationships, safety, and trust. They require special authorization, legal and HR review, strict data minimization, immediate safety escalation, and a learning-focused outcome.

Special authorization, participant protection, and exclusions

Define permitted populations, locations, communication channels, pretexts, languages, time windows, third parties, identity claims, data collection, credential handling, recording, escalation, and immediate exclusions. Prohibit targeting personal accounts, family members, medical or crisis themes, emergency services, safety systems, and vulnerable individuals unless a competent authority has approved an exceptional controlled design.

Use a small white team including the sponsor, security, legal/privacy, HR or people operations, communications, and physical safety where applicable. Establish a verification phrase, exercise contact, stop signal, real-incident handoff, and process for employees to independently verify suspicious requests.

Physical assessment boundaries and safety

Scope exact buildings, entrances, floors, restricted areas, hours, escort rules, badges, photography, props, parking, loading docks, tenant spaces, alarms, guards, and life-safety systems. Physical access authorization does not imply permission to bypass fire controls, enter hazardous spaces, confront staff, tailgate unknown people, manipulate vehicles, or remove production equipment.

Prefer observation, test badges, white-team escorts, instrumented doors, synthetic documents, and pre-staged evidence markers. Carry a verifiable authorization contact and stop immediately when challenged according to the ROE. Any real safety or criminal activity discovered during the exercise transfers to normal response procedures.

Measurement, reporting, debriefing, and organizational care

Aggregate results around control behavior: message delivery, secure email handling, identity verification, reporting rate and latency, SOC correlation, help-desk process, access control, visitor management, escalation, and containment. Limit personal attribution to the minimum required for remediation and approved case handling.

Debrief promptly, explain the tested behavior, reinforce how to verify and report, provide support channels, and publish lessons without ridicule. The purpose is to improve system design and decision support. A surprising pretext that damages workforce trust can be an operational failure even if engagement metrics are high.

Applied workflow — validate a synthetic identity-verification scenario

Choose one process. Select a support, payment, access, OAuth, MFA, visitor, or information-sharing workflow with a documented verification requirement.
Define safe outcomes. Use synthetic credentials, a training tenant, a benign landing page, test records, or a pre-staged physical marker. Do not collect real passwords or sensitive employee data.
Approve content and population. Have legal/privacy, HR, security, communications, and the process owner review audience, exclusions, wording, collection, retention, escalation, and debrief.
Instrument the full response path. Correlate delivery, participant action, report channel, mail or identity telemetry, SOC alert, analyst triage, process-owner response, and containment.
Run a limited pilot. Test with the white team or a small approved cohort, verify stop mechanisms and data minimization, then expand only if no unexpected harm appears.
Measure the control. Report aggregate outcomes and process failures; do not treat a single click as proof of compromise or an employee character judgment.
Debrief and improve. Update verification steps, user interfaces, technical controls, reporting channels, analyst context, and training; then repeat the same scenario to measure change.

Required artifacts

Special authorization and stakeholder approvals
Scenario, population, exclusions, and safe outcomes
Privacy notice, collected fields, and retention
White-team, stop, and real-incident procedures
Aggregate measurement and debrief plan
Control owner, improvement, and retest criteria

AI boundary

AI may help generate accessible variants, compare the scenario with policy, or aggregate de-identified outcomes. It must not personalize manipulation from private employee data, impersonate real people without explicit approval, make employment judgments, or retain participant content outside the approved system.

Evidence gate: do not launch until authority, participant safeguards, prohibited themes and targets, data minimization, real-incident escalation, debriefing, and the exact organizational control being measured are documented.

Module 13 — Red-team infrastructure and operations

5 topics

Operator infrastructure is part of the assessed risk. It must not become an unmanaged route into the client, a source of uncontrolled internet activity, or a repository of secrets and evidence without ownership.

Purpose-built architecture, segmentation, and lifecycle

Separate operator workstations, evidence storage, collaboration, redirectors or test endpoints, payload build systems, malware laboratories, AI/MCP services, and target-facing execution. Define which components are client-managed, operator-managed, cloud-hosted, local, temporary, or shared. Use dedicated accounts, projects, networks, domains, addresses, and naming that can be allowlisted and retired.

Document data flows, ingress, egress, administration, dependencies, backups, monitoring, patching, ownership, creation, and teardown. Infrastructure used for one client or classification should not silently persist into another engagement. Route higher-risk testing through isolated disposable environments instead of daily-use systems.

Operator identity, access, secrets, and approvals

Use named operator identities, MFA, least privilege, short-lived credentials, separate administrative paths, peer approval for high-impact actions, and emergency revocation. Keep target credentials, provider tokens, signing keys, payload secrets, API keys, and evidence encryption material in an approved secret-management system rather than scripts, chat, terminal history, or model prompts.

Record who may change scope allowlists, approve a tool invocation, retrieve evidence, access a client identity, sign an artifact, or modify logging. Break-glass access needs the same audit and post-use review as production administration.

Tool, artifact, payload, and dependency governance

Maintain an approved tool inventory with source, version, hash, license, expected network behavior, privilege requirement, configuration, update policy, and owner. Review templates, modules, proof-of-concept code, containers, packages, and MCP servers before use; a popular repository is not a trusted build.

Every generated artifact should have an engagement ID, purpose, target class, build recipe, hash, signer where applicable, expiration, expected effects, cleanup method, and storage location. Prefer benign test artifacts. Treat payloads and collected samples as controlled material even when they are designed for a lab.

Logging, health monitoring, deconfliction, and teardown

Centralize operator authentication, administrative change, tool invocation, target selection, network flow, approval, evidence access, and cleanup events. Synchronize time and preserve enough context to distinguish operator traffic from real malicious activity. Monitor resource health, rate, cost, egress, unexpected targets, duplicate calls, and external abuse reports.

Teardown includes cloud resources, DNS, certificates, storage, accounts, access grants, API keys, queues, test identities, redirectors, firewall rules, temporary repositories, AI indexes, model conversation data, and local artifacts. Verify removal from the authoritative control plane and document retention exceptions.

Applied workflow — build a disposable, auditable exercise environment

Define services and trust boundaries. Draw operator, evidence, AI/MCP, tool, target, collaboration, and administrative flows before provisioning.
Provision from reviewed configuration. Use version-controlled infrastructure definitions, pinned images and packages, target allowlists, egress policy, resource limits, tags, budgets, and expiration.
Create named access paths. Issue short-lived operator and service identities, separate administration, require MFA, and record high-impact approval roles.
Register tools and artifacts. Capture source, version, hash, configuration, effect class, privileges, expected communications, build recipe, cleanup, and owner.
Validate safety controls. Test blocked out-of-scope targets, blocked egress, failed approvals, duplicate calls, timeouts, secret redaction, log ingestion, emergency revocation, and restore.
Run a benign end-to-end dry run. Execute discovery against a lab target, save raw evidence, invoke an approved analysis path, observe monitoring, and complete cleanup.
Operate with continuous reconciliation. Compare active resources, identities, tools, target calls, evidence objects, and costs with the approved manifest throughout the exercise.
Destroy and attest. Tear down resources, revoke credentials, remove target artifacts, verify deletion, retain only approved evidence, and obtain a second-person review of exceptions.

Infrastructure manifest

Resource, owner, purpose, region, and expiry
Identity, role, credential lifetime, and reviewer
Tool, version, source, hash, and effect class
Target allowlist and egress policy
Logging, evidence, backup, and retention
Teardown check and residual exception

HexStrike architecture path

The HexStrike MCP orchestration architecture separates AI orchestration from the Kali execution environment. Extend that pattern with target allowlists, approval, structured tool schemas, read-only evidence mounts, egress controls, centralized audit, and deterministic teardown.

Evidence gate: infrastructure is ready only when every resource, identity, tool, target route, data store, approval, log, expiration, and teardown action exists in the reviewed manifest and the failure controls have been tested.

Related Cyber Knowledge: Cyber Threat Intelligence (CTI) — Module 4 — Collection Sources

Module 14 — Program governance and maturity

5 topics

A red-team program is a repeatable assurance capability, not a sequence of impressive one-off exercises. Governance should make authority, coverage, evidence, remediation, retesting, and organizational learning visible.

Engagement intake, prioritization, and portfolio balance

Prioritize assessments using business change, threat relevance, exposure, control uncertainty, incident lessons, regulatory commitments, high-risk identities, architectural concentration, release milestones, and time since meaningful validation. Do not allocate the entire program to whichever system is easiest to test or whichever tool produces the most findings.

Maintain a portfolio across external, application, cloud, identity, endpoint, human-layer, supplier, detection, and recovery questions. Match assessment type to the decision: architecture review, vulnerability assessment, penetration test, red team, purple team, tabletop, control test, or retest.

Metrics that preserve evidence and avoid false confidence

Useful measures include objectives answered, critical paths tested, validated findings by root cause, time to owner assignment, remediation age, retest closure, telemetry availability, analytic success, alert latency, analyst interpretation, containment, cleanup completeness, recurrent control gaps, and evidence quality.

Avoid counting technique IDs, tools executed, vulnerabilities scanned, emails clicked, or shells obtained as standalone success measures. These can reward unsafe breadth and hide whether the business question was answered. Report denominator, scope, time window, environment, test version, and limitations for every percentage.

Finding, detection, architecture, and process backlogs

Route results to the right backlog: software defect, vulnerable component, cloud or identity configuration, architectural weakness, inventory gap, telemetry gap, analytic gap, SOC workflow, access process, training need, or governance decision. One red-team report should not become a parallel issue tracker with no accountable engineering owner.

Each item needs an owner, affected scope, business decision, evidence reference, priority rationale, remediation or risk treatment, dependency, due date, validation method, and closure authority. Preserve links between a root cause and the multiple observations it produced.

Quality assurance, independent review, and ethical practice

Peer review engagement design, high-impact actions, findings, severity, ATT&CK mapping, AI-assisted conclusions, cleanup, and public communication. Separate operator self-assessment from sponsor acceptance. Independent reviewers should be able to challenge a conclusion using the preserved evidence without rerunning intrusive actions.

Maintain conflict-of-interest rules, disclosure processes, researcher safety, privacy controls, secure evidence handling, competence requirements, and a mechanism to stop work that cannot be performed safely. Honest limitations and negative results increase assurance; manufactured certainty reduces it.

Applied workflow — design a twelve-month validation program

Identify decision owners and crown-jewel processes. Map business services, critical actions, accountable executives, system owners, security controls, and required assurance.
Build the evidence baseline. Collect prior incidents, assessments, architecture, inventory, findings, threat profiles, detection coverage, recovery tests, and unresolved limitations.
Select a balanced portfolio. Schedule architecture and exposure review, specialist penetration tests, one or more threat-informed purple-team exercises, human/process validation where appropriate, and retests.
Define acceptance gates. Standardize ROE, evidence packet, severity review, cleanup, data handling, finding ownership, retest, and executive decision requirements.
Measure outcomes, not activity. Track answered objectives, validated control behavior, remediation and retest, recurrent root causes, detection lifecycle performance, and residual uncertainty.
Review quarterly. Reprioritize after incidents, major releases, acquisitions, infrastructure changes, new threat evidence, control failures, and overdue remediation.
Publish a defensible annual view. Report what was tested, what was not, evidence confidence, improved controls, open risks, recurring gaps, next-year priorities, and investment decisions.

Program register

Business decision and accountable owner
Assessment type, scope, assumptions, and schedule
Threat/control hypothesis and success criteria
Evidence quality and review status
Findings, actions, owners, and due dates
Retest state, residual risk, and acceptance

Maturity progression

Move from ad hoc tool execution, to repeatable scoped testing, to evidence-linked specialist assessments, to threat-informed attack–defense validation, and finally to a continuously governed portfolio where findings, telemetry, detections, architecture, response, and retests share authoritative records.

Program gate: do not claim maturity from the existence of a red team. Demonstrate repeatable authority, representative coverage, reviewed evidence, owned remediation, successful retests, measurable defensive improvement, and explicit unresolved risk.

Operator technical deep dives

7 decision records

Each deep dive starts with a concrete analytical question and ends with an acceptance gate. The purpose is to make the reasoning behind the test visible: prerequisites, baseline, controlled variation, evidence, alternative explanations, defensive visibility, cleanup, and the limits of the conclusion.

Deep dive 1 — Validate a network service without overstating the result

Question: “What service is reachable on this approved asset from this vantage point, what component appears to answer, and what safe next test is justified?” Begin with an authoritative target record and a narrow target list. Record the scanner host, interface, source address, route or VPN, DNS resolver, test window, tool version, timing profile, TCP/UDP policy, excluded probes, and expected monitoring. Establish whether load balancers, WAFs, NAT, CDN, service mesh, or provider edges sit between operator and origin.

Progressive validation

Reachability: determine whether the host and protocol respond from the chosen vantage point. Preserve lack of response as a condition, not as proof that no service exists.
Transport: record port state and the exact exchange supporting it. Repeat only enough to exclude transient loss or rate limiting.
Protocol: use a well-formed, non-mutating protocol request. Confirm that the response grammar and state correspond to the expected protocol.
Service: compare banner, handshake, TLS certificate, HTTP behavior, protocol capability, and owner inventory. Assign confidence instead of forcing a product label.
Product and version: corroborate a version with authenticated inventory, package data, administrative interface, vendor-specific behavior, or owner confirmation. A banner alone is weak evidence.
Security property: test only the property needed by the objective—such as exposure, authentication requirement, encryption configuration, or a vendor-provided safe check.

Evidence packet

Target and owner; collection point; DNS and routing context; raw machine-readable output; protocol transcript; TLS/HTTP metadata; product/version sources; scanner confidence; timestamps; defensive event IDs; interpretation; alternatives; scope decision; and next test.

Alternative explanations

Shared edge, port-forwarding, protocol proxy, honeypot, stale exposure index, banner deception, virtual hosting, load-balanced pools with different builds, scanner fallback, network policy, or a service that only reveals its identity after authentication.

Defensive visibility

Correlate firewall, load-balancer, WAF, server, endpoint, and SIEM records. Note whether source address, destination, protocol, request, host header, identity, action, and test ID survive normalization. Scanner alerts without usable target context are a defensive finding.

Stop conditions

Unexpected production instability, scope ambiguity, third-party routing, rate-limit impact, sensitive response data, real compromise indicators, or evidence that the target is not the approved system triggers pause and escalation.

Collapsing repeated edge addresses into duplicate “open services” without endpoint normalization.
Converting every fingerprint into a CVE match while product, build, and configuration are unconfirmed.
Running broad scripts before identifying protocol and side effects.
Keeping only a screenshot and discarding the XML, JSON, transcript, and timing context.

Acceptance gate: a peer reviewer can reproduce the narrow service observation, distinguish edge from origin, see which identity/version claims are confirmed or inferred, and agree that the proposed next step is both authorized and technically necessary.

Deep dive 2 — Model and test one web or API transaction

Question: “Does the server enforce the intended security property for this business transaction across roles, tenants, objects, channels, and workflow states?” Choose one transaction such as exporting a synthetic invoice, changing a recovery address, approving a payment, sharing a document, or retrieving an API object. Document the business rule before testing. Identify actors, roles, tenants, objects, operations, states, approval requirements, rate or value limits, and expected audit events.

Create the transaction model

Trace browser or client input through DNS, edge, gateway, application, identity provider, backend services, queues, storage, third parties, and audit. Record every request involved, not only the final API call. A secure front-end operation can depend on a vulnerable preview, export, batch, mobile, GraphQL, websocket, support, or administrative path. Enumerate alternate encodings and identifiers only after the baseline is understood.

Paired-request method

Create synthetic users and objects for at least two roles or tenants; record immutable IDs and expected policy.
Capture a successful baseline request and its persistent state change, including anti-CSRF, session, token, and workflow context.
Capture the expected-deny baseline using an identity that clearly lacks the action.
Change one security variable: object ID, tenant, role, workflow state, method, channel, claim, or approval state.
Compare status, headers, response body, timing, side effects, subsequent reads, notification, billing or quota effects, and audit events.
Repeat only enough to isolate the root condition; stop after the synthetic proof answers the objective.

Authentication

Test enrollment, login, MFA, recovery, federation, session creation, refresh, revocation, concurrent sessions, device trust, and step-up as separate state machines. Use dedicated accounts and do not lock real users.

Authorization

Evaluate horizontal, vertical, tenant, object, function, field, workflow, and bulk-operation access. The authoritative question is whether the server permits the subject–action–object combination.

Input and output

Identify parser boundaries, canonicalization, validation, transformation, storage, query, template, downstream interpreter, and output context. A scanner payload match is not proof of code execution or data impact.

Business logic

Review sequencing, replay, concurrency, approval separation, value limits, inventory, entitlement, discount, refund, invitation, sharing, and support overrides. These flaws often require stateful reasoning more than payload dictionaries.

Finding language

Describe the violated security property, exact affected transaction, required identity and state, paired request difference, observed unauthorized effect, synthetic impact, server-side root cause, audit result, scope, and limitation. Recommend policy enforcement at the authoritative server boundary and a regression test covering the failing subject–action–object case—not merely hiding the UI control.

Acceptance gate: the finding includes reproducible paired requests, role/tenant/object state, persistent effect, server-side evidence, audit behavior, synthetic impact, cleanup, and a negative regression test. No real customer or employee data was needed.

Primary: OWASP Web Security Testing Guide · OWASP ASVS · 1200km: Burp Suite workflow

Deep dive 3 — Build a vulnerability decision record

Question: “Is this exact asset affected by the weakness, is the vulnerable behavior reachable under realistic preconditions, what did controls change, and what action should the owner take?” Never begin with a severity score alone. Create one record that keeps asset identity, component identity, vulnerability identity, exploitability, exposure, control behavior, business impact, confidence, and remediation state separate.

Evidence sequence

Normalize the lead. Preserve scanner, plugin or template ID, version, configuration, target, raw result, timestamp, and the logic that produced the match.
Confirm the asset. Resolve owner, environment, business service, criticality, exposure, authentication boundary, network path, and whether a proxy or shared provider answered.
Confirm the component. Use package inventory, SBOM, authenticated management data, build metadata, deployment manifest, file evidence, vendor API, or owner record. Product names and CPE matches are not sufficient by themselves.
Read primary sources. Compare vendor advisory, CVE record, fixed builds, affected branches, configuration conditions, exploit consequences, workarounds, and known exploitation evidence. Note disagreements among sources.
Evaluate preconditions. Determine reachable interface, required identity, feature state, privileges, user interaction, network position, data type, and environmental mitigations.
Choose minimum proof. Prefer vendor safe checks, version/configuration proof, harmless response difference, synthetic marker, or isolated clone. Escalate only if uncertainty affects the business decision and authorization permits it.
Observe controls. Separate vulnerable condition, attempted behavior, prevention, detection, alert, response, and residual impact.
Make the disposition. Confirmed, affected but blocked, not affected, false positive, duplicate/root-cause child, accepted risk, remediated, or unresolved—with confidence and limitation.

Priority inputs

Business service, internet/internal exposure, reachable path, required privileges, exploit maturity, known exploitation, likelihood signals, blast radius, data/control impact, compensating controls, recovery, asset lifecycle, and owner deadline.

Do not combine

CVSS estimates technical severity; KEV records known exploitation inclusion; EPSS estimates a probability under its model; asset criticality reflects local business value. None alone is a final organizational risk decision.

Duplicate control

Group findings by authoritative asset, component, root cause, and vulnerable range. Preserve each source observation but avoid creating separate remediation items for the same underlying defect unless owners, environments, or treatments differ.

Retest

Verify deployed fixed build or configuration, restart/redeploy state where applicable, original proof now fails safely, service still functions, controls still log, related assets are addressed, and temporary workaround or credentials are removed.

Declaring exploitation based on a template name or HTTP string match.
Using a public proof-of-concept without source review, sandboxing, side-effect analysis, or authorization.
Copying advisory maximum impact into the report when the local preconditions were not present.
Closing on package installation while the vulnerable process, image, function, or node still runs the old build.

Acceptance gate: the disposition identifies the authoritative asset and component, affected range, local preconditions, safe proof, controls, demonstrated and plausible impact, source citations, confidence, owner action, and versioned retest. An independent reviewer can see why the scanner lead was accepted, rejected, or left unresolved.

Deep dive 4 — Validate an identity attack path edge by edge

Question: “Can the authorized starting principal reach the protected identity or action through effective, repeatable control relationships, and which single edge should be removed or monitored?” Start with immutable principal and object IDs, directory or tenant, group memberships, token context, current session, trust domain, and data timestamp. Identity graphs become stale quickly; collection time and source authority matter.

Edge vocabulary

Classify each relationship: direct group membership, nested group, object ACL, ownership, delegated administration, password or key reset, session presence, local administrator, service control, Kerberos delegation, SPN or service relationship, certificate template/enrollment condition, federation or consent, cloud role assumption, workload identity, secret access, support workflow, or policy inheritance. For every edge, record the controlled object, effective right, precondition, target effect, required protocol, audit source, and remediation owner.

Validation workflow

Confirm the starting identity and collect only authorized directory or provider metadata.
Generate candidate paths, but rank them by current effective rights, reachable systems, required credentials, monitoring, business relevance, and proof safety.
Manually validate each edge using authoritative access checks and current configuration. Remove historical, disabled, denied, or context-incompatible edges.
Select the shortest safe proof that demonstrates the security property, preferably against a synthetic object or account.
Correlate identity-provider, directory, CA, endpoint, cloud, application, and SIEM records. Record event IDs and field quality.
Remediate the root edge, recalculate alternate paths, rotate or revoke test credentials and certificates, terminate sessions, and rerun the expected-deny test.

Kerberos

Separate account/service configuration, ticket request, encryption support, delegation condition, service reachability, credential material, and authorization after ticket use. A ticket-related observation is not automatically domain compromise.

ADCS

Evaluate CA, template, enrollment rights, issuance requirements, subject naming, EKUs, manager approval, authorized signatures, mapping behavior, and target privileges. Report the exact template and chain; avoid labeling every permissive setting as an exploitable escalation.

Cloud federation

Record issuer, tenant, application/client, audience, consent, claims, conditional access, session restrictions, role assumption, resource policy, and provider audit. Display names are insufficient for cross-tenant analysis.

Detection

Measure source event creation, collection, normalization, enrichment, analytic logic, alert routing, analyst understanding, containment, and credential invalidation separately. High-volume identity telemetry without immutable IDs can make a valid detection operationally unusable.

Acceptance gate: every graph edge is current, effective, independently evidenced, and tied to a protocol and owner; the controlled proof stops at the approved synthetic action; alternate paths and session/credential cleanup are documented; and the detection record distinguishes expected logs from observed response.

1200km path: AD lab · Certificate escalation scenario · Cloud identity takeover scenario

Deep dive 5 — Test a cloud or Kubernetes boundary with tenant-safe evidence

Question: “Can this exact principal perform this exact control-plane or workload action on this resource, and what policy chain permits or denies it?” Define the tenant/account/project/subscription, region, resource IDs, network, cluster, namespace, workload, identity, credential source, provider rules, cost ceiling, and cleanup owner before testing. Provider terms and third-party authorization remain part of the ROE.

Cloud permission record

Capture the principal’s immutable ID, authentication and session context, requested API action, target resource, identity policy, group or role inheritance, resource policy, organization controls, permissions boundary, explicit denies, conditions, service-control behavior, and effective result. If a simulator is used, mark it as a prediction until confirmed by an authorized harmless action. Preserve request or event IDs from the provider API and audit log.

Kubernetes permission record

Capture cluster and namespace, subject and groups, service account, token audience/expiry, verb, API group, resource, resource name, role/cluster role, binding, admission result, API response, audit event, workload/image, node, network policy, secret source, and cloud-workload identity mapping. A broad list permission and a named secret read are different proofs; a namespace path and a node path are different findings.

Establish expected allow and expected deny using synthetic resources.
Review effective permission using native provider or Kubernetes authorization interfaces.
Identify the smallest policy edge that appears to violate the intended boundary.
Perform one harmless named-object action using the approved identity.
Verify provider/Kubernetes audit, network, workload/runtime, identity, and SIEM evidence.
Remove or narrow the policy edge, rotate the relevant token or secret, and rerun the deny case.
Inventory and remove resources, images, snapshots, keys, sessions, logs outside retention, and cost-bearing services.

Evidence quality

Provider API result and audit event tied to immutable IDs are primary. Policy exports and before/after infrastructure-as-code diffs explain root cause. Console screenshots support the record but should not be the only evidence.

Impact restraint

Use synthetic objects, empty buckets, isolated namespaces, test keys, and harmless control-plane actions. Do not copy production data, modify shared policy, assume another tenant, or create persistence when the permission decision itself answers the objective.

Acceptance gate: the tested principal, policy chain, resource, request, response, audit event, synthetic effect, remediation diff, deny retest, credential rotation, resource reconciliation, and cost confirmation all refer to the same tenant and test ID.

Deep dive 6 — Validate detection as a lifecycle, not a rule screenshot

Question: “For this exact relevant procedure, does the environment prevent, observe, analyze, route, interpret, and respond as intended?” Begin with a source-backed behavior and local hypothesis. Record procedure details—platform, identity, process or API, input, target, sequence, and observable characteristics—before mapping ATT&CK. Technique IDs organize knowledge but do not supply the environment-specific test.

Telemetry contract

List each expected data source, producer, event, field, collection agent, transport, normalization, enrichment, index, retention, query, expected latency, and owner. Include time synchronization and a unique test marker. Verify raw event ingestion before evaluating the detection rule; otherwise a missing alert can be misclassified as a logic failure when the data never arrived.

Layer	Question	Evidence	Common gap
Prevention	Did a control block or modify the action?	Operator result, target state, control event	Block inferred from lack of effect without control evidence
Generation	Did the source create the required event?	Native endpoint/cloud/application record	Audit category or logging policy disabled
Collection	Was the event transported and retained?	Agent and pipeline state, raw event, latency	Dropped event, delay, parsing failure, retention gap
Normalization	Are required fields correct and usable?	Raw-to-normalized comparison	Missing identity, process, target, tenant, or test marker
Analytics	Did the versioned logic evaluate the event?	Rule/query version, evaluation trace, result	Wrong field, threshold, scope, suppression, or disabled rule
Alerting	Was context created and routed?	Alert ID, enrichment, queue, timestamps	Rule fires but queue, ownership, or enrichment fails
Analysis	Did the analyst reach the intended conclusion?	Triage notes, source pivots, decision and timing	Alert lacks procedure, asset, identity, or business context
Response	Did containment and recovery work safely?	Approved action, state, communications, recovery	Playbook exists but authority, automation, or rollback fails

Rule improvement and retest

When a layer fails, change that layer and keep the procedure stable. Version the test artifact, analytic, lookup/enrichment, target configuration, and expected result. Evaluate false positives using representative benign data without weakening the malicious behavior indiscriminately. Rerun the same test, compare event and alert timing, preserve both failure and success, and state the validated scope: platform, procedure, telemetry, rule version, and date.

Marking a technique green because a rule title or data-source mapping exists.
Changing the test at the same time as the rule, making the retest incomparable.
Testing only whether the alert fired and ignoring whether the analyst could act on it.
Reporting “no detection” when prevention stopped the procedure before the expected event.

Acceptance gate: the record links threat source, exact procedure, versioned safe test, expected telemetry, raw events, analytic, alert, analyst decision, response, gap owner, change, and comparable retest. Coverage is claimed only for that bounded procedure and environment.

1200km path: Operation Desert Hydra · Attack–Defense Simulation Framework · AdversaryGraph Attack Simulation

Deep dive 7 — Design an AI/MCP control plane that remains reviewable

Question: “Can an assistant help plan, interpret, or invoke authorized security tools while deterministic controls—not model compliance—enforce target, effect, data, and approval boundaries?” Treat the complete system as a privileged distributed application: user, AI client, model provider, system policy, conversation context, retrieval, memory, MCP servers, tool schemas, credentials, runner, network, target, evidence store, logs, and human approver.

Tool contract

Each tool needs a stable name and version, narrow purpose, effect class, input schema, target type, scope validator, argument allowlist, credential identity, time and resource limits, network/filesystem policy, approval requirement, idempotency or duplicate-call behavior, structured response schema, side-effect report, artifact references, error model, and cleanup or rollback. Reject unknown fields and ambiguous targets. Resolve hostnames and ranges at the policy layer while preventing DNS rebinding or expansion beyond the approved inventory.

Response contract

Return invocation ID, normalized target and arguments, start/end time, tool/server version, execution status, observations, raw artifact IDs and hashes, parser/version, warnings, partial-completion state, side effects, created or modified objects, cleanup requirement, and safe error details. Keep raw output outside model prose. A timeout, partial result, parser error, and confirmed empty result must remain distinguishable.

Human approval design

Display the objective and scope record that authorizes the proposed call.
Show normalized target, tool, arguments, effect class, credentials, data disclosure, expected side effects, stop condition, rollback, and evidence location.
Require fresh approval for active scanning, authentication, file writes, code execution, exploitation, credential use, privilege change, persistence, movement, external communication, and data transfer.
Bind approval to the exact normalized call and expiry; do not approve an opaque plan that the model can reinterpret.
Log rejection as well as approval so policy quality and unsafe proposals can be reviewed.

Prompt-injection defense

Retrieved documents, web content, repository text, banners, tool output, and report uploads are untrusted data. Separate them from policy; label provenance; restrict retrieval; sanitize display; prevent content from changing permissions; and test instructions that request secrets, new targets, policy override, or hidden calls.

Data governance

Classify prompts, evidence, credentials, personal data, client data, and model logs. Prefer approved local processing when evidence cannot leave the environment. Minimize context, redact secrets, define provider retention, isolate tenants, and delete embeddings or caches during closure when required.

Failure testing

Test unavailable models/servers, malformed inputs, unknown fields, oversized output, timeouts, retries, duplicate calls, partial writes, stale approval, target mismatch, path traversal, command injection, result spoofing, prompt injection, leaked secret, audit outage, and failed cleanup.

Analytical verification

Independently verify asset ownership, service/product/version, CVE relevance, ATT&CK mapping, query syntax, finding severity, and remediation. Model confidence is not evidence confidence. Record discarded suggestions and corrections.

Acceptance gate: unauthorized targets and effect classes fail even when the model requests them; approvals bind exact calls; schemas reject ambiguity; raw evidence and side effects are preserved; prompt-injection tests do not alter authority; partial failures are visible; and an operator can reconstruct every accepted conclusion without trusting the assistant narrative.

1200km path: HexStrike research hub · AI in Offensive Security · Practical Attacks Against LLM Agents

End-to-end case studies

6 controlled scenarios

These scenarios show how to connect scope, collection, validation, evidence, defensive observation, cleanup, and reporting. They are designs for owned laboratories or explicitly authorized environments—not instructions to target public systems.

Case 1 — External discovery to a validated web authorization finding

ExternalWeb/APIAuthorizationBurp SuiteEvidence-led

Objective: determine whether a standard customer in a training tenant can access another tenant’s synthetic export and whether the application and SOC record the denied or successful attempt. The authorized target is a deliberately vulnerable lab application behind a reverse proxy; CDN and shared-provider addresses are explicitly excluded.

Import the supplied domain, lab address, application owner, tenant identifiers, allowed test accounts, business transaction, source IP, time window, and prohibition on availability testing into the engagement record.
Perform passive DNS and certificate review, then narrow active service validation. Reconcile the virtual host and reverse proxy so the evidence is attributed to the application instead of the hosting address.
Capture the normal export workflow with User A: authentication, API request, object identifier, asynchronous job, download, audit event, and the synthetic marker in the resulting file.
Build a role–action–object matrix for User A, User B in another tenant, an expired session, and the approved administrative role. Record expected allow and deny decisions.
Replay only the object reference under User B. Preserve the sanitized baseline and mutated requests, response, resulting job state, downloaded synthetic marker if exposed, identity/tenant context, and application audit entry.
Confirm the minimum root cause with the owner: server-side authorization uses object existence but does not enforce tenant ownership. Stop without enumerating unrelated exports.
Correlate WAF, identity, application, API, and SIEM evidence. Report separately whether traffic was logged, an analytic matched, an alert was created, and an analyst received actionable context.
Remediate with centralized tenant-aware authorization, a negative integration test, audit improvement, and a detection hypothesis. Rerun the identical controlled request and preserve the denied result.

Deliverables

Attributed attack-surface record, transaction map, authorization matrix, paired HTTP evidence, synthetic impact proof, root-cause finding, detection observation, cleanup confirmation, and before/after retest.

1200km reading

Burp interface-testing tutorial · Burp with LLMs · Secure Code / AppSec

Do not claim: compromise of the entire platform, access to real customer data, effectiveness of every authorization path, or detection coverage beyond this versioned transaction and environment.

Case 2 — Standard user to a certificate-based identity control path

Active DirectoryADCSIdentity graphDetectionRetest

Objective: validate whether a synthetic standard account can obtain a certificate representing a privileged test identity through an intentionally misconfigured laboratory template, and whether directory, certificate, endpoint, and SIEM controls expose the path.

Deploy the isolated AD laboratory, add certificate services, synthetic identities, endpoint logging, directory auditing, CA logs, and SIEM ingestion. Snapshot the baseline.
Model domains, OUs, groups, template permissions, enrollment services, authentication settings, and the protected administrative action. Label every graph edge with the exact principal, object, right, and protocol condition.
Confirm that the test account may enroll in the selected template and that the template’s identity-binding configuration creates the intended laboratory risk. Preserve configuration evidence before attempting enrollment.
Use a synthetic privileged identity and the minimum certificate request needed to validate the edge. Record request identifiers, account, template, CA, timestamps, resulting certificate metadata, and all target changes.
Validate only the pre-agreed administrative marker, then stop. Correlate directory, certificate, authentication, endpoint, and SIEM events with the operator timeline.
Classify each layer: dangerous configuration exists; request succeeds or fails; authentication succeeds or fails; privileged action succeeds or fails; telemetry exists; analytic fires; analyst understands the certificate relationship.
Remediate template rights and identity binding, revoke the test certificate, remove artifacts, verify revocation and cleanup, then rerun the same enrollment attempt and expected detection query.

Deliverables

Identity path record, template and CA evidence, controlled request record, certificate metadata, privilege marker, event timeline, analytic result, revocation and cleanup proof, and path-closure retest.

1200km reading

ADCS primer · ESC1 reference · Certificate-attack detection · HexStrike ADCS lab

Do not claim: a generic “ADCS compromise.” State the exact template, principal, enrollment path, identity condition, validated action, and environment.

Case 3 — Cloud workload identity with excessive storage privilege

CloudWorkload identityStorageAuditSynthetic data

Objective: test whether a low-privilege application workload in a disposable project can read a synthetic object from a protected bucket because of an inherited role, and whether the provider audit and SIEM pipeline explain the effective permission.

Record the organization, project/account/subscription, region, resource IDs, provider testing policy, test principal, allowed APIs, budget, expiry, source network, and prohibition on provider infrastructure testing.
Provision a tagged workload, one public test endpoint, a protected storage resource containing a unique synthetic marker, an intentionally broad inherited role, audit logging, and a second expected-deny identity.
Build the effective-permission chain: workload identity binding, group or role inheritance, resource policy, conditions, and the exact storage action. Validate with policy analysis and read-only API evidence before accessing the object.
Request only the named synthetic object using the workload identity. Preserve the sanitized API call, resource and principal IDs, provider event ID, response metadata, marker, and operator timestamp.
Compare the expected-deny identity, confirm audit fields and SIEM ingestion, and test whether the analytic identifies the workload, target resource, inherited grant, and unusual access path.
Replace the broad role with a least-privilege permission, revoke temporary credentials, delete the marker and test resources, compare inventory and cost against baseline, and rerun both identities.

Deliverables

Resource graph, effective-permission chain, provider event IDs, synthetic object evidence, allow/deny comparison, SIEM result, policy change, inventory/cost reconciliation, and retest.

1200km reading

GCP testing guide · Identity attack surface · Cloud investigation case study

Do not claim: exposure of unrelated storage, organization-wide privilege, or data theft. The validated result is limited to the synthetic object, principal, policy version, and project.

Case 4 — Kubernetes service-account and namespace boundary validation

KubernetesRBACService accountRuntimeAudit

Objective: determine whether a synthetic workload in Namespace A can read a designated secret in Namespace B because of an intentionally over-broad binding, and validate Kubernetes and cloud audit visibility without attempting node or host escape.

Create a disposable cluster with two namespaces, synthetic service accounts, a designated secret marker, network policy, audit logging, runtime monitoring, restricted admission, resource quotas, and deterministic teardown.
Record cluster, namespace, workload, pod, service account, role, binding, token audience, cloud identity linkage, image, node, and API server identifiers. Establish the expected-deny baseline.
Review RBAC rules and effective access for the Namespace A service account. Trace the exact binding that grants the cross-namespace read instead of relying only on a scanner label.
From the approved test pod, request only the named synthetic secret through the Kubernetes API. Preserve API request metadata, audit event, service-account identity, response metadata, and marker.
Correlate Kubernetes audit, workload, network, runtime, cloud identity, and SIEM events. Verify whether the analyst can distinguish normal controller activity from the synthetic cross-namespace request.
Replace the binding with namespace-scoped permission, rotate the test secret and token, remove the pod and images, verify audit continuity, rerun the expected deny, and destroy the cluster.

Deliverables

Cluster scope, RBAC relationship, service-account and token context, expected-deny baseline, controlled API evidence, audit timeline, remediation manifest, secret rotation, retest, and cluster teardown.

1200km reading

Kubernetes testing playbook · Kubernetes RBAC · Service accounts

Do not claim: cluster compromise or container escape. The evidence supports one service-account authorization path and its detection lifecycle.

Case 5 — Threat report to PowerShell detection validation

CTIATT&CKPowerShellAtomic validationPurple team

Objective: convert a source-backed report describing encoded or obfuscated PowerShell behavior into a benign, versioned laboratory procedure, then determine whether required telemetry, analytic logic, alert routing, analyst interpretation, and containment operate as expected.

Preserve the report, publication date, relevant procedure excerpt, platform, actor or campaign confidence, ATT&CK mapping, and local relevance. Separate the cited behavior from generic technique assumptions.
Write a detection hypothesis defining process, command-line or script-block characteristics, parent/child context, user and host context, expected benign variation, data sources, required fields, time window, and analyst decision.
Create a harmless script that writes a unique marker, then encode or obfuscate only enough to preserve the behavior required by the hypothesis. Record script hash, test ID, version, target, expected events, and cleanup.
Execute in the isolated endpoint lab, preserve process and script evidence, verify target state, query raw telemetry before evaluating the analytic, and correlate time across endpoint and SIEM.
Classify the result across prevention, event creation, collection, field quality, rule evaluation, alert enrichment, routing, analyst triage, and containment. Record the first failed layer.
Improve logging or logic, version the change, rerun the identical procedure, compare noise and false-positive considerations, remove the marker, and publish the validated limitation.

Deliverables

Source-to-procedure mapping, ATT&CK layer, test artifact and hash, telemetry contract, raw event references, analytic version, alert/analyst timeline, gap classification, cleanup, and retest evidence.

1200km reading

Operation Desert Hydra · Attack–Defense Simulation Framework · AdversaryGraph Attack Simulation · TTP to detection rule

Do not claim: complete T1059.001 coverage. The result applies to the exact procedure, telemetry configuration, analytic version, endpoint, and test window.

Case 6 — Constrained HexStrike MCP laboratory assessment

AIMCPHexStrikeSandboxHuman approval

Objective: assess a private Metasploitable or deliberately vulnerable Ubuntu lab with an AI client and HexStrike MCP server while proving that targets, tool effects, approvals, evidence, prompt-injection resistance, and teardown remain under deterministic operator control.

Separate the AI client, MCP server, security-tool runner, evidence store, and vulnerable target into constrained systems. Permit only the lab subnet, block unintended egress, mount evidence read-only where possible, and issue no production credentials.
Register read-only discovery tools first with narrow schemas, target types, timeouts, rate limits, structured results, and audit IDs. Test rejection of public and malformed targets before allowing the approved lab address.
Ask the model to propose a plan tied to the objective. Require each step to cite the scope record and explain evidence, side effects, and stop criteria. Approve one normalized call at a time.
Preserve the model/provider/version, policy version, prompt context reference, proposed call, operator decision, tool/server version, normalized arguments, raw output hash, parser output, and evidence record.
Insert untrusted text into a laboratory service banner or document that attempts to redirect the assistant. Verify that the content is treated as data, the tool layer rejects an out-of-scope target, and no secret or unauthorized call is produced.
Enable one active validation tool behind fresh approval only after discovery succeeds. Use minimum proof against the lab, record changes, stop at the pre-agreed marker, and independently verify the model’s interpretation.
Terminate sessions, remove artifacts, destroy disposable containers/VMs, revoke credentials, verify the target, archive approved evidence, and compare actual tool calls with the approval ledger.

Deliverables

Trust/data-flow diagram, tool-effect registry, target policy, response schema, approval and invocation ledger, prompt-injection test, raw evidence, finding review, cleanup attestation, and residual limitations.

1200km reading

HexStrike hub · HexStrike documentation · Metasploitable lab · Vulnerable Ubuntu lab

Do not claim: autonomous security validation. The accepted result is the human-reviewed deterministic tool evidence; model suggestions and summaries remain attributed analytical leads.

Field references, templates, and learning curriculum

Reusable operator material

Use these references to make each assessment reviewable. Adapt them to the organization’s legal, privacy, safety, engineering, and evidence requirements; a template is not authorization.

Tool decision matrix — choose by question and evidence

No tool proves an engagement objective by itself. Select the smallest tool set that produces the required evidence within scope, then record version, source, configuration, privileges, target, rate, expected effects, raw output, and cleanup.

Phase	Question	Representative tools	Evidence to preserve	Primary caution
Planning	What is authorized, why, and how will it stop?	ROE, ticketing, diagrams, repositories, evidence register	Approved scope, objectives, technique classes, contacts, data rules, stop and cleanup plan	A tool configuration never expands written authority.
Passive recon	What public or supplied records suggest candidate assets and identities?	DNS and certificate tools, registration data, repository search, exposure indexes, OSINT platforms	Source URL/API, query, collection time, raw record, attribution confidence, scope decision	Historical, shared, and third-party observations are not owned assets automatically.
Network validation	Which approved hosts and services respond from the defined vantage point?	Nmap, protocol clients, TLS tools, Wireshark; rate-controlled discovery where explicitly approved	Target list, source, time, rate, scan options, XML/JSON output, service proof, packet trace where needed	Banner and fingerprint matches do not confirm product version or vulnerability.
Web and API	Does the server enforce authentication, authorization, session, input, and business rules?	Burp Suite, OWASP ZAP, browser tools, API clients, reviewed fuzzers	Identity/tenant context, baseline and mutated request, response, state effect, audit event, cleanup	Automated crawling misses state and can trigger cost or availability effects.
Vulnerability validation	Is the exact component affected, reachable, and impactful here?	Vendor checks, authenticated scanners, Nuclei under review, package/SBOM tools, lab-only exploit frameworks	Component/version/configuration, primary advisory, plugin/template, minimum proof, controls, confidence	Public PoC code may be unsafe, modified, irrelevant, or destructive.
Host and privilege	Which local configuration or right creates the authorized privilege transition?	Native OS tools, configuration collectors, file/registry/service inspection, lab validation frameworks	Starting identity, candidate, precondition, transition, target change, telemetry, rollback	Broad secret collection and unstable kernel exploits rarely provide minimum necessary proof.
Identity	Which principal controls which object through what exact relationship?	Native directory/cloud queries, BloodHound-style analysis, Kerberos/ADCS assessment tools in labs	Principal, object, right, protocol condition, path, controlled action, events, alternate paths	Graph reachability alone is not effective exploitability or authorization.
Cloud	What is the effective permission and resource path in this tenant?	Provider CLI/API, policy analyzers, cloud inventory, audit queries, infrastructure-as-code diff	Tenant, immutable IDs, principal, policy chain, API/event IDs, before/after state, cost and cleanup	Shared-provider infrastructure and control-plane APIs need distinct scope treatment.
Kubernetes	How do RBAC, workload identity, runtime, and cluster controls combine?	kubectl and provider APIs, RBAC analyzers, image/SBOM tools, audit and runtime platforms	Cluster/namespace, service account, binding, workload/image, API request, audit event, teardown	A cluster scanner result does not prove a reachable namespace, node, or cloud path.
Mobile/client	How does the exact build handle local data, platform trust, network, updates, and backend authority?	OWASP MASTG tooling, emulators/VMs, static analyzers, debuggers/instrumentation, intercepting proxy	Build hash/signer, device state, requirement ID, static and runtime proof, backend decision, update path	Results that require a modified client state must be reported with that threat-model assumption.
Emulation	Can a relevant, safe procedure validate telemetry, analytics, and response?	Atomic Red Team, CALDERA, scenario scripts, ATT&CK Navigator, AdversaryGraph	Source behavior, procedure version, target, artifact/hash, events, rule, alert, analyst outcome, retest	Technique or rule existence is not validated coverage.
AI and MCP	Can assistance or orchestration reduce analysis effort without losing control?	HexStrike, approved MCP servers, local or approved remote LLMs, structured parsers	Model/policy, prompt context reference, approved call, normalized args, raw result hash, reviewer decision	Prompts are not access controls; retrieved content and tool output are untrusted data.
Evidence/reporting	Can another reviewer reproduce and challenge the conclusion?	Encrypted evidence store, hashes, timeline, version control, report templates, issue tracker	Artifact ID, collector, time, source, hash, handling, finding link, cleanup, retention and deletion	Screenshots without context and AI summaries without raw evidence are insufficient.

1200km libraries: PT Tools & Techniques · HexStrike · AI in Offensive Security · Lab Work

Twelve-lab practical curriculum

Each lab should begin with written authority and a baseline, use synthetic data, produce raw and interpreted evidence, include defensive observation, end with cleanup, and preserve a repeatable retest. Progress only when the learner can explain the protocol and independently verify tool output.

Lab	Build and objective	Required output	1200km path
1. Scope and evidence	Write vulnerability-assessment and red-team ROEs for the same private host; configure time, evidence IDs, hashing, and cleanup.	Two engagement packs showing different objectives, permissions, proof, and reporting.	Data handling
2. Network baseline	Create a three-host private network with expected services, filtering, and one stale inventory record; perform controlled Nmap validation.	Attributed asset map, raw XML, service confidence, packet evidence, inventory correction.	Nmap series
3. Web authorization	Deploy a two-tenant vulnerable application and test one object or export transaction with Burp or ZAP.	Role–action–object matrix, paired requests, synthetic impact, remediation test.	Burp tutorial
4. Finding validation	Scan an intentionally vulnerable Ubuntu or Metasploitable host; select one confirmed, one rejected, and one unresolved lead.	Three evidence packets with different dispositions, confidence, and safe proof.	Vulnerable Ubuntu
5. Linux privilege path	Seed one reversible permission or service misconfiguration and endpoint logging; validate a synthetic privilege marker.	Starting state, path, precondition, transition evidence, events, fix, and cleanup.	Vulnerability research
6. AD identity graph	Deploy the AD lab with a risky ACL or delegation relationship and directory/endpoint logging.	Edge-by-edge identity path, controlled proof, event timeline, remediation, path recalculation.	AD lab
7. ADCS validation	Add certificate services and one deliberately risky synthetic template; pair the path with CA and SIEM evidence.	Template/path evidence, request record, certificate metadata, detection, revocation, retest.	Certificate scenario
8. Cloud IAM	Create a disposable project with an over-permissioned workload identity and protected synthetic object.	Effective-permission chain, provider event IDs, least-privilege change, cost/cleanup reconciliation.	Cloud identity scenario
9. Kubernetes boundary	Build a disposable two-namespace cluster with one broad binding, audit logging, and synthetic secret.	RBAC path, API/audit evidence, remediation manifest, token/secret rotation, teardown.	Kubernetes playbook
10. Detection validation	Select a source-backed ATT&CK behavior, implement a benign atomic procedure, and measure the full defensive lifecycle.	Source mapping, test artifact, telemetry contract, raw events, analytic/analyst result, retest.	Simulation framework
11. AI + MCP safety	Separate an AI client, HexStrike server, tool runner, and lab target; test allowlists, approvals, schemas, prompt injection, and logs.	Trust diagram, tool registry, rejected calls, approval ledger, raw evidence, teardown attestation.	HexStrike hub
12. Capstone	Chain two or three validated procedures into an objective-led attack–defense exercise with a formal report and retest.	Complete engagement pack, timeline, findings, defensive outcomes, remediation backlog, retest, closure.	Lab index

Laboratory acceptance criteria — what “completed” means

A screenshot, tool output, or successful action does not complete a lab. Completion requires that the learner can explain the mechanism, reproduce the result, identify uncertainty, show defensive evidence, return the environment to its baseline, and communicate the decision. Use the criteria below as a peer-review rubric; retain a “not demonstrated” state rather than awarding credit from a plausible narrative.

Lab	Technical pass	Evidence pass	Defensive and closure pass
1. Scope and evidence	Assessment type, objective, starting point, targets, action classes, exclusions, proof, and stop criteria are internally consistent.	Every planned action has an ID, authority reference, expected artifact, handling class, and owner.	Pause/resume, emergency contact, cleanup, retention, and review are exercised in a tabletop.
2. Network baseline	The learner distinguishes reachability, transport, protocol, service, product, and version and reconciles the stale record.	Raw output, vantage point, route, rate, DNS/TLS/protocol context, confidence, and alternatives are preserved.	Expected network/server telemetry is found; no unapproved address or shared host enters scope.
3. Web authorization	A server-side policy failure or correct denial is demonstrated with one controlled variable and synthetic objects.	Role/tenant/object matrix, paired requests, response and persistent state, audit event, and root cause are linked.	Regression test passes after remediation; test users, sessions, objects, and messages are removed.
4. Finding validation	One lead is confirmed, one rejected, and one left unresolved for defensible reasons.	Asset/component/version, primary sources, preconditions, safe proof, controls, impact, confidence, and disposition are explicit.	Owner action and retest exist; temporary scanner credentials and proof artifacts are revoked or deleted.
5. Host privilege	The principal–object–right–trigger–consumer path is proven with a reversible synthetic marker.	Starting identity/state, exact configuration, transition, target state, process and authorization evidence are preserved.	Endpoint/OS events are correlated; services, tasks, files, groups, sessions, and secrets return to baseline.
6. AD identity graph	Each graph edge is current and effective; one root relationship is validated without broad credential collection.	Immutable IDs, ACL or delegation source, groups, protocol condition, proof, alternate paths, and timestamps are recorded.	Directory/endpoint/SIEM events are reviewed; the edge is removed and expected-deny retest passes.
7. ADCS	The exact CA/template/enrollment/mapping path is established with synthetic identities and minimum proof.	Template settings, rights, request, issued certificate metadata, target action, and limitations are linked.	CA and identity telemetry is correlated; certificate revoked, template fixed, sessions closed, path recalculated.
8. Cloud IAM	One effective permission chain is proven against a synthetic object in the correct tenant and region.	Immutable IDs, policy chain, API request/response, provider event ID, before/after state, and cost are recorded.	Policy is narrowed, deny retest passes, credentials revoked, resources and spend reconciled.
9. Kubernetes	Subject, namespace, verb, resource, role/binding, token context, and controlled API effect align.	RBAC records, request, response, audit event, workload/image, network, node/cloud assumptions, and manifest are preserved.	Binding fixed, secret/token rotated, test workloads/images removed, deny retest passes, cluster destroyed.
10. Detection validation	The procedure is source-backed, safe, versioned, reproducible, and relevant to the selected environment.	Raw source events, normalized fields, rule version, alert, analyst and response timeline identify the first failed layer.	Gap is owned, change versioned, same test passes or limitation remains explicit, artifact cleaned.
11. AI + MCP safety	Target/effect policy, schemas, approvals, isolation, timeouts, and error behavior work independently of model compliance.	Model/policy/tool versions, normalized calls, decisions, raw artifacts, parser results, side effects, and corrections are traceable.	Prompt injection and out-of-scope requests fail; credentials, indexes, logs, containers, and target changes are reconciled.
12. Capstone	Two or three individually validated steps answer one business/control objective without exceeding minimum proof.	Complete objective-to-action-to-evidence-to-finding-to-detection chain survives independent peer review.	Report drives assigned remediation; comparable retest completes; sponsor accepts residual risk and closure.

Scoring rule: pass a lab only when all three dimensions pass. A technical pass with missing evidence is not reviewable; evidence without a valid procedure is not a security result; and a result without defensive correlation and cleanup is operationally incomplete.

Failure-mode atlas — diagnose the work before repeating the tool

When a result is confusing, do not immediately increase scan intensity or ask an AI assistant for a more confident answer. Classify the failure. Most assessment errors come from authority, identity, attribution, state, vantage point, protocol interpretation, data quality, control behavior, evidence handling, or cleanup—not from a missing payload.

Failure class	Symptoms	Diagnostic questions	Corrective action
Authority mismatch	Discovered target, provider, action, or data type is absent from the ROE.	What exact authority covers the asset and technique? Is a third party involved?	Pause, preserve the lead, notify the white team, and obtain written clarification before action.
Attribution error	Shared IPs, wildcard names, CDN edges, old DNS, or SaaS hosts appear as company assets.	Which authoritative source and owner confirm the relationship now?	Label confidence and shared/third-party state; do not scan or import as owned until confirmed.
Vantage-point error	Internal/external, VPN, region, DNS, or source controls produce contradictory reachability.	Where did the request originate, resolve, route, terminate, and get filtered?	Repeat the same safe test from documented points; compare route, policy, and logs.
Identity-state error	Unexpected access result changes between clients or retries.	Which account, tenant, token, session, claims, device, group state, cache, and workflow state applied?	Reset to controlled identities and baseline state; change one variable and capture the server decision.
Protocol/fingerprint error	Banner, version, status code, or scanner product label conflicts with manual behavior.	Did a proxy answer? Was the request protocol-valid? What source confirms build identity?	Validate transport, protocol, service, product, and version separately; lower confidence if unresolved.
Scanner/template error	Large duplicate sets, generic string matches, stale signatures, or unexplained severity.	What exact matcher, request, response, version, and assumption triggered the result?	Preserve raw evidence, review detection logic, manually test minimum property, deduplicate by root cause.
Control interference	Proof fails or changes because WAF, EDR, rate limit, proxy, sandbox, or policy intervenes.	Was the vulnerable condition absent, or did a control prevent the chosen procedure?	Record condition and control separately; use owner-approved evidence or lab validation instead of bypassing blindly.
Telemetry pipeline error	Action succeeded but no alert or expected field appears.	Was an event generated, collected, parsed, enriched, evaluated, routed, and retained?	Find the first failed lifecycle layer; correct it and rerun the same versioned test.
Time/state drift	Results cannot be reproduced; policy, deployment, DNS, image, or identity changed.	What build and state were active at each timestamp? Are systems synchronized?	Record immutable versions, config, event time and collection time; retest under a controlled baseline.
AI interpretation error	Invented CVE, unsupported ownership, wrong syntax, missing side effect, or confident summary.	Which raw source supports each claim? Was retrieved content untrusted? Which model/policy produced it?	Reject unsupported claims, verify manually, correct structured records, retain the decision and source evidence.
Evidence-integrity error	Only screenshots exist, artifacts were edited, context is missing, or hashes/time are unavailable.	Can a reviewer reconstruct acquisition, target, tool, state, and chain of custody?	Repeat only if safe and necessary; preserve originals, metadata, hashes, access, interpretation, and limitation.
Cleanup/retest error	Residual accounts, resources, sessions, rules, data, images, or inconsistent post-fix results remain.	What changed, who owns it, which authoritative state proves removal, and is the retest comparable?	Reconcile the change ledger, rotate/revoke, verify baseline, then rerun the original acceptance test.

Module review questions — demonstrate reasoning, not memorization

Use these questions for self-study, peer review, interview preparation, or the final discussion after a lab. A strong answer cites evidence and explains uncertainty. A tool name without a decision model is incomplete.

1. Mission and authorization

How do red-team, penetration-test, and vulnerability-assessment success criteria differ for the same target?
Which scope ambiguities create the greatest safety risk?
What minimum evidence lets a sponsor decide whether an objective was answered?

2. Reconnaissance

How do you distinguish a current owned asset from historical or shared infrastructure?
Which fields make an asset observation reproducible?
When should passive evidence be escalated to active validation?

3. Vulnerability validation

Which facts must be proven between scanner lead and confirmed finding?
How do affected condition, exploitability, controls, and business impact differ?
When is “unresolved” the correct disposition?

4. Web and API

How would you model a transaction across subjects, actions, objects, tenants, and states?
What paired evidence proves server-side authorization?
Why can the UI, status code, or scanner alone misrepresent the result?

5. Cloud and Kubernetes

Which immutable identifiers keep evidence in the correct tenant and cluster?
How do permission existence, effective access, reachability, and impact differ?
What remains after a workload or cluster is deleted?

6. Active Directory and identity

What makes a graph edge effective rather than theoretical?
How would you validate a certificate, delegation, ACL, or federation edge safely?
How do you prove remediation removed alternate paths?

7. Privilege and movement

What are the required edges in a host privilege path?
Which proofs avoid unnecessary credential collection?
How do you separate foothold, privilege, movement, and business impact?

8. Threat-informed emulation

What source detail must survive translation into a safe test?
Which lifecycle layers are hidden by the phrase “the detection failed”?
What exactly can be claimed after one successful atomic test?

9. AI and MCP

Which controls must exist outside the prompt?
How should tool inputs, partial failures, side effects, and raw artifacts be represented?
How do you test indirect prompt injection without giving content authority?

10. Labs and reporting

What makes a lab isolated, reproducible, observable, and disposable?
How should a finding separate observation, inference, impact, and limitation?
What conditions make a retest comparable?

11. Mobile and thick client

Which conclusions depend on a modified, rooted, jailbroken, or instrumented client?
Where must authorization be enforced when the client is untrusted?
How do build signer, update path, local storage, and backend behavior enter the evidence record?

12. Human and physical

What special authority and participant protections are required?
How can a scenario test the organizational control instead of blaming an employee?
Which results must never be published or retained unnecessarily?

13. Operator infrastructure

How are operator, tool, target, evidence, and management planes separated?
Which identities, artifacts, egress, and approvals need independent logs?
What evidence proves infrastructure teardown?

14. Program governance

Which metrics show defensive improvement without rewarding unsafe activity?
How are findings routed to software, identity, cloud, telemetry, analytic, workflow, or governance owners?
What evidence supports a maturity claim?

Technical glossary — precise terms used in this guide

The glossary favors operational definitions. Local policies may use different labels; record the approved definition when it changes the engagement.

Acceptance criterion: A pre-agreed observable condition that determines whether a test, remediation, or retest passes.
Active reconnaissance: Authorized traffic sent to a target to confirm reachability, service, technology, or behavior.
Adversary emulation: A controlled exercise reproducing selected, source-backed adversary procedures to evaluate controls and response.
Artifact: A file, request, event, configuration, transcript, image, or other object produced or collected during work.
Asset attribution: The evidence-based decision that a system, identity, service, or resource belongs to or is operated for an organization.
Attack path: A sequence of effective relationships and actions connecting an assumed starting position to a security consequence.
Authentication: The process of establishing or accepting an identity assertion.
Authorization: The decision that a subject may perform an action on an object under current policy and context.
Blast radius: The set of assets, identities, data, operations, or tenants plausibly affected by a validated condition.
Chain of custody: The documented acquisition, handling, access, transfer, and disposition history of evidence.
Claim ladder: The progression from source lead through observation, corroboration, reproduction, impact evidence, and bounded conclusion.
Cleanup: Removal, revocation, restoration, and authoritative verification of every test-created or modified object and state.
Compensating control: A control that reduces likelihood or impact when the primary weakness remains; it does not erase the underlying condition.
Confidence: The analyst’s assessment of how strongly available evidence supports a conclusion; distinct from severity.
Control plane: The API, policy, identity, and management mechanisms that configure or govern resources and workloads.
Deconfliction: The process for distinguishing exercise activity from real incidents and resolving safety, scope, or operational conflicts.
Detection hypothesis: A testable statement connecting relevant behavior to expected telemetry, analytic logic, and analyst decision.
Disposition: The reviewed state assigned to a lead or finding, such as confirmed, rejected, unresolved, remediated, or accepted risk.
Effective permission: The action actually permitted after inheritance, conditions, resource policy, boundaries, and explicit denies are applied.
Evidence: A preserved artifact or authoritative record that supports or challenges a stated claim under defined conditions.
Exploitability: Whether required preconditions and a viable procedure permit a weakness to produce a security consequence in the environment.
Finding: A reviewed, evidence-backed statement of an affected security property, scope, impact, root cause, and required action.
Human approval: An explicit, attributable decision authorizing a defined action after reviewing target, effect, data, and rollback.
Immutable identifier: A provider, directory, resource, object, or event ID intended to remain stable when display names change.
Impact simulation: A reversible, synthetic action that demonstrates a security consequence without causing the real harmful outcome.
Lead: An observation or source item worth investigating that has not yet met the finding acceptance criteria.
Minimum necessary proof: The least intrusive authorized evidence sufficient to answer the objective and support the decision.
Model Context Protocol (MCP): A protocol for exposing tools and resources to AI clients; it does not itself grant target authorization or guarantee tool safety.
Observation: A recorded result returned by a system, tool, person, or source under specified conditions.
Passive reconnaissance: Collection from supplied or existing sources without directly probing the target system.
Procedure: The environment-specific implementation of a behavior, including inputs, sequence, target, context, and observable effects.
Provenance: The origin and processing history of data, analysis, model output, evidence, or a claim.
Purple team: A collaborative attack–defense workflow that uses controlled procedures to improve prevention, telemetry, analytics, and response.
Retest: Comparable re-execution of a versioned acceptance test after a change to determine whether the security property now holds.
Rules of engagement (ROE): The detailed authority, scope, constraints, communications, safety, data, and stop conditions governing a security test.
Scope: The approved assets, identities, providers, people, locations, time, actions, data, and exclusions for the engagement.
Security property: The intended rule being evaluated, such as tenant isolation, least privilege, authenticated access, or event visibility.
Severity: The assessed magnitude of a finding under the chosen technical and business model; distinct from evidence confidence.
Side effect: Any created, modified, transmitted, consumed, charged, logged, or persistent state caused by a test action.
Stop condition: A defined event requiring the operator to halt, preserve state, and notify the authorized authority.
Synthetic marker: Non-sensitive test data or state designed to prove access or effect without touching real protected content.
Telemetry contract: The documented events, fields, sources, timing, collection, retention, and queries expected from a controlled procedure.
Threat-informed: Prioritized or designed using relevant source-backed adversary behavior plus the organization’s environment and decisions.
Tool effect class: A category describing whether a tool reads, scans, authenticates, writes, executes, changes privilege, moves, or transfers data.
Unresolved: A valid disposition indicating that current authorized evidence cannot confirm or reject the lead.
Vantage point: The source network, identity, device, region, resolver, route, or trust position from which an observation was made.
White team: The small authorized group coordinating safety, scope, deconfliction, and sponsor communication during an exercise.

Template 1 — Authorization and rules of engagement

Record sponsor and legal authority; purpose; in-scope and excluded assets, identities, providers, people, and locations; assumed access; permitted and prohibited technique classes; source infrastructure; time window; rate and availability constraints; credential and data rules; third-party approval; white team; communication; real-incident deconfliction; stop, pause, resume, and kill-switch authority; evidence retention; cleanup; public disclosure; signatures and revision history.

Template 2 — Objective and test-case record

Assign an objective ID; business decision; protected process; threat/control hypothesis; assumed starting point; target; prerequisites; authorized procedure; expected security property; expected prevention and telemetry; minimum proof; stop point; potential side effects; rollback; required evidence; reviewer; result; limitations; linked findings; and retest acceptance criteria.

Template 3 — Asset, identity, and scope record

Use a canonical ID; aliases; owner; business service; environment; criticality; hostname, address, cloud/resource, application, tenant, namespace, or directory identifiers; provider; exposure; authentication; technology evidence; identity relationships; source; first/last seen; attribution confidence; scope status; permitted probe class; review owner; and current decision.

Template 4 — Operator action and change ledger

Record action ID; objective; operator; approval; UTC start/end; source; target; identity; tool and version; normalized parameters or request reference; effect class; expected outcome; actual result; raw artifact IDs; target changes; secrets or data touched; defensive correlation; stop decision; cleanup action, owner, status, verifier, and exception.

Template 5 — Evidence record

Record evidence ID; objective/action/finding links; title; observation type; collector; acquisition time and time source; target and identity context; tool/source and version; original location; encrypted storage location; hash; handling classification; redaction; chain of custody; interpretation; confidence; reviewer; retention; deletion date; and publication approval.

Template 6 — Finding record

Record finding ID and title; affected asset, build, component, identity, tenant, and version; violated security property; root cause; preconditions; authorized reproduction; observation and evidence; demonstrated impact; plausible impact clearly separated; control context; likelihood and confidence; severity rationale; limitations; remediation options; detection opportunity; owner; due date; cleanup; and versioned retest procedure.

Template 7 — Detection-validation record

Record source behavior and ATT&CK procedure; environment relevance; hypothesis; test ID/version/hash; target and time; expected data sources and fields; raw event references; collection delay; analytic ID/version/query; alert and enrichment; routing; analyst decision; containment; result by lifecycle layer; gap classification; change owner; false-positive review; acceptance criteria; and retest.

Template 8 — Cleanup, retest, and closure record

Inventory created or modified accounts, credentials, certificates, files, tasks, services, payloads, sessions, routes, rules, domains, cloud resources, storage, images, packages, test data, AI indexes, prompts, logs, and evidence copies. For each, record owner, expected state, cleanup action, authoritative verification, exception, retention decision, second reviewer, retest result, residual risk, sponsor acceptance, and closure timestamp.

Final professional review checklist

Authority and safety

Every target and action traces to current written authority.
Third-party, cloud, human, physical, and high-impact permissions are explicit.
Stop, deconfliction, emergency, privacy, and safety procedures were tested.
No public visibility or tool capability was treated as permission.

Technical quality

Versions, configurations, identities, tenants, and preconditions are specific.
Raw output is preserved separately from interpretation.
Observations, reproductions, inferences, and demonstrated impact are distinct.
Alternative explanations and false positives were evaluated.

AI and automation

Tool-layer allowlists and permissions—not prompts—enforced scope.
Model, context, policy, calls, responses, evidence, and reviewer decisions are traceable.
Retrieved content and tool output were treated as untrusted.
Every accepted claim was independently verified.

Defensive value

Prevention, telemetry, analytics, alerts, analysts, containment, and recovery are separate results.
ATT&CK mappings describe the exact observed procedure.
Gaps have the correct telemetry, analytic, workflow, process, or architecture owner.
Retest criteria use the same versioned security property and procedure.

Reporting

The executive summary answers the sponsor’s decision.
Severity, likelihood, confidence, and limitations are supported.
Engineering teams receive reproducible evidence and practical remediation options.
No metric hides its denominator, scope, environment, or test date.

Closure

All target and operator changes are reconciled.
Credentials, sessions, resources, payloads, data, and AI artifacts are revoked or dispositioned.
A second reviewer verified cleanup exceptions and evidence handling.
Owners, due dates, retests, residual risk, and acceptance are recorded.

Publication gate: publicly share only synthetic or explicitly approved evidence. Remove customer and employee identifiers, credentials, internal architecture, unpublished vulnerabilities, sensitive defensive gaps, and operational details that create avoidable risk.