Fazer auditoria de logs no WordPress é cruzar log de acesso, de erro e de atividade para reconstruir quem fez o quê. Segundo o NVD/NIST (2024), a CVE-2016-10887 com CVSS 9.8 permitia bypass de autenticação. A retenção curta apaga a evidência. Leia os logs antes de limpar o site.

Auditar logs no WordPress é o ato de ler os registros que o servidor e a aplicação gravam para identificar acessos, erros e alterações suspeitas. Sem essa leitura, uma invasão vira mistério: você vê o site desfigurado, mas não sabe por onde entraram nem o que tocaram. A auditoria responde a três perguntas (quem entrou, quando e o que mudou) usando log de acesso do servidor, log de erro do PHP e log de atividade do painel. Este guia mostra como ler cada um, quais ferramentas usar e os cinco sinais que separam um pico de tráfego de um ataque real. Comece pelo nosso guias de segurança WordPress da FULL se quiser o contexto completo.

Primeiros passos: Os 3 tipos de logs no WordPress

Toda auditoria precisa cruzar 3 camadas de logs, e elas vivem em lugares diferentes do servidor. O log de acesso registra cada requisição HTTP; o log de erro do PHP guarda falhas de execução; o log de atividade registra ações no painel. Cruzar os três transforma dado solto em uma linha do tempo da invasão.

O log de acesso (access.log do Apache ou Nginx) traz IP, horário e URL de cada requisição. O log de erro mostra tentativas de exploração que quebram scripts. O log de atividade, gerado por plugins como o WP Activity Log, fica dentro do banco e registra logins, edição de posts e troca de tema.

Sem os três, a auditoria fica cega para metade dos vetores. Quem só olha o painel perde o ataque de força bruta; quem só olha o servidor perde o usuário admin criado por dentro.

Por que os logs somem antes da auditoria de segurança

A maior falha de auditoria não é ler os logs errado, é não ter mais o que ler. Em hospedagem compartilhada, a rotação de log padrão guarda de 1 a 7 dias, e uma invasão de madrugada de domingo já sumiu na segunda de manhã. Nos tickets de segurança que chegam ao suporte da FULL, o relato mais frequente é o site hackeado sem nada nos logs: quase sempre é retenção curta.

A regra prática é separar dois ambientes: o log de servidor, que a hospedagem controla e rotaciona rápido, e o log de atividade da aplicação, que você configura para reter 90 dias. Exportar o access.log para fora do servidor preserva a cadeia de custódia mesmo se o atacante apagar o original. Sem retenção, a evidência da vulnerabilidade explorada desaparece antes da perícia.

Como fazer a auditoria de logs em 4 passos

Auditar logs do WordPress de forma estruturada leva cerca de 30 minutos por site e segue quatro passos em ordem fixa: coletar, correlacionar por IP, validar contra o log de atividade e isolar a janela do incidente. A maioria dos administradores pula a correlação e olha cada log isolado, o que esconde 70% dos ataques que cruzam servidor e aplicação. Os passos abaixo mantêm a sequência que usamos no suporte da FULL para reconstruir uma invasão a partir do zero.

Legenda: a correlação por IP entre o access.log do servidor e o log de atividade do painel é o que revela o ataque completo.

Passo 1: Colete os três logs no mesmo intervalo

Baixe o access.log e o error_log via SFTP e exporte o log de atividade do WP Activity Log em CSV, sempre recortando a mesma janela de tempo (por exemplo, as 48 horas em torno do incidente). Trabalhar com intervalos diferentes em cada arquivo gera correlações falsas. Guarde uma cópia íntegra antes de filtrar.

Passo 2: Correlacione os eventos por endereço IP

Pegue os IPs com mais requisições no access.log e cruze com os logins do log de atividade. Um IP estrangeiro com 400 requisições em wp-login.php e um login bem-sucedido logo depois é o desenho clássico de força bruta vencida. Ferramentas como Fail2ban automatizam essa contagem por IP.

Passo 3: Valide as ações no log de atividade

Confirme no WP Activity Log toda ação sensível da janela: criação de usuário com papel administrador, edição de arquivo de tema e mudança de URL do site. Esses três eventos quase nunca são legítimos fora de uma manutenção planejada e marcam o momento em que o atacante assumiu o controle.

Passo 4: Isole a janela do incidente

Com IP e ação confirmados, recorte a linha do tempo do primeiro acesso suspeito até a última ação maliciosa. Essa janela define o que restaurar do backup e qual malware procurar. Documente tudo antes de limpar o site.

Cves reais: O que os logs revelam de uma exploração

Logs registram a assinatura de explorações de vulnerabilidades conhecidas, não só força bruta. A CVE-2016-10887 no All in One Security, com CVSS 9.8 no NVD/NIST, permitia bypass de autenticação em versões abaixo da 4.0.9 e aparecia no log de acesso como requisição direta a endpoint administrativo sem login prévio.

Já a CVE-2015-9310, também CVSS 9.8 e corrigida na versão 3.9.1, deixava rastro de upload não autorizado no error_log. Vale a distinção honesta: as duas já foram corrigidas, então um plugin com muitos CVEs todos com patch é sinal de manutenção ativa, não de risco atual.

Segundo o perfil público do WPVulnerability, o All in One Security acumula 43 CVEs históricos, todos com correção. A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais. Quem audita log de exploração aqui literalmente cataloga a vulnerabilidade do outro lado.

5 sinais de invasão escondidos nos logs

Cinco padrões nos logs separam um pico de tráfego de uma invasão, e todos aparecem antes do site dar sinal visível. Em ordem de gravidade: rajada de POSTs em wp-login.php de um único IP, sequência de 404 em wp-admin seguida de um 200, criação de usuário admin fora do horário comercial, edição de arquivo de tema via painel e arquivos PHP inexistentes em /uploads/.

Wordfence com log de atividade ativo dispara alerta no primeiro sinal, antes do firewall bloquear. O segundo sinal é o mais perigoso: vários 404 sequenciais em wp-admin terminando em um 200 indica enumeração de usuário seguida de acesso bem-sucedido. Para tentativas repetidas de login, nosso guia de como lidar com falhas de login no WordPress detalha o bloqueio. Se confirmar dois ou mais sinais, trate como incidente.

Ferramentas para centralizar e ler os logs

Quatro ferramentas cobrem a leitura de logs no WordPress, cada uma em uma camada diferente. O WP Activity Log é o registro de atividade mais profundo do painel, com mais de 60 tipos de evento e exportação em CSV. O Wordfence correlaciona log de tráfego com firewall e mostra o IP do atacante em tempo real, antes do bloqueio.

O All in One Security oferece log de login e bloqueio por país no plano gratuito. Fora do WordPress, o Fail2ban lê o access.log e bane IPs por padrão de requisição, e o Sucuri verifica o site de fora, útil quando o atacante já apagou os logs locais.

• Se você precisa só do log de atividade do painel → instale o WP Activity Log com retenção de 90 dias.
• Se quer correlacionar tráfego com firewall → use Wordfence, que mostra o IP em tempo real.
• Se o ataque vem por força bruta no servidor → ative o Fail2ban no access.log e bane por padrão.
• Se o site já foi comprometido e os logs locais somem → adote monitoramento externo com Sucuri.

Quando a segurança gerenciada resolve a auditoria por você

Manter retenção, correlação e atualização de plugin em cada site manualmente não escala além de um punhado de instalações. É aqui que entra a segurança gerenciada: o plano PRO da FULL (R$849,90/ano) inclui o bundle de plugins de segurança com registro de atividade já configurado, e ao dividir por 10 sites o custo cai para cerca de R$85 por site ao ano.

A gente vê no suporte da FULL que a maioria das invasões acontece em sites com plugin desatualizado e log sem retenção, exatamente o que a gestão centralizada elimina. Não é hospedagem: a FULL é complementar ao seu host e cuida da camada de segurança e atualização. Conheça os planos da FULL para entender o que entra no bundle.

Para um diagnóstico imediato, escaneie seu site no FULL Scan e descubra se algum plugin está vulnerável, ou consulte o repositório de vulnerabilidades atualizado com dados oficiais de CVEs.

Perguntas frequentes sobre auditoria de logs no WordPress

Próximos passos para blindar seu WordPress com logs

Auditar logs deixa de ser perícia pós-desastre quando vira rotina: retenção de 90 dias no log de atividade, correlação por IP a cada alerta e atualização imediata de plugin com CVE conhecido. Os cinco sinais deste guia funcionam como uma checklist rápida sempre que algo parecer estranho no site. Se o WordPress já mostrou sinal de comprometimento, siga para o passo a passo de como limpar e recuperar um site hackeado e depois reforce a base com a auditoria completa de segurança. Para continuar aprendendo, o FULL Academy reúne os guias de segurança WordPress em um só lugar. A leitura de logs é a diferença entre saber o que aconteceu e adivinhar.