O que Análise de Amostras de Bootkit e Rootkit faz?
Quando Usar
- Um sistema apresenta sinais de comprometimento que persistem mesmo após a reinstalação do sistema operacional
- Antivírus e EDR não conseguem detectar malware apesar de evidências claras de comprometimento
- O UEFI Secure Boot foi desabilitado ou apresenta violações de integridade
- A análise de memória revela comportamento de rootkit (processos ocultos, chamadas de sistema hookadas)
- Investigação de ameaças de nível estatal conhecidas por deploy de bootkits (APT28, APT41, Equation Group)
Não use para malware padrão de modo de usuário; bootkits e rootkits operam em um nível fundamentalmente diferente, exigindo técnicas de análise especializadas.
Pré-requisitos
- Ferramentas de imageamento de disco (dd, FTK Imager) para adquirir setores MBR/VBR
- UEFITool para análise e extração de módulos de volumes de firmware UEFI
- chipsec para avaliação de segurança de firmware em nível de hardware
- Ghidra com suporte a x86 modo real e 16 bits para análise de código MBR
- Volatility 3 para detecção de artefatos de rootkit em nível de kernel
- Live USB Linux inicializável para análise offline do sistema
Fluxo de Trabalho
Passo 1: Adquirir Setores de Boot e Firmware
Extraia MBR, VBR e firmware UEFI para análise offline:
# Adquirir MBR (primeiros 512 bytes do disco)
dd if=/dev/sda of=mbr.bin bs=512 count=1
# Adquirir primeira trilha (geralmente contém código de bootkit além do MBR)
dd if=/dev/sda of=first_track.bin bs=512 count=63
# Adquirir VBR (Volume Boot Record - primeiro setor da partição)
dd if=/dev/sda1 of=vbr.bin bs=512 count=1
# Adquirir Partição de Sistema UEFI
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/
# Despejar firmware UEFI (requer chipsec ou flashrom)
# Usando chipsec:
python chipsec_util.py spi dump firmware.rom
# Usando flashrom:
flashrom -p internal -r firmware.rom
# Verificar integridade do despejo de firmware
sha256sum firmware.rom
Passo 2: Analisar MBR/VBR para Código de Bootkit
Examine o código do setor de boot para modificações maliciosas:
# Desmontar código MBR (modo real de 16 bits)
ndisasm -b16 mbr.bin > mbr_disasm.txt
# Comparar MBR com MBR conhecido do Windows
# MBR padrão do Windows começa com: EB 5A 90 (JMP 0x5C, NOP)
# MBR padrão do Windows 10: 33 C0 8E D0 BC 00 7C (XOR AX,AX; MOV SS,AX; MOV SP,7C00h)
python3 << 'PYEOF'
with open("mbr.bin", "rb") as f:
mbr = f.read()
# Verificar assinatura MBR (bytes 510-511 devem ser 0x55AA)
if mbr[510:512] == b'\x55\xAA':
print("[*] Assinatura MBR válida (0x55AA)")
else:
print("[!] Assinatura MBR inválida")
# Verificar assinaturas conhecidas de bootkit
bootkit_sigs = {
b'\xE8\x00\x00\x5E\x81\xEE': "Bootkit TDL4/Alureon",
b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "MBR padrão do Windows (limpo)",
b'\xEB\x5A\x90\x4E\x54\x46\x53': "VBR NTFS padrão (limpo)",
}
for sig, name in bootkit_sigs.items():
if sig in mbr:
print(f"[{'!' if 'limpo' not in name else '*'}] Correspondência de assinatura: {name}")
# Verificar entradas da tabela de partições
print("\nTabela de Partições:")
for i in range(4):
offset = 446 + (i * 16)
entry = mbr[offset:offset+16]
if entry != b'\x00' * 16:
boot_flag = "Ativa" if entry[0] == 0x80 else "Inativa"
part_type = entry[4]
start_lba = int.from_bytes(entry[8:12], 'little')
size_lba = int.from_bytes(entry[12:16], 'little')
print(f" Partição {i+1}: Tipo=0x{part_type:02X} {boot_flag} Início=LBA {start_lba} Tamanho={size_lba} setores")
PYEOF
Passo 3: Analisar Firmware UEFI para Implantes
Inspecione volumes de firmware UEFI em busca de módulos não autorizados:
# Extrair componentes do firmware UEFI com UEFITool
# GUI: Abrir firmware.rom -> Inspecionar volumes de firmware
# CLI:
UEFIExtract firmware.rom all
# Listar todos os drivers DXE (alvo mais comum para implantes UEFI)
find firmware.rom.dump -name "*.efi" -exec file {} \;
# Comparar com lista de módulos de firmware conhecidos como bons
# Cada módulo UEFI tem um GUID - comparar com a linha de base do fabricante
# Verificar configuração do Secure Boot
python chipsec_main.py -m common.secureboot.variables
# Verificar proteção contra gravação da flash SPI
python chipsec_main.py -m common.bios_wp
# Verificar padrões conhecidos de malware UEFI
yara -r uefi_malware.yar firmware.rom
Pontos de Detecção de Bootkit UEFI Conhecidos:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28):
- Flash SPI modificada
- Driver DXE adicionado que solta agente no Windows
- Persiste mesmo com reinstalação do SO e substituição do disco
BlackLotus:
- Explora CVE-2022-21894 para contornar Secure Boot
- Modifica bootloader da Partição de Sistema EFI
- Instala driver de kernel durante a inicialização
CosmicStrand:
- Modifica módulo de firmware CORE_DXE
- Hooka a inicialização do kernel durante o boot
- Injeta shellcode na memória do kernel do Windows
MoonBounce:
- Implante na flash SPI no módulo CORE_DXE
- Função GetVariable() modificada
- Implanta programa de modo de usuário através da cadeia de boot
ESPecter:
- Modifica o Gerenciador de Boot do Windows na ESP
- Aplica patch no winload.efi para desabilitar DSE
- Carrega driver de kernel não assinado
Passo 4: Detectar Comportamento de Rootkit em Nível de Kernel
Analise o sistema em execução em busca de artefatos de rootkit:
# Análise forense de memória para detecção de rootkit
# Detecção de hooks SSDT
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"
# Processos ocultos (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# Diferenciar para encontrar processos ocultos
# Registro de callbacks do kernel (rootkits registram callbacks para filtragem)
vol3 -f memory.dmp windows.callbacks
# Análise de drivers
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules
# Verificar drivers não assinados
vol3 -f memory.dmp windows.driverscan | while read line; do
driver_path=$(echo "$line" | awk '{print $NF}')
if [ -f "$driver_path" ]; then
sigcheck -nobanner "$driver_path" 2>/dev/null | grep "Nao assinado"
fi
done
# Detecção de hooks IDT
vol3 -f memory.dmp windows.idt
Passo 5: Verificação de Integridade do Processo de Boot
Verifique a integridade de toda a cadeia de boot:
# Verificar assinatura do Gerenciador de Boot do Windows
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
# Verificar winload.efi
sigcheck -a C:\Windows\System32\winload.efi
# Verificar ntoskrnl.exe
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Verificar logs de Boot Medido (se TPM estiver disponível)
# Windows: BCDEdit /enum firmware
bcdedit /enum firmware
# Verificar estado do Secure Boot
Confirm-SecureBootUEFI # Cmdlet do PowerShell
# Verificar configuração de boot para adulteração
bcdedit /v
# Procurar alterações na configuração de boot
# testsigning: deve ser No
# nointegritychecks: deve ser No
# debug: deve ser No
bcdedit | findstr /i "testsigning nointegritychecks debug"
Passo 6: Documentar Análise de Bootkit/Rootkit
Compile descobertas abrangentes da análise:
A análise deve documentar:
- Status de integridade do setor de boot (MBR/VBR) com comparação hexadecimal
- Inventário de módulos de firmware UEFI e verificação de integridade
- Status do Secure Boot e quaisquer mecanismos de bypass detectados
- Hooks em nível de kernel (SSDT, IDT, IRP, inline) identificados
- Processos, drivers e arquivos ocultos descobertos
- Mecanismo de persistência (flash SPI, ESP, MBR, driver de kernel)
- Resultados da verificação de integridade da cadeia de boot
- Atribuição a famílias conhecidas de bootkit, se possível
- Etapas de remediação (regravar firmware, reconstruir MBR, substituir hardware)
Conceitos Chave
| Termo | Definição |
|---|---|
| Bootkit | Malware que infecta o processo de boot (MBR, VBR, UEFI) para executar antes do carregamento do sistema operacional, obtendo controle persistente de baixo nível |
| MBR (Master Boot Record) | Primeiros 512 bytes de um disco contendo código de bootstrap e tabela de partições; bootkits MBR substituem este código por loaders maliciosos |
| UEFI (Unified Extensible Firmware Interface) | Interface de firmware moderna substituindo BIOS; bootkits UEFI implantam módulos maliciosos em volumes de firmware ou modificam a ESP |
| Secure Boot | Recurso de segurança UEFI que verifica assinaturas digitais dos componentes de boot; bootkits como BlackLotus exploram vulnerabilidades para contorná-lo |
| Flash SPI | Chip de memória flash que armazena firmware UEFI; bootkits avançados como LoJax e MoonBounce modificam a flash SPI para persistência em nível de firmware |
| DKOM (Direct Kernel Object Manipulation) | Técnica de rootkit que modifica estruturas do kernel para ocultar processos, arquivos e conexões de rede sem hookar funções |
| Driver Signature Enforcement (DSE) | Recurso de segurança do Windows que exige que drivers de kernel sejam assinados digitalmente; bootkits desabilitam o DSE durante o boot para carregar drivers rootkit não assinados |
Ferramentas e Sistemas
- UEFITool: Editor e analisador de imagens de firmware UEFI de código aberto para inspecionar volumes de firmware, drivers e módulos
- chipsec: Framework de avaliação de segurança de hardware da Intel para verificar proteção da flash SPI, Secure Boot e configuração UEFI
- Volatility: Framework de análise forense de memória com plugins de detecção de SSDT, IDT, callbacks e drivers para identificação de rootkits de kernel
- GMER: Ferramenta de detecção de rootkit para Windows que verifica hooks SSDT, hooks IDT, processos ocultos e módulos do kernel modificados
- Bootkits Analyzer: Ferramenta especializada para analisar código MBR/VBR, incluindo desmontagem e comparação com linhas de base conhecidas como boas
Cenários Comuns
Cenário: Investigação de Comprometimento Persistente que Sobrevive à Reinstalação do SO
Contexto: Uma organização reinstalou a imagem de uma estação de trabalho comprometida, mas o mesmo beacon C2 foi retomado em horas. A análise forense padrão de disco não encontra malware. Suspeita-se de bootkit UEFI.
Abordagem:
- Inicialize a partir de um live USB Linux para evitar executar quaisquer componentes do SO comprometido
- Despeje o firmware da flash SPI usando chipsec ou flashrom para análise offline
- Despeje os setores MBR e VBR com dd para análise do setor de boot
- Copie a Partição de Sistema EFI para verificação de integridade do bootloader
- Abra o despejo SPI no UEFITool e compare os GUIDs dos módulos com o firmware fornecido pelo fabricante
- Procure por drivers DXE adicionais ou modificados que não deveriam estar presentes
- Analise quaisquer módulos suspeitos com Ghidra (formato de módulo UEFI x86_64)
- Verifique a configuração do Secure Boot e verifique se há bypasses baseados em explorações
Armadilhas:
- Analisar o sistema enquanto o SO comprometido está em execução (o rootkit pode se esconder da análise ao vivo)
- Não verificar a flash SPI (analisar apenas componentes de boot baseados em disco ignora implantes em nível de firmware)
- Assumir que o Secure Boot previne todos os bootkits (existem bypasses conhecidos, ex.: CVE-2022-21894)
- Não preservar o despejo de firmware original antes de regravar (evidência crítica para atribuição)
Formato de Saída
RELATÓRIO DE ANÁLISE DE BOOTKIT / ROOTKIT
============================================
Sistema: Dell OptiPlex 7090 (UEFI, TPM 2.0)
Versão do Firmware: 1.15.0 (Dell)
Secure Boot: ATIVADO (mas contornado)
Método de Captura: Live USB Linux + despejo SPI com chipsec
ANÁLISE MBR/VBR
Assinatura MBR: Válida (0x55AA)
Código MBR: CORRESPONDE ao MBR padrão do Windows 10 (limpo)
Código VBR: CORRESPONDE ao VBR NTFS padrão (limpo)
ANÁLISE DE FIRMWARE UEFI
Total de Módulos: 287
Esperado pelo Fabricante: 285
Módulos Extras: 2 NÃO AUTORIZADOS
[!] Driver DXE GUID: {ABCD1234-...} "SmmAccessDxe_mod" (MODIFICADO)
Tamanho Original: 12.288 bytes
Tamanho Atual: 45.056 bytes (32KB ADICIONADOS)
Entropia: 7.82 (ALTA - payload criptografado)
[!] Driver DXE GUID: {EFGH5678-...} "UefiPayloadDxe" (NOVO - não está no firmware do fabricante)
Tamanho: 28.672 bytes
Função: Solta agente de persistência durante o boot
INTEGRIDADE DA CADEIA DE BOOT
bootmgfw.efi: MODIFICADO (incompatibilidade de hash, bypass do Secure Boot via CVE-2022-21894)
winload.efi: MODIFICADO (DSE desabilitado no momento do carregamento)
ntoskrnl.exe: LIMPO (mas driver não assinado carregado após o boot)
COMPONENTES DO ROOTKIT DE KERNEL
Driver: C:\Windows\System32\drivers\null_mod.sys (não assinado, oculto)
Hooks SSDT: 3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Processos Ocultos: 2 (PID 6784: beacon.exe, PID 6812: keylog.exe)
Arquivos Ocultos: C:\Windows\System32\drivers\null_mod.sys
ATRIBUIÇÃO
Família: Variante de BlackLotus
Confiança: ALTA (exploração CVE-2022-21894, padrão de modificação de ESP corresponde)
REMEDIAÇÃO
1. Regravar firmware SPI com imagem limpa do fabricante usando programador de hardware
2. Reconstruir a Partição de Sistema EFI a partir de uma mídia de instalação limpa do Windows
3. Reinstalar o sistema operacional a partir de mídia verificada
4. Ativar todas as proteções de gravação de firmware
5. Atualizar o firmware para a versão mais recente (corrige CVE-2022-21894)