Administradores WordPress com sessão iniciada transformados em instaladores de backdoors

A maioria dos administradores WordPress mantém o wp-admin aberto num separador enquanto navega pelo resto da web. Uma cadeia de ataque analisada recentemente, seguida sob o nome TRUST#GRAFT, foi construída precisamente à volta desse hábito. Não adivinha, não rouba nem faz phishing da palavra-passe do administrador. Limita-se a esperar por um administrador que já tem sessão iniciada e usa a sessão de confiança desse browser para instalar um plugin malicioso no site. O resultado é um backdoor PHP persistente escondido numa pasta que a página normal de plugins nunca mostra.

O que aconteceu

A cadeia começa com um carregador JavaScript colocado numa página WordPress comprometida. Ainda não foi confirmado como esse primeiro script chega à página, pelo que o vetor de acesso inicial continua a ser uma questão em aberto e não um facto estabelecido.

Quando um visitante entra na página, o carregador cobre-a com um iframe em ecrã inteiro desenhado para parecer um ecrã de verificação ao estilo Cloudflare, com o clássico "Just a moment…". Enquanto o visitante espera, o script recolhe discretamente a impressão digital do browser: tamanho do ecrã, dados da placa gráfica, fuso horário e número de plugins instalados no browser. Procura também sinais de sandboxes e de ferramentas de análise automática. Os dados recolhidos seguem para um servidor de controlo, que decide se aquele visitante em concreto merece uma segunda fase.

Se o visitante for um administrador WordPress autenticado, chega o passo decisivo. Apoiado nos cookies de sessão que o browser já tem, o script pede a página de carregamento de plugins, lê aí o nonce de segurança, descarrega um ficheiro ZIP chamado wm.zip a partir de um servidor intermédio e submete-o através do endpoint normal de instalação de plugins. Depois abre a página de plugins e ativa o novo plugin. O WordPress aceita cada pedido porque, do seu ponto de vista, tudo está a ser feito por um administrador legítimo com permissão para instalar plugins.

Isto não é um contorno da autenticação. A conta já tem de ser de administrador, com permissão para instalar plugins. Mas é uma forma muito eficaz de virar essa confiança contra o próprio site.

O backdoor e como se esconde

O plugin carregado apresenta-se como Web Media Optimizer 2.1. O nome sugere uma ferramenta inofensiva para imagens. Não é nada disso. O plugin:

• injeta JavaScript remoto nas páginas públicas do site;
• desativa a validação de certificados TLS quando descarrega o seu script de controlo;
• consegue definir um cookie de sessão de administrador para a primeira conta admin através de um token fixo no código, dando aos operadores uma porta de regresso sem palavra-passe.

Ao ser ativado, copia-se também para wp-content/mu-plugins/wmedia-recovery.php. O WordPress carrega automaticamente todos os ficheiros da pasta mu-plugins, e esses ficheiros não aparecem na lista habitual de plugins. Apagar o plugin visível não afeta, portanto, a cópia que realmente interessa, e é por isso que esta classe de malware do tipo must-use plugin volta a aparecer depois de limpezas interrompidas demasiado cedo.

Porque é que importa

Malware que só se ativa dentro de uma sessão autenticada é difícil de apanhar com análises de rotina. Um scanner que visita o site público vê uma página que pode parecer limpa, enquanto o comportamento perigoso só dispara para um administrador com sessão iniciada. Quem usa um único perfil de browser tanto para a navegação do dia a dia como para gerir o site está exposto, porque o ataque não precisa de mais do que uma visita à página errada enquanto o wp-admin ainda está autenticado.

O que fazer

• Separe a navegação de administração. Use um perfil de browser dedicado, ou um browser diferente, para o wp-admin. Não navegue noutros sites a partir dele.
• Termine a sessão quando acabar, e logo após qualquer camada de "verificação" inesperada.
• Rode as credenciais de administrador e invalide as sessões ativas se suspeitar de exposição.
• Limite as permissões de carregamento de plugins. Poucas contas precisam de instalar plugins, e o WordPress permite desativar por completo a modificação de ficheiros em sites que implementam plugins por outros meios.
• Vigie a pasta mu-plugins. Crie alertas para qualquer ficheiro PHP novo em wp-content/mu-plugins/ e reveja essa pasta em cada limpeza.
• Limpe a fundo. Remova o plugin visível, a cópia em mu-plugins e qualquer tag de script remoto injetada. Deixar um só dos três chega para a reinfeção.

Indicadores a procurar

• Nome do plugin: Web Media Optimizer 2.1
• Ficheiro da segunda fase: wm.zip
• Ficheiro de persistência: wp-content/mu-plugins/wmedia-recovery.php
• Script de controlo: ads.php
• Domínios de comando e controlo (defanged): caapman[.]me, vtevens[.]icu, gerlace[.]com, nutmann[.]club, okuneva[.]sbs, vilialobos[.]lol
• SHA256 do wm.zip: 9215d17e5138cee498bb529e69b1cc7267305136535025e9b49fe173cf648720
• SHA256 do wmedia-recovery.php: 86d775c2d5cb459541cd2b0b967fac65ce20c60e483c71c9f7e108d5ad0bd564
• SHA256 do ads.php: 2dfa9e708fdb92e5d36080065f978a33a692c0fe813a75be9c7cdff03be51b6e

Os domínios estão propositadamente defanged. Reponha-os apenas dentro de uma plataforma controlada de threat intelligence ou do seu SIEM.

Ataques como este resultam porque os sinais são pequenos: uma tag de script inesperada numa página pública, um ficheiro a mais numa pasta que ninguém verifica, um plugin que ninguém se lembra de ter instalado. O nosso serviço de análise de vulnerabilidades foi desenhado para trazer à superfície precisamente esses pequenos sinais em instalações WordPress, desde cores e plugins desatualizados até scripts injetados inesperados, para que uma sessão de administrador emprestada não se transforme silenciosamente num ponto de apoio permanente.