OysterLoader, also tracked as Broomstick and CleanUp, is a multi‑stage loader malware written in C++ and actively leveraged in campaigns linked to the Rhysida ransomware group.
First highlighted in mid‑2024 during malvertising and SEO‑poisoning campaigns abusing trojanized installers for popular IT tools such as PuTTY, WinSCP, and Google Authenticator, OysterLoader masquerades as legitimate software download packages to gain initial access on victim systems.
Once executed, it establishes a stealthy foothold that can ultimately deliver Rhysida ransomware or commodity info‑stealers like Vidar, extending its impact beyond a single ransomware operation.
Security researchers note that Rhysida operators, associated with the broader WIZARD SPIDER/Vanilla Tempest ecosystem, have heavily invested in this tool, using dozens of fraudulent code‑signing certificates and malicious ad infrastructure to repeatedly re‑launch campaigns even after prior certificates are revoked.
OysterLoader’s loader‑as‑a‑service profile remains ambiguous: while it is clearly favored in Rhysida‑linked operations, evidence also shows it installing other payload families, suggesting it may circulate within a closed criminal ecosystem rather than being exclusive to a single group.
OysterLoader Evasion Tactics
Malware analysis shows OysterLoader relies on a four‑stage infection chain starting from a seemingly benign Microsoft Installer (MSI) package that is often legitimately signed to bypass basic trust checks.
The malware code is encapsulated with legitimate calls, sometimes, only the prologue of the function is filled with DLLs calls.
Stage 1 acts as a packer/obfuscator, loading the next stage from a “shuffled” blob in memory using RWX allocations, while aggressively flooding execution flow with superfluous Windows API calls such as GDI functions to generate noise and mislead static and heuristic engines.
These calls do not materially change system state but complicate decompilation, while a simple IsDebuggerPresent check that drops into an infinite loop if a debugger is detected adds low‑grade but effective anti‑analysis friction.
A custom dynamic API resolution routine using per‑sample hashing further hides real dependencies from static scanners and signatures.
Stage 2 consists of shellcode that consumes a shared “core” structure from the first stage and immediately pivots into a custom LZMA‑like decompression routine.
After decompression, the shellcode walks the buffer to fix CALL/JMP relocations, dynamically resolves imports via LoadLibraryA/GetProcAddress, flips memory protections with VirtualProtect, and then jumps into the reconstructed intermediate payload.
Stage 3 operates as a downloader and environment verifier, performing checks on language and process count before talking to the first C2 layer.
Earlier variants use HTTPS endpoints like /reg and /login with spoofed headers (including a WordPress‑themed user agent and custom x‑amz‑cf-id and Content‑Encoding fields) and hide the next stage inside an image/x‑icon response using steganography and RC4 with a hardcoded key.
Once decrypted, the resulting PE is dropped under names such as COPYING3.dll in %APPDATA% and scheduled via schtasks to run periodically using rundll32, providing persistence while varying file and task names across campaigns.
Rhysida Ransomware
The final stage, implemented as a DLL core, switches to a plain‑HTTP C2 protocol over multiple hard‑coded IPs and, in more recent versions, domain‑based infrastructure with evolving API paths.
Instead of using a standard LZMA header and bitstream, the developers implemented their own header layout and subtle format changes, preventing off‑the‑shelf tools such as 7‑Zip or typical lzma libraries from unpacking the payload directly.
Initial variants relied on /api/connect and /api/session, later moving to /api/kcehc and /api/jgfnsfnuefcnegfnehjbfncejfh, and by late 2025 transitioning again to /api/v2/init, /api/v2/facade, and long random beacon paths such as /api/v2/YgePIY5zPSoGUjzRx7C50MTx6EzABXIPd.
As of January 2026, active C2 infrastructure includes domains like grandideapay[.]com, nucleusgate[.]com, cardlowestgroup[.]com, socialcloudguru[.]com, coretether[.]com, and registrywave[.]com hosting /api/v2/facade, reflecting ongoing maintenance and rotation of backend servers.
OysterLoader’s command traffic is encapsulated in JSON where the main content field is further encoded using a non‑standard Base64 alphabet combined with a per‑message shift derived from a PRNG, forcing defenders to perform custom decoding to inspect payloads.
Newer builds enrich the system fingerprint with running process names and PIDs, and even allow the C2 to update the custom Base64 alphabet dynamically via a tk field in responses, raising the bar for static detection and long‑term signatures.
Combined with realistic browser user‑agents and multi‑server fallback logic, these features make OysterLoader a resilient loader platform.
For defenders, OysterLoader’s evolution underscores the need to monitor for signed MSI installers from untrusted download sources, detect abnormal GDI/API hammering behaviour, and hunt for its characteristic C2 paths and encoded JSON patterns on the wire.
Network and endpoint telemetry tuned to Rhysida‑linked malvertising, steganographic C2 exchanges, and the rotating /api/v2/* endpoints can significantly improve early detection of this loader before it hands control to ransomware or info‑stealer payloads.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
