Diese Veröffentlichung ist eine Sammlung verschiedener häufiger Angriffsszenarien auf Microsoft Entra ID (ehemals Azure Active Directory) und erläutert, wie diese entschärft oder erkannt werden können.
Diese Veröffentlichung ist eine Sammlung verschiedener häufiger Angriffsszenarien auf Microsoft Entra und wie diese entschärft oder erkannt werden können. Alle enthaltenen Szenarien, Erkenntnisse und Kommentare basieren auf Erfahrungen der Mitwirkenden während ihrer Angriffssimulationen, praktischen Übungen oder realen Szenarien.
Es sollte als lebendes Dokument betrachtet werden, das aktualisiert wird, sobald sich Praktiken weiterentwickeln und sich Änderungen bei Angriffs- und Verteidigungstechniken ergeben. Wir laden Identitäts- oder Sicherheitsexperten aus der Community ein, gemeinsam an dieser Veröffentlichung zu arbeiten und Aktualisierungen, Feedback, Kommentare oder weitere Ergänzungen beizutragen.
In allen Kapiteln folgen wir derselben Leitlinie für die Kapitelstruktur. Beim Lesen können Sie Folgendes erwarten:
Die folgenden Abschnitte enthalten eine kurze Beschreibung jedes Kapitels, das Sie im „Entra ID Attack & Defense Playbook“ finden.
Die ursprüngliche Idee für das „Azure AD Attack & Defense Playbook“ stammt von Thomas Naunheim. Unser erster Teams-Anruf fand irgendwann im Herbst 2020 statt, als Thomas die Idee vorstellte – und sie war sofort verkauft.
Das erste Kapitel drehte sich um den Angriff „Password Spray“, wobei wir uns stark auf den Erkennungsmechanismus von Entra ID Protection (ehemals Azure AD Identity Protection) konzentrierten, um Angriffe vom Typ „Password Spray“ zu erkennen. Während des ersten Kapitels lernten wir, dass die Kalenderzeit für den Abschluss der Recherche erheblich länger dauern kann als erwartet, aufgrund der Komplexität der Forschung und der unterschiedlichen Blickwinkel. Die Eingrenzung des Umfangs ist, wie bei jeder Projektarbeit, äußerst wichtig.
Bei den neuesten Kapiteln hatten wir das Glück, weitere Community-Mitglieder in das Projekt einzubinden, wie Joosua Santasalo, Fabian Bader und Christopher Brumm, die als Sparringspartner und Reviewer mitwirkten.
MITRE ATT&CK Framework wird häufig verwendet, um Taktiken, Techniken & Verfahren (TTPs) für Angreiferaktionen abzubilden und Verteidigungsmaßnahmen für Organisationen weltweit zu emulieren. In diesem Playbook nutzen wir in allen Kapiteln das MITRE ATT&CK-Framework v11, um Techniken, Taktiken & Verfahren (TTPs) den Angriffsszenarien zuzuordnen. Dies hilft Blue Teams, Verteidigungsmaßnahmen für die entsprechenden Szenarien aufzubauen.
In den einzelnen Kapiteln finden Sie mehrere Erkennungsregeln, die auf dem jeweiligen Angriffsszenario basieren. Da das Playbook eine große Anzahl an Erkennungsregeln enthält, haben wir uns entschieden, eine Visualisierung zu erstellen, die alle Angriffsszenarien enthält, die TTPs zugeordnet sind. Beachten Sie auch, dass jedes Kapitel eine Visualisierung für das entsprechende Angriffsszenario enthält.
In MITRE ATT&CK Navigator öffnen
Die zugehörigen Erkennungsfunktionen der Microsoft-Sicherheitsprodukte (Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect, Microsoft Defender for Cloud) werden im Erkennungsteil der Angriffsszenarien behandelt. Benutzerdefinierte Regelschablonen für Microsoft Sentinel, die für das Playbook entwickelt wurden, sind ebenfalls den TTPs zugeordnet. Die Erkennungsregeln sind als Microsoft Sentinel-Regelschablone (bereitstellungsfertig) im JSON-Format (ARM-Vorlage) hier verfügbar.
In MITRE ATT&CK Navigator öffnen
Randnotiz: Wir haben die vorhandene TTP-Zuordnung aus den Microsoft Sentinel-Regelschablonen und der Microsoft 365-Vorfallkorrelation verwendet. Einige Erkennungen bieten keine vollständige MITRE ATT&CK-Abdeckung und sind in dieser Visualisierung nicht enthalten.
Normalerweise hat ein Kapitel etwa 1-2 Monate Kalenderzeit in Anspruch genommen, sodass es eine erhebliche Anstrengung war, alle vier (4) Kapitel und den Anhang zusammenzustellen. In den letzten zwei (2) Jahren haben wir zu den folgenden Szenarien geforscht:
„Bei einem Password-Spray-Angriff werden mehrere Benutzernamen mit gängigen Passwörtern in einer einheitlichen Brute-Force-Methode angegriffen, um unbefugten Zugriff zu erlangen.“
Das Kapitel wurde ursprünglich im November 2020 erstellt und im November 2021 aktualisiert, um die neuesten Sicherheitsprodukt-Updates der Microsoft Ignite 2021 zu enthalten.
Das Kapitel enthält eine kurze Beschreibung des Angriffs und der Werkzeuge, die zur Simulation von Password-Spray-Angriffen verwendet werden. Im Erkennungsteil werden mehrere Microsoft-Sicherheitslösungen wie Microsoft Sentinel & Defender for Cloud Apps verwendet.
In den Randnotizen finden sich außerdem Überlegungen zur On-Premises-Umgebung und zu ADFS, falls diese noch verwendet werden.
„Bei einem unerlaubten Consent-Grant-Angriff erstellt der Angreifer eine in Azure registrierte Anwendung, die Zugriff auf Daten wie Kontaktinformationen, E-Mails oder Dokumente anfordert. Der Angreifer bringt dann einen Endbenutzer dazu, dieser Anwendung die Zustimmung zum Zugriff auf seine Daten zu erteilen – entweder durch einen Phishing-Angriff oder durch das Einschleusen von unerlaubtem Code in eine vertrauenswürdige Website. Nachdem der unerlaubten Anwendung die Zustimmung erteilt wurde, hat sie ohne ein Organisationskonto Zugriff auf Daten auf Kontenebene.
Normale Abhilfemaßnahmen wie das Zurücksetzen von Passwörtern für kompromittierte Konten oder die Anforderung von Multi-Faktor-Authentifizierung (MFA) für Konten sind gegen diese Art von Angriff nicht wirksam, da es sich um Drittanbieteranwendungen handelt, die außerhalb der Organisation liegen. Diese Angriffe nutzen ein Interaktionsmodell, das davon ausgeht, dass die Entität, die die Informationen abruft, Automatisierung ist und kein Mensch.“
Das Kapitel enthält eine Angriffsbeschreibung und eine Erklärung, warum es wichtig ist, Aktivitäten rund um das Entra-ID-Consent-Framework zu sichern und zu überwachen. Im Erkennungskapitel haben wir die folgenden Lösungen verwendet:
Da das Thema umfangreich und komplex ist, enthält der Teil zur Entschärfung Anweisungen und Details, wie Sie die Angriffsfläche in Ihrer Umgebung reduzieren können.
In den folgenden beiden Angriffsszenarien haben wir unseren Fokus auf privilegierte Dienstprinzipale als Teil von Release-Pipelines in Azure DevOps (ADO) und die (potenziell) eingeschränkte Sichtbarkeit bei der Prüfung gelegt.
ADO ist ein großes Thema, und in diesem Kapitel beschränkt sich der Umfang nur auf die oben genannten Szenarien. Dabei wird der gleiche Weg verfolgt:
Als wir an diesem Kapitel arbeiteten, verbrachten wir viel Zeit mit den Erkennungstechniken, was vor allem aufgrund des ADO-Überwachungsprotokoll-Schemas kompliziert war. Dennoch zahlt sich harte Arbeit aus, und wir konnten unser definiertes Ziel erreichen und Angriffe in Microsoft Sentinel erkennen.
Das Kapitel enthält im Kapitel zur Entschärfung ausführliche Informationen zur Absicherung der Azure DevOps-Umgebung.
In diesem Beitrag konzentrieren wir uns hauptsächlich auf das folgende Szenario:
Nicht im Umfang enthalten sind Privilegienerweiterung und Angriffspfade vom AADC-Server in Richtung Active Directory (einschließlich Missbrauch des Azure AD DS-Connector-Kontos).
Das neueste Kapitel, veröffentlicht am 14. März 2022, dreht sich ganz um den Missbrauch des Microsoft Entra Connect-Synchronisierungsdienstkontos. Genauer gesagt ist das AAD Connect-Konto für die Durchführung von Aktionen auf der Azure-AD-Seite verantwortlich.
Das Thema und das Angriffsszenario waren für die Forschungsarbeit äußerst interessant, und obwohl ich in der Vergangenheit viel mit Microsoft Entra Connect gearbeitet habe, muss ich zugeben, dass ich in den letzten zwei (2) Monaten viel gelernt habe. Wir haben einige interessante Erkenntnisse gewonnen, die uns vorher nicht aufgefallen sind.
Wenn Sie so weit gelesen haben, empfehle ich Ihnen, sich die KQL-Abfragen für Microsoft Sentinel anzusehen, die wir während unserer Forschungsarbeit erstellt haben.
Microsoft hat Windows 11 mit der Anforderung eingeführt, einen Trusted Platform Module (TPM)-Chip zu verwenden. Dies hat die Möglichkeiten zur Nutzung der Sicherheitsfunktionen von Windows 11 erheblich erweitert, einschließlich einer zusätzlichen Schutzschicht für cloudbasierte Authentifizierungsszenarien. Das Primary Refresh Token (PRT) und andere relevante Schlüssel können durch TPM unter Windows 11, aber auch unter Windows 10 und Windows-Server-Versionen ab 2016 gut geschützt werden. Unter Berücksichtigung dieser Aspekte konzentrieren wir uns in diesem Beitrag hauptsächlich auf die folgenden Szenarien:
Der Zweck des Entra ID Security Config Analyzer besteht darin, eine Lösung bereitzustellen, die die Sicherheitskonfiguration von Entra ID von den ausgewählten Microsoft Graph-API-Endpunkten abruft und die Daten in Log Analytics aufnimmt. Azure Workbook wird zur Datenvisualisierung verwendet, und Microsoft Sentinel kann verwendet werden, um Warnungen/Vorfälle zu erstellen, wenn eine kritische Konfigurationsänderung erkannt wird.
Das folgende Bild beschreibt die EIDSCA-Lösungsarchitektur, die verwendete Lösung und die Datenflüsse:
Referenzarchitektur zur Integration von EIDSCA in eine Microsoft Sentinel-Umgebung. Die Daten werden in denselben Workspace wie Sentinel aufgenommen. Es hängt von Ihrer Implementierung und Ihrem Design ab, ob Sie eine Integration in einen dedizierten, operativen oder bestehenden Sentinel-Workspace wünschen.
EIDSCA-Kontrollen werden auch in Maester verwendet. Weitere Informationen finden Sie in der Maester-Dokumentation.
Verschiedene Token spielen eine entscheidende Rolle bei der Cloud-Authentifizierung. Daher ist es wichtig, ihre Funktionsweise zu verstehen und zu verstehen, wie Angreifer sie ausnutzen können, wenn sie in falsche Hände geraten. Dieses Verständnis kann beim Aufbau von Schutzmaßnahmen gegen Identitätsangriffe helfen.
Token-Diebstahl tritt auf, wenn ein Angreifer Zugriff erhält und Token kompromittiert. Einmal gestohlen, kann der Angreifer die gestohlenen Token erneut abspielen und auf das kompromittierte Konto zugreifen. Im AiTM-Szenario kann der Angreifer die MFA-Anforderung umgehen, da die MFA-Ansprüche bereits im Token enthalten sind und die Authentifizierungsanforderungen erfüllt sind. Dadurch erlangt der Angreifer Zugriff auf die Umgebung. Wir werden das Szenario, die Erkennung und die Entschärfung später in diesem Beitrag erläutern.
Weitere Informationen zu Entra-ID-Sicherheitstoken finden Sie in den folgenden Microsoft-Learn-Ressourcen:
Das Kapitel „Replay of Primary Refresh (PRT) and other issued tokens from an Azure AD joined device“ des Entra ID Attack & Defense Playbooks beleuchtet das erneute Abspielen von PRT, Zugriffstoken & Aktualisierungstoken:
In diesem Kapitel konzentrieren wir uns auf Angriffe vom Typ Adversary-in-the-Middle (AiTM), bei denen der Angreifer das Sitzungscookie des Opfers abfängt und es später erneut abspielt, um auf den Anmeldedienst zuzugreifen.
Cyberkriminelle nutzen derzeit AiTM-Phishing-Techniken, um Multi-Faktor-Authentifizierungs-Schutzmaßnahmen (MFA) in großem Umfang zu umgehen. Diese fortschrittlichen Techniken werden durch das Cyberkriminalitäts-Geschäftsmodell Phishing-as-a-Service (PhaaS) demokratisiert und verbreitet, das seit 2021 mehrere Dienstleistungsangebote hervorgebracht hat.
Heutzutage wächst die Zahl der PhaaS-Plattformen mit AiTM-Fähigkeiten im Zeitraum 2023–2024 weiter, wobei bestehende Dienste ihren Plattformen AiTM-Fähigkeiten hinzufügen und neu geschaffene Dienste AiTM-Phishing-Techniken nativ integrieren. Während traditionelle Formen des Credential-Phishings weiterhin existieren, übersteigt die Zahl der AiTM-Phishing-Angriffe diejenigen ohne diese Fähigkeit.
Das ultimative Ziel von AiTM-Phishing ist es, Benutzeranmeldeinformationen und Sitzungscookies zu stehlen. Browser speichern Sitzungscookies, um Benutzern den Zugriff auf Dienste zu ermöglichen, ohne dass sie sich wiederholt authentifizieren müssen. AiTM-Phishing zielt auf Sitzungscookies und Anmeldeinformationen ab, um traditionelle MFA-Schutzmaßnahmen zu umgehen.
Weitere Informationen zu PhaaS:
Jeder moderne Webdienst implementiert nach erfolgreicher Authentifizierung eine Sitzung mit dem Benutzer, sodass dieser nicht jede neue Seite, die er besucht, erneut authentifizieren muss. Diese Sitzungsfunktion wird durch ein Sitzungscookie ermöglicht, das von einem Authentifizierungsdienst nach der ersten Authentifizierung ausgestellt wird. Das Sitzungscookie dient dem Webserver als Nachweis, dass der Benutzer authentifiziert wurde und eine aktive Sitzung auf der Website aufrechterhält.
Bei einem AiTM-Phishing-Angriff fängt ein Angreifer das Sitzungscookie des Zielbenutzers ab und spielt es später erneut ab, um auf den Anmeldedienst zuzugreifen. Da das Cookie nachweist, dass die MFA-Prüfung bereits bestanden wurde (im Token enthaltener Anspruch), erfüllt es die MFA-Anforderung, sodass der Angreifer die MFA-Schutzmaßnahmen umgehen und auf das kompromittierte Benutzerkonto zugreifen kann.
Beim AiTM-Phishing über einen Reverse-Proxy wird der Proxy zwischen einem Benutzer und der legitimen Website oder Anwendung platziert, die der Benutzer besuchen möchte (z. B. Microsoft-Anmeldeportale oder LinkedIn). Der Reverse-Proxy leitet die Anfragen des Benutzers an den tatsächlichen Dienst weiter und fängt die Antworten ab. Diese Art der Einrichtung ermöglicht es dem Angreifer, das Passwort des Ziels und das Sitzungscookie zu stehlen und abzufangen, das dessen laufende und authentifizierte Sitzung mit der Website nachweist.
Beliebte Phishing-Kits bei Angreifern sind: EvilGinx, Modlishka, Muraena und „Office 365“ (EvilProxy). Diese Phishing-Kits ermöglichen es Angreifern, AiTM-Phishing-Angriffe mithilfe von Reverse-Proxy-Servern durchzuführen.
Nebenbei bemerkt: In vielen Kampagnen war die Zielanwendung in den Entra-ID-Protokollen OfficeHome.
Diagramm des AiTM-Phishing-Angriffs über einen Reverse-Proxy (ursprüngliche Abbildung aus den Microsoft Defender XDR Threat Intelligence-Berichten).
Eine weitere AiTM-Methode wird als 'AiTM-Phishing über ein synchrones Relais' bezeichnet. Bei dieser Art von Angriff wird dem Ziel eine Kopie oder Nachbildung einer Anmeldeseite präsentiert, wie man es von traditionellen Phishing-Angriffen kennt. Gibt ein Benutzer seine Anmeldedaten auf dieser Seite ein, werden die Daten auf einem vom Angreifer kontrollierten Server gespeichert, auf dem die Phishing-Kit-Instanz einschließlich ihres Admin-Panels installiert ist. Im Grunde bedeutet das, dass die Eingaben des Benutzers gestohlen werden, einschließlich Anmeldedaten, Zwei-Faktor-Authentifizierungscodes (MFA) und Sitzungscookies.
Die Relais-Server werden in der Regel von der Akteursgruppe bereitgestellt und kontrolliert, die hinter der Entwicklung steht, sowie von den verantwortlichen Stakeholdern der PhaaS-Plattform. Ein Beispiel für eine solche Gruppe ist Storm-1295, die laut Microsoft Threat Intelligence-Berichten hinter der Greatness-PhaaS-Plattform steht.
Diagramm des AiTM-Phishings über ein synchrones Relais (ursprüngliche Abbildung aus den Microsoft Defender XDR Threat Intelligence-Berichten).
Aktualisierung oder neue Inhalte (Pull Request): Wie bereits erwähnt, möchten wir ein lebendiges Dokument haben, das von der Entra-Community getragen wird! Teilen Sie Ihre Ergebnisse und Erkenntnisse im Rahmen dieses Projekts! Senden Sie einen Pull-Request, um Ihre Inhalte zu diesem Projekt hinzuzufügen.
Issues/veraltete Inhalte: Schutzfunktionen oder Tools ändern sich ständig. Aktualisieren Sie die veralteten Inhalte (im Rahmen eines Pull-Requests) oder erstellen Sie ein Issue, um darauf hinzuweisen.
Reviewer: Wir suchen auch Experten, die die bestehenden oder neuen Inhalte vor der Veröffentlichung überprüfen oder diskutieren möchten!
Feedback: Zögern Sie nicht, Angriffs-/Verteidigungsszenarien vorzuschlagen, die für die Community interessant sein könnten. Wir werden sie in den Backlog und in die Ideensammlung aufnehmen!
Dies ist ein von der Community getragenes Projekt und keine offizielle Lösung und kein offizielles Produkt. Code oder ein anderes Abfragebeispiel wird "AS IT IS" ohne jegliche Gewährleistung bereitgestellt, weder ausdrücklich noch stillschweigend, einschließlich, aber nicht beschränkt auf die stillschweigenden Gewährleistungen der Marktgängigkeit und/oder Eignung für einen bestimmten Zweck. Dieses Beispiel wird von keinem Supportprogramm oder Supportdienst unterstützt. Wir lehnen ferner alle stillschweigenden Gewährleistungen ab, einschließlich, ohne Einschränkung, der stillschweigenden Gewährleistungen der Marktgängigkeit oder der Eignung für einen bestimmten Zweck. Das gesamte Risiko, das aus der Nutzung oder Leistung des Beispiels und der Dokumentation entsteht, verbleibt bei Ihnen. In keinem Fall haften wir, die Autoren oder sonstige an der Erstellung, Produktion oder Bereitstellung des Skripts beteiligte Personen für Schäden jeglicher Art (einschließlich, ohne Einschränkung, Schäden durch Verlust von Geschäftsgewinnen, Betriebsunterbrechung, Verlust von Geschäftsinformationen oder sonstige finanzielle Verluste), die aus der Nutzung oder der Unfähigkeit zur Nutzung des Beispiels oder der Dokumentation entstehen, selbst wenn Microsoft auf die Möglichkeit solcher Schäden hingewiesen wurde.
 Sami Lamppu 💬 📖 |  Thomas Naunheim 💬 📖 |
 Joosua Santasalo 💬 📖 |  Markus Pitkäranta 💬 📖 |  Christopher Brumm 💬 📖 |  Fabian Bader 💬 📖 |  Nestori Syynimaa 💬 📖 |  Robbe Van den Daele 💬 📖 |
