# T1606.002 - SAML Tokens
> [!danger] Golden SAML
> Esta técnica é conhecida informalmente como **"Golden SAML"** - análoga ao ataque Golden Ticket do Kerberos, mas para infraestruturas de identidade federada em nuvem. Foi central no ataque [[solarwinds-supply-chain|SolarWinds]] de 2020.
## Técnica Pai
Esta é uma sub-técnica de [[t1606-forge-web-credentials|T1606 - T1606 - Forge Web Credentials]].
## Descrição
Um adversário pode forjar tokens SAML com quaisquer reivindicações de permissão e tempos de vida desejados, desde que possua um certificado de assinatura de token SAML válido. O tempo de vida padrão de um token SAML é de uma hora, mas o período de válidade pode ser específicado no valor `NotOnOrAfter` do elemento `conditions` dentro do token. Esse valor pode ser alterado usando `AccessTokenLifetime` em uma `LifetimeTokenPolicy`. Tokens SAML forjados permitem que adversários autentiquem-se em **qualquer serviço que utilize SAML 2.0 como mecanismo de SSO (Single Sign-On)** - incluindo Microsoft 365, Azure, AWS, e aplicações SaaS corporativas.
Um adversário pode utilizar técnicas de roubo de [[t1552-004-private-keys|Chaves Privadas]] para comprometer o certificado de assinatura de token de uma organização e criar tokens SAML forjados. Se o adversário tiver permissões suficientes para estabelecer uma nova relação de confiança de federação com seu próprio servidor Active Directory Federation Services (AD FS), ele poderá gerar seu próprio certificado de assinatura de token confiável. Isso difere de [[t1528-steal-application-access-token|Steal Application Access Token]] e outros comportamentos similares porque os tokens são **novos e forjados** pelo adversário - e não roubados ou interceptados de usuários legítimos.
Um adversário pode obter privilégios administrativos no [[microsoft-entra-id|Microsoft Entra ID]] (anteriormente Azure AD) se um token SAML for forjado alegando representar uma conta altamente privilegiada. Isso pode levar ao uso de [[t1550-use-alternate-authentication-material|Material de Autenticação Alternativo]], potencialmente contornando a autenticação multifator (MFA) e outros mecanismos de proteção de autenticação - pois o Identity Provider já válida o token como legítimo.
> [!warning] Impacto Crítico
> A técnica Golden SAML permite persistência quase invisível: um adversário que obteve o certificado de assinatura pode continuar gerando tokens válidos mesmo após reset de senhas, revogação de sessões e outras respostas a incidentes convencionais - contanto que o certificado não sejá rotacionado.
---
## Como Funciona
A forjá de tokens SAML requer acesso ao certificado de assinatura privado do Identity Provider (IdP). Em ambientes AD FS (Microsoft), esse certificado é protegido pelo DKM (Distributed Key Manager) no [[active-directory|Active Directory]].
**Pré-requisitos para o ataque:**
1. **Comprometimento do servidor AD FS** ou acesso ao certificado de assinatura via extração do DKM
2. **Ou**: Permissões suficientes no Azure/Entra para criar uma nova relação de confiança de federação com IdP controlado pelo adversário
**Fluxo técnico detalhado:**
1. **Extração do certificado**: O adversário acessa o servidor AD FS e extrai o certificado de assinatura de token. Ferramentas como [[s0677-aadinternals|AADInternals]] (`Export-AADIntADFSCertificates`) automatizam esse processo. Em ambientes onde o DKM está ativo, pode ser necessário comprometer o AD para extrair a chave de descriptografia.
2. **Construção do token SAML**: Com o certificado em mãos, o adversário usa ferramentas especializadas para criar um token SAML XML contendo:
- `NameIdentifier`: Identidade do usuário alvo (ex: administrador global)
- `NotOnOrAfter`: Data futura distante (ex: 10 anos)
- Claims de grupos e roles desejados
- Assinatura XML válida usando a chave privada do certificado
3. **Uso do token forjado**: O token é injetado em requisições para serviços que confiam no IdP comprometido - Microsoft 365, AWS com SAML federation, Salesforce, Workday, entre outros.
4. **Acesso persistente**: Como o token é assinado com o certificado legítimo, os Service Providers aceitam-no como válido sem questionar. A autenticação bem-sucedida pode ser quase indistinguível de logins legítimos.
---
## Attack Flow
```mermaid
graph TB
A["Comprometimento Inicial do Ambiente"] --> B["Reconhecimento da Infraestrutura de Identidade"]
B --> C{"Vetor de Acesso ao Certificado"}
C --> D["Comprometimento do Servidor AD FS"]
C --> E["Extração via DKM no Active Directory"]
C --> F["Criação de Nova Federação Confiável"]
D --> G["Extração do Certificado de Assinatura"]
E --> G
F --> H["Geração de Certificado Próprio Confiável"]
G --> I["Forjá de Token SAML Golden SAML"]
H --> I
I --> J["Token com Claims Privilegiadas e Lifetime Estendido"]
J --> K["Autenticação em Microsoft 365 / Azure"]
J --> L["Autenticação em SaaS Corporativo"]
J --> M["Autenticação em AWS SAML Federation"]
K --> N["Acesso como Administrador Global"]
L --> N
M --> N
N --> O["Persistência Resistente a Reset de Senha e MFA"]
```
---
## Exemplos de Uso
### Cenário 1 - Ataque SolarWinds (Operação UNC2452 / APT29)
O ataque à cadeia de suprimentos da [[solarwinds-supply-chain|SolarWinds]] em 2020 é o caso mais documentado de uso de Golden SAML em escala. O grupo [[g0016-apt29|APT29]] (Cozy Bear), após comprometer ambientes via backdoor SUNBURST, extraiu certificados de assinatura AD FS de organizações-alvo e forjou tokens SAML para manter acesso persistente ao Microsoft 365 e Azure - mesmo após as organizações iniciarem processos de resposta a incidentes e resetarem senhas.
O que tornou o ataque particularmente devastador: como os tokens eram assinados com certificados legítimos, os logs de autenticação não revelavam atividade anômala óbvia. A investigação exigiu correlação avançada de logs do AD FS com logs do Azure AD.
### Cenário 2 - AADInternals para Forjá de Token
A ferramenta de código aberto [[s0677-aadinternals|AADInternals]], desenvolvida por pesquisadores finlandeses, demonstrou a viabilidade do Golden SAML de forma detalhada:
```powershell
# Exportar certificados do servidor AD FS (requer acesso admin local ao AD FS)
Export-AADIntADFSCertificates
# Criar um token SAML forjado para um usuário específico
$token = New-AADIntSAMLToken `
-UserName "
[email protected]" `
-Issuer "http://sts.empresa.com.br/adfs/services/trust" `
-Certificaté $cert
# Usar o token para autenticar no Azure AD
$tokens = Get-AADIntAccessTokenWithSAML -SAMLToken $token -Resource "https://graph.microsoft.com"
```
### Cenário 3 - Federação AWS + Azure
Em empresas que usam federação SAML entre Azure AD e AWS, a forjá de tokens permite que um adversário com acesso ao certificado AD FS assuma roles AWS com permissões arbitrárias - sem interagir com as credenciais AWS diretamente. Esse vetor é especialmente crítico em ambientes com contas AWS de produção.
---
## Detecção
A detecção de Golden SAML é desafiadora porque os tokens são técnicamente válidos. A estratégia principal é identificar **anomalias contextuais** - não falhas de autenticação.
### Sigma Rule - Token SAML com Lifetime Excessivo
```yaml
title: SAML Token with Extended Lifetime
status: experimental
description: Detecta autenticações SAML com tokens de válidade anormalmente longa
logsource:
category: cloud
service: azure_ad
product: microsoft365
detection:
selection:
eventName: "Sign-in activity"
authenticationProtocol: "SAML"
filter_normal:
tokenLifetime|lt: 3600
condition: selection and not filter_normal
level: high
tags:
- attack.credential_access
- attack.t1606.002
```
### Sigma Rule - Acesso ao Certificado AD FS
```yaml
title: AD FS Token Signing Certificaté Export
status: experimental
description: Detecta acesso ou exportação do certificado de assinatura do AD FS
logsource:
category: process_creation
product: windows
detection:
selection_tool:
Image|endswith:
- '\adfsdump.exe'
- '\ADFSDump.exe'
CommandLine|contains: 'export'
selection_powershell:
CommandLine|contains:
- 'Export-AADIntADFSCertificates'
- 'Get-ADFSCertificaté'
- 'DKMDatabaseValue'
condition: selection_tool or selection_powershell
level: critical
tags:
- attack.credential_access
- attack.t1606.002
- attack.t1552.004
```
### Indicadores Comportamentais para Investigação
| Indicador | Fonte de Log | Severidade |
|-----------|-------------|------------|
| Login SAML de IP não corporativo | Azure AD Sign-in logs | Alta |
| Token com `NotOnOrAfter` > 24h | AD FS Event Log (ID 1202/1203) | Crítica |
| Autenticação em serviço não usado pelo usuário | Azure AD / Office 365 UAL | Alta |
| Acesso ao DKM no AD (`ms-FVE-*` objects) | AD Security Events (ID 4662) | Crítica |
| Exportação de certificados no servidor AD FS | Windows Security (ID 4648, 4688) | Crítica |
---
## Mitigação
| ID | Mitigação | Descrição |
|----|-----------|-----------|
| M1015 | [[m1015-active-directory-configuration\|M1015 - Active Directory Configuration]] | Proteger o servidor AD FS com controles de acesso rigorosos. Restringir acesso ao DKM (Distributed Key Manager) no AD. Considerar uso de Hardware Security Module (HSM) para proteção do certificado de assinatura. |
| M1047 | [[m1047-audit\|M1047 - Audit]] | Habilitar logging detalhado no AD FS (Event IDs 1200-1210, 1202, 1203) e correlacionar com Azure AD Sign-in logs. Monitorar acessos ao servidor AD FS e ao DKM no AD. |
| M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Limitar o número de contas com permissão para gerenciar AD FS e modificar relações de confiança de federação. Revisar regularmente as contas de serviço do AD FS. |
| M1026 | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Implementar Privileged Access Workstations (PAW) para administração do AD FS. Usar contas dedicadas e separadas para administração de identidade. Habilitar MFA resistente a phishing para admins do AD FS. |
### Controles Específicos para Golden SAML
- **Rotação periódica do certificado de assinatura AD FS**: A Microsoft recomenda rotação anual; após incidente, rotacionar imediatamente
- **Microsoft Entra ID Protection**: Habilitar políticas de risco de usuário e risco de login para detectar comportamentos anômalos pós-autenticação
- **Monitorar anomalias de User Agent**: Logins via SAML com User Agents incomuns (scripts, ferramentas) são suspeitos
- **Separação de ambientes AD FS**: Não colocar servidores AD FS em domínios de produção geral; usar tier separado
- **Alertas para novos relying parties**: Qualquer novo Service Provider confiante no AD FS deve gerar alerta
---
## Contexto Brasil/LATAM
A técnica de forjá de tokens SAML é particularmente relevante para o contexto brasileiro devido à rápida adoção de soluções Microsoft 365 e ambientes híbridos com AD FS por organizações dos setores financeiro, governo e saúde.
**Adoção acelerada de M365 no Brasil**: O Brasil é um dos maiores mercados de Microsoft 365 na América Latina. Organizações que migraram para o M365 com federated identity (em vez de password hash sync ou passthrough authentication) são diretamente vulneráveis ao Golden SAML se o AD FS não estiver adequadamente protegido.
**Operações de Espionagem Contra o Brasil**: Grupos de estado-nação com interesse documentado no Brasil - incluindo operações relacionadas a espionagem industrial, vazamento de dados governamentais e comprometimento de infraestrutura crítica - têm adotado técnicas de comprometimento de identidade federada como vetor de persistência de longo prazo, dada a dificuldade de detecção e a resistência a respostas a incidentes convencionais.
**Setor Financeiro e BACEN**: Bancos brasileiros regulados pelo [[bacen|Banco Central do Brasil]] (BACEN) sob as normas da Resolução CMN 4.893/2021 e BCB 85/2021 são obrigados a implementar controles de gestão de identidade e acesso privilegiado. A exploração bem-sucedida de Golden SAML em uma instituição financeira pode constituir violação dessas normas, além das obrigações da [[lgpd|LGPD]].
**Alerta para Ambientes Governamentais**: Em 2023 e 2024, foram documentados múltiplos comprometimentos de ambientes Microsoft em organizações governamentais brasileiras via técnicas de identidade federada. A adoção do padrão de configuração de Entra ID com Password Hash Sync (em vez de federação AD FS pura) é recomendada pelo CISA e reduz significativamente a superfície de ataque.
> [!tip] Recomendação para o Brasil
> Organizações brasileiras que ainda usam AD FS on-premises para federar com Entra ID devem avaliar a migração para **Password Hash Sync (PHS)** ou **Pass-Through Authentication (PTA)** - ambas eliminam a dependência do AD FS e removem o vetor Golden SAML do modelo de ameaça.
---
## Referências
- [MITRE ATT&CK - T1606.002: SAML Tokens](https://attack.mitre.org/techniques/T1606/002/)
- [Golden SAML - Seminal Research by CyberArk (2017)](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
- [CISA Alert AA21-008A - SolarWinds and SAML Token Abuse](https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a)
- [Microsoft - Detect and Remediaté Illicit Consent Grants](https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediaté-illicit-consent-grants)
- [AADInternals - Golden SAML Attack Demonstration](https://aadinternals.com/post/adfs/)
- [CISA - Securing Identity Infrastructure](https://www.cisa.gov/sites/default/files/2023-03/fact_sheet_securing_microsoft_cloud_identities_508.pdf)
**Técnicas Relacionadas:** [[t1606-forge-web-credentials|T1606]], [[t1552-004-private-keys|T1552.004]], [[t1528-steal-application-access-token|T1528]], [[t1550-use-alternate-authentication-material|T1550]], [[ta0006-credential-access|Credential Access]], [[g0016-apt29|APT29]]
---
*Fonte: [MITRE ATT&CK - T1606.002](https://attack.mitre.org/techniques/T1606/002/)*