# T1553.006 - Code Signing Policy Modification ## Técnica Pai Sub-técnica de [[t1553-subvert-trust-controls|T1553 - Subvert Trust Controls]] ## Descrição Adversários podem modificar políticas de assinatura de código para viabilizar a execução de código não assinado ou autoassinado, contornando controles de integridade do sistema operacional. A assinatura de código é um mecanismo fundamental de confiança que garante a autenticidade e integridade de programas - associando um executável ou driver a um desenvolvedor verificado por uma Autoridade Certificadora (CA) confiável. Controles de segurança modernos em Windows e macOS dependem fortemente da válidade dessas políticas de assinatura: - **Windows** - Driver Signature Enforcement (DSE) exige que drivers em modo kernel sejam assinados por uma CA Microsoft reconhecida. O Secure Boot e o Code Integrity (CI) válidam a cadeia de confiança desde o firmware até os módulos carregados no kernel. Aplicações de controle como Windows Defender Application Control (WDAC) e AppLocker podem ser configuradas para bloquear DLLs e executáveis não assinados. - **macOS** - System Integrity Protection (SIP) e Gatekeeper aplicam políticas de assinatura e notarização para binários, extensões de kernel (kext) e aplicações distribuídas fora da App Store. Ao subverter essas políticas, adversários podem carregar drivers maliciosos, executar shellcode não assinado e implantar rootkits em modo kernel - o nível mais privilegiado de execução disponível no sistema operacional. Esta sub-técnica é particularmente grave porque remove uma das últimas barreiras de defesa em profundidade: mesmo que um payload sejá detectado como suspeito por outras camadas, a política de assinatura comprometida elimina o bloqueio baseado em integridade de código. ## Como Funciona **Vetores de modificação em Windows:** **1. bcdedit.exe - Modo de Teste (Test Signing)** O comando `bcdedit.exe /set TESTSIGNING ON` ativa o Test Signing Mode no bootloader do Windows. Nesse modo, o sistema aceita drivers assinados com certificados autoassinados ou de teste. Requer reinicialização e deixa um artefato visual - marca d'água "Test Mode" no canto inferior direito da área de trabalho - que adversários frequentemente tentam remover via modificações no registro. **2. bcdedit.exe - Debug Mode (nointegritychecks)** `bcdedit.exe /set nointegritychecks ON` desabilita a verificação de integridade de código para todos os módulos kernel. Alternativa ao Test Signing que não requer certificado de assinatura, mas igualmente requer reinicialização. **3. Modificação direta da variável de kernel g_CiOptions** Adversários avançados modificam a variável `g_CiOptions` na memória do kernel do Windows, que controla o comportamento do Code Integrity. Ao alterar o valor para `0x0` (disabled), DSE é desabilitado sem necessidade de reinicialização e sem artefatos visuais. Para acessar a memória do kernel, utilizam a técnica BYOVD (Bring Your Own Vulnerable Driver) via [[t1068-exploitation-privilege-escalation|Exploração para Escalada de Privilégios]] - carregando um driver legítimo mas vulnerável que permite escrita arbitrária em memória kernel. **4. Modifying Registry para Application Control Policies** Políticas do Windows Defender Application Control (WDAC) e AppLocker são configuradas via chaves de registro. Adversários com privilégios administrativos podem modificar ou remover essas chaves para eliminar restrições de execução aplicadas a DLLs e scripts. **Vetores de modificação em macOS:** **5. csrutil disable - Desabilitação do SIP** O comando `csrutil disable` executado no ambiente de Recovery Mode desabilita o System Integrity Protection. Requer acesso físico ou reinicialização no modo de recuperação, mas uma vez desabilitado, o SIP permanece desativado persistentemente até ser reativado manualmente. **6. Modificação de variáveis NVRAM** Adversários podem modificar variáveis de firmware NVRAM no macOS para alterar configurações de boot que controlam o comportamento do SIP e da verificação de assinatura de extensões de kernel, potencialmente sem acesso físico quando obtido privilégio de root. > [!example] APT39 - Carregamento de Drivers Maliciosos > O [[g0087-apt39|APT39]], grupo iraniano focado em telecomúnicações e viagens, utiliza modificações de DSE para carregar drivers de captura de tráfego e keyloggers em modo kernel em sistemas Windows de organizações-alvo. A capacidade de operar em modo kernel garante invisibilidade frente a soluções EDR que operam em modo usuário. > [!example] BlackEnergy - Ataques a Infraestrutura Ucraniana > O malware [[s0089-blackenergy|BlackEnergy]], usado em ataques devastadores a distribuidoras de energia elétrica na Ucrânia (2015-2016), utilizou modificações de política de assinatura de código para carregar plugins maliciosos em modo kernel. Esses plugins forneciam capacidade de destruição de dados (KillDisk) e sabotagem de sistemas ICS/SCADA, sendo invisíveis para controles baseados em assinatura de código. > [!example] BYOVD - Técnica Widespread em 2024-2025 > A técnica Bring Your Own Vulnerable Driver (BYOVD) tornou-se epidêmica em 2024-2025, com múltiplos grupos - incluindo operadores de ransomware como LockBit, BlackCat/ALPHV e grupos nacionais - usando drivers legítimos e assinados (mas vulneráveis) como `mhyprot2.sys` (anti-cheat do Genshin Impact), `RTCore64.sys` e `WPRO.sys` para obter escrita arbitrária em memória kernel e desabilitar DSE sem necessidade de assinatura própria. > [!example] Pandora - Relevância para LATAM > O malware [[s0664-pandora|Pandora]], identificado em campanhas contra fornecedores da indústria automotiva (incluindo empresas com operações no Brasil e México), utiliza modificações de política de assinatura para carregar seus componentes de espionagem sem acionar proteções do Windows Defender. O Pandora foi associado ao grupo TINWOODSMAN em relatórios da Trend Micro de 2022. ## Attack Flow ```mermaid graph TB A[Adversário com privilégios elevados] --> B{Plataforma alvo} B --> B1[Windows] B --> B2[macOS] B1 --> C[Método de modificação Windows] C --> C1[bcdedit TESTSIGNING ON] C --> C2[bcdedit nointegritychecks ON] C --> C3[BYOVD - driver vulnerável legítimo] C3 --> C4[Escrita em g_CiOptions no kernel] C --> C5[Modificação de chaves de registro WDAC/AppLocker] C1 & C2 & C4 & C5 --> D[DSE desabilitado ou política relaxada] B2 --> E[Método de modificação macOS] E --> E1[csrutil disable - Recovery Mode] E --> E2[Modificação de variáveis NVRAM] E1 & E2 --> F[SIP desabilitado] D & F --> G[Carga de código não assinado] G --> G1[Driver / rootkit em modo kernel] G --> G2[DLL maliciosa sem assinatura] G --> G3[Extensão de kernel não notarizada] G1 & G2 & G3 --> H[Execução com máximos privilégios] H --> I[Objetivos do adversário] I --> I1[Evasão total de EDR] I --> I2[Persistência em nível kernel] I --> I3[Interceptação de chamadas de sistema] ``` ## Exemplos de Uso > [!example] Turla - Rootkits em Modo Kernel > O grupo [[g0010-turla|Turla]], associado ao serviço de inteligência russo FSB, documentadamente usa a modificação de políticas de assinatura de código para carregar seus rootkits em modo kernel em alvos de espionagem. O malware [[s0009-hikit|Hikit]], associado ao grupo, utiliza a técnica BYOVD para obter escrita em memória kernel e modificar `g_CiOptions`, permitindo o carregamento de drivers não assinados que interceptam chamadas de sistema para ocultar arquivos, processos e conexões de rede. ## Detecção > [!tip] Estrategia de Detecção > Modificações de política de assinatura de código são eventos extremamente raros em operações legítimas de produção - qualquer ocorrência fora de ambientes de desenvolvimento deve ser investigada imediatamente como incidente de alta severidade. Priorize alertas em tempo real sobre execução de `bcdedit.exe` com parâmetros de modificação de políticas de integridade. **Sigma - bcdedit.exe Modificando Política de Integridade de Código** ```yaml title: Modificação de Política de Assinatura de Código via bcdedit status: stable logsource: category: process_creation product: windows detection: selection: Image|endswith: '\bcdedit.exe' CommandLine|contains: - 'TESTSIGNING' - 'nointegritychecks' - 'loadoptions' condition: selection level: high tags: - attack.defense_evasion - attack.t1553.006 ``` **Sigma - csrutil Desabilitado no macOS** ```yaml title: SIP Desabilitado via csrutil no macOS status: experimental logsource: category: process_creation product: macos detection: selection: Image|endswith: '/csrutil' CommandLine|contains: 'disable' condition: selection level: critical tags: - attack.defense_evasion - attack.t1553.006 ``` **Sigma - Driver Vulnerável Carregado (BYOVD)** ```yaml title: Carregamento de Driver com Hash Conhecido Vulnerável (BYOVD) status: experimental logsource: category: driver_load product: windows detection: selection: Hashes|contains: - 'sha256=9a5c4b37d5af4bd9e24e665e91a6c28e11b9b80e' - 'sha256=0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5' condition: selection level: critical tags: - attack.defense_evasion - attack.t1553.006 - attack.privilege_escalation - attack.t1068 ``` **Fontes de dados recomendadas:** - Windows Event Log - System (Event IDs 7045, 7040 para instalação de serviços/drivers) - Sysmon Event ID 6 - Driver Load (com hash de driver) - Logs de criação de processos para `bcdedit.exe`, `powershell.exe` com cmdlets de Secure Boot - macOS Unified Log - `kernel` subsystem para eventos de carregamento de kext - Microsoft Defender for Endpoint - alertas de BYOVD e modificação de DSE - LOLBAS/LOLDRIVERS database - lista atualizada de drivers legítimos vulneráveis conhecidos ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1026 | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Restrinjá severamente quem pode executar `bcdedit.exe` com parâmetros de política de integridade. Em ambientes corporativos, use AppLocker ou WDAC para bloquear execução de bcdedit fora de contextos administrativos aprovados. No macOS, limite quem pode reiniciar em Recovery Mode. Implante autenticação multifator para todos os acessos administrativos. | | M1046 | [[m1046-boot-integrity\|M1046 - Boot Integrity]] | Habilite Secure Boot em todos os endpoints. O Secure Boot impede modificações no bootloader que alterariam políticas de integridade de código antes do SO inicializar. No Windows, combine com UEFI Secure Boot + Microsoft Pluton (em hardware compatível) para proteção adicional. No macOS, habilite o Modo de Segurança Completo (Full Security) nas configurações de Startup Security Utility. | | M1024 | [[m1024-restrict-registry-permissions\|M1024 - Restrict Registry Permissions]] | Restrinjá permissões de escrita nas chaves de registro que controlam políticas de WDAC, AppLocker e Code Integrity. Monitore modificações nessas chaves via auditoria de objetos do Windows. Chaves críticas incluem `HKLM\SYSTEM\CurrentControlSet\Control\CI\Config` e chaves relacionadas a políticas de integridade de código. | ## Contexto Brasil/LATAM > [!warning] Relevância para Ambientes Corporativos e Industriais na LATAM > A técnica T1553.006, embora técnicamente avançada, tornou-se mais acessível com a proliferação de ferramentas BYOVD prontas para uso em fóruns de crime cibernético. Grupos de ransomware operando no Brasil - incluindo operadores afiliados ao LockBit, BlackCat e Medusa - adotaram BYOVD como método padrão para desabilitar EDRs antes de executar o payload de criptografia. O contexto brasileiro apresenta desafios específicos: **Ambientes de desenvolvimento desprotegidos**: É comum em empresas brasileiras de desenvolvimento de software que ambientes de desenvolvimento sejam configurados com Test Signing Mode habilitado por conveniência - e que essas configurações migrem para servidores de produção sem hardening adequado. Isso cria uma superfície de ataque desnecessária. **Hardware legado sem Secure Boot**: Grande parte do parque de servidores e estações de trabalho em uso no Brasil - especialmente em governo e educação - não suporta ou não tem Secure Boot habilitado, tornando ineficaz a mitigação M1046 nesses ambientes. A atualização desse parque é um desafio de longo prazo. **Grupos APT com foco em espionagem industrial LATAM**: O [[g0087-apt39|APT39]] tem histórico de alvos em telecomúnicações na América Latina. Operadores de espionagem industrial direcionados ao setor de petróleo e gás (Petrobras e fornecedores), ao setor financeiro e a ministérios governamentais representam o perfil de risco mais elevado para esta técnica na região. Recomendações práticas para o contexto brasileiro: - Audite imediatamente todos os sistemas em produção para verificar se TESTSIGNING ou nointegritychecks estão habilitados - Implante Windows Defender Application Control (WDAC) em modo de auditoria como primeiro passo, progredindo para modo de bloqueio após mapeamento de aplicações legítimas - Subscreva-se ao feed de drivers vulneráveis do projeto LOLDrivers (loldrivers.io) e implante bloqueios baseados em hash para drivers BYOVD conhecidos - Para macOS em ambientes corporativos, use MDM (Jámf, Mosyle) para monitorar e forçar configurações de Secure Boot e SIP ## Threat Actors que Usam - [[g0087-apt39|APT39]] - [[g0010-turla|Turla]] ## Software Associado - [[s0089-blackenergy|BlackEnergy]] (malware) - [[s0009-hikit|Hikit]] (malware) - [[s0664-pandora|Pandora]] (malware) ## Referências - Microsoft Security Blog - "The evolution of BYOVD attacks" (2024) - ESET Research - "Turla: A Cyber-Espionage Group" - rootkit analysis - Trend Micro - "Pandora backdoor used against automotive industry suppliers" - LOLDrivers Project - Catálogo de drivers vulneráveis usados em ataques BYOVD - Apple Platform Security Guide - System Integrity Protection architecture - MITRE ATT&CK - T1553: Subvert Trust Controls - parent technique overview --- *Fonte: MITRE ATT&CK - T1553.006*