Site WordPress invadido: o que fazer nas primeiras horas

Seu site WordPress foi invadido? Veja o passo a passo priorizado das primeiras horas: backup, senhas, contenção, o que não fazer, clientes e LGPD.

Se o seu site WordPress foi invadido, faça isto agora, nesta ordem: (1) tire um backup completo dos arquivos e do banco de dados, mesmo infectado; (2) troque as senhas da hospedagem, do painel/FTP/SSH e do banco, a partir de um computador limpo; (3) avise a hospedagem; (4) coloque o site em modo de manutenção se ele estiver redirecionando visitantes ou distribuindo malware. Só depois disso você parte para a limpeza.

Respira. Invasão de WordPress é comum, tem conserto, e na maioria dos casos dá para recuperar o site sem perder conteúdo. O que piora a situação é sair apagando coisas no desespero. Abaixo está o passo a passo das primeiras horas, priorizado do mais urgente para o menos urgente.

Antes de tudo: como ter certeza de que foi invasão

Se você ainda está na dúvida, os sinais mais típicos são: redirecionamento para sites de apostas, farmácia ou golpes (às vezes só no celular), páginas em japonês aparecendo no Google, aviso vermelho de "site perigoso" no Chrome, administradores que você não criou e e-mail da hospedagem dizendo que a conta foi suspensa por malware ou spam. Temos um guia só sobre isso: como saber se seu site foi hackeado.

Se pelo menos um desses sinais apareceu, trate como invasão até prova em contrário.

Passo a passo das primeiras horas

1. Faça um backup completo (sim, do site infectado)

Parece contraintuitivo, mas é o passo mais importante. O backup do site infectado:

• garante que você não perde conteúdo, pedidos e configurações se algo der errado na limpeza;
• preserva as evidências de como o invasor entrou (logs, arquivos modificados, datas);
• permite comparar depois o que mudou.

Baixe os arquivos (a pasta inteira do WordPress, incluindo wp-content e arquivos ocultos como .htaccess) e o banco de dados. Com WP-CLI, o banco sai assim:

wp db export backup-infectado-$(date +%F).sql
tar -czf arquivos-infectados-$(date +%F).tar.gz /caminho/do/site

Sem acesso SSH, use o gerenciador de backups do painel da hospedagem (cPanel, Plesk, painel próprio) ou o phpMyAdmin para exportar o banco. Guarde esse backup fora do servidor e identifique como infectado, para ninguém restaurar por engano.

Atenção: não abra arquivos do backup infectado clicando duas vezes no seu computador. Trate-os como material contaminado.

2. Troque as senhas, começando pela hospedagem

Se o invasor tem a senha da sua hospedagem, qualquer limpeza é inútil. A ordem recomendada:

1. Conta da hospedagem (painel do cliente, onde dá para mudar tudo).
2. Acessos ao servidor: FTP/SFTP, SSH, cPanel.
3. Usuário do banco de dados (depois, atualize o DB_PASSWORD no wp-config.php, senão o site cai).
4. Administradores do WordPress.
5. E-mail ligado ao domínio e às contas de admin, e o registro do domínio (Registro.br ou outro registrador).

Faça isso de um computador que você confia. Se o invasor conseguiu sua senha por um malware no seu notebook, trocar a senha nele mesmo pode não adiantar. Ative autenticação em dois fatores onde houver.

3. Avise a hospedagem

A hospedagem pode ter informação que você não tem: logs de acesso, horário do primeiro arquivo malicioso, outros sites da mesma conta infectados. Peça:

• logs de acesso (access log) e de erros dos últimos dias;
• confirmação se outros sites na mesma conta também foram afetados;
• se existem backups automáticos e de quais datas.

Se a hospedagem já suspendeu sua conta, ela normalmente libera o acesso para limpeza mediante pedido. Seja direto: "estou ciente da infecção e vou limpar, preciso de acesso".

4. Contenha o estrago

Se o site está redirecionando visitantes para golpes ou baixando malware, cada hora no ar machuca sua reputação no Google e expõe seus visitantes. Opções, da mais simples à mais robusta:

• ativar o modo de manutenção da hospedagem ou um index.html estático temporário;
• restringir o acesso por senha (autenticação HTTP no painel da hospedagem);
• se você usa Cloudflare, ativar o modo "Under Attack" ou regras que bloqueiem o tráfego enquanto limpa.

Se o problema é "só" spam no Google (páginas em japonês, por exemplo) e o site funciona normalmente para os visitantes, dá para manter no ar enquanto limpa.

5. Verifique os administradores

Invasores quase sempre criam um usuário administrador para voltar depois. Liste os admins:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Alguns backdoors escondem o usuário do painel, então confira direto no banco também (troque wp_ pelo prefixo das suas tabelas, se for diferente):

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Anote os usuários estranhos (login, e-mail, data de criação) antes de remover. A data de criação é uma pista valiosa de quando a invasão começou.

6. Derrube todas as sessões

Trocar senha não desloga quem já está logado. Regenerar as chaves de segurança (salts) do wp-config.php invalida todos os cookies de login:

wp config shuffle-salts

Sem WP-CLI, gere novas chaves em https://api.wordpress.org/secret-key/1.1/salt/ e substitua o bloco correspondente no wp-config.php.

7. Agora sim: limpe

A limpeza de verdade envolve reinstalar o núcleo e os plugins de fontes oficiais, caçar backdoors e revisar o banco de dados. Isso está detalhado no guia como remover malware e backdoors do WordPress. Se o Google já está mostrando aviso, siga depois para como remover o aviso de site perigoso do Google.

Checklist das primeiras horas

O que NÃO fazer

Algumas reações instintivas pioram muito a situação:

• Não apague o site inteiro sem backup. Você perde conteúdo e as evidências de como o invasor entrou.
• Não restaure um backup qualquer e dê o caso por encerrado. Se a falha (plugin desatualizado, tema pirata, senha vazada) continuar lá, a reinfecção costuma ser rápida. E o backup pode já conter o backdoor, porque muitas invasões ficam semanas quietas antes de aparecer.
• Não confie só em um plugin de segurança "que limpou tudo". Scanners ajudam, mas não pegam tudo, principalmente backdoors no banco de dados ou em arquivos que imitam nomes legítimos.
• Não instale mais plugins aleatórios no desespero. Cada plugin novo é mais código rodando num servidor que já não é confiável.
• Não peça revisão ao Google antes de terminar. Pedir revisão com o site ainda infectado pode atrasar as próximas análises.
• Não pague resgate nem negocie com quem invadiu. Não há garantia nenhuma, e você financia o próximo ataque.
• Não esconda o problema de quem foi afetado, se houve dados pessoais envolvidos (veja abaixo).

Como comunicar clientes e visitantes

Se o seu site é a vitrine do seu negócio, alguém provavelmente já percebeu. Uma comunicação curta e honesta passa mais confiança do que silêncio.

Para clientes que perguntarem ou foram redirecionados:

"Identificamos um problema de segurança no nosso site e ele está temporariamente em manutenção. Já estamos tratando. Se você recebeu algum link estranho em nosso nome, não clique. Nenhum pagamento é solicitado por [canal]."

Algumas regras práticas:

• diga o que aconteceu sem detalhes técnicos que ajudem outros atacantes;
• diga o que a pessoa deve fazer (não clicar em links, trocar senha se tinha conta no site);
• não prometa o que você ainda não sabe ("nenhum dado vazou") antes de investigar;
• se você é agência, avise seu cliente antes que ele descubra pelo Google.

Se o site tinha área de login para clientes (loja, área de membros), force a troca de senha de todos os usuários depois da limpeza.

LGPD: e se houve vazamento de dados pessoais?

Nem toda invasão é vazamento. Um site institucional que só ganhou páginas de spam talvez não tenha exposto dado pessoal nenhum. Mas se o seu WordPress guarda dados de clientes (pedidos do WooCommerce, cadastros, formulários de contato salvos no banco, área de membros), considere que o invasor pode ter tido acesso a eles.

Em termos gerais, a LGPD (art. 48) e o regulamento da ANPD (Resolução CD/ANPD nº 15/2024) determinam que o controlador comunique à ANPD e aos titulares os incidentes de segurança que possam causar risco ou dano relevante. Pontos que vale saber:

• o prazo geral é de três dias úteis a partir do momento em que você toma conhecimento de que o incidente afetou dados pessoais (agentes de pequeno porte podem ter prazos diferenciados);
• a comunicação à ANPD é feita por formulário no site oficial da autoridade, e pode ser complementada depois;
• mesmo incidentes que você decide não comunicar devem ficar registrados internamente.

O que fazer na prática: anote o que aconteceu, quando você descobriu, quais dados estavam no site e o que foi feito. Esse registro é útil de qualquer forma. E se houve risco real para os titulares, fale com um advogado especializado em proteção de dados. Este texto é orientação geral, não parecer jurídico.

Depois da poeira baixar

Limpar sem descobrir por onde o invasor entrou é enxugar gelo. As portas de entrada mais comuns são plugins e temas desatualizados, plugins e temas piratas ("nulled"), senhas reutilizadas e hospedagens mal isoladas. Depois da limpeza, passe pelo checklist de segurança para WordPress e acompanhe o site por algumas semanas: invasões malfeitas de limpar costumam voltar.

Quer ajuda para resolver isso?

Se você tem familiaridade com servidor, WP-CLI e banco de dados, dá para seguir os passos deste guia e dos links acima por conta própria. Eles são os mesmos que um profissional seguiria.

Se preferir delegar, a Mobgeek faz a limpeza de site WordPress invadido: diagnóstico, remoção de malware e backdoors, restauração, troca de credenciais, hardening, pedido de revisão no Google e relatório do que foi encontrado, com 30 dias de garantia contra reinfecção. O início é em até 24h e o valor parte de R$ 790. Também há um plano mensal de proteção para quem quer monitoramento contínuo. Se quiser, conte o seu caso e peça um orçamento.