Assumed Breach Testing Guide: Starting Inside to Test Detection and Containment

Most security testing spends its budget proving that an attacker can get in, and then runs out of time before it tells you whether anyone would notice them once they are inside. Assumed breach testing skips the front door: the testers are handed a foothold, such as a standard user's workstation, a valid domain credential, a cloud role or a test service account with an API key, and the exercise measures what happens next. It answers the questions boards and incident responders actually care about: how far can an intruder get, how long until we detect them, and how quickly can we contain them. This guide is for security programme owners, SOC leads and the people who commission and govern these tests. It covers objectives, scoping, safety controls, ATT&CK-based test plans, measurement of detection and containment, and how to turn results into fixes. It does not describe attack techniques or tooling.

Key takeaways

• Start from a realistic foothold that matches your threat model: a phished laptop, a leaked token, a compromised supplier account or a stolen service account credential.
• Measure the defenders, not the testers. The main outputs are time to detect, time to contain and which ATT&CK techniques produced no telemetry or no alert.
• Governance makes it safe: a small control group, written rules of engagement, a deconfliction route and a stop condition are needed before the first action.
• Non-human identities are a first-class starting point. A provisioned test service account or API key shows whether you can see machine credentials being misused, which many SOCs cannot.
• Results only matter if they are retested. Every missed technique should become a detection engineering ticket with an owner and a retest date.

What assumed breach testing is and why it differs

The idea comes from the Zero Trust principle Microsoft describes as assume breach: security controls are designed on the expectation that attackers may already be operating inside the environment, so they focus on limiting breach impact and enabling rapid detection and response. An assumed breach test turns that principle into an evidence-gathering exercise. Instead of asking whether the perimeter holds, it asks whether the inside of the network, the identity plane and the cloud control plane are observable and defensible.

It is different from a classic penetration test, which the UK NCSC describes as a way of gaining assurance in your vulnerability management, and from a full no-notice red team, which also tests initial access. Regulated red teaming schemes already recognise the need: the Bank of England CBEST implementation guide allows "leg up" assistance, where testers are given help to reach the next stage of an attack path when progress is slow, provided it is agreed with the regulator and recorded in the report. Assumed breach simply makes that leg up the planned starting point.

See the Red Teaming Guide, the Penetration Testing Guide and the Purple Teaming Guide for those formats in depth.

Setting objectives

Write objectives as statements about defensive capability, each one measurable. Weak objectives ("see what the testers can find") produce a list of findings and no decision. Good objectives look like these:

• Detection: the SOC raises a triaged incident within an agreed time (for example four hours) of the first credential access or discovery activity from the foothold.
• Containment: once an incident is declared, the compromised identity and host are isolated, sessions revoked and credentials rotated within an agreed time.
• Blast radius: from a standard user foothold, the testers cannot reach a named crown jewel, such as the payments database, the backup console or the domain controllers, without generating an alert.
• Identity plane: misuse of a service account or API key outside its normal pattern (new source, new API calls, bulk reads) is detected.
• Process: the escalation path from analyst to incident commander to system owner works out of hours and across teams.

Tie each objective to a business service and an owner. CBEST's remediation planning, for example, expects technical findings to be linked back to business risk and important business services, with board input.

Choosing the foothold and scoping the test

The starting point should be the compromise you consider most likely, not the most convenient.

The NCSC's scoping advice for penetration tests applies here too: involve risk owners, the technical staff who know the estate and the test team, and record boundaries, scenarios, effort, reporting needs and time constraints. Add three items specific to assumed breach: the exact foothold and how it will be issued, the objectives (crown jewels) the testers may try to reach, and the actions they must stop short of.

Where identity fits

Most assumed breach paths are identity paths. CISA's red team report on a US critical infrastructure organisation (AA24-326A) lists high-risk activity that went undetected, including anomalous LDAP queries, Kerberos abuse such as golden tickets and S4U2Self, DCSync and outbound HTTP from a domain controller, and notes that an Active Directory account-creation alert had been disabled. A test service account or API key is the cleanest way to test the non-human side of this.

• Provision, do not borrow: create the account through your normal process so it looks real, give it the permissions of a typical integration, and record it as a test identity in the inventory. See the Service Account Security Guide.
• Plant it where real secrets leak: for example a configuration file or pipeline variable the testers are told about, simulating a leaked secret. See the API Key Management Guide.
• Watch the right signals: new source addresses, new API operations, unusual hours, bulk reads and attempts to create further credentials (T1098 Account Manipulation, T1136 Create Account).
• Revoke and prove it: containment for a machine identity means rotating or disabling the credential and confirming that no derived tokens survive.

The Dropbox Sign breach shows why: an attacker reached a back-end configuration tool, compromised a service account with broad production privileges and reached the customer database, including API keys and OAuth tokens. An assumed breach test that starts from that kind of account tells you whether you would have seen the bulk read.

Building an ATT&CK-based test plan

A test plan lists the behaviours the testers will attempt after the foothold, mapped to MITRE ATT&CK so that every result can be compared with your detection coverage. The plan describes intent and expected evidence, not procedures. Build it from threat intelligence about actors relevant to you; the MITRE Center for Threat-Informed Defense Adversary Emulation Library publishes full emulation plans (including APT29, FIN7, menuPass, OilRig, Sandworm, Turla and Wizard Spider) with an intelligence summary and operational flow, plus micro emulation plans for common behaviours such as Active Directory enumeration, web shells, log clearing and data exfiltration. The library is Apache 2.0 licensed and states that it should only be used with prior, explicit authorisation. See the MITRE ATT&CK Guide for Defenders.

Use marker data (synthetic files created for the test) for any exfiltration or data access objective, never real personal or customer data. Agree that impact techniques such as T1486 Data Encrypted for Impact are demonstrated by reaching the position to perform them, not by doing them.

Safety and governance

Assumed breach tests run on live systems with real credentials, so they need the same governance as a regulated red team. CBEST and TIBER-EU both use a small control group (TIBER-EU calls it the control team) that is the only part of the organisation aware of the test, with information shared on a need-to-know basis.

• Rules of engagement: signed scope, footholds, permitted and forbidden actions, working hours, data handling, reporting cadence and the named authoriser. Include suppliers whose systems are touched.
• Control group and trusted agents: CISA's red team assessments rely on trusted agents in the target organisation who receive findings, deconflict activity and supply target scopes. Keep the group small and senior enough to make decisions.
• Deconfliction: a way for the control group to confirm quickly whether an incident is the test, without tipping off the SOC. Real incidents always take priority; a test must never mask one.
• Stop conditions: CBEST's control group can order a temporary halt if there is a risk of damage or disruption to an important business service. Write down who can say stop and how the testers are told.
• Risk assessment: complete one before work begins and review it during the test, as CBEST requires. Cover availability, data exposure, regulatory notifications and the chance that the test is mistaken for a real attack by a third party.
• Credential hygiene: all test credentials are inventoried, time-limited and revoked at close. Implants and artefacts are listed by the testers and removed, and removal is verified. AA24-326A noted implants persisting undetected on a legacy host without EDR for several months, which is exactly what a cleanup check must rule out.
• Payload handling: agree with defenders how suspicious samples are analysed. In AA24-193A some red team payloads were exposed when defenders analysed them in an internet-connected sandbox.

Measuring detection and containment

Record a timeline for every action: what the testers did and when (from their log), when telemetry appeared, when an alert fired, when an analyst triaged it, when an incident was declared and when containment completed. Compare the two timelines after the test. CISA's AA24-193A shows why this matters: the red team operated undetected through the first phase of an eight-month assessment, EDR quarantined some tools but alerts were not reviewed daily, and administrators investigated anomalies for weeks without the SOC knowing.

Distinguish three outcomes for each technique: not logged, logged but not alerted, and alerted but not acted on. Each has a different owner (platform, detection engineering, SOC operations). See the Detection Engineering Guide and the SIEM Guide.

How to run it: a phased approach

1. Prepare (2 to 4 weeks): agree objectives with the risk owner, appoint the control group, pick the foothold from your threat model, draft the ATT&CK test plan and the rules of engagement, and complete the risk assessment.
2. Baseline: check that the logs you expect to rely on (directory, identity provider, EDR, cloud audit, proxy) are actually collected and retained long enough to analyse after the test. AA24-193A found logs retained for only 60 to 90 days and EDR quarantine data for 30.
3. Issue the foothold: provision the device, account or test service account through normal processes, record it, and hand it over through a secure channel.
4. Execute covertly: testers work through the plan, logging every action with timestamps; the control group monitors for risk and deconflicts.
5. Escalate deliberately if undetected: if nothing is detected by an agreed point, increase noise in steps so that response and containment can still be tested. CISA's assessments use a second phase designed to trigger a response.
6. Switch to collaboration: once covert objectives are met or time runs out, run a purple team replay of missed techniques with the SOC to confirm root causes.
7. Close and clean up: revoke all test credentials, remove artefacts, verify removal and confirm the test identities are disabled in the inventory. This is the rollback step and must be signed off.
8. Report, fix and retest: produce a remediation plan with owners and dates, and schedule a retest of every missed technique.

Acting on the results

• Prioritise by path, not by finding: fix the control that would have broken the attack path earliest, for example tiering privileged accounts or removing a service account's excess rights, before chasing individual alerts.
• Turn gaps into detections: each "logged but not alerted" technique becomes a rule with a test case; each "not logged" technique becomes a logging change.
• Move beyond indicators: AA24-193A lists reliance on known-bad, IOC-based detection as a lesson because it missed alternate techniques; build behaviour and baseline-based detections.
• Fix process as well as tools: the same report cites bureaucratic processes and decentralised teams as hindering defenders. Escalation paths, out-of-hours cover and cross-team visibility are legitimate findings.
• Feed risk decisions: AA24-326A records that leadership had accepted the risk of an outdated web server and that a compensating WAF was left in monitor-only mode. Test results should reopen accepted risks where the compensating control did not work.
• Retest continuously: automate retests of fixed techniques with breach and attack simulation where possible. See the Breach and Attack Simulation (BAS) Guide and the Continuous Automated Red Teaming (CART) Guide.

Decision guidance: scale and frequency

• Small organisations or no 24x7 SOC: run an announced, time-boxed assumed breach exercise with your MDR provider, focused on one foothold and the containment steps you would take. The value is in proving the provider calls you and that you can disable accounts quickly.
• Mid-size with an in-house SOC: one covert assumed breach test a year, alternating footholds (endpoint, cloud identity, service account), with quarterly purple team replays.
• Large or regulated organisations: combine annual or biennial threat-led testing (CBEST, TIBER-EU, or DORA threat-led penetration testing under Delegated Regulation (EU) 2025/1190) with internal assumed breach tests between cycles, and continuous automated validation.
• Covert or announced: choose covert when you need an honest time-to-detect figure; choose announced or purple when detection is immature and the goal is to build coverage quickly.

Framework mapping

Common failure patterns

• Using a real production credential as the foothold: it cannot be cleanly revoked, muddies attribution in logs and may breach supplier terms. Always provision dedicated test identities.
• Testing footholds you do not fear: starting from a domain admin or a fully patched lab device tells you little. Match the foothold to how you are most likely to be breached.
• Measuring only the testers' success: a report listing paths to domain admin without detection timestamps does not answer the question the test was commissioned for.
• Leaking the test to the SOC: a large control group or a change ticket visible to analysts invalidates time-to-detect figures.
• No retest: findings closed on the word of the owner, with no verification, tend to reappear in the next test.

Practitioner checklist

• Write three to five measurable defensive objectives tied to named business services.
• Choose the foothold from your threat model, including a test service account or API key where machine identities are in scope.
• Appoint a small control group, a deconfliction route and a named person who can stop the test.
• Sign rules of engagement covering scope, forbidden actions, data handling and suppliers.
• Build an ATT&CK-mapped test plan from relevant threat intelligence or emulation plans.
• Confirm log collection and retention before the test starts.
• Capture tester and defender timelines and calculate time to detect and time to contain.
• Classify each technique as not logged, logged but not alerted, or alerted but not acted on.
• Revoke all test credentials and verify artefact removal at close.
• Assign owners and dates for every finding and schedule retests.

Standards and references

• CISA: Enhancing Cyber Resilience: Insights from CISA Red Team Assessment of a US Critical Infrastructure Sector Organization
• CISA: AA24-193A, Red Team Operations Against a Federal Civilian Executive Branch Organization
• MITRE Center for Threat-Informed Defense: Adversary Emulation Library
• NCSC: Penetration testing
• Bank of England: CBEST Threat Intelligence-Led Assessments Implementation Guide
• European Central Bank: TIBER-EU framework
• NIST: SP 800-53 Rev. 5
• Microsoft Learn: What is Zero Trust?

Related NHI Mgmt Group resources: Red Teaming Guide · Purple Teaming Guide · Penetration Testing Guide · Incident Response Guide · Service Account Security Guide