Limpar um WordPress pirateado: remoção de malware, cópias de segurança e proteção

Saiba mais sobre os serviços de auditoria de segurança WordPress da WPPoland.

Este guia percorre passo a passo a limpeza de um WordPress infetado. Usa ferramentas de linha de comandos (SSH, WP-CLI) porque são mais rápidas e completas do que qualquer plugin. Os scanners em forma de plugin aparecem mais abaixo, na secção sobre a documentação do WordPress.org.

#Sinais de que o seu WordPress foi pirateado

Antes de começar a limpar, confirme que o site está realmente comprometido. Os sinais mais comuns:

• Redirecionamentos indesejados: os visitantes são enviados para sites de spam, farmácias ou casinos
• Conteúdo de spam injetado: páginas com texto em japonês ou chinês ou ligações para sites maliciosos
• Utilizadores administradores desconhecidos: novas contas de administrador que não criou
• Ficheiros alterados recentemente: ficheiros do núcleo, de temas ou de plugins modificados sem o seu conhecimento
• Avisos da Google: uma etiqueta de aviso nos resultados de pesquisa ou uma página de aviso intersticial no navegador
• Queda de tráfego orgânico: a Google penalizou ou retirou o site do índice
• Envio de emails de spam: o seu servidor está a enviar emails não solicitados
• Desempenho degradado: o site ficou visivelmente mais lento

Se o primeiro sinal foram páginas japonesas no Google e não algo visível no site, provavelmente tem a variante dissimulada, que exige um primeiro passo diferente: consulte o hack japonês de palavras-chave antes de apagar o que quer que seja.

#Como os atacantes entram num site WordPress

Bots maliciosos varrem a web em busca de vulnerabilidades conhecidas, testam credenciais de administrador por força bruta e exploram servidores mal configurados. Para limpar um site, é preciso perceber primeiro como o atacante obteve acesso.

#Vulnerabilidades em plugins e temas desatualizados

Falhas como injeção de SQL (SQLi), inclusão local de ficheiros (LFI) e execução remota de código (RCE) surgem com frequência em plugins desatualizados. Os atacantes usam ferramentas automáticas para detetar versões vulneráveis conhecidas e executar as suas cargas. Duas classes de vulnerabilidade são especialmente perigosas:

• Injeção de objetos PHP (desserialização): ocorre quando dados do utilizador chegam diretamente à função unserialize() do PHP. Se o código contiver classes auxiliares que sirvam de “POP chain”, o atacante consegue instanciar objetos PHP arbitrários, executar código e escrever ficheiros no sistema.
• Envio de ficheiros sem restrições: se um plugin não valida bem os ficheiros enviados a partir dos seus formulários (por exemplo, verifica a extensão apenas no navegador e não no servidor), o atacante pode enviar uma web shell disfarçada de imagem, guardá-la em /wp-content/uploads/ e executá-la com um pedido HTTP direto.

#Palavras-passe fracas e ataques de força bruta

Os bots atacam sem parar /wp-login.php e /xmlrpc.php com listas de palavras-passe comuns. Se a conta de administrador usar uma palavra-passe fraca, acabará comprometida.

#Como os atacantes abusam do xmlrpc.php

O ficheiro herdado xmlrpc.php permite comunicar com a API do WordPress através de XML. Como suporta pedidos multicall, um atacante consegue testar centenas de combinações de credenciais num único pedido HTTP e contornar os limites normais de início de sessão.

#Infeção a partir de outros sites em alojamento partilhado

Se o seu site estiver num servidor partilhado, uma vulnerabilidade no site de um vizinho pode permitir ao atacante escrever ficheiros na árvore de diretórios e infetar os seus ficheiros limpos.

#O que o WordPress.org recomenda fazer primeiro quando um site foi pirateado

O artigo de suporte do WordPress.org FAQ My site was hacked trata a primeira hora como trabalho de documentação, não de limpeza. O primeiro passo concreto é anotar o que vê, quando reparou (com o fuso horário) e o que mudou recentemente: um plugin novo, uma edição do tema, uma alteração num widget. Essa nota é a base do relatório do incidente, quer limpe o site sozinho quer o entregue a outra pessoa.

O mesmo artigo enumera indicadores de compromisso que apontam para um ataque real e não para uma falha: o site está numa lista negra da Google ou do Bing, o alojamento desativou-o, está assinalado por distribuir malware, o antivírus dos visitantes bloqueia-o, alguém informa que ataca outros sites ou surgem utilizadores que ninguém criou.

Para a análise, o artigo combina scanners ao nível da aplicação (os plugins Wordfence, Sucuri, Quttera e GOTMLS) com scanners remotos como VirusTotal e Sucuri SiteCheck, porque cada tipo deteta coisas diferentes.

Quatro pontos desse artigo esquecem-se facilmente sob pressão:

• Analise também o seu próprio computador. O artigo refere que muitas infeções começam no equipamento do proprietário, onde um trojan captura as credenciais de FTP e do wp-admin. As palavras-passe novas escritas num portátil infetado chegam diretamente ao atacante.
• Fale cedo com o alojamento. Num alojamento partilhado, o ataque pode afetar mais do que um site, e um site usado para enviar spam pode levar o IP do servidor a listas negras de email, o que afeta o email enviado a partir desse mesmo servidor.
• Reinstale a mesma versão, e não a partir do wp-admin. O artigo desaconselha as opções de reinstalação do painel porque esses instaladores muitas vezes só sobrescrevem ficheiros existentes, enquanto os ataques acrescentam ficheiros novos. Indica /wp-admin e /wp-includes como os diretórios que se podem substituir com segurança.
• Altere as palavras-passe duas vezes. Uma ao descobrir o ataque e outra quando o site estiver confirmado como limpo, em todos os pontos de acesso: SFTP, wp-admin, painel do alojamento e MySQL. O artigo sugere ainda alterar o utilizador e a palavra-passe da base de dados e atualizar o wp-config.php em conformidade.

Também nomeia os ficheiros que merecem uma revisão manual seja qual for o tipo de infeção, porque uma alteração neles afeta todos os pedidos: .htaccess (na raiz e em qualquer subdiretório que o tenha), index.php e os ficheiros do tema header.php, footer.php e functions.php.

#Como colocar um WordPress pirateado offline durante a limpeza

O guia da Google Quarantine your site recomenda colocar o site pirateado offline, para que deixe de servir conteúdo aos utilizadores, e responder com o código 503, que indica uma indisponibilidade temporária. Para o WordPress contam dois detalhes:

• Sirva o 503 a partir de fora da árvore comprometida, por exemplo na configuração do servidor web ou do proxy que o alojamento controla. Um plugin de manutenção ou um ficheiro PHP dentro da instalação infetada corre ao lado do malware.
• Uma resposta 4xx ou 5xx por si só não chega, porque “com estes códigos de estado ainda pode ser devolvido conteúdo nocivo aos utilizadores” (Google, Quarantine your site, tradução própria). Um disallow no robots.txt também não chega: só bloqueia os rastreadores dos motores de busca, não os visitantes.

O guia afirma que colocar o site offline temporariamente durante a recuperação dificilmente afetará o posicionamento futuro. Os outros dois passos coincidem com o WordPress.org: avisar o alojamento, rever a lista de utilizadores, apagar as contas criadas pelo atacante e alterar todas as palavras-passe (FTP, base de dados, administrador do sistema e CMS).

Volte a colocar o site online antes de pedir a revisão à Google, porque a revisão precisa de páginas que o Googlebot consiga rastrear.

#Como fazer uma cópia de segurança de um WordPress pirateado

Antes de qualquer alteração, crie uma cópia de segurança completa do estado infetado. Isto é crucial por duas razões: (1) se algo correr mal durante a limpeza, pode restaurar, e (2) pode analisar o malware mais tarde para perceber como aconteceu a intrusão.

# Cópia de segurança do sistema de ficheiros
tar -czf /tmp/compromised-files-$(date +%Y%m%d).tar.gz -C /var/www/html .

# Exportar a base de dados
wp db export /tmp/compromised-db-$(date +%Y%m%d).sql --path=/var/www/html

#Como analisar os registos de acesso do WordPress por SSH

Para localizar o ponto de entrada e o momento do ataque, analise os registos de acesso do servidor web com comandos SSH. Assim encontra pedidos POST maliciosos que coincidem com as datas de alteração dos ficheiros.

# IP com muitos pedidos POST ao login ou ao XML-RPC
grep -h "POST /wp-login.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20
grep -h "POST /xmlrpc.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20

# Tentativas de exploração contra caminhos conhecidos
grep -E "wp-config\.php|\.env|eval\(|union\+select" /var/log/nginx/access.log

# Pedidos de um IP que alterou ficheiros durante a janela do ataque
grep "192.168.1.100" /var/log/nginx/access.log | grep -E "POST|PUT"

Identificar o IP de origem e o script exato que processou o pedido revela o plugin ou tema explorado, para que possa corrigir a vulnerabilidade.

#Como encontrar malware num WordPress pirateado

#Como encontrar ficheiros PHP suspeitos

Use grep e find para procurar padrões comuns de malware e ficheiros modificados:

# Procurar funções de ofuscação comuns
grep -rn "eval(" /var/www/html/wp-content/ --include="*.php"
grep -rn "base64_decode" /var/www/html/wp-content/ --include="*.php"
grep -rn "str_rot13" /var/www/html/wp-content/ --include="*.php"
grep -rn "gzinflate" /var/www/html/wp-content/ --include="*.php"

# Procurar ficheiros PHP em uploads (não deveria haver nenhum)
find /var/www/html/wp-content/uploads/ -type f -name "*.php"

# Listar ficheiros PHP alterados nos últimos 7 dias
find /var/www/html/ -type f -name "*.php" -mtime -7

#Como verificar os administradores na base de dados

-- Procurar administradores suspeitos
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
    SELECT user_id FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities'
    AND meta_value LIKE '%administrator%'
);

#Tipos de ataque ao WordPress mais comuns em 2026

#Como substituir o núcleo do WordPress após um ataque

Não confie em antivírus para os ficheiros do núcleo. O método mais seguro é substituir todos os ficheiros do núcleo por versões limpas, sem tocar na pasta de conteúdos wp-content/:

# Descarregar o núcleo limpo sem tocar em wp-content
wp core download --force --skip-content --path=/var/www/html

# Verificar a integridade com as somas de verificação oficiais
wp core verify-checksums --path=/var/www/html

Isto substitui wp-admin/, wp-includes/ e todos os ficheiros do núcleo na raiz pelas versões originais, eliminando as alterações maliciosas nesses ficheiros.

#Como interpretar o wp core verify-checksums e a verificação de plugins

wp core verify-checksums descarrega do WordPress.org as somas md5 da versão instalada e compara-as com os ficheiros no disco. Segundo a referência do comando, fá-lo sem carregar o WordPress, o que é importante num site em que carregar o WordPress executa o malware.

Um núcleo limpo termina com Success: WordPress installation verifies against checksums. Cada ficheiro alterado gera uma linha como Warning: File doesn't verify against checksum: wp-includes/version.php, e a execução acaba com Error: WordPress installation doesn't verify against checksums.

Opções úteis depois de um ataque:

• --include-root verifica também o diretório raiz e avisa se encontrar elementos que não pertencem ao WordPress, que é onde aparecem os carregadores deixados junto a wp-load.php.
• --version=<version> e --locale=<locale> comparam com uma versão e um idioma concretos.
• --format=json devolve uma saída legível por máquina para um script ou um ticket do incidente.
• --insecure repete a transferência sem validar o certificado. A referência avisa que isso deixa o pedido exposto a um ataque de intermediário, por isso não o use num servidor comprometido.

wp core download --force só sobrescreve os ficheiros existentes, segundo a referência da transferência. Os ficheiros que o atacante acrescentou dentro de wp-admin/ ou wp-includes/ podem sobreviver. A ordem mais segura é apagar esses dois diretórios, que a FAQ do WordPress.org considera seguros de substituir, e depois descarregar e verificar.

Para os plugins, wp plugin verify-checksums --all verifica os ficheiros com as somas do WordPress.org, e --strict faz falhar até as “alterações ligeiras”, como edições do readme.txt (referência). Como as somas vêm do WordPress.org, o comando cobre os plugins do diretório do WordPress.org. Os plugins premium e desenvolvidos à medida precisam de um pacote novo do fornecedor ou do seu próprio repositório.

wp core verify-checksums --include-root --path=/var/www/html
wp plugin verify-checksums --all --strict --path=/var/www/html

#Como limpar o wp-content num WordPress infetado

#Como reinstalar os plugins após um ataque

A forma mais segura é apagar e reinstalar todos os plugins, para que não fiquem portas dos fundos escondidas:

# Listar plugins ativos
wp plugin list --status=active --path=/var/www/html

# Reinstalar cada plugin a partir do repositório
wp plugin install nome-do-plugin --force --path=/var/www/html

Para plugins premium, descarregue versões novas do fornecedor original.

#O que fazer com os temas após um ataque

Apague todos os temas exceto o ativo. No tema ativo, compare os ficheiros linha a linha com a versão original.

#Como eliminar ficheiros PHP da pasta uploads

A pasta uploads NUNCA deve conter ficheiros PHP. Elimine todos os que encontrar:

find /var/www/html/wp-content/uploads/ -name "*.php" -delete
find /var/www/html/wp-content/uploads/ -name "*.phtml" -delete
# .htaccess apenas listar e rever, não apagar: o WooCommerce protege woocommerce_uploads/ com o seu próprio .htaccess
find /var/www/html/wp-content/uploads/ -name ".htaccess"

#Como limpar a base de dados de um WordPress pirateado

Os atacantes deixam muitas vezes contas de administrador próprias, scripts de redirecionamento e spam de SEO diretamente nas tabelas da base de dados.

#Como eliminar administradores falsos

-- Eliminar utilizadores suspeitos (verifique os IDs primeiro)
DELETE FROM wp_users WHERE ID IN (lista_de_ids_suspeitos);
DELETE FROM wp_usermeta WHERE user_id IN (lista_de_ids_suspeitos);

#Como encontrar scripts injetados em wp_posts e wp_options

Ataques típicos como o Japanese Keyword Hack escrevem milhares de ligações de spam diretamente nos campos dos artigos:

-- Procurar scripts injetados nos artigos
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
OR post_content LIKE '%eval(%';

-- Procurar opções suspeitas
SELECT option_name, option_value
FROM wp_options
WHERE option_name LIKE '%hack%'
OR option_name LIKE '%inject%'
OR option_value LIKE '%base64_decode%';

#Como eliminar portas dos fundos no cron e na configuração do WordPress

O malware agenda muitas vezes tarefas cron que voltam a infetar os ficheiros limpos. Por isso, mesmo que substitua todos os ficheiros de sistema, o site pode voltar a ser infetado em poucas horas.

#Como verificar as tarefas cron do WordPress

Todas as tarefas agendadas são guardadas como arrays serializados na tabela wp_options, na opção cron. Com este comando WP-CLI vê os eventos agendados:

# Listar todos os eventos cron agendados
wp cron event list --path=/var/www/html

#Como apagar um evento cron malicioso com PHP

Se encontrar um hook de cron desconhecido (por exemplo, wp_update_system_cache a apontar para código dinâmico), este script PHP remove-o:

declare(strict_types=1);

namespace WPPoland\Security\Cron;

/**
 * Remove hooks de cron maliciosos do agendamento.
 */
function remove_malicious_cron_event(): void {
    $target_hook = 'wp_update_system_cache';

    // Remover o hook se estiver agendado
    $timestamp = wp_next_scheduled( $target_hook );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, $target_hook );
        error_log( sprintf( 'Security Action: Unscheduled backdoor hook "%s".', $target_hook ) );
    }
}
add_action( 'init', __NAMESPACE__ . '\\remove_malicious_cron_event' );

#Como encontrar portas dos fundos em .user.ini e .htaccess

Um mecanismo de persistência habitual é injetar ficheiros .user.ini ou .htaccess na raiz do site. O atacante define diretivas PHP como auto_prepend_file para executar um script malicioso antes de carregar qualquer código do WordPress:

; Diretiva maliciosa em .user.ini
auto_prepend_file = "/var/www/html/wp-content/uploads/2026/06/backdoor.jpg"

Como este ficheiro atua de forma global, qualquer pedido PHP, incluindo o ecrã de início de sessão, executa a porta dos fundos. Procure alterações em .user.ini e .htaccess na raiz do site e confirme que nenhum script não autorizado é anteposto ou acrescentado.

#Como reforçar o WordPress depois de limpar o malware

Depois da limpeza, reforce o site contra futuros ataques:

#Como alterar a palavra-passe de administrador e as chaves salt

# Alterar a palavra-passe de administrador
wp user update admin --user_pass="nova-palavra-passe-segura" --path=/var/www/html

# Regenerar as chaves salt (termina todas as sessões ativas)
wp config shuffle-salts --path=/var/www/html

Renovar as chaves salt invalida de imediato todas as sessões e cookies de início de sessão existentes.

#Que proteções acrescentar ao wp-config.php

// Desativar o editor de ficheiros de temas e plugins
define( 'DISALLOW_FILE_EDIT', true );

// Bloquear a instalação de plugins e temas a partir do painel
define( 'DISALLOW_FILE_MODS', true );

// Forçar HTTPS na área de administração
define( 'FORCE_SSL_ADMIN', true );

#Que permissões de ficheiros usar no WordPress

# Diretórios: 755
find /var/www/html/ -type d -exec chmod 755 {} \;

# Ficheiros: 644
find /var/www/html/ -type f -exec chmod 644 {} \;

# wp-config.php: 400 (só leitura)
chmod 400 /var/www/html/wp-config.php

#Quem deve ser o proprietário dos ficheiros do WordPress

Além das permissões, reveja a propriedade dos ficheiros. O processo do servidor web (por exemplo www-data ou apache) não deve ser o proprietário dos ficheiros PHP do WordPress. Defina como proprietário um utilizador de implementação separado (por exemplo wp-user) e como grupo www-data. Assim, um processo do servidor web comprometido não consegue escrever nem alterar os ficheiros .php do sistema:

# Proprietário: utilizador de implementação; grupo: servidor web
chown -R wp-user:www-data /var/www/html/

# Escrita do servidor web apenas em uploads
chown -R www-data:www-data /var/www/html/wp-content/uploads/

#Sistema de ficheiros só de leitura para WordPress em Docker

A documentação oficial da imagem (docker-library/docs) descreve uma implementação estática: construir uma imagem própria com o código em /usr/src/wordpress e executá-la só de leitura, com armazenamento gravável apenas para /tmp, /run e, opcionalmente, wp-content/uploads. Por omissão, a imagem guarda o WordPress num volume gravável /var/www/html e atualiza-o aí, por isso read_only: true sobre a imagem padrão não dá esta proteção.

FROM wordpress:apache
WORKDIR /usr/src/wordpress
RUN set -eux; \
	find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e "s!/var/www/html!$PWD!g" -e "s!Directory /var/www/!Directory $PWD!g" '{}' +; \
	cp -s wp-config-docker.php wp-config.php
COPY custom-theme/ ./wp-content/themes/custom-theme/
COPY custom-plugin/ ./wp-content/plugins/custom-plugin/

# docker-compose.yml: imagem própria só de leitura
services:
  wordpress:
    image: custom-wordpress:tag
    read_only: true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./uploads:/usr/src/wordpress/wp-content/uploads

Com a camada de código selada, uma falha que permita escrever ficheiros só alcança o volume de uploads, e é por isso que as verificações de uploads deste guia continuam necessárias. Atualizar significa reconstruir e voltar a implementar a imagem, e a documentação lembra que isso deve ser feito com regularidade para receber as atualizações de segurança do WordPress.

#O que o guia de reforço do WordPress acrescenta após uma limpeza

O guia Hardening WordPress fixa o wp-config.php em 400 ou 440, para que só o utilizador e o servidor web o possam ler. Sobre DISALLOW_FILE_EDIT, diz que a definição “não impede um atacante de enviar ficheiros maliciosos para o seu site, mas pode travar alguns ataques” (WordPress.org, Hardening WordPress, tradução própria). Para o utilizador da base de dados bastam os privilégios de leitura e escrita no funcionamento normal, mas o guia desaconselha retirar privilégios estruturais como ALTER, porque algumas atualizações e plugins alteram o esquema. Quanto à monitorização, recomenda executar o controlo de ficheiros como root para que o atacante não o consiga desativar facilmente, vigiar apenas tipos de ficheiro executáveis como .php para reduzir o ruído e guardar cópias periódicas, de modo a ter versões de antes e de depois de um comprometimento.

#Como confirmar que o malware do WordPress foi eliminado

#Lista de verificação após eliminar o malware

• Núcleo do WordPress verificado com somas de verificação
• Todos os plugins reinstalados a partir de fontes limpas
• Ficheiros PHP eliminados de uploads
• Utilizadores administradores falsos eliminados
• Palavras-passe alteradas para todos os utilizadores
• Chaves salt regeneradas
• Permissões de ficheiros corrigidas
• DISALLOW_FILE_EDIT ativado
• XML-RPC desativado se não for necessário
• Plugin de segurança instalado (Wordfence, Sucuri)
• Cópias de segurança automáticas configuradas

#Como a Google informa sobre um site pirateado e quanto tempo demora a revisão

As conclusões da Google aparecem no Search Console, no relatório de problemas de segurança (Ajuda do Search Console). As páginas afetadas podem mostrar uma etiqueta de aviso nos resultados de pesquisa ou um aviso intersticial no navegador. O relatório usa quatro categorias de ataque:

A mesma página fixa três regras. Corrija o problema em todo o site, porque corrigir apenas algumas páginas não devolve parcialmente o site aos resultados. Clique em Request Review só quando todos os problemas do relatório estiverem corrigidos em todas as páginas. Não reenvie o pedido enquanto houver outro pendente. Um bom pedido explica o problema exato, descreve os passos dados para o corrigir e documenta o resultado.

O guia da Google Request a review acrescenta os requisitos prévios: propriedade verificada no Search Console, o site limpo, a vulnerabilidade corrigida e o site novamente online para que o Googlebot o possa rastrear. Verifique antes, com cURL ou Wget, a página inicial e um URL que o atacante alterou. Um pedido enviado enquanto o problema persiste prolonga o tempo em que o site continua assinalado.

Se a Google considerar o site limpo, os avisos do navegador e da pesquisa são retirados no prazo de 72 horas. Caso contrário, o relatório pode mostrar mais URLs de exemplo e os avisos mantêm-se. A Google não é a única lista: a FAQ do WordPress.org recomenda registar o site também no Bing Webmaster Tools, no Yandex Webmaster e no Norton Safe Web, porque os visitantes podem usar qualquer uma delas.

A 20 de outubro de 2026, a Google anunciou que o Chrome divide em dois níveis os avisos do Safe Browsing sobre sites, para quem tem a proteção melhorada ativa: sites suspeitos (veredicto com menor confiança, possível risco para o utilizador) e sites perigosos (veredicto com elevada confiança, risco elevado para o utilizador) (Google, 20 de outubro de 2026). Os sites perigosos continuam a receber o aviso vermelho de ecrã inteiro. O aviso de site suspeito tem formato, ícone, cor e texto diferentes, e a Google mostra-o quando uma página apresenta padrões enganosos habitualmente associados a sites maliciosos conhecidos.

#Como evitar que o WordPress volte a ser pirateado

A melhor defesa é a prevenção:

• Atualize sempre: núcleo, plugins e temas, automaticamente se possível
• Use palavras-passe fortes: mínimo de 16 caracteres, únicas para cada conta
• Ative a 2FA: autenticação de dois fatores para todas as contas de administrador
• Alojamento seguro: VPS com firewall, não alojamento partilhado
• Cópias de segurança diárias: automatizadas e guardadas fora do servidor
• Monitorização contínua: alertas de alterações de ficheiros e de atividade suspeita

#Como é um plano de segurança de 90 dias para WordPress

• Dias 1 a 30 (triagem imediata): auditoria completa da integridade dos ficheiros com WP-CLI para detetar ficheiros do núcleo alterados. Renove as palavras-passe da base de dados, as credenciais root da base de dados e as chaves de acesso SSH e SFTP. Renove os salts do wp-config.php para terminar as sessões ativas e desative a edição direta de temas e plugins com DISALLOW_FILE_EDIT.
• Dias 31 a 60 (forense e firewall): reveja as tarefas cron ativas para confirmar que não resta nenhuma função maliciosa agendada. Analise os registos do servidor web em busca de comportamentos anómalos, picos de POST ao XML-RPC ou padrões de LFI. Implemente uma firewall de aplicações web (WAF) no servidor ou um proxy inverso (por exemplo Cloudflare) para bloquear cargas SQLi e XSS na periferia da rede.
• Dias 61 a 90 (reforço e auditoria): configure cópias de segurança automáticas externas num armazenamento WORM (escrita única, leitura múltipla). Faça análise estática de código e testes de intrusão em temas próprios e plugins à medida. Agende análises de segurança trimestrais e defina um protocolo de resposta a incidentes para a equipa.

Conheça os nossos serviços de auditoria de segurança WordPress e de manutenção WordPress para proteger o seu site de forma profissional, ou contacte-nos diretamente.