Capítulo 27 — Perícia digital e análise de malware: verificação | Graduação Perícia digital e análise de malware

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX079.

flowchart TD
  N0["27.1 Por que verificar as constatações"]
  N1["27.2 Ferramentas independentes"]
  N2["27.3 Verificações brutas"]
  N3["27.4 Revisão por pares"]
  N4["27.5 Verificação dos horários"]
  N5["27.6 Quando a verificação falha"]
  N6["27.7 Documentação"]
  N7["Reproduzir a partir das notas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX079"]

Desenho lógico

flowchart LR
  N0["27.1 Por que verificar as constatações"]
  N1["27.2 Ferramentas independentes"]
  N2["27.3 Verificações brutas"]
  N3["27.4 Revisão por pares"]
  N4["27.5 Verificação dos horários"]
  N5["27.6 Quando a verificação falha"]
  N6["27.7 Documentação"]
  N7["Reproduzir a partir das notas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[27.1 Por que verificar as constatações]
    |
    v
[27.2 Ferramentas independentes]
    |
    v
[27.3 Verificações brutas]
    |
    v
[27.4 Revisão por pares]
    |
    v
[27.5 Verificação dos horários]
    |
    v
[27.6 Quando a verificação falha]
    |
    v
[27.7 Documentação]
    |
    v
[Reproduzir a partir das notas]
    |
    v
[Exemplo resolvido] --> [Exercício EX079]

Objetivos de aprendizagem

Você vai (1) verificar constatações por métodos independentes; (2) conferir a saída das ferramentas com os dados brutos; (3) conduzir a revisão por pares das constatações; (4) documentar a verificação.

27.1 Por que verificar as constatações

Uma constatação é mais forte quando dois métodos independentes concordam. A ISO/IEC 27042 trata da análise e da interpretação e da necessidade de que as constatações sejam sustentadas e revisáveis. A concordância entre métodos importa porque cada um tem seus próprios modos de falha. Uma ferramenta pode interpretar mal um valor; uma pessoa pode ler errado uma visualização hexadecimal. Quando dois métodos com fraquezas diferentes dão a mesma resposta, a chance de ambos errarem do mesmo jeito é pequena. A ênfase da ISO/IEC 27042 em constatações revisáveis significa que a verificação é registrada, e não apenas feita.

27.2 Ferramentas independentes

A ferramenta principal de Leah relata a run key. Ela a confirma com uma segunda ferramenta que analisa as hives do registro de outro modo. Ambas mostram o valor "Updater" → rundll32 update.dll com o mesmo horário de última escrita. As duas ferramentas precisam ser de fato independentes: se ambas dependem da mesma biblioteca de análise, um defeito nela afetaria as duas. Leah confere na documentação qual parser cada uma usa. O horário de última escrita coincidente também liga a chave à linha do tempo, já que ele deve concordar com a criação da run key às 09:31:07, depois da correção do relógio.

27.3 Verificações brutas

Para os artefatos principais, ela inspeciona diretamente os bytes ou registros subjacentes — por exemplo, vendo os dados do valor do registro numa visualização hexadecimal — para confirmar a interpretação da ferramenta. Uma visualização hexadecimal mostra os bytes que a ferramenta interpretou. Para o valor da run key, Leah confirma que a cadeia guardada é rundll32 seguido do caminho para update.dll, codificada do jeito que o registro a guarda. Se a ferramenta tivesse mostrado uma versão limpa ou encurtada, a visualização bruta revelaria isso. As verificações brutas são lentas, então ela as reserva para as constatações em que se apoiam as conclusões do laudo.

27.4 Revisão por pares

Um colega de Grace revisa cada constatação: a fonte é citada? A interpretação é sustentada? As alternativas foram consideradas? Comentários e respostas são registrados. As três perguntas do revisor correspondem à lista de verificação que Leah rascunhou a partir dos erros recorrentes. Registrar os comentários e as respostas mostra como cada constatação mudou, se é que mudou, durante a revisão. Uma constatação que foi contestada e depois sustentada com mais evidências é mais forte do que uma que nunca foi questionada, e o registro mostra essa força. Leah responde a todos os comentários, mesmo quando a resposta é simplesmente que nenhuma mudança era necessária, e por quê.

27.5 Verificação dos horários

Os horários principais são confirmados em pelo menos duas fontes: o horário de última escrita da run key contra o início do processo na memória e nos logs de eventos. Por exemplo, o horário de última escrita da run key deve ficar pouco depois do início do processo rundll32 que a criou; a memória e os logs de eventos registram esse início de forma independente. Se os horários diferissem em minutos, Leah procuraria uma segunda escrita na chave ou um problema de relógio. A concordância ao segundo dá confiança de que a linha do tempo corrigida está certa.

27.6 Quando a verificação falha

Se duas ferramentas discordam, nenhum dos resultados é relatado até que a diferença seja entendida e documentada. O exemplo resolvido mostra um caso típico: uma diferença de uma hora causada por configurações de exibição, e não pelas evidências. Até a causa ser encontrada, qualquer um dos valores poderia estar errado, e relatar um deles teria sido um palpite. Documentar a discrepância e sua resolução também ajuda o próximo perito que usar as mesmas ferramentas. A lição, configurar todas as ferramentas para exibir UTC, é acrescentada ao registro de lições de toda a equipe.

27.7 Documentação

Uma tabela de verificação lista constatação, método principal, método de verificação, resultado e revisor. Uma linha da tabela de Leah diz: F6 run key; método principal ferramenta de registro A; método de verificação ferramenta de registro B e visualização hexadecimal; resultado concordam; revisor o colega de Grace. Os revisores podem percorrer a tabela para ver quais constatações se apoiam num só método e pedir mais trabalho onde for preciso. A tabela é anexada ao laudo como apêndice. As constatações verificadas por um só método são marcadas, e a redação do laudo para elas é mais cautelosa.

Reproduzir a partir das notas

Um teste forte é saber se outro analista consegue reproduzir uma constatação usando apenas as notas. Leah pede a um colega que siga suas notas sobre a run key sem ajuda. Ele consegue, mas pergunta onde a cópia da hive foi guardada; ela acrescenta o caminho ao seu modelo de notas para que o próximo leitor não precise perguntar.

Exemplo resolvido

Duas ferramentas discordam sobre o tempo de criação de update.dll em exatamente uma hora. Leah rastreia a causa: uma ferramenta exibia os horários no fuso local da sua máquina de análise, uma hora à frente do UTC. Convertidos para UTC, ambos concordam. A nota registra a discrepância, a causa e a resolução.

Caso sintético. A discrepância é inventada.

Erros e limites

Duas ferramentas que compartilham a mesma biblioteca de análise não são independentes; confira como cada uma funciona.

Exercícios

EX079 — Verificação da run key. Como a constatação da run key foi verificada?
Mostrar critérios de avaliação
Rubrica: 3 = segunda ferramenta com outro parser, mesmo valor e horário; verificação bruta; 2 = parcial; 1 = executar de novo a mesma ferramenta; 0 = nada.
EX080 — Diferença de uma hora. O que causou a discordância de uma hora?
Mostrar critérios de avaliação
Rubrica: 3 = uma ferramenta mostrava a hora local, uma hora à frente do UTC; 2 = parcial; 1 = defeito da ferramenta; 0 = nada.
EX081 — Independência. Quando duas ferramentas não são independentes?
Mostrar critérios de avaliação
Rubrica: 3 = compartilham biblioteca/código de análise; 2 = parcial; 1 = sempre independentes; 0 = nada.

Síntese

Verifique de forma independente as constatações importantes, explique cada discordância e registre quem revisou o quê.

Continue estudando — capítulo 27 de 40

← Capítulo 26 (rascunho) · Índice de capítulos do curso · Capítulo 28 (rascunho) →