Malware em 1.980 sites WordPress usa Steam Community como C2 com esteganografia em Unicode

Pesquisadores da GoDaddy descobriram uma campanha de malware com aproximadamente 1.980 sites WordPress comprometidos que utiliza a plataforma Steam, da Valve, como infraestrutura de comando e controle. Os atacantes escondem payloads em comentários de perfis públicos do Steam Community, codificados com caracteres Unicode invisíveis intercalados entre texto ASCII art aparentemente inofensivo, e instalam um backdoor PHP autorreparável capaz de sobreviver a limpezas parciais.

O que aconteceu

A equipe de pesquisa de segurança da GoDaddy identificou que cerca de 1.980 sites WordPress estavam comprometidos por um malware que recupera suas instruções de comando e controle lendo comentários em perfis públicos da Steam Community. À primeira vista, esses comentários parecem apenas ASCII art — internamente, no entanto, carregam instruções codificadas que dizem aos sites infectados de onde baixar o JavaScript malicioso final.

O esquema é uma demonstração engenhosa de abuso de plataformas legítimas para evasão de filtros de rede corporativos. Conexões de saída para steamcommunity.com raramente despertam suspeita em ambientes corporativos, e bloquear o domínio inteiramente é inviável em ambientes com usuários de games ou desenvolvedores ligados ao ecossistema Steamworks.

O abuso de plataformas confiáveis como infraestrutura de C2 não é novo — já vimos o uso de Pastebin, Telegram, GitHub Gists, Slack e DNS-over-HTTPS — mas o uso do Steam Community, combinado com a esteganografia baseada em caracteres Unicode invisíveis, representa um nível incomum de criatividade técnica para o ecossistema de malware focado em WordPress.

Como o ataque funciona

A codificação utiliza seis caracteres Unicode sem representação visual: zero-width non-joiner (U+200C), zero-width joiner (U+200D) e os “function application”, “invisible times”, “invisible separator” e “invisible plus” (U+2061 a U+2064). O malware remove os caracteres visíveis do comentário do Steam, mapeia cada caractere invisível para um número entre 0 e 5, converte para binário, reconstrói bytes a partir desse fluxo e aplica uma operação bitwise NOT em cada byte resultante.

Em algumas variantes, o payload decodificado é protegido com camadas adicionais de criptografia AES-256-CTR, derivação de chave via PBKDF2 com 10.000 iterações e autenticação HMAC-SHA256. Após a decodificação, o payload constrói uma URL apontando para hello-mywordl[.]info, que serve um arquivo JavaScript nomeado lodash.core.min.js — escolha deliberada para mimetizar a biblioteca legítima Lodash.

O script malicioso é carregado em todas as páginas frontend do WordPress por meio do hook wp_enqueue_scripts, usando o handle asahi-jquery-min-bundle — outro nome escolhido para se confundir com infraestrutura padrão de bibliotecas JavaScript. Qualquer revisão superficial de scripts enfileirados passaria batido por ele.

“Essa codificação permite que dados binários sejam embutidos dentro de texto de aparência normal. Os caracteres visíveis servem de camuflagem enquanto os invisíveis carregam o payload real”, afirmou a equipe de segurança da GoDaddy em seu relatório técnico.

O componente mais perigoso: o backdoor PHP autorreparável

O componente server-side é significativamente mais grave do que a injeção de JavaScript. O backdoor PHP fica em escuta em cada carregamento de página do WordPress e verifica dois cookies específicos em requisições POST: o cookie DEpjndDbNc dispara uma resposta de “ping” informando ao atacante que o backdoor está ativo e retorna um identificador de versão. Já o cookie tEcaKKXEsb aceita código PHP em base64 via parâmetro POST.

Mais grave: a função de modificação de arquivo varre recursivamente diretórios de plugins e temas em busca de uma string-marcador, sobrescrevendo as linhas correspondentes com novo código. Em outras palavras, mesmo que um administrador remova manualmente a injeção JavaScript, o atacante pode simplesmente reescrever o código a qualquer momento — limpezas parciais são essencialmente inúteis.

Quem é afetado e riscos

• Aproximadamente 1.980 sites WordPress já confirmados como comprometidos por esta variante específica.
• Administradores que executaram limpezas parciais — a infecção pode retornar via reescrita automática.
• Visitantes desses sites, expostos a injeção de JavaScript de origem externa hospedada em hello-mywordl[.]info.
• Equipes de SOC com regras de detecção baseadas em strings literais — toda string sensível usa escape octal/hexadecimal para escapar de buscas por texto.
• Operadores de hospedagem que não monitoram conexões de saída atípicas a partir dos servidores web.

Análise

Essa campanha exemplifica a evolução do “abuso de infraestrutura legítima” como pilar de ataques modernos. Bloquear domínios como steamcommunity.com é, na prática, inviável, e a comunicação de C2 mistura-se ao tráfego de uma plataforma com milhões de usuários ativos por dia. O resultado é um canal de instruções resistente à inspeção, sem necessidade de manter um C2 próprio que possa ser derrubado por autoridades ou sinkholed.

A esteganografia via caracteres Unicode invisíveis é particularmente preocupante porque é completamente invisível para inspeções visuais, escapa de buscas textuais comuns e atravessa intactamente a maioria das ferramentas de monitoramento de conteúdo. Esse não é o primeiro caso documentado — vimos uso similar em campanhas anteriores envolvendo prompt injection em modelos de IA — mas é um dos primeiros vetores em escala dentro do ecossistema WordPress.

Existe ainda um ponto técnico digno de nota: a arquitetura do backdoor, com sua capacidade de autorrestauração via reescrita de arquivos em plugins e temas, lembra o comportamento dos ataques de cadeia de suprimentos que abordamos em campanhas recentes contra repositórios como GitHub, LiteLLM e mais recentemente o pipeline da Red Hat. A tendência clara é que atacantes estejam projetando malwares para resistir à remediação parcial, contando com administradores apressados ou sem ferramentas adequadas.

Recomendações práticas

• Restaurar a partir de backup limpo anterior à data de infecção sempre que possível — limpezas manuais parciais são insuficientes.
• Buscar nos arquivos PHP de plugins e temas por arrays contendo U+200C, U+200D ou U+2061 a U+2064 e por chamadas a hash_pbkdf2 e openssl_decrypt com modo AES-256-CTR.
• Monitorar requisições POST contendo os cookies DEpjndDbNc ou tEcaKKXEsb, ou o parâmetro POST new_code.
• Bloquear ou alertar sobre conexões de saída de servidores WordPress para domínios da Steam Community — esse tráfego não tem justificativa em servidores web.
• Bloquear o domínio hello-mywordl[.]info e variações em firewalls e DNS corporativos.
• Verificar scripts enfileirados via wp_enqueue_scripts — desconfiar de handles como asahi-jquery-min-bundle e nomes de arquivo como lodash.core.min.js que não correspondem a plugins instalados.
• Atualizar WordPress core, todos os plugins e temas para versões atuais; revogar e regerar credenciais de administrador, chaves de FTP/SFTP e tokens de API.
• Implantar Web Application Firewalls (WAFs) com regras específicas para detecção de execução de PHP via parâmetros POST em endpoints normalmente estáticos.

Fonte: Security Affairs