Triagem e Classificação de Arquivos

Nota 01 do capítulo 25, que abre a esteira prática de análise técnica de artefatos e campanhas de malware.
A triagem decide, em minutos, o destino de cada amostra: aprofundamento estático, detonação controlada, engenharia reversa ou descarte documentado.
Dialoga com as notas 02 a 05 deste capítulo, com o ciclo de vida de IOCs do capítulo 03 e com os controles de coleta do framework CTH.

1. Contexto e Posicionamento na Biblioteca

Toda campanha investigada por CTI termina, mais cedo ou mais tarde, em um punhado de arquivos: anexo de phishing, loader baixado por macro, payload recuperado de sandbox, dump extraído de memória. A triagem é a etapa que transforma esses arquivos brutos em objetos de análise com identidade, tipo, risco e prioridade definidos. Sem essa disciplina, a equipe gasta horas de análise profunda em amostras irrelevantes ou, pior, manipula artefatos ativos em estações de produção. Esta nota estabelece o fluxo padrão de triagem que as demais notas do capítulo assumem como ponto de partida.

O papel da triagem na biblioteca é o de filtro qualificado entre a coleta de inteligência técnica e a análise aprofundada. O capítulo 02 cobre como os artefatos chegam pelas fontes técnicas, e o capítulo 03 define o que é um IOC e seu ciclo de vida; aqui o foco é o manuseio seguro e a classificação inicial do artefato. A triagem também sustenta a reprodutibilidade: uma ficha preenchida corretamente permite que outro analista retome o caso semanas depois sem repetir conjecturas sobre o que era o arquivo e de onde ele veio.

2. Manuseio Seguro e Ambiente de Triagem

A regra fundamental da triagem é simples e inegociável: nenhum artefato suspeito é aberto ou executado na estação de trabalho do analista. A triagem é uma atividade estática por definição, e qualquer necessidade de interação com o conteúdo deve ser adiada para o ambiente de análise dinâmica da nota 03. O ideal é uma máquina virtual dedicada, isolada da rede corporativa, com pastas compartilhadas desativadas, snapshot limpo e ferramentas de linha de comando instaladas. A amostra transita sempre dentro de um arquivo ZIP protegido com senha padrão combinada pela equipe, prática que reduz disparos acidentais de antivírus em trânsito e impede execução por duplo clique acidental.

O fluxo recomendado de recepção segue a ordem abaixo, e cada etapa gera um campo da ficha de triagem.

• Receber o arquivo em zona de quarentena, preferencialmente por canal que preserve origem, horário e remetente, pois esse contexto alimenta a análise de campanha e a eventual atribuição.
• Calcular os hashes antes de qualquer manipulação, pois o primeiro contato com o arquivo é o momento de menor risco de alteração acidental do binário.
• Renomear o arquivo para um nome interno padronizado, preservando o nome original apenas como campo da ficha, o que reduz execução acidental por associação de extensão.
• Identificar o tipo real por magic bytes e confrontar com a extensão declarada, registrando qualquer divergência como achado analítico, e não como curiosidade.
• Encaminhar o artefato para classificação de risco e definição de rota: descarte documentado, monitoramento de reputação, análise estática ou detonação controlada.

O arsenal mínimo de triagem cabe em uma VM leve e é inteiramente de linha de comando, o que favorece automação futura. A tabela abaixo resume as ferramentas, o papel de cada uma e a etapa do fluxo onde atuam.

3. Identidade do Artefato: Hashes e Deduplicação

A identidade criptográfica do arquivo é o primeiro IOC formal extraído e o elo que conecta a amostra ao restante da biblioteca. O SHA-256 é o hash de referência, por colisão impraticável; o MD5 e o SHA-1 continuam presentes em feeds e em serviços de reputação, e devem ser capturados por compatibilidade, jamais usados como único identificador. Hashes difusos como ssdeep e TLSH capturam similaridade entre variantes, o que é produtivo em famílias que recompilam com pequenas mudanças a cada build, situação comum em stealers e loaders comerciais.

# Identidade criptografica do artefato, sempre antes de qualquer manipulacao
sha256sum LDR-2026-0142.bin
md5sum LDR-2026-0142.bin
ssdeep -b LDR-2026-0142.bin
tlsh -f LDR-2026-0142.bin

Antes de iniciar qualquer trabalho, o hash deve ser confrontado com o corpus interno e com o Threat Intelligence Platform em uso, como MISP ou OpenCTI. Um hash conhecido pode pular a fila de análise, herdar classificação anterior e entrar direto na esteira de enriquecimento; um hash novo entra na triagem completa. Essa deduplicação economiza horas de analista e evita que a mesma amostra coletada por três fontes diferentes gere três fichas paralelas inconsistentes, problema típico de equipes que crescem sem processo.

4. Tipo Real versus Extensão: Magic Bytes

A extensão de um arquivo é uma sugestão do remetente, nunca uma garantia, e campanhas de phishing exploram exatamente essa confiança. O tipo real é determinado pelos magic bytes, a sequência de assinatura no início do arquivo, e essa verificação é a primeira análise técnica de fato. A tabela abaixo resume as assinaturas mais úteis na triagem diária.

A ferramenta file resolve a maioria dos casos na linha de comando, e o Detect It Easy complementa com identificação de compilador, linker e empacotador em saída estruturada. Os comandos abaixo ilustram o par mínimo da triagem.

file -b LDR-2026-0142.bin
file --mime-type LDR-2026-0142.bin
diec -j LDR-2026-0142.bin

Divergências entre tipo real e extensão são, em si, um indicador de campanha. Um PDF que é na verdade um executável MZ, um atalho LNK disfarçado de documento, um ISO entregue como anexo de boleto e um arquivo OneNote com payload embutido formam padrões recorrentes de engenharia social recentes. Registrar o par extensão declarada contra tipo real na ficha cria, com o tempo, uma base de padrões de mascaramento da região e do setor, útil tanto para detecção quanto para conscientização de usuários.

5. Aninhamento: Contêineres Dentro de Contêineres

As campanhas contemporâneas raramente entregam o payload no primeiro nível do arquivo, e a triagem precisa abrir camadas antes de chegar ao executável. O padrão comum do phishing financeiro brasileiro empilha ZIP protegido por senha, que contém um ISO ou IMG montável, que contém um LNK que executa um script ou um DLL sideload. Cada camada é um tipo real próprio, e o 7z resolve quase todas elas, incluindo imagens de disco e contêineres Office, sem execução de qualquer conteúdo.

7z l Boleto_Fatura_0342.zip
7z x -opasso1 -pSenh4d0Bolet0 Boleto_Fatura_0342.zip
7z l passo1/Fatura.img
7z x -opasso2 passo1/Fatura.img
file passo2/*

O registro da pilha de aninhamento na ficha é tão valioso quanto o payload final, pois o padrão de empacotamento de campanhas, senha do ZIP derivada do texto do e-mail, nome de arquivo interno repetido, assinatura de imagem de disco, costuma se manter entre as centenas de anexos da mesma operação. Essa observação permite que a detecção de e-mail da organização bloqueie a camada externa, sem precisar esperar pela análise do payload interno, que fica a cargo das notas seguintes.

6. Empacotamento: Detecção de Packers

Packers são ferramentas que comprimem ou criptografam o executável e o descomprimem em memória na execução, com o objetivo declarado de reduzir tamanho e o objetivo real, no malware, de frustrar análise e detecção. Detectar o empacotamento na triagem muda a expectativa do analista: strings e imports visíveis serão escassos, e a análise estática direta da nota 02 produzirá pouco sem desempacotamento prévio. Os sinais clássicos de empacotamento são listados abaixo.

• Seções PE com entropia alta, tipicamente acima de 7,2 em escala de 0 a 8, indicando dados comprimidos ou cifrados.
• Conjunto mínimo de imports, muitas vezes reduzido a LoadLibraryA, GetProcAddress e VirtualAlloc, pois as demais APIs são resolvidas em tempo de execução.
• Anomalias de seção, como nomes não padrão, tamanho bruto zero com tamanho virtual grande, ou entry point localizado na última seção em vez da primeira.
• Assinatura direta de empacotador conhecido, caso de UPX, Themida, VMProtect ou ASPack, identificada pelo DIE ou pelo PEStudio.

diec -j LDR-2026-0142.bin | jq '.[0].detects[] | {name, type, warn}'
upx -t LDR-2026-0142.bin
upx -d -o LDR-2026-0142_desempacotado.bin LDR-2026-0142.bin

O UPX merece nota especial porque é ferramenta legítima, presente em software comercial e em jogos, e porque permite desempacotamento reversível com a própria ferramenta. Empacotamento UPX não torna um arquivo malicioso, e empacotadores caros não garantem malícia; a classificação de risco considera o conjunto, e a descompressão UPX é passo barato que frequentemente revela o payload real para as notas seguintes do capítulo.

7. Classificação de Risco e Rota de Análise

Com tipo real, hashes e status de empacotamento definidos, a triagem termina com duas decisões: o nível de risco do artefato e a rota de análise. O risco combina a natureza do artefato, o grau de ofuscação e o contexto de chegada, como origem interna ou externa, campanha ativa e criticidade do setor afetado. A tabela abaixo propõe uma escala prática, que cada equipe deve adaptar ao seu catálogo de serviços.

A priorização entre artefatos do mesmo nível segue a relevância operacional: amostra de campanha atingindo a organização agora vence amostra arquivada há meses, e artefato coletado por fonte primária confiável vence amostra de segunda mão repassada por terceiro. Essa ordem evita o padrão patológico de fila infinita de triagem, em que tudo é urgente e, portanto, nada é.

8. Exemplo de Ficha de Triagem Preenchida

A ficha abaixo documenta o artefato que servirá de fio condutor para as notas 02, 03 e 04 do capítulo, um loader fictício denominado internamente LDR-2026-0142.

Três campos dessa ficha concentram o valor analítico. A divergência entre nome PDF e tipo PE é o indicador de mascaramento que deve subir para a detecção de e-mail; a origem no setor financeiro direciona a hipótese de campanha de golpes de boleto, comum no Brasil; e o TLP define que os IOCs extraídos podem circular internamente, mas não em canais públicos, orientação que vale para todo o restante do caso.

9. Erros Comuns e Pontos de Atenção

O erro mais grave e mais frequente é confiar na extensão, e ele tem duas formas: abrir um arquivo porque parece inofensivo, e classificar mal um artefato porque a ferramenta herdou a extensão declarada. Ambas as formas se resolvem com a verificação de magic bytes como etapa obrigatória e registrada. O segundo erro recorrente é calcular hashes depois de manipular o arquivo, quando ferramentas podem ter alterado metadados ou, em caso de detonação acidental, o próprio conteúdo, invalidando a identidade documentada.

Completam a lista os itens abaixo.

• Executar a amostra "só rapidamente" na VM de triagem sem snapshot de retorno, transformando um ambiente controlado em ambiente contaminado.
• Descompactar o ZIP protegido fora da VM, com o payload solto na estação de trabalho e protegido apenas pela esperança.
• Tratar packer detectado como veredito de malícia, classificando como ameaça um instalador UPX legítimo e atrasando serviços internos.
• Descartar artefatos sem registro do motivo, destruindo a memória institucional que permitiria vincular campanhas futuras ao mesmo padrão.
• Não registrar origem e horário de chegada, perdendo a linha do tempo necessária para correlacionar a amostra com alertas do SOC.
• Preencher a ficha de memória ao final do dia, com detalhes imprecisos que contaminam todas as análises seguintes do caso.

10. Integração com o Restante da Biblioteca

A ficha de triagem é o contrato de entrada das notas seguintes: a análise estática da nota 02 assume tipo real e status de empacotamento conhecidos, a análise dinâmica da nota 03 recebe a rota definida, e a engenharia reversa da nota 04 herda a hipótese de campanha registrada no campo de origem. Os IOCs colhidos aqui, hashes e padrão de mascaramento, entram no ciclo de vida de indicadores do capítulo 03, com validação, enriquecimento e expiração seguindo aquele fluxo.

Na direção da operação, a triagem alimenta o controle DAT.4 do framework CTH, na ingestão e centralização de logs, e o SIM.4, no teste de detecção de IOCs e IOAs, usando os artefatos classificados como material de simulação. A nota 05 do capítulo converte as características observadas em regras YARA versionadas, e o capítulo 18 recebe essas regras como código de detecção no pipeline. O resultado esperado da esteira completa é que nenhum artefato entre em análise profunda sem identidade, risco e rota registrados, e que nenhum descarte ocorra sem documentação.