This publication is a collection of various common attack scenarios on Azure Active Directory and how they can be mitigated or detected.
All of the included scenarios, insights and comments are based on experiences from the contributors during their attack simulations, hands-on or real-world scenarios.
It should be considered a living document, which will be updated as practices progress & changes in attack and defense techniques.
We invite identity or security experts from the community to work together on this publication and contribute updates, feedbacks, comments or further additions.
In all chapters, we follow the same guideline on the chapter structure. When reading, you can expect to find:
The following sections contain a short description of each chapter you can find from the ‘Azure AD Attack & Defense Playbook’.
The initial idea for creating the ‘Azure AD Attack & Defense Playbook’ came from Thomas Naunheim.
Our first Teams call was somewhere in Autumn 2020 where Thomas presented the idea and it was sold immediately.
The first chapter was about the ‘Password Spray’ attack where we focused heavily on the Azure AD Identity Protection detection mechanism to detect ‘password spray’ type of attacks.
During the first chapter we learned that calendar time for finalizing the research might take significantly longer than expected due to the complexity of the research and different angles on the research.
Scoping, like in any project type of work, is extremely important.
MITRE ATT&CK Framework is commonly used for mapping Tactics, Techniques & Procedures (TTPs) for adversary actions and emulating defenses on organizations around the world.
In this playbook, we are leveraging the MITRE ATT&CK framework v11 in all of the chapters to map Technics, Tactics & Procedures (TTPs) to the attack scenarios.
This would help Blue Teams to build defenses for the corresponding scenarios.
You can expect to find multiple detection rules from the individual chapters based on the specific attack scenario.
Because the playbook has a high number of detection rules, we decided to create visualization that contains all the attack scenarios mapped to TTPs.
Take also into account, every individual chapter has visualization for the corresponding attack scenario.
The related detection capabilities of Microsoft Security products (Microsoft 365 Defender, Microsoft Sentinel, Azure AD Identity Protection, Microsoft Defender for Cloud) will be covered in the detection part of the attack scenarios.
Custom rule templates for Microsoft Sentinel, which has been developed for the playbook, are also mapped to the TTPs.
The detection rules are available as Microsoft Sentinel Rule Template (ready-to-deploy) in JSON (ARM Template) format here.
Side note: We’ve used the existing TTP mapping from the Microsoft Sentinel rule templates and Microsoft 365 incident correlation.
Some detections are not offering full MITRE ATT&CK coverage and are not included in this visualization.
Typically, one chapter has taken approximately 1-2 months of calendar time so it has been quite an effort to put all four (4) chapters & appendix together.
During the last two (2) years we did research on the following scenarios:
“A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access.”
The chapter was initially created in November 2020 and updated in November 2021 to contain the latest security product updates from Microsoft Ignite 2021.
The chapter contains a short description of the attack and tools used to simulate the password spray type of attack. In the detection part multiple Microsoft security solutions as used such as Microsoft Sentinel & Defender for Cloud apps.
On the side notes, there are some considerations for the on-prem environment and ADFS as well if one is still in use.
“In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents.
The attacker then tricks an end-user into granting that application consent to access their data either through a phishing attack or by injecting illicit code into a trusted website.
After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account.
Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack since these are third-party applications and are external to the organization.
These attacks leverage an interaction model that presumes the entity that is calling the information is automation and not a human.”
The chapter contains an attack description and explanation of why it’s important to secure & monitor activities around the Azure AD Consent framework. In the detection chapter we used the following solutions:
Because the topic is huge and complicated the mitigation part contains instructions & details on how you can reduce the attack surface in your environment.
In the following two attack scenarios, we’ve set our focus on privileged service principals as part of release pipelines in Azure DevOps (ADO) and the (potential) limited visibility in auditing.
ADO is a large topic and in this chapter, the scope is limited only to the scenarios mentioned above. The same path followed here:
When we worked with this chapter we spent a lot of time on the detection technics which was a complicated mainly because of the ADO audit log schema.
Nevertheless, hard work pays off and we were able to achieve our defined target and detect attacks in Microsoft Sentinel.
The chapter contains deep-dive information on how to secure the Azure DevOps environment on the mitigation chapter.
In this paper we are mainly focusing on the following scenario:
Out of scope are privilege escalation and attack paths from AADC server in direction to Active Directory (incl. abuse Azure AD DS connector account)
The latest chapter released on the 14th of March 2022 is all about abusing the Azure AD Connect sync service account.
To be precise, the AAD Connect account is responsible for performing actions to the Azure AD side.
The topic and attack scenario was extremely interesting for research work and even though I’ve worked a lot with Azure AD Connect in the past I have to admit that I’ve learned a lot during the last two (2) month period.
We did some interesting findings which we haven’t noticed earlier.
If you have read this far I encourage you to check out the KQL queries for Microsoft Sentinel which we created during our research work.
Microsoft has introduced Windows 11 with the requirement to use a Trusted Platform Module (TPM) chip.
This has greatly increased the capabilities to use Windows 11 OS security features including an extra layer of protection for cloud-based authentication scenarios.
The Primary Refresh Token (PRT) and other relevant keys can be well protected by TPM in Windows 11 but also in Windows 10 and Windows Server versions from 2016 and above.
Taking this into account in this paper we mainly focus on the following scenarios:
With simple specifications inspired by retro gaming consoles, such as displaying only 16 colors and…
hickory-dns - Uses hickory-resolver as DNS resolver instead of tokio's builtin. local-http - Allow using…
Syscall tables are critical components of operating systems, mapping system calls to their respective kernel…
GitButler is a git client that lets you work on multiple branches at the same…
Self-spreading to other Minecraft servers using an extendable, module-based lateral movement system. Crafty Controller Auth'd…
ModTask is an advanced C# tool designed for red teaming operations, focusing on manipulating scheduled…