Site, app ou SaaS invadido: o que fazer nas primeiras 24 horas em 2026

Se você está lendo isso porque está acontecendo agora: respira. Os próximos passos importam mais do que o pânico. Esse texto é um guia cronológico — minutos, primeiras horas, primeiras 24 horas — feito para quem está descobrindo que sofreu (ou está sofrendo) um ataque na plataforma da empresa.

Se você está lendo antes de qualquer incidente: melhor ainda. Salve este link em algum lugar acessível (Notion da empresa, Google Drive compartilhado, README do GitHub). No dia que precisar, você não vai ter cabeça pra procurar.

Antes de qualquer coisa: você está mesmo invadido?

Sintomas comuns que geralmente indicam ataque real:

• Conteúdo do site mudou sozinho (mensagens estranhas, defacement)
• Clientes reclamando que receberam emails que vocês não enviaram
• Cobranças no cartão da empresa que vocês não fizeram
• Pedido de resgate por email (ransomware)
• Banco notificando movimentação suspeita de conta corporativa
• Hospedagem (Vercel, AWS, Hostinger) avisando uso anormal de recursos
• Servidor lentíssimo sem motivo aparente
• Logs estranhos que ninguém da equipe explicou

Sintomas que podem ser outras coisas:

• Site fora do ar (geralmente é DNS, hospedagem ou bug — nem todo apagão é hacker)
• Erro 500 isolado (geralmente é deploy ruim)
• Cliente reportando que viu dado errado (pode ser bug)

Importante: mesmo com dúvida, trate os primeiros passos como se fosse ataque real. Custo de tratar incidente que não existe = pequeno. Custo de ignorar incidente real por horas = enorme.

🚨 Primeiros 15 minutos — não faça besteira

O que NÃO fazer (importante)

• Não desligue o servidor. Você apaga rastros e dificulta investigação posterior. Isolar é diferente dedesligar.
• Não delete arquivos suspeitos. Eles são prova. Você vai precisar pra entender como entraram.
• Não troque senhas no painel atacado. Se o atacante ainda tem acesso, ele vê a senha nova. Troque por canais independentes (você verá no passo 5).
• Não fale com cliente ou imprensa antes de entender o escopo. Comunicação errada cedo gera processo, pânico desnecessário e perda de credibilidade.
• Não pague resgate (ransomware). Pagar não garante recuperação — relatórios da Sophos e Veeam mostram que cerca de 1 em cada 3 organizações que pagam não conseguem recuperar todos os dados. E pagar marca sua empresa como alvo dócil: vítima que paga é frequentemente atacada de novo nos meses seguintes.
• Não tente “corrigir o bug” sem entender o que aconteceu. Você pode estar fechando porta 1 enquanto o atacante entra pela 2.

O que fazer agora (em ordem)

Passo 1 — Acionar resposta organizada (5 min)

Avise por canal seguro (WhatsApp/Signal pessoal, NÃO email da empresa) as 3 a 5 pessoas-chave:

• Sócio/CEO
• Líder técnico (CTO ou dev sênior)
• Responsável pelo financeiro
• Jurídico (interno ou advogado externo)
• Encarregado de Dados (DPO), se houver

Ative uma war room virtual (Discord, Slack canal privado, ou ligação em conferência). Defina UMA pessoa como coordenadora — sem coordenador, todo mundo faz tudo errado em paralelo.

Passo 2 — Documentar tudo (5 min, em paralelo)

Crie um Google Doc ou Notion com timestamp. A partir de agora, anote:

• Quando vocês perceberam (data e hora exata, com fuso)
• Como perceberam (cliente, log, alerta automático)
• O que viram exatamente (screenshots, mensagens copiadas)
• Cada decisão tomada e por quem

Esse documento vale ouro para: comunicação à ANPD (LGPD), investigação posterior, defesa em processo judicial, e relatório aos clientes. Sem timeline documentado, o pós-incidente vira pesadelo de versões conflitantes.

Passo 3 — Isolar (sem desligar) — 15 min

“Isolar” significa: fechar o acesso do atacante, sem destruir os rastros dele. Em ordem:

• Cloudflare:ative “Under Attack Mode” (Security → Under Attack Mode). Isso adiciona challenge JS em todo request, dificultando ataque automatizado.
• Bloquear IPs suspeitos identificados nos logs (Cloudflare → Security → Tools → IP Access Rules).
• Desativar painéis administrativos temporariamente (rota /admin retornando 503 manualmente).
• Revogar tokens de API emitidos (Stripe, OpenAI, Resend, etc. — todas as chaves precisam ser rotacionadas).
• Não deletar logs nem arquivos suspeitos. Cópie-os para fora do servidor, mas mantenha os originais.

Passo 4 — Snapshot de tudo (30 min)

Antes de mais qualquer mudança, tire fotografia digital do estado atual:

• Snapshot do servidor (AWS, Google Cloud, Vercel deployment hash atual)
• Backup do banco de dados em S3 / Drive separado
• Cópia dos logs da hospedagem (últimos 30 dias se possível)
• Cópia dos logs do Cloudflare (últimos 7 dias)
• Histórico de commits do Git (rebase, force-push?)
• Lista atual de usuários com permissão admin

Esses arquivos vão ser críticos para investigação. Sem eles, você não descobre como entraram, e fica vulnerável a entrar de novo.

Passo 5 — Trocar credenciais (1h)

Em ordem de prioridade:

1. Email principal da empresa(geralmente o “rei” — quem tem acesso ao email reseta senha de tudo)
2. Painel da hospedagem (Vercel, AWS, Hostinger)
3. Painel do Cloudflare
4. Painel do registrador de domínio (Registro.br, GoDaddy)
5. Banco / financeiro (separar imediatamente)
6. Stripe / PagSeguro / Mercado Pago
7. GitHub / GitLab / Bitbucket
8. SaaS críticos (Slack, Discord, Notion, Google Workspace)
9. Banco de dados (rotacionar senha do usuário admin)
10. Tokens de integração (OpenAI, OAuth secrets, JWT signing keys)

Importante: senhas novas devem usar gerenciador (1Password, Bitwarden), e cada conta crítica deve ter 2FA com app autenticador (Authy, Google Authenticator), não SMS (SMS é vulnerável a SIM swap).

Passo 6 — Avaliar dados expostos (2–4h)

Pergunta crítica: o que o atacante teve acesso?

Categorize:

• Dados pessoais de clientes (CPF, email, telefone, endereço, dados bancários) — gatilha LGPD
• Dados financeiros (transações, saldos, dados de cartão) — gatilha Bacen e PCI-DSS
• Dados sensíveis (saúde, jurídico, escolar) — gatilha LGPD + multa agravada
• Credenciais de clientes (senhas hasheadas, tokens) — atenção máxima
• Conteúdo proprietário (código-fonte, documentos internos)
• Dados públicos (já estavam acessíveis) — gravidade baixa

Se houve acesso a dados pessoais, o relógio da LGPD começou a contar. O Art. 48 exige que você comunique em prazo razoávela ANPD e os titulares afetados quando o incidente puder causar “risco ou dano relevante”. Não há prazo fixo na lei, mas a ANPD interpreta como 2 a 5 dias úteis em casos graves.

Passo 7 — Comunicar partes obrigatórias (4–24h)

ANPD (se há dados pessoais expostos)

Formulário oficial: gov.br/anpd. Você precisa informar:

• Natureza dos dados afetados
• Número aproximado de titulares
• Riscos prováveis
• Medidas adotadas
• Cronograma de comunicação aos titulares

Clientes afetados

Comunicado direto, em linguagem clara, contendo:

• O que aconteceu, em 2 frases
• Quais dados podem ter sido expostos
• O que vocês estão fazendo
• O que o cliente deve fazer (trocar senha, ativar 2FA, monitorar conta)
• Canal direto pra dúvidas

Não minta, não minimize, não use jargão. Cliente que descobre que você escondeu informação processa.

Banco / Bacen (se é instituição financeira)

Resolução Bacen 4.893 e BCB 85 exigem comunicação imediata em caso de incidente cibernético em IF/IP. Prazo curto, multa pesada se atrasa.

Passo 8 — Investigação técnica (24–72h)

Aqui geralmente entra empresa especializada (forense + pentest). Objetivo: responder com certeza:

• Por onde o atacante entrou
• Quanto tempo ficou dentro
• O que ele fez
• Se ele ainda tem algum acesso
• Se há outras vulnerabilidades exploráveis (pra fechar antes de subir o sistema)

Sem essa investigação, vocês podem corrigir o sintoma e deixar a causa intacta. Atacante volta em 30 dias por outra porta.

Passo 9 — Remediação + retorno seguro (3–14 dias)

Antes de subir o sistema novamente:

• Vulnerabilidade explorada precisa estar corrigida
• Outras vulnerabilidades graves identificadas precisam estar corrigidas
• Credenciais comprometidas todas rotacionadas
• Backups validados (não basta ter, tem que testar restore)
• Monitoramento adicional ativado (alerta para padrões similares)
• Re-test feito por terceiro independente

O que esperar do mês seguinte

Estimativa realista, baseada em incidentes públicos brasileiros:

Total típico de incidente médio em SaaS brasileiro: R$ 200.000 a R$ 1.500.000. Pentest preventivo anual custa fração disso.

O melhor momento de ler isso era ontem

Se você está descobrindo este texto em modo emergência, fale com a gente: a No Vuln tem capacidade de pentest emergencial + forense para responder em 24h. Mande mensagem com “EMERGÊNCIA” no assunto pra [email protected] ou WhatsApp.

Se você está descobrindo este texto preventivamente: bom sinal. Marque uma call e a gente avalia o que precisa ser blindado antes de virar emergência.