Não apague nada ainda.
O instinto de quem descobre um arquivo estranho é removê-lo imediatamente. E isso destrói a evidência de como entraram — sem a qual você limpa o site e é reinfectado na semana seguinte, pela mesma porta.
A ordem importa mais que a velocidade. Este guia segue a sequência que um provedor usa ao atender um caso: isolar, entender, encontrar, decidir. ⚠️ Cada passo depende do anterior — pular o terceiro é o motivo mais comum de o problema voltar.
| Primeiro | Tire o site do ar e troque as senhas — sem apagar nada |
| Depois | Descubra como entraram, nos logs e nas datas dos arquivos |
| Só então | Limpe — ou recrie do zero, que costuma ser mais rápido |
| O erro mais comum | Restaurar backup sem fechar a brecha — reinfecta em dias |
| Faça backup do site sujo | Ele é a evidência. Guarde antes de tocar em qualquer coisa |
Conteúdo
Passo 1: confirme que é invasão
Nem todo comportamento estranho é invasão, e tratar um plugin quebrado como incidente de segurança custa tempo.
Estes sinais confirmam:
Redirecionamento para outro site, principalmente quando só acontece com visitantes vindos do Google e não quando você digita o endereço.
Aviso no Google Search Console, em Segurança e ações manuais — ou a tela vermelha do Google aparecendo para os visitantes.
A hospedagem suspendeu a conta, geralmente por envio de spam ou consumo anormal de recursos.
Arquivos modificados numa data em que você não mexeu no site.
Um usuário administrador que você não criou, frequentemente com nome plausível.
E páginas estranhas indexadas — busque site:seudominio.com.br no Google e veja se aparecem títulos em outro idioma, geralmente sobre remédios, apostas ou produtos falsificados.
⚠️ Estes não são invasão: erro 500 depois de atualizar um plugin, site fora do ar com domínio expirado, ou lentidão que coincide com um pico de tráfego.
Passo 2: isole, sem apagar
Tire o site do ar
Enquanto ele serve malware, o Google acumula histórico — e sair da lista do Safe Browsing depois é mais lento que evitar entrar.
Coloque em manutenção pelo painel de controle, ou renomeie o .htaccess e crie um index.html simples. ⚠️ Não apague nada — renomear preserva.
Faça backup do site comprometido
Parece contraintuitivo, e é o passo mais importante.
Esse backup é a evidência. É nele que você vai procurar como entraram, e é a ele que recorre se a limpeza der errado. Baixe a conta inteira e o banco de dados antes de tocar em qualquer arquivo.
⚠️ Guarde fora do servidor, e marque claramente que está infectado — para ninguém restaurar por engano.
Troque as senhas, na ordem certa
A ordem importa porque trocar só uma não adianta.
1. O painel de hospedagem — cPanel ou DirectAdmin. É o acesso de maior privilégio.
2. FTP e SFTP, incluindo contas secundárias que você possa ter esquecido.
3. O banco de dados, atualizando também o wp-config.php.
4. Os usuários do WordPress, todos os administradores.
5. E o e-mail associado ao painel, se houver qualquer suspeita de que ele também foi comprometido.
⚠️ Trocar só a senha do WordPress é o erro clássico. Se entraram por FTP ou pelo painel, a troca não muda nada — eles continuam dentro.
E invalide as sessões ativas. No WordPress, cada usuário tem a opção “Desconectar de todos os outros locais” no próprio perfil.
Passo 3: descubra como entraram
Este é o passo que quase ninguém faz, e o que evita a reinfecção.
Os logs de acesso
No cPanel, em Métricas → Acesso bruto, ou diretamente em ~/access-logs/.
O que procurar:
# requisições POST para arquivos que não deveriam existir
grep "POST" access.log | grep -v "wp-admin\|wp-login\|admin-ajax"
# tentativas de login bem-sucedidas em horário estranho
grep "wp-login.php" access.log | grep " 302 " ⚠️ Um POST para um arquivo PHP dentro de /wp-content/uploads/ é praticamente confirmação — essa pasta guarda mídia, e nada ali deveria executar código.
Anote o IP e o horário. Eles vão reaparecer nos outros logs.
As datas de modificação
Arquivos alterados quando você não estava mexendo no site:
# arquivos PHP modificados nas últimas 48 horas
find . -name "*.php" -mtime -2
# nos últimos 60 minutos, para acompanhar reinfecção
find . -name "*.php" -mmin -60 Sem acesso SSH, o Gerenciador de Arquivos do cPanel ordena por data — clique no cabeçalho da coluna.
⚠️ Atacantes experientes ajustam a data para disfarçar. Se nada aparecer e o site continuar comprometido, isso em si é um sinal.
Os suspeitos habituais
Plugin ou tema desatualizado com vulnerabilidade conhecida. É a causa mais comum, de longe — e a data da última atualização do plugin costuma coincidir com a da invasão.
Senha fraca em usuário administrador, descoberta por força bruta. Os logs mostram centenas de tentativas antes da que funcionou.
Permissão 777 numa pasta, permitindo escrita a qualquer processo do servidor. Nosso guia sobre chmod explica por que ela nunca deveria existir.
E credencial vazada — senha reutilizada de outro serviço, ou FTP salvo num computador infectado.
Passo 4: encontre o que deixaram
Invasores não entram e saem. Eles deixam formas de voltar.
Os lugares clássicos
Arquivos PHP na pasta de uploads. wp-content/uploads guarda imagens e documentos — um arquivo .php ali nunca é legítimo.
Arquivos estranhos em wp-admin ou wp-includes. ⚠️ Essas pastas deveriam ser idênticas ao pacote oficial do WordPress. Qualquer arquivo a mais é suspeito. Nosso guia sobre a estrutura de arquivos do WordPress mostra o que deveria estar lá.
Código no fim do functions.php do tema. Costuma vir depois de várias linhas em branco, para não aparecer ao abrir o arquivo.
E o .htaccess — regras de redirecionamento que enviam apenas visitantes vindos do Google para outro site.
Procure por código ofuscado
Backdoors quase sempre usam as mesmas funções:
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|shell_exec\(|passthru\(" . ⚠️ Nem todo resultado é malware — alguns plugins legítimos usam base64_decode. Mas um arquivo com eval(base64_decode($_POST[...])) é backdoor, sem ambiguidade.
O que quase ninguém verifica
O cron job que reinstala tudo. ⚠️ É a razão de o malware voltar depois de uma limpeza aparentemente completa.
Verifique em dois lugares: as tarefas cron do painel de hospedagem, e o agendamento interno do WordPress — um plugin como o WP Crontrol lista o que está agendado.
Usuários administradores criados pelo invasor. Confira a lista em Usuários, e desconfie de qualquer conta com e-mail que você não reconhece.
E chaves SSH autorizadas, se você tem VPS — o arquivo ~/.ssh/authorized_keys pode ter ganhado uma linha.
Passo 5: limpar ou recriar
A decisão honesta: recriar costuma ser mais rápido e mais seguro.
Quando recriar do zero
Quando você não construiu o site. Encontrar backdoor em código alheio é trabalho de horas, sem garantia.
Quando há muitos plugins e temas, aumentando os lugares onde algo pode estar escondido.
Quando a invasão é antiga — se o site está comprometido há semanas, o backup limpo pode não existir mais.
E quando você já limpou uma vez e voltou.
Como fazer:
1. Baixe o WordPress do site oficial e substitua wp-admin e wp-includes inteiros.
2. Reinstale temas e plugins das fontes oficiais — não reaproveite os arquivos existentes.
3. Recrie o wp-config.php a partir do modelo, com senha nova de banco e chaves de segurança novas.
4. Traga de volta apenas a pasta uploads, depois de verificar que não há arquivos PHP nela.
5. E revise o banco de dados — o conteúdo costuma estar limpo, mas confira usuários e opções.
Quando limpar vale a pena
Quando o site é seu, você conhece o código, e existe backup anterior à invasão.
⚠️ E restaurar backup exige uma ordem: feche a brecha antes de restaurar. Se você restaura e só depois atualiza o plugin vulnerável, há uma janela em que o site está no ar, limpo e vulnerável — e os scanners automáticos encontram isso em horas.
A ordem certa: restaure com o site ainda fora do ar → atualize tudo → troque as senhas → só então volte ao ar.
Como saber se limpou de verdade
Quatro verificações, e nenhuma é opcional.
Rode uma varredura externa — o Sucuri SiteCheck e o VirusTotal analisam o site do lado de fora, como o Google vê.
Peça uma varredura ao suporte da hospedagem. ⚠️ Eles têm acesso a ferramentas de servidor que você não tem, e veem padrões que se repetem entre contas.
Monitore por alguns dias com o comando de arquivos modificados. Se algo mudar sozinho, a brecha continua aberta.
E solicite a revisão do Google, em Search Console → Segurança e ações manuais. A resposta leva alguns dias, e descrever o que foi feito acelera — nosso guia sobre a tela vermelha do Google detalha o que escrever na solicitação e por que a descrição genérica atrasa.
Se voltar
Significa uma de três coisas:
A brecha não foi fechada. Você limpou o efeito, não a causa — é o motivo mais comum, e é o que o Passo 3 existe para evitar.
Sobrou um backdoor. Um arquivo que a limpeza não encontrou, ou um cron job reinstalando.
Ou a credencial ainda está com eles. Se o computador de onde você acessa o FTP está infectado, trocar a senha só dá uma senha nova ao invasor.
⚠️ Na segunda reinfecção, pare de limpar. Recrie do zero, em conta nova se possível, e verifique a máquina de onde você administra o site.
O que a hospedagem faz e o que não faz
Vale entender a divisão, porque ela evita expectativa errada.
O que a infraestrutura contém: num servidor com CloudLinux, o CageFS isola cada conta — então a invasão do vizinho não chega até você, e a sua não chega até ele.
⚠️ Mas isolamento não impede que a sua conta seja invadida. Ele limita o estrago, não a entrada — e é por isso que este artigo existe.
O WAF e o ModSecurity filtram ataques conhecidos antes de chegarem ao site. Bloqueiam muito, não bloqueiam tudo — sobretudo vulnerabilidades novas.
E o backup do provedor existe, mas ⚠️ verifique a retenção. Se são sete dias e a invasão tem duas semanas, todos os backups disponíveis já estão infectados.
A prevenção que realmente importa
Quatro coisas, em ordem de impacto:
Manter atualizado. ⚠️ Plugin desatualizado é a causa da maioria das invasões de WordPress — e ative a atualização automática pelo menos para os de segurança.
Senha forte com dois fatores em todos os administradores. A força bruta ainda funciona porque senhas fracas ainda existem.
Backup fora do servidor. Backup na mesma conta é comprometido junto. E teste a restauração — backup que nunca foi restaurado é hipótese, não garantia.
E menos plugins. Cada um é uma superfície a mais. Remova os desativados — eles continuam no servidor e continuam vulneráveis.
⚠️ O que ajuda menos do que se vende: plugin de segurança não substitui atualizar. Ele detecta e avisa, o que é útil — mas não fecha a vulnerabilidade que o plugin desatualizado deixou aberta.
Descobrir como entraram depende do log bruto de acesso e do histórico de modificação dos arquivos — e boa parte das hospedagens não entrega isso ao cliente. Na Homehost, os logs ficam à mão no painel, o CloudLinux isola sua conta das vizinhas, e as ferramentas do cPanel permitem baixar a conta inteira quando você quiser. Servidores no Brasil e suporte em português. A partir de R$ 7,90/mês.
Ver planos de hospedagemPerguntas frequentes
Como saber se meu site foi invadido?
Os sinais mais confiáveis são redirecionamento para outro site — muitas vezes só para quem vem do Google —, aviso no Search Console, suspensão da conta pela hospedagem, e arquivos modificados numa data em que você não mexeu no site. Buscar site:seudominio.com.br no Google também revela páginas estranhas indexadas.
Qual a primeira coisa a fazer?
Tirar o site do ar e fazer backup do estado comprometido — sem apagar nada. ⚠️ Apagar o arquivo suspeito destrói a evidência de como entraram, e sem isso você limpa e é reinfectado pela mesma porta.
Devo apagar o arquivo malicioso assim que encontrar?
Não imediatamente. Copie-o e anote onde estava e qual a data de modificação — essa informação é o que leva à brecha. Depois de entender a entrada, apague.
Restaurar um backup resolve?
Só se a brecha estiver fechada. ⚠️ Restaurar e depois atualizar deixa uma janela em que o site está no ar, limpo e vulnerável — e scanners automáticos encontram isso em horas. A ordem é: restaurar com o site fora do ar, atualizar tudo, trocar senhas, e só então voltar.
Como sei se meu backup está limpo?
Compare a data dele com a da primeira modificação suspeita que você encontrou. ⚠️ E verifique a retenção do provedor — se são sete dias e a invasão tem duas semanas, todos os backups disponíveis já estão infectados.
Vale mais limpar ou recriar do zero?
Recriar costuma ser mais rápido e mais seguro, sobretudo num site que você não construiu ou que tem muitos plugins. Limpar vale quando o site é seu, você conhece o código, e existe backup anterior à invasão.
Por que o malware voltou depois de eu limpar?
Três causas: a brecha não foi fechada, que é a mais comum; sobrou um backdoor que a limpeza não encontrou; ou um cron job está reinstalando. ⚠️ Verifique as tarefas agendadas no painel e no WordPress — é o lugar que quase ninguém olha.
Meu vizinho de servidor foi invadido. Meu site corre risco?
Num servidor com CloudLinux e CageFS, não — cada conta fica isolada, e o invasor não enxerga nem sabe que você existe. ⚠️ Sem essa camada, o risco é real. É uma das diferenças invisíveis entre planos aparentemente iguais.
A hospedagem limpa o site para mim?
Varia. Muitas fazem varredura e apontam os arquivos infectados, o que já ajuda bastante. Limpeza completa costuma ser serviço à parte — e vale perguntar antes, porque descobrir isso durante a emergência é pior.
Como tiro o aviso do Google?
Depois de limpar, peça a revisão em Search Console → Segurança e ações manuais. A resposta leva alguns dias, e descrever o que foi feito na limpeza costuma acelerar. ⚠️ Pedir revisão antes de limpar de verdade queima a solicitação e atrasa o processo.
Plugin de segurança impede invasão?
Ajuda, mas não substitui atualizar. Ele detecta, avisa e bloqueia padrões conhecidos — mas não fecha a vulnerabilidade que um plugin desatualizado deixou aberta. ⚠️ Manter tudo atualizado continua sendo a defesa principal.
Preciso avisar meus clientes?
Se o site coletava dados pessoais e há indício de acesso a eles, sim — a LGPD prevê comunicação aos titulares e à ANPD em caso de incidente que possa gerar risco relevante. ⚠️ Documente o que aconteceu e o que foi feito enquanto a informação está fresca.
Conclusão
A reação instintiva a um site invadido é apagar o que parece errado. E é exatamente o que garante que o problema volte — porque o arquivo era o efeito, não a causa.
Três coisas resumem a ordem certa. Isole antes de investigar, e faça backup do site sujo, porque ele é a evidência. Descubra como entraram antes de limpar — nos logs e nas datas de modificação. E feche a brecha antes de restaurar, nunca depois, porque a janela entre uma coisa e outra é suficiente para os scanners automáticos.
E a decisão honesta é que recriar costuma ganhar de limpar. Num site que você não construiu, caçar backdoor é trabalho de horas sem garantia — enquanto reinstalar o WordPress, os plugins e os temas de fonte oficial leva uma tarde e não deixa dúvida.
A camada de isolamento do servidor protege você dos vizinhos e os vizinhos de você. ⚠️ O que ela não faz é impedir a entrada na sua conta — essa parte depende de atualizar, de senha forte e de backup que você já testou restaurar.
