VPS comprometido: checklist de resposta das primeiras 24 horas (2026): desconectar primeiro ou preservar evidências primeiro?

Para a maioria dos incidentes de VPS, a ordem mais segura é:

• Primeiro cortar o acesso à rede pública
• Mas tentar manter o sistema ligado e sem reiniciar

Isso significa que o que você deve fazer é mais parecido com:

• Ajustar temporariamente os grupos de segurança / firewalls no console do provedor de nuvem
• Bloquear novo acesso de entrada
• Cortar conexões de saída suspeitas tanto quanto possível
• Se necessário, desconectar a instância da rede pública

Em vez de diretamente:

• reboot
• shutdown now

Se você já vê os seguintes sinais, isolar a rede tem prioridade sobre tudo:

• Envio contínuo de pacotes de saída, suspeita de atacar outros
• Exfiltração de dados em larga escala em andamento
• Escaneamento lateral da rede interna
• Uso como proxy, phishing ou nó de spam
• Atividade de intrusão contínua óbvia no negócio

Neste ponto, sem isolamento, o dano só vai continuar se expandindo.

Se você está diante de:

• Uma investigação de conformidade
• Vazamento de dados de clientes
• Necessidade de rastrear o caminho do ataque
• Suspeita de backdoor persistente ou intrusão avançada

Então você deve conter ainda mais o impulso de "reiniciar imediatamente".

Porque uma vez que a energia é cortada, muitas evidências voláteis desaparecem.

• Causando dano contínuo → isolar a rede primeiro
• Necessidade de preservar valor forense → não se apresse em desligar/reiniciar
• Ambos importam → isolar a rede primeiro, depois preservar a cena

Primeiro anote:

• O horário da anormalidade
• A fonte que disparou o alerta
• Qual serviço está anormal
• Quais contas/portas/processos são suspeitos

Este passo parece simples, mas depois é muito importante para revisão, comunicação e julgamento da linha do tempo.

Priorize usar:

• Firewall do provedor de nuvem
• Grupos de segurança
• Regras de rede do console

O objetivo é:

• Bloquear o atacante de continuar se conectando
• Bloquear o tráfego de saída suspeito
• Evitar danificar a cena tanto quanto possível

Você precisa se conter neste passo.

Não faça imediatamente estas coisas por pânico:

• Antivírus de um clique
• Scripts de reparo automático
• Limpar /tmp
• Excluir cron
• Diretamente apt upgrade

Todos esses podem contaminar a cena, tornando impossível rastrear a causa depois ou confirmar o escopo do impacto.

Se este VPS está rodando negócio de produção, você precisa tomar uma decisão nos primeiros 15 minutos:

• Esta máquina precisa sair do ar imediatamente?
• Existe um nó de reserva ou página de degradação estática?
• É necessário trocar o tráfego para uma máquina de backup?

Não deixe "a continuidade do negócio" para lembrar uma hora depois.

Se você já suspeita que root, usuários sudo, contas de implantação ou contas do painel foram comprometidas, pause o uso dessas contas para continuar operando, para evitar expandir a contaminação e evitar que o atacante use suas próprias operações para encobrir rastros.

Recomenda-se abrir imediatamente um registro de incidente separado:

• Quem fez o quê e quando
• Qual regra foi alterada
• Quais logs foram exportados
• Quais anormalidades foram vistas

Você vai agradecer muito por este passo depois.

1. Lista de processos atual
2. Conexões de rede atuais
3. Sessões de login e atividade de usuários
4. Logs-chave do sistema
5. Tarefas agendadas, itens de inicialização, chaves SSH, alterações de configuração do sudo
6. Logs do serviço web, banco de dados, painel, contêineres

• Existem nomes de processos anormais
• Existem relações suspeitas entre processos pai e filho
• Existem portas de escuta desconhecidas
• Existem conexões de saída para IPs desconhecidos
• Existem contas recém-criadas / chaves SSH recém-adicionadas
• Existem tarefas agendadas / serviços systemd modificados

Porque muitos comportamentos-chave do atacante só vivem no "estado de execução atual":

• Conexões de callback
• Malware residente em memória / código malicioso sem arquivo
• Tokens temporários
• Sessões de shell

Uma vez que você reinicia, esses podem desaparecer diretamente.

Se o atacante ainda está na máquina, ou existe um backdoor persistente, então as novas senhas, tokens e chaves que você acabou de trocar podem ser obtidos novamente pelo atacante em breve.

Então a ordem mais segura geralmente é:

1. Isolar o acesso primeiro
2. Confirmar o escopo do impacto
3. Invalidar sessões / tokens / chaves primeiro
4. Depois rotacionar credenciais em massa

• Senhas de usuários root / sudo
• Chaves SSH
• Contas do painel
• Contas de banco de dados
• Credenciais da máquina de implantação
• Chaves de API / Access Tokens
• Chaves de armazenamento de objetos
• Segredos de CI/CD

Se este VPS tem:

• .env
• Scripts de implantação
• Ferramentas de automação
• GitHub Actions / GitLab Runner / webhook

Então o que vaza muitas vezes não é apenas este servidor em si, mas toda uma cadeia de credenciais a montante e a jusante.

Nas seguintes situações, você normalmente deve tratar "reconstruir" como o caminho principal por padrão:

• O root foi tomado
• O ponto de entrada e a duração do ataque são incertos
• Existem rastros óbvios de persistência
• Suspeita de backdoors em nível de kernel / de altos privilégios
• O negócio permite recuperação via backup
• É impossível confirmar se o sistema ainda é confiável

Por quê?

Porque limpeza não é igual a recuperação confiável.

Excluir um programa de mineração não significa que não há um segundo backdoor; corrigir um cron não significa que não há persistência no systemd; restaurar um arquivo não significa que o atacante não modificou outra coisa.

Somente quando as seguintes condições são relativamente claras você deve considerar isso com relutância:

• O escopo do impacto é muito pequeno
• O caminho da intrusão é claro
• Não há persistência de altos privilégios
• Você tem confiança suficiente de que a limpeza está completa
• O negócio não pode ser reconstruído no curto prazo

Mesmo assim, é mais recomendável migrar para uma nova instância o quanto antes.

Se a vulnerabilidade ainda está lá, as portas ainda estão abertas e as permissões não foram ajustadas, o atacante só precisa de alguns minutos para voltar.

Você restaurou a máquina, mas as chaves antigas ainda são válidas; isso não é muito diferente de não ter restaurado nada.

Arquivos maliciosos, scripts de backdoor e backups contaminados às vezes não estão apenas no host.

Este é um dos locais de persistência mais comuns em VPS Linux.

Se você não reforçar o monitoramento dentro de uma hora após a recuperação, então na verdade você não sabe se o atacante voltou.

• Registrar a fonte da anormalidade
• Isolar a rede no nível do painel de controle
• Decidir se troca o tráfego/degrada
• Não reiniciar, não limpar a cena

• Exportar logs
• Verificar processos, portas, conexões
• Registrar alterações de contas, agendamento de tarefas, serviços
• Manter cópias de evidências-chave

• Julgar o escopo do impacto
• Invalidar sessões e tokens
• Rotacionar credenciais de alto risco
• Julgar se reconstrói diretamente

• Restaurar de backups confiáveis para um novo ambiente
• Endurecer patches, permissões, MFA, políticas de rede
• Ativar monitoramento de alta frequência
• Registrar a causa raiz, a linha do tempo e as ações pendentes

Normalmente não se recomenda o desligamento direto. A ação padrão mais segura é isolar a rede primeiro para evitar mais danos, preservando ao mesmo tempo evidências voláteis como memória, conexões e sessões tanto quanto possível.

Na maioria dos casos, desconectar a rede / isolar o acesso tem prioridade. Porque se o atacante ainda estiver online, a nova senha também pode vazar novamente em breve.

Se já envolve altos privilégios, persistência ou um escopo de impacto pouco claro, normalmente é mais recomendável reconstruir uma nova instância em vez de continuar confiando no sistema antigo.

Então você deve se apegar ainda mais à abordagem de "isolar primeiro, preservar evidências básicas, depois reconstruir". Não conserte em pânico enquanto destrói toda a cena.