Attackers are exploiting the Claude Code adoption wave. A six-stage fileless infostealer is being delivered through a poisoned search result to first-time developers who think they are following an installation guide. Here is everything you need to know.
Credit and original research: Cyderes Howler Cell
Why this campaign matters before we get to the technical details
Most malware campaigns target careless users or misconfigured systems. This one targets something different: enthusiasm.
Claude Code has opened software development to people who never thought it was accessible to them. A small business owner automating their invoicing. A teacher building a grading tool. An entrepreneur with an app idea and, for the first time, a realistic path to shipping it. These are the people this campaign is hunting. Not IT administrators ignoring security policy. First-time builders sitting down to install a tool they are genuinely excited about, following instructions that look completely legitimate.
The attacker did not need to trick a security professional. They needed to be at the top of a search result when someone motivated, trusting, and technically inexperienced went looking for a getting-started guide. SEO poisoning put them there. And unlike a corporate user, this audience typically has no proxy filtering, no endpoint detection, and no security team to call. What they have is a browser, a search engine, and instructions that look exactly like every other installation guide they have ever followed.
Cyderes Howler Cell identified and documented this campaign in full. What follows is a technical breakdown of their findings, with analysis of what makes this chain particularly dangerous and what defenders need to do about it.
The attack chain at a glance
The full delivery chain is six stages deep, entirely fileless after Stage 1, and engineered to defeat file inspection, AMSI, EDR telemetry, sandbox analysis, and static IOC matching simultaneously. Here is the sequence:
Initial access begins with an SEO-poisoned search result for "claude code install" leading to a spoofed Anthropic install page. The page looks right. The branding is convincing. The instructions feel familiar.
Execution happens through a ClickFix lure. The victim is instructed to open the Windows Run dialog using Win+R and paste a pre-staged mshta.exe command, framed as a required step to complete the installation. This is hands-on keyboard execution rather than automated drive-by delivery, which bypasses many endpoint controls that key on automated or scripted execution patterns. The victim complies because they have no baseline for what legitimate installation should or should not ask them to do.
Stage 1 sees mshta.exe retrieve an MP3/HTA polyglot payload from download.version-516[.]com, a software-update-themed lure domain designed to look like a routine update server.
Stage 2 has the HTA spawn cmd.exe, which runs an encoded PowerShell script performing three operations: an AMSI bypass, RC4 string decryption, and victim fingerprinting via an MD5 hash of the machine name and username.
Stage 3 downloads a second PowerShell script from a per-victim subdomain on oakenfjrod[.]ru, executed entirely in memory. The script is 17 MB, a size engineered deliberately to break analysis tooling.
Stage 4 delivers a reflective .NET infostealer that beacons to Russian infrastructure at 185[.]177[.]239[.]255:443 for credential exfiltration. Nothing is written to disk. No new process is spawned.
Before going deeper, one clarification that matters: Anthropic is not compromised. The legitimate Claude Code installation path is unaffected. This campaign is brand impersonation, not a supply chain attack.
Stage 1: The MP3/HTA polyglot and why it defeats file inspection
The payload retrieved by mshta.exe in Stage 1 is one of the more technically elegant evasion constructions seen in commodity malware recently. It is a 6.7 MB file that simultaneously satisfies the parsing rules of two completely different file formats: MP3 and HTA.
The file carries a valid ID3v2.4 tag, embedded JPEG cover art, and playable MPEG audio frames occupying the first approximately 4.7 MB of the file. It is a real, playable MP3. Open it in VLC or Windows Media Player and it plays. A security tool that classifies files by header, magic bytes, or content inspection will see a legitimate MP3 and move on.
When mshta.exe processes the same file, it parses linearly. It moves past the audio content, reaches the embedded HTA script block at the end of the file, and executes it. The same bytes, two completely different runtime interpretations. Sandbox environments that open the file as media may deprioritise analysis entirely, which is precisely the intent.
This is the Living Off the Land principle applied at the file format level. The attacker is not hiding malicious code in an obviously suspicious container. They are hiding it inside something that looks like exactly what it claims to be.
Defender note: mshta.exe initiating outbound HTTPS connections to external infrastructure has no legitimate use in most enterprise environments. Blocking or alerting on mshta.exe network activity catches this stage regardless of payload obfuscation. MITRE technique: T1218.005.
Stage 2: AMSI bypass, RC4 decryption, and victim fingerprinting
The HTA registered a scheduled task through the Schedule.Service COM object to spawn cmd.exe with delayed-expansion enabled. The command line reconstructed the string "powershell" at runtime using split variables to break static signature detection, then explicitly invoked the 32-bit PowerShell binary at %windir%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe.
Targeting the 32-bit binary is deliberate. EDR telemetry coverage is frequently weighted toward 64-bit process activity. By invoking the 32-bit PowerShell host, the attacker reduces the likelihood of being captured in high-fidelity telemetry streams that a security operations team would be monitoring.
The PowerShell script executed a Base64-encoded payload that performed three sequential operations. First, an AMSI bypass: it patched System.Management.Automation.AmsiUtils.amsiInitFailed in memory via Marshal::WriteInt32, disabling in-process script scanning before any further stages are executed. This is a well-documented technique, but its effectiveness depends on the EDR not having already instrumented the AMSI interfaces at a lower level. Many commodity endpoints have not.
Second, RC4 string decryption: sensitive string constants were decrypted at runtime using the hardcoded key BWJFEesMEqRvjQbm, keeping indicators out of static analysis. Any analyst examining the script without executing it sees only ciphertext where the meaningful strings would be.
Third, victim fingerprinting: the script computed an MD5 hash of COMPUTERNAME concatenated with USERNAME to generate a unique subdomain label for the Stage 3 download URL. This fingerprinting step is the architectural foundation of the campaign's most effective IOC-defeating mechanism.
Defender note: 32-bit PowerShell spawned from a scheduled task registered via COM object is rare in enterprise environments and represents a high-confidence detection signal. MITRE techniques: T1059.001, T1562.001, T1027.
Stage 3: The 17 MB obfuscation fortress and per-victim infrastructure
Stage 2 used the MD5 victim fingerprint as a subdomain label to construct a unique retrieval URL in the format https://MD5_HASH.oakenfjrod[.]ru/cloude-uuid. The loader issued an HTTPS GET request to this URL and piped the response directly into IEX for in-memory execution, inheriting the AMSI-disabled state from Stage 2. Nothing was written to disk.
The retrieved Stage 3 script is approximately 17 MB. This is not accidental. Legitimate PowerShell loaders are typically under 100 KB. The size here is engineered as a weapon against the analysis pipeline itself.
Automated deobfuscators have memory and time limits. Sandbox environments have resource constraints. Human analysts have finite patience for unwinding nested obfuscation layers at 17 MB of scale. The size is a deliberate tax on the defender's analysis capability, designed to make full deobfuscation expensive enough that many analysts will give up or accept a partial result.
The obfuscation layers stacked inside this script are comprehensive. Massive integer-encoded byte arrays that must be reconstructed before any logic surfaces. Multi-layer string fragmentation using split-and-concatenate chains and character-code substitution. Runtime variable name mangling with identifiers reassigned dynamically to break cross-references between analysis passes. Stacked Base64 and RC4 decryption layers that must be unwound in the correct sequence. A third XOR layer using the key AMSI_RESULT_NOT_DETECTED, a detail worth pausing on: the attacker used Microsoft's own AMSI bypass indicator string as a decryption key, which is either a deliberate provocation or a functional choice that also serves as a signature-defeating red herring. And finally, the reflective .NET shellcode carried inline as a byte array, removing the need for any additional network fetch at this stage.
The per-victim subdomain structure deserves particular attention from a threat intelligence perspective. Every victim gets a unique URL derived from their machine name and username. Static IOC sharing at the URL level is therefore functionally useless. Sharing the URL a specific victim connected to does nothing for the next victim, because their URL will be completely different. The only meaningful IOC at this layer is the domain itself: oakenfjrod[.]ru. Wildcard blocking on that domain is the correct defensive response, not per-subdomain matching.
Defender note: DNS queries to *.oakenfjrod[.]ru are a strong indicator of compromise. Block and alert at the domain level. Per-subdomain IOC matching is ineffective by design. MITRE techniques: T1568, T1620.
Stage 4: The reflective .NET infostealer and what it takes
The terminal stage is a .NET-based infostealer delivered as raw bytes embedded inside the Stage 3 PowerShell script. It is never written to disk. It never loads as a module. It never spawns a child process. The entire stealer executes inside the existing powershell.exe address space.
The loading technique abuses the .NET Framework's built-in ability to execute managed code directly from a byte array in memory via Assembly.Load(byte[]). This is functionally equivalent to techniques used by Cobalt Strike's execute-assembly, Donut, and SharpSploit, but executed entirely from PowerShell without an unmanaged loader stub. The consequence for defenders is significant: there is no file artifact on disk, no new process entry in the process tree, and no image-load event tied to a suspicious file path. The traditional tripwires that defenders have built detection around simply do not fire.
The infostealer beacons over HTTPS to 185[.]177[.]239[.]255:443 for command and control and credential exfiltration. The IP resolves to Russian infrastructure. SensitiveFileRead telemetry from Cyderes Howler Cell's analysis confirms browser credential store access during execution, meaning the stealer is actively harvesting saved passwords, session tokens, and authentication cookies from the victim's browser profiles.
Defender note: .NET assembly loads from PowerShell without a corresponding file on disk are detectable via ETW (Event Tracing for Windows) and process memory inspection. EDR platforms with .NET assembly load visibility catch this where file-based controls cannot. MITRE techniques: T1620, T1555.003, T1041.
The full MITRE ATT&CK mapping
T1204.003 User Execution via ClickFix: Win+R paste of attacker-supplied MSHTA command triggering hands-on keyboard execution.
T1218.005 Signed Binary Proxy via mshta.exe: mshta.exe fetched and executed a remote HTA payload disguised as an MP3 file.
T1059.001 PowerShell: Base64 and RC4-obfuscated encoded commands across multiple stages.
T1027 Obfuscated Files or Information: RC4 encryption of sensitive string literals, integer-encoded byte arrays, and runtime variable mangling.
T1562.001 Impair Defenses via AMSI Bypass: Marshal::WriteInt32 used to set amsiInitFailed via reflection, disabling in-process script scanning.
T1620 Reflective Code Loading: Reflective .NET stealer loaded entirely in memory via Assembly.Load(byte[]), leaving no file artifact.
T1071.001 Application Layer Protocol via HTTPS: C2 communications on port 443 across all stages, blending with legitimate encrypted traffic.
T1568 Dynamic Resolution: Per-victim C2 subdomain derived from MD5(COMPUTERNAME+USERNAME), making static IOC sharing ineffective.
T1555.003 Credentials from Browser: SensitiveFileRead events confirm browser credential store access during final stage execution.
T1041 Exfiltration Over C2 Channel: Harvested credentials exfiltrated to 185[.]177[.]239[.]255.
Indicators of compromise
Domain: download.version-516[.]com - HTA payload delivery, fake Claude download site
Domain: oakenfjrod[.]ru - Stage 3 C2, block as wildcard *.oakenfjrod[.]ru
IP: 185[.]177[.]239[.]255 - Final stealer C2, Russian infrastructure
URL pattern: https://[md5_16char].oakenfjrod[.]ru/cloude-[uuid] - Per-victim beacon URL structure, unique per machine
What makes this campaign notable and what to do about it
The operators behind this campaign did not rely on a single trick. They stacked deliberate evasion choices end-to-end and produced a chain where each traditional detection surface has been accounted for at the design stage. The MP3/HTA polyglot defeats file-type filtering. The 32-bit PowerShell invocation reduces EDR telemetry coverage. The AMSI bypass clears the path for in-memory execution. The 17 MB Stage 3 script is sized to break analysis tooling and exhaust sandbox resources. The per-victim subdomain structure neutralises static IOC sharing. The reflective .NET final stage leaves no file, no new process, and no image-load artifact.
What is notable is not the novelty of any individual technique. Each component is documented and understood by the security community. What is notable is the targeting logic: a rapidly growing population of non-technical users with high motivation, low threat awareness, and a search engine that, for a moment, put the attacker exactly where a legitimate download page should have been.
For defenders, the actionable steps are clear. Block mshta.exe outbound network connections at the endpoint level. Alert on 32-bit PowerShell spawned from scheduled tasks registered via COM objects. Apply wildcard DNS blocking on oakenfjrod[.]ru immediately. Deploy EDR platforms with ETW-based .NET assembly load visibility. And brief non-technical users in your organisation who may be using AI development tools: if an installation guide asks you to paste a command into the Windows Run dialog, stop and verify before proceeding.
For the broader security community, this campaign is a preview of what commodity malware targeting AI-tool adopters will look like as the developer population expands. The attack surface is growing faster than the security awareness of the people being added to it. Campaigns like this one are a direct consequence of that gap.
Full technical research and IOC details by Cyderes Howler Cell. Subscribe to their research feed for ongoing infrastructure tracking and updates as this campaign evolves.
MITRE ATT&CK techniques referenced: T1204.003, T1218.005, T1059.001, T1027, T1562.001, T1620, T1071.001, T1568, T1555.003, T1041
No comments:
Post a Comment