t1606-forge-web-credentials

# T1606 - Forge Web Credentials ## Descrição A técnica **T1606 - Forge Web Credentials** descreve o comportamento de adversários que **fabricam** materiais de credencial - cookies de sessão, tokens de acesso, asserções SAML, JWTs - que permitem acesso a aplicações web e serviços de nuvem sem passar pelo processo normal de autenticação. Esta é uma distinção crítica em relação a técnicas de roubo como [[t1539-steal-web-session-cookie|T1539 - Steal Web Session Cookie]] ou [[t1528-steal-application-access-token|T1528 - Steal Application Access Token]]: aqui, as credenciais são **criadas do zero** pelo adversário, não interceptadas de usuários legítimos. A efetividade desta técnica depende do adversário ter obtido previamente os **valores secretos** necessários para a forjá: chaves privadas de assinatura de tokens (RSA/ECDSA), certificados X.509 de provedores de identidade, segredos de sessão de aplicações web, ou credenciais de APIs de nuvem com permissão para gerar tokens temporários. Quando bem-sucedida, a técnica permite ao adversário impersonar qualquer usuário do ambiente - incluindo administradores - sem conhecer as senhas reais e frequentemente **bypassando a autenticação multifator (MFA)**, uma vez que o mecanismo de MFA já foi "ultrapassado" na geração do token forjado. A técnica se desdobra em duas sub-técnicas principais: - **[[t1606-001-web-cookies|T1606.001 - Web Cookies]]**: forjá de cookies de sessão web - **[[t1606-002-saml-tokens|T1606.002 - SAML Tokens]]**: forjá de asserções SAML - o ataque conhecido como "Golden SAML" Em ambientes de nuvem (IaaS), adversários podem usar APIs nativas como `AssumeRole` (AWS), `GetFederationToken` (AWS) ou a chave de pré-autenticação do Zimbra (`zmprov gdpak`) para gerar tokens com permissões arbitrárias. Isso transforma credenciais de serviço de baixo privilégio em tokens de alta permissão de forma programática. ## Como Funciona O processo de forjá de credenciais web segue etapas bem definidas dependendo do tipo de credencial alvo: **1. Forjá de Cookies de Sessão (T1606.001)** Aplicações web que geram cookies usando segredos compartilhados previsíveis ou que utilizam algoritmos de assinatura fracos são vulneráveis. O adversário que obtém o segredo de sessão (via dump de memória, acesso ao banco de dados de configuração ou exfiltração de variáveis de ambiente) consegue gerar cookies assinados válidos para qualquer usuário, incluindo o campo de identificação de conta (`user_id`, `email`, `sub`). Ferramentas como `flask-unsign` permitem decodificar, modificar e reassinar cookies de sessão Flask. Aplicações que usam frameworks com configurações padrão inseguras (chave secreta padrão, fraca ou hardcoded) são alvos especialmente vulneráveis. **2. Forjá de Tokens SAML - "Golden SAML" (T1606.002)** SAML (Security Assertion Markup Language) é o protocolo padrão de federação de identidade corporativa. Uma SAMLResponse é assinada digitalmente pelo Identity Provider (IdP) usando seu certificado de token signing. Quando o adversário obtém a chave privada do certificado de assinatura do AD FS, Okta, Azure AD ou outro IdP, ele pode gerar SAMLResponses para qualquer usuário e qualquer serviço (SP - Service Provider) sem interagir com o IdP real. Esse ataque foi central no incidente **SolarWinds/SUNBURST** (2020), onde o grupo [[g0016-apt29|APT29]] (Cozy Bear) utilizou acesso aos sistemas da SolarWinds para extrair certificados de assinatura ADFS de vítimas e persistir no ambiente por meses gerando tokens SAML legítimos para usuários privilegiados no Microsoft 365. **3. Geração de Tokens Temporários via APIs de Nuvem** APIs como `sts:AssumeRole` (AWS) e `auth:generateAccessToken` (GCP) permitem que identidades autorizadas gerem tokens de curta duração com permissões específicas. Adversários com acesso a credenciais de serviço que têm permissão de `AssumeRole` em roles privilegiadas podem gerar tokens com amplos privilégios administrativos. Isso é especialmente crítico quando IAM policies usam wildcards (`*`) ou quando existe trust policy excessivamente permissiva entre roles. **4. Pre-authentication Keys em Zimbra** O comando `zmprov gdpak` do Zimbra gera uma chave de pré-autenticação que permite fazer login como qualquer usuário do domínio. Adversários com acesso de administrador ao Zimbra podem gerar estas chaves e acessar qualquer caixa de email sem conhecer as senhas individuais. ## Attack Flow ```mermaid graph TB A["Obtenção de Acesso Inicial (phishing, exploit, supply chain)"] --> B["Reconhecimento Interno (identificar IdP, certificados, segredos)"] B --> C{"Tipo de credencial alvo?"} C -->|"Cookie de sessão web"| D["Extração do segredo de assinatura da aplicação"] C -->|"SAML Token"| E["Extração do certificado de token signing do IdP"] C -->|"Token de nuvem"| F["Identificação de role assumível com wildcards"] D --> G["Forjá do cookie com usuário privilegiado"] E --> H["Geração de SAMLResponse (Golden SAML)"] F --> I["Chamada API AssumeRole / GetFederationToken"] G --> J[">de autenticação alternativo"] H --> J I --> J J --> K["Acesso a recursos SaaS/IaaS com bypass de MFA"] K --> L["Exfiltração, Persistência ou Destruição"] ``` ## Exemplos de Uso ### APT29 - Operação SolarWinds / Golden SAML (2020) O grupo russo [[g0016-apt29|APT29]] (Cozy Bear), responsável pelo ataque à cadeia de suprimentos da SolarWinds em 2020, utilizou a técnica Golden SAML de forma extensiva. Após comprometer os sistemas internos da SolarWinds e distribuir o backdoor [[s0559-sunburst|SUNBURST]] via atualizações do Orion, os adversários acessaram os ambientes das vítimas e extraíram os certificados de assinatura do ADFS. Com esses certificados, geraram tokens SAML para usuários privilegiados no Microsoft 365, obtendo acesso a email corporativo, SharePoint e outras aplicações sem disparar alertas de MFA por meses. Mais de 100 organizações nos EUA foram afetadas, incluindo agências governamentais. ### Ataque a Identity Providers SaaS - Okta (2022) Em 2022, o grupo LAPSUS$ e posteriormente o grupo Scattered Spider obtiveram acesso a sistemas internos da Okta via engenharia social. Com acesso ao painel administrativo, conseguiram gerar sessões para clientes da plataforma sem autenticação. Embora o mecanismo específico variasse, o resultado era equivalente à forjá de credenciais web: acesso autenticado a dezenas de clientes corporativos sem conhecimento das credenciais reais dos usuários. ### Exploração de IAM Policies Permissivas na AWS Em auditorias de segurança recorrentes em ambientes cloud brasileiros, é comum encontrar roles AWS com `sts:AssumeRole` permitido para `*` (qualquer entidade) ou com condições ausentes. Um adversário que compromete qualquer credencial de serviço no ambiente pode encadear múltiplos `AssumeRole` até obter permissões de administrador (`AdministratorAccess`), gerando tokens temporários completamente legítimos do ponto de vista da AWS CloudTrail. ### Zimbra em Ambientes Governamentais Múltiplos grupos de espionagem patrocinados por estados - incluindo atores com foco na América Latina - exploraram servidores Zimbra expostos em órgãos governamentais da região. Com acesso ao servidor, o uso de `zmprov gdpak` permite geração de tokens de acesso a qualquer caixa do domínio, resultando em exfiltração silenciosa de comúnicações governamentais. ## Detecção A detecção de forjá de credenciais web é desafiadora porque os tokens gerados são **criptograficamente válidos** - do ponto de vista dos serviços, eles são indistinguíveis de tokens legítimos. A detecção deve ser baseada em **anomalias comportamentais**: **Indicadores de Golden SAML:** - SAMLResponses geradas fora do horário normal de operação do IdP - Atributos SAML com valores inconsistentes (ex: usuário sem licença acessando recurso premium) - Ausência de eventos de autenticação correspondentes nos logs do IdP para uma sessão ativa - Acesso de IPs incomuns com tokens válidos **Indicadores em ambientes de nuvem:** - Chamadas `AssumeRole` ou `GetFederationToken` de entidades incomuns - Tokens com TTL máximo gerados fora de horário de expediente - Atividade em roles raramente usadas logo após assumir a role **Regra de detecção (Sigma):** ```yaml title: Suspicious SAML Token Generation Outside Business Hours status: experimental logsource: category: application product: azure_ad detection: selection_saml_issue: EventType: 'SamlTokenIssuance' filter_business_hours: EventTime|re: '^.*(0[0-7]|2[0-3]):[0-5][0-9]:[0-5][0-9]' selection_privileged_user: TargetUserRoles|contains: - 'GlobalAdmin' - 'PrivilegedRoleAdmin' - 'SecurityAdmin' condition: selection_saml_issue and filter_business_hours and selection_privileged_user level: high tags: - attack.credential_access - attack.t1606.002 ``` **Monitoramento adicional recomendado:** - Auditar acesso ao certificado de token signing do ADFS/IdP (eventos de exportação de certificado) - Alertar sobre rotação incomum de segredos de aplicação ou chaves de API - Correlacionar tokens de nuvem com chamadas de API que os geraram - Implementar detecção de uso de tokens em múltiplos IPs/regiões geograficamente distantes (impossible travel) ## Mitigação | ID | Mitigação | Descrição | |---|-----------|-----------| | M1026 | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Restringir o acesso ao certificado de token signing do IdP a um número mínimo de contas de serviço. Usar HSMs (Hardware Security Modules) para armazenar chaves privadas de assinatura, impedindo extração por software. Rotacionar certificados periodicamente. | | M1054 | [[m1054-software-configuration\|M1054 - Software Configuration]] | Configurar aplicações web para usar segredos de sessão longos e aleatórios (mínimo 256 bits). Desabilitar funcionalidades de geração de tokens permissivas (ex: restringir `AssumeRole` via condições estritas em políticas IAM). Revogar pré-chaves de autenticação Zimbra regularmente. | | M1047 | [[m1047-audit\|M1047 - Audit]] | Auditar regularmente quem tem acesso aos certificados de assinatura do IdP, às chaves secretas de aplicações e às permissões de geração de tokens em ambientes de nuvem. Revisar IAM policies para remover wildcards em trust policies. | | M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Implementar princípio do menor privilégio para roles e permissões de geração de tokens. Limitar quais identidades podem assumir roles com altos privilégios. Implementar condições temporais e de IP em políticas de AssumeRole. | ## Contexto Brasil/LATAM A técnica T1606 tem impacto crescente no contexto regional por múltiplos fatores: **Adoção acelerada de SaaS e nuvem no Brasil:** O Brasil lidera a adoção de SaaS na América Latina, com Microsoft 365 e Google Workspace amplamente difundidos em empresas de todos os portes e no governo. Isso aumenta a superfície de ataque para forjá de tokens SAML e OAuth, já que muitas organizações dependem de um único IdP para centenas de aplicações. **Lacunas em configuração de Identity Providers:** Diagnósticos de segurança em organizações brasileiras frequentemente revelam configurações inadequadas em ADFS e Azure AD - incluindo certificados de token signing sem proteção adequada, ausência de Conditional Access policies e trust policies IAM excessivamente permissivas em ambientes AWS e Azure. **Ataques de ransomware pré-criptografia via credenciais forjadas:** Grupos de ransomware que operam no Brasil, como afiliados do [[lockbit|LockBit]] e do [[black-basta|Black Basta]], têm adotado técnicas de acesso via credenciais web forjadas para persistir silenciosamente nas redes por semanas antes de detonar o payload de criptografia - maximizando o impacto e dificultando a recuperação. **Fornecedores de IdP locais:** Provedores de identidade e SSO com presença no mercado brasileiro (como TOTVS Identity, fornecedores de certificado digital ICP-Brasil) podem conter vulnerabilidades específicas que precisam de aténção e cobertura de inteligência de ameaças local. **LGPD e responsabilidade:** Incidentes envolvendo forjá de credenciais que resultem em acesso não autorizado a dados pessoais têm implicações regulatórias diretas sob a [[lgpd|Lei Geral de Proteção de Dados]] - tornando a mitigação desta técnica não apenas uma questão de segurança, mas de conformidade legal. ## Sub-técnicas - [[t1606-001-web-cookies|T1606.001 - Web Cookies]] - [[t1606-002-saml-tokens|T1606.002 - SAML Tokens]] ## Referências - [MITRE ATT&CK - T1606](https://attack.mitre.org/techniques/T1606) - [Golden SAML - CyberArk Research](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) - [SolarWinds SUNBURST - Mandiant Report](https://www.mandiant.com/resources/blog/sunburst-additional-technical-details) - [AWS AssumeRole Security Considerations](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) - [[t1539-steal-web-session-cookie|T1539 - Steal Web Session Cookie]] - [[t1528-steal-application-access-token|T1528 - Steal Application Access Token]] - [[t1550-use-alternate-authentication-material|T1550 - Use Alternaté Authentication Material]] - [[g0016-apt29|APT29 - Cozy Bear]] - [[s0559-sunburst|SUNBURST Malware]]