# AzureAD-Attack-Defense: ten flat files, an ATT&CK map frozen in January, and no license > A community playbook for defending Microsoft Entra ID, organised as eight attack chapters plus two appendix entries, each one detection and mitigation guidance mapped to MITRE ATT&CK. The substance is sound and entirely defensive. The bookkeeping is where the gaps are: no releases, no license file anywhere in the tree, and a combined attack map served from a folder dated nine months before the last commit. **Cloud-Architekt/AzureAD-Attack-Defense** — This publication is a collection of various common attack scenarios on Microsoft Entra ID (formerly known as Azure Active Directory) and how they can be mitigated or detected. - Repository: https://github.com/Cloud-Architekt/AzureAD-Attack-Defense - Stars: 2,558 · Forks: 367 - Language: PowerShell - License: not declared - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/cloud-architekt-azuread-attack-defense ## Ten markdown files sit flat at the root instead of in a docs tree Every chapter in this playbook is a top-level markdown file, linked from the README by bare filename. There is no `docs/` directory, no `chapters/` directory and no site generator in the tree. What sits at the root is eight chapter files, two appendix files, this README, and four asset directories: `config/`, `media/`, `queries/` and `scripts/`. Those four directories tell you how the playbook is meant to be used. `scripts/` holds the code, and the repository's primary language is PowerShell. `queries/` holds the detection queries. `config/` holds configuration. `media/` holds the ATT&CK visualizations. The consequence of the flat layout is that a chapter is a file you can read, quote or check into your own documentation without any build step, which is a genuine benefit for a document that describes itself as a living document. The cost is that there is no versioning underneath it at all: the repository has no GitHub releases, and there is no changelog at the root to tell you what changed between two points in time. The one versioning signal that does exist is inside `media/`, and it is a file path rather than a tag. ## The combined ATT&CK map is served from a folder named for January 2025 The README links the consolidated attack scenario visualization to a path that ends in `media/mitre/Update-Jan-2025/Attacks-combined_2025.svg`, and the MITRE ATT&CK Navigator link points at the matching `.json` layer in the same folder. Both filenames and the folder name carry a 2025 stamp, and the folder name carries a month. The most recent push to this repository is 2026-06-30. So the consolidated map and the repository contents are nine months apart, and the only way to tell which is which is the date in the asset path. Chapters may have been revised since the map was drawn; nothing in the documentation states that the map is regenerated on release, and with no releases there is no event to regenerate it on. There is a second freshness marker one section earlier. The MITRE ATT&CK section says the playbook leverages framework v11 in all of the chapters to map techniques, tactics and procedures to the attack scenarios. So the pinned framework version and the map's asset date are two independent numbers, and neither one is tied to the repository's last commit. Both combined and per-chapter visualizations are promised. The README states that because the playbook carries a high number of detection rules, a visualization containing all the attack scenarios mapped to TTPs was created, and that every individual chapter also has a visualization for its own scenario. ## The metadata reports the license as unknown and no license file exists The repository's license field reads as unknown, and the top level of the tree contains no license file. The entries are ten markdown documents, the README, and the four asset directories. Nothing in the visible documentation grants reuse. That matters more here than it would for a library. The material a reader actually wants from this project is the content of `queries/` and `scripts/`: detection logic and PowerShell to deploy in a tenant they administer. Copying those into an internal runbook or a commercial security product is a decision that needs a license, and there is nothing on this page to make it. This is an absence rather than a contradiction. No license file is present to be inconsistent with the license field, and no chapter text discussing licensing is visible. The honest reading is that the project has not stated terms, and a reader who needs them has to ask the authors. For contrast, the authors are identified and reachable. Two are credited as authors, and six more are listed as contributors and reviewers, each with a blog and a social link in a table. ## Every chapter promises the same four sections, which is what makes the set usable The playbook commits to a fixed chapter template, and the README states it up front so a reader knows what to expect in each file: a description of the common attack scenarios, detection of the attacks by leveraging the Microsoft security stack, mitigation for the attack together with instructions for improving security posture based on the chapter scope, and matching of the scenario and its detection capabilities to MITRE ATT&CK tactics, techniques and procedures. Four elements, in the same order, eight times. That is a modest promise and it is the one that makes the collection more useful than a pile of isolated blog posts, because a chapter on password spray and a chapter on consent grants can be read side by side and compared. The detection half is anchored to specific Microsoft products rather than to generic telemetry. The detection sections cover Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect, and Microsoft Defender for Cloud. The coverage itself is where the chapters differentiate. Password Spray, Consent Grant, Service Principals in Azure DevOps Pipelines, Microsoft Entra Connect Sync Service Account, Replay of Primary Refresh (PRT) and other issued tokens, Entra ID Security Config Analyzer, Adversary-in-the-Middle attacks, and Microsoft Entra Connect Sync Application-based Authentication. The two appendix entries are different in kind: an overview of identity security monitoring in Microsoft Cloud, and a chapter on preventing lateral movement to Entra ID when Active Directory has already fallen. ## The section on detection rule templates ends partway through a word The heading is Detections and rule templates for attack scenarios. The text under it names the four Microsoft products the detection coverage will use, then breaks off. The last complete clause covers the detection capabilities of Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect and Microsoft Defender for Cloud, saying these will be covered in the detection part of the attack scenarios. The next sentence begins with the words Custom rule te and stops there. So the introductory section for rule templates is unfinished at exactly the point where it would have told you what the custom rules are, which is the part a practitioner would most want before opening `queries/`. What survives is the chapter template described above, which tells you a detection section exists in each file, and the stated per-chapter and combined visualizations. Between those, a reader can still find the rules. They just cannot find the framing the author intended for them. The same document carries other small breaks in the same region. The MITRE paragraph spells the term Technics rather than Techniques, while the chapter guideline higher up spells it correctly. The Background section calls the project the Azure AD Attack & Defense Playbook, using the name the project has since moved away from, and spells formerly as formely when it introduces Entra ID Protection. ## One contributor's two links point at two different domains The contributors and reviewers section is an HTML table with one row of table cells, each holding a name link, a social link and a blog link. In five of the six cells the name link and the blog link share a domain, or the pair is at least visibly the same property. The sixth cell does not match. Fabian Bader's name is linked to `www.cloudbrothers.info` while the blog link beside it, on the same line under the same name, points to `www.cloudbrothers.com`. Two different domains, a `.info` and a `.com`, for one person in a single row. One of the two is wrong and the page does not say which. The remaining rows are consistent in the same way, with Sami Lamppu and Thomas Naunheim in the authors table above pointing at personal domains, and the other five reviewers pointing at properties including a shared blog for two of them. Worth noting for what it is: this is an all-contributors style block maintained by a bot comment marker above and below it, and the sort of generated table where one hand-edited cell can drift. It is a small thing, and it is the kind of small thing that tells you the table is regenerated rather than reviewed. ## The project's origin story is a record of how slowly this kind of work moves The Background section is two paragraphs and it is more useful than most origin stories, because it records a scheduling lesson rather than a mission statement. The idea came from Thomas Naunheim. The first Teams call was in Autumn 2020, where he presented it and it was sold immediately. The first chapter was Password Spray, and it focused on the Entra ID Protection detection mechanism, formerly called Azure AD Identity Protection. The recorded lesson from that first chapter is that calendar time to finalize the research took significantly longer than expected, because of the complexity of the research and the different angles available on it. The conclusion drawn is that scoping is very important, as it is in any project of that kind of work. Read next to the current state, that is a useful calibration. Five and a half years after the first call there are eight chapters and two appendix entries, and the map asset is dated January 2025. A reader expecting a chapter every few weeks will be disappointed, and the Background section is where the project says so itself. The document also invites identity and security experts from the community to contribute updates, feedback, comments or further additions, which is consistent with a project that describes itself as a living document updated as practices and techniques change. ## Conclusion Read this playbook if you run Entra ID and want a detection and mitigation checklist organised around real attack scenarios rather than around product features. Two authors and six named reviewers maintain it, and the value is in the coverage: password spray, consent grants, Azure DevOps service principals, Entra Connect sync accounts, primary refresh token replay, configuration analysis, adversary-in-the-Middle, and application-based sync authentication. Before you reuse anything from it, check the license yourself, because the metadata reports it as unknown and there is no license file at the root of the tree. And treat the January 2025 attack map as a snapshot rather than current, since chapters and repository have both moved since. ## FAQ ### What does the AzureAD-Attack-Defense playbook cover? Eight chapters, each following the same four-part structure: scenario description, detection using the Microsoft security stack, mitigation with posture instructions, and a mapping to MITRE ATT&CK TTPs. The chapters cover Password Spray, Consent Grant, Service Principals in Azure DevOps Pipelines, Entra Connect Sync Service Account, Replay of Primary Refresh and other issued tokens, the Entra ID Security Config Analyzer, Adversary-in-the-Middle attacks, and Entra Connect Sync Application-based Authentication. ### Which Microsoft security products does AzureAD-Attack-Defense map its detections to? Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect, and Microsoft Defender for Cloud. The detection sections of the attack scenarios cover the capabilities of those four products, and the repository carries a queries directory alongside scripts, config and media. ### Which MITRE ATT&CK version do the chapters use? Framework v11, and it is applied in all of the chapters to map techniques, tactics and procedures to the attack scenarios. The consolidated map of all scenarios is published as an SVG with a matching ATT&CK Navigator JSON layer, both under a media path whose folder is named Update-Jan-2025. ### Can I reuse the detection queries and scripts from AzureAD-Attack-Defense? Check the terms first. The repository's license field reads as unknown, and the top level of the tree contains no license file, so nothing in the visible documentation grants reuse of the content in the queries and scripts directories. The authors are identified in the README if you need to ask. ### Does AzureAD-Attack-Defense have versioned releases? No. The repository has no GitHub releases and no changelog at its root. Each chapter is a flat markdown file linked by filename from the README, so there is no version to pin to; the only dated artifact is the folder name inside the media directory holding the combined ATT&CK map. ## Sources - [Cloud-Architekt/AzureAD-Attack-Defense on GitHub](https://github.com/Cloud-Architekt/AzureAD-Attack-Defense) - [Issues](https://github.com/Cloud-Architekt/AzureAD-Attack-Defense/issues) - [README](https://github.com/Cloud-Architekt/AzureAD-Attack-Defense/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloud-architekt-azuread-attack-defense