Capítulo 6 — Perícia digital e análise de malware: avaliação controlada
Mapa da aula
Aula 06 publicada. Mapa, exemplo, EX026.
flowchart TD
N0["6.1 A pergunta"]
N1["6.2 Logs rotativos"]
N2["Laboratório — retenção sob diferentes taxas"]
N3["6.3 Ler o resultado"]
N4["6.4 Distinguir limpeza de rotação"]
N5["6.5 Teste controlado"]
N6["6.6 Mudança de prontidão"]
N7["6.7 Relato"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX026"]
Desenho lógico
flowchart LR
N0["6.1 A pergunta"]
N1["6.2 Logs rotativos"]
N2["Laboratório — retenção sob diferentes taxas"]
N3["6.3 Ler o resultado"]
N4["6.4 Distinguir limpeza de rotação"]
N5["6.5 Teste controlado"]
N6["6.6 Mudança de prontidão"]
N7["6.7 Relato"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]
[6.1 A pergunta]
|
v
[6.2 Logs rotativos]
|
v
[Laboratório — retenção sob diferentes taxas]
|
v
[6.3 Ler o resultado]
|
v
[6.4 Distinguir limpeza de rotação]
|
v
[6.5 Teste controlado]
|
v
[6.6 Mudança de prontidão]
|
v
[6.7 Relato]
|
v
[Exemplo resolvido] --> [Exercício EX026]
Objetivos de aprendizagem
Você vai (1) avaliar por quanto tempo a evidência em logs sobrevive; (2) modelar a retenção sob diferentes taxas de eventos; (3) projetar um teste controlado da configuração de logs; (4) aplicar os resultados à prontidão.
6.1 A pergunta
Durante o incidente, Aiyana descobriu que os logs de segurança de várias estações de trabalho começavam só algumas horas antes do ataque. O atacante os apagou ou eles simplesmente rotacionaram? Marta ordena uma avaliação controlada. A resposta importa para o laudo: um log apagado é uma ação do atacante e uma constatação, enquanto um log rotacionado é um limite de configuração e uma lacuna de prontidão. Chamar todo log curto de "apagado" exageraria o que o atacante fez, e chamar todos de "rotacionados" poderia esconder atividade antiforense. Marta quer um método testado que separe os dois padrões em cada host afetado.
6.2 Logs rotativos
Muitos logs têm tamanho fixo; quando enchem, as entradas mais antigas são sobrescritas. Quanto tempo um evento sobrevive depende da capacidade do log e da taxa de eventos. A aritmética é simples: o tempo guardado é igual à capacidade dividida pela taxa de eventos. Um log de estação de trabalho que guarda semanas de atividade tranquila pode guardar apenas horas quando um ransomware ou um atacante gera milhares de eventos por hora. O laboratório abaixo mostra o quanto a taxa de eventos muda o histórico que um log guarda. Os logs de segurança das estações de trabalho da Corvane usam um tamanho fixo desse tipo.
Laboratório — retenção sob diferentes taxas
"""How long do events survive in a fixed-size rotating log? (synthetic)"""
capacity = 20_000 # events the log holds
for label, rate in [("quiet", 150), ("normal", 600), ("attack burst", 4000)]:
print(f"{label:12} {rate:5} events/h -> oldest event kept ~{capacity/rate:6.1f} h")
Execute com python3 lab_retention.py. Saída verificada:
quiet 150 events/h -> oldest event kept ~ 133.3 h
normal 600 events/h -> oldest event kept ~ 33.3 h
attack burst 4000 events/h -> oldest event kept ~ 5.0 h
6.3 Ler o resultado
Um log com capacidade para 20.000 eventos guarda cerca de 133 horas de histórico a 150 eventos por hora, 33 horas a 600 e apenas 5 horas durante uma rajada de 4.000 eventos por hora. A atividade ruidosa de um atacante — ou as próprias operações de arquivo do ransomware, se registradas — pode empurrar para fora evidências anteriores em poucas horas, sem nenhuma limpeza deliberada. O modelo oferece, portanto, uma explicação inocente para os logs das estações que começavam poucas horas antes do ataque, mas não mostra quais hosts foram apagados; isso exige o evento de log apagado ou um início abrupto, conferidos host a host.
6.4 Distinguir limpeza de rotação
A limpeza deliberada costuma deixar o próprio registro (um evento de log apagado) e um início abrupto; a rotação mostra um log contínuo cuja entrada mais antiga simplesmente avança. Aiyana confere os dois padrões nos hosts afetados: dois mostram eventos de limpeza, os demais mostram rotação. A conferência é feita host a host: para cada log curto, Aiyana procura um registro de log apagado no início e a continuidade das entradas seguintes. A WS-07 se encaixa no padrão de limpeza, o que é coerente com seu papel de host infectado primeiro. Relatar os dois padrões separadamente mantém as ações do atacante distintas da configuração da Corvane.
6.5 Teste controlado
Em máquinas de teste com a configuração de produção, a equipe gera atividade sintética realista e mede quanto tempo os eventos sobrevivem, confirmando o modelo com margem de 10%. O teste usa o mesmo tamanho de log e as mesmas configurações de auditoria das estações de produção da Corvane, com atividade sintética em taxas tranquila, normal e de rajada. Os tempos de sobrevivência medidos ficam a menos de 10% das 133, 33 e 5 horas do modelo. O modelo pode então ser citado no laudo como testado, e não apenas calculado. As configurações do teste, os scripts de atividade e as medições são guardados para que o teste possa ser repetido quando o tamanho dos logs mudar.
6.6 Mudança de prontidão
Encaminhar os logs de segurança ao coletor central quase em tempo real e ampliar os logs locais, para que a rotação deixe de destruir evidências. Com o encaminhamento central, um evento sobrevive assim que o coletor o recebe, aconteça o que acontecer depois com o log local. Logs locais maiores acrescentam uma margem caso o encaminhamento seja interrompido. A mudança trata diretamente do padrão da WS-12; não impede que um atacante apague os logs locais, mas a cópia encaminhada permanece. As duas mudanças entram na política de prontidão e são testadas nos exercícios técnicos semestrais.
6.7 Relato
O laudo distingue os hosts com logs apagados (ação do atacante) dos que rotacionaram (limite de configuração). No CF-21, o laudo aponta a WS-07 e o outro host apagado como ação do atacante, com os eventos de log apagado como evidência. Os hosts rotacionados, como a WS-12, são listados entre os limites, com o modelo e o teste controlado explicando por que seu histórico era curto. Os leitores podem então ver quais lacunas foram causadas pelo atacante e quais pela configuração. As suposições do modelo, como taxas de eventos constantes, são declaradas junto com ele, para que os leitores conheçam seus limites.
Exemplo resolvido
O log da WS-07 começa às 01:05 com um evento de log apagado registrado sob uma conta de administrador; o da WS-12 começa às 22:40, sem esse evento e com entradas contínuas. Aiyana relata a WS-07 como apagada deliberadamente e a WS-12 como rotacionada durante atividade intensa.
Caso sintético. As taxas são geradas pelo script do laboratório.
Erros e limites
O modelo supõe taxas constantes; as rajadas reais variam, por isso teste com atividade realista.
Exercícios
- EX026 — Retenção no laboratório. Informe as horas de retenção nas três taxas. Rubrica: 3 = ~133, ~33, ~5 horas; 2 = duas; 1 = uma; 0 = nada.
- EX027 — Limpeza ou rotação. Como os dois padrões diferem? Rubrica: 3 = evento de limpeza e início abrupto contra log contínuo com a entrada mais antiga avançando; 2 = parcial; 1 = iguais; 0 = nada.
- EX028 — WS-07 e WS-12. Como cada host foi classificado? Rubrica: 3 = WS-07 apagada; WS-12 rotacionada; 2 = um; 1 = invertido; 0 = nada.
- EX029 — Mudança de prontidão. Que mudança de configuração foi recomendada? Rubrica: 3 = encaminhamento central quase em tempo real; logs maiores; 2 = uma; 1 = vago; 0 = nada.
- EX030 — Verificação do modelo. Como o modelo foi validado? Rubrica: 3 = teste controlado com a configuração de produção, dentro de 10%; 2 = parcial; 1 = suposto; 0 = nada.
Síntese
A avaliação controlada separa a ação do atacante dos limites de configuração e orienta mudanças de prontidão.
Continue estudando — capítulo 06 de 12
← Capítulo 05 (rascunho) · Índice de capítulos do curso · Capítulo 07 (rascunho) →