Notifications
Clear all
Topic starter
08/07/2026 6:52 pm
TL;DR: A spoofed OpenClaw site used ClickFix social engineering, DLL sideloading, and native Windows networking to steal browser credentials and session data while blending into normal activity, according to Gurucul threat research. The campaign shows that browser trust, user execution, and endpoint visibility fail together when attackers combine social engineering with staged payload delivery.
NHIMG editorial — based on content published by Gurucul: Threat research on a fake OpenClaw AI tool used to deliver an infostealer via ClickFix
Questions worth separating out
Q: How should security teams reduce risk from ClickFix-style attacks?
A: Security teams should focus on execution behaviour, not just download controls.
Q: Why do browser credentials create account risk after malware infection?
A: Browser credentials are reusable identity artefacts.
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.
Practitioner guidance
- 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%.
- 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.
- Protect browser credential stores as high-value identity data Prioritise monitoring for access to browser Login Data databases, cookie stores, and session token files.
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.
👉 Read Gurucul's analysis of the OpenClaw ClickFix infostealer campaign →
ClickFix and browser credential theft: what IAM teams should watch?
Explore further
08/07/2026 7:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OpenClaw ClickFix campaign shows how browser credentials get stolen
