Capítulo 20 — Perícia digital e análise de malware: solução de problemas
Mapa da aula
Aula 20 publicada. Mapa, exemplo, EX058.
flowchart TD
N0["20.1 Perda silenciosa"]
N1["20.2 O sintoma"]
N2["Laboratório — regex que pula linhas"]
N3["20.3 Lendo o resultado"]
N4["20.4 Prevenção"]
N5["20.5 Causa raiz"]
N6["20.6 Relatando a correção"]
N7["20.7 Método geral"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX058"]
Desenho lógico
flowchart LR
N0["20.1 Perda silenciosa"]
N1["20.2 O sintoma"]
N2["Laboratório — regex que pula linhas"]
N3["20.3 Lendo o resultado"]
N4["20.4 Prevenção"]
N5["20.5 Causa raiz"]
N6["20.6 Relatando a correção"]
N7["20.7 Método geral"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[20.1 Perda silenciosa]
|
v
[20.2 O sintoma]
|
v
[Laboratório — regex que pula linhas]
|
v
[20.3 Lendo o resultado]
|
v
[20.4 Prevenção]
|
v
[20.5 Causa raiz]
|
v
[20.6 Relatando a correção]
|
v
[20.7 Método geral]
|
v
[Exemplo resolvido] --> [Exercício EX058]
Objetivos de aprendizagem
Você vai (1) diagnosticar problemas em scripts e pipelines periciais; (2) detectar perdas silenciosas de dados; (3) corrigir erros de análise com expressões regulares; (4) evitar a recorrência com testes.
20.1 Perda silenciosa
O defeito mais perigoso no ferramental pericial descarta dados sem erro. Um analisador que pula as linhas que não consegue casar produz um resultado de aparência limpa, mas incompleto. Uma quebra é visível e acaba corrigida; uma linha pulada parece apenas um log mais tranquilo. Numa investigação, essa diferença pode mudar as conclusões, porque uma contagem baixa demais pode deixar uma hora abaixo de um limiar de alerta ou eliminar o único evento que ligava duas máquinas. A regra de Jonah é que todo analisador precisa informar quantas linhas leu, casou e pulou.
20.2 O sintoma
A contagem de logons malsucedidos de Jonah a partir do log de texto do FILESRV-02 é de 38 para a hora do ataque; o visualizador de eventos do próprio servidor mostra 41. Faltam três eventos. O total de 41 citado para essa hora no capítulo sobre medição é o número do visualizador de eventos. A coincidência com 38, o número de falhas atribuídas ao desktop de mfoster, é uma armadilha: Jonah confere que a atribuição foi calculada a partir do conjunto completo de eventos, e não da saída incompleta do seu analisador, e registra essa conferência nas notas do caso.
Laboratório — regex que pula linhas
"""A timestamp regex that silently skips lines with milliseconds, and the fix."""
import re
lines = ["2026-05-04 08:01:12 fail admin", "2026-05-04 08:01:15.250 fail admin", "2026-05-04 08:01:19 fail admin"]
bad = re.compile(r"^(\d{4}-\d\d-\d\d \d\d:\d\d:\d\d) (\w+) (\w+)$")
good = re.compile(r"^(\d{4}-\d\d-\d\d \d\d:\d\d:\d\d(?:\.\d+)?) (\w+) (\w+)$")
print("bad regex matched:", sum(bool(bad.match(l)) for l in lines), "of", len(lines))
print("fixed regex matched:", sum(bool(good.match(l)) for l in lines), "of", len(lines))
Execute com python3 lab_regex.py. Saída verificada:
bad regex matched: 2 of 3
fixed regex matched: 3 of 3
20.3 Lendo o resultado
O padrão original exige horários como 08:01:12 e rejeita em silêncio 08:01:15.250, que tem milissegundos: ele casa 2 de 3 linhas sintéticas. O padrão corrigido torna a parte fracionária opcional e casa 3 de 3. No log real, três linhas tinham milissegundos — os três eventos que faltavam. O laboratório reproduz a falha real com três linhas para que a causa fique fácil de ver. Um padrão escrito para um único formato de carimbo de tempo é uma suposição oculta, e o log mudou de formato sem aviso. A correção é pequena, mas encontrá-la exigiu notar uma diferença de três entre duas contagens e recusar-se a aceitar qualquer uma delas até que a diferença fosse explicada.
20.4 Prevenção
O analisador agora conta as linhas não casadas e as imprime; qualquer contagem diferente de zero é investigada. Foi acrescentado um teste com formatos de carimbo de tempo mistos. Imprimir as linhas não casadas transforma uma falha silenciosa numa falha visível. O novo teste inclui uma linha com milissegundos e outra com sufixo de fuso horário, para que a próxima mudança de formato seja pega nos dados de teste, e não num caso. Jonah também acrescenta o arquivo de teste de formatos mistos ao repositório, para que quem alterar o analisador o execute automaticamente.
20.5 Causa raiz
A fonte de log passou a usar carimbos de tempo com milissegundos depois de uma atualização de software no meio do dia. A atualização mudou o formato do log no meio do dia, o que explica por que só algumas linhas foram afetadas. Jonah pede ao responsável pelo servidor o horário da atualização e confirma que ele fica entre a última linha sem milissegundos e a primeira com eles. A falha do analisador era real, mas o gatilho foi uma mudança da qual ninguém avisou a equipe de segurança. Os avisos de mudança das fontes de log agora também vão para a equipe de segurança.
20.6 Relatando a correção
As notas do caso registram a contagem original, a causa, a correção e a contagem corrigida. A nota informa a versão do analisador que produziu cada contagem, para que o leitor veja por que um número anterior difere de um posterior. Corrigir um número abertamente protege o caso: uma mudança sem explicação de 38 para 41 entre versões do rascunho levantaria dúvidas sobre todos os outros números do relatório. O número corrigido substitui o antigo em todos os relatórios que o usaram, e cada relatório registra a mudança. Quem viu o rascunho anterior é avisado diretamente.
20.7 Método geral
Compare as saídas com uma fonte independente; quando as contagens divergirem, descubra por que antes de confiar em qualquer uma delas. Neste caso, a fonte independente foi o visualizador de eventos do servidor. Outras comparações também funcionam: o número de linhas de um arquivo contra o número de linhas analisadas, a contagem de uma ferramenta contra a de outra, ou a contagem recebida por um coletor contra a contagem enviada pela fonte. Sempre que duas contagens divergem, nenhuma é considerada confiável até que o motivo seja encontrado. Registrar qual comparação foi feita também diz a um revisor como a contagem foi conferida.
Monitoramento do pipeline
Jonah acrescenta verificações simples ao pipeline de logs: linhas recebidas por hora e por fonte, comparadas com a semana anterior. Uma queda repentina significa que uma fonte parou de enviar ou que um analisador está falhando; um alerta vai para a equipe de TI. As falhas silenciosas se tornam falhas visíveis, que podem então ser corrigidas antes que se perca evidência.
Exemplo resolvido
Depois da correção, a contagem é 41, igual à do visualizador de eventos. Jonah corrige sua nota anterior: "Corrigidos os logons malsucedidos de 4 de maio, 08:00–09:00, de 38 para 41; o analisador omitia as linhas com carimbos de tempo em milissegundos (corrigido na versão 1.3 do script)."
Caso sintético. As linhas de log vêm do script do laboratório.
Erros e limites
Os testes cobrem os formatos que você prevê; as contagens de linhas não casadas pegam os que você não prevê.
Exercícios
- EX058 — Casamentos no laboratório. Quantas linhas cada regex casou? Rubrica: 3 = a ruim 2/3; a corrigida 3/3; 2 = uma; 1 = errado; 0 = nada.
- EX059 — Causa raiz. Por que os carimbos de tempo mudaram de formato? Rubrica: 3 = atualização de software passou a usar milissegundos no meio do dia; 2 = parcial; 1 = ao acaso; 0 = nada.
- EX060 — Prevenção. O que evita a recorrência? Rubrica: 3 = contar/imprimir as linhas não casadas; teste com formatos mistos; 2 = um; 1 = vago; 0 = nada.
Síntese
Cace a perda silenciosa de dados comparando com fontes independentes, contando o que os analisadores pulam e testando os formatos.
Continue estudando — capítulo 20 de 30
← Capítulo 19 (rascunho) · Índice de capítulos do curso · Capítulo 21 (rascunho) →