Capítulo 4 — Perícia digital e análise de malware: explicações concorrentes
Mapa da aula
Aula 04 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["4.1 Por que as alternativas importam"]
N1["4.2 Observação"]
N2["4.3 Testes"]
N3["4.4 Alternativas no caso de malware"]
N4["4.5 Viés de confirmação"]
N5["4.6 Registrando o raciocínio"]
N6["4.7 Implicação para o estudo"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["4.1 Por que as alternativas importam"]
N1["4.2 Observação"]
N2["4.3 Testes"]
N3["4.4 Alternativas no caso de malware"]
N4["4.5 Viés de confirmação"]
N5["4.6 Registrando o raciocínio"]
N6["4.7 Implicação para o estudo"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[4.1 Por que as alternativas importam]
|
v
[4.2 Observação]
|
v
[4.3 Testes]
|
v
[4.4 Alternativas no caso de malware]
|
v
[4.5 Viés de confirmação]
|
v
[4.6 Registrando o raciocínio]
|
v
[4.7 Implicação para o estudo]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem
Você vai (1) enunciar explicações concorrentes para uma observação pericial; (2) projetar testes que as separem; (3) aplicar a ideia a resultados de triagem; (4) evitar o viés de confirmação.
4.1 Por que as alternativas importam
Casey (2011) enfatiza que os peritos devem considerar explicações alternativas antes de chegar a conclusões. A ISO/IEC 27042 também trata da análise e da interpretação de evidências digitais, incluindo a necessidade de raciocínio documentado e repetível. Para Tomás, isso se aplica à sua pesquisa tanto quanto ao trabalho com casos: um resultado inesperado precisa ter explicações alternativas consideradas antes de ser interpretado. Suas anotações listam cada explicação com o teste que poderia descartá-la, como ele faria num exame em sua função policial. A Dra. Osei revisa essas anotações em cada reunião de orientação, começando pelas três explicações para a imagem do piloto com redução baixa.
4.2 Observação
Numa execução do piloto, a redução numa imagem foi de apenas 40%, muito abaixo das outras. Tomás lista explicações: (a) a imagem tinha mais arquivos de usuário; (b) a versão do sistema operacional era mais nova do que o conjunto de referência; (c) a ferramenta de hash falhou em alguns arquivos. Um resultado tão distante dos demais poderia refletir uma propriedade real da imagem ou uma falha em seu método. Listar as explicações antes de testar qualquer uma delas o impede de se fixar na primeira que parecer plausível. Cada explicação é escrita nas anotações do piloto com o teste que ele planeja usar.
4.3 Testes
(a) Contar os arquivos de usuário: semelhante às outras. (b) Comparar a data da versão do sistema operacional com o lançamento do conjunto de referência: a versão era mais nova, por isso muitos arquivos de sistema não têm entradas. (c) Recalcular os hashes com uma segunda ferramenta: hashes idênticos. A explicação (b) sobrevive. Cada teste foi escolhido para descartar uma explicação independentemente das outras. A explicação sobrevivente muda a forma como o estudo precisa ser projetado, porque a redução agora parece depender da atualidade do conjunto de referência em relação ao sistema operacional. As anotações do piloto registram cada teste e cada resultado, incluindo as duas explicações rejeitadas, para que um revisor possa acompanhar o raciocínio.
4.4 Alternativas no caso de malware
Quando um executável desconhecido permanece depois da filtragem, as explicações incluem malware, uma ferramenta interna feita sob medida ou uma atualização de software mais nova do que o conjunto de referência. O exame estático dos metadados da amostra sintética — assinante, recurso de versão, caminho de instalação — ajuda a separá-las sem executá-la. Essas explicações importam porque as imagens sintéticas incluem atualizações de software posteriores ao conjunto de referência, de modo que um executável desconhecido não é automaticamente suspeito. Tomás registra o que cada característica dos metadados mostrou e qual explicação ela apoia. Ele não executa amostras desconhecidas, de acordo com o limite ético do curso.
4.5 Viés de confirmação
Peritos que esperam malware podem ler cada arquivo desconhecido como hostil. A revisão cega, em que um colega avalia sem conhecer a hipótese, reduz esse risco. No estudo dele, as perdas projetadas são conhecidas por Tomás, mas não pelos peritos do estudo de concordância, que classificam eventos sem saber quais arquivos foram plantados. Ele também pede a um colega que revise uma amostra de suas próprias classificações sem lhe contar suas expectativas, e registra onde diferiram e por quê. A revisão cega também é usada nas conferências manuais de executáveis desconhecidos.
4.6 Registrando o raciocínio
Cada explicação, seu teste e seu resultado vão para as anotações, para que um revisor veja por que as opções rejeitadas foram rejeitadas. Registrar as explicações rejeitadas protege o trabalho de duas formas. Um revisor pode conferir se os testes foram adequados, e um pesquisador posterior pode ver quais explicações já foram consideradas. As anotações do piloto de Tomás para a imagem com redução baixa são escritas dessa forma: três explicações, três testes e uma declaração curta de qual explicação sobreviveu e por quê. O mesmo formato é usado para os executáveis desconhecidos na execução principal.
4.7 Implicação para o estudo
A redução depende da atualidade do conjunto de referência; Tomás acrescenta "dias entre a versão do sistema operacional e o lançamento da referência" como variável. O achado do piloto se converte numa mudança de desenho: em vez de tratar a imagem com redução baixa como ponto fora da curva, Tomás mede para cada imagem o intervalo entre a versão do sistema operacional e o lançamento da referência. A execução principal pode então mostrar como a redução muda com esse intervalo, o que é mais útil para os profissionais do que uma média única. Ele registra a mudança e sua razão no protocolo antes do início da execução principal.
Exemplo resolvido
As anotações do piloto dizem: "Imagem L3: redução de 40%. H(a) volume de usuário — rejeitada, 102 arquivos de usuário vs. média de 98. H(b) sistema operacional mais novo — apoiada, versão 73 dias após o lançamento da referência. H(c) falha da ferramenta — rejeitada, a segunda ferramenta coincidiu em todos os hashes."
Caso sintético. A imagem L3 e seus números são inventados.
Erros e limites
Sobreviver a um teste não prova uma explicação; ela é apenas a mais bem apoiada até agora.
Exercícios
- EX021 — Três explicações. Liste as três explicações para a redução baixa em L3. Rubrica: 3 = volume de usuário, sistema operacional mais novo, falha da ferramenta; 2 = duas; 1 = uma; 0 = nada.
- EX022 — Teste da ferramenta. Como a falha da ferramenta foi testada? Rubrica: 3 = novo cálculo de hash com segunda ferramenta, idêntico; 2 = parcial; 1 = errado; 0 = nada.
- EX023 — Executável desconhecido. Nomeie três explicações para um executável desconhecido depois da filtragem. Rubrica: 3 = malware, ferramenta interna, atualização mais nova; 2 = duas; 1 = só malware; 0 = nada.
- EX024 — Separação estática. Que metadados ajudam a separá-las sem execução? Rubrica: 3 = assinante, recurso de versão, caminho; 2 = dois; 1 = executá-lo; 0 = nada.
- EX025 — Controle de viés. Descreva um controle contra o viés de confirmação. Rubrica: 3 = revisão cega por um colega; 2 = vago; 1 = tentativa mínima; 0 = nada.
- EX026 — Nova variável. Que variável o estudo acrescentou, e por quê? Rubrica: 3 = dias entre a versão e o lançamento da referência; a atualidade determina a redução; 2 = parcial; 1 = errado; 0 = nada.
Síntese
Nomeie explicações rivais, teste cada uma, registre por que as rejeitadas falharam e deixe o resultado remodelar o estudo.
Continue estudando — capítulo 04 de 08
← Capítulo 03 (rascunho) · Índice de capítulos do curso · Capítulo 05 (rascunho) →