AzureAD-Attack-Defense: a chapter-by-chapter playbook for Entra ID attack and detection

The gap this playbook fills for Entra ID defenders

Entra ID documentation explains how a feature works. It rarely explains how an attacker abuses that feature, what the abuse looks like in logs, and which control would have stopped it. This repository is organised around that second question. Each chapter takes one scenario, such as password spray, consent grant abuse, service principals in Azure DevOps pipelines, the Entra Connect Sync service account, replay of primary refresh tokens, adversary-in-the-middle attacks, or application-based authentication in Entra Connect Sync, and walks through description, detection, mitigation and TTP mapping.

The audience is narrow and worth stating plainly. The README addresses identity and security experts, and the chapters assume familiarity with Entra ID, Microsoft Sentinel and the wider Microsoft security stack. A generalist administrator looking for a hardening checklist will find the material dense. A detection engineer who already writes KQL and owns an identity monitoring backlog is the reader this was written for. The README also frames the publication as a living document, updated as attack and defense practices change, and invites community contributions rather than presenting itself as a finished product.

How the chapters are structured and where the code lives

Every chapter follows the same guideline, which the README spells out: a description of the attack scenario, detection using the Microsoft security stack, mitigation with instructions for improving posture within the chapter's scope, and a mapping of the scenario to MITRE ATT&CK tactics, techniques and procedures. The playbook states it uses MITRE ATT&CK v11 across all chapters. That consistent shape is the main design decision here, and it is a good one: you can jump to the detection section of an unfamiliar chapter without relearning the layout.

The repository layout backs this up. The top level is a set of Markdown files, one per chapter, plus an appendix on identity security monitoring in Microsoft Cloud and a chapter on preventing lateral movement to Entra ID after Active Directory has fallen. Alongside the prose there are three supporting directories: queries, scripts and config, with a media folder for images. The queries directory is where detection content lives, the scripts directory holds PowerShell, and config holds configuration artifacts. The README does not document the contents of these folders file by file, so treat the directory names as the map and inspect the files before assuming what a given rule covers. Because the primary language is PowerShell, expect the automation to be Microsoft-centric rather than portable.

Reading the playbook: install steps and a first chapter

There is nothing to install. The project is a documentation repository, and the README gives no package, no module and no release artifact. The practical first step is cloning the repository and opening the chapter that matches your current incident or detection gap.

The commands below clone the default branch and list the top-level entries, which is the fastest way to see the chapter set and the supporting directories before you commit to reading anything.

git clone https://github.com/Cloud-Architekt/AzureAD-Attack-Defense.git
cd AzureAD-Attack-Defense
ls

You should see the chapter Markdown files (PasswordSpray.md, ConsentGrant.md, ServicePrincipals-ADO.md, AADCSyncServiceAccount.md, ReplayOfPrimaryRefreshToken.md, AADSecurityConfigAnalyzer.md, Adversary-in-the-Middle.md, EntraSyncAba.md), the appendix files, and the config, media, queries and scripts directories.

A sensible first use is to start with the chapter closest to a control you already own. If you run Entra ID Protection, start with PasswordSpray.md, which the README describes as the first chapter and the one that focused heavily on the Entra ID Protection detection mechanism for password spray. Read the detection section with your own tenant's sign-in logs open, then check the queries directory for matching rules before writing anything new.

ls queries
ls scripts

Use that listing to decide whether the repository already ships a rule for your scenario. The README does not describe an import process for the queries folder, so how you deploy a rule to Sentinel is your decision, not something the project prescribes.

Detection content is guidance, not a deployed control

The most important limitation is easy to miss because the chapters read as authoritative. This is a publication. Nothing in the repository runs against your tenant on its own, and the README makes no claim about testing detection rules against live environments. The authors describe the scenarios, insights and comments as based on their experiences during attack simulations, hands-on work or real-world scenarios. That is a statement about provenance, not about validation in your environment.

Two consequences follow. First, a detection described in a chapter is a starting point for a rule you still have to write, tune and test against your own log volume and licensing. Second, the mitigation sections describe controls that may not be available to you. If your tenant lacks the relevant Entra ID Protection tier or the Sentinel data connectors the chapter assumes, the detection guidance is theoretical for your case. The README does not map chapters to licence tiers, so that check is on you.

There is also a currency problem inherent to the format. The README calls the document living and says it will be updated as practices progress. The last push to the repository was on 2026-06-30. That is recent enough that the material is not stale, but a Markdown playbook about a cloud identity platform will always lag the product. Verify any portal path or feature name against current Microsoft documentation before you build on it.

How this differs from running an attack-path tool

A reasonable alternative for the same job is a tool that enumerates your tenant and produces findings, rather than a document that describes scenarios. Attack-path mapping tools query your directory, build a graph of principals and permissions, and output concrete paths an attacker could take in your environment. The difference in approach is direct: a tool tells you what is true in your tenant right now, while this playbook tells you what is generally possible and how to detect it.

Neither replaces the other, and the playbook's own framing supports that. Its TTP mapping exists so blue teams can build defenses for corresponding scenarios, which is a design-time activity, not a scan. If you need a prioritised list of exploitable paths in your own directory today, a graph tool answers that question and this repository does not. If you need to understand why a consent grant abuse appears the way it does in your logs, and which control closes it, the chapter format is the better fit. The repository's EIDSCA chapter points at Entra ID Security Config Analyzer, a configuration analyzer, which is a third category again: it checks settings rather than modelling attack paths.

Maintenance, licensing and what the repository does not state

The last push was on 2026-06-30, and the repository is not archived. There are no retrieved releases, which fits a documentation project: chapters are edited in place rather than versioned. That has a practical cost. There is no changelog to tell you what changed between your last read and the current main branch, so if you fork the repository or copy rules out of it, you have no release boundary to diff against. Tracking upstream means watching commits.

The licence is not stated anywhere in the repository files reviewed here. That matters more than usual, because the value of the repository is its text and its detection rules. Copying chapters into internal runbooks, or importing queries into a production Sentinel workspace, is exactly the kind of reuse a licence governs. Until you confirm the licence from the repository itself, treat internal quotation as safe and redistribution or incorporation into a product as unresolved. This is a factual gap to close, not a legal opinion.

Upgrade cost is low in the conventional sense, since there is no software to patch. The real recurring cost is re-reading. Every time Microsoft changes Entra ID Protection behaviour or Sentinel connector schemas, the detection sections of the chapters you rely on need revalidation, and the repository gives you no signal about which chapters were touched.

Editorial conclusion

Adopt this playbook if you own Entra ID detection engineering and need a scenario-by-scenario reference that maps to MITRE ATT&CK and Microsoft Sentinel, and read it before you tune alerts rather than after. Do not adopt it expecting runnable code: the repository is Markdown chapters plus queries, scripts and config folders, and the README describes no installer, no release and no support commitment. Verify first whether the chapter you care about matches your tenant's configuration, whether the detection guidance still lines up with the Microsoft security stack you actually have licensed, and whether the repository's queries folder contains rules you can import as written.

Frequently asked questions

Official sources

1. Cloud-Architekt/AzureAD-Attack-Defense on GitHub
2. Issues
3. README