Vulnérabilités

Votre connexion, leurs profits des acteurs de la menace détournent des SDK pour monétiser votre bande passante

11 minutes de lecture

Avant-propos

Nous avons détecté une campagne visant à prendre le contrôle des machines de victimes et à monétiser l’accès à leur bande passante. Elle repose sur l’exploitation de la vulnérabilité CVE-2024-36401 impactant GeoServer, une base de données géospatiale. Le score CVSS de cette faille d’exécution de code à distance, classée critique, s’élève à 9,8.

Les cybercriminels s’en servent pour déployer des kits de développement logiciel (SDK) légitimes ou des applications modifiées, leur permettant de générer des revenus passifs via le partage de réseau ou l’usage de proxies résidentiels.

Cette méthode de génération de revenus passifs est particulièrement furtive. Elle reproduit une stratégie de monétisation adoptée par certains développeurs d’applications qui préfèrent les SDK aux publicités traditionnelles. Une pratique parfois bien intentionnée, destinée à préserver l’expérience utilisateur et à améliorer la fidélisation.

Les applications que nous avons identifiées dans le cadre de cette activité malveillante fonctionnent presque en silence. Elles consomment très peu de ressources tout en monétisant la bande passante internet des victimes, sans création ni distribution de malwares. Cette intégration permet aux développeurs d’applications de percevoir des paiements, tandis que les criminels profitent des ressources serveur inutilisées – ce qui leur permet d’échapper à la détection.

Depuis mars 2025, les attaquants sondent les instances GeoServer exposées sur internet. Cortex Xpanse a recensé 3 706 instances de GeoServer accessibles publiquement lors de la première semaine de mai 2025, révélant une surface d’attaque potentiellement importante pour les adversaires exploitant la vulnérabilité CVE-2024-36401.

Les clients de Palo Alto Networks sont mieux protégés contre les menaces mentionnées dans cet article 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 aux incidents.

Unit 42 – Thématiques connexes	Vulnerabilities

Dissection de la campagne

Nous avons suivi de près une campagne apparue début mars 2025. Les attaquants ont modifié aussi bien leur infrastructure que leurs tactiques, techniques et procédures (TTP) pour établir une présence.

Nos analyses ont révélé que les attaquants ont détourné à la fois un SDK et une application :

Le SDK permettait aux développeurs de monétiser d’autres applications en collectant des données utilisateur afin de générer des revenus passifs.
L’application offrait aux utilisateurs la possibilité de gagner un revenu passif en partageant leur connexion internet.

La chronologie suivante illustre l’évolution de cette menace.

Phase 1 : Intrusion initiale (début mars 2025)

La campagne a débuté par des tentatives d’exploitation ciblant la vulnérabilité CVE-2024-36401, suivies du déploiement de l’application détournée et des payloads associés au SDK détourné.

8 mars 2025 : la campagne a commencé par des tentatives d’exploitation provenant de l’adresse IP source 108.251.152[.]209. L’attaquant a utilisé un exploit visant spécifiquement la vulnérabilité CVE-2024-36401.
Distribution d’exécutables personnalisés : nous avons observé que ces premières exploitations récupéraient des exécutables personnalisés hébergés à l’adresse 37.187.74[.]75.
Deux exécutables principaux ont été distribués depuis cet hôte :
- L’application détournée : nous avons détecté plusieurs variantes, dont trois que nous avons désignées sous les identifiants a193, d193 et e193.
- Le SDK détourné : nous avons identifié plusieurs variantes, dont cinq que nous avons désignées sous les identifiants a593, c593, d593, s593 et z593.

Phase 2 : Évolution des tactiques (fin mars – début avril 2025)

Au cours de cette phase, les attaquants ont changé de tactique.

24 mars 2025 : quelques éditeurs présents sur VirusTotal ont signalé l’adresse IP de distribution 37.187.74[.]75 comme étant malveillante. Ce basculement indique que la communauté de la sécurité a commencé à identifier des activités malveillantes émanant de cette adresse. Nous pensons que ce facteur a joué un rôle déterminant dans la décision des attaquants de déplacer leur infrastructure vers une nouvelle adresse IP.
26 mars 2025 : les attaquants semblent avoir cessé de distribuer de nouveaux échantillons de l’application détournée. L’attention s’est apparemment portée exclusivement sur le SDK détourné.
1er avril 2025 : les acteurs de la menace ont basculé leur infrastructure principale de diffusion d’exploits vers une nouvelle adresse IP source, 185.246.84[.]189. Cette manœuvre visait probablement à contourner les listes de blocage et à poursuivre leurs opérations sans entrave.

Phase 3 : Expansion de l’infrastructure et persistance (mi-avril 2025 – en cours)

Les attaquants ont étendu leur infrastructure pendant cette phase de la campagne.

17 avril 2025 : ils ont élargi leur infrastructure backend en mettant en ligne une nouvelle adresse IP de distribution d’exécutables personnalisés, 64.226.112[.]52.
L’adresse IP de distribution initiale, 37.187.74[.]75, était toujours active à la mi-juin.

À la date de rédaction de ce rapport, les tentatives d’exploitation se poursuivent depuis l’adresse 185.246.84[.]189, et les serveurs de distribution d’exécutables personnalisés restent opérationnels.

Analyse de l’exploitation de la vulnérabilité CVE-2024-36401

Le cœur de cette vulnérabilité réside dans la capacité d’un attaquant à injecter du code arbitraire dans des instructions de requête JXPath. JXPath est une bibliothèque du projet Apache Commons qui propose une mise en œuvre de XPath.

XPath est une norme largement adoptée pour l’interrogation et la transformation de documents XML. JXPath étend de manière transparente l’utilisation des expressions XPath à diverses structures de données Java au-delà du XML, notamment les JavaBeans et plusieurs types de collections. D’un point de vue sécurité, cette flexibilité supplémentaire soulève également des préoccupations importantes.

JXPath prend en charge des fonctions d’extension, qu’un attaquant peut exploiter s’il parvient à contrôler l’instruction de requête, ce qui lui permet d’exécuter du code arbitraire. Cette situation représente un risque plus élevé que les vulnérabilités classiques d’injection de requête.

Les attaquants ont par exemple utilisé les fonctions d’extension standard pour invoquer des méthodes telles que getRuntime().exec().

La Figure 1 montre un exemple de code malveillant exploitant la capacité de JXPath à évaluer des expressions, ce qui permet à un attaquant d’injecter et d’exécuter des commandes système arbitraires via le placeholder #{cmd}. En appelant exec(java.lang.Runtime.getRuntime()) au sein de context.getValue, l’attaquant déclenche le mécanisme d’exécution du runtime Java, ce qui conduit à une exécution de code à distance sur le système cible.

Une ligne de code affichée sur fond sombre montre une vulnérabilité d’injection de commande utilisant Java Runtime pour exécuter une commande non indésirable. — Figure 1. Code malveillant contenant une référence JXPath vers une fonction d’exécution Java.

La Figure 2 met en évidence le payload issu de cette attaque. Nous avons reproduit la partie clé de ce payload dans la Figure 2. La portion masquée contraint la victime à exécuter une commande système destinée à télécharger un fichier depuis les adresses IP de distribution contrôlées par l’attaquant.

Capture d’écran d’un extrait de code, incluant des balises telles que GetPropertyValue et ValueReference. L’arrière-plan est noir avec du texte vert. Certaines informations ont été masquées. — Figure 2. Payload d’un exploit observé en conditions réelles.

Selon la NVD :

Cette vulnérabilité a été confirmée comme exploitable via différents types de requêtes Web Feature Service (WFS), Web Map Service (WMS) et Web Processing Service (WPS), notamment GetFeature, GetPropertyValue, GetMap, GetFeatureInfo, GetLegendGraphic et Execute.

Lors de l’analyse d’un exploit utilisé dans cette attaque, nous avons configuré une instance de GeoServer et appliqué un payload observé en conditions réelles afin d’étudier son fonctionnement. Le suivi du flux de code de GeoServer nous a permis d’observer ce qui se passe en interne.

Après avoir simulé l’envoi d’un payload d’attaque, notre commande a été transmise à la fonction GetPropertyValue. Comme l’illustre la Figure 3, la ligne surlignée prend l’objet request entrant et le transmet à une méthode run. La commande est alors portée par request.valueReference.

Capture d’écran d’un code dans un IDE, comprenant la définition d’une méthode dans une classe marquée comme remplaçant une méthode d’un service implémenté. Le code est mis en évidence par une coloration syntaxique en rouge et bleu. — Figure 3. Point d’entrée d’un payload malveillant.

En entrant dans cette fonction, on constate que le payload de la Figure 2 a été transmis à l’objet propertyNameNoIndexes, comme le montre le code d’exploit de la Figure 4. Cet objet appelle ensuite la méthode evaluate de GeoTools.

Capture d’écran d’un code dans un IDE avec coloration syntaxique, affichant des méthodes et une gestion des exceptions liées aux propriétés d’attributs. L’image montre plusieurs lignes de code avec commentaires et indicateurs d’erreurs. — Figure 4. Le payload malveillant est transmis à une méthode GeoTools non sécurisée.

Nous sommes ici dans le code source de GeoTools. La méthode evaluate récupère la valeur de l’attribut GeoTools à partir de l’objet fourni. Dans cette méthode, un objet PropertyAccessor est utilisé pour lire la propriété. La Figure 5 montre que PropertyAccessor est une interface centrale qui définit les opérations de lecture et d’écriture des valeurs de propriété d’un objet. GeoTools tente de trouver un accessor en fonction des paramètres fournis.

Capture d’écran d’un code dans un IDE, comprenant plusieurs méthodes et instructions conditionnelles « if-else », affichées avec des numéros de ligne et une coloration syntaxique. La ligne PropertyAccessors est mise en surbrillance. — Figure 5. Le payload malveillant est transmis à la méthode findPropertyAccessors de l’objet PropertyAccessor.

Une fois l’accessor identifié, il utilise la méthode get de l’objet pour récupérer la valeur de la propriété. La Figure 6 montre que notre payload a été transmis à cette méthode via le paramètre attPath.

Capture d’écran d’un écran d’ordinateur affichant du code dans un IDE, incluant des fonctions et des propriétés écrites dans un langage de programmation, avec un focus sur une méthode nommée « getAttributeExpression ». — Figure 6. Un payload malveillant est transmis à attPath.

La méthode get de l’objet appelle la fonction iteratePointers de la bibliothèque JXPath. Comme le montre la Figure 7, un payload est injecté dans la variable xpath, laquelle est ensuite transmise à la méthode context.iteratePointers.

Capture d’écran de code informatique dans un environnement de développement intégré (IDE), relatif aux requêtes HTTP et à la gestion des erreurs. — Figure 7. Fonction iteratePointers de JXPath.

La fonction ExtensionFunction a été manipulée et utilise computeValue pour évaluer l’expression. Comme l’illustre la Figure 8, la variable function pointe désormais directement vers javax.lang.Runtime.exec, la méthode standard de Java pour exécuter des commandes du système d’exploitation. Les paramètres transmis à cette fonction incluent la commande de l’attaquant, et la ligne surlignée exécute cette commande.

Capture d’écran d’une interface de codage dans un IDE montrant du code HTML et JavaScript. — Figure 8. Exécution de code malveillant.

Serveurs vulnérables exposés

Les données de télémétrie de Cortex Xpanse recueillies en mars et avril 2025 ont révélé 7 126 instances GeoServer exposées publiquement dans 99 pays. Les cinq pays où ces instances sont le plus souvent hébergées sont présentés dans la Figure 9. La majorité des serveurs exposés se trouvent en Chine.

Graphique en barres montrant la répartition des instances GeoServer exposées parmi les cinq principaux pays. La Chine affiche le nombre le plus élevé (plus de 2 500), suivie par les États-Unis, l’Allemagne, le Royaume-Uni et Singapour avec des volumes nettement inférieurs. — Figure 9. Répartition des instances GeoServer exposées dans les cinq pays où elles sont le plus souvent hébergées.

Analyse de la chaîne d’attaque

Nous avons identifié plusieurs stratégies d’exploitation distinctes dans le cadre de cette campagne. Toutes visent à déployer et exécuter un SDK sur le système de la victime. Cette analyse se concentre sur une variante du SDK que nous avons appelée « z593 ». La Figure 10 illustre la première étape : l’exploitation de la vulnérabilité CVE-2024-36401 pour télécharger le payload malicieux (z593) depuis un hôte malveillant contrôlé par l’attaquant.

Image affichant un extrait de code en format XML, lié à WFS et comprenant des références aux exécutables Java Runtime et à des chemins système. L’arrière-plan de la zone de code est sombre, avec du texte mis en évidence en vert, rouge, jaune et blanc. — Figure 10. Étape 1 : exploitation initiale permettant de télécharger le payload de la deuxième étape.

Au cours de la deuxième étape, l’attaquant exploite à nouveau la vulnérabilité CVE-2024-36401 afin d’exécuter le payload téléchargé lors de la première étape (z593), comme le montre la Figure 11.

Capture d’écran affichant du code XML lié à un WFS, avec des URL d’espace de noms et une requête utilisant un environnement Java Runtime. — Figure 11. Étape 2 : exploitation permettant d’exécuter le payload de la deuxième étape.

Plutôt que d’utiliser un serveur web HTTP standard, les attaquants ont déployé des instances privées d’un serveur de partage de fichiers basé sur transfer.sh afin de distribuer leurs payloads. L’instance de transfer.sh est hébergée sur l’une des adresses IP de distribution contrôlées par les attaquants (cf. Figure 12).

Capture d’écran d’un site web intitulé « Easy file sharing from the command line », affichant des exemples de commandes d’upload de fichiers et une zone de glisser-déposer, avec un bouton « Learn more » en bas. Une adresse IP apparaît en haut à gauche. — Figure 12. Page d’index d’un serveur transfer.sh hébergé sur 64.226.112[.]52:8080 par les attaquants.

Les déploiements décrits dans la Figure 12 étaient actifs sur le port 8080 et répartis sur deux adresses IP contrôlées par les attaquants :

64.226.112[.]52
37.187.74[.]75

Si l’exploitation initiale aboutit, le script agit alors comme un « stager ». Deux autres fichiers sont alors téléchargés, comme l’illustre la Figure 13.

Capture d’écran d’un terminal affichant des commandes pour télécharger des fichiers avec wget depuis des adresses IP spécifiques. — Figure 13. Contenu du fichier z593 depuis 64.226.112[.]52 menant à des fichiers supplémentaires.

z401 est le premier script identifié dans la Figure 13. Il est conçu pour être furtif : il crée un répertoire caché et y place l’exécutable principal, comme le montre la Figure 14.

Capture d’écran d’un terminal affichant des commandes Unix pour supprimer, créer et naviguer dans des répertoires, ainsi qu’une commande wget permettant de télécharger un fichier depuis une adresse IP donnée. — Figure 14. Contenu de z401 depuis 64.226.112[.]52.

La Figure 15 illustre le fonctionnement du second script mentionné dans la Figure 13 (z402), qui prépare l’environnement puis lance l’exécutable principal en lui transmettant la clé d’application.

Texte affiché dans une fenêtre de terminal montrant une interface en ligne de commande, avec du code impliqué dans la configuration d’une variable d’environnement nommée « PATH ». — Figure 15. Contenu de z402 depuis 64.226.112[.]52.

Une fois lancé, l’exécutable fonctionne de manière furtive en arrière-plan. Il surveille les ressources de l’appareil et partage illicitement la bande passante de la victime dès que possible. L’attaquant génère alors des revenus passifs.

Les fichiers exécutables issus de ces tentatives d’exploitation sont conçus pour interagir avec deux services légitimes : l’application et le SDK détournés. Tous deux offrent normalement aux utilisateurs un moyen de générer un revenu passif en partageant les ressources réseau d’appareils inactifs.

Dans ce contexte, les attaquants détournent les fonctionnalités de l’application ou du SDK. À l’image des mineurs de crypto-monnaie qui réquisitionnent les ressources système à des fins lucratives, ces applications exploitées exploitent elles aussi les ressources des appareils pour en tirer un gain financier. Cependant, contrairement aux mineurs malveillants, ce type d’abus d’applications ou de SDK reste généralement plus discret. Il attire moins l’attention et génère des profits plus modestes pour l’acteur malveillant, ce qui peut contribuer à prolonger ses opérations tout en échappant à la détection.

Analyse de l’application détournée

Une analyse approfondie du binaire installé par les attaquants sur le serveur de la victime révèle qu’ils ont utilisé Dart, comme l’illustre la Figure 16. Dart est un langage de programmation open source. Deux raisons principales semblent avoir motivé ce choix :

Monétisation via SDK : les attaquants ont utilisé Dart pour intégrer le SDK de revenus passifs et interagir avec son service. Cette interaction est conçue pour garantir la génération et la collecte de flux de revenus passifs au bénéfice de l’acteur malveillant.
Compatibilité multiplateforme sous Linux : les attaquants ont également tiré parti de la portabilité inhérente de Dart. Ils ont exploité cette caractéristique pour compiler l’exécutable spécifiquement pour les architectures Linux, élargissant ainsi leur champ potentiel de cibles.

L’adoption de Dart à ces fins est notable, car elle peut représenter une tentative d’échapper aux signatures de détection, généralement davantage axées sur les langages couramment associés aux malwares.

Capture d’écran d’une interface de programmation affichant une liste de code et de fonctions principalement associées au langage Dart. Une chaîne de caractères spécifique est mise en évidence. — Figure 16. Binaire utilisant Dart pour une compatibilité multiplateforme.

Analyse du SDK détourné

Afin de vérifier la nature du composant SDK utilisé dans cette campagne, nous avons comparé le binaire du SDK détourné par l’attaque avec la version officielle du SDK disponible sur le site de l’éditeur. Notre analyse a confirmé que les deux fichiers étaient identiques. Cela suggère que les attaquants utilisent un SDK légitime et non modifié, ce qui leur permet potentiellement de contourner la détection par les solutions de protection des postes de travail.

Conclusion

Cette campagne en cours illustre une évolution significative dans la manière dont les adversaires monétisent les systèmes compromis. La stratégie centrale des attaquants repose sur une monétisation furtive et persistante plutôt que sur une exploitation agressive des ressources. Ils y parviennent en déployant des exécutables qui détournent des services légitimes de revenus passifs, exploitant discrètement les ressources des appareils pour des activités telles que le partage de bande passante. Cette approche privilégie une génération de revenus à long terme et à faible visibilité plutôt que des techniques facilement détectables.

Pour contrer cette menace, nous recommandons vivement d’appliquer les correctifs et mises à jour disponibles dès que possible.

Les clients de Palo Alto Networks sont mieux protégés contre les vulnérabilités et les malwares grâce aux produits et services suivants :

Advanced Threat Prevention peut bloquer les attaques grâce aux bonnes pratiques via la signature de prévention des menaces 95463. De plus, ATP inclut une protection basée sur le machine learning capable de détecter le trafic d’exploitation en temps réel.
Advanced WildFire peut empêcher le transfert de l’exécutable personnalisé.
Advanced URL Filtering et Advanced DNS Security permettent de bloquer des URL malveillantes associées à cette activité..

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 aux incidents 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 : 000 800 050 45107

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

Adresses IP et ports TCP utilisés pour l’infrastructure de la campagne

37.187.74[.]75:8080
64.226.112[.]52:8080

Artefacts de la campagne

SHA256 du fichier	URL contactée par le fichier
89f5e7d66098ae736c39eb36123adcf55851268973e6614c67e3589e73451b24	hxxp://37.187.74[.]75:8080/w1wOYGVLEX/a101
6db4b685f413a3e02113677eee10a29c7406414f7f4da611f31d13e3f595f85d	hxxp://37.187.74[.]75:8080/IyxzymKCp2/a102
4e4a467abe1478240cd34a1deaef019172b7834ad57d46f89a7c6c357f066fdb	hxxp://37.187.74[.]75:8080/cE58oqrYGO/a193
4e40a0df8f4ba4a87ab8fc64950c67f6725a7e8f14a0a84a4ed79b3a8924ba19	hxxp://37.187.74[.]75:8080/YDjV1ocro3/a401
663970530e764f91b0be43936331e6c0a93610db6b86c6c4b64de270ae4d4630	hxxp://37.187.74[.]75:8080/3g5eBN8nqv/a402
7c18fe9da63c86f696f9ad7b5fcc8292cac9d49973ba12050c0a3a18b7bd1cc9	hxxp://37.187.74[.]75:8080/JadF0ucQNf/a593
84ee11f40da3538e4601456912c3efa0e92a903948812fd17fe650c5f7ac33ad	hxxp://37.187.74[.]75:8080/Do4YwzvAJN/alog
0971264967ba8d461ce98f86b90810493c5e22fc80bf61f0d0eb7a2599a7f77a	hxxp://37.187.74[.]75:8080/DQ5ydzkPnK/c401
491f5af9d29f52a6df026159a8ebd27ee6e27151ea78c4782eb05b2c5d39bfc3	hxxp://37.187.74[.]75:8080/a8HejAHngH/c402
a852133ff7f24b14e4224e7052f6d309353b4838fe5f17d25c712d7a1dd6e80a	hxxp://37.187.74[.]75:8080/vLs5vxpDgV/c593
b66c64ccd7b9c96fad53f6d3aa0441e46eca899ad8d97964573e41c94fccddba	hxxp://37.187.74[.]75:8080/KaMJw2fsDW/d101
f340abe5689e51cf78b10165cb93ab8a2988d0fedd0e74c74fc23ac2dca93a13	hxxp://37.187.74[.]75:8080/TMuAS1wp8m/d102
fc28f97f818d07fd8824333de26e5a0ca0d3fe7233d86f7e227e4838cfea0ca4	hxxp://37.187.74[.]75:8080/iKA3jGXk6x/d193
7c0c69aa0dcfc937c1fef8d42c74f7e46d128898c1d99d3362f2d18397be36ae	hxxp://37.187.74[.]75:8080/fK4SCflkNg/d401
33aad585d6280d1921b5f46f8894ee05d426c7751c2133ed5484bf65af587576	hxxp://37.187.74[.]75:8080/Y1WT747MRP/d402
2c5581572ec4877df8ec3e5d2b30bfff5718ecd27d8b3dbe2f393aa5821e7ddd	hxxp://37.187.74[.]75:8080/H0cwXMzCrJ/d593
0e2b92991186bc8a817e0187a9b58928969350bc8d8ad7e6b6cd91c185a7e03c	hxxp://37.187.74[.]75:8080/XA8Dkr1CJ4/dlog
5bc5dfeaeb43fb1e967cad028f8d2c48f5db17ee6c23c383faee74455c2f1f33	hxxp://37.187.74[.]75:8080/52F6SqfuuS/e101
8b25144ad17d023f67477be4791db45d9197d7cfb666b3a5ccc1b1c0e4bae3af	hxxp://37.187.74[.]75:8080/7kS5qiHwg8/e102
8aafb9965e946e5d4be085a1373abc750a1488ff78e6e082cc36ff20ff328465	hxxp://37.187.74[.]75:8080/ei0Ul7l75J/e193
a13a07d15d94c996d8b7e8ed633073f6a3e2268a8d14363f16ad48160b85df08	hxxp://37.187.74[.]75:8080/kGQtGhOpCP/elog
cdae958629383c4dba22a115615d8a63211bbccb06335cd1c4b5e2c2aa3fee77	hxxp://37.187.74[.]75:8080/wHNOFLazdK/glog (from d401)
bbdda70f0c4a3de4ec955e134ad46895ac931e21b930837a85633277128ab7d2	hxxp://37.187.74[.]75:8080/wlLiXFNtjU/hlog (from c401)
4fd789a19db35e054a5135466d610452bea607a11b7ec765b5474847c22e637c	hxxp://37.187.74[.]75:8080/gmhm4lmSLO/plog (from z401)
43b49294b778d4489c69922ff3aca27964a04e0f08bcc830108dc83261a0b205	hxxp://37.187.74[.]75:8080/QF8plwpY8Y/s401
ae706c149497c2fc809682e8827996ea3ceb7bcecddd87be7543d1dca4853470	hxxp://37.187.74[.]75:8080/zJ03zmSrz6/s402
3fd7794be80782b11a09f51ac8cbf2147e9d79303923f279d610ee45e12506eb	hxxp://37.187.74[.]75:8080/22mINruojN/s593
e25d6134c6a0573ded1d340f609dd71d15934ca165ea79d47898aa37a5185415	hxxp://37.187.74[.]75:8080/3pHrSu54Pf/slog (from s401)
085da541d7555ac6afcacd5899027c3fa4132c1eccfb3d8223794c4e0e3eb361	hxxp://37.187.74[.]75:8080/vPN5rgRMTz/wlog (from a401)
2aa6f95dbe8d17e8e70db677808c96ee956c36b7cc8f274435173cfed0b1f5af	hxxp://37.187.74[.]75:8080/T8VevroEJT/z401
2b176eb8afa0b089ee8fb072c68c6fdcfe4b2f034c776cc32064f26c0e6c69a3	hxxp://37.187.74[.]75:8080/uCX4Nl2Pwu/z402
915d1bb1000a8726df87e0b15bea77c5476e3ec13c8765b43781d5935f1d2609	hxxp://37.187.74[.]75:8080/3twwHaJzxo/z593
fa2687f94955fbdc2c41f1cff8c7df24937aeb942e4d7856bf2ff52ebf2e61aa	hxxp://64.226.112[.]52:8080/MFTYFuqKGU/a401
663970530e764f91b0be43936331e6c0a93610db6b86c6c4b64de270ae4d4630	hxxp://64.226.112[.]52:8080/cxtpjeM3KU/a402
e0b886a39cf098a3c7daa021c7af022b0ceb6edcf3fa49e3c3b8f70b843423c2	hxxp://64.226.112[.]52:8080/XEQS3MTzdS/a593
9515df36a6d16c0a9fcca680d6b181539d80efd4cda85dacbfb30127a7f11736	hxxp://64.226.112[.]52:8080/fAFUQgw7Py/c401
491f5af9d29f52a6df026159a8ebd27ee6e27151ea78c4782eb05b2c5d39bfc3	hxxp://64.226.112[.]52:8080/0rX20C97S6/c402
b381e8355cf3a432e63064897cc7719e8b9c38e91c6151cd1e7aed4cd219a75b	hxxp://64.226.112[.]52:8080/LuoHgydq6F/c593
dec84a568b6393ccd863bb38851a76f54de6f59193660e4b88aa1f941b744469	hxxp://64.226.112[.]52:8080/g1Gl1JWEUw/d401
33aad585d6280d1921b5f46f8894ee05d426c7751c2133ed5484bf65af587576	hxxp://64.226.112[.]52:8080/AORGz7zIzn/d402
7620f22a5ed1a8ac2a1da732e55e14a13197b631e5abba6431f88e5cfa3ae2de	hxxp://64.226.112[.]52:8080/rKS64mUmF7/d593
3d7ac752bb0d54802f2def38f44e10854f70ab5a9a001b5c39ab0531b9ed74bf	hxxp://64.226.112[.]52:8080/vbbdG8dpAw/s401
ae706c149497c2fc809682e8827996ea3ceb7bcecddd87be7543d1dca4853470	hxxp://64.226.112[.]52:8080/W7lJoMcuOu/s402
6dd6751bae92dfa504f0ad5558ab8adfdfba3df5a7f218245627574bfac39f11	hxxp://64.226.112[.]52:8080/6mXfFz7ltE/s593
357ca4ad31132ad4bd605e3217968819b04d577884a4e9dd760ed0182c4609ed	hxxp://64.226.112[.]52:8080/YbEYCqCFVl/z401
2b176eb8afa0b089ee8fb072c68c6fdcfe4b2f034c776cc32064f26c0e6c69a3	hxxp://64.226.112[.]52:8080/1Vt9KBLEFr/z402
97c8ec63766ce63b8ace283928922cfceb7c8f3bc72edcbd255e157a1afb15fe	hxxp://64.226.112[.]52:8080/09KvYAUSHm/z593

Pour aller plus loin

Le composant JXPath – Apache Commons