Como responder a um incidente de segurança em uma VM Linux: guia técnico passo a passo

Passo a passo

1. 1

   1. Não desligue — preserve a memória volátil

   Antes de qualquer ação, capture a memória RAM com LiME (Linux Memory Extractor) ou via /proc/kcore. A memória contém processos ocultos, chaves de criptografia em uso, sessões de rede abertas e malware residente que desaparece com o desligamento. Use 'insmod lime.ko path=/mnt/evidencias/mem.lime format=lime' e documente o hash SHA-256 imediatamente para garantir a integridade forense e a cadeia de custódia.

2. 2

   2. Tire um snapshot/imagem do disco antes de tocar em qualquer arquivo

   Crie um snapshot da VM no nível do hypervisor (AWS: aws ec2 create-snapshot; GCP: gcloud compute disks snapshot) ou use 'dd if=/dev/sda | gzip | ssh backup@host dd of=disco.img.gz' para imagem bit a bit. Calcule e armazene os hashes MD5 e SHA-256 de cada imagem. Essa imagem imutável é a base da cadeia de custódia — sem ela, qualquer análise posterior pode ser contestada.

3. 3

   3. Isole a VM sem destruí-la

   Altere o Security Group (AWS), firewall rules (GCP/Azure) ou regras do iptables para bloquear todo o tráfego de entrada e saída, exceto sua sessão SSH de investigação originada de um IP de gerência confiável. Não apague a instância, não restaure o backup ainda. O objetivo é cortar a comunicação com o atacante (C2, exfiltração) mantendo o estado forense intacto para análise.

4. 4

   4. Triade de triagem: processos, conexões e persistência

   Execute em sequência rápida, redirecionando saída para arquivos com timestamp: (a) Processos — 'ps auxf', 'top -bn1', 'lsof -nP'; (b) Conexões de rede — 'ss -tulnp', 'netstat -antp', 'lsof -i'; (c) Persistência — 'crontab -l', 'cat /etc/cron.*/*', 'systemctl list-units --type=service', 'grep -r CRON /var/spool/cron/', 'cat ~/.bashrc ~/.profile', 'cat ~/.ssh/authorized_keys'. Mapeie tudo antes de alterar qualquer arquivo.

5. 5

   5. Audite usuários, logins e logs de autenticação

   Verifique 'cat /etc/passwd | awk -F: \"$3==0\"' para UID 0 indevidos; 'last -F' e 'lastb -F' para logins bem-sucedidos e falhos com IPs; 'who' e 'w' para sessões ativas; 'cat /var/log/auth.log' ou 'journalctl -u ssh --since "48 hours ago"' para tentativas de autenticação. Identifique usuários criados pelo atacante, chaves SSH inseridas e elevações de privilégio via sudo/su.

6. 6

   6. Verifique integridade de binários e rastreie rootkits

   Em sistemas RPM: 'rpm -Va 2>/dev/null | grep -E "^..5|^.M"' detecta binários alterados. Em Debian/Ubuntu: 'debsums -c'. Execute 'chkrootkit' e 'rkhunter --check --skip-keypress' de mídia externa (pen drive ou AMI limpa montada) para evitar falsos negativos causados por binários do sistema já comprometidos. Verifique também 'find / -perm -4000 -type f 2>/dev/null' para SUID indevidos.

7. 7

   7. Contenha, erradique via reprovisionamento e recupere de imagem limpa

   Após a coleta de evidências, não confie em nenhuma limpeza manual — o atacante pode ter implantado persistência em níveis que você não verá. A prática recomendada pelo NIST SP 800-61 é reprovisionar a VM a partir de uma AMI/imagem de linha de base verificada, restaurar apenas dados (não binários) de backup pré-comprometimento, e só então reintegrar ao ambiente com monitoramento intensificado (IDS/EDR, logs centralizados).

8. 8

   8. Documente, notifique e registre lições aprendidas

   Elabore o relatório de incidente com: linha do tempo (timeline), TTPs mapeados ao MITRE ATT&CK (táticas, técnicas, procedimentos), IoCs (hashes, IPs, domínios), causa raiz, impacto estimado e ações tomadas. Notifique partes internas (CISO, jurídico, comunicação) e externas obrigatórias (ANPD se dados pessoais foram expostos, conforme LGPD art. 48). Agende reunião de lições aprendidas em até 5 dias úteis após o encerramento.

Fundamentos: por que a ordem das ações importa em incidentes Linux

O NIST SP 800-61 (Computer Security Incident Handling Guide) estabelece quatro fases para resposta a incidentes: Preparação, Detecção e Análise, Contenção/Erradicação/Recuperação e Atividade Pós-Incidente. Em VMs Linux, a sequência das ações na fase de contenção é crítica porque cada ação modifica o estado do sistema — e a ordem errada pode destruir evidências antes que sejam coletadas.

A volatilidade das evidências segue uma hierarquia: registradores de CPU e estado do processo (mais voláteis), memória RAM, conexões de rede e tabelas de roteamento, processos em execução, sistemas de arquivos temporários (/tmp, /dev/shm) e, por último, arquivos em disco (menos voláteis). Essa ordem — conhecida como 'Order of Volatility' — deve guiar a sequência de coleta forense antes de qualquer ação de contenção.

Erros comuns que comprometem investigações incluem: reboot imediato 'para limpar o sistema', execução de 'rm -rf /tmp/*' antes de coletar evidências, restauração do backup antes da análise, e comunicação do incidente por canais potencialmente comprometidos. Equipes sem treinamento específico em IR tendem a cometer esses erros sob pressão, o que é um argumento técnico sólido para acionar especialistas desde o início.

Triagem forense: mapa completo dos artefatos em um sistema Linux

A triagem sistemática em Linux cobre cinco superfícies de análise. (1) Processos e memória: 'ps auxf --forest' para árvore de processos, 'lsof -nP +L1' para arquivos deletados ainda abertos (técnica comum de malware), '/proc/[PID]/maps' e '/proc/[PID]/exe' para localizar binários de processos suspeitos, 'strings /proc/[PID]/mem' para extrair artefatos da memória de um processo específico.

(2) Rede: 'ss -tulnp' lista todos os sockets com PID associado, 'iptables -L -n -v' e 'ip rule show' revelam regras de firewall que o atacante pode ter inserido, '/proc/net/tcp' e '/proc/net/udp' mostram conexões mesmo se 'netstat' estiver comprometido. (3) Persistência: além de cron e systemd já mencionados, verifique '/etc/rc.local', '/etc/init.d/', 'at -l' (jobs agendados), 'find / -name ".bashrc" -o -name ".profile" 2>/dev/null | xargs grep -l "curl\|wget\|nc "'.

(4) Autenticação e controle de acesso: além de /etc/passwd, analise '/etc/shadow' em busca de hashes recém-alterados, '/etc/group' para membros inesperados de grupos privilegiados (sudo, wheel, adm), e os logs PAM em /var/log/auth.log. (5) Integridade do sistema de arquivos: 'find / -mtime -1 -type f 2>/dev/null' lista arquivos modificados nas últimas 24h, 'stat' em binários críticos revela timestamps de modificação inconsistentes com o histórico de patches.

Cadeia de custódia e documentação forense: requisitos mínimos

Cadeia de custódia é o registro ininterrupto e verificável de quem coletou, armazenou e acessou cada evidência, e em que momento. Sem ela, evidências são inadmissíveis em processos judiciais e podem ser contestadas em auditorias regulatórias (LGPD, PCI DSS, ISO 27001). Para cada evidência coletada, registre: data e hora (UTC), responsável pela coleta, método e ferramentas utilizados, hash SHA-256 antes e após qualquer transferência, e localização de armazenamento.

Para imagens de disco e memória, use 'sha256sum' imediatamente após a captura e armazene o hash junto à evidência em meio separado (ex.: e-mail assinado digitalmente enviado para si mesmo ou para um terceiro confiável). Ferramentas como Guymager ou dc3dd geram hashes automaticamente durante a aquisição. Para logs, use 'tar czf --numeric-owner logs_$(date +%Y%m%d_%H%M%S).tar.gz /var/log/' e calcule o hash do arquivo compactado.

O relatório de incidente deve seguir estrutura padronizada: sumário executivo (para gestão), linha do tempo técnica detalhada (para a equipe de IR e jurídico), IoCs (para bloqueio e threat intelligence), análise de causa raiz (para correção), impacto estimado (para seguros e reguladores) e recomendações de remediação priorizadas. Mapear TTPs ao framework MITRE ATT&CK — como T1053 (Scheduled Task/Job), T1136 (Create Account) ou T1059 (Command and Scripting Interpreter) — facilita a comunicação entre equipes técnicas e permite correlação com ameaças conhecidas.

Erradicação e recuperação: por que reprovisionar é a única opção segura

A tentação de 'limpar' um servidor comprometido é compreensível — parece mais rápido do que reprovisionar. Na prática, é a decisão que mais frequentemente leva a recompromissos em dias ou semanas. Rootkits de nível de kernel (LKM rootkits) modificam chamadas de sistema diretamente no kernel, tornando-se invisíveis para qualquer ferramenta que rode no mesmo sistema operacional. Bootkit modificam o bootloader. Implantes em bibliotecas compartilhadas (/usr/lib/) afetam todos os processos que as carregam.

O processo correto de erradicação começa com a identificação da vulnerabilidade explorada (CVE, misconfiguration, credencial vazada) e sua correção na imagem base antes de reimplantar. Sem corrigir a causa raiz, o mesmo atacante — ou outros que compraram o acesso — recomprometerão o sistema em horas. Use infraestrutura como código (Terraform, Ansible, CloudFormation) para garantir que a nova instância seja provisionada de forma reproduzível e auditável.

Na recuperação, restaure apenas dados de negócio (banco de dados, uploads de usuário) de backups verificados anteriores ao incidente — nunca restaure binários, configurações ou scripts de fontes comprometidas. Reintegre o servidor ao ambiente de produção sob monitoramento intensificado: EDR ativo, logging de todas as chamadas de sistema (auditd), alertas de integridade de arquivos (AIDE, Wazuh) e revisão manual dos primeiros logs por 48 a 72 horas. Documente a data e hora de retorno à produção como parte da linha do tempo do incidente.

Quando acionar uma equipe especializada de resposta a incidentes

Alguns sinais indicam que o incidente excede a capacidade de resposta interna e exige especialistas externos imediatamente: (1) há evidências de exfiltração de dados sensíveis (dados pessoais, propriedade intelectual, segredos de negócio), o que pode acionar obrigações legais de notificação à ANPD em até 72 horas; (2) o comprometimento atingiu múltiplos sistemas ou parece ser um ataque direcionado (APT) com persistência sofisticada; (3) a causa raiz não foi identificada após a triagem inicial; (4) há impacto operacional crítico (sistemas de pagamento, infraestrutura de saúde, controle industrial).

Outros critérios para acionamento imediato: (5) a equipe interna não tem ferramentas forenses adequadas ou treinamento específico em IR Linux; (6) existe risco de impacto reputacional ou regulatório que exige documentação forense para defesa legal; (7) o atacante ainda está ativo no ambiente — uma equipe especializada tem capacidade de executar threat hunting e expulsão coordenada sem alertar o invasor prematuramente.

Acionar especialistas não significa perder o controle do incidente — significa ter ao lado uma equipe com ferramentas, playbooks e experiência em centenas de incidentes similares. A diferença entre uma resposta interna não estruturada e uma resposta profissional pode ser medida em horas de downtime evitado, dados não exfiltrados e multas regulatórias não aplicadas. A Decripte opera com plantão 24x7 e SLA de início de atendimento em até 4 horas para clientes com plano de resposta a incidentes contratado.

A Decripte realiza resposta a incidentes e forense digital para empresas de todos os portes — do MEI ao grupo com mais de 100.000 colaboradores — com equipe certificada, cadeia de custódia documentada e relatórios aceitos por órgãos reguladores e judiciais brasileiros. Se sua VM Linux foi comprometida ou você suspeita de comprometimento, acesse /plano/resposta-incidentes para ativar atendimento ou solicite um diagnóstico gratuito para avaliar o nível de exposição do seu ambiente.

Lições aprendidas e hardening pós-incidente: transformando crise em maturidade

A fase de lições aprendidas — obrigatória no NIST SP 800-61 — é frequentemente pulada por equipes sob pressão para voltar à normalidade. É um erro estratégico: incidentes em organizações sem esse processo tendem a se repetir com variações, porque a causa raiz estrutural não é endereçada. A reunião de pós-incidente deve ocorrer em até 5 dias úteis após o encerramento, com participação de técnicos, gestores e representantes de negócio.

As perguntas centrais da retrospectiva: como o atacante entrou (vetor inicial)? Quanto tempo ficou sem ser detectado (dwell time)? Quais controles existentes deveriam ter detectado o ataque e não detectaram? O que funcionou bem na resposta? Quais procedimentos falharam? As respostas alimentam um plano de hardening priorizado por risco real — não por compliance teórico.

Controles pós-incidente típicos para ambientes Linux: implementação de MFA para acesso SSH (chaves + TOTP via PAM), desabilitação de autenticação por senha no SSH, uso de bastion host ou VPN para acesso administrativo, implantação de AIDE ou Wazuh para integridade de arquivos em tempo real, centralização de logs em SIEM imutável (logs locais são os primeiros alvos de atacantes), segmentação de rede por função (DBs não acessíveis diretamente da internet), e programa de patch management com SLA definido por criticidade de CVE.

Termos importantes

Cadeia de Custódia

Registro documentado, cronológico e verificável de quem coletou, transferiu, acessou e armazenou cada evidência digital em uma investigação forense. Garante a integridade e autenticidade das evidências para uso em processos judiciais, auditorias regulatórias e disputas contratuais. É estabelecida calculando hashes criptográficos (SHA-256) das evidências no momento da coleta e mantendo o registro de toda a cadeia de acesso subsequente.

Dwell Time

Tempo decorrido entre o comprometimento inicial de um sistema e sua detecção pela equipe de segurança ou pelo time de resposta a incidentes. Quanto maior o dwell time, maior o potencial de dano: o atacante teve mais tempo para movimento lateral, exfiltração de dados, escalada de privilégios e estabelecimento de múltiplos pontos de persistência. A redução do dwell time é um dos principais indicadores de maturidade de um programa de segurança.

Order of Volatility

Hierarquia de evidências digitais ordenada da mais para a menos volátil, que define a sequência de coleta forense. Em ordem decrescente de volatilidade: registradores de CPU e estado de processos, memória RAM, conexões de rede e tabelas de roteamento, processos em execução, sistemas de arquivos temporários, disco rígido e, por último, logs e backups arquivados. Coleta na ordem correta preserva evidências que se perderiam com o tempo ou com ações subsequentes.

MITRE ATT&CK

Framework público mantido pela organização MITRE que categoriza e descreve táticas, técnicas e procedimentos (TTPs) usados por grupos de ameaças avançadas em ataques reais. Em resposta a incidentes Linux, é usado para mapear os artefatos encontrados (ex.: job de cron malicioso → T1053.003 Cron, chave SSH inserida → T1098.004 SSH Authorized Keys) a técnicas conhecidas, facilitando a comunicação entre equipes e a identificação de padrões de ataque específicos de grupos APT.

Perguntas frequentes