Key takeaways
- The foothold type defines the threat scenario the exercise can answer: a standard domain user tests segmentation, a local administrator tests credential extraction paths.
- Objectives must name a specific target or a defined detection outcome, not a technique or a phase of the kill chain.
- Rules of engagement protect live services and give the blue team a benchmark for assessing its own response.
- A report that maps each finding to the objective it tested is more actionable than one that lists techniques without that context.
- Detection maturity determines the appropriate scope: narrow objectives test specific gaps, while broad scope requires a capable SIEM to make the results interpretable.
What a scope document has to settle before the exercise starts
An assumed-breach exercise asks a different question from a standard penetration test. A pentest asks whether an attacker can get in. An assumed-breach test grants that access, then asks what happens next. The scope document separates a focused, reproducible exercise from a free-form exploration that produces findings nobody can act on.
Four decisions have to be made before the first connection: what credential or shell to hand the operator, what targets define success, which systems are excluded, and who the deconfliction contact is. Each shapes what the exercise can and cannot tell you.
The deconfliction contact matters more than it might seem. A known IP address or user account hitting internal systems will sometimes trigger a real alert. Without a named person who can confirm the activity is authorised, a security team may treat it as a genuine incident, interrupt the exercise, or run a parallel investigation. The scope document is where that confusion is prevented.
Foothold options and what each tests
The foothold is the position the operator starts from: a set of credentials, a remote shell on a workstation, or a session on a service account. The choice is not arbitrary. Each foothold tests a specific question about your environment's internal security posture.
A standard domain user with no local administrator rights tests the minimum-privilege scenario. If an operator with those credentials can reach a domain controller, read an HR database, or access backup infrastructure, the finding shows directly that internal segmentation is not working. A local administrator on a single workstation opens a different set of techniques. The article on LSASS memory dumping covers what the credential extraction path looks like from that position.
A service account foothold tests a different threat model: what an attacker achieves after compromising an application or a scheduled task rather than a human account. Service accounts often reach parts of the network that no user account should, and they are rarely audited. The foothold you choose determines what the exercise answers, so it should follow from the threat scenario your organisation cares most about.
| Foothold | Starting privilege | Primary question | What it does not test |
|---|---|---|---|
| Standard domain user | Least privilege | Can an unprivileged account reach sensitive assets? | Endpoint controls, local privilege escalation |
| Workstation with local admin | Medium, one host | What credential extraction and lateral movement paths are open? | Initial endpoint compromise |
| Service account | Varies by account | Are application-tier reachability paths over-provisioned? | Interactive user access patterns |
| Domain-joined workstation, standard user | Standard user | Does a full client-side chain including EDR hold? | Service account and API paths |
Setting objectives that test a real threat scenario
Objectives turn the exercise into a test. Without them, the operator explores and the report lists techniques. The MITRE ATT&CK framework gives each step a name, from lateral movement through credential access to the final target. With named objectives, the report answers a specific question: could an attacker reach what you most need to protect?
Objectives come in three forms. A destination objective names a specific system or dataset: access the payroll database, read a file on the finance server, obtain credentials for a named account. A detection objective defines what the blue team should catch. The exercise succeeds from the operator's perspective if a particular technique goes undetected past a defined point. A combined objective pairs both: reach the destination without triggering an alert.
The cloud token theft article in this cluster shows one destination objective in practice: an operator pivoting from an endpoint foothold to a cloud tenant using cached tokens as the bridge. The framing matters because it determines what counts as a finding, what counts as success, and what the remediation recommendation addresses. Set vague objectives and the findings will be vague. Set specific ones and the remediation recommendations follow directly.
In
Foothold granted
Credentials or shell handed to the operator
Internal reconnaissance
Network map, privilege level, adjacent systems
Through
Lateral movement
Paths from the starting position to adjacent systems
Credential access
Cached secrets, service tokens, Kerberos tickets
Out
Objective test
Operator reaches or fails to reach the defined target
Evidence collected
Path taken, detection gaps, remediation points
Rules of engagement: what the operator can and cannot do
Rules of engagement define the boundary between a structured exercise and an uncontrolled one. They answer four questions: which systems the operator can touch, which actions are out of bounds, what happens if a critical system is reached unintentionally, and what notice the operator gives before taking any action that could cause disruption.
Out-of-scope systems typically include production payment infrastructure, medical devices, operational technology, and third-party supplier networks. The exclusions are not about protecting the operator from consequences. They protect live services from accidental disruption during a test. An exercise that causes a real outage is a failure regardless of what it found.
The SIEM detection article in this cluster describes what the blue team should see during the exercise. That view only makes sense if the rules of engagement define what the operator is authorised to do. An expected detection and an unexpected one are different findings, and the report should distinguish them. For organisations considering a broader campaign, a red team engagement extends the same model to physical access, social engineering and a longer timeline.
Detection maturity
Validate detections
Test whether specific alerts fire against one defined technique and foothold.
Full simulation
Broad objectives, active blue team, closest to a sustained real-world intrusion.
Build a baseline
Safe starting point: one foothold, one objective, focused findings to act on.
Outrunning the defence
Broad scope without mature detection produces findings the team cannot respond to.
Objective scope
What the engagement produces and how to read the findings
The report from an assumed-breach exercise has a different structure from a standard penetration test report. A pentest finding describes a vulnerability. An assumed-breach finding describes a path: what the operator started with, the steps taken to reach each system, the evidence collected at each step, and the detection that should have fired but did not.
Each finding maps to the objective it tested. A report that lists techniques without that mapping mixes findings that address the agreed question with findings that are interesting but out of scope. The report should also record which objectives were not reached and why: a path a control blocked is as informative as a path that succeeded. For a team that wants a parallel detection exercise, a purple team session uses the same findings as a starting list of techniques to run against the SIEM.
NIST SP 800-115 describes the documentation an assessment has to produce across its planning, execution and reporting phases. The NIST Cybersecurity Framework identifies the control categories that remediation recommendations should map to, connecting technical findings to organisational action. Together they give the report a structure that regulatory reviewers, boards and the technical team can each work from.
Assumed-breach testing and UAE cyber resilience requirements
Assumed-breach testing aligns with the resilience requirements UAE financial regulators have set in recent years. The Central Bank of the UAE (CBUAE) expects licensed financial institutions to show they can detect and contain threats from inside the network, not only block external access. An assumed-breach exercise tests that directly, starting from a position the attacker has already reached.
In Dubai, entities under the Dubai Electronic Security Center (DESC) framework, including government bodies and their direct suppliers, carry cyber resilience requirements that go beyond perimeter controls. An assumed-breach test works from inside that boundary. In Abu Dhabi, healthcare organisations regulated under ADHICS face access control and incident response requirements that the exercise can produce evidence against, particularly where privileged access paths are a concern.
Federal entities across the UAE operate under the National Electronic Security Authority information assurance standards, which set control objectives covering internal network segmentation, privileged access management and detection capability. An assumed-breach test generates findings against all three. For UAE organisations, the exercise produces documented evidence: a named objective was set, a structured test was run against it, and the outcome is recorded in a form that regulatory reviewers and boards can read and act on.
Frequently asked questions
What is an assumed-breach exercise?
An assumed-breach exercise is a structured security test that starts from the position that an attacker already has a foothold inside the network. Instead of testing whether initial access is possible, it tests what an attacker can do once inside: which systems can be reached, which credentials can be obtained, and whether the blue team detects the activity. The operator is given a starting credential or shell, and the test runs from there toward a defined objective.
How does an assumed-breach test differ from a penetration test?
A penetration test tries to break in. An assumed-breach test skips that step and asks what happens next. A pentest finding describes a vulnerability in the perimeter or authentication layer. An assumed-breach finding describes a path through the internal network, mapped to a specific objective. The two exercises answer different questions and are often run in sequence, with the assumed-breach exercise picking up where the pentest left off.
What foothold should I grant for a first assumed-breach engagement?
A standard domain user with no local administrator rights is the lowest-risk starting position and tests the most important question: whether an unprivileged internal account can reach sensitive assets. The findings it produces are directly actionable for access control and segmentation teams. More privileged footholds are appropriate once that baseline is established and remediation applied.
How do I define objectives for an assumed-breach test?
Name a specific system, dataset, or account that represents a genuine business risk: the payroll database, the configuration store for a critical application, the credentials for a named privileged account. A well-formed objective has an unambiguous outcome: either the operator reached it or did not. Technique-based objectives such as 'test lateral movement' are harder to report against and harder to remediate.
Which systems should be excluded from an assumed-breach scope?
Production payment infrastructure, medical devices, operational technology, and third-party environments the organisation does not control are standard exclusions. The purpose is to prevent accidental disruption to live services, not to limit what the operator can find. Exclusions should be agreed in writing before the exercise begins and reviewed against the foothold to confirm the operator has no path to them from the starting position.
What is a deconfliction contact and why does an assumed-breach exercise need one?
A deconfliction contact is a named person who can confirm to the security operations team, on request, that specific activity is part of an authorised exercise. Without one, an alert generated by the test may be treated as a real incident. The team responds, the exercise is interrupted, and two investigations run in parallel without either side knowing about the other. A deconfliction contact prevents that without tipping off the analysts who should be trying to detect the operator.
Can assumed-breach findings map to MITRE ATT&CK?
Every technique an operator uses in an assumed-breach exercise has a MITRE ATT&CK identifier. Mapping findings to the framework lets you compare results across engagements, prioritise detections by technique frequency, and measure remediation by checking whether previously used techniques would still succeed. The framework also provides a shared vocabulary between red and blue teams when reviewing findings together after the exercise.
How long does an assumed-breach exercise typically run?
Scope and objectives determine duration more than foothold does. A focused test against one objective with a standard-user foothold can run in two to three days. An exercise with multiple objectives across a segmented network takes longer. Fixing scope before the engagement starts is the most reliable way to keep duration predictable and findings actionable.
What sections should an assumed-breach report contain?
The report should cover the scope agreed, the foothold granted, the objectives set, and the outcome against each one. Each finding should describe the path taken, the systems reached, the evidence collected, and the detection that should have fired. A closing section should map findings to remediation recommendations and note which objectives were not reached and why. That last point is as useful as the positive findings.
