A sophisticated C++-based loader, also tracked as Broomstick and CleanUp, evades detection through layered obfuscation and dynamic payloads.
First spotted in mid-2024, it spreads via fake sites that mimic tools like PuTTY and WinSCP, often paving the way for Rhysida ransomware or Vidar infostealers. Into early 2026, its evolving code and C2 infrastructure keep it a persistent threat for Windows environments.
Infection Chain Overview
OysterLoader deploys via signed MSI installers that trigger a four-stage process starting with memory-resident execution to dodge disk forensics.
Stage 1: uses the TextShell packer to shuffle and inject shellcode, flooding the code with irrelevant GDI and Win32 API calls, such as CreateSolidBrush and SetMapMode, to confuse heuristics and sandboxes.
These “API hammering” tactics produce noisy decompilations while hiding core operations, such as RWX memory allocation via NtAllocateVirtualMemory.
Dynamic API resolution adds variability: each sample hashes functions using unique algorithms, such as h = (h * 0x2001 + ord(ch)) & 0xFFFFFFFF, thereby thwarting static signatures.
Basic anti-debug checks, such as IsDebuggerPresent(), can lead to infinite loops and further stall analysts, making them easy to bypass but effective against automated tools.
Decompression and Relocation
Stage 2: shellcode starts with a custom LZMA decoder that mimics standard range coding but uses non-standard headers and bitstream tweaks.
This breaks tools like 7-Zip or Python’s lzma module because properties are stored at custom offsets rather than the usual 13-byte header.
Post decompression, it scans for E8/E9 opcodes to fix CALL/JMP relocations, resolves imports via LoadLibraryA/GetProcAddress, and flips protections with VirtualProtect before jumping to the entry point.
The shellcode relies on a shared “core” struct from Stage 1 to pack compressed data, configuration blobs, and pointers to essentials like InternetOpenW. This position-independent design ensures reliability across memory layouts.
C2 Infrastructure Evolution
Environment Checks and Initial C2
Stage 3: runs environment probes: it bails if fewer than 60 processes run, creates mutexes like “h6p#dx!&fse?%AS!”, and tests timing with looped Beep/Sleep calls to spot hooks. It skips Russian localized systems via unused code remnants and verifies keyboard layouts.
C2 starts over HTTPS to /reg with the WordPressAgent UA, sending random IDs in the x-amz-cf-id and Content-Encoding headers.
Success triggers /login using FingerPrint UA; the response hides Stage 4 PE in an ICO file via steganography: a size byte, junk image, “endico” marker, then RC4 decryption with a fixed-length key.
The DLL (e.g., COPYING3.dll) is dropped to %APPDATA% and persists via schtasks, running rundll32.exe #path# DllRegisterServer every 13 minutes.
Core Payload and Evolving C2
Stage 4: the DLL’s DllEntrypoint repeats LZMA unpacking, then beacons unencrypted over port 80 to fallbacks like 85.239.53.66.
JSON payloads use custom Base64 (alphabet: yog/N3fj5ISmbep=Wu2k+BZcP0t4CYR1dQxHUaXEwGDKJV7i9ML6snhzrlqO8vAFT) with Mersenne Twister-shifted encoding per message.
Check-ins (/api/kcehc) exfil system info (username, OS build, domain); beacons (/api/jgfnsfnuefcnegfnehjbfncejfh) fetch Base64 payloads.
Recent 2026 updates overhaul this: /api/v2/init GET, /api/v2/facade POST with process/PID lists in t11/t12 fields, and dynamic beacon paths like /api/v2/YgePIY5zPSoGUjzRx7C50MTx6EzABXIPd.
C2 supplies “tk” for new alphabets mid-session, using WinINet with Chrome UA spoofing.
Current domains include grandideapay[.]com and nucleusgate[.]com on /api/v2/facade, with delivery servers handling /reg/login stego. This tiered setup provides static delivery, and dynamic C2 sustains operations amid takedowns.
Site: cybersecuritypath.com
%20(1).webp "Technitium: Self-Hosted DNS Server for Enhanced Privacy and Security")
.webp "Cal.com’s Access Control Mess: How It Let Attackers Hijack Accounts and Dump Millions of Bookings")
