Rhadamanthys Stealer Returns After Takedown

TL;DR — Unit 42 reported a fresh Rhadamanthys infostealer campaign that resurfaced days after a global law-enforcement takedown, delivered through a cloned RingCentral download page at rlngcentrel[.]com. The chain runs a 385,126,400-byte inflated dropper to defeat sandboxes, chains multiple layers of DLL side-loading (via Krita and BugSplat masquerades) into shellcode injected in svchost.exe, and communicates over RC4-encrypted C2 hidden behind Azure Front Door CDN redirectors.

About this analysis. This is a PhishEye Threat Research summary of findings published by Unit 42 (Palo Alto Networks) on 23 July 2026. All indicators are attributed to Unit 42 and defanged; PhishEye's contribution here is defensive analysis, not original discovery.

Why this campaign matters

Rhadamanthys is a mature, commodity infostealer sold under a malware-as-a-service model, and its operators have proven resilient. Unit 42's researchers documented a new campaign appearing shortly after a coordinated global law-enforcement takedown — a reminder that disruption of infrastructure rarely ends a well-resourced stealer operation. The rebuild leans on a familiar but effective phishing primitive: a typosquatted brand-impersonation site that hands victims a trojanized installer.

For defenders, the interesting part is not the stealer payload itself but the delivery engineering around it. According to Unit 42, this campaign stacks brand impersonation, an intentionally oversized dropper, layered DLL side-loading, UAC bypass via environment-variable manipulation, reflective PE loading, and cloud-CDN C2 masking into a single chain. Each layer is a deliberate defense-evasion choice, and each one maps to a specific detection opportunity.

Initial access: a cloned RingCentral download

Unit 42 reported that initial access begins with a webpage impersonating RingCentral, hosted at the typosquatted domain rlngcentrel[.]com/download/. The domain swaps the "i" in "ring" for an "l" and alters "central" to "centrel" — the kind of homoglyph-adjacent lure that reads as legitimate at a glance in a browser address bar or search result.

A visitor who clicks "Download ZIP for Windows" is routed through a PHP redirector (/file.php?src=download_win_exe), which delivers a malicious ZIP archive containing setup.exe to disk. Routing the download through a server-side redirector gives the operators a control point to swap payloads, geofence, or filter analysts without changing the visible download button.

Stage 1: the 385MB dropper

The parent process setup.exe side-loads an initial container DLL, dropped into either a generated Krita or BugSplat path. The standout tradecraft here, per Unit 42, is deliberate file inflation: the dropper is padded to 385,126,400 bytes — roughly 385 MB — specifically to exceed the file-size limits that many automated sandboxes and analysis pipelines impose. Many sandboxes silently skip or truncate very large samples, so the padding is a low-cost way to buy the payload a free pass through automated triage.

Once running, the dropper unpacks and writes all subsequent infection files — executables and malicious DLLs — to disk, setting up the side-loading that follows.

Stage 2: DLL side-loading via Krita and BugSplat

Unit 42's researchers documented two parallel side-loading pathways, each abusing a legitimate signed executable to load a malicious DLL of the same expected name:

• Krita masquerade. A dropped krita.exe is spawned and side-loads a malicious krita.dll. The DLL is obfuscated and resolves its APIs dynamically through PEB walking and djb2 hashing rather than a readable import table. Privilege escalation is achieved through a UAC bypass that manipulates an environment variable — setting HKCU\Environment\windir to c:\dell.
• BugSplat masquerade. A dropped BugSplatHD64.exe is spawned and side-loads BugSplat64.dll, which impersonates the well-known crash-reporting component and hides its logic in roughly 40 MB of .bss-section obfuscation. It performs the same environment-variable UAC bypass.

Side-loading against genuinely signed binaries lets the malicious code inherit the trust and reputation of Krita and BugSplat, frustrating signature- and reputation-based controls. Dynamic API resolution via djb2 hashing keeps sensitive calls out of static analysis.

Stage 3: reflective injection into svchost.exe

Whichever DLL loads, Unit 42 reported that it injects 64-bit assembly shellcode into svchost.exe. The shellcode is a reflective PE loader: it recovers its own base address, scans for MZ/PE signatures, resolves APIs such as VirtualAlloc and LoadLibraryA through PEB walking and djb2 hashing, and allocates PAGE_EXECUTE_READWRITE memory. It then maps and executes an embedded 3,017-byte PE32+ DLL. Running inside svchost.exe — a ubiquitous, expected Windows process — helps the C2 activity blend into normal host behavior.

Stage 4: RC4 config and Azure Front Door C2

Executing within svchost.exe, the payload initializes command and control. According to Unit 42, it extracts a 16-byte RC4 key, uses it to decrypt its embedded configuration, and parses server entries stored as 128-byte records. It then connects over a socket and establishes RC4-encrypted communication.

The infrastructure tactic is the notable part: the malware connects to Azure Front Door CDN domains acting as C2 redirectors. Unit 42 named two known endpoints, azure-h5acekaze0f7fhf8[.]z02[.]azurefd[.]net and azure-a8bqa7acbwf4dddv[.]z02[.]azurefd[.]net. Fronting C2 behind Azure Front Door masks the true backend server IP and blends malicious traffic with legitimate Microsoft cloud infrastructure, so simple IP or domain reputation blocking is far less effective — the traffic terminates at Microsoft-owned edge nodes.

Stage 5: command dispatch

Once the encrypted channel is live, the implant awaits instructions. Unit 42 documented a compact command set keyed by numeric opcode:

• cmd 10 — keepalive
• cmd 21 — data transfer
• cmd 32 — process execution
• cmd 33 — file operations
• cmd 50 — system information collection
• cmd 8993 — extended operations

This gives the operator credential and data theft (Rhadamanthys' core purpose), arbitrary process execution, file manipulation, and host reconnaissance — a full remote-operations toolkit on top of the stealer function.

What defenders should do

• Block and monitor the typosquat. Add rlngcentrel[.]com and the listed .click domains to blocklists, and hunt for the string patterns of the cloned RingCentral download path (/download/, /file.php?src=download_win_exe) in web proxy and DNS logs.
• Treat brand-impersonation typosquats as an active control. RingCentral-adjacent lookalike registrations should be surfaced through continuous domain monitoring so a cloned download page is caught at registration or first resolution, not after a user installs setup.exe.
• Alert on DLL side-loading from user-writable paths. Flag krita.exe or BugSplatHD64.exe (and same-named DLLs) executing from unexpected, generated, or user-profile directories rather than legitimate install locations.
• Monitor the UAC-bypass primitive. Watch for modifications to HKCU\Environment\windir — legitimate software has no reason to redirect it to a path like c:\dell.
• Detect injection into svchost.exe. Hunt for svchost.exe processes spawned outside services.exe, RWX memory allocations, and unexpected outbound sockets from svchost.
• Do not treat Azure Front Door domains as inherently safe. Inspect z02[.]azurefd[.]net traffic for the specific endpoints Unit 42 named and profile beaconing behavior rather than relying on domain reputation.
• Raise sandbox size ceilings where feasible. Samples engineered above common size limits — here roughly 385 MB — should be routed to manual or extended analysis instead of silently skipped.

Indicators (attributed to Unit 42, defanged)

Defanged; re-fang by replacing [.] with . — these are live/known-malicious, handle in isolation.

# Delivery / typosquat domain (Unit 42)
rlngcentrel[.]com

# Additional domains (Unit 42)
8eh18dhq9wd[.]click
8nioqhxciwoqc[.]click
8fnuawbfuac[.]click

# Azure Front Door C2 redirectors (Unit 42)
azure-h5acekaze0f7fhf8[.]z02[.]azurefd[.]net
azure-a8bqa7acbwf4dddv[.]z02[.]azurefd[.]net

# SHA256 file hashes (Unit 42)
# krita.dll
9b0e4e6aa169eb51ffc127edd62afb405bffa8ac74172f0df256ffffa028cb9e
# BugSplat64.dll
cbb4b70bdd1c8f892a234574290123bb7c69eaae934c9a4975affac75fa6c9d3

Totals: Unit 42 published six domains (one delivery typosquat, three .click domains, two Azure Front Door C2 redirectors) and two SHA256 hashes. All indicators above are reproduced from Unit 42's report.

Sources

• Unit 42 (Palo Alto Networks), "Rhadamanthys infostealer" activity post, LinkedIn, 23 July 2026: https://www.linkedin.com/posts/unit42_rhadamanthys-infostealer-activity-7486492056039763968-UbMW/
• Unit 42 Intel (@Unit42_Intel), X/Twitter, 23 July 2026: https://x.com/Unit42_Intel/status/2080726419093454877
• Research authors: Jonny Westfall and Cameron Martin, Unit 42.

FAQ

What is Rhadamanthys? Rhadamanthys is a commodity infostealer sold as malware-as-a-service. Unit 42 observed this new campaign shortly after a global law-enforcement takedown of related infrastructure.

How does the campaign infect victims? Unit 42 reported that a cloned RingCentral download page at rlngcentrel[.]com serves a ZIP containing setup.exe through a PHP redirector; running it triggers a multi-stage DLL side-loading chain.

Why is the dropper 385MB? The dropper is deliberately inflated to 385,126,400 bytes to exceed common automated-sandbox file-size limits, so many analysis pipelines skip it. Raising sandbox size ceilings helps counter this.

How does the malware hide its command-and-control traffic? According to Unit 42, it fronts RC4-encrypted C2 through Azure Front Door CDN domains, masking the real backend IP and blending with legitimate Microsoft cloud traffic.

What should defenders prioritize? Block the named domains, monitor for DLL side-loading from user-writable paths, alert on HKCU\Environment\windir changes, detect injection into svchost.exe, and inspect the named Azure Front Door endpoints.

---

About the authors

PhishEye Threat Research analyzes phishing and digital-risk campaigns to help defenders act on emerging threats. This article summarizes and adds defensive context to research originally published by Unit 42 (Palo Alto Networks) on 23 July 2026 by Jonny Westfall and Cameron Martin; all indicators, figures, and technical findings are attributed to Unit 42. PhishEye's contribution is analysis and defender guidance, not original discovery.