Site hackeado: o que fazer e por que o aviso do Google demora a sair

Quase ninguém descobre a invasão pelo painel do site. Descobre por um cliente que manda um print com a tela vermelha do Chrome, por um resultado no Google com título em japonês ou por um e-mail do Search Console que ficou dias sem ser aberto. A partir daí, a pergunta é sempre a mesma: o que fazer agora, e em que ordem.

As listas que circulam respondem bem a parte técnica: trocar senhas, restaurar backup, remover o código malicioso, atualizar plugins. Este guia cobre essa parte, mas acrescenta o que pesa no negócio: quanto tempo o aviso de site perigoso continua no ar depois da limpeza, por que pedir a revisão cedo demais atrasa tudo, por que atualizar não basta e quando a invasão vira uma obrigação legal com prazo de dias úteis.

O que fazer primeiro quando o site é hackeado?

A primeira hora decide quanto a invasão vai custar. O objetivo não é limpar tudo de uma vez, e sim conter o dano, preservar as provas e recuperar o controle dos acessos. Limpeza apressada, feita antes de entender o que aconteceu, costuma apagar a pista de como o invasor entrou, e ele volta pela mesma porta.

1. Tire o site do ar ou coloque em manutenção, se ele estiver redirecionando visitantes, servindo arquivos para download ou pedindo dados. Proteger quem visita vem antes do tráfego.
2. Faça uma cópia do estado atual (arquivos e banco de dados) antes de mexer. Ela é a evidência de como a invasão aconteceu e, se houver dado pessoal envolvido, sustenta a avaliação que a lei exige.
3. Troque todas as senhas: painel do site, hospedagem, FTP/SFTP, banco de dados, e-mail do domínio e registro do domínio. Faça isso de um computador que você sabe que está limpo.
4. Revise quem tem acesso de administrador e remova contas que você não reconhece. Usuário criado pelo invasor é uma das formas mais comuns de ele voltar.
5. Avise a hospedagem. Ela pode ter registros de acesso que você não enxerga e, em servidor compartilhado, outros sites podem estar no mesmo problema.
6. Abra o relatório Problemas de segurança do Search Console para ver o que o Google já detectou. Se o site ainda não está verificado lá, verifique agora: sem isso, não há como pedir a revisão depois.

Só depois desses seis passos começa a limpeza propriamente dita. A ordem importa: quem restaura o backup antes de trocar as senhas entrega ao invasor um site limpo com a mesma chave na porta.

Como saber se o seu site foi hackeado?

Nem toda invasão derruba o site. As mais rentáveis para o invasor são justamente as silenciosas, que usam o seu domínio para empurrar spam ou redirecionar parte dos visitantes sem que o dono perceba. Os sinais mais frequentes são:

• aviso de página perigosa ou enganosa no navegador, ou um aviso junto ao site nos resultados da pesquisa;
• páginas que você não criou aparecendo no Google, muitas vezes em outro idioma ou vendendo produtos que nada têm a ver com o seu negócio;
• visitantes relatando redirecionamento para outro site, sobretudo quando chegam pelo Google ou pelo celular;
• usuários administradores desconhecidos, arquivos novos no servidor ou alterações em arquivos que ninguém da equipe tocou;
• queda brusca de tráfego orgânico ou mensagem do Search Console sobre problema de segurança.

Um detalhe engana muitos donos de site: o invasor costuma mostrar o conteúdo malicioso só para quem vem do Google ou só para o robô de busca. A ajuda do Search Console explica que hackers usam técnicas de cloaking para esconder o spam do proprietário e recomenda inspecionar as páginas com a ferramenta de inspeção de URL ou com cURL simulando a origem do clique, em vez de abrir a página no navegador (relatório de problemas de segurança, Google Search Console). Por isso, "abri o site e está normal" não prova nada.

Que tipo de invasão é a sua: spam, malware ou phishing?

O Google separa os problemas de segurança em três famílias, e cada uma pede uma limpeza e um tempo de revisão diferentes. Saber em qual delas o seu caso se encaixa é o que permite estimar quanto tempo o site vai ficar marcado.

Categorias do relatório Problemas de segurança (Google Search Console) e tempos do guia "Solicitar uma análise" (Google, web.dev)

Um site pode ter mais de um tipo ao mesmo tempo. A ajuda do Search Console lembra que o site pode estar infectado por mais de um tipo de malware e que a lista de URLs do relatório é só uma amostra: não é necessariamente completa. Limpar apenas as páginas listadas é o caminho mais curto para um pedido de revisão negado.

Por que o aviso de site perigoso não sai quando você limpa o site?

Porque a marcação não é retirada sozinha no momento em que o código malicioso some. Ela sai depois que o dono do site pede uma revisão no relatório Problemas de segurança e o Google confirma que o problema foi resolvido. Até lá, a tela de aviso continua afastando visitantes, e cada dia de marcação é tráfego, venda e confiança perdidos.

O mesmo guia faz um alerta que muda a estratégia: solicitar uma análise com o problema ainda presente apenas prolonga o período em que o site fica sinalizado como perigoso. A ajuda do Search Console vai além e diz que reenviar pedidos sem corrigir o problema pode alongar a resposta seguinte e até marcar o site como infrator reincidente. A pressa de tirar o aviso é compreensível, mas um pedido negado custa mais tempo do que dois dias a mais de limpeza bem feita.

Como limpar o site sem apagar as provas nem reinfectar?

Com a cópia de evidência guardada e as senhas trocadas, a limpeza segue uma lógica simples: descobrir por onde o invasor entrou, fechar essa porta e só então devolver o site ao ar. Inverter a ordem é o motivo mais comum de reinfecção.

1. Descubra a porta de entrada

Compare os arquivos atuais com uma versão conhecida e limpa, procure arquivos modificados recentemente e cruze as datas com os registros de acesso da hospedagem. Em sites WordPress, a porta costuma ser um plugin ou tema vulnerável, uma senha fraca ou reaproveitada, ou um acesso de terceiro que nunca foi revogado.

2. Restaure de um backup anterior à invasão, se ele existir

Backup só ajuda se for de antes da invasão e se estiver fora do alcance de quem invadiu. Uma cópia guardada no mesmo servidor pode ter sido alterada junto com o site. Se esse ponto ainda é frágil na sua operação, vale ler sobre a cópia de backup que o ataque também alcança.

3. Sem backup confiável, reconstrua em vez de remendar

Reinstale o núcleo da plataforma, os temas e os plugins a partir das fontes oficiais, e reaproveite só o conteúdo (textos, imagens, banco de dados) depois de revisado. Remendar arquivo por arquivo deixa para trás portas dos fundos escondidas em lugares que ninguém olha.

4. Feche a vulnerabilidade antes de voltar ao ar

Atualize ou substitua o componente vulnerável, remova plugins e temas que não estão em uso, ative autenticação em duas etapas onde a plataforma permitir e revise as permissões de quem administra o site. O pedido de revisão do Google pede justamente isso: explicar como o site foi limpo e qual falha foi corrigida.

5. Confira como o Google enxerga as páginas

O guia do Google recomenda checar a página inicial e uma URL que foi modificada pelo hacker com wget ou cURL, e lembra que o Googlebot precisa conseguir rastrear essas páginas: se elas estiverem bloqueadas por robots.txt ou por noindex, o Google não tem como confirmar que estão limpas.

Como pedir a revisão no Search Console do jeito certo?

O pedido é feito no próprio relatório Problemas de segurança, pelo botão de solicitar revisão, e só deve sair quando todos os problemas listados estiverem corrigidos em todas as páginas. A ajuda do Search Console diz que corrigir só algumas páginas não ajuda a voltar parcialmente aos resultados.

1. Explique exatamente o problema que o site tinha, usando as categorias que aparecem no relatório.
2. Descreva o que foi feito para cada categoria: o que foi removido e qual falha foi fechada. O Google dá como exemplo de explicação a remoção do spam injetado e a atualização de um plugin desatualizado.
3. Documente o resultado: páginas verificadas, componentes atualizados, acessos revogados.
4. Envie um único pedido e espere a decisão. O Google confirma o recebimento por e-mail e avisa de novo quando a revisão termina.

Se o pedido for negado, o relatório pode trazer novos exemplos de URLs infectadas. Use-os como ponto de partida para uma segunda rodada de limpeza, que deve ser mais ampla que a primeira, e não como lista fechada do que falta corrigir.

Limpar o site tira o invasor. Só a revisão aprovada tira o aviso.

Por que atualizar os plugins não basta?

"Mantenha tudo atualizado" aparece em todo guia sobre site hackeado, e continua certo. O problema é que a atualização depende de duas coisas que o dono do site não controla: o desenvolvedor publicar a correção e o site instalá-la antes que alguém explore a falha. Os números do ecossistema WordPress mostram que essa janela é curta e, em quase metade dos casos, nem chega a abrir.

O mesmo relatório registra que o núcleo do WordPress teve só seis vulnerabilidades reportadas no ano, todas de baixa prioridade. O risco mora nos componentes acrescentados ao site. Na prática, isso leva a três cuidados que vão além de clicar em "atualizar":

• Menos componentes: cada plugin instalado é uma porta a mais. O que não está em uso deve sair, não só ficar desativado.
• Componentes com manutenção ativa: plugin sem atualização há muito tempo ou de autor que sumiu é candidato a substituição.
• Proteção que não depende da correção: monitoramento de integridade de arquivos, firewall de aplicação e alerta de vulnerabilidade cobrem o intervalo em que a correção ainda não existe.

Para quem quer medir o risco antes do próximo incidente, um pentest com reteste das correções mostra o que de fato é explorável no site, em vez de uma lista genérica de boas práticas.

Quando a invasão vira assunto da LGPD?

Quando o site trata dados pessoais e a invasão pode tê-los atingido. Formulário de contato, cadastro de clientes, área logada, loja virtual e newsletter guardam nome, e-mail, telefone, endereço e às vezes senha e dado de pagamento. Se o invasor teve acesso a isso, o problema deixa de ser só técnico.

A obrigação não vale para todo incidente. Pelo texto da Resolução CD/ANPD nº 15/2024, a comunicação é devida quando o incidente pode acarretar risco ou dano relevante aos titulares: quando pode afetar significativamente seus interesses e direitos e, ao mesmo tempo, envolve ao menos um destes critérios: dados sensíveis; dados de crianças, adolescentes ou idosos; dados financeiros; dados de autenticação em sistemas, como logins e senhas; dados protegidos por sigilo; ou dados em larga escala. Um site invadido com base de clientes e senhas pode se encaixar com facilidade.

• O prazo conta do conhecimento: os três dias úteis começam quando o controlador sabe que o incidente afetou dados pessoais, não quando a limpeza termina.
• Agente de pequeno porte tem prazo em dobro, nos termos da própria resolução, que remete ao regulamento de agentes de tratamento de pequeno porte.
• O registro é obrigatório mesmo sem comunicação: o controlador deve guardar o registro do incidente por no mínimo cinco anos, inclusive dos que não foram comunicados, com a avaliação de risco e os motivos de não comunicar.
• A comunicação ao titular deve usar linguagem simples e ser direta e individualizada quando for possível identificar as pessoas afetadas.

É aqui que a cópia de evidência feita na primeira hora faz diferença: sem ela, fica difícil dizer quais dados foram expostos, desde quando e de quantas pessoas, que são exatamente as informações que a comunicação exige.

Quais erros prolongam o problema?

• Pedir a revisão do Google antes de terminar a limpeza. O próprio Google avisa que isso só prolonga a marcação.
• Limpar só as URLs de exemplo do relatório. A lista é uma amostra, e o invasor raramente deixa uma página só.
• Restaurar o backup sem fechar a falha. O site volta limpo e vulnerável, e a reinfecção chega em dias.
• Conferir o site só pelo navegador. Com cloaking, o dono vê a página normal enquanto o Google e os visitantes vindos da busca veem o spam.
• Esquecer as senhas fora do painel: FTP, banco de dados, hospedagem e o e-mail que recupera todas as outras.
• Tratar a LGPD como etapa final. O prazo de comunicação corre em paralelo com a limpeza, não depois dela.
• Não registrar nada. Sem anotação do que foi visto e feito, o pedido de revisão fica genérico e a avaliação de incidente fica sem base.

O que muda entre site institucional, loja virtual e WordPress?

O roteiro é o mesmo, mas o peso de cada etapa muda conforme o que o site guarda e de onde vem a receita.

Quando o golpe envolve uma página falsa usando a sua marca, o problema conversa com o de phishing e do clique que vai acontecer: a defesa passa tanto pelo site quanto por avisar e orientar quem pode ser enganado.

Quanto custa deixar o site marcado como perigoso?

O custo mais visível é o tráfego que para na tela de aviso. Mas há outros que aparecem depois: campanhas pagas que levam para uma página bloqueada, e-mails de clientes perguntando se a empresa foi hackeada, a equipe comercial explicando o problema em vez de vender. Para o site de uma empresa B2B, que vive de credibilidade, o aviso vermelho comunica descuido antes de qualquer conversa.

É por isso que vale tratar a invasão também como um episódio de reputação. Uma nota curta nos canais oficiais, dizendo o que aconteceu, o que foi feito e o que o cliente deve observar, costuma conter mais boatos do que o silêncio. E, se houver dado pessoal envolvido com risco relevante, essa transparência deixa de ser opção e passa a ser regra.

Por onde começar hoje?

Se o site está invadido agora, siga a ordem: conter, copiar a evidência, trocar senhas, descobrir a porta, limpar, fechar a falha, conferir como o Google vê as páginas e só então pedir a revisão. Em paralelo, avalie se houve dado pessoal atingido, porque esse relógio corre em dias úteis.

Se o site não foi invadido, use este momento para fazer o que encurta qualquer incidente futuro: verificar o domínio no Search Console e cadastrar um e-mail que alguém de fato lê, ter backup fora do servidor, enxugar plugins e saber quem tem acesso de administrador. Esse é o trabalho que a área de Tech & Security da Alliance faz com os clientes, junto com o monitoramento do site.

E se a segurança do site é só uma das peças soltas da presença digital da empresa, o diagnóstico de marketing gratuito mostra em que ponto estão a tecnologia, os dados e os canais, e por onde vale começar.