OpenClaw ClickFix campaign shows how browser credentials get stolen

At a glance

What this is: This threat research dissects a spoofed OpenClaw campaign that uses ClickFix, DLL sideloading, and browser credential theft to exfiltrate data through HTTPS.

Why it matters: It matters to IAM and security teams because browser sessions, tokens, and stored credentials are identity assets, and this chain bypasses both user intent controls and many conventional download protections.

👉 Read Gurucul's analysis of the OpenClaw ClickFix infostealer campaign

Context

ClickFix changes the access model by getting the user to run the malicious command themselves. That shifts the security problem from blocked downloads to user-driven execution, which means the browser, endpoint, and identity controls all need to assume trusted-looking prompts can still produce hostile code execution.

For identity programmes, the key issue is not just malware delivery. It is that browser credentials and session tokens are reusable identity artefacts, so once harvested they can be replayed outside the browser and beyond the original user session, undermining both IAM visibility and response timing.

Key questions

Q: How should security teams reduce risk from ClickFix-style attacks?

A: Security teams should focus on execution behaviour, not just download controls. Block or alert on user-driven shell commands that retrieve and run files from user-writable locations, then correlate that activity with browser credential access, unusual DLL loading, and outbound communications from freshly dropped binaries. The goal is to stop the chain after user interaction but before credential theft and exfiltration.

Q: Why do browser credentials create account risk after malware infection?

A: Browser credentials are reusable identity artefacts. Stored passwords, cookies, and session tokens can be replayed without the original user present, which means a single infostealer infection can become account compromise even if the initial malware is removed. That makes browser profile access a governance issue for IAM, not only an endpoint issue.

Q: What do security teams get wrong about DLL sideloading?

A: Teams often look for obviously malicious executables and miss the trusted-looking wrapper that loads the payload. DLL sideloading abuses normal Windows search behaviour, so the key signal is usually the relationship between the executable, its directory, and the co-located DLL. Detection should focus on abnormal execution context and file placement, not just file reputation.

Q: Who should be accountable when browser token theft leads to account compromise?

A: Accountability should sit across endpoint security, IAM, and application owners because the stolen artefacts are identity credentials, not just malware indicators. Browser token theft can bypass password resets if session artefacts remain valid, so incident response must include session invalidation, credential review, and containment of any accounts accessed with the stolen material.

Technical breakdown

ClickFix social engineering turns the user into the execution path

ClickFix is a social engineering pattern where the victim is instructed to copy or run a command manually, often through Command Prompt or a similar shell. In this campaign, that user action becomes the initial execution event and bypasses browser-based download controls because the payload is no longer delivered through a standard file transfer path. The important technical shift is that the attacker does not need privilege escalation at the start. They only need the user to execute a trusted-looking instruction, after which normal system utilities can retrieve and launch the next stage.

Practical implication: monitor for user-initiated shell execution followed by download-and-run behaviour from user-writable locations.

DLL sideloading and masquerading hide the malicious payload

DLL sideloading occurs when a legitimate-looking executable loads a malicious DLL from the same directory, taking advantage of Windows search-order behaviour. Masquerading strengthens that deception by naming the dropped binary after a trusted product or service, such as AvastSvc.exe, even when it is not installed in a normal program path. In this chain, the loader is not the final payload. It is a delivery wrapper that causes the malicious DLL to execute under the appearance of a trusted process, reducing user suspicion and complicating static detection.

Practical implication: flag signed or trusted-looking executables launched from user directories with co-located DLLs and abnormal installation paths.

Browser credential stores are the real target, not the browser itself

The malware selectively targets Chromium-based browsers and Firefox by looking for stored credentials, cookies, session tokens, and profile data. Those artefacts are identity assets because they can preserve authenticated state without needing the original password. The campaign then uses WinHTTP over HTTPS for command-and-control traffic, which helps the activity blend into normal outbound web traffic. This is a common post-execution pattern in credential theft: collect the browser state, package the identity data, and send it out using a standard system library instead of unusual malware networking code.

Practical implication: treat browser credential stores and session tokens as high-value identity data and monitor access to them as potential account compromise.

Threat narrative

Attacker objective: The attacker aims to steal usable browser credentials and session artefacts for account access, replay, and follow-on compromise without triggering obvious download or malware controls.

1. Entry occurred when users were lured to a typosquatted OpenClaw site that instructed them to execute a malicious command manually through Command Prompt.
2. Credential access followed the initial execution as the loader dropped a masqueraded executable and malicious DLL that harvested browser credentials, cookies, and session tokens from local browser stores.
3. Impact came through HTTPS exfiltration using WinHTTP APIs, allowing the attacker to remove identity data and maintain stealthy communication with attacker-controlled infrastructure.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser credentials are identity assets, not just malware loot. This campaign worked because the stolen material was not limited to files or configuration data. Cookies, session tokens, and stored passwords are operational identity artefacts that can be replayed outside the original workstation. That makes browser theft an IAM problem as much as an endpoint problem. Practitioners should treat browser data access as an identity event, not only a security telemetry event.

ClickFix is a control bypass pattern, not simply a social engineering trick. The user is converted into the execution path, which means browser protections that assume downloads are the main delivery channel no longer hold. The control gap is not just poor filtering. It is the absence of behavioural guardrails around command execution initiated from trusted-looking prompts. Security teams should recognise that the attack starts before the payload exists on disk.

User-writable execution paths create a hidden trust boundary. Once malicious files are written into %AppData% and executed from there, many traditional trust assumptions collapse. Legitimate-looking names, local directories, and co-located DLLs let the malware borrow process legitimacy without borrowing actual trust. The implication is that endpoint governance has to distinguish installed software from user-space execution with much higher precision.

Identity theft is now blended with living-off-the-land technique chains. The use of curl, WinHTTP, and native Windows process behaviour means the campaign does not depend on exotic tooling. That reduces detection opportunities because the behaviour is distributed across ordinary system components. This is why NHI and IAM teams need to align with endpoint and browser telemetry rather than assume identity compromise will always surface through authentication logs alone.

For identity programmes, the named concept is browser session trust debt: authenticated browser state persists longer than the user action that created it, so one successful theft can outlive the original login by hours or days. That persistence turns a single ClickFix event into reusable access across systems that still trust the session artefact. Practitioners should design controls around the lifespan of the session, not just the login event.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For the wider threat landscape, review 52 NHI Breaches Analysis to see how identity abuse patterns recur across real incidents.

What this signals

Browser session trust debt is a useful way to think about this campaign. Identity programmes often focus on the initial authentication event, but stolen browser state can outlive that moment and continue to function as access. That is why session invalidation, token scope, and browser telemetry now belong in the same operational conversation as credential hygiene.

With 97% of NHIs carrying excessive privileges, identity teams already know that over-permissioning amplifies blast radius. The same logic applies here: once browser artefacts are stolen, permissive access and weak session controls turn one infection into broad account exposure.

The programme signal is clear for IAM and security architects. Controls that assume attacks begin with a blocked download are too narrow for ClickFix-style delivery, and browser state needs to be monitored as part of identity risk management. Teams that align endpoint, browser, and IAM telemetry will spot compromise earlier and contain it faster.

For practitioners

• Detect command execution from trusted-looking prompts Alert on user-initiated cmd.exe or PowerShell activity that immediately downloads and executes files into user-writable locations such as %AppData%. Correlate parent-child process chains and deny-by-default execution from paths that are not part of approved software installation behaviour.
• Block and inspect DLL sideloading patterns Hunt for legitimate-looking executables that load co-located DLLs from the same directory, especially when the executable name mimics security software. Quarantine unsigned DLLs in user directories and investigate binaries that execute outside standard installation paths.
• Protect browser credential stores as high-value identity data Prioritise monitoring for access to browser Login Data databases, cookie stores, and session token files. Where possible, reduce local persistence, harden profile permissions, and alert on unusual processes reading browser profile directories.
• Track native Windows network APIs used for exfiltration Look for WinHTTP-based outbound traffic from unusual parent processes or newly dropped binaries, particularly when paired with browser credential access. Native APIs can blend into normal web traffic, so network detection needs process context as well as destination reputation.

Key takeaways

• This campaign shows that browser credentials, cookies, and tokens are identity assets with direct account compromise value.
• The attack chain combines user-driven execution, DLL sideloading, and native Windows networking to evade conventional download-centric controls.
• Security teams should treat browser state, session invalidation, and user-writable execution paths as part of identity governance and incident containment.

Key terms

• ClickFix: ClickFix is a social engineering pattern that persuades a user to manually run a command or paste code, turning the victim into part of the execution path. It bypasses some browser and download protections because the malicious action is performed locally by the user rather than delivered as a normal file download.
• DLL sideloading: DLL sideloading is a technique where a legitimate-looking executable loads a malicious DLL from its own directory or another preferred search location. The executable borrows trust from familiar naming or placement, while the DLL provides the malicious behaviour. It is effective because Windows loading logic can make the payload appear routine.
• Browser credential store: A browser credential store is the set of local files and databases that hold saved passwords, cookies, session tokens, and profile data. These artefacts are valuable identity assets because they can preserve authenticated access without requiring the user to log in again, making them attractive targets for infostealers.

What's in the full article

Gurucul's full blog covers the operational detail this post intentionally leaves for the source:

• Process tree analysis showing how cmd.exe, curl, the loader, and the masqueraded executable connect in the infection chain.
• File-system indicators that help distinguish sideloading from legitimate application installation behaviour.
• Registry, network, and browser-credential indicators that support hunting and triage.
• MITRE ATT&CK mappings and indicators of compromise for operational detection work.

👉 Gurucul's full blog covers the process tree, IOCs, and detection opportunities in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.