OSINT: Du C2 à l'hébergeur (suite du loader PowerShell)

TL;DR

Un domaine C2 (ieservice[.]cc) extrait d’un loader PowerShell. En partant de cette seule chaîne de caractères, et uniquement avec des sources publiques :

• identification de l’IP d’origine derrière Cloudflare, la fuite qui débloque tout ;
• reconstitution d’un cluster de 4 domaines liés par leur registrar, leurs dates d’enregistrement et leurs nameservers ;
• identification de l’hébergeur réel, après correction d’une première piste erronée basée sur une donnée périmée ;
• mise en évidence d’une rotation d’infrastructure entre deux réseaux directement interconnectés ;
• corroboration externe par une vingtaine de DNSBL et par un rapport public de threat intelligence.

1. Le point de départ

À l’issue du reverse, il ne restait qu’une poignée de chaînes utiles. Une seule pointait vers l’extérieur :

hxxps://ieservice[.]cc/JApCJpJtnKvUHmpsgrQIQKpPbiPC/XdGqmpktPRjNQUUgRHmFJKJDsSNZnj.html

Un domaine. C’est tout ce dont je disposais.

Premier réflexe, avant tout pivot : poser la question à laquelle je veux répondre. « qui a écrit ce malware » ? parce qu’avec 0 détection sur VirusTotal, je me suis dit « joli, quand même »

Le premier constat vient sans effort : le domaine sert une page « Access Restricted: This server has been blocked ». Le serveur a déjà été suspendu. Bonne nouvelle pour les victimes, mauvaise nouvelle pour l’analyse : je n’obtiendrai rien du contenu. Il faut travailler sur la structure.

2. Premier pivot : trouver l’origine derrière Cloudflare

Une résolution DNS via CentralOps Domain Dossier donne :

canonical name : ieservice.cc.
addresses      : 45.13.212.251

Et là, il faut s’arrêter une seconde, parce que c’est le résultat le plus important de toute l’investigation.

Le domaine est servi par Cloudflare (ses nameservers sont en ns.cloudflare.com). Or, tout l’intérêt de Cloudflare pour un opérateur malveillant, c’est justement de masquer l’IP d’origine : le visiteur ne parle qu’aux edges de Cloudflare, jamais au serveur réel.

Ici, la résolution renvoie une IP qui n’appartient pas à Cloudflare. C’est une fuite d’origine : le serveur réel est exposé. Les causes possibles sont classiques: enregistrement DNS oublié, proxy désactivé sur un sous-domaine, configuration retirée après suspension du service… Quelle qu’en soit la cause, le résultat est le même : j’ai le serveur.

À partir de là, l’IP devient le pivot central.

3. Fausse piste

Une recherche Shodan sur 45.13.212.251 renvoie un profil riche :

Deux choses sautent aux yeux. D’abord un second domaine : avprog[.]cc. Ensuite un nom de société : PPTECHNOLOGY LIMITED.

La piste PPTECHNOLOGY

Companies House est sans ambiguïté :

• PPTECHNOLOGY LIMITED, n° 12176225
• Siège : 35 Firs Avenue, Londres N11 3NE
• Immatriculée le 27/08/2019, dissoute le 23/12/2025
• SIC 96090: « Other service activities not elsewhere classified »
• Historique : comptes dormants sur toute la durée de vie, plusieurs procédures de radiation

Une société sans activité déclarée, un code d’activité fourre-tout, une dissolution récente. Et ce n’est pas une découverte originale : Team Cymru a publié en décembre 2024 une analyse de ce montage. Leurs conclusions : le 35 Firs Avenue héberge plus de 1 000 sociétés actives, dont environ 85 % sous le code 96090 ; ces entités ne traitent aucun flux financier lié à de la vente d’hébergement ; leur fonction est de fournir une apparence de légitimité, notamment pour les échanges avec le RIPE. Rien d’illégal au regard du droit britannique, et c’est bien le problème.

J’avais donc mon coupable. Sauf que non.

La correction

Par acquit de conscience, j’ai interrogé la source faisant autorité, le RIPE lui-même :

inetnum:      45.13.212.0 - 45.13.212.255
netname:      DATA-CAMPUS
country:      PR
org:          ORG-DCL55-RIPE
status:       ASSIGNED PA
created:      2019-05-10T12:51:48Z
last-modified: 2025-08-07T04:13:13Z

organisation: ORG-DCL55-RIPE
org-name:     Data Campus Limited
country:      HK
org-type:     LIR
address:      Suite C, Level 7, World Trust Tower, 50 Stanley Street, Central, Hong Kong

route:        45.13.212.0/24
origin:       AS215929
created:      2025-08-07T04:11:56Z

Le netblock n’appartient pas à PPTECHNOLOGY. Il appartient à Data Campus Limited (Hong Kong), LIR, annoncé par AS215929.

Que s’est-il passé ? La chronologie est cohérente :

• 07/08/2025 : l’objet route est créé par le mainteneur lir-hk-datacampus-1-MNT. Le /24 passe sous Data Campus.
• 23/12/2025 : PPTECHNOLOGY LIMITED est dissoute.
• 06/02/2026 : Shodan affiche encore « PPTECHNOLOGY LIMITED ».

Le champ Organization de Shodan provient de sa propre base IP→org, qui se met à jour avec du retard. Elle avait six mois de retard. J’ai failli construire toute une attribution sur une étiquette périmée pointant vers une société déjà morte. (la boulette !)

Cela dit, la piste PPTECHNOLOGY n’est pas fausse, elle est historique : elle documente ce que ce netblock était avant. Dans un dossier d’infrastructure, l’historique compte. Elle passe simplement de « attribution » à « contexte », avec une confiance moyenne sur le lien de continuité entre les deux exploitants.

Le profil réel de l’hébergeur

Trois juridictions différentes pour un même /24. Ce mismatch géographique est en soi un marqueur : les infrastructures légitimes n’ont aucune raison de disperser ainsi leurs déclarations.

Signal supplémentaire, visible sur bgp.he.net : AS215929 annonce des bogons, des préfixes qui ne devraient pas être routés. Ce n’est pas un critère de malveillance en soi, mais c’est une pratique de routage que les opérateurs sérieux évitent.

Confiance : élevée - sources primaires RIPE, concordantes.

4. Le WHOIS des domaines : le cluster apparaît

Avec deux domaines en main, le WHOIS devient exploitable.

Le même jour. Le même registrar. La même durée d’un an.

Chaque élément pris isolément est banal. C’est leur conjonction qui fait la preuve :

• Même date : deux domaines enregistrés le même jour, ça n’arrive pas par hasard entre acteurs indépendants.
• NiceNIC : registrar hongkongais à bas coût, régulièrement présent dans les dossiers d’abus. Ce n’est pas un choix par défaut.
• Un an ferme : de l’infrastructure jetable. Personne ne construit à un an.
• Le nommage : ieservice évoque un service Internet Explorer, avprog un programme antivirus. C’est du masquerading (ATT&CK T1036), des noms conçus pour paraître légitimes dans un log ou une liste de processus. Deux variations sur le même thème « composant Windows/sécurité ».

5. Les nameservers Cloudflare : la faille d’OPSEC

Le reverse DNS de l’IP a révélé deux domaines supplémentaires : enixwegemtir[.]cc et mispolishal[.]com. Leur WHOIS complète le tableau et c’est là que se trouve la meilleure trouvaille.

avprog[.]cc et enixwegemtir[.]cc partagent exactement la même paire de nameservers.

Ce n’est pas une coïncidence esthétique. Cloudflare assigne la paire de nameservers au niveau du compte : tous les domaines d’un même compte reçoivent la même paire. Deux domaines partageant iris/trace sont donc, selon toute vraisemblance, dans le même compte Cloudflare.

C’est un lien d’une nature différente de tout ce qui précède : il ne passe ni par l’hébergeur, ni par le registrar, mais par le compte de l’opérateur lui-même.

Et le tableau raconte une histoire d’OPSEC : quatre domaines, trois comptes Cloudflare distincts. L’opérateur compartimente délibérément, mais il a mis deux domaines dans le même panier, et le reverse DNS les a réunis de toute façon.

le mécanisme d’assignation Cloudflare est documenté et le partage exact des deux NS est très peu probable au hasard ; la réserve tient à ce que je ne peux pas vérifier l’assignation côté Cloudflare.

6. Validation externe

Une investigation qui ne repose que sur ses propres déductions est fragile. Deux corroborations indépendantes ici.

Les DNSBL

45.13.212.251 est listée sur une vingtaine de blocklists : Spamhaus (ZEN, SBL, XBL, PBL), Barracuda, UCEPROTECT (niveaux 1, 2 et 3), CBL/abuseat, DroneBL, Tornevall, blocklist.de, SpamRATS, backscatterer, PSBL, NordSpam, bogons.cymru.com…

L’IP n’est pas « suspecte » : elle est massivement documentée comme malveillante par des organismes qui ne se parlent pas entre eux.

Un rapport public sur le même hébergeur

En mars 2026, Breakglass Intelligence a publié « Campaign #39 » : une distribution de NetSupport RAT via ClickFix. Les points de recoupement sont frappants :

• C2 hébergés chez Data Campus Limited (Hong Kong), AS215929, le même AS ;
• enregistrement unifié via NiceNIC, le même registrar ;
• ciblage d’utilisateurs italiens.

Mon cluster tombe donc exactement dans un couple hébergeur/registrar déjà tracé par un tiers.

Et c’est ici qu’il faut résister à la tentation. Ce recoupement ne dit pas que mon loader et Campaign #39 ont le même auteur :

• la famille de malware diffère (loader PowerShell vs NetSupport RAT) ;
• un hébergeur abuse-tolerant a, par définition, plusieurs clients.

Ce que le recoupement établit, avec une confiance élevée, c’est que le couple AS215929 + NiceNIC est un nexus documenté d’activité malveillante.

7. La rotation d’infrastructure

Deux mouvements observés :

L’IP a été recyclée. 45.13.212.251 n’héberge plus ieservice[.]cc ni avprog[.]cc, mais enixwegemtir[.]cc et mispolishal[.]com, les domaines du second lot. Le serveur brûlé sert désormais la vague suivante.

Le domaine a migré. ieservice[.]cc est passé sur 88.80.150.25 :

inetnum:  88.80.150.0 - 88.80.150.255
netname:  DEDISTART-COM
country:  BG
org:      Redcluster LTD
address:  Larnaca, CYPRUS
abuse:    [email protected]

Netblock bulgare, société chypriote, annoncé par AS44901.

Et le détail qui donne son sens à toute la section : AS215929 et AS44901 échangent directement en BGP (l’objet aut-num d’AS215929 déclare import: from AS44901 / export: to AS44901).

Le domaine n’a donc pas fui vers un hébergeur quelconque. Il s’est déplacé à l’intérieur d’un ensemble de réseaux directement interconnectés. C’est la signature du modèle décrit par Spamhaus sous le nom de separation of liabilities : plusieurs entités juridiques dans plusieurs juridictions, chacune renvoyant la responsabilité à la suivante, pendant que l’opérateur se déplace librement de l’une à l’autre.

Confiance : élevée sur la migration et le peering (objets RIPE) ; moyenne sur l’interprétation en termes de cluster coordonné.

8. Chronologie reconstituée

Le point le plus parlant de ce tableau : six mois séparent l’enregistrement des domaines de l’observation du malware. L’infrastructure est pré-provisionnée par lots, à l’avance. Ce n’est pas de l’improvisation ; c’est une chaîne d’approvisionnement.

9. Conclusions et niveaux de confiance

Sur cette dernière ligne

C’était la question de départ, et la réponse est : non, et c’était prévisible.

L’erreur naturelle, quand on voit un nom de société dans un champ Organization, c’est d’y lire un coupable. Mais ce champ désigne le détenteur du bloc d’adresses, l’hébergeur, ou celui qui gère l’allocation. Accuser Data Campus d’avoir écrit ce loader reviendrait à accuser un hébergeur grand public parce qu’un de ses clients y a monté un C2.

La différence, ici, est que Data Campus n’a pas l’air d’être un hébergeur naïf : DNSBL massives, bogons annoncés, déclarations dispersées sur trois juridictions, historique de sociétés-écrans. Le faisceau plaide pour un environnement qui sait ce qu’il héberge. Mais « complaisant » et « auteur » sont deux accusations différentes, et seule la première est soutenue par mes éléments.

C’est exactement pour cela que ce montage existe. Chaque couche, la société-écran britannique, le LIR hongkongais, le netblock déclaré à Porto Rico, le serveur en Roumanie, le registrar hongkongais, le proxy Cloudflare, n’est pas là pour empêcher l’analyse. Elle est là pour rendre la responsabilité inattribuable.

10. Indicateurs de compromission

Domaines

Réseau

11. Limites

Ce que je n’ai pas fait, et pourquoi :

• Aucune interaction avec l’infrastructure. ieservice[.]cc est peut-être encore vivant sur son IP de migration. Récupérer le payload de second étage depuis une adresse personnelle reviendrait à signaler sa présence à l’opérateur et à télécharger du code arbitraire. Le second étage reste donc indéterminé.
• Passive DNS historique non exploité. Les bases complètes sont derrière abonnement. L’historique du /24 élargirait très probablement le cluster.
• Pas de pivot sur la clé d’hôte SSH. Le fingerprint OpenSSH relevé par Shodan est un excellent pivot, une clé réutilisée sur un autre serveur constitue un lien fort entre machines. Cela demande un accès Censys/Shodan étendu.
• L’échantillon n’est pas partagé. Il provient d’un poste utilisateur en environnement professionnel ; il n’a pas été rediffusé et toute donnée relative à la victime a été écartée dès la collecte.
• Instantané daté. Cette infrastructure tourne. Ces observations valent pour juillet 2026.

12. Ce que j’en retire

J’ai commencé en cherchant « qui ». J’ai terminé avec une carte d’infrastructure, une chronologie, une caractérisation d’hébergeur et un « qui » toujours vide.

La donnée périmée est plus dangereuse que la donnée absente. Une case vide invite à chercher. Une case remplie avec six mois de retard invite à conclure. J’ai construit une hypothèse entière sur une étiquette Shodan qui désignait une société déjà dissoute. Le réflexe qui a sauvé l’analyse, redescendre au RIPE, est le plus rentable de tout ce billet.

Les meilleurs pivots sont ceux que l’opérateur ne contrôle pas. Il a choisi son registrar, ses noms de domaine, son hébergeur. Il n’a pas choisi que Cloudflare assigne ses nameservers par compte, ni que le RIPE horodate ses objets, ni que vingt DNSBL indépendantes tiennent des registres. La compartimentation a tenu partout, sauf là où elle ne dépendait pas de lui.

Il est plus simple de monter cette infrastructure que de l’analyser. Quatre domaines à quelques euros, un LIR complaisant, une société à 30 £ dans une boîte aux lettres londonienne partagée avec mille autres. En face, il faut croiser deux registres nationaux, une base RIR, un WHOIS de registrar, vingt DNSBL et un rapport TI pour aboutir à « je sais où, je ne sais pas qui ». Cette asymétrie est le sujet.

Analyse menée en OSINT passif exclusivement, à des fins de recherche défensive. Aucune donnée relative à la victime n’a été collectée ni publiée. Les entités nommées le sont sur la base de registres publics ; aucune affirmation de responsabilité pénale n’est formulée à l’encontre de quiconque.

- loulouby, juillet 2026