The EntraGUARD attack simulator: 35 known attacks, replayed read-only

Why a simulator on top of the audit

An audit measures posture control by control. It is precise, defensible, and exactly what a framework expects. But a decision-maker rarely asks “how many controls pass”; they ask “can someone get in”. Those are not the same question. A tenant can score well on paper and still expose a complete attack path, end to end — and a single viable path is all an attacker needs.

The simulator re-reads the findings the way an attacker would. Instead of a list of settings, it walks through a kill-chain: initial access, then persistence and escalation, then the configuration weaknesses that widen the surface. Each scenario answers one blunt question — “does this path work against this tenant, today?”

Read-only by design

This is the most important point: the simulator takes no action on the tenant. It never sends phishing, never triggers an MFA push, never creates an object, never changes a setting. Every scenario is evaluated solely from the configuration and state read through the same read-only Graph application the audit already uses. What it replays is the reasoning of an attack against the tenant's real configuration — not the attack itself.

That constraint makes the simulator safe to run on a production tenant in the middle of the day, and it is also its accepted limit: when a signal genuinely cannot be observed read-only, the step is marked indeterminate rather than guessed.

35 scenarios across three phases

The catalogue is grouped by kill-chain phase, and each attack can be switched on or off before a run:

Phase	Examples
Initial access	AiTM / session theft, device code phishing, password spray, legacy authentication, MFA fatigue, malicious external identity provider, accounts without MFA, unhandled risky users.
Persistence & escalation	Consent phishing, shadow admin, break-glass account abuse, service principal credentials, standing privileged roles, role-assignable groups, privileged guests, Golden SAML / federation, risky application secrets, takeover-grade Graph permissions.
Configuration & exposure	Conditional Access bypass, cross-tenant abuse, ownerless applications, dangerous redirect URIs, permissive user consent, app creation by users, no baseline protection, open guest invitations, no admin consent workflow, no Conditional Access at all, exploitable dynamic groups, anonymous SharePoint / OneDrive sharing.

What a run produces

Select the attacks, start the run: each scenario is replayed in turn — the screen scrolls through them one by one, just like the audit, without freezing the page. Nothing else is shown during the run; at the end, the result appears: an overall exposure score out of 100 and the number of viable attack paths among the scenarios run.

Each scenario carries its own verdict — viable attack path, attack interrupted or indeterminate — an exposure sub-score, and, when the path is broken, the exact break point: the control that stopped it. That detail makes all the difference between “you failed this scenario” and “your phishing-resistant MFA stopped it, keep it”.

History and reporting

Every run is kept in a dedicated history, filterable by period, each entry showing its score, its number of viable paths and its number of scenarios. Opening a run shows the full kill-chain of each scenario, and the run exports to a branded PDF — the same white-label treatment as the audit reports. The dashboard also surfaces the latest simulation as a card, so the exposure score sits next to the compliance score.

How to read it alongside the audit

The two are complementary. The audit is the exhaustive, framework-aligned measurement; the simulator is the attacker's-eye summary that lands the audit in a meeting. A good habit: present the exposure score and the number of viable paths first, then use the audit to explain why each path is open and what to fix. The break points show which controls already in place are doing their job — name them, because a defence that works is rarely given credit.