Selon une publication technique signĂ©e par Pierre Le Bourhis (Sekoia.io), cette recherche dĂ©taille le fonctionnement dâOysterLoader (a.k.a. Broomstick/CleanUp), un loader C++ multiâĂ©tapes distribuĂ© via faux sites dâinstallateurs MSI signĂ©s, utilisĂ© dans des campagnes menant au ransomware Rhysida et Ă la diffusion de lâinfostealer Vidar.
â Aperçu et chaĂźne dâinfection (4 Ă©tapes)
Stage 1 â Packer/Obfuscator (TextShell) : API hammering massif (appels GDI/DLL sans but), rĂ©solution dynamique dâAPI par hachage custom, antiâdebug basique (IsDebuggerPresent â boucle infinie), allocation RWX et copie « mĂ©langĂ©e » du stage suivant. Structure interne « core » embarquant donnĂ©es compressĂ©es, API rĂ©solues et config. Stage 2 â Shellcode : dĂ©compression LZMA custom (enâtĂȘte et bitstream non standards), fixups de relocalisation (patch E8/E9), rĂ©solution dâimports via LoadLibraryA/GetProcAddress, changement des protections mĂ©moire puis saut vers le payload reconstruit. Stage 3 â Downloader : vĂ©rifications dâenvironnement (compte les processus et quitte si < 60 ; fonction de test langue russe non appelĂ©e ; mesures de timing), premier contact C2 via HTTPS avec enregistrement (/reg) et dĂ©guisement rĂ©seau (entĂȘtes x-amz-cf-id, Content-Encoding, UA « WordPressAgent » puis « FingerPrint »). RĂ©cupĂ©ration du stage suivant via stĂ©ganographie dans une icĂŽne retournĂ©e par /login, dĂ©cryptĂ©e en RC4 avec une clĂ© hardcodĂ©e ; dĂ©pĂŽt dâune DLL dans %APPDATA% et persistance par tĂąche planifiĂ©e (rundll32 DllRegisterServer, toutes les 13 min). Stage 4 â Core (COPYING3.dll) : rĂ©emploi de lâobfuscation (shellcode + LZMA custom), C2 HTTP clair (port 80) avec fallback sur 3 IPs, beacons et schĂ©ma JSON encodĂ© par Base64 non standard avec dĂ©calage alĂ©atoire (Mersenne Twister) et alphabet custom. Ăvolution rĂ©cente vers /api/v2/ avec init/facade et rotation dâalphabet fournie par le C2 (champ tk) ; empreinte enrichie (t11/t12 : liste des processus et PIDs). â DĂ©guisement, Ă©vasion et communication C2
...