Resumo executivo: Um cliente de healthcare nos EUA foi comprometido duas vezes em duas semanas mesmo com Wordfence Premium instalado e Sucuri tendo feito a remediação inicial. Quando o The
Media Trust sinalizou o site novamente, fizemos a investigação forense com o SysWP Shield. Identificamos o vetor exato — uma conta admin legítima abusada, não uma exploração de código — e três diferenças arquiteturais que fizeram o Shield detectar o que as outras ferramentas perderam.
O incidente
Dia 0: O The Media Trust (TMT), serviço que escaneia anúncios digitais por segurança, detecta um skimmer e cartão de crédito no site do cliente. Domínios C2 identificados: bernardi.lol. Sucuri é contratada, faz cleanup, declara o site limpo.
Dia 5: TMT sinaliza o site DE NOVO. Novos domínios C2: wowlowski.icu, loureiru.lol. Padrão idêntico. Reinfecção.
Pergunta crítica: Como o atacante voltou tão rápido? E por que o Wordfence Premium, que escaneia diariamente, não detectou nenhum dos dois ciclos de infecção?
A investigação
Conectamos o SysWP Shield ao site. Em 15 minutos, três detectores do Shield trouxeram dados que mudaram completamente a narrativa.
Detector 1 — Plugin Provenance Audit
A primeira coisa que o Shield faz quando se conecta a um site é listar TODOS os plugins instalados e verificar quais estão no wordpress.org e quais NÃO estão.
Plugins que não estão no wp.org não são necessariamente maliciosos podem ser plugins custom, ntegrações de marketplaces premium, ferramentas de vendor. Mas TODA instalação fora do wp.org merece revisão manual, porque é exatamente onde backdoors disfarçados se escondem.
Wordfence Premium não tem essa categoria como verificação sistemática. Os hash scanners comparam arquivos contra assinaturas conhecidas. Para um plugin custom sem assinatura, eles silenciosamente passam por cima.
No site do cliente, o Shield identificou um plugin chamado “wpconsole_v2” — ativo, com aparência de plugin de console de desenvolvedor, fora do wp.org. Inspeção do código revelou: auto-login admin, injeção de C2 em todas as páginas, auto-ressurreição via mu-plugin se desativado.
O backdoor.
Detector 2 — Threat Detection Suite
Com o backdoor identificado, a pergunta era: como ele foi instalado?
O Threat Detection Suite do Shield monitora três fluxos:
- File_Watcher — baseline SHA-256 de wp-content + alertas em arquivos NOVOS, MODIFICADOS, ou em locais sensíveis (uploads/, mu-plugins/)
- Content_Monitor — scoring de posts/comentários novos (palavras-chave de spam, links suspeitos, padrões SEO de pharma/casino)
- User_Monitor — registros de novos usuários, mudanças de função, escalações de privilégio
O User_Monitor mostrou: uma conta “Jason Woffod” foi promovida a admin há 11 dias. Ninguém na equipe do cliente sabia quem era Jason Woffod.
Cross-reference com o Activity Log do plugin Aryo (que o cliente já tinha instalado): a conta foi criada por um IP específico, 162.33.179.219, geolocalizado nos EUA. Mesma origem fez login 5 vezes nos dias 11, 12 e 13 antes de o skimmer aparecer.
O vetor de entrada: conta admin legítima criada via um endpoint de registro que ninguém auditou nem fechou.
Detector 3 — Activity Log na nossa SaaS
Aqui o Shield arquitetonicamente faz algo diferente: os logs de atividade do WordPress (logins, instalações de plugin, mudanças de função) são enviados em tempo real para a nossa SaaS, NÃO armazenados no site do cliente.
Por quê? Porque quando o atacante volta para limpar rastros — e voltam SEMPRE — eles limpam os logs primeiro. Wordfence, Sucuri, WP Activity Log: todos armazenam o audit trail no mesmo servidor WordPress. Comprometeu o servidor, apagou os logs.
No nosso modelo, mesmo que o atacante apague tudo no servidor, o trail está na nossa SaaS, com hash de cada evento, timestamp UTC, IP do ator, contexto.
Isso permitiu reconstruir a linha do tempo COMPLETA do comprometimento, incluindo dois logins do atacante DEPOIS que o Sucuri tinha declarado o site limpo. Foi assim que descobrimos que a “limpeza” estava incompleta — o atacante ainda tinha acesso à conta admin legítima.
O que o Wordfence Premium perdeu
Não é uma crítica direta. Wordfence é uma ferramenta sólida. Mas o modelo deles tem três gaps arquiteturais que ficaram visíveis nesse caso:
- Hash scanning é cego para plugins custom. Se não tem assinatura conhecida, não tem como flaggear. Plugin Provenance resolve isso virando o problema do lado: “este plugin NÃO está no wp.org — você sabe quem instalou?”
- Não rastreia mudanças de função de usuário como evento de segurança. Promover alguém a admin é um evento muito mais crítico do que detectar mais um bot. User_Monitor trata como tal.
- Audit log vive no site. Comprometeu o site, perdeu o log. Shield Activity Log vive na SaaS, sobrevive ao comprometimento.
O resultado
O site foi limpo manualmente com base no que o Shield identificou. A conta Jason Woffod foi contida (posts reatribuídos antes da eliminação). O IP 162.33.179.219 foi bloqueado em nível de rede para os 26 sites da nossa fleet. WordPress Hardening foi ativado (8 defesas always-on). Activity Log começou a enviar eventos para a SaaS em tempo real.
Status atual do site:
- Risk Score: 13/100 (Grade A — saudável)
- 1.492 ataques bloqueados nas últimas 24h
- 0 alertas críticos abertos
- Sentinel baseline estabelecido
- Plugin 0.32.1 (última versão, com Event Logger ativo)
A lição
Se você gerencia sites WordPress, o próximo comprometimento provavelmente NÃO vai vir pelo CVE do mês. Vai vir por:
- Uma conta admin esquecida — alguém que não trabalha mais lá, acesso de um vendor antigo, registro aberto sem auditoria.
- Um plugin que ninguém audit — uma instalação custom de 6 meses atrás, sem assinatura no wp.org, fazendo coisas que você não monitora.
- Audit logs no servidor comprometido — quando você precisar deles para investigar, o atacante já apagou.
Os hash scanners tradicionais não cobrem nenhum dos três. SysWP Shield foi desenhado especificamente para fechar essas lacunas.
Como começar
O plano Free do Shield já inclui:
- 16 sinais de detecção de bot
- Threat Detection Suite (File_Watcher, Content_Monitor, User_Monitor)
- Plugin Provenance audit
- Malware Sentinel
- WordPress Hardening 8 defesas
- 2FA self-enrollment
Activity Log enviado para a SaaS está disponível a partir do Starter ($9/mês). Plugin Provenance está livre em todos os planos — porque achamos que detectar backdoors disfarçados não deveria ser feature paga.
Para instalar: shield.syswp.pro
Caso real, junho 2026. Dados anonimizados por confidencialidade. Relatórios forenses completos disponíveis para clientes mediante solicitação.
