Inside FakeAgent: How a Claude Desktop Malvertising Campaign Hit 29 Organizations with SectopRAT

Update: We have updated the malware attribution for this blog to SectopRAT due to the presence of HVNC in the .NET payload after closer inspection of the related Command and Control services revealed in the Ethereum BSC transactions.

Background

Between July 21 and July 22, 2026, Huntress' Security Operations Center (SOC) lit up with a swathe of unusual executable installs, Defender exclusions, and anomalous persistence across 29 organizations, all coming from ClaudeDesktop.exe. The attacks had one common denominator: victims had searched for the Claude desktop app and were taken to a malicious public Claude Artifact on the actual Claude AI domain, which appeared to be a legitimate download link for the desktop app.

Our deeper investigation into the attacks revealed a frustrating anti-analysis technique, command-and-control (C2) data stored in the Ethereum blockchain, and at its core, SectopRAT, a remote access trojan (RAT) that siphons off user credit card data, personal information, files, and passwords. We have titled this campaign FakeAgent, for what we believe to be self-evident reasons: the use of Claude to host the malicious loader as a Claude Artifact, and the use of Claude Desktop itself as the masquerading application.

On our end, the analysis of this attack was partially aided by Claude itself. Some reimplementation details, specifically regarding AES and SM5 emulation, were rolled out via Claude Opus 4.8. We think these details are important to disclose, for both transparency, and to be clear where LLM integrations give us an advantage as cyber defenders.

Analysis

Initial Access

SEO poisoning and malicious paid advertisements have been a thorn in the side of cybersecurity practitioners for some time now. This attack is no different. The user performed an innocuous Bing search for  "CLAUDE DESKTOP APP". As shown in Figure 1, the sponsored results were filled with fake pages pretending to offer Claude Desktop. However, mixed in with those results was a sponsored link to the legitimate Claude.ai domain. 

A closer look at that sponsored link showed something more sinister. Instead of sending the user to a normal page, the ad pointed to the public artifact hosted on Claude.ai. Public artifacts are documents or files that users or large language models can create, upload, and share publicly. They are often used to show simple proof-of-concept content, such as a one-page website, chart, or image.

Figure 1: Bing search results with several malicious sponsored advertisements, including the Claude.ai hosted public artifact.

In this case, the victims are taken from Bing Search to a public artifact hosted at claude[.]ai/public/artifacts/ca456f1f-44c0-42af-b329-4f1c7534a877. Claude indicates in a disclaimer in Figure 2 that it posts across all its artifact pages: "Content is user-generated and unverified." We reported the artifact for takedown to help disrupt the distribution of this malware; it has since been removed by Anthropic.

However, before removal, the malicious artifact link had 7,100 page views.

Figure 2: Claude Desktop/Cowork phishing page hosted as a Claude artifact.

This user-generated artifact masquerades as a legitimate Claude Desktop installation, but redirects the user to an external domain when clicking the "Download" button. Specifically, they are sent to claude.ai.download-app[.]us (registered May 9, 2026) and subsequently to downloading-api.it[.]com/html/claude/win. 

At this point, the user is served with a malicious ClaudeDesktop.exe file, which they unknowingly download and execute, with disarmed trust given the legitimate Claude.ai domain they originally obtained it from.

Into the Malware

ClaudeDesktop.exe & DockerDesktop.exe

The primary executables are ClaudeDesktop.exe and DockerDesktop.exe. These are identical: one serves to download and stage the initial payload (ClaudeDesktop.exe) and the other (DockerDesktop.exe) is written to disk as a persistent scheduled task to repeatedly reinfect the computer.

Figure 3: ClaudeDesktop.exe process details.

It's worth noting that ClaudeDesktop.exe is not actually ClaudeDesktop.exe, but instead a component of JetBrains' jcef_helper.exe, a Chromium Embedded Framework application. 

This application is vulnerable to a technique known as DLL sideloading.

A brief aside on DLL sideloading

DLL sideloading is a technique whereby a malicious, tampered dynamically linked library (DLL) can be co-located within the search path of the application. These DLLs typically contain code that is imported and executed by the parent executable. By maliciously modifying that function in the DLL, an adversary can achieve execution in the context of a trusted and signed executable.

With this in mind, our actual payload lives in the DLL that is located next to the malicious application (libcef.dll). This is a DLL typically found with the Chromium Embedded Framework (hence CEF) and by itself is not cause for alarm.

However, the hash for this file does not match public records, and thus, we can conclude that an adversary has likely tampered with it.

Upon examination of the libcef.dll binary, we note a few unique things about our malware: 

• It's been packed with VMProtect, a commercial software protection tool that attackers have abused to make their malware notoriously difficult to reverse. 

• It has references to an Ethereum contract (0xc1907d7be91f95903ad66d775c397302e7dd9228)

VMProtect is genuinely problematic as it makes malware analysis much slower and more resource-intensive for defenders, so we explore the Ethereum contract to begin with. In this case, the Ethereum contract referenced by the binary has no balance, but instead the function calls can be traced to ultimately downloading and executing a payload stored at cache.dat, which appears to subsequently install the secondary component of this malware, the RAT itself. 

This act of storing command-and-control information in the Ethereum blockchain is a known tactic called "EtherHiding" that has been taking malware development by storm. It is essentially a resilient command-and-control address: by simply posting a new transaction to the Ethereum address, an adversary can trivially rotate their command-and-control services in a manner that is difficult to take down or disrupt. The purpose of these Ethereum contracts is not to contain/move cryptocurrency funds, NFTs, or code representations of some transaction; but to provide a take-down resilient means to allow malware to shift its command and control service.

By calling the Ethereum contract, we're given an encrypted response back, with no apparent way to decrypt it. Recursing through the binary, we can see that the application enters the VMProtect section shortly afterwards, and we're left with a dead end. What was the command and control? What details were being fetched from the Ethereum contract? Faced with the reality of having to work through VMProtect obfuscation or difficult dynamic analysis procedures, we move on to the other payload observed on the host.

Unmasking the RAT

An additional persistence mechanism was written to %APPDATA\Roaming\Microsoft\EdgeUpdate\Install\sslconf.exe, so we can explore this next.

Sslconf.exe is once again a signed application—in this case, an IBM SPSS binary. IBM SPSS is a statistical analysis platform; so another legitimate and unremarkable application that's widely used in many verticals. 

However, our adversary is a fan of patterns. Upon further investigation, we found that the actor once again used DLL sideloading, this time via the sideloading vector  tempdir.dll. This file is also maliciously modified by the adversary, and this time it doesn't pack VMProtect. 

However, it implements several protections that, themselves, are incredibly difficult to overcome. Chief amongst them is the fact that tempdir.dll implements a GPU anti-VM gate. This is an anti-analysis technique where malware checks the graphics hardware on a system before deciding whether to actually execute its malicious payload. By examining the DirectX Graphics Interface (DXGI) adapters on the host and looking for values such as 0x1234 (QEMU), 0x15AD (VMWare), etc., the adversary is able to defeat common analysis platforms.

The attackers also look for limited VRAM (Video RAM) allocations (below 1GB) and perform a small compute shader timing check. Limited VRAM allocation is typically a reliable signal that they could be running inside a virtual machine or sandbox rather than on a real victim's physical computer. If this finishes exceptionally fast, which may be the case in emulation, the malware fails to execute. 

This isn't the only graphical interaction with this malware though. In fact, the entire payload was stored on disk as appcfg.dat. Traditionally, we would grab the decryption routine from the malware and run it across the payload, but our adversary has thought ahead. 

The malware's decryption routine isn't a typical CPU-based decryption routine: instead, it is a compiled DirectX shader that is executed on the payload, delegating payload decryption to the DirectX graphics interface (commonly a graphics card.) 

While CPU-based decryption routines typically call crypto APIs or custom algorithms to decrypt into memory—which is easily caught by defenders who can hook crypto API calls and scan the process memory for suspicious unpacked code—GPU/shader-based encryption doesn't use the typical instruction set, and standard reverse engineering toolkits do not handle decompilation of this codebase well. It is essentially abstracted to us, very similarly to the VMProtect payload. The malware does some blackbox magic, and credentials are exfiltrated.

We're faced with a fork in the road now: 

• Reverse the VMProtected code

• Look to emulation platforms to try and achieve deobfuscation

• Implement our own SM5 bytecode interpreter and emulate the raw shader function

None of these seem particularly appetizing, but our own SM5 interpreter was the route we opted to chase, with the aid of our trusty Claude integrations.

Using Claude for AI-assisted analysis

We set Claude to task, which immediately began by extracting the DirectX Binary Container (DXBC) file. The file was notably quite large: 26,536 bytes for a simple decryption scheme. This means more than just the crypto-algorithm was embedded.

Peeling it back a bit, we recovered the Rijndael S-box stored within the shader, as well as the key materials. Walking the binary, we were unable to identify any known crypto-algorithms. We initially explored ChaCha20 as a likely case; but this was quickly dismissed with the baked-in tables, which then pointed us to AES-256-CTR. 

We recovered the AES forward S-box and the AES Rcon sequence for key expansion, and set to work essentially reimplementing AES to decrypt this without the aid of a GPU. By setting up an oracle, or a decryption piece we can try repeatedly against, we were able to repeatedly validate our assertions of a 'correct' key against the oracle and achieve decryption. 

With some steering, we guided Claude into a successful derivation of the AES-256 key and nonce, as well as all relevant cryptographic material. And we politely asked it to levy those to decrypt the payload. It tried OpenSSL and… it failed. LLMs can often introduce bugs or issues with the code, and cryptography is quite precarious, so it's not out of the question that AI-aided analysis made a mistake at some point in the line.

Figure 4: Claude self-documentation for tempdir.dll SM5 emulation; validates correct understanding of AES-256-CTR modifications against AES oracle to recover AES cryptomaterial.

However, manual cross-checking and reimplementation of particularly opaque parts deriving key traits from the GPU shader still resulted in a failure to decrypt the payload. The SM5 decryption had only parsed several portions of the application, we needed a more realistic implementation. Claude is set to task once again to achieve results.

Figure 5: Claude is giving up on us.

Claude returned and bluntly delivered the news: we've achieved the boundary of what's achievable here. We've reimplemented a more robust SM5 bytecode interpreter, and even discovered why decryption didn't particularly work; the shader uses a non-standard MixColumns function, so a more complete SM5 emulation was fruitful, but ultimately did not result in decryption. 

We drop our analyst hats and put on our engineering hats. When things aren't working and you've checked everything relevant, instead examine your assumptions. We create a DirectX shader ourselves to test our application, and it passes, our SM5 implementation is correct. Something in our assumptions upstream is incorrect.

The answer is painfully simple with some manual analysis. We've transcribed the AES key incorrectly. Within the key, a single byte was incorrectly copied as 0x68 instead of 0x6b. This one-byte error drove our inability to decrypt, even with the fixed Row 3 operation derived from bytecode emulation. If you've ever doubted it, this is the importance in the human-in-the-loop equation.

Figure 6: Claude celebrated, we celebrated, and I think I heard applause from my MacBook speakers.

With this, we're able to decrypt appcfg.dat statically on disk (without the use of the shader directly) simply by reimplementing the specific AES-256-CTR algorithm with the slight modification of the Row 3 MixColumns function.

Cracking the Egg

Before we get into this section, I want to remind the viewer of the nuance here: we do not have the command and control yet from the binary. We don't even know what it does beyond what we've asserted here. 

With this in mind, we set to examining appcfg.dat, freshly decrypted by Claude. Within the nonsense we are able to carve out both a standard PE file, as well as a .NET assembly. With some hypothesizing about what this means, the .NET assembly holds the bulk of our loot. 

Booting up ILSpy, a common .NET decompiler, we are immediately inundated with a heavily obfuscated .NET payload. Plaintext strings include references to browser logins, cookies, autofills, credit cards, chromium key theft, FTP, Discord, messaging clients, etc.

However, the command and control service is still obfuscated, so we're not out of the woods yet—though we have a good idea of what this malware is: SectopRAT. We can triangulate this based on the exposed strings, targeted data, and behaviors. If not a direct implementation of commodity SectopRAT, it is an unremarkable fork of the SectopRAT family.

Without the command-and-control, however, we're stuck. VMProtect still holds the keys for our command-and-control if we climb back to our earlier analysis, and the .NET payload is also heavily obfuscated. .NET is much easier to work with though, so we hypothesized: "If the adversary used Etherhiding once, they might use it again?" And we began to look for Etherhiding characteristics in the .NET payload.

We hit paydirt.

Burning at Both Ends

We immediately located the HttpClient behavior within the decompiled binary—woefully obfuscated, but discernable; with some variable references that let us climb up to view the configuration structure. 

Figure 7: Employing the critically useful skill of Ctrl+F'ing for common function names.

We set Claude to task decrypting and deobfuscating all relevant strings, and generally tracing control flow with our noted HttpClient as the anchor and achieved a faithful representation of the code. It's important to note that this is not a "conventional" deobfuscation; instead the LLM has created its interpretation of what the function looked like based on its understanding of the encryption/obfuscation. This isn't dramatically different from the Intermediate Languages that reverse engineering platforms such as BinaryNinja utilize.

Figure 8: Deobfuscated LLM representation of embedded .NET code. 

With this in hand, we finally have our loot, the Ethereum contract, and the means to decrypt it; and we're given the live command-and-control (C2) address: 2.24.131[.]246, and we've surmounted the Matryoshka malware nesting present in this campaign.

Operational Security Gone Wrong

Within our analysis, we pivoted on several fields using a combination of public WHOIS records and the Validin intelligence platform. We were able to identify the email address used to register the malicious download-app[.]us before the hosting provider redacted the user's personal details.

Figure 9: Validin results indexing the individual's email address across various phishing and malware distribution sites.

Validin successfully indexed 10 distinct domains registered with this same email address, extending back to December 2025. Further to this, we noted that at least one site hosted with this email address was seized by Microsoft as part of Operation Endgame, a joint international effort to disrupt malware distribution and command and control services. Specifically, the domain polse[.]us was identified by Microsoft as hosting StealC stealer malware.

Huntress analysts triangulate this user to a campaign we internally tracked in April 2026, where the same individual utilized Docker Hub to distribute a fake Docker Desktop install with similar tactics, utilizing libcef.dll sideloading to distribute malware under the guise of a legitimate Docker install from a trusted domain.

By examining the Ethereum BNB Smart Chain (BSC) transactions for the addresses listed, the command-and-control that we've identified in this attack extends far beyond the current event, back to an initial transaction date of 2025-05-30.

Figure 10: Ethereum BSC transactions against one of the two addresses listed; all containing command-and-control services.

Because we now possess the cryptomaterials for their BSC transactions, we can fully decrypt all C2s historically used by the operator. We've provided this list below the IOCs section, as they can likely be attributed to other campaigns, and differ from our primary scope of analysis.

Conclusions

When we talk about "AI-accelerated" attacks, what we often mean is agentic attacks or LLM-generated scripts being utilized in an attack. However, at an entertaining face value, the attack we observed in this blog is also AI-accelerated, but with an interesting twist. As users increase their pursuit of AI tools, AI provider websites make ripe targets for malvertising and in some cases, even malicious hosting themselves. What does that mean for users who want to protect themselves?

• Do not trust top-level domains implicitly. A legitimate Claude.ai link served this particular malicious link. This campaign is becoming strikingly common. 

• Use exceptional caution when utilizing search engines. The paid malvertising/SEO poisoning is a well-documented and long-running attack. 

• AI/LLM tools are powerful. They're equipping attackers with advanced methods of malware distribution and new attack facets, but they're also equipping defenders to deal with more complex threats and understand attacks more viscerally. 

Primary IOCs

Extracted C2 Addresses