Nachfolgend präsentieren wir die Top-10 risikoreichsten Microsoft-Cloud-Sicherheitskonfigurationen, welche wir während zahlreichen Security Assessment festgestellt haben. Microsoft hat Active Directory (AD) mit den Windows 2000 Server-Editionen im Jahr 2000 als Nachfolger des Windows-NT-Directory eingeführt. Und wie sich einige von Ihnen erinnern, war IT-Sicherheit zu diesem Zeitpunkt nicht immer das wichtigste Thema. Dies führte vor allem zu unsicheren Konfigurationen, wie z. B. zahlreiche Zuweisungen von Benutzerkonten zu privilegierten Gruppen wie zu den Domain Admins.

Im Laufe der Jahre wurden jedoch schlechte AD-Sicherheitspraktiken reduziert, da es zum Standard wurde, dass AD besser geschützt werden muss. So wurde es beispielsweise zur gängigen Praxis, eine minimale Anzahl dedizierter Domain-Admin-Konten einzurichten, die nur innerhalb ihrer zulässigen Security-Boundary arbeiten dürfen. Warum erzählen wir Ihnen das? Weil es sich bei Cloud-Assessments manchmal so anfühlt, als ob man mit einer Zeitmaschine ins Jahr 2000 zurückreist, um dieselben Fehler zu sehen, die in dieser Zeit gemacht wurden.

Die Top-10 risikoreichsten Konfigurationen

Die folgende Top-10-Liste bringt Sie “zurück in die Zukunft”, indem diese grundlegende riskante Konfigurationen oder Praktiken beschreibt, die vermieden werden sollten. Ausserdem finden Sie eine Liste mit Links und Quellen für weiterführende Informationen. Die identifizierten Risiken basieren auf unseren Erfahrungen aus verschiedenen Microsoft Cloud Assessments.

Risk 1 – Reguläre Benutzerkonten, welche der globalen Administratoren-Rolle zugewiesen sind

Vergleicht man alle unsere Microsoft Cloud-Assessment der letzten Jahre, so hatten 8 von 10 ein oder mehrere reguläre Benutzerkonten, die permanent an Tier-0 Rollen in Azure AD zugewiesen waren. Tier-0-Rollen in der Cloud können als alle Rollen oder Entitäten interpretiert werden, die direkt oder indirekt zu Global Adminstrators werden können, wie zum Beispiel Mitglieder der Privilege Role Administrators oder Identitäten mit der AppRole RoleManagement.ReadWrite.Directory. Bei den entdeckten regulären Benutzerkonten handelte es sich hauptsächlich um Hybrid Identities, die aus dem Active Directory synchronisiert wurden. Der Grund für die Zuordnung war oft Bequemlichkeit, Unwissenheit oder die Angst, aus dem Azure AD ausgesperrt zu werden. Überraschenderweise versuchen die Unternehmen üblicherweise, dem Active Directory-Least-Privilege-Konzept zu folgen, indem sie beispielsweise ein dediziertes Konto verwenden oder sogar das Microsoft-Tiering-Modell zur Verwaltung Ihres Active Directory’s anwenden. Für die Microsoft-Cloud wurde dieses Prinzip jedoch nicht mehr angewandt.

Die Verwendung regulärer Benutzerkonten für die Verwaltung von Tier-0 vergrössert die Angriffsfläche unnötig und kann zu einer Kompromittierung des Microsoft-Cloud-Tenants führen. Angreifer werden versuchen, die Sicherheitsausnahmen zu missbrauchen, die meist für reguläre Benutzerkonten gelten, z. B. unlimitierter Internetzugang, Passwortrücksetzfunktionen, Social Engineering, laxe Härtungsmassnahmen, MFA-Fatigue Attack und weitere. Daher empfehlen wir, sich an das Least Privilege Modell zu halten, indem Sie dedizierte Cloud-only-Benutzerkonten für die Verwaltung der Microsoft Cloud verwenden. Die Tier-0 Cloud-Only-Benutzerkonten müssen Teil eines Joiner-Mover-Leaver (JML)-Prozesses sein. Ein manueller JML-Prozess, z. B. in Form eines Tickets, reicht aus, um zu vermeiden, dass ein IAM-System zu Tier-0 hochgestuft werden muss, da die Anzahl der Tier-0-Benutzerkonten gering gehalten werden sollte. Das Argument, dass Hybrid Identities bereits in den JML-Prozess einbezogen sind, ist nicht immer stichhaltig. Es kann zu dem oben beschriebenen Szenario führen, bei welchem reguläre Benutzerkonten Tier-0 Entitäten zugewiesen werden, da Active Directory Tier-0-Benutzer meist nicht in die Cloud synchronisiert werden. Angenommen, Azure AD Hybrid Identities müssen zwingend aus einem Grund für Tier-0 Cloud Berechtigungen verwendet werden. In diesem Fall empfehlen wir, ein dediziertes Active Directory-Identitätsmuster für die Hybrid Idenities zu erstellen und dieses wiederum in einen JML-Prozess einzubinden. Auf diese Weise können für diese Hybrid Identities restriktive Zugriffsrichtlinien im AD und in der Cloud festgelegt werden. Zusätzlich empfehlen wir die Verwendung von der Microsoft Cloud Lösung Privilege Identity Management (PIM) für privilegierte Konten. Um die Rolle zu aktivieren, sollte Multifaktor-Authentifizierung (MFA) verwendet werden.

Weitere Informationen:

• Introduction to delegated administration and isolated environments
• Securing privileged access for hybrid and cloud deployments in Azure AD
• Privilege Identity Management
• Securing privileged access
• Azure Attack Paths: Azure AD Roles
• MITRE ATT&CK tectics and rechniques
• AAD & M365 kill chain
• @_wald0 Tier-0 definition examples

Risk 2 – Schwaches Azure AD Service Principal und Cloud Application Management

Service Principals repräsentieren die Identität einer Microsoft Cloud Application. Ein neu angelegter Azure AD-Tenant mit entsprechenden Lizenzen hat etwa 390 vorkonfigurierte Service Principals, welche die Cloud-Application wie Microsoft Teams, SharePoint Online, Exchange Online oder Microsoft Graph repräsentieren. Wenn beispielsweise eine benutzerdefinierte Microsoft-Cloud-Anwendung im Azure AD-Portal oder über die API erstellt wird, werden zwei Entitäten erstellt. Eine Application und ein Service Principal. Die Application Objekt ist die globale Repräsentation der Unternehmens-Applikation für alle Tenants, während der Service Principal die lokale Repräsentation eines bestimmten Tenants ist. Service Principals oder Managed Identities in Azure ARM werden auch für die IaaS- und PaaS-Dienste von Azure genutzt, um beispielsweise für neue Dienste, bestehende Dienste oder allgemein für Automatisierungsaufgaben. Die Kompromittierung von Service Principals ist ein interessantes Ziel für Angreifer. Service Principals können mit einer Vielzahl von Berechtigungen ausgestattet werden und sind ideal für Privilege Escalation Szenarios oder Backdooring von Azure AD oder Azure ARM.

Cloud-Application werden durch die Zusammenstellung verschiedener IaaS- und PaaS-Services erstellt. Ein Application in der Microsoft Cloud ist in der Regel ein Service Principal zugewiesen. Wenn eine Application beispielsweise Zugriff auf eine Datenbank benötigt, wird dem Service Principal der Anwendung der Zugriff auf die Datenbank gewährt. Anwendungsnutzer greifen in der Regel über OAuth 2.0 Authorisation Flows auf Cloud-Applications zu. Die Erteilung von Berechtigungen für Applications kann kritisch werden, da einige Applications hoch privilegierte Zugriffsrechte haben können.

Häufig bei unseren Assessments finden wir privilegierte Service Principals oder Cloud-Application mit einem alltäglichen Benutzerkonto als Owner. Ein Owner kann den Service Principal verwalten oder sich als solcher ausgeben. Wenn also ein Benutzer eine Anwendung mit höheren Privilegien als der Benutzer selbst steuern kann, ist eine Privilege Escalation über den Service Principal möglich. Neben der Ownership stellen wir auch häufig fest, dass zugewiesene Berechtigungen nicht aktiv überwacht werden. Häufig finden wir über privilegierte Service Principals mit Anwendungsrollenrechten wie *.ReadWrite.All, *.ReadWrite.Directory oder direkte Zuweisungen zu den Rollen Global Administrator oder Exchange Administrator. Die Überprüfung, wer Applications verwalten kann, einschliesslich Applications- und Delegationsberechtigungen, ist in einer Microsoft-Cloud-Umgebung von entscheidender Bedeutung, um unerwünschte Credential-Pivoting-Pfade zu verhindern. Beispielsweise sollte der Besitzer von privilegierten Service Principals oder Applications niemals ein reguläres Benutzerkonto sein.

Weiterführende Informationen:

• Azure Privilege Escalation via Azure API Permissions Abuse
• Azure Privilege Escalation via Service Principal Abuse
• Managed Identity Attack Paths, Part 1-3: Automation Accounts
• Azure AD built-in roles

Risk 3 – Zu viele Administratoren

Allzu oft ist ein Ergebnis eines Microsoft Cloud Assessment, dass der Microsoft Cloud Tenant zu viele Administratoren hat. Sei es in Azure AD, Azure ARM, Azure DevOps oder M365. Die Gründe dafür sind vielfältig, aber einer der Gründe für diese Praxis ist meistens, dass verschiedene IT-Teams mit unabhängigen Projekten und engen Zeitplänen die Microsoft Cloud administrieren. Das Ergebnis sind viele Administratoren, die beispielsweise Conditional Access, Azure AD-Berechtigungen, Service Principals, Azure ARM-Ressourcen und so weiter konfigurieren müssen. Silos sollten in der Cloud keinen Platz haben, da alles viel stärker miteinander verbunden ist als bei On-Premises IT Lösungen. Fehlkonfigurationen können schwerwiegende Folgen haben. Daher ist es wichtig, einen Plan zu haben, um zu vermeiden, dass projektbezogene Benutzerkonten zufälligen Rollen zugewiesen werden, ohne die Auswirkungen der Berechtigungen oder die daraus resultierenden Zugriffsrechte zu verstehen. Ähnlich wie bei Active Directory sollte die Anzahl der Administratoren auf ein Minimum beschränkt werden.

Weiterführende Informationen:

• Least privileged roles by task in Azure Active Directory
• Understand roles in Azure Active Directory
• Classic subscription administrator roles, Azure roles, and Azure AD roles
• Microsoft cloud Adoption Framework for Azure

Risk 4 – Riskante Ausnahmen für Global Administrators oder andere privilegierte Rollen

Wir haben in jedem Microsoft-Cloud-Assessment Ausnahmen gefunden, insbesondere für Global Administrator in Conditional Access Regeln. Leider ist die Begründung allzu oft die Umgehung von Sicherheitskontrollen oder ein Shortcut, um Zeit zu sparen. Insbesondere für privilegierte Rollen wie Global Administrator sollten keine Ausnahmen gemacht werden, mit einer Ausnahme: Breakglass-Konten.

Manchmal werden für reguläre Benutzerkonten Ausnahmen benötigt. In diesem Fall empfehlen wir die Verwendung der Microsoft Cloud-Funktion Access Review, sobald eine Ausnahme erforderlich ist. Zugriffsüberprüfungen können für eine bestimmte Azure AD-Gruppe festgelegt werden, die beispielsweise eine monatliche Überprüfung aller Gruppenmitglieder, die Teil der Ausnahme sind, erzwingt. Das Ziel sollte sein, die Ausnahme in naher Zukunft durch eine sicherere Lösung zu ersetzen.

Weiterführende Informationen:

• Plan an Azure Active Directory access reviews deployment
• Common Conditional Access policies
• The Attackers Guide to Azure AD Conditional Access
• Manage emergency access accounts in Azure AD

Risk 5 – Fehlende Management-Einschränkungen für privilegierte Rollen

Die sichere Cloud-Verwaltung wurde häufig in unseren Assessments als nicht vorhanden eingestuft. Wir kamen häufig zum Schluss, dass die Anmeldung mit dem Global Administrator oder anderen privilegierten Rollen von jedem Gerät aus möglich war. So wurde beispielsweise nur das M365-Portal durch Conditional Access eingeschränkt, nicht aber das Azure AD Portal oder der alte Azure AD Graph Explorer. Warum? Weil häufig das Projektteam Conditional Access einrichtete z.B. nur für M365, nicht aber für Azure ARM zuständig war (Silo-Mentalität, welche vermieden werden sollte). In der Vergangenheit gab es nur wenige Möglichkeiten, der Management Zugriff auf die Microsoft Cloud zu beschränken. Wir empfahlen meistens, die Verwaltung nur von einem bestimmten Unternehmens-Admin-Proxy mit einer dedizierten öffentlichen IP-Adresse aus zuzulassen. Heutzutage lässt sich mit Conditional Access jedoch festlegen, auf welchem Gerät sich ein Benutzer mit einer bestimmten Rolle anmelden darf. Daher empfehlen wir dringend Privileged Access Workstations (PAW) in Kombination mit Conditional Access zu verwenden, zumindest für Tier-0-Administratoren.

Weiterführende Informationen:

• Securing devices as part of the privileged access story
• Conditional Access: Filter for devices
• Abusing Azure AD SSO with the Primary Refresh Token
• Death from Above: Lateral Movement from Azure to On-Prem AD

Risk 6 – Wissenslücken

Bei Assessments stellen wir oft fest, dass das zuständige IT-Personal Wissenslücken in Bezug auf die Funktionsweise der Microsoft Cloud hat. Das geht Hand in Hand mit der Silo-Mentalität, die unserer Meinung nach in einem Cloud-Setup nicht förderlich ist. Ein häufig missverstandenes Beispiel sind die verschiedenen Rollentypen in der Microsoft-Cloud. Zusammengefasst kennt die Microsoft-Cloud-Architektur vier Hauptorte, an denen Rollen zu finden sind. Der erste Ort ist der Azure Resource Manager (ARM), der IaaS- und PaaS-Workloads hostet. Die Rollen an diesem Ort werden als Azure RBAC-Rollen bezeichnet und gewähren Zugriff auf verschiedene Dienste wie Virtual Machines, Storage Accounts, Key Vaults und mehr. Der zweite Standort ist Azure AD. Azure AD verwaltet übergeordnete Rollen, welche direkten und indirekten Zugriff auf ARM- und SaaS-Anwendungen haben. Die mächtigste Rolle in der Microsoft-Cloud, der Global Administrator, ist hier zu finden. Diese Rolle kann alle Entitäten in einem Tenant kontrollieren. Die meisten Rollen in Azure AD haben den Zweck, M365 zu verwalten. Der dritte Standort sind Rollen innerhalb von Cloud-Anwendungen. Als Beispiel in Cloud Applications wie Microsoft Graph, Exchange Online, Defender for Endpoint oder Azure DevOps. In solchen Rollen können manchmal Azure AD-Rollen, Gruppen, Service Principals oder Benutzer als Mitglieder gefunden werden. Der letzte Ort ist das Azure EA-Portal, in dem die Subscriptions für ARM verwaltet werden, wenn Ihr Unternehmen eine Enterprise Agreement hat. Der Enterprise Administrator und der Account Owner im EA-Portal haben vollen indirekten Zugriff auf alle Subscriptions, welche vom EA-Portal verwaltet werden. Die Rollen in Cloud Applications und des EA-Portals werden oft übersehen und fehlen daher in den Prozessen vom Identity & Access Management (IAM). Angreifer können solche Rollen nutzen, um unbemerkt zu bleiben, und können so weitreichenden Zugang zu verschiedenen Cloud-Diensten erhalten. Wir empfehlen daher, solche Rollen in die IAM-Prozesse aufzunehmen. Für das EA-Portal sollten nur dedizierte Microsoft Cloud Work Accounts verwendet werden, und es sollte sichergestellt werden, dass ähnliche organisatorische und sicherheitstechnische Massnahmen wie bei anderen privilegierten Konten, z. B. Global Administrators, angewendet werden.

Weiterführende Informationen:

• Microsoft Security Best Practices
• Enterprise billing and Azure AD tenants
• Security considerations of Azure EA management and potential privilege escalation

Risk 7 – AAD Connect Missverständnisse

AAD Connect ist eine lokale Lösung, die Identitäten aus Active Directory mit der Microsoft Cloud synchronisieren kann. Die synchronisierten Objekte in der Cloud werden als Hybrid Identity bezeichnet. Der JML-Prozess, der bereits in der bestehenden lokalen IAM-Lösung implementiert ist, ist somit angeblich gewährleistet. Leider ist dies nicht wirklich der Fall, da AAD Connect nicht alle Cloud-Entitäten wie Cloud-Only-Benutzer, Gastkonten und Service Principals verwalten kann. Diese Entitäten werden meist vergessen und erfordern ebenfalls einen JML-Prozess. Daher sollte ein Konnektor, vorzugsweise über die Microsoft Graph API, eingerichtet werden, um nicht synchronisierte Entitäten abzudecken. Ausserdem muss die AAD Connect-Lösung als Tier-0-Lösung behandelt und sollte daher nur von Tier-0-Administratoren des Active Directory verwaltet werden.

Weiterführende Informationen:

• Unnoticed sidekick: Getting access to cloud as an on-prem admin
• Azure AD Connect for Red Teamers
• Azure Active Directory Pass-Through Authentication Flaws

Risk 8 – DevOps Lösungen und ihre versteckten Risiken

Im Artikel Attack Path Analysis – Vorteil gegenüber Angreifern verschaffen haben wir einen möglichen Attack Path beschrieben, welcher ein reguläres Benutzerkonto in Azure DevOps missbraucht, um Zugriff auf einen privilegierten Service Principal zu erhalten. Um solche Attack Paths zu verringern, empfehlen wir sicherzustellen, dass ähnliche organisatorische und sicherheitstechnische Massnahmen wie bei anderen privilegierten Konten, z. B. Global Administrators, angewendet werden. Überdies sollte die verwendete DevOps-Lösung gemäss den verfügbaren Sicherheitsempfehlungen gehärtet werden.

Weiterführende Informationen:

• Attack Path Analysis – Vorteil gegenüber Angreifern verschaffen
• Security groups, service accounts, and permissions in Azure DevOps
• Security best practices
• Azure DevOps: Recommended Practices for Secure Pipelines
• Microsoft Security Code Analysis
• Development security strategy

Risk 9 – Fehlende Anwedungen vom Clean Source Principal

“Beim Clean Source Principle müssen alle Sicherheitsabhängigkeiten genauso vertrauenswürdig sein wie das zu sichernde Objekt.” (Microsoft – Clean source principle). In On-Premises-Umgebungen und erst recht in der Cloud wird dieses grundlegende Prinzip oft vergessen/ignoriert. Eine häufig vorgebrachte Begründung bei unseren Assessments lautet: “Unser Microsoft Cloud Tenant ist noch nicht produktiv”, was offensichtlich gegen das eben genannte Prinzip verstösst. Ein Azure AD Tenant ist unserer Meinung nach produktiv, sobald der Azure AD Tenant auf der Microsoft Website angefordert wird. Daher sollten die Prinzipien wie Least Privilege und Clean Source von Anfang an beachtet werden. Wer kann sonst garantieren, dass der Tenant nicht während des Einrichtungsprozesses oder der Pilotphase kompromittiert wurde?

Weiterführende Informationen:

• Clean source principle

Risk 10 – Fehlende Cloud-Verteidiger/Angreifer Denkweise

Die alte Sicherheitsarchitektur vor dem Cloud Computing ähnelt der Struktur einer mittelalterlichen Burg. Alles befand sich in einem vertrauenswürdigen internen Netz, und alle Sicherheitskonfigurationen waren um den Burgrand herum angeordnet. Mit Cloud Computing ist diese Architektur mehr und mehr obsolet geworden. Ausserdem ist das Konzept der Perimetersicherheit nicht praktikabel, wenn die Dienste auf einer gemeinsam genutzten, mit dem Internet verbundenen Infrastruktur laufen. Um diese neuen Herausforderungen zu bewältigen, sind innovative Modelle für die Sicherheitsarchitektur und eine Änderung der Denkweise erforderlich. Ein Beispiel für eine fragwürdige Denkweise ist, wenn die Begründung für eine Sicherheitsfeststellung lautet: “Aber Microsoft kümmert sich schon darum”. Leider ist mit einer solchen Denkweise die Wahrscheinlichkeit einer Kompromittierung hoch. Vereinfacht ausgedrückt bedeutet die Kultivierung der Denkweise eines Verteidigers, dass man versteht, wer für was in einer Cloud-Umgebung verantwortlich ist. Laut Microsoft sind “Cloud-Dienste eine geteilte Verantwortung”. Aus der Sicht von Microsoft bedeutet “gemeinsam”, dass Microsoft die Plattform und die Tools zur Verfügung stellen, die Konfiguration, Überwachung und Sicherung des Tenants obliegt, aber Ihnen. Daher ist es von entscheidender Bedeutung, ein umfassendes Verständnis dafür zu haben, wie ein Microsoft Cloud Tenant gesichert, überwacht und verwaltet werden muss. Regelmässige Konfigurationsüberprüfungen und -anpassungen mit der Unterstützung von Microsoft-Sicherheitstools wie Microsoft Secure Score, Defender for Cloud Recommendations, Azure Monitor Workbooks und anderen werden empfohlen. Auch die Verwendung von Assessmenttools von Drittanbietern wie AzureHound, ROADtools, AzureADAssessment oder AAD Internals, um nur einige zu nennen, kann bei einem Assessment der Sicherheitslage eines Azure AD Tenant von Nutzen sein.

Weiterführende Informationen:

• Shared responsibility in the cloud
• Attack Path Analysis – Vorteil gegenüber Angreifern verschaffen
• Introducing the Adversary Resilience Methodology
• Defender’s Mindset

Assessment Tools:

Der Grundsatz des Clean Source Principal sollte beachtet werden. Verwendete Tools sollten zuerst überprüft und möglichst mit den geringsten benötigten Privilegien verwendet werden.

• AzureHound
• BloodHound Enterprise
• ROADtools
• Azure Stormspotter
• Azure AD Exporter
• Azure Review Checklists
• Azure Threat Research Matrix
• Azure ARM Governance Visualizer
• Azure Tenant Security Solution
• MicroBurst: A PowerShell Toolkit for Attacking Azure
• BloodHound Attack Research Kit
• Microsoft Azure AD Assessment
• AAD Internals

Fazit

Die präsentierten Top-Ten-Risiken sind nicht als abschliessend zu betrachten, da die Liste um weitere risikoreiche Aspekte ergänzt werden könnte, z. B. fehlende Sicherheitsüberwachung, Unkenntnis über Credential Pivoting und Extraktion von Access- oder Refresh-Tokens aus Browser-Sitzungen. Nichtsdestotrotz wollten wir Ihr Bewusstsein für bewährte Sicherheitspraktiken schärfen, denn in der Cloud ist die Einhaltung dieser Praktiken noch wichtiger als im On-Premises Umfeld. Die Befolgung von Sicherheitsstandards ist ein guter Ratschlag für den Betrieb von Cloud-Plattformen, da diese ohne Härtungsmassnahmen und kontinuierliche Sicherheitsanpassungen standardmässig nicht sicher sind. Alles in allem unterscheiden sich die Grundlagen der Sicherung einer Cloud-Umgebung nicht wesentlich von der Sicherung einer On-Premises Umgebung. Daher ist es wichtig, die Fehler der Vergangenheit nicht zu wiederholen und in ein solides Fundament zu investieren, bevor die umfangreichen und lukrativen Möglichkeiten einer Cloud-Plattform genutzt werden.

Über den Autor

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://attack.mitre.org/matrices/enterprise/cloud
• https://blog.xpnsec.com/azuread-connect-for-redteam/
• https://bloodhoundenterprise.io/
• https://cloudbrothers.info/en/azure-attack-paths
• https://danielchronlund.com/2022/01/07/the-attackers-guide-to-azure-ad-conditional-access
• https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token
• https://github.com/Azure/Stormspotter
• https://github.com/Azure/review-checklists
• https://github.com/AzureAD/AzureADAssessment
• https://github.com/BloodHoundAD/AzureHound
• https://github.com/BloodHoundAD/BARK
• https://github.com/JulianHayward/Azure-MG-Sub-Governance-Reporting
• https://github.com/NetSPI/MicroBurst
• https://github.com/azsk/AzTS-docs
• https://github.com/dirkjanm/ROADtools
• https://github.com/microsoft/azureadexporter
• https://github.com/mpeder/azdevopssecurity
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-condition-filters-for-devices
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-policy-common
• https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/secure-with-azure-ad-introduction
• https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/secure-with-azure-ad-resource-management#enterprise-billing-and-azure-ad-tenants
• https://learn.microsoft.com/en-us/azure/active-directory/governance/deploy-access-reviews
• https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
• https://learn.microsoft.com/en-us/azure/active-directory/roles/concept-understand-roles
• https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task
• https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference
• https://learn.microsoft.com/en-us/azure/active-directory/roles/security-emergency-access
• https://learn.microsoft.com/en-us/azure/active-directory/roles/security-planning
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/development-security-strategy-overview
• https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops&tabs=preview-page
• https://learn.microsoft.com/en-us/azure/devops/organizations/security/security-best-practices?view=azure-devops
• https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles
• https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• https://learn.microsoft.com/en-us/security/compass/compass
• https://learn.microsoft.com/en-us/security/compass/overview
• https://learn.microsoft.com/en-us/security/compass/privileged-access-devices
• https://learn.microsoft.com/en-us/security/compass/privileged-access-success-criteria#clean-source-principle
• https://medium.com/@johnlatwc/defenders-mindset-319854d10aaa
• https://microsoft.github.io/Azure-Threat-Research-Matrix/?s=09
• https://o365blog.com/aadinternals/
• https://o365blog.com/aadkillchain
• https://o365blog.com/post/on-prem_admin
• https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48
• https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
• https://posts.specterops.io/death-from-above-lateral-movement-from-azure-to-on-prem-ad-d18cb3959d4d
• https://posts.specterops.io/introducing-the-adversary-resilience-methodology-part-one-e38e06ffd604
• https://posts.specterops.io/managed-identity-attack-paths-part-1-automation-accounts-82667d17187a
• https://secdevtools.azurewebsites.net
• https://twitter.com/_wald0/status/1569831939569324034
• https://www.cloud-architekt.net/azure-ea-management-security-considerations/
• https://www.secureworks.com/research/azure-active-directory-pass-through-authentication-flaws