Umfassende und zeitnahe Aktivitätsprotokolle sind leistungsstarke Tools, die die Sicherheitsüberwachung und die Reaktion auf Vorfälle auf cloud ermöglichen. Bei der Untersuchung von Azure-Protokollen sind unseren Forschern jedoch viele Mängel aufgefallen, die das Verständnis von Benutzeraktionen erschweren und sogar einen Angreifer entkommen lassen könnten. In diesem Beitrag werden wir diese Probleme und ihre Auswirkungen auf die Arbeit des Blue-Teams diskutieren.
Warum wir Azure Monitor Logs untersuchen
Bevor wir auf anbieterspezifische Details eingehen, sollten wir beachten, dass Protokolle in cloud und in On-Premises-Umgebungen eine unterschiedliche Bedeutung haben.
Bei der Einrichtung vor Ort haben die Administratoren einige Möglichkeiten: Sie können den Netzwerkverkehr anzapfen, um Aktivitäten zu überwachen, oder Protokolle am Netzwerkrand und auf einzelnen Rechnern sammeln. Die Protokollierungs- und Überwachungslösungen (Hardware und Software) sind austauschbar, und wenn ein bestimmtes Herstellerprodukt nicht gut funktioniert, kann ein anderes installiert werden.
Bei cloud haben Sie diese Möglichkeiten nicht - der Anbieter kontrolliert die verfügbaren Protokolle vollständig. Wenn sie von hoher Qualität sind, großartig! Aber wenn es Probleme gibt, sind Sie der Bereitschaft des Anbieters ausgeliefert, diese zu beheben. Sie können sie entweder beim Anbieter ansprechen und auf eine Lösung hoffen oder versuchen, sie zu umgehen, sofern dies möglich ist.
Bei der Überwachung von Aktivitäten in der Umgebung von cloud gibt es mehrere Erwartungen:
- Keine unangekündigten Änderungen an Struktur oder Inhalt des Protokolls
- Zeitnahe Protokollierung von Ereignissen
- Vollständige und genaue Aufzeichnungen (ohne fehlende oder fehlerhafte Werte)
- Vollständige Dokumentation für protokollierte Ereignisse
- Eine einfache Möglichkeit, Ereignisse und Benutzersitzungen zwischen verschiedenen Protokollen zu korrelieren
- Ein Satz von Bedrohungsindikatoren für die Analyse von Vorfällen
Bei der Analyse von Aktivitäten müssen die folgenden Daten in allen Protokollquellen und für alle Ereignistypen konsistent verfügbar sein:
- Namen und Einzelheiten der Operation
- Benutzeridentität und Sitzungsinformationen
- IPs
- Geolokalisierung
- Informationen zum Gerät
- Indikatoren für Bedrohung und Reputation
Im Wesentlichen möchten Sie in der Lage sein, festzustellen, wer was und wann getan hat (und was er noch getan hat). Leider werden diese Erwartungen in Azure-Protokollen nicht immer erfüllt.
Wie wir Ereignisse in Azure überwachen
Azure verfügt über eine Reihe ausgereifter Produkte zur Ereignisanalyse und -überwachung:
Microsoft Sentinel ist ein natives SIEM-Produkt, das Protokolle aus verschiedenen Quellen aufnimmt. Es verfügt über eine Reihe integrierter Erkennungsfunktionen und ermöglicht es uns, eigene zu definieren.
Azure Log Analytics ist eine Plattform zur Protokollanalyse, die sich hervorragend für Ad-hoc-Untersuchungen verdächtiger Ereignisse eignet.
Beide unterstützen Kusto - eine leistungsstarke Sprache für die Abfrage und Analyse von Protokollen. Darüber hinaus können Sie Lösungen von Drittanbietern zur Überwachung und Interpretation der Protokolle verwenden.
Die Azure-Protokollierungsinfrastruktur ist riesig und verfügt über Dutzende, wenn nicht Hunderte von Protokollquellen. Es wäre unmöglich, sie alle zu besprechen. Konzentrieren wir uns daher auf Protokolle, die von Azure AD (jetzt Entra ID), der IAM-Lösung von Azure, und Microsoft 365, einer cloud SaaS-Bürosuite, generiert werden.
Abdeckung der Entra ID-Protokolle:
- Sign-ins - verschiedene Protokolle, die die Sign-In-Aktivität von interaktiven und nicht-interaktiven Benutzern, Dienstauftraggebern und verwalteten Identitäten erfassen
- Audits - eine Aufzeichnung der wichtigsten Verzeichnisoperationen
- Provisioning - Daten über die Bereitstellung von Nutzern durch Drittdienste
Diese Protokolle sind über die Graph-API zugänglich und liegen derzeit in einer Basisversion (1.0) und einer Beta-Version vor, die unterschiedliche Schemata aufweisen.
Microsoft 365-Aktivitätsprotokolle werden über die Management-Aktivitäts-API abgerufen , die mehrere Protokolle für verschiedene Arten von Ereignissen bereitstellt:
- Audit.AzureActiveDirectory - Ereignisse des Entra ID-Dienstes (ähnlich wie bei der Graph API), z. B. Zuweisungen und Verzeichnisänderungen
- Audit.Exchange - Exchange-Ereignisse
- Audit.SharePoint - SharePoint-Aktivität
- Audit.General - die meisten anderen Aktionen, die nicht in eines der anderen Protokolle passen
- DLP.All - Ereignisse zum Schutz vor Datenverlust
Bekannte Probleme im Azure Monitor Log
Nachdem wir nun die Bedeutung von Azure Log Monitoring erkundet haben, wollen wir uns mit einigen Problemen befassen, die wir in diesen Protokollen gefunden haben. Das Wissen darüber kann Ihnen helfen, bessere Analyseabfragen zu erstellen und weniger Zeit mit der Frage zu verschwenden, warum sich Dinge so verhalten, wie sie es tun.
Zu den spezifischen Herausforderungen, die jeder Sicherheitsanalytiker und -architekt im Auge behalten sollte, gehören:
- Fluid-Schema
- Protokollfluss
- Verzögerungen bei Ereignissen
- Fehlende Ereignisse
- Logging-Steuer
- Ereignisse, die nie protokolliert werden
- Mangelhafte Dokumentation
- Unangekündigte Änderungen
- ID-Ungereimtheiten
- IP-Ungereimtheiten
- Unstimmigkeiten bei der Geolokalisierung
- Unstimmigkeiten bei den Geräteinformationen
- Kaputte Werte
Schauen wir uns die einzelnen Punkte genauer an.
Fluid-Schema
Das Schema in einigen Protokollen (z.B. Management Activity API) ist "fließend". Das bedeutet, dass ein eindeutiger Parameter in einer neuen Operation dem Protokoll als neue Spalte hinzugefügt wird.
Das macht die Verwaltung schwierig, selbst für Log Analytics. (Wir haben beobachtet, dass es Fehler anzeigt, die sich auf ein "Limit von maximal 500 Spalten erreicht" beziehen). Wenn Sie Ereignisse in einem externen SIEM nutzen möchten, müssen Sie möglicherweise selektiv auswählen, welche Spalten genutzt werden sollen, und es ist unmöglich, neue Spalten vorherzusagen, die Azure hinzufügt.
Eine bessere Methode wäre ein statisches Schema in allen Protokollen gewesen, mit hinzugefügten Strukturfeldern (z. B. in JSON), um die Variabilität zu handhaben.
Protokollfluss
In Azure kommt es gelegentlich zu Protokollierungsausfällen. In den letzten Jahren gab es sogar mehrere davon. Einer dauerte mehrere Wochen und wurde zufällig entdeckt, aber Microsoft ist im Allgemeinen gut darin, Kunden in solchen Situationen zu benachrichtigen.
Das Problem besteht darin, dass Sie während eines Ausfalls keinerlei Aktivitäten in der Umgebung wahrnehmen können. Wenn Sie auch noch die Ausfallmeldung verpassen, deutet nichts auf ein Problem hin. Es ist wichtig, den Zustand des Dienstes in Azure im Auge zu behalten und möglicherweise in eine Überwachungslösung zu investieren, die den Protokollfluss verfolgt.
Ausfälle können auch beabsichtigt sein. Die Konfiguration der Protokollierung wird bandintern gesteuert, und eine Kompromittierung eines Administratorkontos kann dazu führen, dass ein Angreifer die Protokollierung in großem Umfang (z. B. über Set-AdminAuditLogConfig) oder in einer feinkörnigeren und verdeckten Weise (z. B. über Set-Mailbox -AuditEnabled) deaktiviert.
Die Überwachung des Protokollflusses und der Konfigurationsänderungen ist von entscheidender Bedeutung, um solche Probleme zu entschärfen. Nur wenige autorisierte Benutzer müssen die Protokollierungseinstellungen ändern können. Es wäre wünschenswert, wenn Azure der Protokollkonfiguration mehr Kontrollen hinzufügen würde, da die versehentliche oder absichtliche Deaktivierung von Protokollen erhebliche nachteilige Folgen haben kann.
Verzögerungen bei Ereignissen
Microsoft veröffentlicht die erwarteten Zeiten für die Verfügbarkeit seiner Protokollereignisse. Die Aufnahmezeit der Graph-API wird mit unter 3 Minuten angegeben. Nach unserer Erfahrung kann es bis zu 30 Minuten dauern, bis die Ereignisse in diesen Quellen erscheinen.
Die angekündigte typische Verfügbarkeit für die Management ActivityAPI-Ereignisse liegt zwischen 60 und 90 Minuten. In der Realität sind die von uns beobachteten Verzögerungen jedoch deutlich größer. Hier sind einige Maximalwerte, die wir in letzter Zeit erfasst haben - einige Zeiten liegen weit über 24 Stunden (die Spalte max_delay enthält die maximale Zeit, die zwischen der Erstellung des Ereignisses und seiner Verfügbarkeit im Protokoll liegt):
Diese Art von Verzögerungszeiten sind nicht tragbar. Einige Angreifer bewegen sich extrem schnell. Berücksichtigt man die Zeit, die für die Verarbeitung durch Erkennungstools, die Aufnahme durch externe SIEM und die Reaktion des SOC-Personals erforderlich ist, wird klar, dass das blaue Team in vielen Fällen zu spät kommt - fast schon absichtlich.
Je mehr Angreifer ihre Werkzeuge automatisieren, desto schlimmer wird die Situation. Azure muss der schnellen Verfügbarkeit von Protokollen Vorrang einräumen. Andernfalls können Verteidiger nur auf Vorfälle reagieren, sie aber nicht aufhalten. Ereignisverzögerungen sind noch schwieriger zu bewältigen, wenn Protokolldatensätze an ein externes SIEM weitergeleitet werden. Protokoll-API-Aufrufe benötigen Zeitbereiche als Parameter, sodass Sie entweder den Verlust von Datensätzen in Kauf nehmen oder überlappende Zeitbereiche abfragen und doppelte Datensätze entfernen müssen, um keine verspäteten Ereignisse zu verpassen.
Fehlende Ereignisse
Einige Ereignistypen können in mehr als einem Protokoll zu finden sein. So sind beispielsweise Anmeldedatensätze sowohl in der Graph API als auch in der Management Activity API verfügbar. Vergleichen Sie die Datensätze für dasselbe Ereignis in beiden Quellen, und Sie werden gelegentlich Unterschiede feststellen.
Betrachten Sie die folgenden Beispiele aus einer kürzlich durchgeführten Untersuchung eines Vorfalls. Obwohl sie alle auf dieselben Aktionen eines Angreifers zurückzuführen sind, stimmen die protokollierten Datensätze nicht genau überein:
Graph API (Beta-Version im Azure Portal):
Graph API (v1.0):
AuditAzureActiveDirectoryin Management Activity API:
Diese Art von Inkonsistenz ist schwer zu reproduzieren und zu erklären, aber Sie müssen sich dessen bewusst sein, wenn Sie eine Protokollanalyse durchführen. Datensätze können verloren gehen, und die Analyse mehrerer Protokolle kann notwendig sein, um ein vollständigeres Bild der Vorgänge zu erhalten.
Logging-Steuer
Viele Protokollierungsereignisarten und -details sind nur in den höher bezahlten Stufen (z. B. E5 und P2) verfügbar. Einige Beispiele sind MailItemsAccessed-Ereignisse, Risikodetails im Anmeldeprotokoll und andere. Dies stellt für viele Kunden ein Dilemma dar - sie müssen sich zwischen niedrigeren Kosten und besserer Transparenz der Aktivitäten in ihrer Umgebung entscheiden.
Dies ist keine gute Wahl, zu der man gezwungen werden sollte, und unserer Meinung nach sollten grundlegende Sicherheitsfunktionen (wie z. B. Protokolle) für alle Kunden von cloud verfügbar sein. Der US-Senator Ron Wyden hat es kürzlich so formuliert: "Wenn man für Premium-Funktionen, die notwendig sind, um nicht gehackt zu werden, Geld verlangt, ist das so, als würde man ein Auto verkaufen und dann einen Aufpreis für Sicherheitsgurte und Airbags verlangen."
Dieser Mangel an Transparenz hat bei vielen Vectra AI Kundenvorfällen, die wir zu untersuchen hatten, zu Schwierigkeiten geführt. Ein kürzlich öffentlich bekannt gewordener Einbruch durch APT Storm-0558, mit dem sich Microsoft selbst auseinandersetzen musste, hat dieses Problem ans Licht gebracht. Infolge dieses Vorfalls hat Microsoft mit der CISA vereinbart, den Zugang zur Protokollierung in diesem Herbst auf alle Kunden auszuweiten.
Hoffentlich werden die Dinge bald besser. In der Zwischenzeit müssen Sie sicherstellen, dass die Protokollierung, auf die Sie mit Ihrer Lizenz Zugriff haben, für die IR-Anforderungen Ihrer Organisation ausreichend ist. Wenn nicht, ist es Zeit für ein Upgrade. Wenn wichtige Daten nicht verfügbar sind, können einige davon (z. B. IP-Reputation und Geolocation-Informationen) von Drittanbietern bezogen werden.
Einige Ereignisse, die nie protokolliert werden
Azure ist ein "Erkundungsparadies" mit "get"-artigen Ereignissen, die dem Auslesen von Konfigurationen und Daten entsprechen und bis auf wenige Ausnahmen nicht protokolliert werden. Im Oktober 2023 wurde ein neues Protokoll eingeführt , das Graph-API-Aufrufe auf zeichnet und einige der Aufklärungsvorgänge abdeckt. Die Aufzählung über andere APIs bleibt jedoch für Verteidiger unsichtbar.
Das bedeutet, dass ein Angreifer, wenn er Zugriff auf die Umgebung cloud erhält, die meisten Informationen - Benutzer, Dienste, Konfiguration - aufzählen kann, ohne von Verteidigern gesehen zu werden. Dies stellt einen großen blinden Fleck dar - in unseren Tests hinterließen die meisten quelloffenen M365/AAD-Aufzählungstools keine Spuren in den Protokollen.
Es ist unklar, warum die Entscheidung getroffen wurde, solche Ereignisse nicht zu protokollieren, möglicherweise um Platz zu sparen. Leider gibt es keine Option zur Aktivierung einer solchen Protokollierung, selbst wenn der Kunde diese Art von Ereignissen sehen möchte. Das bedeutet, dass Sie im Dunkeln tappen, bis Angreifer beginnen, Änderungen an Ihrer Umgebung vorzunehmen.
Mangelhafte Dokumentation
Während die Azure-APIs recht gut dokumentiert sind, mangelt es an einer Dokumentation der Protokollereignisse. Für viele Ereignisse ist nur der Name der Operation dokumentiert, aber die einzelnen Felder und ihre Bedeutung sind oft ein Rätsel. Man muss sich durch Blogs und Diskussionsforen wühlen, um zu verstehen, was passiert ist.
Nicht nur der Zweck eines Feldes ist unklar, auch die einzelnen Datenwerte sind manchmal schlecht dokumentiert. Wir haben spezifische Authentifizierungstypen, Statuscodes, Operationssubtypen und andere Daten ohne Beschreibung gesehen. Selbst eine gründliche Recherche brachte bei einigen dieser Werte keine Klarheit.
Da wir einige Felder und Werte nicht verstehen, können wir sie bei der Untersuchung und Reaktion auf einen Vorfall nicht überwachen und interpretieren.
Unangekündigte Änderungen
Wenn sich die Funktionalität von cloud weiterentwickelt (was häufig der Fall ist), erscheinen neue Ereignistypen unangekündigt in den Protokollen. Zum Beispiel wurde ein neuer Fehlercode für passwortlose Anmeldefehler hinzugefügt, den wir kürzlich dokumentiert haben. Das Vectra AI Security Research Team musste einige Zeit damit verbringen, ihn zu untersuchen, bevor wir verstehen konnten, was ihn ausgelöst hat, und bis dahin waren unsere Überwachungsabfragen blind für ihn.
Noch beunruhigender ist, dass auch bestehende Veranstaltungen verschwinden oder ihr Format ändern können. Einige aktuelle Beispiele sind:
- MailboxLogin-Ereignis, das wir verfolgt haben und das stillschweigend aus den Exchange-Protokollen verschwunden ist.
- Anmeldefehler für nicht existierende Benutzernamen, die wir verfolgt haben, um frühe Phasen von Aufklärungsaktivitäten zu erkennen, wurden nicht mehr in die Anmeldeprotokolle geschrieben.
Wenn Sie Überwachungs- und Analyseabfragen haben, die nach bestimmten Ereignissen suchen, werden diese Änderungen dazu führen, dass sie ohne Vorwarnung nicht mehr funktionieren. Dies ist die schlimmste Art von Ausfall - wenn Sie nicht einmal wissen, dass es ein Problem gibt. Möglicherweise müssen Sie in eine Logik zur Überwachung der Protokollintegrität investieren und die sich ändernden Protokollinhalte und -dokumente genau im Auge behalten. Leider sind die meisten Verteidiger zu beschäftigt, um dafür Zeit aufzuwenden.
ID-Ungereimtheiten
Die Benutzer-IDs sind nicht immer "stabil". Je nach Kontext und Art des Vorgangs kann ein und derselbe Benutzer in den Protokollen unter verschiedenen "Benutzerprinzipalnamen" (UPN) auftauchen. Ihr Benutzer könnte zum Beispiel angemeldet sein als:
- john.smith@company.com
- John.Smith@company.com (beachten Sie den Unterschied in der Groß- und Kleinschreibung)
- AN045789@company.com
M365 Exchange macht einen Strich durch die Rechnung, indem es veraltete Namen wie die folgenden (und andere) hinzufügt:
"NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e "im Namen von "NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/JohnSmith"
In Fällen von Namensvariabilität wird es schwierig, verschiedene Ereignisse demselben Benutzer zuzuordnen. Während die Korrelation von Ereignissen anhand der UPN der erste Impuls sein mag, kann die Korrelation anhand der eindeutigen internen ID eine robustere Strategie sein (aber immer noch nicht narrensicher).
Die Schwierigkeiten gehen weiter:
- Verschiedene Namen in verschiedenen Protokollen können sich überschneidende Feldnamen mit unterschiedlichen Bedeutungen haben. Zum Beispiel bedeutet user_id in einem Protokoll eine Benutzer-GUID und in einem anderen eine UPN.
- Benutzer-IDs können Werte haben, die Vor- und Nachnamen von Benutzern, Anwendungsnamen, Anwendungs-GUIDs und andere ungewöhnliche Namen und eindeutige IDs darstellen.
- Benutzer-IDs können leer sein oder unbrauchbare Namen wie "Nicht verfügbar", "Unbekannt" oder "Kein UPN" enthalten:
Als Verteidiger müssen Sie bereit sein, diese (wenig hilfreichen) Informationen in den Feldern der Benutzeridentität zu sehen und die Abfragefunktionen entsprechend zu gestalten.
IP-Ungereimtheiten
Eine gültige IP-Adresse ist eine Grundvoraussetzung für jeden Protokolleintrag. Während in den meisten Fällen gültige IPv4- und IPv6-Adressen in den Protokolleinträgen vorhanden sind, sehen wir manchmal IPs, die schwer zu verstehen und in der Analyse zu verwenden sind:
- IPs mit Portnummern (sowohl v4 als auch v6)
- Leere IPs
- Lokale und private IPs: 127.0.0.1, 192.168.*, 10.*
- Alle Null-IPs: 0.0.0.0
- IP-Masken anstelle von IPs: 255.255.255.255
- IPs, die der Azure-Infrastruktur entsprechen, nicht dem Benutzer, der den Vorgang ausführt
Bei einigen Vorgängen können die IPs nicht mit den Anmeldedaten in Beziehung gesetzt werden, was die Analyse von Vorfällen erschwert. IP-Risiko- und Reputationsindikatoren können gelegentlich verfügbar sein, unterliegen aber der "Protokollierungssteuer".
Als Verteidiger sollten Sie beim Schreiben von Jagdabfragen und Warnmeldungen mit diesen Sonderfällen rechnen und sie in Ihrer Logik berücksichtigen.
Unstimmigkeiten bei der Geolokalisierung
Derzeit bietet Microsoft nur die Geolokalisierung für Anmeldedatensätze an. Dies wäre für andere Protokollquellen hilfreich gewesen, da man Aktivitäten nicht immer mit bestimmten Anmeldeeinträgen in Verbindung bringen kann.
Diese Funktion ist nicht perfekt. Gelegentlich gibt es Schluckauf:
- Dieselbe IP wird zu mehreren Standorten aufgelöst (höchstwahrscheinlich im Zusammenhang mit mobilen Geräten).
- Datensätze werden massenhaft falsch geolokalisiert.
- Es fehlen Geoinformationen:
Die Geolokalisierung lässt sich auch leicht durch TOR, VPNs, Proxys und die IPs von cloud täuschen - und sollte mit Vorsicht genossen werden.
Unstimmigkeiten bei den Geräteinformationen
Gerätedetails sind für Microsoft nur schwer zu ermitteln (es sei denn, es handelt sich um ein registriertes Gerät). Plattform- und Browserinformationen werden in der Regel aus dem User Agent (UA) analysiert.
Leider gibt es auch hier Ungereimtheiten:
- Einige Protokolle analysieren den UA und stellen ihn stückweise zur Verfügung, andere wiederum geben den gesamten UA-String an (den Sie interpretieren müssen)
- Geräteinformationen sind nicht in allen Protokollen verfügbar
- Die geparsten Werte sind nicht immer konsistent (z. B. "Windows" vs. "Windows 10")
Angreifer können den Benutzer-Agenten leicht fälschen, aber er ist für Ermittlungen immer noch wertvoll, da nicht alle diszipliniert genug sind, ihn unauffällig zu ändern.
Kaputte Werte
Einige Protokollfelder haben komplexe Strukturen (z. B. JSON), und Jagd- und Überwachungsabfragen müssen diese analysieren, um auf bestimmte Unterfelder zu verweisen.
Gelegentlich werden diese Werte aufgrund von Größenbeschränkungen abgeschnitten, was zu fehlerhaften Strukturen führt. Betrachten Sie zum Beispiel den folgenden Wert, der für den Vorgang Set-ConditionalAccessPolicy protokolliert wurde. Ein Teil des Wertes wird abgeschnitten und durch drei Punkte ("...") ersetzt, was den JSON-Parser verwirren wird:
Überwachungsabfragen, die auf solche Datensätze stoßen, schlagen fehl, was zu blinden Flecken führt.
In solchen Fällen ist es möglicherweise nicht die beste Strategie, sich darauf zu verlassen, dass die Werte korrekt geparst werden, und die Suche nach Teilstrings funktioniert möglicherweise besser.
Was ist nötig, um die Qualität der Protokolle zu verbessern?
Wir sind nicht die Einzigen, die die Qualität der Azure-Protokolle kritisieren (ähnliche Probleme wurden bereits von CrowdStrike und EricWoodruff angesprochen), und wir können nur darüber spekulieren, warum es so viele davon gibt.
Protokolle haben bei der Softwareentwicklung in der Regel Vorrang vor anderen Funktionen. Backend-Servicefunktionen können geopfert werden, wenn das Entwicklungsteam unter Zeitdruck steht, um die primäre Produktfunktionalität zu veröffentlichen.
In riesigen Produkt-Ökosystemen wie Azure werden mehrere unabhängige (und manchmal auch veraltete) Produkte zusammengeführt. Es kann schwierig sein, dass alle ein gutes Signal in einer gemeinsamen Protokollierungsarchitektur bereitstellen, und diese Funktionalität ist nicht gerade "kundenorientiert", so dass Beschwerden darüber möglicherweise keine Priorität haben.
Was auch immer der Grund sein mag, das Fehlen von Alternativen in einer cloud Umgebung macht die Probleme mit der Protokollierung viel schwerwiegender, als sie es in einer traditionellen On-Premises-Konfiguration gewesen wären. Abgesehen davon, dass sie sich der Mängel in den Protokollen bewusst sind und versuchen, einige von ihnen zu umgehen, haben die Verteidiger keine anderen Möglichkeiten. Microsoft ist Eigentümer dieser Funktionalität, und es liegt an ihnen, sie zu verbessern.
Wir sind der Meinung, dass das Azure-Team eine Reihe von nicht-invasiven Änderungen vornehmen kann (und sollte):
- Alle Ereignisse, Felder und Enum-Werte sollten vollständig dokumentiert werden, um das Rätselraten bei der Protokollanalyse zu vermeiden.
- Struktur und Inhalt des Protokolls sollten wie eine API behandelt werden - alle Änderungen, die die Funktionalität der Protokollabfrage beeinträchtigen könnten, sollten kontrolliert eingeführt werden, und den Kunden sollte Zeit gegeben werden, die Änderungen zu berücksichtigen.
- Alle Hinzufügungen und (insbesondere) Streichungen von protokollierten Vorgängen müssen deutlich angekündigt werden.
- Die Aufzeichnungen müssen viel schneller als heute geliefert werden - in Sekunden statt in Minuten oder Stunden - und die Ereignisse sollten nicht verzögert werden oder nicht in der richtigen Reihenfolge eintreffen.
- Alle protokollierten Werte sollten nützlich, korrekt und nicht eindeutig sein.
- Die Protokolle sollten umfangreiche Informationen enthalten, die für die Reaktion auf Vorfälle nützlich sind (z. B. IP-Reputation).
Idealerweise wäre eine Überarbeitung der Protokollierungsarchitektur von Vorteil, um sie schlanker zu gestalten (ähnlich wie bei AWS und Okta).
Die wichtigsten Erkenntnisse für Spieler der roten Mannschaft
Wir haben bisher nur über die Schwierigkeiten gesprochen, die diese Probleme für Ihr Team mit sich bringen. Aber es ist wichtig, sich daran zu erinnern, dass der Verlust eines Verteidigers der Gewinn eines Angreifers ist. Kompetente Black Hats, APTs und Red-Teamer können die Besonderheiten der Azure-Protokollierung ausnutzen, um ihre Aktionen zu verbergen und die Bemühungen des Blue-Teams zu erschweren.
Hier sind einige der Techniken, die Angreifer einsetzen könnten:
- Verwendung ungewöhnlicher Vorgänge, die weniger dokumentiert oder verstanden werden
- Ausführen von Aktionen, die fehlerhafte oder undokumentierte Werte in die Protokolle einspeisen und so die Analyse erschweren
- Verbindung von Standorten aus, für die IP- oder Geolocation-Informationen falsch protokolliert werden
- Zeitliche Abstimmung von Vorgängen, um Verzögerungen bei der Datenaufnahme auszunutzen oder die Erkennung von zusammenhängenden Ereignissen zu erschweren
Natürlich wären weitere Forschungen erforderlich, um aus einem Mangel in der Protokollierung eine robuste Umgehungstechnik zu machen.
Ihr Job als Verteidiger ist hart. Der Versuch, Angriffe schnell zu erkennen und zu beheben, ist ein großes Unterfangen, und es wird noch mühsamer, wenn Sie Probleme protokollieren und umgehen müssen.
Das Versprechen einer besseren Sicherheit auf cloud ist kein Hirngespinst, und eine der Möglichkeiten, dies zu erreichen, besteht darin, eine qualitativ hochwertige Protokollierung zu liefern. Die Anbieter haben zwar die Möglichkeit, dies zu erreichen, aber möglicherweise fehlt ihnen der Anreiz, dies zu einem vorrangigen Ziel zu machen. Hier kommen wir ins Spiel. Je mehr die Sicherheitsforschungsgemeinschaft aufdeckt und je mehr Druck wir ausüben, desto näher können wir der Verbesserung der Protokollqualität kommen.
Möchten Sie sich an der Diskussion beteiligen? Diskutieren Sie mit dem Vectra AI Security Research Team direkt über diesen Blogbeitrag und andere Themen auf Reddit.