Une campagne de malware sur WordPress cache ses charges malveillantes dans des profils Steam

Une campagne de malware WordPress cache ses charges utiles dans des profils Steam

Environ 2000 sites internet WordPress ont été infectés par un logiciel malveillant qui utilise les commentaires de profils de la communauté Steam pour dissimuler ses données de commande et de contrôle.

Le pirate a exploité des caractères Unicode invisibles pour encoder une charge utile qui construit une URL vers un script malveillant. Cette méthode permet à l’attaquant de ne pas avoir à gérer sa propre infrastructure de commande et d’échapper aux méthodes de détection classiques.

Depuis sa découverte en juillet 2025, les ingénieurs en sécurité de GoDaddy ont identifié ce malware sur près de 1980 sites WordPress.

La méthode d’intrusion initiale reste incertaine. Les chercheurs évoquent plusieurs possibilités : le vol d’identifiants d’administration, la compromission d’accès FTP ou SFTP, l’exploitation d’une faille dans un thème ou un plugin WordPress, ou encore une compromission de la chaîne d’approvisionnement.

Le malware de premier stade, une fois installé sur un site, profite du chargement des pages WordPress pour accéder à des profils Steam spécifiques. Il extrait alors du texte à partir de commentaires qui semblent inoffensifs.

Ce texte contient en réalité des caractères Unicode invisibles qui cachent des charges malveillantes, parfois déguisées en art ASCII.

Commentaire Steam malveillant

Commentaire Steam malveillant
Source : GoDaddy

Les chercheurs de GoDaddy précisent que le pirate utilise six caractères Unicode invisibles pour encoder la charge utile :

  • Le caractère de non-jointure de largeur nulle (U+200C)
  • Le caractère de jointure de largeur nulle (U+200D)
  • L’application de fonction (U+2061)
  • Le signe de multiplication invisible (U+2062)
  • Le séparateur invisible (U+2063)
  • Le signe plus invisible (U+2064)

Le décodeur ignore les caractères visibles et associe chaque caractère invisible à un nombre. Ces nombres sont convertis en représentation binaire, ce qui permet de reconstruire les octets du flux de données.

« Ce codage permet d’intégrer des données binaires dans un texte qui semble normal. Les caractères visibles servent de camouflage, tandis que les caractères invisibles transportent la charge utile réelle », indique GoDaddy.

Selon les chercheurs, la charge utile décodée sert à construire une URL du domaine hello-mywordl[.]info. Cette URL distribue un code JavaScript qui est ensuite injecté dans toutes les pages publiques du site WordPress.

Le malware récupéré se fait passer pour une bibliothèque JavaScript légitime, comme le suggèrent ses noms de fichiers, par exemple « asahi-jquery-min-bundle » ou « lodash.core.min.js ».

La phase finale de l’attaque consiste à installer une porte dérobée. Cette dernière répond à des requêtes POST spécialement formulées qui contiennent un cookie d’authentification spécifique. Si le cookie « tEcaKKXEsb » est présent, la porte dérobée accepte et exécute du code PHP encodé en base64 qui est transmis via un paramètre POST.

Requête POST avec le cookie d'authentification

Requête POST avec le cookie d’authentification
Source : GoDaddy

GoDaddy décrit plusieurs mécanismes d’évasion employés par ce malware. Parmi eux figurent l’obfuscation des chaînes de caractères avec des séquences d’échappement octales et hexadécimales, des noms de fonctions aléatoires, du faux code de journalisation désactivé, et l’utilisation des API WordPress standards pour se fondre dans l’activité normale du site.

Les propriétaires de sites peuvent se protéger en vérifiant la présence de références à des URL de la communauté Steam, d’injections externes de JavaScript suspectes, de connexions sortantes de leurs serveurs WordPress vers Steam, ou de scripts chargés depuis des domaines comme hello-mywordl[.]info.

D’autres signes d’infection incluent la présence de caractères Unicode invisibles, des entrées de cache _transient_caption_ suspectes, la désactivation de la vérification SSL dans les requêtes cURL, et des requêtes POST qui contiennent les cookies d’authentification du malware ou un paramètre nommé « new_code ».

Les chercheurs recommandent aux équipes de sécurité de restaurer leur site à partir d’une sauvegarde saine datant d’avant l’infection. Si cette option n’est pas possible, le nettoyage manuel doit être extrêmement minutieux, car « les attaquants peuvent réinstaller le code supprimé via la porte dérobée si une seule de ses composantes reste active. »