Site invadido exige uma resposta rápida, mas agir sem método pode apagar evidências, contaminar um backup ou ampliar a interrupção. O primeiro passo é confirmar os sinais, preservar uma cópia do estado atual e restringir o acesso sem fazer alterações aleatórias. Depois vêm diagnóstico, limpeza, troca de credenciais, atualização e monitoramento.
Uma invasão pode aparecer como redirecionamento para páginas estranhas, novos usuários administrativos, arquivos modificados, anúncios que você não publicou, alerta do navegador ou aviso no Google Search Console. Esses sinais justificam uma análise; isoladamente, porém, nem todos provam que o site foi comprometido.
Este guia apresenta 11 ações seguras para lidar com um site invadido, explica o que não fazer e mostra quando é prudente buscar suporte especializado.
Sumário
- Como confirmar a invasão
- 11 ações para recuperar o site
- Avisos do Google e revisão
- Como reduzir novas ocorrências
- Quando contratar suporte
- Perguntas frequentes
Como confirmar se o site foi invadido?
Antes de concluir que existe um site invadido, registre o que aconteceu: data, horário, páginas afetadas, mensagens exibidas e mudanças percebidas. Faça capturas de tela e guarde os alertas recebidos. Esse histórico ajuda a diferenciar invasão, erro de configuração, falha de atualização e indisponibilidade da hospedagem.
A documentação oficial do WordPress lista sinais como inclusão não autorizada de usuários, avisos de malware, bloqueio pela hospedagem, alterações visíveis e alertas de mecanismos de pesquisa. O guia do WordPress para sites comprometidos também recomenda manter a calma, documentar o ocorrido e procurar ajuda quando necessário.
Confira o painel do WordPress, a hospedagem, os registros disponíveis e o relatório “Problemas de segurança” do Search Console. Analise em um dispositivo confiável. Se houver suspeita de roubo de senha no computador usado para administrar o site, trocá-la no mesmo dispositivo possivelmente comprometido pode não resolver.
Nem todo erro 500, tela branca ou página fora do ar significa ataque. Se o principal sintoma for apenas indisponibilidade, consulte também o guia da Web10 sobre site fora do ar. O diagnóstico correto evita tratar como malware um conflito de plugin ou uma falha do servidor.
Sinais que merecem investigação imediata
- redirecionamentos que não foram configurados pelo responsável;
- páginas, anúncios, links ou arquivos desconhecidos;
- novos administradores ou alterações de senha não autorizadas;
- alerta de phishing, malware ou conteúdo nocivo;
- mensagens da hospedagem sobre arquivos suspeitos;
- picos incomuns de processamento, envio de e-mails ou tráfego;
- resultados do Google com títulos e descrições estranhos;
- plugins ou temas desativados ou modificados sem explicação.
Um site invadido pode apresentar apenas parte desses indícios. Algumas ameaças tentam permanecer discretas, enquanto outras alteram imediatamente a aparência. Por isso, a ausência de uma tela ostensiva não elimina a necessidade de investigação quando existem evidências técnicas consistentes.
Site invadido: 11 ações seguras para recuperar
1. Preserve informações antes de alterar
Registre os sintomas e obtenha uma cópia dos arquivos, do banco de dados e dos registros disponíveis antes de iniciar a limpeza. Essa cópia não deve ser considerada segura para restauração; ela preserva o estado do incidente para comparação e investigação.
Evite apagar arquivos suspeitos imediatamente. Uma remoção precipitada pode ocultar a origem, quebrar o site ou deixar outro ponto de acesso ativo. Em um site invadido, preservar evidências e manter uma linha do tempo reduz o risco de repetir ações sem saber o que mudou.
2. Acione a hospedagem e defina a contenção
Informe a hospedagem e pergunte quais recursos estão disponíveis: registros, varredura, isolamento, restauração, bloqueio temporário e suporte a incidentes. O provedor pode identificar consumo anormal, arquivos modificados ou outros sites afetados na mesma conta.
Dependendo do risco, pode ser necessário colocar o projeto em manutenção, restringir o acesso ou isolar a instalação. A decisão deve considerar vendas, cadastros, dados pessoais e perigo para visitantes. Manter um site invadido aberto sem controle pode expor usuários; derrubá-lo sem planejamento também pode destruir informações úteis.
3. Use um dispositivo confiável
Verifique os computadores e celulares usados para administrar o site. Atualize o sistema, o navegador e as ferramentas de segurança. Se houver suspeita de malware local, utilize outro dispositivo confiável para alterar credenciais e acessar a hospedagem.
O problema pode não estar apenas no WordPress. Senhas salvas no navegador, contas de e-mail, painel da hospedagem, registrador do domínio e serviços conectados também merecem atenção. Recuperar o site invadido sem proteger esses acessos pode permitir uma nova entrada.
4. Troque credenciais na ordem correta
Troque senhas do e-mail principal, hospedagem, painel do servidor, SFTP ou SSH, banco de dados e usuários administrativos. Use senhas longas, exclusivas e armazenadas em um gerenciador confiável. Não reutilize a mesma combinação em serviços diferentes.
Revise chaves de aplicação, tokens, integrações e usuários. Remova contas desconhecidas e reduza privilégios excessivos. A documentação de segurança do WordPress recomenda senhas fortes e ressalta que a proteção depende do sistema, da hospedagem e das práticas das pessoas.
Se houver mais de um administrador, coordene a troca para não manter uma credencial antiga ativa. Em um site invadido, alterar somente a senha do painel pode ser insuficiente quando o atacante também obteve acesso à hospedagem ou ao e-mail de recuperação.
5. Revogue sessões e renove chaves
Depois de redefinir acessos, encerre sessões abertas e renove chaves de segurança quando o procedimento for aplicável ao ambiente. Isso ajuda a invalidar cookies e credenciais que possam continuar ativos.
Revise também aplicativos conectados, usuários de API e senhas de aplicação. Não copie comandos encontrados aleatoriamente sem entender o efeito. A execução correta varia conforme a hospedagem, a versão do WordPress e a arquitetura do projeto.
6. Identifique o alcance da alteração
Compare arquivos com cópias confiáveis e versões oficiais. Examine temas, plugins, uploads, arquivos de configuração, tarefas agendadas, banco de dados, usuários e redirecionamentos. Procure alterações recentes que não correspondam a uma manutenção legítima.
Uma varredura automática ajuda a localizar padrões conhecidos, mas não prova sozinha que toda ameaça foi removida. Um arquivo alterado pode ser legítimo; um arquivo aparentemente normal pode esconder código malicioso. O diagnóstico do site invadido precisa combinar ferramentas, registros e conhecimento do projeto.
Se vários sites compartilham a mesma conta de hospedagem, todos devem ser avaliados. Limpar uma instalação e deixar outra comprometida pode permitir reinfecção. Confira ainda subdomínios, cópias antigas, ambientes de teste e instaladores esquecidos.
7. Escolha entre limpeza e restauração
Uma cópia anterior pode acelerar a recuperação, desde que seja completa, íntegra e realmente anterior ao incidente. Antes de restaurar, avalie o que foi criado depois da data do backup, como pedidos, cadastros, artigos e mensagens.
Restaurar sem corrigir a causa pode devolver a mesma vulnerabilidade. Por outro lado, limpar manualmente sem conhecer todos os componentes pode deixar uma porta de entrada. A melhor opção depende do histórico, da qualidade dos backups e do alcance do site invadido.
A documentação oficial recomenda preservar arquivos e banco de dados para uma restauração completa. Veja as orientações do WordPress sobre backups e recuperação. Mantenha separadas a cópia contaminada, a cópia limpa e a versão final recuperada.
8. Reinstale componentes de fontes oficiais
Quando possível, substitua o núcleo do WordPress, plugins e temas por cópias íntegras obtidas das fontes oficiais ou dos fornecedores legítimos. Não preserve arquivos executáveis desconhecidos apenas porque o site depende deles.
Remova componentes sem uso e extensões abandonadas. Antes de excluir um plugin, verifique se ele armazena dados ou executa uma função essencial. Em projetos personalizados, faça a comparação com o repositório ou backup confiável para não apagar código legítimo.
O manual de proteção do WordPress explica que não existe uma solução única para toda preocupação de segurança. Um site invadido exige correção da causa e redução das oportunidades de novo acesso.
9. Atualize e teste em etapas
Depois da limpeza, atualize WordPress, temas e plugins compatíveis. Componentes desatualizados podem conter falhas corrigidas em versões recentes. Porém, aplicar tudo simultaneamente sem teste pode criar conflitos e dificultar a identificação de um novo erro.
Crie um ponto de recuperação, faça alterações em etapas e teste páginas, formulários, login, busca, compras e integrações. Se o projeto for crítico ou muito personalizado, utilize um ambiente de testes antes de alterar a produção.
Para estabelecer uma rotina após resolver o site invadido, consulte o conteúdo da Web10 sobre manutenção de site WordPress. Atualização, backup e testes precisam continuar depois da emergência.
10. Verifique conteúdo, banco de dados e SEO
Procure páginas escondidas, links externos não autorizados, usuários desconhecidos, scripts inseridos, regras de redirecionamento e alterações em títulos ou descrições. Confira também mapas do site, arquivos de configuração e integrações com ferramentas de busca.
Pesquise o domínio no Google para localizar páginas estranhas, mas não trate a busca como inventário completo. O mecanismo pode mostrar apenas parte das URLs. Use os relatórios do Search Console e a análise técnica para entender o alcance.
Se o site invadido publicou spam, a remoção deve abranger todas as páginas e mecanismos que recriam o conteúdo. Apagar somente os exemplos visíveis pode não resolver a origem nem atender a uma revisão de segurança.
11. Monitore depois da recuperação
A volta ao ar não encerra o incidente. Monitore alterações de arquivos, novos usuários, tentativas de login, consumo do servidor, envio de e-mails, alertas e disponibilidade. Registre o que foi corrigido e as credenciais renovadas.
Confirme periodicamente que backups novos são concluídos e podem ser restaurados. Revise permissões e mantenha somente os acessos necessários. Se o mesmo sinal reaparecer, trate-o como possível persistência ou reinfecção e retome a investigação.
Após recuperar um site invadido, documente a causa provável, o alcance confirmado, as ações realizadas e as medidas preventivas. Esse relatório facilita futuras manutenções e reduz o tempo de resposta se ocorrer outro alerta.
O que fazer quando o Google mostra aviso de segurança?
O relatório “Problemas de segurança” do Search Console pode apontar conteúdo invadido, malware, software indesejado ou engenharia social. O Google informa que páginas afetadas podem receber avisos nos resultados ou uma tela de alerta no navegador.
Abra cada tipo de problema, analise as URLs de exemplo e corrija a ocorrência em todo o site. A lista fornecida pode ser apenas uma amostra. O relatório oficial de problemas de segurança orienta testar a correção e solicitar revisão depois que todos os itens forem resolvidos.
Na solicitação, descreva com clareza o problema, as ações adotadas e o resultado. Não peça revisão antes de concluir a limpeza. Se o aviso for um erro, reúna evidências e use o procedimento apropriado, sem tentar ocultar páginas do site invadido apenas para acelerar a análise.
Uma revisão pode levar tempo e não substitui o monitoramento. Continue acompanhando o Search Console, os registros e a experiência de visitantes. Separar o relatório de segurança de uma ação manual também é importante: são relatórios diferentes, com causas e procedimentos distintos.
Como reduzir o risco de ter o site invadido novamente?
Nenhuma medida oferece proteção absoluta. Segurança funciona em camadas: atualizações, senhas, autenticação, permissões, hospedagem, backup, monitoramento e práticas dos usuários. A prevenção deve partir do que realmente causou ou facilitou o incidente.
- mantenha núcleo, temas e plugins atualizados;
- remova extensões e usuários sem necessidade;
- use senhas exclusivas e autenticação em dois fatores quando disponível;
- controle acessos à hospedagem, domínio, e-mail e WordPress;
- mantenha backups em local separado e teste a restauração;
- utilize HTTPS corretamente configurado;
- acompanhe alertas e mudanças relevantes;
- escolha componentes mantidos por fornecedores confiáveis;
- proteja os dispositivos usados na administração;
- defina quem responde quando surgir um incidente.
A proteção contra tentativas de login pode incluir limitação de requisições, autenticação adicional e controles no servidor ou na rede. A documentação oficial sobre ataques de força bruta no WordPress recomenda senhas únicas, 2FA para administradores e monitoramento de anomalias.
Não instale vários plugins de segurança com funções sobrepostas sem avaliar compatibilidade e consumo. Mais ferramentas não significam automaticamente mais proteção para um site invadido. Uma configuração simples, atualizada e acompanhada pode ser mais confiável que uma pilha de componentes abandonados.
Também é necessário proteger o processo humano. Mensagens falsas podem tentar obter senhas ou induzir a instalação de arquivos. Confirme pedidos de acesso, evite compartilhar credenciais em conversas abertas e retire permissões quando alguém deixa de trabalhar no projeto.
O que não fazer diante de um site invadido
Não execute comandos desconhecidos, não apague o banco de dados e não restaure qualquer backup sem conferir sua origem. Evite publicar senhas ou detalhes sensíveis em fóruns. Não confie em quem promete limpeza definitiva sem analisar o ambiente.
Também não esconda o problema mantendo páginas perigosas acessíveis. Se visitantes correm risco, contenha o acesso e comunique os responsáveis. Uma interrupção planejada pode ser menos prejudicial que permitir phishing, download malicioso ou coleta indevida de informações.
Não presuma que trocar a senha resolve todo site invadido. O acesso pode permanecer por arquivos, usuários, chaves, integrações ou outra instalação na hospedagem. A recuperação precisa confirmar que a persistência foi removida e que a causa foi tratada.
Quando contratar suporte para site invadido?
Procure apoio especializado quando o site recebe pagamentos ou dados pessoais, quando não existe backup confiável, quando a hospedagem suspendeu a conta, quando o alerta reaparece ou quando ninguém conhece a estrutura técnica.
Também vale buscar suporte se várias instalações compartilham o servidor, se há personalizações importantes ou se o responsável não consegue comparar arquivos e registros. Alterações improvisadas podem aumentar o tempo de recuperação e causar perda de conteúdo legítimo.
Antes de contratar a recuperação de um site invadido, pergunte como o profissional preservará dados, quais acessos serão necessários, como registrará as mudanças e o que está incluído no acompanhamento. Não entregue senhas definitivas por canais inseguros. Crie acessos específicos quando possível e revogue-os ao término.
A Web10 pode analisar a situação antes de propor uma intervenção. Se você encontrou sinais de site invadido, informe quando o problema começou, quais avisos apareceram, qual plataforma utiliza e se possui acesso à hospedagem e aos backups.
Fale com a Web10 pelo WhatsApp: 18 99697-4124.
Perguntas frequentes sobre site invadido
Um site invadido precisa ficar fora do ar?
Depende do risco para visitantes e dados. Pode ser necessário restringir o acesso ou colocar uma página segura de manutenção enquanto ocorre a análise. A decisão deve equilibrar contenção, preservação de evidências e continuidade do negócio.
Restaurar o backup elimina a invasão?
Não necessariamente. O backup pode já estar contaminado, e a vulnerabilidade original pode continuar ativa. É preciso confirmar a data, verificar a integridade, preservar dados recentes e corrigir a causa antes ou durante a restauração.
Um plugin de segurança consegue limpar tudo?
Ferramentas podem detectar padrões e ajudar no monitoramento, mas nenhuma garante identificar todo tipo de alteração. A análise deve abranger arquivos, banco de dados, usuários, credenciais, hospedagem e outras instalações relacionadas.
O Google remove o aviso automaticamente?
O Search Console permite solicitar revisão depois que todos os problemas foram corrigidos. O prazo e o resultado dependem da avaliação do Google. O pedido deve explicar as correções e só deve ser feito após testar o site.
Quanto custa recuperar um site invadido?
O valor depende do tamanho, da plataforma, do alcance do incidente, dos backups, da hospedagem e das funções do projeto. Um orçamento responsável exige análise prévia; preço fixo sem diagnóstico pode não refletir o trabalho necessário.
Como saber por onde o invasor entrou?
Registros, arquivos alterados, usuários, versões de componentes e histórico de acessos podem oferecer pistas. Nem sempre é possível provar uma única origem. Quando não houver evidência suficiente, a conclusão deve permanecer como hipótese, não como certeza.
Recupere o site com método e preserve seu negócio
Um site invadido precisa de contenção, diagnóstico, limpeza, renovação de acessos e acompanhamento. A pressa deve servir para organizar a resposta, não para executar mudanças aleatórias. Preservar dados, trabalhar com fontes confiáveis e registrar cada etapa aumenta a segurança da recuperação.
Se você precisa avaliar um alerta, recuperar o acesso ou verificar se a limpeza foi completa, converse com a Web10. Explique os sinais observados e os recursos mais importantes do projeto para que a situação seja analisada antes de qualquer alteração.
Atendimento Web10 pelo WhatsApp: 18 99697-4124.
