Análise Estática de Malware

Nota 02 do capítulo 25, dedicada à inspeção do binário sem executá-lo, complemento direto da triagem da nota 01.
A análise estática extrai capacidades, configurações aparentes e IOCs do arquivo parado, com custo baixo e risco próximo de zero.
Alimenta a detonação da nota 03, a engenharia reversa da nota 04 e as regras YARA da nota 05, e dialoga com a pirâmide de indicadores do capítulo 03.

1. Contexto e Posicionamento na Biblioteca

A análise estática examina o artefato sem execução, trabalhando sobre bytes, estruturas e metadados que já estão no arquivo. É o método com melhor relação entre custo e retorno no começo do caso: não exige laboratório montado, não arrisca contaminação e produz insumos imediatos para detecção, como strings, imports, seções e assinaturas de empacotador. Sua limitação estrutural é a ofuscação, porque tudo o que o malware cifra, empacota ou gera em tempo de execução simplesmente não está visível no arquivo parado.

O posicionamento na esteira do capítulo é claro: a triagem da nota 01 entregou tipo real, hashes e status de empacotamento; a análise estática aprofunda essas informações até o limite do que o arquivo revela sobre si mesmo. O que sobra de dúvida define o script da detonação na nota 03, e os padrões estáveis observados aqui se transformam em regras YARA na nota 05. Analistas de CTI raramente precisam ser engenheiros reversos completos, mas precisam dominar a camada estática, pois é dela que saem os IOCs que alimentam o capítulo 03 e as detecções do capítulo 18.

2. Strings: A Camada Mais Rápida de Evidência

Strings são sequências legíveis embutidas no binário: URLs, caminhos de registro, nomes de mutex, mensagens de erro, caminhos de PDB e dados de configuração. A extração é trivial, e o valor depende da leitura com hipótese: strings de usuário, caminhos do compilador e imports de runtime aparecem em todo binário legítimo, e o analista procura o que difere. O utilitário strings cobre o caso simples, com as opções -n para filtrar ruído curto, -a para varrer o arquivo inteiro e -el para strings wide, usadas em binários Windows que carregam texto UTF-16.

strings -n 8 -a LDR-2026-0142.bin > strings_ascii.txt
strings -el -n 8 LDR-2026-0142.bin > strings_wide.txt

O FLOSS, da equipe FLARE, automatiza o passo que o strings não alcança: decodificação de strings ofuscadas em tempo de compilação, reconstrução de stack strings montadas byte a byte na pilha e identificação de strings decodificadas em runtime em amostras levemente empacotadas. O comando abaixo direciona a saída para as categorias de maior valor, e a comparação entre o arquivo de strings cruas e o FLOSS costuma revelar exatamente a camada de ofuscação aplicada pelo autor.

floss LDR-2026-0142.bin --only decoded stack tight > floss_output.txt

Nas amostras de referência do capítulo, a leitura combinada já entregou achados produtivos: o mutex Global\Sombra-Mtx-0142, a rota de C2 hxxp://203.0.113.42:8085/gate.php escrita em stack string, e o caminho de PDB C:\Users\dev\source\repos\LdrGate\Release\LdrGate.pdb, que indica ambiente de desenvolvimento e nome de projeto do autor. Caminhos de PDB são particularmente valiosos para agrupamento de campanhas, pois o diretório e o nome de projeto mudam pouco entre builds do mesmo desenvolvedor, apesar de trocas de infraestrutura.

3. Imports: Capacidade Declarada pelo Binário

A Import Address Table lista as funções de bibliotecas do sistema que o binário exige para funcionar, e portanto declara capacidades em alto nível. Um executável que importa VirtualAllocEx e WriteProcessMemory declara manipulação de memória de outro processo; um que importa CryptDecrypt declara decifragem embutida; um que importa InternetOpenUrlA declara comunicação HTTP. A leitura profissional cruza os imports com a hipótese de campanha, e não os trata como lista de suspeição, pois ferramentas legítimas importam as mesmas APIs.

O PEStudio apresenta os imports com classificação automática de funções historicamente associadas a comportamento suspeito, e o Detect It Easy lista bibliotecas e funções em saída estruturável. Em binários que resolvem APIs dinamicamente por GetProcAddress com nomes cifrados, a IAT fica propositalmente vazia, e o esforço migra para a análise dinâmica da nota 03 ou para a engenharia reversa da nota 04, que reconstrói os nomes resolvidos em runtime.

Os artefatos de compilação completam a leitura de capacidades com a leitura de origem: quem compilou, com que ferramenta e quando. Esses metadados raramente identificam o adversário sozinhos, mas sustentam agrupamento de amostras e estimativa de data da campanha, e valem registro sistemático na ficha.

4. Seções PE, Recursos e Entropia

A estrutura de seções do PE conta a história física do binário: onde está o código, onde estão os dados, e onde está a anomalia. O PEStudio e o DIE expõem nome, tamanho virtual, tamanho bruto, entropia e flags de cada seção, e a comparação entre tamanho virtual e tamanho bruto é um dos detectores mais confiáveis de manipulação, pois seções que ocupam espaço virtual sem bytes correspondentes em disco indicam shellcode que só existe em memória. A tabela abaixo resume a leitura das seções da amostra LDR-2026-0142.

A entropia por seção separa código de dado cifrado com precisão suficiente para triagem: código compilado gira entre 5 e 6,5, recursos e imagens em torno de 6 a 7,4, e blocos cifrados ou comprimidos acima de 7,5. A seção .sxdata da tabela, com nome fora do padrão e entropia de 7,86, é o candidato imediato a payload embutido, e a leitura deve prosseguir para os recursos e para a extração desse bloco. O módulo math do YARA automatiza essa leitura em escala, como a nota 05 demonstra.

Recursos são dados embutidos no executável: ícones, versões, diálogos e, no malware, payloads inteiros cifrados. A inspeção usa o PEStudio na aba de resources, e a extração direta pode ser feita com ferramentas de arquivamento, pois recursos seguem estrutura de árvore.

7z l LDR-2026-0142.bin
7z x -ores LDR-2026-0142.bin RT_RCDATA
sha256sum res/RT_RCDATA/102
file res/RT_RCDATA/102

Na amostra de referência, o recurso RCDATA 102 é um PE de 180.224 bytes com SHA-256 próprio, ou seja, o payload de segunda etapa inteiro embutido no loader. Extrair esse recurso antes de qualquer detonação encurta a análise dinâmica: a nota 03 pode detonar direto o payload extraído, e o hash do payload interno se torna IOC imediato para caça no parque corporativo, muitas vezes antes de qualquer sandbox externa processar o arquivo.

5. Assinatura de Packer e Reconstituição do Payload

A identificação do empacotador orienta a estratégia de desempacotamento, e cada família tem caminho próprio. UPX é reversível com a própria ferramenta; ASPack e variantes de compressão cedem a desempacotadores genéricos ou à execução controlada com dump de memória; VMProtect e Themida virtualizam código, e o dump recupera o payload mas não o código protegido, que exige a nota 04. O DIE identifica a maioria dos empacotadores comerciais e, quando falha, os indicadores indiretos da nota 01, entropia e imports mínimos, sustentam a hipótese de packer customizado.

diec -j LDR-2026-0142.bin
pestudio LDR-2026-0142.bin /xml pestudio_report.xml
upx -d -o LDR-2026-0142_unpacked.bin LDR-2026-0142.bin

A regra prática de CTI é não gastar horas quebrando empacotamento na análise estática quando a sandbox da nota 03 entrega o payload desempacotado em minutos. O desempacotamento manual é ferramenta de engenharia reversa, para casos em que a amostra evade sandboxes ou quando a configuração cifrada exige depuração, e a fronteira entre as notas é decisão de eficiência, não de orgulho técnico.

6. Extração de IOCs Estáticos

O fechamento da análise estática é a ficha de IOCs, separada por tipo e marcada com confiança e origem. IOCs estáticos são os observáveis extraídos sem execução: hashes do artefato e do payload interno, caminhos de PDB, mutexes, URIs e endpoints de C2 escritos no binário, chaves de registro referenciadas, nomes de seção não padrão e assinaturas de byte do packer. Cada indicador deve entrar no TIP com contexto da amostra, pois a mesma URL pode ser infraestrutura legítima em outro contexto, orientação do capítulo 03 sobre validação de indicadores.

O padrão de bytes que marca o início do bloco de configuração cifrada é o IOC de maior longevidade da ficha, porque o autor raramente regenera o formato de config entre builds. Esse padrão alimenta diretamente as regras YARA da nota 05 e os extractors de configuração da nota 04, fechando a ponte entre a camada estática e a caracterização de família.

7. Exemplo Consolidado: Análise do Loader LDR-2026-0142 em Etapas

A sequência abaixo consolida o fluxo completo em comandos reproduzíveis, do arquivo bruto à ficha de IOCs, usando a amostra fictícia que serve de fio condutor do capítulo.

# Etapa 1: confirmar identidade herdada da triagem
sha256sum LDR-2026-0142.bin
file -b LDR-2026-0142.bin

# Etapa 2: visao geral de PE, imports e secoes
pestudio LDR-2026-0142.bin /xml relatorio_pestudio.xml
diec -j LDR-2026-0142.bin

# Etapa 3: strings cruas e decodificadas
strings -n 8 -a LDR-2026-0142.bin | sort -u > strings_ascii.txt
floss LDR-2026-0142.bin --only decoded stack > floss_decoded.txt

# Etapa 4: extrair recurso RCDATA com payload embutido
7z x -ores LDR-2026-0142.bin RT_RCDATA
sha256sum res/RT_RCDATA/102
file res/RT_RCDATA/102

# Etapa 5: registrar padrao de bytes do bloco de config para YARA
xxd -s 0x84000 -l 64 LDR-2026-0142.bin

Cada etapa gera evidência registrada: a Etapa 1 confirma que a ficha da nota 01 permanece válida; a Etapa 2 produz a leitura de imports da seção 3 desta nota; a Etapa 3 entrega mutex, rota de C2 e caminho de PDB; a Etapa 4 materializa o payload interno com hash próprio; e a Etapa 5 captura o padrão de bytes que a nota 05 usará como âncora de regra YARA. O tempo total de um analista treinado nesse fluxo fica entre vinte e quarenta minutos por amostra, e o ganho acumulado é o caso inteiro montado antes de qualquer execução.

8. Erros Comuns e Pontos de Atenção

O erro dominante da análise estática é sobrevalorizar strings, tratando qualquer texto suspeito como IOC confirmado. Strings são pistas, não conclusões: um endpoint escrito no binário pode ser isca, canário ou vestígio de biblioteca reaproveitada, e a validação contextual do capítulo 03 é obrigatória antes de disseminação. O erro simétrico é desistir da camada estática em amostras empacotadas, ignorando que metadados, recursos e a própria estrutura de seções sobrevivem ao empacotamento e frequentemente bastam para uma regra YARA preliminar.

Completam a lista os pontos abaixo.

• Analisar strings wide com strings padrão, perdendo metade do texto em binários Windows, quando a opção -el é obrigatória.
• Ignorar o payload extraído de recursos, que costuma ser o artefato de maior valor e pode ter assinatura de família diferente do loader.
• Usar entropia do arquivo inteiro em vez de por seção, número que se dilui e esconde blocos cifrados locais.
• Tratar ausência de imports suspeitos como ausência de capacidade, quando resolução dinâmica de APIs é o caso, e não a exceção.
• Extrair IOCs sem campo de confiança e sem contexto de amostra, contaminando o TIP com indicadores órfãos.
• Copiar configurações aparentes de C2 para bloqueio direto sem verificar se o endereço é infraestrutura legítima de terceiro.

9. Integração com o Restante da Biblioteca

A análise estática é a fábrica de insumos do capítulo: a nota 03 recebe o script de detonação guiado pelas hipóteses levantadas, a nota 04 recebe o bloco de config cifrado e o padrão de bytes para extração definitiva, e a nota 05 recebe as âncoras estáveis para regras YARA. Os IOCs produzidos alimentam o ciclo de vida do capítulo 03, e os padrões de bytes de maior longevidade sustentam caças orientadas a IOC no controle TH.10 do framework CTH.

Na camada de detecção, os artefatos desta nota viram regras YARA no repositório do PRT.5, conteúdos inspecionados no gateway de e-mail do PRT.3 e testes materializados no SIM.4. A disciplina de registrar cada extração com origem, confiança e contexto é o que separa uma análise estática profissional de uma lista de strings colada em relatório, e essa disciplina é a mesma que o capítulo 18 exige para transformar os achados em detecções versionadas e medidas.