Capítulo 17 — Perícia digital e análise de malware: ferramental
Mapa da aula
Aula 17 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["17.1 Necessidades"]
N1["17.2 Critérios de seleção"]
N2["17.3 Validação"]
N3["17.4 O kit"]
N4["17.5 Atualizações"]
N5["17.6 Documentação do caso"]
N6["17.7 Scripts"]
N7["Treinamento com o kit"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["17.1 Necessidades"]
N1["17.2 Critérios de seleção"]
N2["17.3 Validação"]
N3["17.4 O kit"]
N4["17.5 Atualizações"]
N5["17.6 Documentação do caso"]
N6["17.7 Scripts"]
N7["Treinamento com o kit"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[17.1 Necessidades]
|
v
[17.2 Critérios de seleção]
|
v
[17.3 Validação]
|
v
[17.4 O kit]
|
v
[17.5 Atualizações]
|
v
[17.6 Documentação do caso]
|
v
[17.7 Scripts]
|
v
[Treinamento com o kit]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) selecionar ferramentas periciais para uma organização pequena; (2) validar as ferramentas antes do uso; (3) manter um kit de ferramentas; (4) documentar o uso das ferramentas nos casos.
17.1 Necessidades
Alder Falls precisa de captura de memória, coleta de triagem, geração de imagem de disco, análise de logs e construção de linhas do tempo, além de uma forma segura de entregar arquivos aos analistas. Cada necessidade corresponde a uma pergunta do caso do CLERK-03: a captura de memória respondeu se havia uma ferramenta remota rodando no PLAN-07; a coleta de triagem reuniu logs e dados do registro rapidamente; a imagem preserva uma cópia completa caso seja necessária depois; a análise de logs e as linhas do tempo juntaram os hosts; a entrega segura levou o helper.exe e o svc.exe ao analista. Uma ferramenta que não atende a nenhuma dessas necessidades não tem lugar no kit.
17.2 Critérios de seleção
Validada ou testável; documentada; com suporte; licença adequada; funciona offline; produz saída verificável (hashes, logs). Funcionar offline importa porque uma ferramenta que contata a internet durante a coleta altera os registros de rede da máquina suspeita e pode alertar um intruso. Saída verificável significa que a ferramenta grava hashes e logs do que fez, para que Renata possa mostrar depois exatamente como cada item foi produzido. Jonah pontua as ferramentas candidatas segundo esses critérios numa tabela curta guardada com os registros do kit. Uma ferramenta mais barata que falha num critério é rejeitada.
17.3 Validação
Antes do uso, cada ferramenta é testada sobre dados sintéticos de conteúdo conhecido. O programa CFTT do NIST publica relatórios de teste de algumas ferramentas de geração de imagem e de bloqueio de escrita; para as demais, a prefeitura executa seus próprios testes pequenos e registra os resultados. Os testes da própria prefeitura são simples, mas registrados: uma máquina sintética com arquivos e logons conhecidos, a ferramenta executada sobre ela e uma conferência de que cada item esperado aparece com o hash certo. O resultado do teste, a data e a versão da ferramenta vão para o log do kit. Quando o coletor de triagem mudou o layout de suas pastas, esse teste pegou o problema antes de um caso real.
17.4 O kit
Um pendrive identificado e protegido contra escrita, com as ferramentas de coleta, uma lista de checksums das próprias ferramentas e um procedimento impresso. Um segundo pendrive é guardado fora do local. O procedimento impresso importa quando o estresse é alto e as telas são desconhecidas. Ele lista os passos em ordem, os comandos a digitar e onde anotar os horários e os hashes. A lista de checksums permite a Jonah confirmar, antes de cada uso, que as ferramentas do pendrive são as versões validadas e não foram alteradas desde o último teste.
17.5 Atualizações
As atualizações de ferramentas são testadas antes de substituírem a versão do kit; as versões antigas são arquivadas para que os casos passados possam ser reproduzidos. Arquivar as versões antigas significa que um resultado produzido no ano passado pode ser reproduzido com a ferramenta exata que o produziu, o que importa se um caso for reaberto ou contestado. Jonah guarda cada versão com seu registro de teste e a data em que entrou no kit ou saiu dele. Atualizar no meio de um caso é evitado, a menos que uma falha obrigue, e então as duas versões são registradas.
17.6 Documentação do caso
Cada caso registra os nomes e as versões das ferramentas e o hash da lista de ferramentas do pendrive do kit. Para o caso do CLERK-03, as notas listam a ferramenta de captura de memória e sua versão, o coletor de triagem e sua versão, a versão do script de manifesto de Jonah e o hash da lista de ferramentas do kit no dia da coleta. Assim, um revisor pode conferir que cada ferramenta era a validada. Sem esses detalhes, uma pergunta sobre o comportamento de uma ferramenta não pode ser respondida para este caso específico. As mesmas notas listam qualquer ferramenta que tenha falhado.
17.7 Scripts
Os scripts próprios (gerador de manifesto, analisador de logs) são versionados e testados como qualquer outra ferramenta. O gerador de manifesto e o analisador de logs são tão importantes para o caso quanto qualquer ferramenta comercial: um defeito em qualquer um deles poderia esconder dados, como mostrou mais tarde o defeito do analisador com carimbos de tempo em milissegundos. Cada script tem testes, um número de versão e um histórico de commits, e a versão usada é registrada em todos os casos em que ele roda. Os scripts escritos durante um caso são revisados por Renata antes que sua saída seja usada e só entram no kit depois de passar pelos mesmos testes que os demais.
Treinamento com o kit
Todo funcionário de TI que possa responder a um incidente pratica com o kit duas vezes por ano numa máquina sintética: coletar a memória, rodar a triagem, gerar o manifesto, entregar. Jonah cronometra cada passo e anota onde o procedimento impresso confundiu as pessoas, e então revisa o texto. A prática transforma um kit pouco usado em algo que a equipe consegue usar com calma sob pressão, e mostra quais passos precisam de rótulos melhores ou de capturas de tela mais claras.
Exemplo resolvido
Uma nova versão do coletor de triagem muda o layout de sua pasta de saída. O script de manifesto de Jonah deixa de fora uma pasta. O teste sobre dados sintéticos antes da implantação revela a falha; ele atualiza o script e registra as duas versões no log do kit.
Caso sintético. A atualização é inventada.
Erros e limites
A validação sobre dados sintéticos cobre os casos testados; sistemas incomuns podem se comportar de outro modo.
Exercícios
- EX049 — Critérios. Liste quatro critérios de seleção de ferramentas. Rubrica: 3 = validada, documentada, com suporte, licença, offline, saída verificável (quaisquer quatro); 2 = três; 1 = um; 0 = nada.
- EX050 — Integridade do kit. Como a integridade do pendrive do kit é protegida? Rubrica: 3 = protegido contra escrita; lista de checksums das ferramentas; cópia fora do local; 2 = duas; 1 = uma; 0 = nada.
- EX051 — Mudança de layout. O que o teste pegou com a nova versão do coletor? Rubrica: 3 = o script de manifesto deixou de fora a pasta nova; corrigido antes do uso; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Um kit validado, versionado e documentado torna a coleta repetível e defensável.
Continue estudando — capítulo 17 de 30
← Capítulo 16 (rascunho) · Índice de capítulos do curso · Capítulo 18 (rascunho) →