# T1562.010 - Downgrade Attack ## Técnica Pai [[t1562-impair-defenses|T1562 - Impair Defenses]] ## Descrição Adversários podem realizar um **ataque de downgrade** para forçar um sistema a operar com versões antigas, vulneráveis ou com suporte reduzido a controles de segurança modernos. Essa técnica explora a compatibilidade retroativa presente em sistemas operacionais, protocolos de rede e plataformas de scripting - um mecanismo projetado para garantir interoperabilidade, mas que se torna uma superfície de ataque quando não gerenciado adequadamente. O princípio central é simples: versões mais antigas de um componente geralmente possuem menos recursos de segurança, menos logging e mais vulnerabilidades conhecidas. Ao forçar o sistema a usar uma versão anterior, o adversário efetivamente desabilita defesas modernas - sem precisar remover ou modificar os controles em si. Isso torna o ataque de downgrade uma forma especialmente furtiva de [[t1562-impair-defenses|Impair Defenses]]. Os alvos mais comuns incluem interpretadores de scripting como o [[t1059-001-powershell|PowerShell]], protocolos de transporte como TLS/SSL e HTTPS, e componentes de boot como o gerenciador de inicialização do Windows (bootmgr). Cada um desses vetores oferece diferentes oportunidades de evasão. ## Como Funciona ### PowerShell - Downgrade de versão para evadir Script Block Logging O PowerShell versão 5 e superior introduziu o **Script Block Logging (SBL)**, que registra o conteúdo completo de scripts executados - incluindo código desobfuscado - no Event Log do Windows (Event ID 4104). Esse recurso é amplamente usado por SOCs e soluções SIEM para detectar execução de código malicioso. O ataque de downgrade consiste em invocar explicitamente o executável `powershell.exe` com a flag `-Version 2`, que força a engine a operar no modo de compatibilidade do PowerShell 2.0 - versão que não possui SBL, AMSI (Antimalware Scan Interface) nem Constrained Language Mode. O adversário então executa scripts maliciosos nesse ambiente degradado, sem deixar rastros nos logs de segurança modernos. Requisito para o ataque: o .NET Framework 2.0 ou 3.5 deve estar instalado no sistema (ainda presente em muitos ambientes corporativos por compatibilidade de aplicativos legados). ### HTTPS para HTTP - Downgrade de protocolo de rede Adversários posicionados como [[t1557-adversary-in-the-middle|Adversário no Meio]] podem interceptar conexões HTTPS e forçar o cliente a aceitar uma conexão HTTP não criptografada, expondo o tráfego em texto claro. Técnicas como SSL stripping exploram o período inicial da negociação TLS para redirecionar para HTTP antes que o canal seguro sejá estabelecido. Isso permite a captura de credenciais, tokens de sessão, comandos C2 e dados exfiltrados via [[t1040-network-sniffing|Network Sniffing]] sem necessidade de quebrar a criptografia. ### Boot Manager - Downgrade para bypass de Secure Boot Em sistemas Windows, adversários com privilégios administrativos podem substituir o gerenciador de boot (`bootmgr`) por uma versão vulnerável mais antiga - uma versão legítima e assinada pela Microsoft, porém com vulnerabilidades conhecidas de bypass do Secure Boot. Como a versão mais antiga ainda possui uma assinatura digital válida, o firmware UEFI a aceita normalmente, permitindo ao adversário desabilitar verificações de integridade do boot e carregar componentes não assinados, como rootkits ou bootkits. A Microsoft tem públicado atualizações para revogar versões vulneráveis do bootmgr via DBX (Forbidden Signatures Database), mas a aplicação dessas revogações em ambientes corporativos costuma ser lenta. ### TLS - Downgrade de versão de protocolo Adversários podem manipular a negociação TLS para forçar o uso de versões antigas (TLS 1.0 ou TLS 1.1) em vez de TLS 1.2 ou 1.3. Versões antigas do TLS possuem vulnerabilidades documentadas (POODLE, BEAST, CRIME) que permitem descriptografia ou injeção de dados. Esse ataque é especialmente relevante em ambientes que ainda mantêm suporte a versões antigas de TLS por compatibilidade. ## Attack Flow ```mermaid graph TB A[Acesso ao Sistema ou Posição de Rede] --> B{Vetor de Downgrade} B --> C[PowerShell - Forçar versão 2.0] B --> D[Rede - SSL Stripping / TLS Downgrade] B --> E[Boot Manager - Substituir por versão vulnerável] B --> F[Protocolo legado - SSH v1, SMBv1, NTLMv1] C --> G[Script Block Logging desabilitado] C --> H[AMSI contornado] D --> I[Tráfego exposto em texto claro] E --> J[Secure Boot bypass - carregamento de código não assinado] F --> K[Exploração de vulnerabilidades em protocolos legados] G --> L[Execução de código malicioso sem rastro em logs] H --> L I --> M[Captura de credenciais e dados via sniffing] J --> N[Instalação de rootkit ou bootkit] K --> O[Relay attacks, pass-the-hash, man-in-the-middle] L --> P[Persistência e movimento lateral sem detecção] M --> P N --> P O --> P ``` ## Exemplos de Uso ### BlackByte Ransomware - Downgrade de driver de segurança O [[s1180-blackbyte-ransomware|BlackByte Ransomware]] empregou uma variante do ataque de downgrade conhecida como **Bring Your Own Vulnerable Driver (BYOVD)**, combinada com downgrade de mecanismos de proteção do kernel. O grupo carregava versões antigas e vulneráveis de drivers legítimos (como o driver `RTCore64.sys` da MSI) para obter privilégios no kernel e desabilitar soluções EDR - incluindo o próprio Windows Defender -, aproveitando vulnerabilidades presentes em versões mais antigas do driver. ### SILENTTRINITY - Downgrade via .NET legado O framework de pós-exploração [[s0692-silenttrinity|SILENTTRINITY]] foi projetado para operar em versões antigas do .NET, aproveitando a falta de controles de segurança modernos (como Enhanced Mitigation Experience Toolkit e AMSI integration) em runtimes mais antigos. Ao carregar payloads via versões legadas do .NET, conseguia contornar detecções baseadas em comportamento de runtime moderno. ### Lazarus Group - Downgrade de SMB para SMBv1 O [[g0032-lazarus-group|Lazarus Group]] e outros atores de nação-estado aproveitaram ambientes com SMBv1 habilitado (legado, sem criptografia e com múltiplas vulnerabilidades críticas como EternalBlue - [[cve-2017-0144|CVE-2017-0144]]) para movimento lateral interno, mesmo em redes que já possuíam SMBv2 e SMBv3 disponíveis. Forçar o cliente a usar SMBv1 durante a negociação de protocolo permitia explorar vulnerabilidades já conhecidas. ## Detecção ### Sigma Rule - PowerShell invocado com flag de versão legada ```yaml title: PowerShell Executado com Flag de Downgrade de Versão status: stable logsource: category: process_creation product: windows detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: - '-Version 2' - '-version 2' - '-v 2' - '-Ve 2' condition: selection falsepositives: - Scripts de compatibilidade legítimos que requerem PowerShell 2 - Testes de válidação de ambiente level: high tags: - attack.defense_evasion - attack.t1562.010 ``` ### Sigma Rule - Bootmgr substituído fora do processo de atualização ```yaml title: Modificação do Gerenciador de Boot do Windows status: experimental logsource: category: file_event product: windows detection: selection: TargetFilename|endswith: - '\bootmgr' - '\bootmgfw.efi' - '\bootx64.efi' filter_trusted: Image|contains: - '\TrustedInstaller.exe' - '\wuauclt.exe' - '\sfc.exe' condition: selection and not filter_trusted level: critical tags: - attack.defense_evasion - attack.t1562.010 - attack.t1542.003 ``` ### Sigma Rule - Detecção de TLS versão legada em logs de proxy ```yaml title: Negociação TLS com Versão Insegura Detectada status: experimental logsource: category: proxy detection: selection: tls.version: - 'TLSv1' - 'TLSv1.0' - 'SSLv3' - 'SSLv2' condition: selection level: medium tags: - attack.defense_evasion - attack.t1562.010 - attack.t1040 ``` ### Indicadores adicionais de detecção - **Event ID 400** (PowerShell Engine Lifecycle): monitorar campos `EngineVersion` menores que `5.0` no log `Windows PowerShell`. - **Ausência de Event ID 4104** (Script Block Logging): a falta de logs de execução de script em um ambiente onde powershell.exe foi invocado é um indicador de downgrade. - **Monitoramento de DBX**: verificar periodicamente se a revogação de bootloaders vulneráveis está aplicada via política de Secure Boot. - **Inventário de versões de protocolo**: auditar regularmente quais versões de TLS, SMB e outros protocolos estão ativas em dispositivos de rede. ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1054 | [[m1054-software-configuration\|M1054 - Software Configuration]] | Desabilitar versões legadas de PowerShell (.NET 2.0/3.5 removido ou bloqueado por política), desabilitar SMBv1 via Group Policy, e configurar TLS mínimo como 1.2 em todos os serviços e clientes | | M1042 | [[m1042-disable-or-remove-feature-or-program\|M1042 - Disable or Remove Feature or Program]] | Remover o .NET Framework 2.0 e 3.5 de sistemas onde compatibilidade legada não é necessária, eliminando o pré-requisito para downgrade do PowerShell | ### Medidas complementares - Habilitar **PowerShell Constrained Language Mode** via AppLocker ou WDAC para limitar o que pode ser executado mesmo em versões legadas. - Aplicar **Windows Defender Credential Guard** para proteger credenciais mesmo em cenários de downgrade de protocolo de autenticação. - Configurar **revogação de bootloaders vulneráveis** via atualização do DBX no firmware UEFI. - Monitorar via **Sysmon Event ID 1** todas as invocações de `powershell.exe` com análise de linha de comando. - Implementar **HTTP Strict Transport Security (HSTS)** para prevenir downgrade de HTTPS para HTTP. ## Contexto Brasil/LATAM O ataque de downgrade é particularmente relevante no contexto brasileiro e latino-americano por razões estruturais: **Legado tecnológico**: Ambientes corporativos e governamentais no Brasil frequentemente operam com sistemas legados - especialmente em setores como financeiro (mainframes), saúde (TISS, sistemas hospitalares) e governo (integração com sistemas do SERPRO, Receita Federal). Esses ambientes geralmente exigem compatibilidade retroativa que mantém protocolos e versões antigas ativos, criando uma superfície de ataque ideal para downgrade. **PowerShell em campanhas de malware bancário**: Grupos que operam no Brasil - como os responsáveis por [[s0531-grandoreiro|Grandoreiro]], [[mekotio|Mekotio]] e [[s0528-javali|Javali]] - utilizam extensivamente PowerShell em suas cadeias de infecção. O downgrade para PowerShell 2.0 tem sido observado em variantes recentes para evadir soluções de segurança brasileiras que dependem de Script Block Logging para detecção. **Ransomware e SMBv1**: Incidentes de ransomware no Brasil - incluindo ataques ao setor de saúde e ao governo estadual - frequentemente exploram SMBv1 para movimento lateral interno, aproveitando a prevalência de sistemas Windows 7 e Windows Server 2008 em ambientes que ainda não completaram ciclos de atualização. **Setor financeiro e TLS**: O setor financeiro brasileiro, regulado pelo Banco Central, exige TLS 1.2 mínimo desde 2020, mas a transição completa ainda não ocorreu em todos os elos da cadeia - especialmente em parceiros e fornecedores de menor porte, criando vetores para ataques de downgrade em integrações B2B. ## Referências - MITRE ATT&CK - T1562.010 (versão 16.2) - Microsoft Security Blog - PowerShell Script Block Logging e evasão via downgrade - SANS ISC - Detecção de PowerShell 2.0 downgrade em ambientes corporativos - Red Canary - Downgrade attack patterns na telemetria de endpoints Windows - Secureworks - BlackByte Ransomware: análise técnica de BYOVD e downgrade de drivers - NIST SP 800-52 Rev. 2 - Guidelines for TLS implementations *Fonte: MITRE ATT&CK - T1562.010*