What your SIEM should catch during an assumed-breach exercise

What the exercise is testing: detection, not prevention

An assumed-breach engagement skips the entry question and starts from inside. The operator is granted a foothold, usually a single workstation in a standard user account, and the engagement begins from there. Whether your perimeter controls would have stopped the initial access is not the question. The question is: once an attacker is present, what does your monitoring see?

A penetration test that reaches domain admin is a failure of your controls. An assumed-breach exercise that reaches domain admin while producing no SIEM alert is a failure of your detection. Both are findings, but the remediation paths are entirely different, and an organisation that has only run penetration tests has likely never tested its detection coverage.

The most important output of the exercise is the comparison between the operator's attack timeline and your SIEM event log. Every step the operator took that does not appear in your logs is a blind spot. Every alert that fired on the right event is a control working. The gap between those two columns is the true finding, and it is only visible if your logging was complete before the exercise started.

Endpoint signals: what your EDR must see before lateral movement

Endpoint Detection and Response tools log process creation, network connections, file writes and registry changes. In an assumed-breach exercise, process creation is the first signal to validate. The operator's initial steps, querying Active Directory, running whoami /all and launching enumeration tools, all appear as process creation events. If those events are not reaching your SIEM, every technique that follows them is invisible too.

Credential access is the second checkpoint. The most common path from a standard user context to a privileged one involves reading from lsass.exe: a direct handle open, a memory dump, or a tool such as Mimikatz. LSASS process-access events should alert before the operator reaches the first lateral move. If they do not, the post-exercise review needs to document which rule is absent and which log source it depends on.

Token manipulation and privilege escalation follow credential access. Each step leaves a process-creation entry with its parent visible: a cmd.exe launched by mmc.exe where the user account has no reason to open a console, or a net localgroup administrators query from an endpoint that never joins domain administrative tasks. These entries exist in Windows Security and Sysmon logs; the question is whether they are being forwarded and whether a rule is watching for them.

Identity and directory signals: where most gaps appear

Active Directory is the most common target in an assumed-breach exercise and the source of the most common detection gaps. The operator will enumerate the domain: accounts, groups, Group Policy Objects, trust relationships. This generates a volume of LDAP queries from a single workstation that would not normally carry out that kind of directory work. A SIEM rule on LDAP query volume per source is one of the highest-value rules to have active before the exercise.

Kerberos logs reveal the next step. MITRE ATT&CK catalogues Kerberoasting as T1558.003 under Credential Access: the attacker requests a service ticket for an account with a Service Principal Name registered, then cracks the ticket offline. The request is visible in the domain controller's Security log as Event ID 4769. A rule alerting on a spike in 4769 events from a single source in a short window is the detection that finds this technique. For detail on how the attack chain runs, the article on Kerberoasting and offline service account cracking walks through each step. The article on cloud token theft in an assumed-breach exercise covers the parallel path through cloud identity, where Kerberos is replaced by OAuth tokens and the detection surface shifts to the identity provider's audit log.

DCSync is the endpoint of the identity attack chain: an operator with Domain Admin or equivalent rights replicates password hashes for every account in the domain. It appears in the domain controller's Security log as Event ID 4662 with a replication GUID. If that event does not produce an alert, the attacker can take the entire directory without a single SIEM notification. Enable Advanced Audit Policy on all domain controllers and confirm that 4662 is forwarded before the exercise runs.

Network and lateral movement signals

Lateral movement produces network events that endpoint logs alone cannot capture. SMB connections from a workstation to other workstations, WinRM sessions from a non-administrative endpoint, RDP from a machine that does not ordinarily act as a jump host: each of these is anomalous enough to be a high-signal detection if baselines exist. Confirm that netflow and DNS query logs are feeding your SIEM. If they are not, the operator's lateral movement is invisible even when every endpoint event is collected.

Pass-the-hash and pass-the-ticket attacks use valid credentials, so they do not produce authentication failures. They produce successful logins: Event ID 4624 with Logon Type 3 from a source workstation that has no scheduled task or service account to explain the connection. The rule is straightforward: a network logon from a workstation to a workstation, with a user account rather than a machine account, in a window where that user has no documented reason to access the target.

Named pipes, DCOM and WMI are the alternatives to SMB for lateral movement and they are less commonly logged. A red team engagement will use whichever method is least visible; an assumed-breach exercise will use the same ones and show you exactly which your rules miss. Check whether WMI process creation events (Event ID 4688 with the WMI provider host as parent) and DCOM activation events are forwarded to your SIEM before the exercise runs, not as a result of it.

After the exercise: mapping the coverage gaps

The post-exercise review compares two timelines: the operator's attack log, which records every action with a timestamp, and the SIEM's event record for the same window. Every operator action that does not correspond to a SIEM event is an undetected technique. Every SIEM alert that fired on a technique the operator did not use is a false positive. The ratio between detected and total actions is the detection coverage number the exercise produces.

Coverage gaps fall into two categories. Missing log sources mean the event never reached the SIEM. Missing rules mean the event arrived but no logic acted on it. Both need different remediation: a missing log source requires a forwarding agent, a firewall rule or an API connection; a missing rule requires a Sigma rule or a vendor detection pack and a tuning pass to reduce noise. Track both categories separately, because fixing one does not fix the other.

A purple team exercise is the natural next step after an assumed-breach review produces a list of gaps. Where the assumed-breach exercise runs the full chain and measures what was caught, a purple team session runs individual techniques one at a time, with the detection team watching in real time. Pairing the two, assumed-breach to map the gaps and purple team to close each one, is what NIST SP 800-137 describes as continuous monitoring assessment applied to practical detection coverage.

Log retention and rule hygiene before the exercise starts

An assumed-breach exercise that runs against a SIEM with seven-day retention tells you almost nothing useful. The operator's attack chain may span several days, and correlating early reconnaissance events with later lateral movement requires the full chain to be present in storage at once. Before the exercise, confirm that all endpoint, identity and network logs are retained for at least 30 days, and that the SIEM's correlation window matches the exercise duration.

Detection rules accumulate over time and many are disabled, suppressed or firing into a dead queue. Before the exercise, review the active rule set: which rules have fired in the last 90 days, which have never fired, and which are suppressed because they generate too much noise. A rule that is suppressed is as useful as no rule. If a rule is too noisy to run in production, the signal it was written to catch is unmonitored. Fix the noise rather than silencing the rule.

Baseline data is the third requirement. A network logon anomaly rule needs to know what normal network logons look like for each endpoint type. A Kerberos volume rule needs a baseline of typical TGS-REQ rates from each subnet. These baselines take time to build and they cannot be built on the day the exercise starts. Work backwards from the planned exercise date and allow at least two weeks of baseline collection first. The baseline collection also covers the systems an infrastructure pentest would target: domain controllers, jump hosts and key servers. If those endpoints are not forwarding logs before the exercise, the detections the test is meant to validate are not present to be measured.

Detection requirements in the UAE regulatory landscape

UAE financial institutions regulated by the Central Bank of the UAE face explicit continuous monitoring obligations. CBUAE cybersecurity guidance requires that banks and licensed financial entities maintain the ability to detect and respond to threats, and that they demonstrate this capability through periodic testing. An assumed-breach exercise with a post-exercise detection coverage review is one of the most direct ways to produce that evidence in a form a regulator can read.

In Dubai, the Dubai Electronic Security Centre sets security requirements for government entities and their suppliers. DESC mandates that covered organisations operate a Security Operations Centre or equivalent monitoring function, and that monitoring capability is assessed periodically. An organisation supplying services to a Dubai government entity that cannot show its SIEM was tested against a realistic attack scenario is carrying a gap that DESC's audit process is designed to surface.

In Abu Dhabi, the Department of Health's ADHICS framework requires healthcare providers to maintain security monitoring aligned with the ADHICS control set. Log retention, alerting on privileged account activity and detection of lateral movement are each named controls. An assumed-breach exercise provides the evidence that those controls are operational, not just documented in a policy that nobody has verified against real attacker behaviour.

The UAE Information Assurance Regulation applies federally and sets baseline monitoring requirements for all entities in scope. It aligns closely with NIST SP 800-137 in its requirements for continuous monitoring and periodic assessment. The SIEM gaps an assumed-breach exercise exposes are exactly the gaps a NESA-informed audit would look for, which means the exercise serves both internal improvement and external evidence at the same time.

Frequently asked questions