TL;DR: In diesem Blogbeitrag besprechen wir, was SAML ist, wie das Alte wieder ganz neu erscheint, und wie ihr SAML-Angriffe erkennen und entschärfen könnt. Unser Schwerpunkt liegt auf der Erkennung und ist als Gerüst gedacht, das euch den Einstieg erleichtert. Es ist nicht zwingend eine Lösung, die für jeden und für alle Installationen funktioniert. Wir werden nicht viel Zeit darauf verwenden, Sunburst oder Supernova zu thematisieren, sondern uns auf einige bereits gewonnene Erkenntnisse konzentrieren und darauf, wie wir uns besser gegen zukünftige Angriffe positionieren können.
Was ist SAML?
Security Assertion Markup Language (SAML) ist eine Methode für den Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen vertrauenswürdigen Parteien. Es handelt sich im Wesentlichen um ein XML-Schema, das die Grundlage von Single Sign-On (SSO) bildet. Zumindest ist dies die heute gebräuchlichste Art der Verwendung. Das Grundkonstrukt besteht darin, dass ein Client bei dem Versuch, sich bei einem Service-Anbieter zu authentifizieren, an einen Authentifizierungsserver weitergeleitet wird. Nach der Authentifizierung wird dem Client eine kryptografisch signierte Antwort übergeben, die er dann seinerseits zurück an den Serviceanbieter übergibt. Nach dem Empfang wird die Antwort dank der Magie der Kryptographie validiert. Zumindest soll es so funktionieren und uns (und unsere Daten) schützen.
Wenn das noch zu verwirrend klingt, seht euch dieses Flussdiagramm von Sygnia an:
(Urheber: Sygnia)
Ohne SAML müssten unsere Systemadministratoren unzählige neue Konten für jeden Service erstellen, den wir für unsere Arbeit benötigen. In der Folge müssten wir uns mehrere Benutzernamen und Kennwörter für jeden Service merken (denn Kennwörter darf man nie wiederverwenden, nicht wahr?) und außerdem sicherstellen, dass sie regelmäßig aktualisiert werden. Es wäre ein administrativer Albtraum für Systemadmins und Benutzer gleichermaßen. Glücklicherweise gibt es jedoch technologische Lösungen, die uns alle nachts ruhig schlafen lassen.
Ein bisschen Geschichte zu Golden SAML
Nun, dieser Zustand war schön, so lange er anhielt. Wie bei jeder Technologie gibt es auch hier Schwachstellen und Angreifer arbeiten unermüdlich daran, diese zu finden und auszunutzen. Bereits 2017 veröffentlichte CyberArk einen Blogbeitrag, in dem eine neue Angriffstechnik namens Golden SAML im Detail vorgestellt wurde. In diesem Blogbeitrag wurde ausführlich eine Technik beschrieben, die es einem Angreifer ermöglicht, eine eigene SAML-Antwort mit dem Inhalt und den Berechtigungen zu generieren, die er für notwendig hält. Doch es gibt ein paar Probleme, die der Angreifer zunächst lösen muss. Insbesondere benötigt er Zugriff auf die Zertifikate, die zum Signieren der SAML-Objekte verwendet werden. Das bedeutet in der Regel, dass er einen Zugang zum Netzwerk und privilegierten Zugriff benötigt, um die Zertifikate zu extrahieren. Es stehen mehrere Tools zur Verfügung, die dem Angreifer helfen, dies zu bewerkstelligen, darunter certutil.exe, PowerShell, ADFSDump und das allseits beliebte Mimikatz (keine Sorge, wir beschreiben in Kürze, wie man diese Vorgänge erkennt). Alles, was der Angreifer tun muss, ist, sein bevorzugtes Tool auszuführen, um die Zertifikate zu extrahieren, und schon ist er auf dem besten Weg zur Golden SAML-Seligkeit.
Sygnia bietet uns eine weitere nachvollziehbare Visualisierung, wie ein Golden SAML-Angriff aussehen würde.
(Urheber: Sygnia)
Warum ist das so wichtig? Da der Angreifer nun Zugriff auf die extrahierten Zertifikate hat, kann er sich im Unternehmen als nahezu jeder Benutzer mit nahezu jeder Berechtigung ausgeben. Und nicht nur das: Er kann das auch von jedem Ort der Welt aus tun. Darüber hinaus ist der Angreifer auch imstande, den Schutz durch Multi-Faktor-Authentifizierung (MFA) zu umgehen. Warum? Weil der eigentliche Authentifizierungsserver vollständig aus dem Prozess entfernt wird. Der Angreifer hat eine gültige Antwort des Authentifizierungsservers gefälscht und damit die MFA komplett umgangen.
Golden SAML und der SolarWinds-Cyberangriff
Was hat das nun alles mit dem SolarWinds-Angriff zu tun hat? Nun ja, die Kompromittierung von SolarWinds Orion hat zum ersten aufgezeichneten Einsatz von Golden SAML in freier Wildbahn geführt. Fast drei Jahre, nachdem das Verfahren zum ersten Mal als praktikable Post-Exploitation-Technik dokumentiert wurde, war dies das erste Mal, dass jemand ihren Einsatz entdeckt hatte. Das spricht entweder für die Effektivität, Flexibilität und Heimlichkeit dieser Technik oder für die Entschlossenheit und Geschicklichkeit dieses Angreifers. Wahrscheinlich beides.
Welche Daten benötige ich?
In unseren Beispielen konzentrieren wir uns auf eine Windows-Umgebung, die Active Directory-Verbunddienste (Active Directory Federation Services oder ADFS) für SAML nutzt. ADFS-Sicherheits- und Audit-Logs geben zusätzliche Informationen zu möglichen Golden SAML-Angriffe. Doch dazu später mehr. Außerdem müssen möglicherweise einige Abfragen in eurer Umgebung angepasst werden, abhängig von den installierten und konfigurierten Splunk-TAs (Technology Add-ons). Und ihr solltet eins bedenken: Nur weil unsere Beispiele auf eine Windows-Umgebung und ADFS beschränkt sind, heißt das nicht, dass dies auch für den Angriffsvektor gilt. Golden SAML-Angriffe sind mit so gut wie jedem SAML-Anbieter möglich.
Aber zuerst ein paar Warnungen. Dies ist kein einfaches Unterfangen. Das Erkennen dieser Aktivitäten kann extrem schwierig sein und Daten aus mehreren Quellen innerhalb einer Enklave erfordern, sowohl intern als auch extern. Wir versuchen Beispiele zu liefern, die euch helfen können, Angriffe dieser Art zu erkennen.
So, da das nun geklärt wäre, lasst uns einige Windows-Ereignisse durchgehen, die wir benötigen, um diese Aktivität zu finden.
Windows Event Codes
Zum Erkennen von SAML-Angriffen gegen Microsoft-Infrastruktur benötigen wir (wenig überraschend) Microsoft-Logs. Im Folgenden findet ihr einige Links und Ideen, wie ihr die Ereignisse aktivieren und erfassen könnt, die ihr benötigt, um Golden SAML-Aktivitäten zu erkennen. Betrachtet sie als „Splunkspiration“. Möglicherweise funktioniert es nicht sofort, aber es sollte euch auf den richtigen Weg bringen. Abhängig von der Erkennungsmethode gibt es mehrere Windows-Ereignisse, die erfasst werden müssen, damit eine Erkennung möglich ist. Denkt daran, dass ihr wahrscheinlich eine Aufsicht (SysAdmin) dabei haben möchtet, bevor ihr irgendwelche Systemänderungen vornehmt. YMMV und es gibt eine Reihe von Anforderungen (wie Windows 2016 oder höher und installierter Sysmon), die erfüllt sein müssen, um tatsächlich ans Ziel zu kommen.
Ach, und da es sich um einen Splunk-Blog handelt, gehen wir davon aus, dass ihr den Splunk Universal Forwarder verwendet, um Windows-Ereignisse in Splunk zu erfassen.
ADFS Event IDs
Dies sind vielleicht die wichtigsten Windows-Ereignisse, die es zu erfassen gilt, und leider sind einige davon standardmäßig nicht aktiviert. Ihr findet zusätzliche Informationen zum Aktivieren dieser Ereignisse in diesem Blogbeitrag und der PowerShell Gallery sowie in der Dokumentation dazu hier und hier.
- 1200 (AD FS-Admin): Der Verbunddienst hat eine neue Anmeldeinformation validiert.
- 1202 (AD FS-Admin): Der Verbunddienst hat ein gültiges Token ausgegeben
- 307 (AD FS-Admin): Die Konfiguration des Verbunddiensts wurde geändert
- 510 (AD FS-Admin): Zusatzinformationen
- 1007 (Microsoft-Windows-CertificateServicesClient-Lifecycle-System): Zertifikat exportiert
Wir sammeln allerdings standardmäßig nicht die Ereignisprotokolle, in denen diese Ereignisse vorkommen, also müssen wir sie einer Splunk TA-Konfiguration hinzufügen – beispielsweise könnt ihr sie zur inputs.conf-Datei im Splunk Add-On für Windows hinzufügen. Fügt zunächst einen Absatz hinzu, um das richtige Log der Certificate Services zu aktivieren (mit dieser Anweisung wird nur 1007 erfasst – entfernt die Whitelist-Anweisung, wenn ihr den Rest der Certificate Services nutzen möchtet):
[WinEventLog://CertificateServicesClient-Lifecycle-System/Operational] disabled = 0 start_from = oldest current_only = 0 checkpointInterval = 5 renderXml=true whitelist = $XmlRegex=’(?:1007).+’
Und nur für den Fall, dass ihr dachtet, das sei die einzige Änderung, lasst euch eines Besseren belehren. Die Active Directory-Verbunddienste weisen ein eigenes Log für Ereignisse auf. Also müssen wir inputs.conf (auf unserem Forwarder) einen weiteren Abschnitt hinzufügen:
[WinEventLog://AD FS/Admin] disabled = 0 start_from = oldest current_only = 0 checkpointInterval = 5 renderXml=true
Diese beiden inputs.conf-Beispiele wurden auf einem Windows 2019-Server getestet.
Domain Controller Event IDs
Zum Erfassen der benötigten Ereignisse vom bzw. von den Domänencontroller(n) müssen wir sie über das Snap-In der lokalen Sicherheitsrichtlinie oder über die Gruppenrichtlinie aktivieren. Weitere Informationen zu den Einstellungen finden sich in der Microsoft-Dokumentation.
- 4769 (Security): Es wurde ein Kerberos-Dienstticket angefordert
Endpunkt-Ereignis-IDs
Alle der unten aufgeführten Ereignis-IDs helfen dabei, die Ausführung einer Zertifikatextraktion an der Befehlszeile oder in PowerShell zu erkennen. Braucht ihr Hilfe beim Erfassen der PowerShell-Ereignisse in Splunk? Dann seid ihr hier genau richtig (Die Dokumentation ist von UBA, aber keine Sorge, sie funktioniert für alle Logs in PowerShell.)
- 4688 (Security) (und vergewissert euch, dass ihr Prozessargumente aktiviert.)
- 4103 (PowerShell) (siehe Slide 79 hier)
- 4104 (PowerShell) (siehe oben)
- 18 (Sysmon)
Wie kann Golden SAML erkannt werden?
Wir haben eine Reihe von Möglichkeiten, um zusammenhängende Aktivitäten zu erkennen. Sehen wir uns an, wie wir einige von ihnen in Splunk finden können, indem wir die Methodik verwenden, die Sygnia in einem kürzlich erschienenen Ratgeber besprochen hat. Bedenkt außerdem, dass es sich hier um Beispielabfragen handelt, die euch weiterhelfen sollen. Das Aufspüren dieser Aktivität in einem Unternehmen kann eine Herausforderung darstellen, Euer Weg kann sich bei den folgenden Abfragen daher unterscheiden und wahrscheinlich ist ein gewisses Maß an Anpassung erforderlich, damit sie in eurer Umgebung richtig funktionieren. Es wird vorausgesetzt, dass ihr Windows-Logs im XML-Format verwendet (eine Umstellung auf das klassische Format ist aber möglich).
1. Suchen nach Zertifikatexporten in den ADFS-Ereignisprotokollen
Damit dieser Angriff erfolgreich sein kann, muss der Angreifer die entsprechenden Zertifikate von einem ADFS-Server exportieren. Dies sollte relativ selten vorkommen, da es nur wenige Gründe für den rechtmäßigen Export von Zertifikaten gibt. Wir können nach dieser Aktivität in den Windows-Ereignisprotokollen für den ADFS-Server nach der Ereignis-ID 1007 suchen.
# sourcetype=xmlwineventlog source="xmlwineventlog:CertificateServicesClient-Lifecycle-System/Operational" EventCode="1007"
Außerdem können wir nach Hinweisen dafür suchen, dass ADFS-Zertifikate über die Befehlszeile oder PowerShell exportiert wurden. Diese Befehle können von überall aus ausgeführt werden, also auch von Servern oder Clients. Achtet also unbedingt darauf, dass eure Abfragen nicht nur auf den ADFS-Server beschränkt sind.
Suchen wir zunächst nach Zertifikatexporten über PowerShell
index=main sourcetype=xmlwineventlog
source="xmlwineventlog:Microsoft-Windows-PowerShell/Operational"
EventCode IN (4104, 4103) ScriptBlockText IN
("*Export-PfxCertificate*", "*certutil -exportPFX*" )
Wir können auch durch die Verwendung von certutil.exe nach Hinweisen suchen
index=main sourcetype=xmlwineventlog source="xmlwineventlog:Security" EventCode=4688 CommandLine="*certutil.exe -exportPFX*"
Suchen wir schließlich nach den Methoden, die von Mimikatz und ADFSDump verwendet werden. Bedenkt bitte, dass diese Pipe sehr beliebt ist. Wir wollen also sehen, welche Prozesse (Images) nicht häufig verwendet werden und diese näher untersuchen.
index=main sourcetype="xmlwineventlog:microsoft-windows-sysmon/operational" EventCode=18 PipeName="\microsoft##wid\tsql\query" | stats count by Image | sort count
2. Identifizieren anormaler Authentifizierungsereignisse
Hinweis: Diese Technik funktioniert nur auf Windows Server 2016 oder höher. Die Ereignis-IDs 1200 und 1202 waren in früheren Versionen von Windows nicht vorhanden.
Gültige SAML-Authentifizierungsereignisse erzeugen mehrere Sicherheitsereignisse auf den ADFS- und DC-Servern, ebenso in dem Service, bei dem wir uns authentifizieren. Wir suchen nach allen drei folgenden Ereignis-IDs auf unserem ADFS und DC in den Logs mit Windows-Sicherheitsereignissen.
- 1200 – Der Verbunddienst hat ein gültiges Token ausgegeben
- 1202 – Der Verbunddienst hat einen neuen Satz Anmeldeinformationen validiert
- 4769 – Es wurde ein Kerberos-Dienstticket angefordert
Anschließend korrelieren wir diese Ereignisse mit den Authentifizierungsereignissen des Services, bei dem sich der Benutzer zu authentifizieren versucht hat (der Serviceanbieter). In diesem Anwendungsfall prüfen wir auf Authentifizierungsversuche in den Anmeldeprotokollen von Azure AD.
Bei Golden SAML-Angriffen fehlen die ADFS-Authentifizierungsprotokolle (und höchstwahrscheinlich auch die DC-Authentifizierungsprotokolle), da der Angreifer die SAML-Antwort bequemerweise fälscht, wodurch sie aus dem Authentifizierungsvorgang entfernt wird. Wir sollten aber trotzdem eine „erfolgreiche“ Authentifizierung vom Serviceanbieter sehen, da er eine signierte SAML-Antwort empfangen hat, auch wenn diese vom Angreifer gefälscht wurde.
sourcetype=xmlwineventlog source="xmlwineventlog:Security"
EventCode IN (1200, 1202, 4769)
`comment("Suche nach diesen drei Ereigniscodes in Windows-Sicherheitsereignisprotokollen")`
[ search sourcetype=ms:aad:signin status.errorCode=0
| eval Account_Name=mvindex(split(userPrincipalName,"@"),0)
`comment("Verwerfe den @domain-Teil des userPrincipalName")`
| fields Account_Name ]
`comment("Erstelle eine Liste der Kontonamen von Anmeldeversuchen über Azure AD zur Korrelierung mit den Windows-Sicherheitsereignisprotokollen")`
| eval Account_Name=mvindex(Account_Name,-1)
`comment("Verwende nur den letzten Wert von Account_Name aus dem Windows Event Log, wodurch Situationen herausgefiltert werden sollten, in denen Account_Name - oder ein Hostwert ist")`
| eval Account_Name=mvindex(split(Account_Name,"@"),0)
`comment("Verwerfe den @domain-Teil des Account_Name")`
| transaction dest Account_Name maxspan=2s maxevents=3
`comment("Erstelle ein einzelnes Ereignis mit dem gleichen Ziel und Account_Name, die innerhalb von 2 Sekunden auftreten, auf drei Ereignisse beschränkt")`
| eval mcount=mvcount(EventCode)
`comment("Zähle die Anzahl der eindeutigen Ereigniscodes für jeden Kontonamen")`
| where mcount<3
`comment("Suche nach Ereignissen, in denen keiner der drei Ereigniscodes vorkommt")`
| table _time Account_Name EventCode
3. Überwachung der ADFS-Trust-Modifications (Änderungen der ADFS-Vertrauensstellung)
Anstatt die benötigten Zertifikate von einem vertrauenswürdigen ADFS-Server zu extrahieren, kann der Angreifer es vorziehen, einen neuen vertrauenswürdigen ADFS-Server hinzuzufügen, den er kontrolliert. Wir suchen nach Ereignis-ID 307 (Die Konfiguration des Verbunddiensts wurde geändert) und korrelieren mit Ereignis-ID 510 mit der gleichen Instanz-ID. Konfigurationsänderungen für Verbunddienste treten in vielen Unternehmen nur selten auf, also verwendet dies als Ausgangspunkt, den ihr nach Bedarf anpasst.
sourcetype=xmlwineventlog source="xmlwineventlog:AD FS/Admin" EventCode IN (307, 510)
Empfehlungen zur Risikominderung
Wie bei jeder Technologie ist das Befolgen von Best-Practice-Anleitungen und Empfehlungen immer der beste Weg nach vorne. Wenn ihr Active Directory-Verbunddienste (ADFS) verwendet, bietet Microsoft eine hervorragende Ressource für deren Schutz. In Anbetracht der Tatsache, wie kritisch ADFS für viele Unternehmen sind, ist die Implementierung so vieler Sicherheitsmaßnahmen wie möglich in jedem Fall empfehlenswert. Vielleicht kommt keiner Einzelmaßnahme eine größere Bedeutung zu als dem Einsatz eines Hardware-Sicherheitsmoduls (Hardware Security Module, HSM) zum Generieren und Speichern von Zertifikaten. HSM bietet den zusätzlichen Vorteil, dass eure Schlüssel sowie alle kryptografischen Funktionen sicher auf einem physischen Gerät gespeichert werden. Warum ist das so wichtig? Es nimmt die Möglichkeit, den so wichtigen privaten Schlüssel zu extrahieren, was die Fähigkeit eines Angreifers, einen Golden SAML-Angriff durchzuführen, effektiv einschränkt (oder zumindest die Hürde und den Aufwand dafür erhöht).
Fazit
Wir wissen nun, was SAML ist, wie ein Golden SAML-Angriff funktioniert und wie einige Beispiel-Erkennungsmethoden sowie einschlägige Datenquellen aussehen. Wir sind zudem kurz auf allgemeine Empfehlungen eingegangen, mit denen sich diese Art von Angriff zukünftig entschärfen lässt. Alle diese Inhalte sollen euch helfen, eure allgemeine Sicherheitslage zu verbessern. Dies wird nicht das letzte Mal sein, dass wir einen Angreifer sehen, der Golden SAML ausnutzt, um sich im Netzwerk eines Opfers aufzuhalten. Die Bekanntheit dieses Angriffs hat die Effektivität dieser Technik demonstriert, was dazu führen kann, dass mehr Angreifer diese Technik in ihren Werkzeugkasten aufnehmen.
Mehr Informationen findet ihr auf unserer SolarWinds Cyberattack Response Page.
Ferner möchte ich John Stoner, Lily Lee, James Brodsky und Ryan Kovar hier bei Splunk besonders erwähnen und mich bei ihnen bedanken. Sie waren maßgeblich daran beteiligt, diesen Blogbeitrag zu verfassen, die Abfragen zu erstellen und sicherzustellen, dass die Logik die Oberhand behielt.
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: A Golden SAML Journey: SolarWinds Continued.
----------------------------------------------------
Thanks!
Splunk
