Analisando Persistência de Bootkit UEFI
Quando Usar
- Um sistema comprometido restabelece comunicação C2 após reinstalação do SO ou substituição do disco
- O Secure Boot foi adulterado, desabilitado ou mostra um registro inesperado de Machine Owner Key (MOK)
- A verificação de integridade do firmware falha em relação às linhas de base fornecidas pelo fornecedor
- A análise forense de memória revela componentes de rootkit carregados durante a fase inicial de boot
- Investigação de campanhas de ameaça persistente avançada (APT) conhecidas por implantar bootkits UEFI
- Auditoria da postura de segurança do firmware para fortalecimento de endpoints corporativos
Não use para bootkits MBR/VBR padrão em sistemas BIOS legados sem UEFI; use análise de bootkit MBR/VBR.
Pré-requisitos
- framework chipsec para dump de SPI flash, inspeção de variáveis UEFI e módulos de segurança de firmware
- UEFITool / UEFIExtract para análise de volumes de firmware e extração de drivers DXE
- Python 3.8+ com módulos struct, hashlib, subprocess e os
- Live USB Linux inicializável para análise offline (evite executar o SO comprometido)
- Volatility 3 para análise forense de memória de artefatos da fase de boot
- YARA com conjuntos de regras para malware UEFI para detecção baseada em padrões
- Acesso às linhas de base de firmware do fornecedor para comparação de integridade
Fluxo de Trabalho
Etapa 1: Dump do Firmware SPI Flash
Adquira o firmware UEFI do chip SPI flash para análise offline:
# Usando chipsec para despejar o conteúdo do SPI flash
python chipsec_util.py spi dump firmware_dump.rom
# Usando flashrom como alternativa
flashrom -p internal -r firmware_dump.rom
# Verificar a integridade do dump
sha256sum firmware_dump.rom
# Ler informações do descritor do SPI flash
python chipsec_util.py spi info
# Verificar permissões de acesso à região do SPI flash
python chipsec_main.py -m common.spi_access
# Verificar se a proteção contra gravação da BIOS está ativada
python chipsec_main.py -m common.bios_wp
# Verificar o bloqueio do controlador SPI flash
python chipsec_main.py -m common.spi_lock
Etapa 2: Inspecionar Variáveis UEFI
Enumere e analise as variáveis UEFI em busca de modificações não autorizadas:
# Listar todas as variáveis UEFI em um sistema ativo
python chipsec_util.py uefi var-list
# Listar variáveis UEFI de um dump de SPI flash
python chipsec_util.py uefi var-list-spi firmware_dump.rom
# Ler variáveis específicas do Secure Boot
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F
# Despejar bancos de chaves UEFI para análise
python chipsec_util.py uefi keys
# Verificar o módulo de configuração do Secure Boot
python chipsec_main.py -m common.secureboot.variables
Etapa 3: Analisar a Partição do Sistema EFI (ESP)
Inspecione a ESP em busca de componentes de boot não autorizados ou modificados:
# Montar a ESP (geralmente a primeira partição FAT32, ~100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp
# Listar todos os arquivos na ESP com timestamps
find /mnt/esp -type f -exec ls -la {} \;
# Verificar indicadores do BlackLotus - diretório personalizado em ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null
# Verificar a assinatura do Windows Boot Manager
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi
# Hash de todos os binários EFI para comparação com valores conhecidos como bons
find /mnt/esp -name "*.efi" -exec sha256sum {} \;
# Verificar arquivos .efi não autorizados fora dos diretórios padrão
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"
# Procurar por grubx64.efi implantado pelo BlackLotus
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;
# Examinar logs do MeasuredBoot em busca de anomalias (Windows)
# Logs localizados em C:\Windows\Logs\MeasuredBoot\
Etapa 4: Escanear o Firmware em Busca de Assinaturas Conhecidas de Bootkit
Analise o dump do firmware em busca de padrões conhecidos de malware UEFI:
# Extrair todos os módulos de firmware com UEFIExtract
UEFIExtract firmware_dump.rom all
# Gerar lista de permissões de módulos de firmware a partir da linha de base do fornecedor
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom
# Comparar o firmware atual com a lista de permissões
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom
# Escanear firmware com regras YARA específicas para UEFI
yara -r uefi_bootkits.yar firmware_dump.rom
# Escanear módulos extraídos individualmente
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;
# Verificar módulo CORE_DXE modificado (alvo de MoonBounce, CosmicStrand)
# Comparar GUID e hash com a linha de base do fornecedor
Etapa 5: Detectar Mecanismos de Bypass do Secure Boot
Verifique técnicas conhecidas de bypass do Secure Boot:
# Verificar se o Secure Boot está ativado
python chipsec_main.py -m common.secureboot.variables
# Verificar proteções do SMM (System Management Mode)
python chipsec_main.py -m common.smm
# Verificar proteção contra gravação da BIOS do SMM
python chipsec_main.py -m common.bios_smi
# No Windows - verificar configuração de boot para indicadores de bypass
bcdedit /enum firmware
bcdedit /v
# Verificar flags testsigning/nointegritychecks/debug
bcdedit | findstr /i "testsigning nointegritychecks debug"
# Verificar se o HVCI (Hypervisor-enforced Code Integrity) não está desabilitado
# BlackLotus define HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# Verificar estado do Secure Boot via PowerShell
# Confirm-SecureBootUEFI retorna True se ativado corretamente
Etapa 6: Realizar Verificação de Integridade da Cadeia de Boot
Verifique todos os componentes da cadeia de boot, do firmware ao kernel:
# Verificar integridade do firmware em relação ao hash do fornecedor
sha256sum firmware_dump.rom
# Comparar com o hash publicado pelo fornecedor
# Verificar assinaturas do bootloader
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Verificar drivers de boot não assinados ou inválidos
sigcheck -u -e C:\Windows\System32\drivers\
# Analisar logs do Measured Boot para entradas inesperadas de EFI_Boot_Services_Application
# Componentes do BlackLotus aparecem como EV_EFI_Boot_Services_Application
# Análise forense de memória para artefatos da fase de boot
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan
Etapa 7: Documentar as Descobertas da Análise de Bootkit UEFI
Compile um relatório de análise abrangente:
O relatório deve incluir:
- Versão do firmware, fornecedor e identificação da plataforma
- Status da proteção do SPI flash (proteção contra gravação, bits de bloqueio, controle de acesso)
- Configuração do Secure Boot e quaisquer indicadores de bypass detectados
- Anomalias em variáveis UEFI (chaves não autorizadas, db/dbx modificados, registro MOK)
- Inventário do conteúdo da ESP com verificação de hash em relação a linhas de base conhecidas como boas
- Comparação do módulo de firmware com a lista de permissões do fornecedor (adicionado, modificado, removido)
- Atribuição de família de bootkit conhecida com nível de confiança
- Resultados da verificação de integridade da cadeia de boot para cada componente
- Etapas de remediação (reflash, rotação de chaves, substituição de hardware)
- Mapeamento MITRE ATT&CK (T1542.001 - System Firmware, T1542.003 - Bootkit)
Conceitos Chave
| Termo | Definição |
|---|---|
| UEFI Bootkit | Malware que persiste no firmware UEFI ou no processo de boot, executando antes do carregamento do sistema operacional e sobrevivendo à reinstalação do SO |
| SPI Flash | Chip de memória flash de interface periférica serial na placa-mãe que armazena o firmware UEFI; bootkits de nível de firmware como LoJax e MoonBounce modificam o conteúdo do SPI flash |
| Partição do Sistema EFI (ESP) | Partição FAT32 contendo bootloaders e drivers EFI; bootkits como BlackLotus e ESPecter modificam arquivos na ESP para persistência |
| Secure Boot | Recurso de segurança UEFI que verifica assinaturas digitais de componentes de boot; pode ser contornado por meio de vulnerabilidades (CVE-2022-21894) ou registro MOK |
| Driver DXE | Driver do Driver Execution Environment carregado durante o boot UEFI; implantes de firmware injetam drivers DXE maliciosos que são executados antes do SO |
| Machine Owner Key (MOK) | Chave de Secure Boot instalável pelo usuário; BlackLotus registra MOKs controlados pelo atacante para assinar bootloaders maliciosos |
| chipsec | Framework de avaliação de segurança de plataforma Intel para analisar SPI flash, variáveis UEFI, Secure Boot e configurações de segurança de hardware |
| HVCI | Hypervisor-enforced Code Integrity, um recurso de segurança do Windows que os bootkits desabilitam para carregar drivers de kernel não assinados |
Ferramentas e Sistemas
- chipsec: Framework Intel para despejar SPI flash, ler variáveis UEFI, verificar proteção contra gravação de firmware e auditar configuração do Secure Boot
- UEFITool: Analisador de imagem de firmware UEFI de código aberto para inspecionar volumes de firmware, extrair drivers DXE e comparar GUIDs de módulos
- sigcheck: Utilitário Sysinternals para verificar assinaturas digitais de binários EFI e componentes da cadeia de boot
- flashrom: Programador de SPI flash de código aberto para ler e gravar chips de firmware em plataformas suportadas
- YARA: Mecanismo de correspondência de padrões usado com conjuntos de regras específicas para UEFI para detectar assinaturas de bootkit conhecidas em dumps de firmware
Cenários Comuns
Cenário: Investigando Comprometimento Persistente que Sobrevive à Reinstalação do SO
Contexto: Um endpoint corporativo foi reintegrado após uma violação confirmada, mas a mesma beaconing C2 foi retomada em horas. O endpoint tem firmware UEFI com Secure Boot ativado e um chip TPM 2.0. A equipe de segurança suspeita de um implante de nível UEFI semelhante ao BlackLotus ou LoJax.
Abordagem:
- Inicialize o sistema a partir de um live USB Linux confiável para evitar a execução de quaisquer componentes do SO comprometido
- Despeje o firmware SPI flash usando
chipsec_util.py spi dumppara análise offline - Monte a ESP e faça o hash de todos os arquivos
.efipara comparação com valores conhecidos como bons de hardware idêntico - Verifique o diretório
ESP:/system32/(indicador do BlackLotus) e ogrubx64.efinão autorizado - Extraia módulos de firmware com UEFIExtract e compare o inventário de GUIDs com a linha de base do fornecedor
- Verifique as variáveis do Secure Boot -- procure por registro MOK não autorizado ou db/dbx modificados
- Verifique a proteção contra gravação do SPI flash e os bits de bloqueio usando módulos chipsec
- Escaneie o dump do firmware e os módulos extraídos com regras YARA específicas para UEFI
- Se houver suspeita de BlackLotus, verifique o registro para HVCI desabilitado e logs do MeasuredBoot para entradas anômalas
Armadilhas:
- Executar a análise a partir do SO comprometido (componentes rootkit se escondem da análise ativa)
- Apenas verificar a ESP sem examinar o firmware SPI flash (perde implantes de nível de firmware como LoJax, MoonBounce)
- Assumir que o Secure Boot impede todos os bootkits (existem CVE-2022-21894 e outros bypasses)
- Não preservar o dump de firmware original antes da remediação (evidência forense crítica)
- Reflash do firmware sem verificar se a imagem do fornecedor é autêntica e não modificada
Formato de Saída
RELATÓRIO DE ANÁLISE DE PERSISTÊNCIA DE BOOTKIT UEFI
============================================================
Sistema: Lenovo ThinkPad X1 Carbon Gen 11
Firmware: N3HET82W (1.54) - Lenovo UEFI BIOS
Plataforma: Intel 13th Gen (Raptor Lake)
TPM: 2.0 (Infineon SLB 9672)
Secure Boot: ATIVADO (BYPASSADO via CVE-2022-21894)
Método de Análise: Live USB Linux + chipsec + UEFITool
STATUS DA PROTEÇÃO DO SPI FLASH
Proteção contra Gravação da BIOS: DESATIVADA [!]
Bloqueio do SPI Flash (FLOCKDN): DEFINIDO [OK]
Proteção contra Gravação da BIOS do SMM: DESATIVADA [!]
Intervalos Protegidos do SPI: Região 0 apenas (descritor)
ANÁLISE DE VARIÁVEIS UEFI
SecureBoot: Ativado (valor=1)
SetupMode: Desativado (valor=0)
PK: Lenovo Ltd. (legítimo)
KEK: Microsoft + Lenovo (legítimo)
db: MODIFICADO - contém entrada não autorizada [!]
[!] Certificado desconhecido: CN=Secure Boot Signing, O=Unknown
[!] Não presente no db da linha de base do fornecedor
MOK: 1 chave não autorizada registrada [!]
[!] MOK registrado: CN=shim, autoassinado, não do fornecedor da distribuição
ANÁLISE DA PARTIÇÃO ESP
Total de binários EFI: 12
Verificados (assinados): 9
Modificados (hash incompatível): 2 [!]
Não autorizados: 1 [!]
[!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFICADO
SHA-256 Esperado: a3f2c8...
SHA-256 Atual: 7b1e4d...
Assinatura: Válida (assinado com MOK não autorizado)
[!] EFI/Microsoft/Boot/grubx64.efi - NÃO AUTORIZADO
SHA-256: e9c1a7...
Não presente na linha de base do fornecedor
Corresponde à assinatura do loader de estágio 2 do BlackLotus
[!] Diretório system32/ presente na ESP (artefato do BlackLotus)
Diretório vazio (arquivos excluídos pós-instalação)
ANÁLISE DE MÓDULOS DE FIRMWARE
Total de módulos de firmware: 312
Módulos de linha de base do fornecedor: 312
Módulos adicionados: 0
Módulos modificados: 0
Integridade do SPI flash: LIMPO (nenhum implante de nível de firmware detectado)
ATRIBUIÇÃO DE BOOTKIT
Família: BlackLotus
Confiança: ALTA
Persistência: Baseada em ESP (não SPI flash)
Método de Bypass: CVE-2022-21894 (baton drop)
MITRE ATT&CK T1542.003 (Bootkit), T1553.006 (Code Signing Policy Modification)
INDICADORES DE COMPROMETIMENTO
- Diretório ESP:/system32/ (vazio, artefato pós-limpeza)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (não autorizado, loader do BlackLotus)
- bootmgfw.efi modificado (reassinado com MOK do atacante)
- HVCI desabilitado via registro: DeviceGuard\...\Enabled = 0
- Registro MOK não autorizado no armazenamento de variáveis UEFI
- Log do MeasuredBoot mostra EV_EFI_Boot_Services_Application para grubx64.efi
REMEDIAÇÃO
1. Substitua bootmgfw.efi por uma cópia autêntica da mídia de instalação do Windows
2. Exclua grubx64.efi não autorizado e o diretório system32/ da ESP
3. Redefina as chaves do Secure Boot para os padrões de fábrica (limpe MOK, restaure PK/KEK/db)
4. Ative a proteção contra gravação da BIOS e verifique os bits de bloqueio do SPI flash
5. Aplique a atualização de firmware para a versão mais recente (corrige CVE-2022-21894)
6. Ative o HVCI e verifique via Política de Grupo
7. Reimporte apenas certificados confiáveis no banco de dados do Secure Boot
8. Monitore logs do MeasuredBoot para carregamento anômalo de componentes de boot