# Análise forense de site WordPress invadido em 6 etapas

A <strong>análise forense de site WordPress invadido</strong> reconstrói como, quando e por onde o ataque entrou antes de qualquer limpeza. Segundo o <a href="https://wpscan.com/statistics/" rel="noopener" target="_blank">WPScan (2025)</a>, 90% das vulnerabilidades WordPress vêm de plugins, 6% de temas e 4% do core. Preservar logs e timestamps reduz a perda de evidência a quase zero. Comece isolando o site, nunca apagando arquivos.

A análise forense de site WordPress invadido é o processo de investigar um ambiente comprometido para identificar o vetor de entrada, o que foi alterado e quais credenciais vazaram, tudo antes de remover o malware. Quem limpa primeiro destrói a evidência e quase sempre reinfecta. A ordem correta é preservar, investigar, conter e só então higienizar. Este guia trata o servidor como cena de crime: cada arquivo modificado, cada linha de log e cada usuário novo conta uma parte da história. Se você ainda não isolou o site, comece pelo <a href="https://full.services/seguranca-wordpress/">guias de segurança WordPress da FULL</a> e volte aqui para a parte investigativa.

---

## Diagnóstico forense: O que a análise forense de site WordPress invadido procura

A análise forense de site WordPress invadido busca quatro evidências objetivas: arquivos modificados fora do ciclo de atualização, contas de administrador criadas sem registro, requisições suspeitas nos logs e <a href="https://full.services/glossario/malware-wordpress/">malware</a> injetado em PHP ou no banco. Em 62 CVEs catalogadas só no Elementor, a maioria dos ataques entra por plugin desatualizado.

Segundo o perfil público do WPVulnerability, o vetor raramente é força bruta no login. Mapear esses quatro pontos define a profundidade da limpeza e separa o site que precisa de higienização cirúrgica do que exige reinstalação completa do core.

<table id="evidencias-forenses-wordpress">
  <caption>Análise forense de site WordPress invadido: evidência, sinal e ação</caption>
  <thead>
    <tr>
      <th scope="col">Evidência</th>
      <th scope="col">Sinal de comprometimento</th>
      <th scope="col">Ação investigativa</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Arquivos do core</th>
      <td>Hash diferente do core oficial</td>
      <td>Comparar com checksums via WP-CLI</td>
    </tr>
    <tr>
      <th scope="row">Usuários admin</th>
      <td>Conta criada fora de horário comercial</td>
      <td>Cruzar data de criação com logs</td>
    </tr>
    <tr>
      <th scope="row">Logs de acesso</th>
      <td>POST repetido em wp-login ou xmlrpc</td>
      <td>Filtrar por IP e user-agent</td>
    </tr>
    <tr>
      <th scope="row">Banco de dados</th>
      <td>Script injetado em wp_options ou posts</td>
      <td>Buscar eval, base64 e iframes ocultos</td>
    </tr>
  </tbody>
</table>

<p class="wp-caption-text">Legenda: a comparação de hashes revela exatamente quais arquivos do core foram adulterados na invasão.</p>

## Antes de tudo: Por que preservar evidência muda a análise forense de site WordPress invadido

A primeira regra da análise forense de site WordPress invadido é não tocar em nada por 15 a 30 minutos: copie os logs, gere um snapshot do banco e baixe os arquivos como estão. Cada `last_modified` de arquivo PHP e cada timestamp de log compõe a linha do tempo do ataque.

Quem deleta o backdoor antes de registrar o horário perde o elo que liga o vetor de entrada ao dano. Na prática, a gente vê no suporte da FULL que boa parte das reinfecções acontece porque a limpeza apagou a prova antes da investigação. Faça uma cópia forense intocada e trabalhe sempre sobre ela, nunca sobre o original em produção, preservando permissões e datas originais dos arquivos. Registre também o hash MD5 de cada arquivo suspeito antes de movê-lo: esse identificador prova, depois, que o material analisado é o mesmo coletado na cena, e sustenta a cadeia de custódia caso a invasão precise de relatório formal para seguro, cliente ou processo judicial sob a LGPD.

---

## Passo a passo: Análise forense de site WordPress invadido na ordem certa

A análise forense de site WordPress invadido segue seis etapas encadeadas, do isolamento ao relatório, e cada uma alimenta a próxima. Pular a preservação de evidência (Passo 1) inviabiliza correlacionar logs com arquivos (Passo 4), o ponto onde a maioria das investigações descobre o vetor real. Reserve de 2 a 4 horas para um site médio.

### Passo 1: Isole o site e congele a evidência

Coloque o site em modo de manutenção ou bloqueie o acesso externo por firewall antes de investigar. Baixe via SFTP todo o `wp-content`, exporte o banco com `mysqldump` e salve os logs de acesso e erro dos últimos 30 dias. Não rode nenhum limpador ainda: o objetivo é uma fotografia fiel do site comprometido. Anote o horário em que percebeu a invasão, porque ele vira o marco zero da timeline forense.

### Passo 2: Compare o Core com a versão oficial

Use o WP-CLI com o comando `wp core verify-checksums` para listar todo arquivo do core cujo hash não bate com o WordPress.org. Qualquer divergência em `wp-admin` ou `wp-includes` indica injeção direta no core, sinal de invasão profunda. Repita o raciocínio com `wp plugin verify-checksums --all` para os plugins do repositório. Os arquivos que falham o checksum entram na lista de evidências da sua análise forense de site WordPress invadido.

### Passo 3: Audite usuários, chaves e tarefas agendadas

Liste todos os administradores com `wp user list --role=administrator` e marque qualquer conta que você não reconheça ou que tenha sido criada na janela do ataque. Verifique as chaves de API ativas, os cron jobs ocultos em `wp_options` e as senhas de aplicativo. Um admin fantasma com e-mail aleatório é a assinatura clássica de quem manteve acesso persistente após a primeira invasão.

### Passo 4: Correlacione logs de acesso com arquivos modificados

Cruze o `last_modified` dos arquivos PHP suspeitos com as linhas do log de acesso no mesmo minuto. Quando um arquivo foi alterado às 03h14 e o log mostra um POST em `xmlrpc.php` vindo do mesmo IP no mesmo instante, você encontrou o vetor de entrada. Essa correlação é o coração da análise forense de site WordPress invadido: ela transforma suspeita em prova e revela se o ataque veio de plugin, de credencial ou de upload malicioso.

### Passo 5: Inspecione o banco de dados por injeção

Busque no banco por padrões de código malicioso: `eval(`, `base64_decode`, `<script>` em `wp_options`, iframes ocultos em `wp_posts` e admins espúrios em `wp_users`. O All in One Security ajuda aqui com seu scanner de integridade de arquivos, mas a leitura do banco costuma ser manual. Exporte as linhas suspeitas para o relatório antes de remover qualquer coisa, mantendo a evidência preservada.

### Passo 6: Documente a timeline e o vetor confirmado

Monte um relatório com a linha do tempo: data do vetor de entrada, arquivos afetados, contas comprometidas e dados potencialmente expostos. Esse documento orienta a limpeza, a comunicação com clientes sob a LGPD e o endurecimento posterior. Sem ele, a remoção vira tentativa e erro. Com ele, você sabe exatamente o que limpar e qual brecha fechar para não reinfectar.

<p class="wp-caption-text">Legenda: cada arquivo listado como divergente entrou no relatório forense como evidência de adulteração.</p>

## Cves reais: O vetor que a análise forense de site WordPress invadido costuma confirmar

Na maioria das investigações, a análise forense de site WordPress invadido aponta um plugin com vulnerabilidade conhecida como ponto de entrada. Dois exemplos reais e já corrigidos mostram o tipo de falha: a <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-48777" rel="noopener" target="_blank">CVE-2023-48777</a> no Elementor, com CVSS 9.9, permitia upload arbitrário de arquivo.

A <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-35489" rel="noopener" target="_blank">CVE-2020-35489</a> no Contact Form 7 (CVSS 10.0, abaixo da versão 5.3.2) abria upload irrestrito. Ambas já têm patch: o risco real hoje é o site que nunca atualizou. Distinga sempre o risco atual sem patch de uma CVE histórica já corrigida, porque tratar falha antiga como ameaça viva gera alarme falso e desperdiça horas de limpeza.

A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, ou seja, está autorizada a atribuir IDs CVE oficiais. Quem investiga vulnerabilidade aqui literalmente cataloga CVE. Por isso a leitura de uma falha não para no CVSS: importa a versão afetada, a existência de patch e se o exploit é público. Para o caso do plugin de firewall, vale lembrar que o próprio All in One Security acumula 43 CVEs históricas, todas com patch e zero sem correção hoje, segundo o perfil público do WPVulnerability, sinal de manutenção ativa, não de fragilidade. Consulte o <a href="https://security.full.services/vulnerabilidades-no-wordpress" rel="noopener" target="_blank">repositório de vulnerabilidades</a> da FULL para confirmar a versão do seu plugin.

## Ferramentas que apoiam a análise forense de site WordPress invadido

A análise forense de site WordPress invadido combina quatro ferramentas reais e complementares: WP-CLI para checksums do core, Wordfence ou All in One Security para varredura de integridade, o NVD para confirmar a CVE do vetor e o Sucuri SiteCheck para detecção remota de blacklist. Nenhuma sozinha resolve a investigação por inteiro.

O WP-CLI mostra o que mudou; o scanner mostra onde está o malware; o NVD confirma a falha explorada. Nenhuma leitura isolada fecha o caso: o checksum aponta o arquivo adulterado, mas só o cruzamento com o log revela quando e por qual IP ele foi alterado, e só o NVD confirma se a versão instalada do plugin ainda expõe aquela brecha. É a correlação entre as quatro fontes que transforma sinal solto em vetor confirmado, exatamente como na linha do tempo do Passo 4. Trabalhe sempre sobre a cópia forense, nunca no site em produção, para não contaminar a evidência durante a varredura. Para a configuração do firewall, consulte o <a href="https://teamupdraft.com/documentation/all-in-one-security/" rel="noopener" target="_blank">passo a passo oficial do All in One Security</a>.

Depois de mapear o vetor, a limpeza precisa seguir uma rota testada. Veja como executar a higienização sem perder ranqueamento no nosso guia de <a href="https://full.services/como-remover-malware-do-wordpress/">como remover malware do WordPress</a> e, para recuperar o ambiente do zero, o tutorial de <a href="https://full.services/como-limpar-e-recuperar-um-site-wordpress-hackeado/">como limpar e recuperar um site WordPress hackeado</a>. Quem chegou aqui pelo susto inicial pode revisar o protocolo de emergência em <a href="https://full.services/site-wordpress-invadido-o-que-fazer-imediatamente/">site WordPress invadido: o que fazer imediatamente</a>.

## Erros comuns que invalidam a análise forense de site WordPress invadido

O erro mais caro na análise forense de site WordPress invadido é restaurar um backup antigo antes de investigar: isso apaga a evidência e, se o backup já estava infectado, reinfeta na hora. Outro erro frequente é limpar arquivos sem confirmar o vetor, o que deixa o backdoor intacto.

Na prática, a gente vê no suporte da FULL que a maioria das reinfecções vem dessas duas pressas. Antes de qualquer restauração, valide a integridade do ponto de <a href="https://full.services/glossario/backup-wordpress/">backup</a> com o guia de <a href="https://full.services/como-fazer-backup-do-seu-site-wordpress/">como fazer backup do seu site WordPress</a>. E nunca trabalhe sobre o site em produção: clone o ambiente comprometido e investigue na cópia, com <a href="https://full.services/glossario/firewall-wordpress/">firewall</a> bloqueando acesso externo. Um terceiro erro silencioso é confiar só no scanner automático: ele acha o malware conhecido, mas ignora o backdoor sob medida que o atacante deixou para reentrar. A leitura manual do banco e dos arquivos recém-modificados é o que fecha essa lacuna e evita a falsa sensação de site limpo.

## Como validar que a análise forense de site WordPress invadido foi completa

Uma análise forense de site WordPress invadido só está completa quando você tem o vetor confirmado, a timeline documentada e zero arquivo divergente após a limpeza. Rode o `wp core verify-checksums` de novo: a saída precisa vir limpa, sem nenhuma linha vermelha.

Confirme que nenhum admin fantasma sobrou, que os logs não mostram mais o IP atacante e que o Sucuri SiteCheck não acusa blacklist. Para fechar o ciclo, faça uma <a href="https://full.services/como-fazer-uma-auditoria-completa-de-seguranca-no-seu-wordpress/">auditoria completa de segurança no WordPress</a> e cruze o resultado com o relatório forense. Se algum ponto ainda divergir, a investigação não terminou e a brecha continua aberta para o próximo ataque. Por fim, monitore os primeiros sete dias após a limpeza: a reinfecção, quando acontece, costuma aparecer nesse intervalo, e o backdoor que escapou se revela no primeiro acesso anômalo registrado no log. Só então o caso pode ser dado como encerrado com segurança.

## Proteja o WordPress com o bundle PRO da FULL

Recuperar um site invadido custa horas de investigação; preveni-lo custa centavos por dia. O plano PRO da FULL sai por R$849 e inclui 17 plugins premium, entre eles o All in One Security e o Wordfence, para 10 sites, o que dá R$85 por site.

Esse valor cobre firewall, varredura de integridade e hardening sem licença avulsa. A gente vê no suporte que a maioria das invasões evitáveis vem de plugin pago pirata ou desatualizado, exatamente o que o bundle elimina ao manter tudo licenciado e atualizado. Conheça o <a href="https://full.services/all-in-one-security/">All in One Security</a> e ative a proteção em <a href="https://full.services/planos">FULL.services/planos</a>. Para investigar agora se algum plugin do seu site está vulnerável, rode o <a href="https://security.full.services" rel="noopener" target="_blank">FULL Scan</a> gratuitamente.

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-da-investigacao">Metodologia da investigação forense</h2>
<p>O protocolo descrito foi consolidado entre <time datetime="2024-01">janeiro de 2024</time> e <time datetime="2026-05">maio de 2026</time> sobre WordPress 6.x, PHP 8.1 e 8.2, em servidores Apache e Nginx. As CVEs citadas vêm do NVD e do perfil público do WPVulnerability, com versão afetada e patch confirmados na data da consulta. Os checksums foram validados via WP-CLI 2.x contra o repositório oficial do WordPress.org. A correlação de logs usou acesso e erro de Apache combine. As reincidências de malware caem de forma consistente quando a investigação precede a limpeza, segundo observação qualitativa do suporte da FULL sobre os 150 mil sites WordPress monitorados. Cada CVE referenciada foi conferida individualmente no NVD pela data da consulta, distinguindo risco atual sem patch de falha histórica já corrigida. Como a FULL é a única CNA brasileira sob a CISA, a catalogação segue o rigor de quem atribui IDs CVE oficiais.</p>
</aside>

<h2 id="faq">Perguntas frequentes sobre análise forense de site WordPress invadido</h2>

<details>
<summary>É possível fazer análise forense de site WordPress invadido sem instalar plugin no servidor?</summary>
<p>Sim, e muitas vezes é o método preferido. Você baixa os arquivos via SFTP, exporta o banco com mysqldump e usa o WP-CLI por linha de comando, sem adicionar nada ao site comprometido. Instalar plugin novo num ambiente invadido pode contaminar a evidência ou ser bloqueado pelo próprio backdoor. A investigação externa preserva a cena intacta e ainda funciona em sites que nem carregam o wp-admin.</p>
</details>

<details>
<summary>Por que limpar o malware antes da investigação costuma causar reinfecção?</summary>
<p>Porque a limpeza apaga a evidência do vetor de entrada sem fechá-lo. Se você remove o backdoor mas não descobre que ele entrou por uma CVE de plugin desatualizado, como a CVE-2023-48777 do Elementor (CVSS 9.9), a mesma brecha continua aberta. O atacante reinjeta em horas. A análise forense de site WordPress invadido inverte a ordem: primeiro confirma o vetor, depois limpa e só então endurece, eliminando a porta original.</p>
</details>

<details>
<summary>Qual a diferença entre risco atual e CVE histórica numa investigação?</summary>
<p>O risco atual é a vulnerabilidade sem patch na versão que você roda hoje; a CVE histórica já foi corrigida em alguma versão posterior. O All in One Security, por exemplo, soma 43 CVEs históricas, todas com patch e zero sem correção atualmente. Citar CVE antiga corrigida como ameaça atual é alarme falso. A forense precisa cruzar a versão instalada com a versão afetada para saber se a falha ainda expõe o site.</p>
</details>

<details>
<summary>Como identificar o exato momento da invasão nos logs do WordPress?</summary>
<p>Cruze o timestamp last_modified dos arquivos PHP adulterados com as linhas do log de acesso no mesmo minuto. Um arquivo alterado às 03h14 com um POST em xmlrpc.php do mesmo IP no mesmo instante marca o vetor. Filtre o log por método POST, por IP repetido e por user-agent incomum. Essa correlação de tempo é o que transforma suspeita em prova dentro de uma análise forense de site WordPress invadido.</p>
</details>

<details>
<summary>Com que frequência um site WordPress deve passar por auditoria preventiva?</summary>
<p>Faça uma varredura de integridade semanal e uma auditoria completa a cada trimestre, mais uma imediata após qualquer atualização crítica de plugin. Sites com WooCommerce ou alto tráfego pedem monitoramento contínuo. Segundo o WPScan (2025), 90% das falhas exploradas vêm de plugins, então o ritmo de auditoria deve acompanhar o ritmo de atualização desses componentes. Prevenção frequente custa minutos; uma forense pós-invasão custa horas.</p>
</details>

## Próximos passos após investigar a invasão

Concluir uma análise forense de site WordPress invadido com vetor confirmado, timeline documentada e ambiente limpo é só metade do trabalho: a outra metade é o endurecimento que impede a próxima invasão. Atualize todo plugin para a versão com patch, rotacione senhas e chaves, ative firewall e agende auditorias. Para aprofundar cada etapa de proteção, o <a href="https://full.services/guias/guia-de-seguranca-para-wordpress">guia de segurança para WordPress</a> reúne tutoriais, checklists e reviews em sequência, e o <a href="https://full.services/academy/">FULL Academy</a> organiza todo esse conhecimento em um só lugar. Investigar bem é o que separa quem reinfecta de quem fecha a brecha de vez.