Se o seu WordPress começou a redirecionar visitantes, surgiram contas de administrador desconhecidas ou o navegador apresenta um aviso de segurança, é natural querer apagar os ficheiros suspeitos ou repor uma cópia de segurança.
Essas medidas podem ser necessárias, mas agir sem diagnóstico pode eliminar informação útil e deixar a porta de entrada aberta. A prioridade é conter o incidente, preservar evidências e recuperar o controlo dos acessos. Só depois deve decidir como limpar ou restaurar o website.
Confirmar os sinais e avaliar a gravidade
Nem todos os comportamentos anormais significam que o website foi atacado. Um erro num plugin, um redirecionamento mal configurado ou um problema de cache também podem explicar alguns sintomas. O primeiro passo é registar o que está a acontecer, quando começou e que páginas ou funcionalidades são afetadas.
| Sinal observado | Primeira verificação |
|---|---|
| Redirecionamentos inesperados | Registar origem e destino; verificar se ocorrem apenas em telemóvel ou em visitas vindas da Google. |
| Administradores desconhecidos | Confirmar contas criadas, alterações de permissões e endereços de correio eletrónico. |
| Páginas ou ligações de spam | Consultar o conteúdo do site, o Search Console e uma pesquisa site:dominio.pt. |
| Envio anormal de mensagens | Verificar formulários, registos de envio e configuração do serviço de correio eletrónico. |
| Ficheiros alterados ou que reaparecem | Comparar datas, localizações e alterações com versões legítimas. |
| Alertas do alojamento ou do navegador | Guardar a mensagem e identificar os endereços afetados. |
Estes sinais ajudam a orientar a investigação, mas não identificam, por si só, a origem do problema. Alguns redirecionamentos só aparecem na primeira visita, em determinados países ou para utilizadores sem sessão iniciada. Se o website estiver a colocar visitantes em risco, não espere pelo diagnóstico completo para limitar os danos.
Conter o incidente sem destruir evidências
Se o website distribui ficheiros maliciosos, apresenta páginas fraudulentas destinadas a recolher credenciais (phishing) ou redireciona visitantes para destinos perigosos, poderá ser necessário restringir temporariamente o acesso público. Dependendo do caso, deve isolar a instalação, desativar a funcionalidade afetada ou pedir ao fornecedor de alojamento que suspenda os serviços comprometidos, incluindo o envio de mensagens abusivas.
Uma simples página de manutenção não garante que o código malicioso deixe de ser executado. A contenção deve impedir, tanto quanto possível, a continuação do comportamento prejudicial.
Antes de apagar ou atualizar ficheiros, preserve, quando viável, uma cópia do estado atual: ficheiros, base de dados, configuração e registos disponíveis do servidor. Guarde também capturas de ecrã, mensagens de aviso, datas e alterações recentes. O fornecedor de alojamento pode ajudar a obter esses elementos sem agravar o incidente.
Uma cópia de segurança feita durante a infeção não deve ser tratada como uma versão pronta a restaurar. Serve para análise, comparação e eventual recuperação seletiva de dados legítimos. Preserve-a separadamente e confirme que as cópias anteriores não serão substituídas automaticamente.
Também deve identificar a última cópia de segurança que possa estar limpa. A data de deteção não é necessariamente a data da invasão: se o ataque começou há duas semanas, uma cópia de ontem pode já conter o mesmo problema.
Proteger contas, credenciais e sessões
Perante indícios de acesso não autorizado, a proteção das contas é urgente. A partir de um dispositivo de confiança, reveja os administradores do WordPress e os acessos ao alojamento, correio eletrónico, base de dados e serviços externos relevantes. Bloqueie contas suspeitas, renove credenciais potencialmente expostas e revogue acessos que já não sejam necessários.
No WordPress, a renovação das chaves e dos salts de segurança em wp-config.php pode invalidar os cookies de autenticação existentes e obrigar os utilizadores a iniciar sessão novamente. A autenticação de dois fatores também reduz o risco associado a palavras-passe roubadas.
Há uma precaução importante: se ainda existir código malicioso capaz de recolher credenciais, uma mudança de palavra-passe pode não ser suficiente. Por isso, controle os acessos logo que possível e repita a renovação das credenciais necessárias depois de eliminar o comprometimento. Faça estas alterações de forma coordenada para não perder o acesso legítimo aos sistemas.
Verifique também os computadores utilizados para administrar o website. Um dispositivo infetado pode voltar a expor credenciais mesmo depois de o WordPress ter sido recuperado.
Identificar a origem e os mecanismos de persistência
Encontrar um ficheiro malicioso não significa que se encontrou toda a infeção. Pode existir uma backdoor — um mecanismo oculto de acesso —, uma conta administrativa não autorizada ou uma tarefa agendada que volte a criar os ficheiros eliminados.
A investigação deve abranger três áreas:
- WordPress e ficheiros:
- núcleo do WordPress, plugins, temas, ficheiros enviados, configurações e alterações inesperadas. Sempre que possível, comparar os ficheiros com os originais da mesma versão, obtidos de fontes fiáveis.
- Base de dados:
- utilizadores, opções, conteúdos, scripts injetados e redirecionamentos que não aparecem como ficheiros autónomos.
- Infraestrutura e acessos:
- registos do servidor, tarefas agendadas, permissões, contas de alojamento e outros websites que possam partilhar o mesmo ambiente.
Existem ferramentas de verificação de integridade, incluindo comparações por checksums dos ficheiros oficiais do WordPress. São úteis, mas um resultado sem alterações não exclui malware noutros ficheiros, na base de dados ou em plugins comerciais. Nenhuma verificação isolada certifica que a instalação está limpa.
A origem pode ser uma vulnerabilidade num plugin, credenciais roubadas ou um problema fora do próprio WordPress. Se houver vários websites afetados, alterações ao nível do servidor ou falta de acesso aos registos, o fornecedor de alojamento deve participar na investigação desde cedo.
Restaurar, limpar ou reconstruir?
A decisão depende da confiança nas cópias disponíveis, da extensão do incidente e dos dados que precisam de ser preservados.
Restaurar uma cópia de segurança pode ser a opção mais rápida quando existe uma versão anterior ao comprometimento, suficientemente fiável e recuperável. Ainda assim, é necessário corrigir a vulnerabilidade original. Restaurar o mesmo plugin vulnerável, sem o atualizar ou substituir, pode reabrir a porta ao atacante.
Limpar a instalação existente pode fazer sentido quando não há uma cópia adequada ou quando é importante conservar dados recentes. Exige identificar e remover os mecanismos de persistência, não apenas os ficheiros assinalados por uma ferramenta.
Reconstruir a instalação a partir de componentes legítimos pode ser mais prudente quando a integridade dos ficheiros e configurações deixou de ser fiável. Em alguns casos, combina-se a substituição dos ficheiros com a recuperação seletiva de conteúdos e dados verificados.
Numa loja WooCommerce, restaurar uma base de dados antiga pode fazer desaparecer encomendas, registos e alterações posteriores à cópia. A recuperação deve prever a conciliação desses dados, incluindo o estado dos pagamentos, antes de voltar a aceitar compras.
Corrigir a causa e validar a recuperação
Depois de preservar as evidências necessárias e executar a recuperação, confirme que WordPress, plugins, temas e componentes do servidor utilizam versões mantidas e adequadas. Remova ou substitua software vulnerável ou abandonado, reveja as permissões e mantenha apenas os acessos indispensáveis.
Antes de reabrir o website, teste as páginas públicas e o painel de administração, incluindo visitas sem sessão iniciada, diferentes dispositivos, formulários e envio de mensagens. Nas lojas online, acrescente a validação do carrinho, da finalização da compra e das integrações essenciais, sem criar transações reais desnecessárias.
E se a Google sinalizou o website?
O relatório Problemas de segurança do Google Search Console pode identificar páginas comprometidas, malware ou conteúdo enganoso. Consulte os exemplos apresentados, mas não presuma que representam todos os endereços afetados. Verifique também se surgiram novos proprietários verificados no Search Console sem autorização.
Uma pesquisa site:dominio.pt pode revelar páginas de spam indexadas, embora não seja uma listagem completa. Depois de eliminar o conteúdo malicioso, corrigir a origem e testar o website, pode solicitar uma revisão no Search Console. Os avisos podem demorar algum tempo a desaparecer; a ausência de alertas, por outro lado, não garante que não existe uma infeção.
E se estiverem envolvidos dados pessoais?
Se houver suspeita de acesso não autorizado a dados de clientes, contas de utilizador ou informações recebidas através de formulários, é necessário avaliar também a possível violação de dados pessoais. Em Portugal, quando uma violação de dados pessoais é suscetível de representar risco para os direitos e liberdades das pessoas, o responsável pelo tratamento deve, em regra, notificá-la à CNPD até 72 horas após ter tido conhecimento da violação. Nem todo o ataque implica notificação, mas a avaliação não deve ficar à espera do fim da recuperação técnica.
Monitorizar depois de voltar online
A recuperação não termina quando a página inicial volta a carregar. Nos dias seguintes, acompanhe novas contas administrativas, alterações de ficheiros, registos de acesso e erros, envio de mensagens e alertas do Search Console. Guarde uma nova cópia de segurança depois de validar o estado recuperado e reveja a retenção e os testes de restauro das cópias futuras.
Se os ficheiros maliciosos reaparecerem ou surgirem novos redirecionamentos, é provável que ainda exista um mecanismo de persistência, uma credencial comprometida ou outra origem por corrigir. Um incidente recorrente, uma loja online afetada ou indícios de exposição de dados justificam acompanhamento técnico especializado.
Conclusão
Perante um WordPress atacado ou infetado, a primeira decisão não é que ficheiro apagar: é como impedir novos danos sem perder a informação necessária para recuperar. A partir daí, é possível identificar a origem, escolher entre limpeza, restauro ou reconstrução e validar o resultado.
O regresso do website ao funcionamento normal é um sinal positivo, mas é essencial verificar a remoção das alterações maliciosas, corrigir as falhas identificadas e manter a vigilância para detetar uma eventual reincidência.
