Diagnóstico de firmware e hardware em CPU suspeito de rootkit persistente: guia prático

Seu servidor apresenta comportamento anômalo que sobrevive a formatação, reinstalação do sistema operacional e até troca de disco rígido. Processos invisíveis consomem ciclos de CPU, tráfego de rede surge em horários impróprios e ferramentas de monitoramento tradicionais nada detectam. A suspeita recai sobre um rootkit persistente alojado no firmware ou no próprio silício — um cenário que exige investigação além do sistema operacional.

Rootkits de firmware operam em camadas privilegiadas (Ring -3, -2) onde o SO não tem visibilidade. Eles podem residir na BIOS/UEFI, no Intel Management Engine (ME), no AMD Platform Security Processor (PSP), no microcódigo da CPU ou em handlers SMI (System Management Interrupt). A remoção exige conhecimento de arquitetura x86, ferramentas de baixo nível e, muitas vezes, acesso físico ao hardware.

Coleta de evidências e cadeia de custódia

Antes de qualquer intervenção, documente o estado do equipamento: número de série, versão de BIOS/UEFI visível no setup, revisão de microcódigo reportada pelo kernel (dmesg | grep microcode no Linux) e hash do firmware atual. Fotografe etiquetas, anote a posição de jumpers de proteção de escrita (WP#) na placa-mãe e registre quem teve acesso físico. Essa cadeia de custódia garante que achados sejam admissíveis em investigações formais e evita contaminação de evidências.

Use um meio de boot confiável — preferencialmente um Linux forense como CAINE ou Kali em USB com escrita bloqueada — para executar as coletas. Evite bootar o SO comprometido. Se o equipamento for crítico, considere clonar o SPI flash com programador externo antes de qualquer tentativa de flash, preservando o estado original para análise posterior.

Análise de BIOS/UEFI: dump, verificação de assinaturas e drivers EFI

O primeiro alvo é o firmware da placa-mãe. Com chipsec, execute chipsec_main.py -m bios para listar regiões SPI, políticas de proteção (BIOS_CNTL, PR0-PR4) e status do Boot Guard. O comando chipsec_main.py -m tools.uefi.uefitool ajuda a extrair volumes FV e drivers DXE/SMM. Procure por:

Drivers EFI não assinados ou com certificados revogados
Módulos DXE com nomes genéricos (“Setup”, “Runtime”, “Legacy”) mas hashes desconhecidos
Variáveis NVRAM suspeitas (BootOrder alterado, drivers carregados via Boot####)

Compare o dump completo do SPI flash (via flashrom -p internal -r bios_dump.bin) com a versão oficial do fabricante. Diferenças binárias em regiões de código executável são indicadores fortes de implante. Para placas com Intel Boot Guard ativo, a verificação de assinatura OEM impede boot de firmware modificado — mas um atacante com chave privada vazada ou falha na implementação pode contornar.

Microcódigo da CPU: versão, revisão e atualizações

O microcódigo corrige erratas e vulnerabilidades (Spectre, Meltdown, Downfall, Reptar). Um rootkit pode downgradear o microcódigo para reativar falhas exploráveis ou injetar microcódigo malicioso se o processo de verificação de assinatura falhar. No Linux, dmesg | grep microcode mostra a revisão carregada pelo kernel. Em Windows, wmic cpu get MicrocodeVersion retorna o valor.

Consulte o boletim do fabricante (Intel Microcode Revision Guidance, AMD CPU Microcode Patch List) e confira se a revisão instalada é a mais recente para o stepping do processador. O arquivo de microcódigo (intel-ucode/xxxx.dat ou amd-ucode/microcode_amd_famXXh.bin) deve ter hash SHA256 idêntico ao distribuído oficialmente. Atualizações via BIOS/UEFI são preferenciais, pois cobrem o microcódigo carregado antes do SO.

Intel ME / AMD PSP: subsistemas invisíveis

O Intel Management Engine (ME) e o AMD PSP são microcontroladores dedicados com firmware próprio, acesso DMA à memória principal, interface de rede independente e execução fora do controle da CPU x86. Comprometimento aqui oferece persistência absoluta. A verificação exige:

Identificar a versão do ME/PSP via chipsec (chipsec_main.py -m me ou chipsec_main.py -m amd.psp)
Baixar o firmware correspondente do Intel ME System Tools ou do repositório AMD PSP
Comparar hashes SHA256 das regiões FTPR (ME) ou PSP directory
Verificar se o ME está em modo “Manufacturing” ou “Recovery” (indicadores de violação)

Se hashes divergirem, a remoção exige flash do firmware ME/PSP via ferramentas OEM (Intel Flash Image Tool, AMD PSP Recovery) ou programador SPI externo com imagem verificada. Nota: alguns laptops corporativos permitem desativar o ME via HAP bit (High Assurance Platform), mas isso exige BIOS desbloqueada.

System Management Mode (SMM) e handlers SMI

O SMM é o modo mais privilegiado do x86 (Ring -2). Handlers SMI maliciosos podem interceptar operações de disco, rede, teclado e criptografia, tudo invisível ao SO e hipervisores. Chipsec expõe a tabela de handlers SMI (chipsec_main.py -m smm) e verifica se o SMRAM está travado (bits D_LCK=1, D_OPEN=0 no registo SMRAMC).

Sinais de alerta:

Handlers SMI em endereços fora da região SMRAM declarada
Múltiplos handlers para o mesmo SMI (encadeamento suspeito)
SMRAM não travada após POST (permite injeção de código)
Uso de SMI para comunicação oculta (ex.: exfiltração via portas I/O reservadas)

A mitigação passa por BIOS com proteção SMM adequada (SMM_BWP, SMM_CPU_SAVE_EN) e verificação de assinatura de drivers SMM (SMM Driver Signing). Em hardware moderno, o Intel TXT / AMD SKINIT mede o lançamento do hypervisor/SO e atesta integridade do SMM via TPM.

Validação física e programação externa do SPI flash

Quando proteções de escrita por software falham (WP# desativado por jumper, BIOS_CNTL limpo, PRx registers zerados), a única via confiável é programador externo. Clips SOIC-8/SOIC-16 conectados a CH341A, Raspberry Pi GPIO (flashrom -p linux_spi) ou Dediprog SF600 permitem dump e flash do SPI sem depender da CPU.

Procedimento mínimo:

Desligar equipamento, remover bateria CMOS
Identificar CI SPI (Winbond 25Q64, MX25L128, etc.) e pinagem
Conectar clip com alimentação 3.3V do programador (não alimentar a placa)
Fazer 3 dumps consecutivos e confirmar hash idêntico (regra dos 3 dumps)
Analisar dumps com UEFITool, binwalk, strings, YARA rules para firmware malicioso
Se limpo, gravar firmware OEM verificado; se infectado, limpar regiões suspeitas e gravar
Validar boot e re-verificar proteções de escrita (BIOS_CNTL, PRx, WP#)

Essa etapa exige habilidade de solda/clipagem e esquemas da placa-mãe. Para ambientes corporativos, manutenção empresarial em De Cpu Sao Paulo oferece infraestrutura de laboratório com programadores profissionais e cadeia de custódia documentada.

Correlação com postura de defesa em profundidade

A investigação de firmware não substitui controles de rede, endpoint e identidade — ela os complementa. Um rootkit de firmware que exfiltra dados via ME ainda precisa de canal de comando-e-controle (C2) na rede. Segmentação de rede, monitoramento de tráfego anômalo em VLANs de gerenciamento e políticas de Zero Trust limitam o dano mesmo se o firmware estiver comprometido. Para referência sobre segmentação física, veja boas-praticas-de-ciberseguranca-para-pequenas-empresas e como-proteger-sua-empresa-contra-ransomware.

Mantenha inventário de versões de firmware aprovadas (baseline), automatize coleta de hashes via scripts agendados (chipsec em modo headless) e integre alertas ao SIEM. A detecção precoce de drift de firmware reduz janela de exposição de meses para horas.

Rootkits em firmware são raros, mas de alto impacto. A combinação de dump forense, verificação criptográfica, análise de SMM/ME/PSP e programação externa forma o conjunto mínimo para diagnóstico confiável. Documente cada passo, preserve evidências e trate o hardware como cena de crime — porque, nesse nível, ele é.

Checklist prático

Coletar hash SHA256 da BIOS/UEFI atual via chipsec ou flashrom Comparar revisão de microcódigo (CPUID) com boletim do fabricante Verificar status do Intel Boot Guard / AMD Platform Secure Boot Analisar drivers EFI e aplicações UEFI com UEFITool em busca de executáveis não assinados Executar chipsec_main.py -m smm para inspecionar handlers SMI e locks de SMRAM Validar versão e hash do firmware Intel ME / AMD PSP contra repositório oficial Confirmar proteção de escrita do SPI flash (WP# pin, BIOS_CNTL, PRx registers) Registrar cadeia de custódia do equipamento e documentar todos os achados com timestamps Se indicado, usar programador externo para dump completo do SPI flash e comparação binária

0 de 9 concluídos

Perguntas frequentes

Como saber se um rootkit está no firmware da CPU e não no sistema operacional?

Rootkits em firmware sobrevivem à reinstalação do SO e formatação de disco. Se o comportamento malicioso persiste após limpeza completa do armazenamento e reinstalação do zero, o comprometimento provavelmente reside na BIOS/UEFI, no microcódigo ou no Intel ME/AMD PSP.

Quais ferramentas permitem dump da BIOS/UEFI para análise offline?

Chipsec, flashrom e UEFITool são as principais. Chipsec oferece módulos específicos para verificação de SMM, Boot Guard e políticas de assinatura. Flashrom permite leitura/gravação direta do SPI flash. UEFITool ajuda a dissecar volumes e drivers EFI suspeitos.

O Intel Management Engine ou AMD PSP podem esconder rootkits?

Sim. Esses subsistemas operam independentemente da CPU principal e têm acesso total à memória e rede. Comprometimento do ME/PSP permite persistência invisível ao SO. A verificação exige firmware assinado pelo fabricante e comparação de hashes com versões conhecidas.

Como validar a integridade do microcódigo da CPU?

Compare a revisão do microcódigo reportada pelo CPUID (via dmesg no Linux ou ferramentas como cpuid) com a última versão publicada pelo fabricante. Atualizações de microcódigo são distribuídas via BIOS/UEFI e pacotes de kernel; hashes SHA256 dos arquivos .dat ou .bin devem conferir com fontes oficiais.

Rootkit em firmware pode ser removido apenas com flash da BIOS?

Nem sempre. Se o SPI flash estiver protegido por hardware (WP# pin, Boot Guard ativo) ou se o rootkit infectou o Intel ME/AMD PSP, o flash convencional falha. Nesses casos, programador externo (CH341A, Dediprog) com clip SOIC-8 e verificação de assinaturas OEM são necessários.

Quais sinais indicam comprometimento de hardware via SMM (System Management Mode)?

Interrupções SMI inexplicáveis, latência anômala em tempo real, registros SMRAM com valores inesperados e drivers SMM não assinados. Chipsec com módulo 'smm' detecta handlers SMI maliciosos e verifica se o SMRAM está travado (D_LCK e D_OPEN bits).