Depois de uma intrusão num site WordPress, a primeira hora serve para documentar; a limpeza vem depois. Primeiro guardo as provas, depois apuro o vetor de ataque e só então removo o malware, numa cópia do site, longe da produção. Ficheiros apagados às cegas apagam os rastos do vetor, e uma cópia antiga restaurada sem verificar a data da infeção pode trazer de volta o próprio código malicioso.
Esta página descreve os sinais de intrusão, a ordem do meu trabalho depois de um incidente, as intrusões em lojas WooCommerce e em sites noutros sistemas e as obrigações do RGPD que começam a contar no momento da deteção. Se quer fazer a limpeza por conta própria, as instruções completas, com comandos, estão no guia de limpeza de um WordPress pirateado.
Site WordPress pirateado: sinais de intrusão
Sinais que costumam indicar uma intrusão e o primeiro passo que dou quando aparecem.
- O que vê: O Google mostra um aviso junto ao seu site ou o Search Console comunica um problema de segurança
- O que façoAbro o relatório de problemas de segurança no Search Console e a lista de endereços assinalados. É o ponto de partida do diagnóstico e do pedido de revisão posterior.
- O que vê: O Search Console tem um proprietário que ninguém na empresa adicionou
- O que façoRegisto-o como prova e retiro-lhe o acesso. Verificar os proprietários do Search Console é dos primeiros passos depois de detetar a intrusão.
- O que vê: Aparece uma conta de administrador desconhecida na lista de utilizadores
- O que façoReviso todas as contas de administrador e as tarefas cron. As contas que ninguém criou são removidas depois de eu guardar os seus dados como prova.
- O que vê: Os ficheiros do núcleo não coincidem com os originais
- O que façoCorro wp core verify-checksums e comparo os ficheiros dos plugins e dos temas com as versões das fontes oficiais.
- O que vê: O site redireciona os visitantes para endereços estranhos ou distribui código malicioso
- O que façoAtivo o modo de manutenção, para o site deixar de infetar visitantes, e faço uma cópia dos ficheiros e da base de dados como prova.
- O que vê: Clientes da loja relatam um comportamento estranho na página de encomenda ou de pagamento
- O que façoTrato o caso como possível violação de dados pessoais. Guardo as provas, anoto a hora do relato e informo-o, porque a partir desse momento contam os prazos do RGPD.
- O que vê: A infeção volta poucos dias depois da limpeza
- O que façoProcuro o vetor que ficou aberto: um backdoor na base de dados, uma tarefa cron, uma conta antiga. Uma limpeza sem fechar o vetor não se aguenta.
Primeira hora depois da intrusão: o que pode fazer sozinho
Antes de escrever a mim ou a qualquer outra pessoa, faça cinco coisas. Não apague nenhum ficheiro. Faça uma cópia dos ficheiros e da base de dados, mesmo infetada, porque é material de prova. Anote a data e a hora em que reparou na intrusão. Veja no Search Console se a lista de proprietários tem alguém desconhecido. Se o site distribui malware ou redireciona visitantes, ative o modo de manutenção.
Depois mude as palavras-passe do painel do WordPress, do SFTP e da base de dados. Não restaure uma cópia de segurança antiga enquanto não souber quando começou a infeção. Uma cópia de há uma semana não ajuda se o código malicioso está no site há um mês.
A limpeza avança mais depressa quando recebo logo acesso ao painel do alojamento, aos registos do servidor, ao SFTP, à base de dados e ao Search Console. Se os acessos estão espalhados por várias pessoas ou empresas, junte-os num só sítio antes de começarmos.
Remover malware do WordPress: a ordem do trabalho
Cada passo termina com algo que se pode verificar: uma cópia, um relatório, uma lista de alterações.
Contrato de subcontratação antes do acesso
Antes de eu ter acesso ao site, assinamos o contrato de subcontratação do artigo 28.º do RGPD. O site infetado guarda dados dos seus clientes.
Primeira hora: guardar as provas
Cópia dos ficheiros e da base de dados como prova, hora da deteção registada, modo de manutenção se o site distribui malware e verificação dos proprietários no Search Console. A partir da deteção contam os prazos do RGPD.
Diagnóstico como etapa separada
O diagnóstico tem preço e âmbito fechados. O resultado é a causa, o âmbito da reparação e o custo, por escrito. A limpeza começa depois de confirmar esse âmbito.
Vetor de ataque numa cópia do site
Trabalho numa cópia do site, longe da produção. Apuro o vetor a partir dos registos do servidor, do wp core verify-checksums e da comparação dos ficheiros dos plugins e temas com versões limpas.
Limpeza dos ficheiros e da base de dados
Removo malware e backdoors dos ficheiros e da base de dados, verifico as contas de administrador e as tarefas cron e reponho o núcleo e os plugins a partir de fontes limpas.
Novas palavras-passe e acessos
Mudo as palavras-passe do painel do WordPress, do SFTP e da base de dados. Trato os dados de acesso antigos como conhecidos do atacante.
Uma publicação que se pode reverter
Publico a versão limpa num só passo, com possibilidade de reversão. Acrescento proteções contra o vetor apurado e descrevo por escrito a causa e a forma de prevenção.
Pedido de revisão ao Google
Quando o site está limpo, peço a revisão no relatório de problemas de segurança do Search Console.
O último passo não depende de mim. Segundo a ajuda do Google, a revisão demora entre alguns dias e algumas semanas e, no fim, o Google envia um email. Por isso não prometo uma data para o aviso desaparecer dos resultados de pesquisa.
Quanto custa remover malware do WordPress
Não indico o preço da limpeza à partida, porque depende do que o diagnóstico encontrar: se a infeção toca alguns ficheiros ou também a base de dados e as contas, se as cópias de segurança são anteriores à infeção e se o vetor é um plugin que basta atualizar. O diagnóstico é uma etapa separada e fechada, com preço próprio. O resultado é a causa, o âmbito da reparação e o custo, por escrito. A limpeza começa depois de confirmar esse âmbito.
Um site sem contrato de manutenção segue pela reparação WordPress, onde indico o preço depois da descrição do incidente. O custo de uma manutenção contínua, que inclui análise de malware e cópias diárias, está na página preço da manutenção WordPress.
Loja WooCommerce pirateada
Uma intrusão numa loja difere de uma intrusão num site de empresa porque quase sempre envolve dados pessoais. A base de dados da loja guarda contas de clientes, moradas de entrega, números de telefone, muitas vezes o NIF e o histórico de encomendas. Por isso, numa loja, parto desde a primeira hora do princípio de que pode haver uma violação de dados pessoais e anoto logo a hora da deteção, que lhe entrego como responsável pelo tratamento.
A ordem do trabalho é a mesma de um site de empresa, mas a verificação é mais larga. Além dos ficheiros, da base de dados, das contas e das tarefas cron, verifico os plugins de pagamento, de transportadora e os conectores com outros sistemas, porque cada um tem as suas chaves de API. As chaves que possam ter saído têm de ser trocadas também do lado do prestador de pagamentos, do ERP e do programa de faturação, e não só no WordPress. Essa troca exige acesso aos painéis desses serviços, por isso fazemo-la em conjunto.
Depois da limpeza testo o percurso carrinho, dados, entrega e pagamento, com referência Multibanco ou MB WAY, sem fazer uma encomenda real, antes de a loja voltar a vender. Também confirmo que as encomendas pagas voltam a gerar fatura no programa certificado. A loja em que este teste tem de correr de forma constante acompanho-a no Store Reliability Plan. Quando, depois da intrusão, o carrinho ou o pagamento não funcionam e é preciso repor as vendas, o serviço certo é o sprint de recuperação WooCommerce.
Cenário típico: loja com contas de clientes e um plugin desatualizado
Um caso típico dos que me chegam de lojas: a loja funciona há alguns anos, tem contas de clientes e uma dúzia de plugins, alguns sem atualizações há meses. Alguém repara numa conta de administrador desconhecida ou num comportamento estranho na página de encomenda. Numa loja assim, primeiro guardo as provas e anoto a hora da deteção, depois verifico se, e que, dados de clientes podem ter sido lidos. Entrego-lhe essa descrição, porque é a sua empresa que decide se e quando notifica a violação à CNPD.
Cenário típico: o site de empresa redireciona quem chega pelo telemóvel
Outro cenário típico: o dono de um site de empresa sabe por um cliente que o site, aberto no telemóvel, salta para outro endereço, enquanto no computador parece normal. Este sinal costuma indicar código malicioso nos ficheiros ou na base de dados que só atua para certos visitantes. Também aqui começo pela cópia como prova e pelo modo de manutenção, e procuro o vetor nos registos do servidor e na comparação dos ficheiros com versões limpas. Se o site tem formulário de contacto, verifico também se o código malicioso teve acesso às mensagens recebidas, porque são dados pessoais.
Intrusão num site em Drupal, TYPO3, Laravel ou Symfony
A mesma ordem de trabalho (provas, vetor, limpeza numa cópia, novos acessos, uma publicação reversível) vale para sistemas fora do WordPress. Mudam as ferramentas: no Drupal e no TYPO3 reponho o núcleo e os módulos a partir de fontes limpas com Composer, numa aplicação Laravel ou Symfony comparo o código no servidor com o repositório.
Uma versão sem suporte de segurança não recebe correções para falhas novas. O Drupal 7 está sem suporte de segurança desde 5 de janeiro de 2025 e o Drupal 10 perde-o a 9 de dezembro de 2026. O suporte gratuito do TYPO3 12.4 terminou a 30 de abril de 2026. Depois de limpar um site numa versão destas, remover o código malicioso não chega: é preciso um plano de atualização ou de migração para WordPress. Para o Drupal 10, as opções estão no artigo fim de suporte do Drupal 10. Um site antigo em Joomla tem o seu caminho descrito no guia de migração do Joomla para WordPress em Portugal.
Intrusão no site e RGPD: 72 horas e a CNPD
Se, com a intrusão, alguém pode ter chegado a dados pessoais (contas de clientes, encomendas, mensagens de formulários), começam a contar os prazos do RGPD. O artigo 33.º, n.º 1, do RGPD diz que o responsável pelo tratamento notifica a violação à autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas depois de ter tido conhecimento dela, a menos que a violação não seja suscetível de resultar num risco para os direitos e liberdades das pessoas singulares. Uma notificação fora desse prazo tem de vir acompanhada dos motivos do atraso. Quando o risco é elevado, o artigo 34.º, n.º 1, exige ainda que as pessoas a quem os dados dizem respeito sejam informadas sem demora injustificada.
Em Portugal a autoridade de controlo é a CNPD. Na página sobre violação de dados, a CNPD indica que a notificação deve ser feita no prazo de 72 horas após ter tido conhecimento da violação, e a notificação faz-se pelo formulário próprio da CNPD.
Quem responde por quê numa violação de dados
A divisão de papéis vem do RGPD e do contrato de subcontratação que assinamos antes do acesso ao site.
A sua empresa, responsável pelo tratamento
- Decide se a violação tem de ser notificada à CNPD (artigo 33.º do RGPD)
- Decide se informa as pessoas a quem os dados dizem respeito (artigo 34.º do RGPD)
- Submete a notificação à CNPD e conta as 72 horas desde que teve conhecimento da violação
- Fala com os clientes cujos dados podem ter saído
Eu, subcontratante
- Informo-o da violação sem demora injustificada depois de ter conhecimento dela (artigo 33.º, n.º 2, do RGPD)
- Entrego os factos necessários à notificação: hora da deteção, ficheiros e dados afetados, vetor apurado
- Não notifico a CNPD em seu nome, salvo se o contrato o previr
- Removo os efeitos da intrusão e fecho o vetor dentro do âmbito escrito no contrato
A responsabilidade de cada parte, incluindo pelas consequências da intrusão, é a que o contrato define. É por isso que o contrato de subcontratação se assina antes do primeiro acesso ao site. Para a notificação serve o que nasce nos primeiros passos do meu trabalho: a hora da deteção, os ficheiros e tabelas afetados e o vetor apurado. O relatório completo, com a causa, chega-lhe por escrito.
Se a sua empresa está num setor abrangido pela NIS2 ou pelo DORA, as obrigações de notificação podem ir além do RGPD. A preparação da infraestrutura WordPress para essas exigências está na página conformidade NIS2 e DORA.
Limpar, restaurar ou substituir
A escolha depende de quando começou a infeção e de onde ela vem.
Tem uma cópia de segurança que é de certeza anterior à infeção e o vetor já é conhecido.
Restauro essa cópia numa cópia de trabalho, fecho o vetor e só depois publico. O conteúdo e as encomendas criados desde a data da cópia têm de ser transferidos à parte.
Não sabe quando começou a infeção, ou todas as cópias são mais recentes do que ela.
Limpo o site numa cópia: ficheiros, base de dados, contas, tarefas cron, núcleo e plugins a partir de fontes limpas.
A origem é um tema ou um plugin que já ninguém desenvolve.
Removo-o ou proponho um substituto. Se a troca exigir código novo, recebe orçamento próprio.
O site está numa versão de CMS sem suporte de segurança.
Depois da limpeza é preciso um plano de atualização ou de migração. Sem ele o vetor continua aberto.
O site não funciona depois da intrusão e não tem contrato de manutenção.
Nada indica uma intrusão, mas quer saber se o site está limpo.
Auditoria de segurança: relatório em 5 dias úteis, ordenado por prioridade.
Como detetar uma intrusão antes do Google
O aviso nos resultados do Google é um sinal tardio. Antes disso, a intrusão deixa rastos nos ficheiros e na base de dados. Na manutenção comparo os ficheiros do núcleo, dos plugins e dos temas com as somas de controlo das fontes oficiais (wp checksum core, wp checksum plugin --all), por isso um ficheiro alterado aparece no espaço de um dia. A análise de malware procura padrões conhecidos de código malicioso e a revisão mensal das contas de administrador apanha contas que ninguém criou.
A segunda fonte são as bases de dados de vulnerabilidades, entre elas a Patchstack e a WPScan. Quando aparece uma falha num plugin que o seu site usa, atualizo-o fora do ciclo semanal. Isso fecha o vetor antes de alguém o aproveitar.
Correções de código depois de uma intrusão
Quando o vetor foi código próprio do site, por exemplo um formulário num plugin feito para a empresa ou uma função do tema que não validava os dados recebidos, corrijo-o como parte da proteção contra o vetor apurado. A correção entra no sistema de controlo de versões, e verifico o código com o PHP_CodeSniffer e as regras das WordPress Coding Standards, que incluem regras de segurança, e com análise estática em PHPStan. Nos sistemas fora do WordPress sigo a norma PSR-12. Antes de publicar, revejo a alteração mais uma vez, separadamente da escrita. Se a correção exigir reconstruir uma parte maior do código, descrevo-a e orçamento-a à parte.
O que recebe depois da limpeza
Depois da limpeza recebe uma descrição escrita: como aconteceu a intrusão, o que foi alterado nos ficheiros e na base de dados, que acessos foram trocados e que proteções acrescentei contra o vetor apurado. Essa descrição serve para a notificação à CNPD, se a fizer, e para a conversa com o alojamento. A versão limpa é publicada num só passo, com possibilidade de reversão, e a cópia da versão infetada fica guardada como prova.
Se quer que, depois da limpeza, alguém vigie o site de forma contínua, ele passa para a manutenção na avença normal.
O que não prometo depois de uma intrusão
Não garanto que o site nunca volte a ser pirateado. A limpeza remove o código malicioso e fecha o vetor que foi possível apurar, mas surgem falhas novas em plugins a toda a hora. Também não garanto o tempo de reparação: depende do alcance da infeção, do acesso ao alojamento e de as cópias de segurança serem ou não anteriores à infeção. Não prometo uma data para o Google retirar o aviso, porque a revisão é feita pelo Google.
Prometo a ordem de trabalho descrita acima, o resultado do diagnóstico por escrito antes da limpeza e um relatório com a causa e a forma de prevenção depois dela.
Como a manutenção reduz o risco de nova intrusão
Na manutenção de sites WordPress faço cópias de segurança diárias e guardo-as pelo menos 30 dias, analiso os ficheiros à procura de malware e controlo a sua integridade, e reviso todos os meses as contas de administrador. A monitorização verifica a disponibilidade do site a cada 1 a 5 minutos e envia-me um alerta quando o site deixa de responder. Quando a análise encontra algo, isolo os elementos infetados, reponho uma versão limpa a partir da cópia, acrescento proteções contra o vetor e descrevo o incidente no relatório mensal.
Os trinta dias de cópias contam nas intrusões detetadas tarde. Quando a infeção tem duas semanas, o histórico de cópias ainda guarda uma versão anterior a ela. Mesmo assim, verifico a data da infeção antes de restaurar o que quer que seja.
Um plugin desatualizado com uma falha publicada é um vetor de ataque aberto. O que protege contra ele é o ciclo regular de atualizações descrito na página atualizações WordPress. O custo de uma manutenção que inclui a análise e as cópias está na página preço da manutenção WordPress.
Próximo passo, se o site está infetado agora: não apague nada, faça uma cópia dos ficheiros e da base de dados, anote a hora em que reparou na intrusão e escreva-me com o endereço do site e a descrição dos sinais.
