# Auditoria de logs no WordPress: Os 5 sinais de invasão 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.
Tipos de logs no WordPress: origem, conteúdo e uso na auditoria
Tipo de log Onde fica O que revela na auditoria
Log de acessoaccess.log do Apache/Nginx no servidorIP, horário e URL de cada requisição; mostra força bruta e enumeração
Log de erro PHPerror_log na raiz ou em /wp-content/Falhas de execução e tentativas de exploração de plugin vulnerável
Log de atividadeBanco de dados, via WP Activity LogLogins, criação de usuário admin e edição de arquivos no painel
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 , 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. ## 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

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

Os logs somem por rotação curta de retenção, não por ausência de registro. Em hospedagem compartilhada, o access.log do servidor guarda de 1 a 7 dias e rotaciona automático, então uma invasão de madrugada já foi apagada na manhã seguinte. A correção é separar o log de atividade da aplicação, configurado para reter 90 dias no WP Activity Log, do log de servidor que a hospedagem controla.

É possível auditar logs do WordPress sem instalar nenhum plugin?

Sim, é possível auditar parte dos logs sem plugin, lendo o access.log e o error_log direto no servidor via SFTP. Essas duas camadas mostram requisições HTTP e falhas de PHP sem nada instalado no WordPress. O limite é o log de atividade do painel: criação de usuário admin e edição de tema só ficam registrados com um plugin como o WP Activity Log, porque o núcleo do WordPress não grava essas ações por padrão.

Qual a diferença entre log de acesso, log de erro e log de atividade?

O log de acesso registra cada requisição HTTP com IP e horário no servidor; o log de erro guarda falhas de PHP e tentativas de exploração no error_log; o log de atividade registra ações dentro do painel, como login e edição de post, via WP Activity Log. Os três vivem em lugares diferentes e a auditoria só fica completa quando você cruza os três pela mesma janela de tempo e pelo mesmo IP.

Quanto tempo de retenção de logs é recomendado para um site WordPress?

A retenção recomendada é de 90 dias para o log de atividade da aplicação, prazo que cobre a maioria dos incidentes descobertos com atraso. O log de servidor costuma rotacionar em 1 a 7 dias na hospedagem compartilhada, por isso convém exportar o access.log para fora do servidor. No bundle de segurança do plano PRO da FULL, a R$85 por site, o registro de atividade já vem com retenção configurada.

O que procurar nos logs para identificar uma invasão no WordPress?

Procure cinco sinais: rajada de POSTs em wp-login.php de um IP único, sequência de 404 em wp-admin terminando em 200, criação de usuário admin fora do horário comercial, edição de arquivo de tema pelo painel e requisições a arquivos PHP em /uploads/. Dois ou mais sinais juntos indicam força bruta ou webshell e devem ser tratados como incidente confirmado.

--- ## 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.