06 — TTP Validation Catalog

BLUF: Each card validates one observable ATT&CK behavior in an owned or explicitly authorized lab. Success means the approved proof was produced, expected telemetry was preserved, the control response was recorded, the stop condition was honored, and the environment was restored.

Use contract

Before selecting a card, record:

1. written scope and ownership;
2. exact hosts, identities, ports, data, and exclusions;
3. synthetic identities or canary data;
4. snapshot or configuration backup and recovery owner;
5. expected endpoint, identity, directory, DNS, proxy, firewall, application, cloud, and packet telemetry;
6. emergency contact, stop authority, proof limit, and cleanup plan.

Do not treat a tool, protocol, vulnerability, product alert, or outcome as an ATT&CK technique. Map the behavior actually observed. Record secondary mappings only when those behaviors also occurred.

Evidence record

Every run should produce one record containing:

Card 01 — Bounded scan of an owned IP range

Objective: Validate that a small allowlisted address range can be discovered and that network controls record the scan.

ATT&CK: Reconnaissance — T1595.001 Scanning IP Blocks.

Mapping rationale: The observed behavior is active scanning of an IP range. Service enumeration after a foothold belongs under T1046 instead.

Prerequisites: Written range allowlist; rate and time window; excluded systems; owner contact; packet capture or flow logs; synchronized clocks.

Safe lab procedure: Scan only the seeded range at the approved rate. Use one discovery method at a time. Record the source, target list, rate, and duration. Do not expand based on newly discovered routes or names.

Expected result: The seeded live hosts are identified without touching excluded systems. Network telemetry attributes the activity to the test source.

Telemetry and detection: Firewall and NetFlow records, IDS scan alerts, router logs, target connection logs, and PCAP. Validate fan-out, port count, rate, and source attribution.

Mitigation: External exposure reduction, ingress filtering, rate controls, segmentation, and alerting on unusual fan-out.

Evidence: Approved target file and hash, scan metadata, discovered seeded hosts, PCAP/flow query, alerts, and UTC timeline.

Stop condition: Stop on an out-of-scope address, instability, unexpected routing, owner request, or completion of the approved range.

Cleanup: Stop the scanner, remove only test outputs according to the data plan, retain required evidence, and confirm no recurring job remains.

Card 02 — Synthetic-account password-spray control test

Objective: Validate lockout, identity telemetry, and detection for a single controlled password across seeded accounts.

ATT&CK: Credential Access — T1110.003 Password Spraying.

Mapping rationale: One password is attempted across multiple accounts. T1078 applies separately only if a valid account is later used.

Prerequisites: Synthetic accounts; approved authentication endpoint; known lockout policy; maximum attempts; identity monitoring; help-desk deconfliction; no production credentials.

Safe lab procedure: Attempt one known test password against the fixed synthetic account list. Use the approved source and rate. Do not enumerate people, source breach data, rotate proxies, or continue after a success or lockout signal.

Expected result: Authentication failures and any seeded success are visible; lockout and alert behavior match the documented policy.

Telemetry and detection: Identity-provider sign-ins, domain-controller authentication events, source IP, user-agent/client, failure reason, account fan-out, and lockout records. Correlate many accounts receiving the same failure pattern from one source.

Mitigation: Phishing-resistant MFA, smart lockout, conditional access, legacy-auth removal, password screening, source throttling, and detection across accounts.

Evidence: Account-list hash, policy snapshot, attempt count, sign-in records, alert, lockout state, and cleanup confirmation.

Stop condition: Stop at the first unexpected success, lockout, non-synthetic account, service degradation, or approved attempt limit.

Cleanup: Unlock only test accounts if the plan requires it, rotate the canary password, and verify no test session or token exists.

Card 03 — Benign spearphishing-link telemetry exercise

Objective: Validate mail, browser, proxy, and user-reporting telemetry without collecting credentials or executing code.

ATT&CK: Initial Access — T1566.002 Spearphishing Link.

Mapping rationale: A link is the simulated delivery behavior. The landing page records only a synthetic campaign token and approved click metadata.

Prerequisites: Synthetic recipients or trained participants; approved template and sender; non-collecting landing page; privacy notice; mail/SWG telemetry; campaign stop contact.

Safe lab procedure: Send one approved message to the fixed recipient list. The link resolves to an owned page that stores no credentials, session cookies, or arbitrary form input. Measure delivery, click, block, and report outcomes.

Expected result: Mail controls, link analysis, browser/proxy controls, and reporting workflows produce attributable evidence.

Telemetry and detection: Mail gateway disposition, URL rewrite/sandbox result, DNS, proxy, browser protection, endpoint process/network evidence, and user-reported-phish events.

Mitigation: Secure email gateway, URL inspection, sender authentication, browser isolation, user reporting, and phishing-resistant MFA.

Evidence: Approved content hash, recipient count, delivery/click/report totals, alerts, landing-page logs, and deletion record.

Stop condition: Stop on unintended recipients, sensitive submission, external forwarding, system impact, complaint, or owner request.

Cleanup: Disable the campaign and landing page, expire tokens, remove test messages if approved, and retain only authorized aggregate evidence.

Card 04 — Public-facing application stop-at-proof validation

Objective: Confirm an intentionally vulnerable owned application path and its detection coverage without establishing durable access.

ATT&CK: Initial Access — T1190 Exploit Public-Facing Application.

Mapping rationale: The lab application is exploited through a known vulnerability. Any later execution, web shell, or account use requires a separate mapping.

Prerequisites: Owned application; fixed vulnerability and version; snapshot; canary flag; request limits; WAF/application/host telemetry; restoration test.

Safe lab procedure: Reproduce the minimum request sequence needed to read the benign flag or return an approved identity value. Do not deploy a shell, modify application data, enumerate adjacent services, or reuse the path elsewhere.

Expected result: The canary proof is returned and the request/application/host trail can be reconstructed.

Telemetry and detection: Reverse-proxy and WAF logs, application access/error logs, process creation, file integrity, container/runtime telemetry, and network connections.

Mitigation: Patch or upgrade, virtual patching, input validation, least privilege, application isolation, secret management, and exposure reduction.

Evidence: Version, request IDs, sanitized request/response, flag identifier, alerts, affected control, and restoration proof.

Stop condition: Stop after the flag, on data outside the canary path, unexpected code execution, instability, or scope uncertainty.

Cleanup: Restore snapshot or exact application state, rotate canaries if required, verify health, and preserve logs.

Card 05 — Windows local account discovery

Objective: Validate local-account discovery visibility using a seeded Windows host.

ATT&CK: Discovery — T1087.001 Local Account.

Mapping rationale: The behavior enumerates local user accounts. Domain-account queries belong under T1087.002.

Prerequisites: Owned Windows host; seeded local accounts; approved test identity; process/audit/EDR collection; baseline account inventory.

Safe lab procedure: Perform one read-only local-account enumeration method. Record the parent process, user context, and returned seeded accounts. Do not access profiles, credentials, or password material.

Expected result: Seeded accounts are listed and process or command telemetry identifies the query.

Telemetry and detection: Process creation, PowerShell/script logging where applicable, EDR command-line telemetry, local security-account queries, and remote-management context if used.

Mitigation: Restrict remote administration, apply least privilege, remove stale accounts, protect administrative interfaces, and alert on unusual enumeration chains.

Evidence: Baseline inventory, returned account list, process tree, event/query references, and result classification.

Stop condition: Stop if the query reaches another host, exposes credential material, or returns data outside the approved account fields.

Cleanup: End the session and confirm no scripts, scheduled jobs, accounts, or files were created.

Card 06 — Approved domain account discovery

Objective: Validate directory-account discovery and its directory, endpoint, and network evidence.

ATT&CK: Discovery — T1087.002 Domain Account.

Mapping rationale: The behavior queries directory identities. Group membership, trust, and permission discovery may need additional mappings when independently exercised.

Prerequisites: Owned directory lab; seeded OU and users; read-only identity; fixed query scope; LDAP/DC telemetry; data minimization plan.

Safe lab procedure: Query only the seeded OU and approved attributes. Use one method and one directory server. Do not request password material, authentication secrets, or unrelated personal attributes.

Expected result: Seeded identities are returned and LDAP plus endpoint activity can be attributed to the test identity and host.

Telemetry and detection: Directory-service logs where configured, LDAP diagnostics, DC network telemetry, client process/script logs, EDR, and identity analytics.

Mitigation: Directory ACL review, least-privilege search access, administrative tiering, protected attributes, segmentation, and analytics for unusual breadth or client context.

Evidence: Query definition, approved attributes, count, client/DC timestamps, telemetry queries, and limitations.

Stop condition: Stop if the query leaves the seeded OU, returns restricted attributes, causes DC impact, or uses an unintended identity.

Cleanup: Close the connection, remove local query output per the data plan, and verify no directory objects changed.

Card 07 — Allowlisted network service scan after foothold

Objective: Validate internal service-discovery telemetry against fixed lab hosts and ports.

ATT&CK: Discovery — T1046 Network Service Scanning.

Mapping rationale: The behavior probes hosts for listening services after access. It is distinct from external IP-block reconnaissance.

Prerequisites: Fixed host/port allowlist; approved source host; rate cap; target owner; endpoint and flow logs; excluded fragile services.

Safe lab procedure: Probe only the listed ports on the listed hosts. Use TCP connection checks or another approved method. Do not run broad vulnerability scripts or follow discovered routes.

Expected result: Seeded services are identified and the source fan-out is observable in host and network telemetry.

Telemetry and detection: Host firewall logs, service logs, NetFlow, IDS, EDR network events, connection failures, and short-window fan-out analytics.

Mitigation: Segmentation, host firewalls, management-network isolation, service minimization, rate detection, and authenticated asset inventory.

Evidence: Allowlist hash, rate, discovered ports, flow/alert records, target health confirmation, and UTC timeline.

Stop condition: Stop on an unlisted host/port, instability, unexpected sensitive service, or approved scan completion.

Cleanup: Terminate probes, remove temporary target files, verify target health, and retain the PCAP or flow evidence required by the plan.

Card 08 — Seeded-SPN Kerberoasting detection

Objective: Validate KDC and identity telemetry for a purpose-built service account without recovering or using a credential.

ATT&CK: Credential Access — T1558.003 Kerberoasting.

Mapping rationale: A Kerberos service ticket is requested for a seeded SPN in the lab. The exercise stops before password cracking or account use.

Prerequisites: Owned AD lab; seeded service account and SPN; non-production password; approved requesting identity and host; DC security logging; snapshot or account reset plan.

Safe lab procedure: Request the single seeded service ticket and record the request. Do not enumerate unrelated SPNs, export tickets beyond the evidence plan, crack the password, or authenticate as the service account.

Expected result: The expected service-ticket event and endpoint process/network trail are retained; detection logic identifies unusual requester, volume, encryption, or service context as configured.

Telemetry and detection: Kerberos service-ticket events, requesting account/host, service name, encryption type, EDR process tree, and directory changes to the seeded SPN.

Mitigation: Group managed service accounts, long random service passwords, AES support, privilege reduction, SPN inventory, and monitoring for abnormal ticket requests.

Evidence: Seeded account/SPN definition, ticket-request event, process tree, analytic result, and confirmation that no cracking occurred.

Stop condition: Stop after the single ticket, on an unintended SPN, unexpected authentication, DC impact, or missing telemetry.

Cleanup: Purge the test ticket if required, rotate the seeded password when the plan calls for it, and confirm no session used the account.

Card 09 — Seeded-account AS-REP roasting detection

Objective: Validate KDC telemetry for one lab account intentionally configured without Kerberos preauthentication.

ATT&CK: Credential Access — T1558.004 AS-REP Roasting.

Mapping rationale: The KDC returns an AS-REP for a seeded account lacking preauthentication. The exercise stops before password recovery or use.

Prerequisites: Owned AD lab; one seeded account; approved temporary preauthentication setting; DC logging; exact restoration step; non-production password.

Safe lab procedure: Request one AS-REP for the seeded account. Do not enumerate other accounts, crack the response, or use the account. Preserve the KDC and client evidence.

Expected result: The request is visible, the configuration weakness is confirmed, and the analytic outcome is recorded.

Telemetry and detection: Kerberos authentication-service events, preauthentication type/status, source host, client process, directory configuration, and identity alerts.

Mitigation: Require Kerberos preauthentication, monitor exceptions, use strong managed secrets, and regularly audit the directory flag.

Evidence: Before/after account setting, request event, process tree, analytic result, and proof that the response was not cracked.

Stop condition: Stop after the seeded response, on another account, missing telemetry, or unexpected authentication.

Cleanup: Re-enable preauthentication, verify the setting, rotate the seeded password if required, and confirm account inactivity.

Card 10 — Single-host internal proxy telemetry

Objective: Validate host and network visibility for one approved internal proxy path.

ATT&CK: Command and Control — T1090.001 Internal Proxy.

Mapping rationale: One lab host relays traffic between the operator and one allowlisted internal destination. The specific tool is implementation metadata.

Prerequisites: One pivot host and one destination; one allowed port; process and flow telemetry; pre-test route/listener/configuration manifest; short lifetime; recovery access.

Safe lab procedure: Establish the approved one-hop proxy, make one benign request to the destination, and stop. Do not add subnet-wide routes, scan, chain proxies, transfer tools, or keep the tunnel alive after proof.

Expected result: The benign request succeeds and both legs of the connection can be correlated to the pivot process and identity.

Telemetry and detection: Pivot process creation, listener and socket state, endpoint network events, flow logs, firewall/proxy logs, authentication logs, and PCAP where approved.

Mitigation: Egress controls, segmentation, application allowlisting, administrative-jump-host policy, process/network correlation, and alerts on unusual long-lived relays.

Evidence: Pre/post route and listener manifests, process hash/version, both connection legs, request result, alerts, and duration.

Stop condition: Stop after one request, on another destination or port, loss of management access, instability, or telemetry failure.

Cleanup: Stop the proxy, remove only test-created routes/listeners/files, restore captured configuration, verify service health and hashes, and preserve telemetry.

Card 11 — Isolated protocol-tunneling detection

Objective: Validate detection of a benign flow encapsulated inside an approved tunnel.

ATT&CK: Command and Control — T1572 Protocol Tunneling.

Mapping rationale: The defining behavior is encapsulation of one protocol inside another. Ordinary use of HTTPS, DNS, or SSH does not automatically satisfy the mapping.

Prerequisites: Isolated lab segment; approved encapsulating protocol; fixed endpoints; benign payload; PCAP and resolver/proxy/firewall telemetry; bandwidth and duration caps.

Safe lab procedure: Send a small canary message through the lab tunnel between the fixed endpoints. Do not use external infrastructure, bypass access controls, or transfer executable or sensitive content.

Expected result: The canary hash matches and the tunnel’s timing, volume, endpoint, and protocol characteristics are observable.

Telemetry and detection: PCAP, DNS/proxy/firewall logs as relevant, flow duration, byte ratios, request/response regularity, protocol violations, and endpoint process/network evidence.

Mitigation: Protocol-aware inspection, egress allowlisting, authenticated resolvers/proxies, segmentation, endpoint controls, and analytics for anomalous encapsulation patterns.

Evidence: Canary and hash, endpoints, protocol parameters, PCAP, alerts/queries, duration, and byte counts.

Stop condition: Stop after one canary, on external resolution/routing, unexpected bandwidth, service impact, or loss of attribution.

Cleanup: Terminate both endpoints, remove temporary configuration, verify listeners and routes are gone, and retain the approved packet evidence.

Card 12 — Canary-file transfer over existing lab C2

Objective: Validate exfiltration-over-C2 telemetry using a generated non-sensitive canary.

ATT&CK: Exfiltration — T1041 Exfiltration Over C2 Channel.

Mapping rationale: A canary file is transferred through an already established lab C2 channel. Ordinary pivot traffic or ingress transfer does not qualify.

Prerequisites: Owned C2 lab; fixed endpoints; generated canary; approved maximum size; DLP/network/endpoint telemetry; destination storage and deletion plan.

Safe lab procedure: Generate a small file containing only the run ID and random data, record its hash, transfer it once over the existing lab channel, verify the destination hash, and stop.

Expected result: Hashes match and the transfer is visible in endpoint, network, C2, and any DLP telemetry.

Telemetry and detection: Source file access, C2 task log, process/network events, proxy/firewall/IDS records, byte count, destination write, DLP result, and PCAP if approved.

Mitigation: Egress filtering, C2 detection, DLP, endpoint behavioral controls, least privilege, segmentation, and monitoring of unusual process-to-network relationships.

Evidence: Canary generator/version, hashes, size, source/destination, C2 task ID, alert/query results, and deletion verification.

Stop condition: Stop after one verified transfer, on any real data, size overrun, unintended destination, alert requiring escalation, or owner request.

Cleanup: Delete the canary from both endpoints according to the plan, terminate the task/session if required, verify removal, and preserve only approved evidence.

Result scale

Review cadence

Revalidate a card when the ATT&CK version, operating system, identity platform, sensor, policy, detection content, network path, lab topology, or procedure changes. Record the exact versions and never generalize one lab result to another environment without retesting.

Related notes

• Red Teaming 101 Index
• Red Teaming 101 Master Index
• Lab Detection Validation Framework
• Rules of Engagement
• Reporting and Portfolio Development
• Windows Domain Playbook