Minha aplicação foi invadida: o que fazer agora

Uma invasão raramente aparece como uma mensagem de erro clara. O sinal costuma ser indireto: o site mostra uma página que você não fez, o uso de CPU fica em 100% sem tráfego, a conta da API de IA chega alta, aparece um administrador que ninguém criou ou o banco de dados some e no lugar dele fica um pedido de resgate.

Nessa hora, a vontade é apagar o que parece estranho e seguir em frente. Esse é o erro mais comum: você destrói as pistas de como o invasor entrou e deixa a porta aberta para ele voltar. A ordem abaixo segue as recomendações de resposta a incidentes do NIST SP 800-61: conter primeiro, depois investigar, recuperar e prevenir.

Como saber se a aplicação foi mesmo invadida?#

Procure estes sinais, do mais ao menos comum em aplicações pequenas:

• Arquivos alterados ou novos que não estão no seu repositório, como scripts injetados no HTML ou um arquivo .php numa aplicação Node.js.
• CPU alta e constante sem aumento de visitas. Mineradores de criptomoeda são a carga típica depois de uma invasão.
• Contas e cobranças estranhas: usuários administradores novos, uso alto em APIs pagas, e-mails enviados em massa pelo seu provedor.
• Dados apagados ou criptografados, às vezes com uma tabela ou coleção nova contendo um pedido de resgate.
• Requisições bem-sucedidas a arquivos sensíveis nos logs de acesso, como esta (exemplo):

203.0.113.7 - - [12/Oct/2026:03:14:07 +0000] "GET /.env HTTP/1.1" 200 1532 "-" "Mozilla/5.0"

O 200 nessa linha significa que o servidor entregou o arquivo .env com todos os seus segredos. Teste agora se o seu site expõe arquivos que nunca deveriam ser públicos. A resposta esperada é 404 ou 403:

for path in .env .git/config; do
  printf '%s -> ' "$path"
  curl -s -o /dev/null -w "%{http_code}\n" "https://www.seusite.com.br/$path"
done

Se você tem os logs de acesso em arquivo, procure as requisições que deram certo:

grep -E '"GET /\.(env|git)' access.log | grep -E '" 200 '

O que fazer na primeira hora?#

Siga esta ordem. Não comece pela limpeza.

1. Contenha. Pare a aplicação ou bloqueie o acesso público. Uma aplicação fora do ar por uma hora custa menos do que um invasor ativo por mais uma hora.
2. Preserve as evidências. Antes de apagar qualquer coisa, baixe os logs e uma cópia dos arquivos que estão no servidor. Sem esse material, você não descobre a causa.
3. Troque todos os segredos. Senhas do banco, tokens de bot, chaves de API, chaves de assinatura de sessão e JWT, credenciais de e-mail e de armazenamento. Considere comprometido tudo o que a aplicação conseguia ler, inclusive as variáveis de ambiente.
4. Proteja as contas ao redor. Troque a senha e ative a autenticação em duas etapas no GitHub, no registrador do domínio e no painel da hospedagem. Encerre as sessões abertas.
5. Invalide as sessões dos usuários. Trocar a chave de assinatura de sessão ou JWT derruba os logins existentes, inclusive os do invasor.

Para tokens de bot e chaves de API, os passos detalhados estão em vazou o token do bot e chave de API exposta no GitHub.

Por onde o invasor costuma entrar?#

Estas são as causas mais comuns em aplicações pequenas, da mais à menos frequente.

Segredos vazados#

Um .env commitado num repositório público, servido pelo próprio site ou incluído num ZIP compartilhado. Confira o histórico do Git e o teste com curl acima. Um segredo vazado pode explicar a invasão inteira: quem tinha a senha do banco não precisou de nenhuma falha no código.

Banco de dados exposto sem senha#

Um banco aberto para a internet sem autenticação cai em pouco tempo nas mãos de robôs que varrem endereços. A documentação de administração do Redis avisa que, por padrão, ele não exige autenticação e escuta em todas as interfaces de rede. O MongoDB escuta só em localhost por padrão, segundo a documentação de segurança, mas muita gente troca para 0.0.0.0 para "fazer funcionar". Confira se o seu banco exige senha e se só aceita conexões da aplicação.

Dependência vulnerável#

Uma biblioteca desatualizada com falha conhecida. Rode a auditoria da sua linguagem e compare a data de publicação das falhas com a data da invasão:

npm audit --audit-level=high
pip-audit -r requirements.txt

O npm audit consulta o registro por vulnerabilidades conhecidas nas suas dependências e sai com erro quando encontra algo no nível indicado. O pip-audit faz o mesmo para Python.

Falha no seu código#

Injeção de SQL por concatenar texto na consulta, upload que aceita qualquer extensão e salva em pasta pública, comando de sistema montado com entrada do usuário, rota administrativa sem verificação de permissão. Procure nos logs de acesso as rotas que receberam requisições estranhas pouco antes dos primeiros sinais.

Senha fraca ou conta comprometida#

Painel administrativo com senha curta e sem limite de tentativas, ou a conta do GitHub de alguém da equipe. Se o invasor fez commits ou deploys, o histórico do Git e os logs de deploy mostram quando.

Para comparar o que está rodando com o que está no repositório, use uma cópia baixada do servidor:

git diff --no-index --stat ./meu-repo/src ./copia-do-servidor/src

Qualquer arquivo que aparecer só na cópia do servidor merece atenção.

Como limpar e voltar ao ar?#

Não tente "consertar" o servidor invadido arquivo por arquivo. Reconstrua:

1. Corrija a causa no código: atualize a dependência, feche o banco, remova o arquivo exposto, corrija a consulta.
2. Faça um deploy novo a partir do repositório, em vez de reaproveitar os arquivos que estavam no servidor.
3. Use os segredos novos, nunca os antigos.
4. Restaure os dados de uma cópia feita antes da invasão, se o banco foi alterado. Veja como fazer backup de um banco de dados para montar uma rotina que permita isso.
5. Monitore de perto nos dias seguintes: logs de acesso, uso de CPU e contas de serviços externos.

Preciso avisar alguém?#

Se dados pessoais de usuários podem ter vazado, provavelmente sim. No Brasil, a ANPD exige que o controlador comunique à autoridade e aos titulares, em até três dias úteis, um incidente que possa causar risco ou dano relevante, segundo a Resolução CD/ANPD nº 15/2024. Nem todo incidente precisa ser comunicado, mas a avaliação de risco é sua. Se você atende usuários de outros países, as leis locais também podem valer.

Fale também diretamente com os usuários: conte o que aconteceu, quais dados foram afetados e o que eles devem fazer, como trocar a senha nos outros serviços em que a reutilizavam.

Como evitar uma nova invasão?#

• Segredos fora do código e fora de qualquer pasta servida pelo site.
• Banco acessível só pela aplicação, sempre com senha e TLS.
• Dependências auditadas a cada deploy.
• Autenticação em duas etapas em todas as contas que podem fazer deploy.
• Um WAF na frente da aplicação para barrar padrões de ataque conhecidos; veja o que é um WAF.
• Cópias testadas dos dados, guardadas fora do servidor.

O checklist de segurança do deploy reúne esses itens com exemplos de código.

Como fazer isso na Square Cloud#

Na Square Cloud, a ordem deste artigo vira passos no painel. Para preservar as evidências, copie os logs pelo painel ou com o comando app logs da CLI (os de antes de um restart continuam visíveis) e tire um snapshot manual da aplicação antes de mexer em qualquer arquivo; snapshots manuais existem em todo plano. O gerenciador de arquivos no navegador mostra o disco da aplicação, o que ajuda a achar o que não está no repositório. Para trocar os segredos, edite as variáveis de ambiente no painel, na API, na CLI ou na extensão do VS Code; a mudança vale no próximo restart, sem rebuild.

Na reconstrução, publique a partir do repositório numa aplicação nova, e não por cima da antiga: o disco persiste entre deploys e um commit sobrescreve só os arquivos que estão no ZIP, então o que o invasor deixou continuaria lá. Para os dados, os bancos têm snapshot automático diário em todo plano com bancos, e as aplicações, a partir do Pro. Cada snapshot diário fica guardado por 7 dias, então escolha um de antes da invasão. Um snapshot de banco restaura no mesmo banco, em outro do mesmo motor ou num banco novo, e também pode ser baixado como .zip.

As aplicações rodam em containers isolados, sem acesso root, e uma não lê variáveis nem arquivos de outra, mesmo na mesma conta. Todos os planos incluem WAF e proteção DDoS L3/L4/L7. Essas camadas limitam o estrago, mas não corrigem uma falha no seu código nem um segredo vazado: a resposta ao incidente continua sendo sua. Veja como funcionam as variáveis de ambiente e os snapshots.