Preservação de evidências e registro de eventos para investigação

Preservação de evidências e registro de eventos (logging) são práticas complementares que permitem entender o que aconteceu em um incidente, sustentar decisões técnicas e administrativas, e viabilizar investigação interna, auditoria e, quando necessário, medidas legais. Em fraudes digitais e incidentes envolvendo engenharia social, o desafio é que parte relevante do “ataque” ocorre em canais de comunicação e em ações humanas (cliques, aprovações, transferências), enquanto outra parte ocorre em sistemas (acessos, alterações, exfiltração). Sem evidências preservadas e eventos registrados de forma confiável, a organização fica limitada a relatos e suposições.

Conceito: o que é evidência digital e o que é registro de eventos

Evidência digital é qualquer informação com valor probatório relacionada ao incidente, armazenada ou transmitida em formato digital. Pode ser um e-mail, um arquivo, um log, uma captura de tela, um extrato de transação, um áudio, um artefato de navegador, um registro de autenticação, um ticket de suporte, entre outros. O ponto central é que a evidência precisa ser íntegra (não alterada), autêntica (origem verificável), completa (contexto suficiente) e rastreável (cadeia de custódia).

Registro de eventos é a coleta sistemática de dados gerados por sistemas e aplicações sobre ações e ocorrências: logins, falhas de autenticação, criação de regras de e-mail, alterações de permissões, execução de processos, conexões de rede, mudanças em configurações, transações financeiras, eventos de endpoint, etc. Logs bem projetados permitem reconstruir uma linha do tempo e responder perguntas como: quem fez o quê, quando, de onde, em qual dispositivo, com qual credencial e qual foi o resultado.

Princípios de preservação: integridade, minimização de alterações e cadeia de custódia

Integridade e “não mexer” no que pode ser prova

Em investigação, a regra prática é: preservar primeiro, analisar depois. Muitas ações comuns “para conferir” podem destruir evidências: abrir anexos em um ambiente não controlado, encaminhar e-mails alterando cabeçalhos, reinstalar aplicativos, limpar histórico do navegador, reiniciar máquinas, “arrumar” a caixa de entrada, apagar mensagens, ou executar ferramentas de limpeza. A preservação busca reduzir alterações no estado original e registrar qualquer intervenção inevitável.

Cadeia de custódia

Cadeia de custódia é o registro contínuo de quem coletou, acessou, transferiu, armazenou e analisou a evidência, com data/hora e justificativa. Isso aumenta a confiabilidade e reduz questionamentos sobre adulteração. Mesmo em investigações internas, manter cadeia de custódia é útil para auditoria e para decisões disciplinares ou acionamento de seguradora.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Carimbo de tempo e sincronização

Eventos de diferentes sistemas só “conversam” se o tempo estiver alinhado. A organização deve garantir sincronização via NTP (ou equivalente) em servidores, endpoints, appliances e aplicações críticas. Na investigação, registre o fuso horário e se os logs estão em UTC ou horário local. Uma diferença de minutos pode mudar a interpretação de causalidade.

O que preservar: mapa prático de fontes de evidência

Em incidentes relacionados a fraude e engenharia social, as evidências costumam estar distribuídas. Abaixo um mapa de fontes comuns, com exemplos do que coletar.

Comunicações e colaboração

• E-mails: mensagem original (formato preservado), cabeçalhos completos, anexos, links, IDs de mensagem, trilha de encaminhamentos, regras criadas na caixa postal, logs de entrega e de acesso.
• Mensageria corporativa: conversas relevantes, metadados (IDs, horários, participantes), arquivos compartilhados, links, registros de chamadas.
• Telefonia/VoIP: registros de chamadas (CDR), gravações (quando existentes e permitidas), horários, ramais, números, duração.
• Videoconferência: convites, links, participantes, chat, gravações e logs de acesso.

Identidade e acesso

• Logs de autenticação: sucessos e falhas, MFA, redefinições de senha, criação de tokens, sessões ativas, mudanças de método de MFA.
• Administração de contas: criação/remoção de usuários, elevação de privilégios, delegações, consentimentos de aplicativos, chaves de API.
• Diretórios e SSO: eventos de login, alterações de grupos, políticas aplicadas.

Endpoints (estações e servidores)

• Artefatos do sistema: logs do sistema operacional, eventos de segurança, lista de processos, serviços, tarefas agendadas, conexões de rede, drivers.
• Artefatos do usuário: histórico do navegador, downloads, cache, arquivos recentes, atalhos, e-mails locais (se aplicável).
• EDR/antimalware: alertas, árvore de processos, quarentena, hashes, linha de comando, conexões externas.

Rede e perímetro

• Firewall/Proxy/DNS: consultas DNS, conexões, bloqueios, categorias, SNI/hostnames, IPs de destino, horários.
• VPN: logins, IP atribuído, localização aproximada, dispositivo, duração.
• IDS/IPS: alertas e assinaturas acionadas, tráfego associado.

Sistemas de negócio e finanças

• ERP/contas a pagar: criação/alteração de fornecedor, alteração de dados bancários, aprovação de pagamentos, trilhas de auditoria.
• Banco e conciliação: comprovantes, horários, beneficiário, conta, agência, identificadores de transação, canal utilizado.
• CRM/tickets: solicitações, aprovações, anexos, comentários, histórico de mudanças.

Fontes “não óbvias”

• Capturas de tela e fotos: úteis para preservar estado de telas, mensagens efêmeras, pop-ups, erros e instruções recebidas.
• Relatos: depoimentos curtos e objetivos de quem recebeu a mensagem, com horário aproximado, ações realizadas e contexto.
• Documentos físicos: anotações, números de telefone, instruções recebidas, comprovantes impressos.

Passo a passo prático: preservação de evidências em um incidente

O passo a passo abaixo é aplicável a diferentes cenários (tentativa de fraude, fraude consumada, comprometimento de conta). Ajuste conforme políticas internas, privacidade e orientação jurídica.

1) Ative um “modo preservação” e defina responsáveis

Assim que houver suspeita razoável, defina um responsável técnico (TI/Segurança) e um responsável de negócio (ex.: Financeiro, RH, Jurídico). Estabeleça um canal de comunicação interno para o caso e evite discutir detalhes em canais potencialmente comprometidos. Registre: data/hora de abertura, quem reportou, descrição inicial e sistemas possivelmente envolvidos.

2) Estabilize sem destruir evidências

Se for necessário conter risco imediato (por exemplo, bloquear uma conta), faça, mas registre exatamente o que foi feito, por quem e quando. Evite ações irreversíveis antes de coletar dados mínimos. Exemplos de contenção com cuidado: desabilitar login, revogar sessões, bloquear regras suspeitas, isolar endpoint da rede (sem desligar), suspender processamento de pagamento.

3) Colete evidências voláteis primeiro (quando aplicável)

Alguns dados somem ao reiniciar ou com o passar do tempo: sessões ativas, conexões de rede, processos em execução, conteúdo de memória, logs de curto prazo. Em endpoints suspeitos, priorize: hora do sistema, usuários logados, conexões ativas, processos, tarefas agendadas, e exportação de logs relevantes. Se a equipe não tiver maturidade para coleta forense, limite-se a preservar o máximo possível sem “fuçar” e acione suporte especializado.

4) Preserve a mensagem original e metadados (e-mail/mensageria)

Para e-mails, o ideal é exportar a mensagem em formato que mantenha cabeçalhos e estrutura (por exemplo, .eml ou equivalente), além de capturar cabeçalhos completos. Não copie e cole o conteúdo em um documento, pois isso perde metadados. Preserve anexos separadamente e registre o hash (ex.: SHA-256) dos arquivos coletados. Para mensageria, exporte conversas e metadados conforme a ferramenta permitir e faça capturas de tela com data/hora visível quando a exportação não for possível.

5) Faça uma linha do tempo inicial (timeline) baseada em fatos

Crie uma timeline com eventos confirmados: recebimento de mensagem, clique, login, alteração de dados, aprovação, transferência, alertas do EDR, etc. Para cada item, registre fonte (log, e-mail, relato), horário e nível de confiança. Isso orienta quais logs buscar e evita investigações “no escuro”.

6) Centralize e proteja o armazenamento das evidências

Use um repositório controlado (pasta com permissões restritas, cofre de evidências, sistema de tickets com anexos). Evite armazenar em dispositivos pessoais. Defina convenção de nomes (data-hora_sistema_tipo_descrição) e mantenha um inventário: o que foi coletado, de onde, por quem, hash, local de armazenamento, observações.

7) Calcule hashes e registre procedimentos

Para arquivos coletados (anexos, exportações, logs), calcule hash criptográfico e registre em um documento de cadeia de custódia. Se o arquivo precisar ser transferido, recalcule hash no destino para confirmar integridade. Registre também a ferramenta e versão usada para coleta/exportação quando possível.

8) Preserve logs com retenção curta imediatamente

Alguns sistemas retêm logs por poucos dias. Priorize exportar ou “congelar” logs de: autenticação, e-mail, proxy/DNS, EDR, VPN e trilhas de auditoria de sistemas financeiros. Se houver SIEM, crie um caso e marque o intervalo de tempo para retenção estendida.

9) Documente decisões e exceções

Se uma evidência não puder ser coletada (por limitação técnica, privacidade, falta de acesso), registre a razão e o impacto. Se for necessário reiniciar um servidor, atualizar um agente ou aplicar correção urgente, registre antes/depois e o horário exato. Em investigação, “o que não foi registrado” tende a virar dúvida.

Registro de eventos (logging): como estruturar para investigação

Preservar evidências após o incidente é essencial, mas a qualidade da investigação depende do que foi registrado antes. Um programa de logging voltado a fraudes e engenharia social deve focar em identidade, comunicação, mudanças sensíveis e trilhas de aprovação.

O que um bom log precisa ter

• Quem: usuário, conta de serviço, ID de sessão, origem (IP, dispositivo), método de autenticação.
• O quê: ação (criar regra, alterar fornecedor, aprovar pagamento), objeto afetado (qual registro), resultado (sucesso/falha).
• Quando: timestamp preciso e fuso/UTC.
• Onde: sistema, aplicação, tenant, endpoint, localização aproximada (quando disponível).
• Contexto: user-agent, ID de correlação, motivo/justificativa (em fluxos de aprovação), campos alterados (antes/depois) quando possível.

Eventos críticos para fraudes e comprometimento de contas

• Logins de localizações incomuns, novos dispositivos, falhas repetidas, bypass de MFA, redefinições de senha.
• Criação de regras de encaminhamento, redirecionamento, exclusão automática e alterações em configurações de caixa postal.
• Consentimento de aplicativos e criação de tokens/chaves que permitam acesso persistente.
• Alterações em dados bancários de fornecedores/beneficiários e mudanças em limites de aprovação.
• Criação de novos usuários, elevação de privilégios, delegações e compartilhamentos externos.
• Downloads em massa, exportações de dados, acessos fora do horário padrão.

Centralização, correlação e retenção

Logs distribuídos em cada sistema dificultam correlação. Centralize em um SIEM ou plataforma de logs com busca e retenção adequadas. Defina retenção com base em risco e requisitos regulatórios/contratuais. Para investigação de fraudes, retenções curtas (7–30 dias) frequentemente são insuficientes, pois a descoberta pode ocorrer semanas depois. Além de reter, é importante garantir imutabilidade (WORM/lock) ou controles que impeçam alteração sem rastreabilidade.

Qualidade do logging: evitar “ruído” e lacunas

Excesso de logs sem estrutura atrapalha. Padronize campos (ex.: user_id, ip, device_id, action, object_id) e use IDs de correlação entre sistemas (por exemplo, um ID de transação que apareça no ERP e no sistema de pagamentos). Monitore falhas de coleta (agentes offline, filas cheias, limites de API) e trate como incidente operacional: log que não chega é evidência que não existirá.

Passo a passo prático: construir uma trilha de auditoria para eventos sensíveis

1) Liste processos e eventos “sensíveis”

Mapeie ações que, se manipuladas, geram perda financeira ou exposição: alteração de dados de pagamento, criação de beneficiário, aprovação fora de política, mudança de e-mail/telefone de contato, concessão de acesso privilegiado, exportação de base de clientes.

2) Defina quais campos precisam de “antes e depois”

Para alterações críticas, registre valores anteriores e novos (ou ao menos o delta), quem aprovou e qual justificativa foi fornecida. Exemplo: mudança de conta bancária deve registrar banco/agência/conta anteriores e novos, data/hora, usuário solicitante, aprovador e ticket associado.

3) Exija vinculação a um identificador de caso

Integre o evento sensível a um ticket, solicitação ou workflow com ID único. Isso cria rastreabilidade entre “pedido”, “aprovação” e “execução”. Em investigação, esse vínculo reduz discussões sobre “quem pediu” versus “quem executou”.

4) Separe funções e registre cada etapa

Mesmo quando a organização já aplica segregação, garanta que o log capture cada etapa: solicitação, revisão, aprovação, execução e confirmação. Se uma etapa for pulada por exceção, registre a exceção e o responsável.

5) Proteja os logs como ativo crítico

Controle acesso aos logs (privilégio mínimo), habilite alertas para alterações em políticas de logging, e mantenha backups/replicação. Em incidentes, atacantes podem tentar apagar rastros; por isso, logs devem estar fora do alcance de contas comuns e, idealmente, com mecanismos de imutabilidade.

Exemplos práticos de preservação e registro (sem repetir conteúdos anteriores)

Exemplo 1: suspeita de comprometimento de conta corporativa

Um colaborador relata que “algo estranho” ocorreu na conta: mensagens lidas sem ele abrir, regras novas, ou alertas de login. Preservação recomendada: exportar mensagens suspeitas com cabeçalhos completos, coletar logs de autenticação do período, registrar regras e delegações existentes, exportar trilha de auditoria de alterações na conta, coletar evidências do endpoint (processos, conexões, alertas do EDR) e preservar logs de proxy/DNS para identificar destinos acessados. Logging preventivo: eventos de criação de regras, consentimento de aplicativos, logins de novos dispositivos e alterações de MFA devem gerar alertas e ficar retidos por período adequado.

Exemplo 2: pagamento realizado com dados alterados

Ao identificar um pagamento suspeito, a prioridade é preservar a trilha completa: solicitação original, aprovações, alterações cadastrais do beneficiário, logs do ERP, comprovantes bancários e comunicações relacionadas. Passo a passo: congelar o registro do fornecedor/beneficiário (sem editar), exportar trilha de auditoria do cadastro, coletar logs de quem acessou e alterou, preservar o ticket/workflow associado, e registrar horários exatos de aprovação e execução. Logging preventivo: alterações de dados bancários devem exigir workflow e gerar log com antes/depois, além de alertas para mudanças fora do padrão (horário incomum, usuário não habitual, múltiplas alterações em sequência).

Exemplo 3: mensagem efêmera em mensageria com instrução operacional

Quando a instrução aparece em canal com mensagens que podem ser apagadas, a preservação precisa ser rápida: capturas de tela com contexto (participantes, horário, conteúdo), exportação do chat se disponível, coleta de metadados (IDs, links, anexos) e registro do dispositivo usado. Logging preventivo: habilitar retenção e eDiscovery quando aplicável, e registrar eventos de deleção/edição de mensagens em canais sensíveis.

Modelos e checklists operacionais

Checklist de preservação imediata (primeiras 2 horas)

• Registrar data/hora da detecção e quem reportou.
• Definir responsáveis e canal interno do caso.
• Identificar contas, sistemas e dispositivos envolvidos.
• Aplicar contenção mínima necessária, registrando ações.
• Preservar comunicações originais (exportação + cabeçalhos/metadados).
• Exportar logs de autenticação e auditoria do intervalo crítico.
• Coletar evidências voláteis do endpoint, se aplicável.
• Armazenar evidências em repositório controlado e calcular hashes.
• Iniciar timeline com fontes e nível de confiança.

Modelo simples de registro de cadeia de custódia

Item: [ID-001] Email suspeito (export .eml) + anexo.pdf  Data/hora coleta: 2026-01-12 10:35 (UTC-3)  Coletado por: Nome / Área  Fonte: Caixa postal usuario@empresa  Método: Exportação preservando cabeçalhos  Hash SHA-256: [hash do .eml] / [hash do anexo]  Armazenamento: Cofre de evidências / caminho  Acessos/transferências: 2026-01-12 11:10 - transferido para repositório forense por Nome  Observações: Contenção aplicada às 10:40 (revogação de sessões)

Campos mínimos para um log investigável (padrão recomendado)

timestamp_utc, system, environment, event_type, action, result, user_id, session_id, source_ip, device_id, user_agent, object_type, object_id, fields_changed, correlation_id

Cuidados legais, privacidade e governança

Preservar evidências envolve dados pessoais e, às vezes, conteúdo sensível. Defina previamente, com apoio jurídico e de privacidade, bases e limites: quem pode coletar, quem pode acessar, por quanto tempo reter, como anonimizar quando possível e como responder a solicitações internas/externas. Em alguns contextos, gravações e monitoramento exigem avisos e políticas claras. Na prática, a governança evita que uma investigação bem-intencionada gere novos riscos (exposição indevida, violação de confidencialidade, quebra de compliance).

Erros comuns que comprometem a investigação

• Encaminhar e-mail suspeito em vez de exportar a mensagem original, perdendo cabeçalhos e metadados.
• “Limpar” a caixa de entrada ou apagar mensagens para reduzir risco, destruindo contexto.
• Reinstalar ou formatar o endpoint antes de coletar dados mínimos.
• Não registrar horários e fuso, tornando a timeline inconsistente.
• Coletar evidências em dispositivos pessoais ou sem controle de acesso.
• Logs sem retenção ou com lacunas (agentes offline, auditoria desativada).
• Ausência de trilha de auditoria em sistemas de negócio, impedindo atribuição e reconstrução de ações.