Tutorial: Untersuchen von Vorfällen mit UEBA-Daten
In diesem Artikel werden allgemeine Methoden und Beispielverfahren für die Verwendung der Benutzer- und Entitätsverhaltensanalyse (User and Entity Behavior Analytics, UEBA) in Ihren regulären Untersuchungsworkflows beschrieben.
Wichtig
Entsprechend gekennzeichnete Features in diesem Artikel sind derzeit als VORSCHAUVERSION verfügbar. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten zusätzliche rechtliche Bedingungen, die für Azure-Features gelten, die sich in der Beta- oder Vorschauversion befinden bzw. anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.
Hinweis
Dieses Tutorial enthält szenariobasierte Verfahren für eine wichtige Kundenaufgabe: Untersuchungen mit UEBA-Daten. Weitere Informationen finden Sie unter Untersuchen von Vorfällen mit Microsoft Sentinel.
Voraussetzungen
Bevor Sie UEBA-Daten in Ihren Untersuchungen verwenden können, müssen Sie die Benutzer- und Entitätsverhaltensanalyse (User and Entity Behavior Analytics, UEBA) in Microsoft Sentinel aktivieren.
Etwa eine Woche nach dem Aktivieren von UEBA können Sie mit der Suche nach computergestützten Erkenntnissen beginnen.
Ausführen proaktiver Routinesuchvorgänge in Entitätsdaten
Wir empfehlen, regelmäßig proaktive Suchvorgänge für Benutzeraktivitäten auszuführen, um Leads für weitere Untersuchungen zu erstellen.
Mithilfe der Microsoft Sentinel-Arbeitsmappe Benutzer- und Entitätsverhaltensanalyse (UEBA) können Sie zum Beispiel Daten für folgende Bereiche abfragen:
- Benutzer mit dem höchsten Risiko, mit Anomalien oder angefügten Vorfällen
- Daten zu bestimmten Benutzern, um zu ermitteln, ob die Person tatsächlich kompromittiert wurde oder ob eine Insiderbedrohung aufgrund einer vom Benutzerprofil abweichenden Aktion besteht.
Erfassen Sie darüber hinaus in der UEBA-Arbeitsmappe nicht routinemäßige Aktionen, und verwenden Sie diese, um nach anomalen Aktivitäten und potenziell nicht konformen Methoden zu suchen.
Untersuchen einer anomalen Anmeldung
Mit den folgenden Schritten führen Sie beispielsweise eine Untersuchung für einen Benutzer aus, der eine Verbindung mit einem zuvor noch nie genutzten VPN hergestellt hat, was eine anomale Aktivität darstellt.
Suchen Sie im Azure Sentinel-Bereich Arbeitsmappen die Arbeitsmappe Benutzer- und Entitätsverhaltensanalyse (UEBA) , und öffnen Sie diese.
Suchen Sie nach einem bestimmten Benutzernamen, der untersucht werden soll, und wählen Sie den Namen in der Tabelle Wichtigste zu untersuchende Benutzer aus.
Scrollen Sie in den Tabellen Aufschlüsselung von Vorfällen und Aufschlüsselung von Anomalien nach unten, um die Vorfälle und Anomalien anzuzeigen, die mit dem ausgewählten Benutzer verbunden sind.
Überprüfen Sie für die jeweilige Anomalie (z. B. Anomale erfolgreiche Anmeldung) die in der Tabelle angezeigten Details, um diese zu untersuchen. Beispiel:
Schritt Beschreibung Beachten Sie die Beschreibung auf der rechten Seite Jede Anomalie enthält eine Beschreibung mit einem Link, über den Sie weitere Informationen aus der MITRE ATT&CK-Wissensdatenbank abrufen können.
Beispiel:
Erstzugriff
Der Angreifer versucht, in Ihr Netzwerk zu gelangen.
Der Erstzugang besteht aus Techniken, die verschiedene Einstiegsvektoren verwenden, um in einem Netzwerk Fuß zu fassen. Zu den Techniken, die verwendet werden, um ins Netzwerk zu gelangen, gehören gezieltes Spear-Phishing und das Ausnutzen von Schwachstellen auf öffentlich zugänglichen Webservern. Ein durch den Erstzugang erworbener Netzwerkzugriff ermöglicht ggf. den fortgesetzten Zugriff (z. B. gültige Konten und die Verwendung externer Remotedienste) oder kann durch das Ändern von Kennwörtern eingeschränkt werden.Beachten Sie den Text in der Spalte „Beschreibung“ Scrollen Sie in der Zeile „Anomalie“ nach rechts, um eine zusätzliche Beschreibung anzuzeigen. Wählen Sie den Link aus, um den vollständigen Text anzuzeigen. Beispiel:
Angreifer können die Anmeldeinformationen eines bestimmten Benutzers oder Diensts mithilfe von Techniken für den Zugriff auf Anmeldeinformationen stehlen oder Anmeldeinformationen zu einem früheren Zeitpunkt in ihrem Erkundungsprozess durch Social Engineering abfangen, um so einen Erstzugang zu erhalten. APT33 hat beispielsweise gültige Konten für den Erstzugang verwendet. Die nachstehende Abfrage erzeugt eine Ausgabe der erfolgreichen Anmeldung eines Benutzers von einem neuen geografischen Standort aus, von dem aus er oder einer seiner Kollegen noch nie eine Verbindung hergestellt hat.Beachten Sie die UsersInsights-Daten Scrollen Sie in der Zeile „Anomalie“ weiter nach rechts, um die UserInsights-Daten (z. B. Anzeigename des Kontos und Kontoobjekt-ID) anzuzeigen. Wählen Sie den Text aus, um die vollständigen Daten auf der rechten Seite anzuzeigen. Beachten Sie die Beweisdaten Scrollen Sie in der Zeile „Anomalie“ weiter nach rechts, um die Beweisdaten für die Anomalie anzuzeigen. Wählen Sie den Text aus, um die vollständigen Daten auf der rechten Seite anzuzeigen, z. B. die folgenden Felder:
- ActionUncommonlyPerformedByUser
- UncommonHighVolumeOfActions
- FirstTimeUserConnectedFromCountry
- CountryUncommonlyConnectedFromAmongPeers
- FirstTimeUserConnectedViaISP
- ISPUncommonlyUsedAmongPeers
- CountryUncommonlyConnectedFromInTenant
- ISPUncommonlyUsedInTenant
Ermitteln Sie mithilfe der Daten in der Arbeitsmappe Benutzer- und Entitätsverhaltensanalyse (UEBA) , ob die Benutzeraktivität verdächtig ist und weitere Maßnahmen erfordert.
Verwenden von UEBA-Daten zum Analysieren falsch positiver Ergebnisse
Manchmal ist ein in einer Untersuchung erfasster Vorfall falsch positiv.
Ein häufiges Beispiel für falsch positive Ergebnisse sind Reiseaktivitäten, die als unmöglich erkannt werden (z. B. bei einem Benutzer, der sich innerhalb einer Stunde bei einer Anwendung oder einem Portal in New York und London angemeldet). Auch wenn Microsoft Sentinel den unmöglichen Ortswechsel als Anomalie erkennt, kann eine Untersuchung des Benutzers klären, dass ein VPN mit einem anderen Standort als dem tatsächlichen Standort des Benutzers verwendet wurde.
Analysieren eines falsch positiven Ergebnisses
Navigieren Sie beispielsweise bei einem Vorfall des Typs Unmöglicher Ortswechsel, nachdem Sie mit dem Benutzer geklärt haben, dass ein VPN verwendet wurde, von der Vorfallsseite zur Benutzerentitätsseite. Verwenden Sie die dort angezeigten Daten, um zu ermitteln, ob die erfassten Standorte in den allgemein bekannten Standorten des Benutzers enthalten sind.
Beispiel:
Die Benutzerentitätsseite ist auch mit der Vorfallsseite selbst und dem Untersuchungsdiagramm verknüpft.
Tipp
Nachdem Sie die Daten auf der Benutzerentitätsseite für den speziellen Benutzer bestätigt haben, der dem Vorfall zugeordnet ist, wechseln Sie zum Microsoft Sentinel-Bereich Hunting, um zu erfahren, ob auch die Kollegen des Benutzers in der Regel von den gleichen Standorten aus eine Verbindung herstellen. Wenn das der Fall ist, wäre dieses Wissen ein noch stärkerer Hinweis auf ein falsch positives Ergebnis.
Führen Sie im Bereich Hunting die Abfrage Anmeldung von anomalen geografischen Standorten aus. Weitere Informationen finden Sie unter Suchen nach Bedrohungen mit Microsoft Sentinel.
Einbetten von IdentityInfo-Daten in Ihre Analyseregeln (Public Preview)
Da Angreifer häufig die eigenen Benutzer- und Dienstkonten der Organisation verwenden, sind Daten über diese Benutzerkonten wie etwa Benutzeridentifikation und Berechtigungen für die Analysten bei der Untersuchung von entscheidender Bedeutung.
Betten Sie Daten aus der Tabelle „IdentityInfo“ ein, um die Analyseregeln für Ihre Anwendungsfälle zu optimieren, falsch positive Ergebnisse zu verringern und ggf. den Untersuchungsprozess zu beschleunigen.
Zum Beispiel:
Gehen Sie wie folgt vor, um Sicherheitsereignisse mit der Tabelle IdentityInfo in einer Warnung zu korrelieren, die ausgelöst wird, wenn jemand außerhalb der IT-Abteilung auf einen Server zugreift:
SecurityEvent | where EventID in ("4624","4672") | where Computer == "My.High.Value.Asset" | join kind=inner ( IdentityInfo | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.SubjectUserSid == $right.AccountSID | where Department != "IT"
Gehen Sie wie folgt vor, um Microsoft Entra-Anmeldeprotokolle mit der Tabelle IdentityInfo in einer Warnung zu korrelieren, die ausgelöst wird, wenn jemand, der kein Mitglied einer bestimmten Sicherheitsgruppe ist, auf eine Anwendung zugreift:
SigninLogs | where AppDisplayName == "GithHub.Com" | join kind=inner ( IdentityInfo | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.UserId == $right.AccountObjectId | where GroupMembership !contains "Developers"
Die Tabelle IdentityInfo wird mit Ihrem Microsoft Entra-Arbeitsbereich synchronisiert, um eine Momentaufnahme Ihrer Benutzerprofildaten zu erstellen. Diese umfassen beispielsweise Benutzermetadaten, Gruppeninformationen und Microsoft Entra-Rollen, die den einzelnen Benutzern zugewiesen sind. Weitere Informationen finden Sie in der Referenz zu UEBA-Anreicherungen unter Tabelle „IdentityInfo“.
Identifizieren von Kennwortspray- und Spear-Phishing-Versuchen
Wenn die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) nicht aktiviert ist, sind Benutzeranmeldeinformationen anfällig für Angreifende, die mit Kennwortspray- oder Spear-Phishing-Versuchen Angriffe zur Kennwortkompromittierung durchführen möchten.
Untersuchen eines Kennwortspray-Vorfalls mit UEBA-Erkenntnissen
Wenn Sie beispielsweise einen Kennwortspray-Vorfall mit UEBA-Erkenntnissen untersuchen möchten, könnten Sie folgende Schritte ausführen, um mehr zu erfahren:
Wählen Sie im Vorfall unten links die Option Untersuchen aus, um die Konten, Computer und anderen Datenpunkte anzuzeigen, die möglicherweise Ziel eines Angriffs waren.
Beim Durchsuchen der Daten wird möglicherweise ein Administratorkonto mit einer relativ großen Anzahl von Anmeldefehlern angezeigt. Auch wenn dies verdächtig ist, möchten Sie das Konto möglicherweise nicht ohne weitere Bestätigung einschränken.
Wählen Sie in der Zuordnung die Entität des Administratorbenutzers und dann auf der rechten Seite Erkenntnisse aus, um nach weiteren Details (z. B. Diagramm der Anmeldungen im Zeitverlauf) zu suchen.
Wählen Sie auf der rechten Seite Info und dann Vollständige Details anzeigen aus, um zur Benutzerentitätsseite zu wechseln und einen weiteren Drilldown auszuführen.
Achten Sie beispielsweise darauf, ob dies der erste potenzielle Kennwortspray-Vorfall des Benutzers ist, oder beobachten Sie den Anmeldeverlauf des Benutzers, um zu erkennen, ob die Fehler anomal waren.
Tipp
Sie können auch die Hunting-Abfrage Anomale fehlgeschlagene Anmeldung ausführen, um alle ungewöhnlichen fehlgeschlagenen Anmeldungen in einer Organisation zu überwachen. Verwenden Sie die Ergebnisse der Abfrage, um Untersuchungen zu möglichen Kennwortspray-Angriffen zu starten.
URL-Detonation (Public Preview)
Wenn die in Microsoft Sentinel erfassten Protokolle URLs enthalten, werden diese URLs automatisch detoniert, um die Selektierung zu beschleunigen.
Der Untersuchungsgraph enthält einen Knoten für die detonierte URL sowie die folgenden Details:
- DetonationVerdict: Die übergeordnete boolesche Einordnung der Detonation. Schlecht bedeutet beispielsweise, dass die Seite als Host für Schadsoftware oder als Phishinginhalt klassifiziert wurde.
- DetonationFinalURL: Die endgültige beobachtete Landing Page-URL nach allen Umleitungen von der ursprünglichen URL.
Zum Beispiel:
Tipp
Sollten in Ihren Protokollen keine URLs angezeigt werden, überprüfen Sie, ob die URL-Protokollierung (auch Bedrohungsprotokollierung genannt) für Ihre sicheren Webgateways, Webproxys, Firewalls oder Legacy-IDS/IPS aktiviert ist.
Sie können auch benutzerdefinierte Protokolle erstellen, um bestimmte relevante URLs zur weiteren Untersuchung an Microsoft Sentinel weiterzuleiten.
Nächste Schritte
Weitere Informationen zu UEBA, Untersuchungen und Hunting finden Sie hier: