Um Backdoor no WordPress recém-analisado pela Sucuri mostra como ameaças contra sites podem ultrapassar completamente o modelo tradicional de um arquivo PHP malicioso escondido no servidor. Batizado de SC, o malware foi observado retornando segundos depois de ser removido, graças a uma arquitetura distribuída que mantém cópias do código em arquivos, banco de dados e memória compartilhada.
O caso chama atenção porque a infecção não depende de um único ponto de persistência. A Sucuri identificou pelo menos oito componentes capazes de participar da reconstrução da ameaça, formando uma espécie de malha circular. Se um elemento é apagado, outro pode recriá-lo, tornando uma limpeza baseada apenas na exclusão de arquivos insuficiente.
Mais incomum ainda é o mecanismo utilizado para comando e controle (C2). Em vez de depender de um servidor malicioso fixo, o SC consulta contratos na blockchain Ethereum por meio de gateways RPC públicos. Essa estratégia dificulta o bloqueio tradicional baseado em endereços IP e servidores conhecidos.
Como funciona a malha autorreparável do backdoor no WordPress
O principal diferencial do Backdoor no WordPress SC é sua redundância. A Sucuri encontrou componentes espalhados por diferentes camadas do ambiente, permitindo que o malware continue funcionando mesmo após uma intervenção parcial.
Um dos pontos iniciais é o arquivo .user.ini, que utiliza a diretiva auto_prepend_file para fazer o PHP carregar outro arquivo antes do processamento normal das requisições. Isso é particularmente relevante porque o mecanismo pode ser executado antes mesmo de o fluxo normal do WordPress começar.
O arquivo indicado pelo auto_prepend_file funciona como um shim, responsável por carregar outro componente oculto. A partir daí, a cadeia pode alcançar um loader que reconstrói o restante da infecção.
Outro ponto crítico são os drop-ins do WordPress, especialmente wp-content/db.php e wp-content/advanced-cache.php. Esses arquivos possuem posições privilegiadas no processo de inicialização do CMS e podem ser carregados muito cedo durante o bootstrap.
No caso analisado pela Sucuri, o db.php armazenava o payload em um bloco gzip codificado em Base64, permitindo reconstruir o malware caso sua cópia principal desaparecesse. Já o advanced-cache.php podia procurar o código em várias fontes diferentes, incluindo plugins, arquivos ZIP, memória compartilhada e banco de dados.
O papel dos plugins obrigatórios e dos temas
A persistência também se espalhava para mu-plugins, categoria de extensões que o WordPress carrega automaticamente e que não pode ser desativada pela interface administrativa convencional.
Entre os componentes identificados estava o arquivo hyper-engine-kit.php, presente tanto em mu-plugins quanto no diretório convencional de plugins. As duas cópias tinham função de redundância, permitindo que uma reconstruísse a outra.
O malware também modificava o functions.php do tema ativo, acrescentando um bloco capaz de restaurar componentes da infecção. Dessa forma, mesmo uma limpeza incompleta do diretório wp-content poderia ser revertida durante uma nova requisição.
Essa arquitetura transforma o malware em algo mais próximo de uma rede de persistência distribuída do que de um simples arquivo malicioso.
A persistência na memória compartilhada
Um dos aspectos mais preocupantes é a utilização de memória compartilhada System V.
A Sucuri encontrou cópias do payload armazenadas em segmentos de memória compartilhada. Isso significa que o código malicioso pode continuar disponível mesmo depois da remoção dos arquivos e da limpeza de determinadas informações no banco de dados.
Para administradores Linux, esse detalhe muda significativamente a investigação. Uma análise limitada ao sistema de arquivos pode indicar que o servidor está limpo quando ainda existem mecanismos capazes de reconstruir a infecção.
A ameaça também utiliza tarefas Cron, incluindo identificadores aleatórios e hooks específicos, para participar do processo de redeployment. Em variantes relacionadas, a Sucuri também observou mecanismos no próprio banco de dados capazes de recriar contas administrativas.
Como o backdoor no WordPress usa a blockchain Ethereum
A comunicação com o operador representa outra característica incomum do SC.
Em vez de apontar diretamente para um domínio ou endereço IP controlado pelo atacante, o malware contém uma lista de aproximadamente 20 gateways RPC públicos da Ethereum e utiliza seletores de métodos de contratos inteligentes para consultar instruções armazenadas na blockchain.
A ideia é explorar uma infraestrutura pública e legítima como camada intermediária. Bloquear um único servidor C2 deixa de ser suficiente porque o malware pode recorrer a outros gateways.
O servidor comprometido também pode coletar informações como URL do site, hostname, versões do WordPress e plugins, temas ativos e componentes instalados. Segundo a Sucuri, esses dados são agrupados e enviados ao endpoint obtido por meio do mecanismo de comando.
O retorno pode conter código PHP adicional, JavaScript para injeção no front-end e instruções para desativar ou remover mecanismos de segurança.
Administradores ocultos e skimmers
O impacto não termina na persistência.
O SC possui mecanismos para criar ou assumir uma conta administrativa oculta, inclusive manipulando diretamente as tabelas users e usermeta quando necessário. Filtros do WordPress podem esconder essa conta das telas administrativas, contagens de usuários e visualizações de funções.
O malware também pode forjar cookies de autenticação e manter acesso administrativo mesmo depois de alterações convencionais nas credenciais.
Em sites de comércio eletrônico, outro risco é a capacidade de inserir JavaScript malicioso no front-end, abrindo espaço para ataques como skimming de pagamentos. Isso transforma uma infecção inicialmente voltada à persistência em um potencial incidente de roubo de dados financeiros.
Exploração do wpForo Forum e o que o CVE-2026-1581 significa
A descoberta do SC ocorre em um cenário de novas vulnerabilidades envolvendo plugins WordPress. Um caso relevante é o CVE-2026-1581, relacionado ao wpForo Forum.
Há uma correção importante de contexto: o registro do CVE descreve uma injeção SQL baseada em tempo e sem autenticação, presente até a versão 2.4.14 do plugin. A vulnerabilidade está associada ao parâmetro wpfob e recebeu CVSS 3.1 de 7,5, classificação High. A versão corrigida indicada pelas fontes de segurança é a 2.4.15.
Portanto, o CVE-2026-1581 não deve ser apresentado como uma vulnerabilidade especificamente atribuída pela Sucuri como porta de entrada do SC. O relatório da Sucuri sobre o SC não estabelece essa relação. O que existe é uma coincidência relevante no ecossistema WordPress: uma vulnerabilidade de plugin pode proporcionar uma superfície de ataque enquanto malwares cada vez mais persistentes exploram ambientes comprometidos.
Também é importante observar que o registro disponível não indica o CVE-2026-1581 como integrante do catálogo CISA Known Exploited Vulnerabilities. O material de enriquecimento associado ao CVE registrava exploração como “none” naquele momento.
Para administradores que utilizam o wpForo, a medida básica é atualizar o plugin para uma versão corrigida, além de investigar sinais de comprometimento caso o ambiente tenha permanecido exposto.
Como auditar um ambiente Linux e WordPress comprometido
Diante de uma possível infecção, simplesmente apagar arquivos suspeitos pode ser insuficiente.
O primeiro passo é interromper a execução do código comprometido e preservar evidências para investigação. Depois, a auditoria deve abranger diferentes camadas do ambiente.
Entre os pontos prioritários estão:
.user.ini,php.inie.htaccess, procurando referências inesperadas aauto_prepend_file;wp-content/db.phpeadvanced-cache.php, verificando alterações que não pertencem ao ambiente legítimo;- diretórios
mu-pluginseplugins, especialmente arquivos desconhecidos ou duplicados; functions.phpdos temas ativos;- opções e transientes suspeitos no banco de dados;
- contas administrativas desconhecidas ou ocultas;
- tarefas Cron do WordPress e do sistema operacional;
- triggers do banco de dados, especialmente aqueles que alteram contas ou dados automaticamente;
- segmentos de memória compartilhada System V;
- conexões de saída do servidor para gateways Ethereum RPC.
A Sucuri recomenda uma abordagem que trate arquivos, banco de dados e memória como partes do mesmo incidente. A ordem da limpeza também importa, pois apagar primeiro um componente que está sendo monitorado por outro pode simplesmente provocar sua recriação.
Depois da remoção, é fundamental alterar credenciais, revisar contas privilegiadas, atualizar WordPress, plugins e temas e monitorar novamente os arquivos e processos do servidor.
O futuro da segurança em CMS frente aos malwares circulares
O caso SC mostra uma mudança importante na forma como um Backdoor no WordPress pode manter acesso a um ambiente comprometido. O malware analisado não depende de uma única webshell ou de um arquivo PHP escondido. Ele combina arquivos, drop-ins, plugins, tema, banco de dados, memória compartilhada e tarefas agendadas em uma estrutura capaz de se reconstruir.
Para administradores Linux e profissionais de segurança, isso significa que uma limpeza considerada “bem-sucedida” apenas porque os arquivos suspeitos desapareceram pode fornecer uma falsa sensação de segurança.
A investigação precisa considerar o servidor como um todo, incluindo processos, memória, banco de dados, tarefas agendadas, contas, conexões de rede e mecanismos de inicialização do PHP e do WordPress.
A principal lição do SC é justamente essa: persistência moderna não precisa estar concentrada em um único lugar.
Se você administra servidores Linux ou sites WordPress, vale compartilhar nos comentários como sua equipe realiza a auditoria de processos, memória compartilhada e tarefas Cron depois de uma infecção. Esses procedimentos podem ajudar outros administradores a identificar mecanismos de persistência que uma simples varredura de arquivos não encontra.
