Análise Dinâmica e Sandboxes

Nota 03 do capítulo 25, dedicada à detonação controlada de artefatos em ambiente isolado e instrumentado.
A análise dinâmica revela o que a estática da nota 02 não alcança: código decifrado em runtime, tráfego real de C2 e persistência instalada.
Dialoga com o controle TH.3 do framework CTH sobre ambientes isolados, com o ciclo de IOCs do capítulo 03 e com a extração de configurações da nota 04.

1. Contexto e Posicionamento na Biblioteca

A análise dinâmica executa o artefato em ambiente controlado e observa o que ele faz, e não apenas o que declara fazer. É a etapa que transforma hipóteses estáticas em comportamento confirmado: o payload cifrado visto na nota 02 aparece descomprimido em memória, a rota de C2 escrita em stack string materializa-se em requisições HTTP reais, e a persistência suspeita deixa de ser import declarado para virar chave de registro efetivamente criada. O custo é maior que o da estática, porque exige laboratório, tempo e disciplina de reversão, mas o retorno é acesso ao estado decifrado do malware, que é onde a maioria das configurações vive.

O posicionamento na biblioteca é o de ponte entre a leitura do arquivo e a caracterização da campanha. A nota 01 definiu a rota de detonação, a nota 02 entregou hipóteses e o payload extraído; esta nota executa e captura, e a nota 04 entra quando a configuração exige depuração além da observação passiva. A tabela abaixo resume o que cada método entrega, para deixar explícito que são complementares e não concorrentes.

2. Ambiente de Detonação: VM, Snapshot e Isolamento

O laboratório mínimo é uma máquina virtual Windows de análise, com snapshot limpo, sem credenciais reais, sem acesso à rede corporativa e com identidade plausível de usuário final. O isolamento tem três camadas obrigatórias: rede dedicada sem rota para a produção, host de virtualização fora do domínio e artefatos transitando apenas dentro de ZIP protegido. A VM deve carregar dados isca coerentes, como documentos fictícios com nomes plausíveis, cookies falsos de webmail e uma planilha de finanças com valores de fantasia, porque stealers modernos verificam presença de dados valiosos e desistem em ambiente vazio, produzindo análise vazia que parece amostra inativa.

A configuração de rede é uma decisão analítica por si só. Simuladores como o FakeNet-NG respondem a todo DNS e a todo serviço, garantindo que a amostra encontre um "internet" estável e revelando o comportamento de rede completo sem contato real com infraestrutura do adversário. Rede com saída real controlada por NAT, por sua vez, confirma que o C2 responde e permite capturar o tráfego de segunda etapa, mas toca infraestrutura viva e deve seguir regras de OPSEC: por VPN dedicada, em horário planejado e nunca com endereços corporativos. A prática comum é detonar duas vezes, primeiro contra simulador para mapear, depois com saída controlada para confirmar.

A identidade da VM também é material de análise e de contra-inteligência. O usuário de laboratório deve ter nome comum, histórico de navegação e arquivos coerentes, e nada que aponte para a organização: domínio interno, nome de empresa, impressora compartilhada e símbolos corporativos são sinais que malware direcionado usa para desistir ou para marcar a vítima investigada. O mesmo rigor vale para a OPSEC da equipe: capturas de tela do laboratório, relatórios intermediários e dumps nunca circulam em canais com escopo mais aberto que o TLP do caso, disciplina que o controle CTI.10 do framework CTH formaliza.

3. Instrumentação de Captura no Host

A captura cobre três domínios: sistema de arquivos e registro, processos e rede. No Windows, o Procmon da Sysinternals é a ferramenta central do primeiro domínio, registrando cada operação de arquivo, registro e rede com pilha de chamadas, e o RegShot fotografa o estado do registro antes e depois para diferencial rápido. A coleta de memória do processo suspeito com Procdump preserva o estado decifrado, e o Process Hacker observa handles, threads e injeções em tempo real. Na rede, o Wireshark captura pacotes completos, e o Zeek do capítulo 08 processa os logs quando o laboratório replica topologia de produção.

# 1. Garantir estado limpo antes de tudo
VBoxManage snapshot Win11Lab restore base-limpa

# 2. Iniciar o simulador de internet e a captura de rede
fakenet-ng.exe -c configs\default.ini
netsh trace start capture=yes tracefile=C:\lab\rede.etl

# 3. Iniciar Procmon com filtro predefinido, gravando em disco
procmon.exe /Quiet /Minimized /AcceptEula /BackingFile C:\lab\procmon.pml

# 4. Fotografar o registro antes da execucao
regshot: salvar hive inicial

# 5. Executar a amostra e aguardar a janela de observacao (10 minutos)

# 6. Encerrar capturas e exportar para analise
procmon.exe /OpenLog C:\lab\procmon.pml /SaveAs C:\lab\procmon.csv

# 7. Capturar memoria do processo suspeito com payload decifrado
procdump.exe -ma LdrGate.exe C:\lab\dump_ldrgate.dmp

# 8. Reverter a VM e retirar os artefatos por canal seguro
VBoxManage snapshot Win11Lab restore base-limpa

A janela de observação merece cálculo próprio: malware comercial usa sleeps longos e verificações de tempo para passar por sandboxes de timeout curto, então a detonação manual deve durar o suficiente para atravessar atrasos típicos de cinco a dez minutos. Filtros do Procmon devem ser preparados antes da execução, focando o processo da amostra e suas filhas, porque o log completo de uma detonação passa de meio milhão de eventos e o valor está no recorte, não no volume.

A tabela abaixo organiza o kit de captura por domínio de evidência, com o papel de cada ferramenta e o artefato que produz.

4. Sandboxes Públicas e Privadas: Comparativo

Sandboxes automatizam o ciclo de detonação, captura e relatório, e o mercado divide-se entre serviços públicos, serviços comerciais privados e instalações próprias. A escolha é decisão de OPSEC tanto quanto de custo, porque detonar em sandbox pública significa, na prática, compartilhar a amostra com o operador do serviço, com outros usuários que pesquisam o mesmo hash e, por extensão, com o ecossistema de inteligência que monitora esses depósitos, adversários incluídos.

A regra de ouro operacional sequencia a decisão: detonação local primeiro, serviço privado contratado quando o caso exige escala ou ambiente especializado, sandbox pública somente quando o TLP da amostra permite compartilhamento amplo e quando o benefício de correlação comunitária supera o custo de exposição. Amostra de campanha direcionada contra a organização, coletada de incidente interno, nunca é detonada em serviço público antes de o caso fechar, pois o adversário monitora submissões e reage trocando infraestrutura em horas.

Há um uso legítimo e produtivo da sandbox pública no final do ciclo, e não no início: depois que o caso está fechado e a regra YARA da nota 05 está em produção, a submissão da amostra em ambiente público verifica a cobertura dos fornecedores e serve de teste de detecção externa, em linha com a validação do SIM.4. Nesse cenário, a amostra já não carrega valor de surpresa para o adversário, e o relatório público passa a ser material de comparação de cobertura, e não fonte primária da investigação. A ordem das operações é o que separa o uso tático do vazamento evitável.

5. Riscos das Sandboxes Públicas e Evasão

O risco de exposição tem três vetores documentados. O primeiro é o compartilhamento direto: amostra submetida passa a integrar datasets de treinamento de motores de detecção, feeds comerciais e repositórios de pesquisa, e segredos embutidos na amostra, como documentos internos exfiltrados e credenciais de teste, vazam junto. O segundo é a observação pelo adversário: grupos de ransomware e operadores de stealer consultam submissões de seus builds para identificar vítimas investigando e para medir detecções, comportamento observado em operações como LockBit e ALPHV, que rotacionavam infraestrutura após picos de submissão. O terceiro é a contaminação analítica: relatório público descreve o comportamento contra o ambiente da sandbox, não contra o seu, e decisões de detecção copiadas de relatório público frequentemente não reproduzem no parque real.

A evasão é a resposta técnica do malware a esse ecossistema, e o analista precisa reconhecer seus padrões em resultados vazios. Amostras que dormem minutos antes de agir, que verificam nome de usuário, contagem de processos, presença de ferramentas de análise, resolução de tela ou quantidade de CPU, e que executam apenas sobre input humano realista, são amostras evasivas, e um relatório de sandbox sem atividade é um resultado analítico, não um veredito de benignidade. As contramedidas de laboratório incluem VMs com perfis realistas, injeção de eventos de mouse e teclado, sleeps acelerados por hooks e, na última instância, a engenharia reversa da nota 04 para entender a condição de evasão e contorná-la na detonação.

6. Extração de IOCs Dinâmicos

O resultado da detonação é convertido em IOCs dinâmicos com origem comportamental, categoria que se sustenta melhor na pirâmide de dor que hashes isolados. O inventário típico de uma detonação produtiva inclui os itens abaixo.

• Artefatos droppados em disco, com caminho, hash e momento da gravação, incluindo payloads de segunda etapa que a estática não extraiu.
• Chaves e valores de registro criados ou modificados, em especial as rotas de persistência Run, RunOnce, serviços e tarefas agendadas.
• Mutexes criados na inicialização, que combinam com o mutex visto em strings e confirmam identidade da família.
• Requisições de rede completas, com DNS resolvido, IP de destino, método, URI, user-agent e cadência de beaconing, observada pela periodicidade entre requisições.
• Processos criados e relações de pai e filho, capturando a árvore que alimenta detecções de processo no SIEM.
• Serviços e tarefas agendadas criados, complementando o diferencial de registro com os pontos de persistência fora do Run.
• Modificações na área de transferência e na memória dos navegadores, achados característicos de stealers e clippers que a estática raramente declara.

# Diferencial de registro entre snapshots antes e depois
regshot: comparar hives e exportar diff_registro.txt

# Filtragem do Procmon para persistencia e rede do processo da amostra
procmon.exe /OpenLog procmon.pml /SaveAs procmon.csv
# No CSV: filtrar Operation is RegSetValue e Path contains CurrentVersion\Run
# filtrar Operation is TCP Connect para mapear destino e porta de C2

# Convertendo o pcap em conversas legiveis
tshark -r detonacao.pcap -Y "http or dns" -T fields -e frame.time -e ip.dst -e dns.qry.name -e http.request.uri

A cadência de beaconing extraída do pcap é um IOC dinâmico de longa vida, pois o intervalo de comunicação e o caminho de URI tendem a sobreviver à troca de endereços IP. Essa cadência alimenta a caça de C2 do capítulo 08, e os artefatos droppados voltam ao início da esteira como novas amostras de entrada na triagem da nota 01, fechando o ciclo de propagação da análise dentro do capítulo.

A ficha final de IOCs dinâmicos ganha qualidade quando cada item é cruzado com os achados estáticos da nota 02, marcando convergências e divergências. O mutex visto em strings e criado em runtime é confirmado com confiança alta; a rota de C2 escrita no binário e usada na detonação é confirmada; e um endpoint que só aparece no tráfego, ausente do binário, indica que a nota 04 precisa explicar sua geração dinâmica. Esse cruzamento evita os dois extremos que degradam acervos de inteligência: IOC duplicado com origens diferentes e IOC órfão sem explicação técnica.

7. Fluxo Consolidado de Detonação Segura

O roteiro abaixo consolida a detonação da amostra LDR-2026-0142, herdada das notas 01 e 02, assumindo VM Windows 11 isolada, snapshot base-limpa e a política de duas fases com simulador e depois rede controlada. A fase um usa FakeNet-NG para mapear comportamento sem tocar infraestrutura real, e confirma as hipóteses estáticas: o payload do recurso RCDATA é droppado em disco, o mutex Global\Sombra-Mtx-0142 é criado, a chave de Run aponta para o payload e a requisição POST para /gate.php sai com user-agent próprio da família. A fase dois, liberada apenas após a revisão do TLP e do caso, confirma que o C2 real responde e captura o tráfego de segunda etapa com credenciais de exfiltração de teste.

O fechamento do fluxo é a retirada e o registro: artefatos saem da VM por canal seguro, a VM é revertida ao snapshot, e a ficha do caso recebe os IOCs dinâmicos com vínculo à amostra, ao horário e à configuração de rede usada. Essa documentação transforma a detonação em evidência reprodutível, e a ausência de atividade observada, quando ocorre, é registrada como hipótese de evasão que encaminha o caso para a nota 04, e não como encerramento por benignidade.

O passo intermediário entre detonação manual e engenharia reversa é a detonação automatizada local com CAPE, que combina o controle do laboratório próprio com relatórios estruturados e extractors de configuração embutidos. Para equipes com volume recorrente, a sequência produtiva é: detonação manual na primeira amostra da campanha, para entendimento profundo; configuração de um pacote de processamento no CAPE com as regras YARA da nota 05 e os filtros de Procmon já calibrados; e processamento automatizado das variantes seguintes, reservando o esforço manual para as amostras que evadem ou que apresentam comportamento novo. Essa progressão é a mesma lógica de automação do capítulo 18 aplicada ao laboratório, e evita tanto o gargalo manual quanto a automação prematura de um processo ainda não entendido.

8. Erros Comuns e Pontos de Atenção

O erro estrutural mais grave é detonar em rede com acesso irrestrito à internet por descuido, transformando o laboratório em origem de ataque real e tocando infraestrutura de terceiros sem controle. O erro simétrico é acreditar que a VM isolada é suficiente sem snapshot de retorno, o que contamina a base do laboratório e propaga o malware para todas as detonações seguintes, inclusive para casos futuros de outras campanhas. Ambos se resolvem com processo escrito e checklist obrigatório antes de cada detonação.

Completam a lista os itens abaixo.

• Interpretar relatório vazio de sandbox como benignidade, quando a leitura correta é hipótese de evasão que exige ambiente manual ou reversão.
• Submeter amostra TLP:RED ou de incidente interno ativo a sandbox pública, expondo o caso ao ecossistema e ao adversário.
• Reutilizar a mesma VM de análise com credenciais, chaves ou VPN corporativa residuais, oferecendo material real ao stealer.
• Deixar a janela de observação menor que os sleeps da amostra, gerando análise truncada que aparenta inatividade.
• Exportar o Procmon sem filtros preparados, afogando o analista em meio milhão de eventos e abandonando a ferramenta por "não funcionar".
• Esquecer de capturar memória do processo durante a execução, perdendo o estado decifrado que a nota 04 precisaria.

9. Integração com o Restante da Biblioteca

A análise dinâmica executa o controle TH.3 do framework CTH, que exige ambiente de hunting e análise isolado, e produz a telemetria que alimenta o DAT.1 na coleta de logs de endpoint e o DAT.2 na telemetria de rede. Os IOCs dinâmicos seguem para o ciclo de vida do capítulo 03, e os padrões comportamentais confirmados, como a cadeia de persistência e a cadência de beacon, viram hipóteses de caça nas notas do capítulo 08, em especial o hunting de persistência e o hunting de C2.

Na camada de detecção, os artefatos droppados e o tráfego capturado viram regras no repositório do PRT.5 e casos de teste no SIM.4, e a extração de configuração que a detonação revela em memória é aprofundada pela nota 04. O capítulo 07 recebe o roteiro de detonação como procedimento documentado de execução de análises, e o capítulo 13 usa o mesmo fluxo quando a resposta a incidente precisa confirmar capacidades de uma amostra coletada em host comprometido. A disciplina de reversão e registro é o elo comum entre o laboratório de análise e a credibilidade do caso.