Descobrir que o site foi invadido provoca uma reação natural e frequentemente errada: restaurar o backup imediatamente.

O problema é que restaurar sem entender como entraram reintroduz a mesma falha — e o site volta a ser comprometido, às vezes em horas. Isso transforma um incidente em um ciclo.

Este guia percorre a ordem correta de reagir. Ele é escrito para as primeiras horas, quando a pressa é grande e as decisões importam.

Como identificar

Nem toda invasão é óbvia. Os sinais mais comuns:

• Redirecionamento para outro site, às vezes só em celular ou só para quem vem de busca.
• Conteúdo que ninguém publicou: páginas, links, textos em outro idioma.
• Aviso do navegador ou do buscador marcando o site como perigoso.
• Usuários administrativos que ninguém criou.
• Envio de spam a partir do domínio, com reclamações chegando.
• Lentidão repentina sem explicação, por processamento que não é seu.
• Arquivos modificados em datas que não correspondem a nenhuma publicação.

O primeiro item é o mais enganoso: redirecionamentos condicionais funcionam apenas para parte dos visitantes — quem administra o site abre e vê tudo normal, enquanto quem chega da busca é levado para outro lugar.

Se houver suspeita, vale acessar o site de um dispositivo diferente, de uma rede diferente e vindo de uma busca — não apenas digitando o endereço.

As primeiras horas, na ordem

1. Contenha

Antes de investigar ou consertar:

1. Coloque o site em manutenção ou tire-o do ar, se houver risco aos visitantes.
2. Troque as senhas de painel, hospedagem, banco e acesso ao servidor.
3. Revogue chaves de acesso e integrações ativas.
4. Encerre as sessões ativas de todos os usuários.
5. Avise quem precisa saber: hospedagem, equipe, agência.

O item 2 tem uma ordem que importa: troque a senha da hospedagem antes da do site. Se o acesso ao servidor está comprometido, mudar apenas a senha do painel não adianta.

2. Preserve evidências

Antes de apagar qualquer coisa:

• Faça uma cópia do estado atual, comprometido, em local isolado.
• Salve os registros de acesso da hospedagem, que costumam ter retenção curta.
• Anote datas e horários do que foi observado.

Parece contraintuitivo guardar um site infectado, e é o que permite entender o que aconteceu. Sem evidência, a investigação vira adivinhação — e a falha original tende a permanecer.

3. Entenda como entraram

A etapa que as pessoas pulam e que determina se o problema volta:

• Plugin ou tema com vulnerabilidade conhecida, especialmente desatualizado.
• Senha fraca ou reaproveitada, de qualquer usuário administrativo.
• Versão antiga do sistema ou da linguagem.
• Plugin ou tema obtido fora dos canais oficiais, que pode já vir comprometido.
• Comprometimento de outro site no mesmo ambiente, em hospedagem compartilhada.
• Acesso de terceiro com credenciais vazadas.

Os registros de acesso costumam responder: procure o primeiro acesso anormal e veja o que ele fez. A data de modificação dos arquivos alterados também ajuda a delimitar a janela.

4. Limpe ou restaure

Com a causa identificada, duas opções:

Restaurar um backup anterior à invasão — desde que você saiba quando ela começou, e que a falha seja corrigida antes de o site voltar. Restaurar para um ponto que já estava comprometido não resolve nada.

Limpar o site atual, removendo o que foi inserido. Mais trabalhoso e necessário quando não há backup limpo ou quando houve publicação relevante depois da invasão.

Em ambos os casos, atualize tudo antes de voltar ao ar e remova o que não é usado — plugins e temas inativos incluídos.

5. Volte e observe

• Reative o site e acompanhe de perto por alguns dias.
• Verifique se o comportamento anômalo cessou, testando como visitante.
• Solicite revisão aos buscadores, se o site foi marcado como perigoso.
• Monitore novos usuários, arquivos modificados e tentativas de acesso.

O terceiro item importa para a recuperação de tráfego: um site marcado como perigoso continua com o aviso até a revisão ser solicitada e concluída, mesmo depois de limpo.

O que verificar depois de limpar

Antes de considerar o incidente encerrado, uma checagem que evita descobrir resíduos semanas depois:

• Usuários administrativos, comparando com a lista que deveria existir.
• Tarefas agendadas criadas no período, que podem reinstalar código removido.
• Arquivos em pastas de upload, onde código malicioso costuma ser deixado.
• Plugins e temas que ninguém instalou.
• Chaves de acesso e integrações ativas no painel e na hospedagem.
• Redirecionamentos e regras de servidor que não estavam lá antes.
• Conteúdo publicado durante a janela do incidente.

O segundo item é o que explica reinfecções aparentemente inexplicáveis: uma tarefa agendada deixada para trás pode reinstalar o que foi removido, horas ou dias depois da limpeza. Quem limpa o site e não verifica os agendamentos costuma repetir o trabalho.

E o terceiro merece atenção redobrada em sites com envio de arquivos: a pasta de uploads é um destino natural para código deixado para reentrada, e o conteúdo dela raramente é revisado.

O que comunicar

Um aspecto não técnico que costuma ser mal conduzido na pressa.

Dependendo do que aconteceu, algumas comunicações são necessárias:

• A hospedagem, que pode ter informações relevantes e precisa saber.
• A equipe, para que ninguém publique ou acesse durante a contenção.
• Clientes ou usuários, se houve exposição de dados ou se o site distribuiu conteúdo malicioso.
• Parceiros integrados, se credenciais compartilhadas foram revogadas.

O terceiro item exige cuidado e não deve ser improvisado: comunicação sobre exposição de dados tem implicações previstas na LGPD, incluindo prazos e conteúdo. Vale acionar orientação especializada antes de enviar qualquer mensagem, e não depois.

Sobre tom: informar o que aconteceu, o que foi feito e o que a pessoa deve fazer — sem minimizar e sem alarmar. Silêncio costuma custar mais que a comunicação.

O que não fazer

Erros que agravam o problema:

• Restaurar o backup e voltar ao ar sem corrigir a falha. É o mais comum, e reinicia o ciclo.
• Apagar tudo antes de investigar, destruindo a única evidência disponível.
• Assumir que um plugin de limpeza resolveu. Ferramentas ajudam e não garantem remoção completa.
• Ignorar porque “o site parece normal”, quando o comportamento é condicional.
• Deixar usuários e chaves antigos ativos, mantendo a porta aberta.
• Não avisar a hospedagem, que pode ter informações e pode estar afetada.

O terceiro merece cuidado: ferramentas automáticas removem o que reconhecem. Código inserido de forma menos usual pode passar — e uma limpeza incompleta dá a sensação de problema resolvido.

Quando buscar ajuda

Vale reconhecer os limites, porque insistir sozinho pode custar mais:

• O site volta a ser comprometido depois de limpo.
• Há dados de clientes envolvidos, o que muda a natureza do incidente.
• Trata-se de uma loja, com implicações financeiras e de pagamento.
• Não há backup limpo e a limpeza manual não está funcionando.
• Você não consegue identificar a origem depois de investigar.
• O servidor inteiro parece afetado, e não apenas o site.

O segundo item tem implicações além do técnico: incidentes envolvendo dados pessoais podem exigir providências previstas na LGPD, incluindo comunicação. É matéria para orientação especializada, e vale acionar cedo.

Depois: o que muda

Um incidente é o momento em que as medidas preventivas deixam de ser teoria:

1. Atualizações em dia, com correções de segurança automatizadas.
2. Senhas fortes e únicas, com autenticação em duas etapas onde possível.
3. Usuários revisados, com permissões mínimas.
4. Plugins e temas reduzidos ao necessário, obtidos apenas de fontes oficiais.
5. Backup automático com restauração testada, guardado fora do servidor.
6. Monitoramento de disponibilidade e de alterações.
7. Rotina de manutenção com data marcada.

O item 5 merece destaque à luz do que acabou de acontecer: um backup guardado no mesmo servidor pode ser comprometido junto com o site. Destino externo deixa de ser recomendação e vira requisito — o assunto está no artigo sobre backup de site.

E o conjunto das medidas preventivas está no artigo sobre segurança no WordPress, que trata de evitar o que este trata de remediar.

O custo real

Vale dimensionar, porque isso orienta quanto investir em prevenção:

• Tempo fora do ar, com vendas e contatos perdidos.
• Trabalho de limpeza e investigação, próprio ou contratado.
• Perda de posicionamento, se o site foi marcado como perigoso.
• Reputação de envio comprometida, se houve spam pelo domínio.
• Confiança dos visitantes, difícil de mensurar e lenta de recuperar.
• Implicações legais, se dados de terceiros foram expostos.

A comparação que orienta: a rotina preventiva completa custa uma fração do tempo de um único incidente — e a maior parte dela é automatizável, como tratado no artigo sobre rotina mínima de manutenção.

Conclusão

A ordem importa mais que a velocidade: conter, preservar, entender, limpar, observar. Restaurar o backup antes de entender como entraram é o erro mais comum, porque reintroduz a mesma falha e transforma um incidente em ciclo.

Duas verificações fazem diferença imediata: trocar a senha da hospedagem antes da do site, porque mudar apenas o painel não adianta se o servidor está comprometido; e testar o site como um visitante externo, vindo de uma busca, porque redirecionamentos condicionais não aparecem para quem administra.

E o aprendizado que sobra: backup guardado no mesmo servidor pode ser comprometido junto. Destino externo com restauração testada deixa de ser recomendação e vira requisito. Conheça a hospedagem WordPress da TBF Host e verifique os recursos de proteção e backup do seu plano.

Perguntas frequentes

Meu site WordPress foi invadido. O que fazer primeiro?

Conter, antes de investigar ou consertar: colocar o site em manutenção, trocar as senhas começando pela hospedagem, revogar chaves e integrações, encerrar sessões ativas e avisar quem precisa saber. Só depois disso vêm a preservação de evidências e a investigação.

Posso simplesmente restaurar o backup?

Não sem entender como entraram. Restaurar sem corrigir a falha reintroduz o mesmo problema, e o site volta a ser comprometido — às vezes em horas. Também é preciso saber quando a invasão começou, porque restaurar para um ponto já comprometido não resolve nada.

Como saber se meu site foi invadido?

Sinais comuns são redirecionamento para outro site, conteúdo que ninguém publicou, aviso do navegador ou do buscador, usuários administrativos desconhecidos, envio de spam pelo domínio, lentidão repentina e arquivos modificados em datas sem publicação correspondente.

O site parece normal para mim, mas alguém reclamou de redirecionamento.

Redirecionamentos condicionais funcionam apenas para parte dos visitantes — quem administra o site costuma ver tudo normal. Vale testar de um dispositivo diferente, de outra rede e chegando ao site por uma busca, em vez de digitar o endereço diretamente.

Por que preservar o site infectado antes de limpar?

Porque sem evidência a investigação vira adivinhação, e a falha original tende a permanecer. Vale fazer uma cópia do estado comprometido em local isolado e salvar os registros de acesso da hospedagem, que costumam ter retenção curta.

Um plugin de limpeza resolve?

Ajuda, mas não garante. Ferramentas automáticas removem o que reconhecem — código inserido de forma menos usual pode passar. Uma limpeza incompleta é pior que nenhuma nesse aspecto, porque dá a sensação de problema resolvido.

Meu site foi marcado como perigoso. Como remover o aviso?

Depois de limpar o site e corrigir a falha, é preciso solicitar a revisão aos buscadores. O aviso permanece até a revisão ser concluída, mesmo com o site já limpo — e é ele que continua afastando visitantes nesse período.

Quando buscar ajuda especializada?

Quando o site volta a ser comprometido depois de limpo, quando há dados de clientes envolvidos, quando é uma loja com implicações de pagamento, quando não há backup limpo, quando a origem não é identificável ou quando o servidor inteiro parece afetado.