Unit 42 Incident Response
Avant-propos
En mars 2025, nous avons découvert une campagne d’empoisonnement des résultats de recherche (SEO poisoning). Sur la base de l’infrastructure et des artefacts linguistiques identifiés, nous estimons – avec un haut niveau de confiance – qu’un acteur de la menace sinophone en est à l’origine. Nous avons baptisé cette opération « Rewrite », en référence à la traduction anglaise de l’un des objets présents dans le code.
Nous suivons ce cluster d’activité sous l’identifiant CL-UNK-1037. Notre analyse a révélé des recoupements au niveau de l’infrastructure et de l’architecture avec le cluster de menace suivi publiquement sous le nom de « Group 9 », ainsi qu’avec la campagne « DragonRank ».
Dans le cadre d’une attaque d’empoisonnement SEO, les cyber attaquants manipulent les résultats des moteurs de recherche afin d’inciter les internautes à visiter des sites inattendus ou indésirables (sites de jeux d’argent, contenu pornographique), dans un objectif financier. Un module Internet Information Service (IIS) malveillant, baptisé BadIIS, a été implanté pour intercepter et altérer le trafic web en exploitant des serveurs légitimes – mais compromis – pour diffuser du contenu malveillant. Le serveur web compromis agit alors comme un proxy « reverse » – un serveur intermédiaire qui récupère du contenu auprès d’autres serveurs et le présente comme s’il était le sien.
L’analyse de la configuration du malware révèle un ciblage clair de l’Asie de l’Est et du Sud-Est, ce qui est d’autant plus évident dans le code du module, qui intègre une logique spécifique pour des moteurs de recherche régionaux.
Les attaquants à l’origine de cette campagne utilisent un arsenal qui dépasse le module BadIIS. Nous avons identifié des variantes non documentées, incluant des gestionnaires de pages ASP.NET allégés, des modules IIS managés en .NET et un script PHP tout-en-un.
Les clients de Palo Alto Networks sont mieux protégés contre les menaces mentionnées ci-dessus grâce aux produits et services suivants :
Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse à incident.
| Unit 42 – Thématiques connexes | Empoisonnement SEO, Web Shells |
Malware BadIIS – Le contexte
Profilé pour la première fois en 2021, BadIIS désigne un ensemble de modules IIS natifs mais malveillants. Ces modules s’intègrent directement dans le pipeline de requêtes du serveur web et héritent de l’ensemble de ses privilèges. En raison de cette position privilégiée au sein du serveur, un seul implant peut exécuter une large variété d’actions, parmi lesquelles :
- injection de JavaScript ou d’iframes
- utilisation d’un proxy « reverse » intégré pour faire transiter le trafic
- redirections 302 afin de tromper les robots d’indexation des moteurs de recherche
- vol d’informations sensibles
Les chercheurs d’ESET ont été les premiers à désigner ces modules sous le nom BadIIS et à en dresser une cartographie.
Le rôle de l’empoisonnement SEO
Les attaquants utilisent le malware BadIIS pour manipuler de manière malveillante les résultats des moteurs de recherche et orienter le trafic vers la destination de leur choix. Cette technique a un nom : l’empoisonnement SEO. Plutôt que de bâtir la réputation d’un nouveau site – un processus fastidieux et chronophage – les attaquants compromettent des sites légitimes et déjà établis dont le domaine jouit d’une bonne réputation.
Pour empoisonner les résultats, les attaquants injectent sur le site compromis des mots-clés et des expressions fréquemment recherchés sur Internet. Cette manipulation altère le référencement du site, qui apparaît désormais pour un plus large éventail de requêtes populaires. En conséquence, le classement du site s’améliore sur ces termes courants, attirant davantage de trafic vers la page désormais « empoisonnée ».
Vue d’ensemble du flux d’attaque
Dans les sections suivantes, nous décrivons la manière dont BadIIS exploite l’empoisonnement SEO. Cette campagne comprend deux grandes phases : inciter les moteurs de recherche à indexer les pages compromises, puis piéger les visiteurs redirigés.
Phase 1 : Phase 1 – Le leurre empoisonné
L’objectif de l’attaquant consiste à amener un moteur de recherche à indexer le site compromis pour certains mots-clés.
- Requête HTTP entrante : un robot d’indexation (crawler) d’un moteur de recherche visite le serveur web compromis www.victim[.]com.
- Interception par le module BadIIS : le module inspecte l’en-tête User-Agent. Si cet en-tête contient un mot-clé présent dans sa liste de configuration, le module identifie le visiteur comme un crawler.
- Communication C2 et réponse : le module contacte son serveur de commande et contrôle (C2) pour récupérer le contenu empoisonné. Le C2 renvoie un HTML sur mesure, chargé de mots-clés et conçu exclusivement pour le SEO.
- Résultat final : le module BadIIS renvoie cet HTML malveillant au crawler. En conséquence, le moteur de recherche indexe www.victim[.]com comme source pertinente pour les termes présents dans la réponse du C2, empoisonnant ainsi les résultats de recherche.
Phase 2 : le piège de la redirection
Maintenant que le leurre est en place, l’attaquant attend qu’une victime clique sur le résultat empoisonné.
- Requête HTTP entrante : un internaute recherche un mot-clé présent dans la liste de configuration du module et clique sur le résultat empoisonné pointant vers www.victim[.]com.
- Interception par le module BadIIS : si le module n’identifie pas cette requête comme provenant d’un crawler, il inspecte alors l’en-tête Referer. S’il reconnaît le référent comme étant un moteur de recherche, il marque le visiteur comme une victime.
- Communication C2 et réponse : le module contacte le serveur C2 pour récupérer le contenu malveillant. Il s’agit généralement d’une redirection vers un site frauduleux.
- Résultat final : le module BadIIS relaie en toute transparence cette redirection vers le navigateur de la victime. L’internaute, qui s’attendait à visiter www.victim[.]com, est immédiatement redirigé vers le contenu contrôlé par l’attaquant.
Analyse technique de l’arsenal et de l’infrastructure CL-UNK-1037
Nous avons enquêté sur une compromission dans laquelle des attaquants ont obtenu un accès initial à un serveur web. Après avoir établi une première présence, les acteurs se sont propagés vers plusieurs serveurs web de production, contrôleurs de domaine et autres hôtes de grande valeur. Ils ont ensuite :
- déployé des web shells supplémentaires sur chaque serveur web compromis ;
- créé des tâches planifiées à distance pour se déplacer latéralement au sein du réseau, et exécuté des commandes de reconnaissance ainsi que des jeux d’outils complémentaires sur les machines ciblées ;
- créé de nouveaux comptes utilisateurs locaux sur les systèmes compromis.
Exfiltration du code source via le web
Les attaquants ont utilisé les webshells déployés pour compresser l’intégralité du répertoire du code source de l’application web dans des archives au format ZIP. Ils ont ensuite déplacé ces archives vers des emplacements accessibles via le web.
Cela indique clairement que les acteurs prévoyaient de récupérer ultérieurement ces archives via HTTP. Après l’exfiltration du code source, les attaquants ont téléversé plusieurs nouvelles DLL sur les serveurs web compromis, en les enregistrant discrètement en tant que modules IIS.
Des analyses complémentaires ont permis d’identifier ces DLL comme des implants BadIIS.
L’échantillon BadIIS découvert initialement
Une investigation plus approfondie de la DLL du module IIS a révélé qu’elle exportait la fonction RegisterModule. La fonction RegisterModule, appelée par IIS au chargement du module :
- crée une instance d’un objet nommé chongxiede ;
- invoque SetRequestNotifications d’IIS ;
- enregistre des gestionnaires pour OnBeginRequest et OnSendResponse.
Ces méthodes permettent au module de manipuler discrètement le contenu des pages web en interceptant la requête HTTP entrante avant tout traitement, puis à nouveau juste avant l’envoi de la réponse finale.
Une fois une instance de l’objet chongxiede créée, son constructeur extrait la configuration chiffrée de l’implant depuis la section de données de la DLL et la déchiffre par XOR, élément par élément, directement en mémoire. Chongxiede est la translittération pinyin chinoise du terme 重写 (chóng xiě), traduit automatiquement par « rewrite » ou « overwrite ». La figure 1 illustre le processus de déchiffrement.
Configuration de BadIIS et fonctionnement interne
La configuration initiale de l’implant est la suivante :
- Liste de mots-clés Referer/User-Agent : google|yahoo|bing|viet|coccoc|timkhap|tuugo
- Premier serveur C2 : hxxp://404.008php[.]com/
- Second serveur C2 : hxxp://103.6.235[.]26/
Ces éléments de configuration témoignent d’une stratégie ciblée. Si la liste de mots-clés inclut des moteurs de recherche généraux et courants tels que Google et Bing, la présence de services spécifiques à certaines langues met en lumière les cibles privilégiées de l’attaquant :
- Cốc Cốc
- Timkhap
- viet
Les deux premiers sont des moteurs de recherche vietnamiens, tandis que viet renvoie plus généralement aux requêtes liées au Vietnam. Ce ciblage précis de l’écosystème numérique vietnamien révèle une intention stratégique claire de l’acteur de la menace.
Le module utilise cette configuration pour exécuter sa logique principale à l’exécution. Si l’en-tête User-Agent de la requête HTTP correspond à un mot-clé de la même liste, le module identifie le visiteur comme un crawler et lance sa phase d’empoisonnement. Il contacte alors le serveur C2 pour récupérer une page HTML malveillante et optimisée pour le SEO, qu’il sert ensuite comme réponse.
La figure 2 illustre un payload réel livré par le serveur C2. Le payload contient le code HTML malveillant ainsi qu’une série de liens conçus pour inciter le moteur de recherche à les parcourir et à les indexer.
Le mécanisme construit d’abord un leurre, puis tend le piège. Le leurre est créé lorsque les attaquants fournissent du contenu manipulé aux crawlers des moteurs de recherche. Ainsi, le site compromis remonte dans les résultats pour des termes auxquels il n’aurait normalement aucun lien.
Le payload embarque de nombreux liens contenant des requêtes vietnamiennes populaires (cf. figure 2). Un exemple clé est la requête « xôi lạc tv trực tiếp bóng đá hôm nay », qui se traduit par « xôi lạc tv foot en direct aujourd’hui », une recherche courante pour accéder aux services illégaux de streaming de football.
Positionner le serveur compromis sur ce terme permet aux attaquants de tirer parti de sa crédibilité et de sa réputation. La figure 3 montre un résultat de recherche Google pour cette chaîne de mots, et montre qu’une entité gouvernementale d’Asie du Sud-Est a été compromise pour diffuser du contenu frauduleux.
Inversement, lorsque l’en-tête HTTP Referer d’une requête entrante contient l’un des mots-clés de sa configuration, le module le marque comme une requête émanant d’un utilisateur réel. Dans ce cas, il contacte un serveur C2 et relaie directement son contenu vers le navigateur de la victime.
La figure 4 montre un payload réellement proxifié envoyé par le C2 : cette image montre comment le serveur web compromis redirige des visiteurs à leur insu vers un site de paris.
Échantillons supplémentaires et infrastructure
Un indice majeur quant à la fonctionnalité et à l’origine probable de l’implant se trouve dans le nom de sa classe C++ : chongxiede. Comme indiqué plus haut, Chongxiede est la translittération pinyin chinoise du terme 重写 (chóng xiě), traduit automatiquement par « rewrite » ou « overwrite ». Cet artefact linguistique a constitué un point d’appui important dans notre enquête et nous a permis d’élargir nos recherches, conduisant à la découverte d’autres échantillons et d’activités malveillantes liées à l’infrastructure.
Nous avons mis au jour une série de modules IIS natifs apparentés partageant les mêmes enregistrements de gestionnaires et la même logique d’initialisation. Plusieurs de ces nouveaux échantillons référencent des domaines C2 familiers, variantes de la famille de domaines 008php[.]com, tandis que d’autres introduisent une infrastructure jusque-là inédite. La figure 5 montre l’infrastructure et les connexions entre ces échantillons.
Nous avons analysé ces échantillons liés, puis extrait et déchiffré leurs configurations intégrées. Cette analyse a révélé un réseau plus large de serveurs C2 et d’URL qui n’étaient pas auparavant associés à cette campagne. L’examen de cette infrastructure nouvellement découverte a permis d’identifier trois variantes supplémentaires, illustrant l’élargissement de l’arsenal de l’acteur de la menace et des capacités dépassant le cadre du module IIS natif.
En raison de l’importance des informations obtenues à partir de cet artefact linguistique, nous avons nommé cette campagne « Operation Rewrite ».
Trois nouvelles variantes du module BadIIS
Première variante : passerelle ASP.NET
La première variante que nous avons découverte n’est pas un module natif, mais un simple gestionnaire de page ASP.NET. Cette variante scriptée implémente une technique différente pour atteindre le même objectif d’empoisonnement SEO que le module BadIIS principal.
Plutôt que de se greffer directement au pipeline IIS, la page ASP.NET contient toute la logique malveillante dans son événement Page_Load. Lorsqu’une victime demande cette page au serveur, celle-ci vérifie l’en-tête HTTP_REFERER du visiteur afin d’identifier et de rediriger le trafic issu des moteurs de recherche, masquant ainsi son véritable but. Pour le reste du trafic, elle agit comme une passerelle, en proxifiant le contenu malveillant provenant d’un serveur C2 distant.
Il s’agit d’une alternative au module BadIIS principal, plus légère et flexible, probablement destinée à un déploiement rapide sur des serveurs compromis moins critiques. La figure 6 présente la fonction Page_Load de la variante ASP.NET.
Deuxième variante : module IIS managé
La deuxième variante atteint le même objectif que le module IIS natif, mais elle est implémentée en tant que module IIS managé en .NET. Cette version en C# s’appuie sur l’intégration d’ASP.NET au sein d’IIS et se branche dans le pipeline de requêtes du serveur, ce qui lui permet d’inspecter et de modifier chaque requête transitant par l’application.
Ce module réalise l’empoisonnement SEO via deux fonctions principales :
- Détournement des erreurs 404 : le module intercepte les erreurs 404 lorsqu’un crawler explore un lien inexistant contenant des mots-clés issus d’une liste codée en dur. Il sert alors une page d’arnaque personnalisée provenant d’un serveur C2, conduisant les moteurs de recherche à indexer le contenu de l’attaquant sous le domaine de confiance de la victime.
- Injection de contenu dynamique : lorsque le module détecte qu’un crawler consulte une page réelle renvoyant un code 200 OK, il injecte dynamiquement des liens spam et des mots-clés fournis par un autre serveur C2. Cette action modifie le classement de la page dans les résultats de recherche sans altérer le contenu visible par les utilisateurs ordinaires.
Troisième variante : script PHP tout-en-un
La troisième variante est un script PHP qui combine redirection d’utilisateurs et empoisonnement SEO dynamique. Plutôt que de s’intégrer à IIS, ce script fonctionne comme un contrôleur frontal PHP autonome. Il effectue des vérifications simples sur le Referer, le User-Agent et les modèles d’URL pour déterminer précisément quel contenu servir.
- Vérification des requêtes mobiles
Pour les visiteurs provenant d’une recherche Google sur un appareil mobile, le script effectue une vérification supplémentaire. Si le chemin de l’URL demandée contient un mot-clé issu d’une liste codée en dur (par exemple « game » ou « video »), il agit en tant que proxy : le script contacte silencieusement une URL C2 codée en dur, récupère le contenu, puis le sert directement à la victime, qui ne se rend pas compte de la substitution.
- Empoisonnement SEO ciblé sur Googlebot
Lorsque le script détecte Googlebot, il lance un processus en deux étapes pour empoisonner le référencement du site :
- Générateur de sitemap : d’abord, le script récupère depuis le C2 une liste de noms de pages et la présente à Googlebot sous la forme d’un sitemap XML valide, jonché de fausses URL.
- Réécriture de contenu : lorsque le script détecte Googlebot, la deuxième étape s’active et le script exécute une fonction de réécriture de contenu. Il récupère un modèle HTML depuis un autre C2 et injecte les mots-clés extraits de l’URL dans le titre et les en-têtes de la page. Le résultat est une page de spam optimisée, conçue pour obtenir un classement élevé dans les résultats de recherche.
Origine des acteurs de la menace
Nous avons analysé des indices linguistiques ainsi que des recoupements au niveau de l’infrastructure afin de déterminer l’origine des acteurs de la menace derrière CL-UNK-1037. Nous attribuons ce cluster d’activité, avec un haut niveau de confiance, à des attaquants sinophones. De plus, nous le relions, avec un niveau de confiance modéré, au groupe Group 9, et avec un faible niveau de confiance à la campagne DragonRank.
Des acteurs de la menace sinophones
Plusieurs artefacts suggèrent l’implication d’un acteur de la menace sinophone. Comme indiqué précédemment, le nom de l’objet natif chongxiede est un terme en pinyin. La variante PHP a révélé d’autres indices linguistiques : de nombreux commentaires de code rédigés en caractères chinois simplifiés.
La figure 7 présente ces commentaires extraits de la variante PHP, accompagnés de leurs traductions en anglais.
Conception du code et recoupements d’infrastructure avec Group 9
L’architecture interne de BadIIS présente des similitudes avec des variantes précédemment utilisées par Group 9, telles que décrites par ESET dans son livre blanc. Citons notamment :
- l’utilisation de la fonction RegisterModule pour initialiser les composants du module ;
- l’utilisation des gestionnaires OnBeginRequest et OnSendResponse pour intercepter et modifier le trafic web.
Ces similitudes suggèrent que les attaquants développent leurs implants à partir d’une base de code ou d’un modèle de conception commun.
Le recoupement direct de l’infrastructure C2 à travers trois domaines distincts renforce le lien avec Group 9. Les serveurs C2 codés en dur dans les échantillons BadIIS incluaient :
- 404.008php[.]com
- 404.yyphw[.]com
- 404.300bt[.]com
Ces serveurs correspondent directement à des domaines utilisés par Group 9. Plus précisément, ESET a observé que Group 9 utilisait les sous-domaines suivants :
- qp.008php[.]com
- fcp.yyphw[.]com
- sc.300bt[.]com
La figure 8 montre ces recoupements d’infrastructure.
Lien possible avec DragonRank
En plus des connexions directes avec Group 9, nous avons observé plusieurs similitudes avec la campagne DragonRank. Comme le détaille l’article de Cisco Talos, DragonRank est attribuée à un acteur de la menace sinophone présentant des similitudes avec Group 9 décrit par ESET.
Bien que nous n’ayons identifié aucun recoupement d’infrastructure entre CL-UNK-1037 et la campagne DragonRank, nous avons observé les similitudes suivantes :
- Ensemble d’outils : fonctionnalités principales et logique d’exécution du malware similaires, bien que les mises en œuvre diffèrent. Les deux variantes se présentent comme des outils de SEO et de proxy.
- Structure d’URI : un motif récurrent, « zz », apparaît dans les URL C2. Même si ce motif est utilisé différemment dans chaque campagne, nous estimons qu’il pourrait refléter une évolution ou une mise à jour progressive de l’arsenal.
Conclusion
Notre enquête sur une campagne d’empoisonnement SEO a révélé l’activité d’un acteur de la menace sinophone utilisant un arsenal d’implants personnalisés. L’ensemble de ces implants est conçu pour manipuler les résultats des moteurs de recherche et contrôler les flux de trafic.
Nous estimons avec un haut niveau de confiance qu’un acteur de la menace sinophone est à l’origine de cette activité, sur la base d’indices linguistiques directs, ainsi que de recoupements d’infrastructure et d’architecture reliant cet acteur au cluster Group 9. Nos recherches ont également mis en évidence plusieurs similitudes avec la campagne DragonRank.
Les équipes de sécurité et les équipes réseau peuvent tirer parti de l’analyse et des indicateurs présentés dans ce rapport pour améliorer leurs capacités de détection et de chasse aux menaces, et ainsi renforcer leur protection face à ce type d’attaques et à des menaces similaires.
Protection et atténuation des risques par Palo Alto Networks
- Advanced URL Filtering et Advanced DNS Security permettent d’identifier les domaines et URL associés à cette activité comme étant malveillants.
- Cortex XDR prévient les menaces décrites dans ce blog grâce à son moteur de prévention des malwares. Cette approche combine plusieurs couches de protection, dont Advanced WildFire, la protection comportementale contre les menaces et le module Local Analysis afin de bloquer les malwares – connus ou non – avant qu’ils ne puissent impacter les terminaux.
Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse à incident ou composez l’un des numéros suivants :
- Amérique du Nord : Gratuit : +1 (866) 486-4842 (866.4.UNIT42)
- Royaume-Uni : +44 20 3743 3660
- Europe et Moyen-Orient : +31.20.299.3130
- Asie : +65.6983.8730
- Japon : +81 50 1790 0200
- Australie : +61.2.4062.7950
- Inde : 00080005045107
Palo Alto Networks a partagé ces conclusions avec les autres membres de la Cyber Threat Alliance (CTA). Les membres de la CTA s’appuient sur ces renseignements pour déployer rapidement des mesures de protection auprès de leurs clients et perturber de manière coordonnée les activités des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.
Indicateurs de compromission
Empreintes SHA256 des implants BadIIS :
- 01a616e25f1ac661a7a9c244fd31736188ceb5fce8c1a5738e807fdbef70fd60
- bc3bba91572379e81919b9e4d2cbe3b0aa658a97af116e2385b99b610c22c08c
- 5aa684e90dd0b85f41383efe89dddb2d43ecbdaf9c1d52c40a2fdf037fb40138
- c5455c43f6a295392cf7db66c68f8c725029f88e089ed01e3de858a114f0764f
- 82096c2716a4de687b3a09b638e39cc7c12959bf380610d5f8f9ac9cddab64d7
- ed68c5a8c937cd55406c152ae4a2780bf39647f8724029f04e1dce136eb358ea
- 6d79b32927bac8020d25aa326ddf44e7d78600714beacd473238cc0d9b5d1ccf
- b95a1619d1ca37d652599b0b0a6188174c71147e9dc7fb4253959bd64c4c1e9f
- 8078fa156f5ab8be073ad3f616a2302f719713aac0f62599916c5084dd326060
- a73c7f833a83025936c52a8f217c9793072d91346bb321552f3214efdeef59eb
- 6d044b27cd3418bf949b3db131286c8f877a56d08c3bbb0924baf862a6d13b27
- 78ef67ec600045b7deb8b8ac747845119262bea1d51b2332469b1f769fb0b67d
- 78ef67ec600045b7deb8b8ac747845119262bea1d51b2332469b1f769fb0b67d
- 88de33754e96cfa883d737aea7231666c4e6d058e591ef3b566f5c13a88c0b56
- a393b62df62f10c5c16dd98248ee14ca92982e7ac54cb3e1c83124c3623c8c43
- 40a0d0ee76b72202b63301a64c948acb3a4da8bac4671c7b7014a6f1e7841bd2
- 40a0d0ee76b72202b63301a64c948acb3a4da8bac4671c7b7014a6f1e7841bd2
- 1c870ee30042b1f6387cda8527c2a9cf6791195e63c5126d786f807239bd0ddc
- 271c1ddfdfb6ba82c133d1e0aac3981b2c399f16578fcf706f5e332703864656
- 22a9e1675bd8b8d64516bd4be1f07754c8f4ad6c59a965d0e009cbeaca6147a7
- e2e00fd57d177e4c90c1e6a973cae488782f73378224f54cf1284d69a88b6805
- 23aa7c29d1370d31f2631abd7df4c260b85227a433ab3c7d77e8f2d87589948f
- ab0b548931e3e07d466ae8598ca9cd8b10409ab23d471a7124e2e67706a314e8
- 22a4f8aead6aef38b0dc26461813499c19c6d9165d375f85fb872cd7d9eba5f9
- de570369194da3808ab3c3de8fb7ba2aac1cc67680ebdc75348b309e9a290d37
- d8a7320e2056daf3ef4d479ff1bb5ce4facda67dfc705e8729aeca78d6f9ca84
- d6a0763f6ef19def8a248c875fd4a5ea914737e3914641ef343fe1e51b04f858
- c6622e2900b8112e8157f923e9fcbd48889717adfe1104e07eb253f2e90d2c6a
- 6cff06789bf27407aa420e73123d4892a8f15cae9885ff88749fd21aa6d0e8ad
Gestionnaire de fichiers ASPX – empreinte SHA256 :
- b056197f093cd036fa509609d80ece307864806f52ab962901939b45718c18a8
Module IIS managé – empreinte SHA256 :
- 2af61e5acc4ca390d3bd43bc649ab30951ed7b4e36d58a05f5003d92fde5e9a7
Gestionnaire de fichiers PHP – empreinte SHA256 :
- 36bf18c3edd773072d412f4681fb25b1512d0d8a00aac36514cd6c48d80be71b
URLs C2 :
- hxxp://103.6.235[.]26/xvn.html
- hxxp://x404.008php[.]com/zz/u.php
- hxxp://103.6.235[.]78/vn.html
- hxxp://x404.008php[.]com/index.php
- hxxp://103.6.235[.]78/index.php
- hxxp://103.6.235[.]78/zz/u.php
- hxxp://cs.pyhycy[.]com/index.php
- hxxp://cs.pyhycy[.]com/zz/u.php
- hxxps://sl.008php[.]com/kt.html
- hxxp://160.30.173[.]87/zz/u.php
- hxxp://404.pyhycy[.]com/index.php
- hxxp://404.pyhycy[.]com/zz/u.php
- hxxp://404.hao563[.]com/index.php
- hxxp://404.300bt[.]com/zz/u.php
- hxxp://404.yyphw[.]com/index.php
- hxxp://103.6.235[.]26/kt.html
- hxxp://404.yyphw[.]com/zz/u.php
- hxxp://404.hzyzn[.]com/index.php
- hxxp://404.hzyzn[.]com/zz/u.php
- hxxp://404.300bt[.]com/index.php
- hxxp://103.248.20[.]197/index.php
- hxxp://103.248.20[.]197/zz/u.php
- hxxps://fb88s[.]icu/uu/tt.js
- hxxp://404.hao563[.]com/zz/u.php
- hxxp://www.massnetworks[.]org
- hxxp://vn404.008php[.]com/index.php
- hxxp://vn404.008php[.]com/zz/u.php
- hxxp://404.008php[.]com/zz/u.php
Pour aller plus loin
SOMMAIRE
Associé Malware Ressources
Abonnez-vous aux infos d’Unit 42 