Les informations disponibles ne permettent pas d’attribuer définitivement C2Looper à un groupe de rançongiciel identifié. Les ressemblances éventuellement relevées entre certaines infrastructures doivent donc être considérées comme des pistes d’enquête, et non comme la preuve d’un même auteur ou d’un même contrôle opérationnel.

Deux versions, deux méthodes de commande

L’ancienne version : un serveur HTTP et des balises très fréquentes

Les premiers échantillons communiquent avec un serveur contrôlé par l’attaquant via HTTP en clair et utilisent des tâches au format JSON. Les analyses font état d’interrogations très rapprochées, parfois espacées d’environ une seconde. Cette régularité peut constituer un signal comportemental particulièrement utile sur le poste ou le réseau.

La balise envoyée par l’implant contient notamment :

• le nom d’utilisateur Windows ;
• le nom d’hôte DNS ;
• l’identifiant du processus C2Looper en cours d’exécution ;
• un identifiant de bot dérivé du nom d’hôte et du nom d’utilisateur.

Les informations d’état sont envoyées vers le chemin /api/beacon, tandis que les résultats des commandes transitent par /api/result/.

Le jeu de commandes observé donne à l’opérateur un contrôle pratique de la machine infectée. Il comprend notamment :

• l’exécution de commandes système ou shell arbitraires ;
• la reconnaissance du système et de l’hôte ;
• le téléchargement de fichiers ;
• la mise à jour de l’implant et le déploiement de charges utiles supplémentaires.

La mise à jour via le détournement de DLL OneDrive

Une fonction upload peut récupérer un exécutable portable depuis une URL fournie par l’opérateur et l’enregistrer sous la forme d’une DLL dans le répertoire OneDrive local de l’utilisateur. Dans les échantillons rapportés, le fichier porte le nom wtsapi32.dll et se trouve sous %LocalAppData%\Microsoft\OneDrive.

Le logiciel malveillant peut ensuite arrêter le processus OneDrive et s’appuyer sur un exécutable OneDrive légitime pour charger la bibliothèque piégée. Cette technique, appelée DLL sideloading ou chargement latéral de DLL, consiste à placer une bibliothèque malveillante à proximité d’un programme de confiance afin que celui-ci la charge dans le cadre de son fonctionnement normal.

Le signal à rechercher n’est donc pas simplement la présence de OneDrive. Il faut plutôt s’intéresser à un exécutable OneDrive légitime qui charge une DLL inattendue depuis un emplacement inhabituel et accessible en écriture par l’utilisateur.

Des mécanismes destinés à compliquer l’analyse

C2Looper chiffre ses chaînes en mémoire ou à l’exécution au moyen d’un mécanisme XOR, avec une clé de huit octets qui serait réutilisée. Il résout également de manière dynamique des API Windows au moyen de LoadLibrary et GetProcAddress. Ces procédés peuvent réduire l’efficacité d’une inspection statique élémentaire et rendent les données comportementales des outils EDR — les solutions de détection et de réponse sur les terminaux — d’autant plus importantes.

La version récente transforme GitHub en infrastructure C2

Une version plus récente délaisse le serveur C2 traditionnel au profit de dépôts GitHub. Ceux-ci servent à transmettre les tâches, recevoir les résultats et, selon les observations disponibles sur cette variante, gérer des données liées aux charges utiles.

Chaque machine infectée se voit attribuer son propre répertoire dans un dépôt. L’implant consulte un fichier cmd.json, exécute l’action demandée, puis écrit le résultat dans un fichier result.json du même répertoire.

Cette organisation basée sur des fichiers offre à l’opérateur un mécanisme simple pour envoyer des commandes et récupérer les réponses sans maintenir nécessairement un serveur C2 dédié. Elle peut aussi compliquer les stratégies qui reposent uniquement sur le blocage de domaines ou d’adresses associés à l’attaquant : GitHub est également utilisé de manière légitime par les développeurs et les entreprises.

La détection doit donc être comportementale. Il est pertinent d’examiner les accès périodiques aux dépôts ou aux API GitHub depuis des postes qui n’ont normalement pas besoin de ces services, puis de distinguer cette activité JSON propre à chaque machine des usages autorisés liés au développement ou à l’intégration continue.

L’adoption de GitHub, ainsi que l’ajout de capacités de déploiement de charges utiles dans les échantillons plus récents, suggèrent que C2Looper est toujours en développement actif.

Une diffusion possible par ingénierie sociale ClickFix

ThreatLabz estime, avec un niveau de confiance faible à moyen, que C2Looper pourrait être distribué au moyen d’une chaîne d’infection ClickFix en plusieurs étapes. Dans ce type de scénario, la victime voit une fausse vérification, une erreur de navigateur, un CAPTCHA ou un message prétendant corriger un problème système. Elle est ensuite incitée à copier puis à exécuter une commande dans PowerShell, la boîte de dialogue Exécuter de Windows ou une autre interface.

Cette méthode fait de l’interaction humaine un point essentiel de prévention. Une page web, un navigateur ou un message de vérification ne devrait jamais demander à un utilisateur de coller une commande dans PowerShell, Terminal ou la boîte de dialogue Exécuter pour terminer une procédure de contrôle ou de réparation.

Des analyses connexes évoquent aussi l’hameçonnage vocal via Teams et l’utilisation abusive de Quick Assist dans l’écosystème plus large de l’ingénierie sociale. Les éléments fournis ne démontrent toutefois pas que chacune de ces campagnes a distribué C2Looper. Ces rapprochements doivent donc être considérés comme un contexte plausible, pas comme une attribution confirmée.

Les comportements à surveiller

Les organisations peuvent se concentrer sur quelques signaux à forte valeur plutôt que chercher à bloquer indistinctement chaque outil ou service associé au malware :

• Balises HTTP en clair très fréquentes : recherchez des requêtes POST JSON inhabituellement régulières, en particulier vers des chemins ressemblant à /api/beacon et /api/result/, lorsqu’elles sont corrélées à un processus nouveau ou suspect.
• Accès GitHub anormal : surveillez les accès aux dépôts ou aux API GitHub selon un rythme périodique, notamment lorsqu’ils impliquent des répertoires propres à chaque hôte contenant cmd.json et result.json. GitHub ne doit pas être bloqué sans distinction : les flux de développement et d’automatisation légitimes doivent être pris en compte.
• Chargement latéral de DLL par OneDrive : déclenchez une alerte lorsqu’un exécutable OneDrive légitime s’exécute depuis un chemin inhabituel du profil utilisateur, charge une DLL depuis un répertoire adjacent accessible en écriture ou crée des processus enfants inattendus.
• Exécution de commandes et reconnaissance : utilisez les journaux EDR pour repérer PowerShell, cmd.exe, l’activité de la boîte de dialogue Exécuter, la découverte du système, les téléchargements par étapes et l’exécution shell depuis des binaires récemment observés.
• Profil comportemental d’un implant Rust : combinez la résolution dynamique d’API, les chaînes chiffrées, les interrogations réseau régulières et le déploiement de charges utiles au lieu de vous fier à une seule caractéristique du fichier.

Les priorités de prévention

Les contrôles techniques doivent être associés à des mesures contre l’ingénierie sociale. Lorsque les contraintes métier le permettent, les entreprises devraient encadrer l’utilisation de PowerShell, des interpréteurs de scripts, des binaires non signés et l’exécution depuis des répertoires accessibles en écriture par les utilisateurs. Une liste blanche applicative peut également limiter l’exécution d’une charge utile téléchargée.

Les collaborateurs et les équipes d’assistance doivent savoir qu’il ne faut jamais coller une commande fournie par un site web, un CAPTCHA, une page d’erreur de navigateur ou un contact d’assistance inattendu. Les outils de support à distance doivent être utilisés via des procédures approuvées, des canaux vérifiés, une authentification forte, une journalisation des sessions et un examen rapide des connexions inhabituelles.

La segmentation du réseau, le principe du moindre privilège, l’authentification multifacteur, la correction rapide des systèmes exposés à Internet et des sauvegardes hors ligne ou immuables régulièrement testées peuvent réduire l’impact d’un accès initial. Si une machine présente des balises suspectes, une activité shell inhabituelle ou un chargement latéral de DLL, elle doit être isolée rapidement, tout en préservant les journaux du terminal, les traces réseau et, lorsque cela est nécessaire, la mémoire pour l’analyse.

À retenir

C2Looper illustre l’évolution d’un backdoor HTTP relativement classique vers un implant plus flexible, capable d’utiliser des dépôts GitHub comme infrastructure opérationnelle. Ses fonctions de shell distant, de reconnaissance, de téléchargement et de mise à jour en font un point d’appui crédible pour des intrusions liées aux rançongiciels. Mais les éléments disponibles justifient une évaluation prudente, et non une attribution définitive.

La meilleure défense consiste à associer des habitudes de travail résistantes aux scénarios ClickFix à une détection comportementale : commandes inhabituelles, chargement de DLL par OneDrive, interrogations HTTP très rapides et activité GitHub inexpliquée.

Les informations disponibles ne permettent pas d’attribuer définitivement C2Looper à un groupe de rançongiciel identifié. Les ressemblances éventuellement relevées entre certaines infrastructures doivent donc être considérées comme des pistes d’enquête, et non comme la preuve d’un même auteur ou d’un même contrôle opérationnel.

Deux versions, deux méthodes de commande

L’ancienne version : un serveur HTTP et des balises très fréquentes

Les premiers échantillons communiquent avec un serveur contrôlé par l’attaquant via HTTP en clair et utilisent des tâches au format JSON. Les analyses font état d’interrogations très rapprochées, parfois espacées d’environ une seconde. Cette régularité peut constituer un signal comportemental particulièrement utile sur le poste ou le réseau.

La balise envoyée par l’implant contient notamment :

• le nom d’utilisateur Windows ;
• le nom d’hôte DNS ;
• l’identifiant du processus C2Looper en cours d’exécution ;
• un identifiant de bot dérivé du nom d’hôte et du nom d’utilisateur.

Les informations d’état sont envoyées vers le chemin /api/beacon, tandis que les résultats des commandes transitent par /api/result/.

Le jeu de commandes observé donne à l’opérateur un contrôle pratique de la machine infectée. Il comprend notamment :

• l’exécution de commandes système ou shell arbitraires ;
• la reconnaissance du système et de l’hôte ;
• le téléchargement de fichiers ;
• la mise à jour de l’implant et le déploiement de charges utiles supplémentaires.

La mise à jour via le détournement de DLL OneDrive

Une fonction upload peut récupérer un exécutable portable depuis une URL fournie par l’opérateur et l’enregistrer sous la forme d’une DLL dans le répertoire OneDrive local de l’utilisateur. Dans les échantillons rapportés, le fichier porte le nom wtsapi32.dll et se trouve sous %LocalAppData%\Microsoft\OneDrive.

Le logiciel malveillant peut ensuite arrêter le processus OneDrive et s’appuyer sur un exécutable OneDrive légitime pour charger la bibliothèque piégée. Cette technique, appelée DLL sideloading ou chargement latéral de DLL, consiste à placer une bibliothèque malveillante à proximité d’un programme de confiance afin que celui-ci la charge dans le cadre de son fonctionnement normal.

Le signal à rechercher n’est donc pas simplement la présence de OneDrive. Il faut plutôt s’intéresser à un exécutable OneDrive légitime qui charge une DLL inattendue depuis un emplacement inhabituel et accessible en écriture par l’utilisateur.

Des mécanismes destinés à compliquer l’analyse

C2Looper chiffre ses chaînes en mémoire ou à l’exécution au moyen d’un mécanisme XOR, avec une clé de huit octets qui serait réutilisée. Il résout également de manière dynamique des API Windows au moyen de LoadLibrary et GetProcAddress. Ces procédés peuvent réduire l’efficacité d’une inspection statique élémentaire et rendent les données comportementales des outils EDR — les solutions de détection et de réponse sur les terminaux — d’autant plus importantes.

La version récente transforme GitHub en infrastructure C2

Une version plus récente délaisse le serveur C2 traditionnel au profit de dépôts GitHub. Ceux-ci servent à transmettre les tâches, recevoir les résultats et, selon les observations disponibles sur cette variante, gérer des données liées aux charges utiles.

Chaque machine infectée se voit attribuer son propre répertoire dans un dépôt. L’implant consulte un fichier cmd.json, exécute l’action demandée, puis écrit le résultat dans un fichier result.json du même répertoire.

Cette organisation basée sur des fichiers offre à l’opérateur un mécanisme simple pour envoyer des commandes et récupérer les réponses sans maintenir nécessairement un serveur C2 dédié. Elle peut aussi compliquer les stratégies qui reposent uniquement sur le blocage de domaines ou d’adresses associés à l’attaquant : GitHub est également utilisé de manière légitime par les développeurs et les entreprises.

La détection doit donc être comportementale. Il est pertinent d’examiner les accès périodiques aux dépôts ou aux API GitHub depuis des postes qui n’ont normalement pas besoin de ces services, puis de distinguer cette activité JSON propre à chaque machine des usages autorisés liés au développement ou à l’intégration continue.

L’adoption de GitHub, ainsi que l’ajout de capacités de déploiement de charges utiles dans les échantillons plus récents, suggèrent que C2Looper est toujours en développement actif.

Une diffusion possible par ingénierie sociale ClickFix

ThreatLabz estime, avec un niveau de confiance faible à moyen, que C2Looper pourrait être distribué au moyen d’une chaîne d’infection ClickFix en plusieurs étapes. Dans ce type de scénario, la victime voit une fausse vérification, une erreur de navigateur, un CAPTCHA ou un message prétendant corriger un problème système. Elle est ensuite incitée à copier puis à exécuter une commande dans PowerShell, la boîte de dialogue Exécuter de Windows ou une autre interface.

Cette méthode fait de l’interaction humaine un point essentiel de prévention. Une page web, un navigateur ou un message de vérification ne devrait jamais demander à un utilisateur de coller une commande dans PowerShell, Terminal ou la boîte de dialogue Exécuter pour terminer une procédure de contrôle ou de réparation.

Des analyses connexes évoquent aussi l’hameçonnage vocal via Teams et l’utilisation abusive de Quick Assist dans l’écosystème plus large de l’ingénierie sociale. Les éléments fournis ne démontrent toutefois pas que chacune de ces campagnes a distribué C2Looper. Ces rapprochements doivent donc être considérés comme un contexte plausible, pas comme une attribution confirmée.

Les comportements à surveiller

Les organisations peuvent se concentrer sur quelques signaux à forte valeur plutôt que chercher à bloquer indistinctement chaque outil ou service associé au malware :

• Balises HTTP en clair très fréquentes : recherchez des requêtes POST JSON inhabituellement régulières, en particulier vers des chemins ressemblant à /api/beacon et /api/result/, lorsqu’elles sont corrélées à un processus nouveau ou suspect.
• Accès GitHub anormal : surveillez les accès aux dépôts ou aux API GitHub selon un rythme périodique, notamment lorsqu’ils impliquent des répertoires propres à chaque hôte contenant cmd.json et result.json. GitHub ne doit pas être bloqué sans distinction : les flux de développement et d’automatisation légitimes doivent être pris en compte.
• Chargement latéral de DLL par OneDrive : déclenchez une alerte lorsqu’un exécutable OneDrive légitime s’exécute depuis un chemin inhabituel du profil utilisateur, charge une DLL depuis un répertoire adjacent accessible en écriture ou crée des processus enfants inattendus.
• Exécution de commandes et reconnaissance : utilisez les journaux EDR pour repérer PowerShell, cmd.exe, l’activité de la boîte de dialogue Exécuter, la découverte du système, les téléchargements par étapes et l’exécution shell depuis des binaires récemment observés.
• Profil comportemental d’un implant Rust : combinez la résolution dynamique d’API, les chaînes chiffrées, les interrogations réseau régulières et le déploiement de charges utiles au lieu de vous fier à une seule caractéristique du fichier.

Les priorités de prévention

Les contrôles techniques doivent être associés à des mesures contre l’ingénierie sociale. Lorsque les contraintes métier le permettent, les entreprises devraient encadrer l’utilisation de PowerShell, des interpréteurs de scripts, des binaires non signés et l’exécution depuis des répertoires accessibles en écriture par les utilisateurs. Une liste blanche applicative peut également limiter l’exécution d’une charge utile téléchargée.

Les collaborateurs et les équipes d’assistance doivent savoir qu’il ne faut jamais coller une commande fournie par un site web, un CAPTCHA, une page d’erreur de navigateur ou un contact d’assistance inattendu. Les outils de support à distance doivent être utilisés via des procédures approuvées, des canaux vérifiés, une authentification forte, une journalisation des sessions et un examen rapide des connexions inhabituelles.

La segmentation du réseau, le principe du moindre privilège, l’authentification multifacteur, la correction rapide des systèmes exposés à Internet et des sauvegardes hors ligne ou immuables régulièrement testées peuvent réduire l’impact d’un accès initial. Si une machine présente des balises suspectes, une activité shell inhabituelle ou un chargement latéral de DLL, elle doit être isolée rapidement, tout en préservant les journaux du terminal, les traces réseau et, lorsque cela est nécessaire, la mémoire pour l’analyse.

À retenir

C2Looper illustre l’évolution d’un backdoor HTTP relativement classique vers un implant plus flexible, capable d’utiliser des dépôts GitHub comme infrastructure opérationnelle. Ses fonctions de shell distant, de reconnaissance, de téléchargement et de mise à jour en font un point d’appui crédible pour des intrusions liées aux rançongiciels. Mais les éléments disponibles justifient une évaluation prudente, et non une attribution définitive.

La meilleure défense consiste à associer des habitudes de travail résistantes aux scénarios ClickFix à une détection comportementale : commandes inhabituelles, chargement de DLL par OneDrive, interrogations HTTP très rapides et activité GitHub inexpliquée.