Notifications
Clear all
Topic starter
20/08/2026 6:04 pm
TL;DR: A ClickFix-style phishing campaign uses cache smuggling to stage a payload through the browser cache instead of an explicit download, which can evade tools that focus on file retrieval and web requests, according to Expel. The pattern matters because it shifts detection toward clipboard abuse, PowerShell execution, and unusual cache access rather than network-based indicators.
NHIMG editorial — based on content published by Expel: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
Questions worth separating out
Q: What breaks when attackers use cache smuggling instead of a normal file download?
A: Download-based detections lose visibility because the browser caches the payload through ordinary web behaviour, and the malicious script later extracts it locally.
Q: Why does ClickFix-style phishing remain effective against mature environments?
A: It succeeds because it targets user trust in familiar workflows such as compliance checks, support steps, or file verification.
Q: How do security teams detect cache smuggling in practice?
A: Look for unusual reads from browser cache directories, script activity that immediately follows a browser interaction, and archive creation or extraction in user-writable paths.
Practitioner guidance
- Monitor browser cache access paths Alert on unexpected processes reading from Chrome or other browser cache directories, especially when the process ancestry includes PowerShell, archive utilities, or suspicious shells.
- Constrain PowerShell execution Restrict PowerShell to approved roles where possible, and where restriction is not feasible, apply script logging, constrained language mode, and strong process monitoring.
- Harden against paste-and-run lures Use user education and browser hardening to reduce successful ClickFix-style execution, especially on systems that provide remote access to corporate environments.
What's in the full article
Expel's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact PowerShell command structure used to extract the payload from the browser cache and launch it locally.
- The page source and clipboard manipulation sequence that made the ClickFix lure look like a routine compliance check.
- The specific cache artefacts and regex pattern used to recover the embedded archive from the disguised image response.
- Defender guidance for spotting browser-cache abuse alongside the later signed-executable stage mentioned in the article.
👉 Read Expel's analysis of cache smuggling in a ClickFix phishing campaign →
Cache smuggling and ClickFix lures: what defenders need to watch?
Explore further
20/08/2026 6:39 pm
Cache smuggling is a delivery-evasion pattern, not just a curious trick. The key governance problem is that security stacks often assume malicious payloads must arrive through a visible download path. This campaign shows that assumption is too narrow because the browser cache can become an unmonitored staging layer. Practitioners should treat cache access as part of endpoint threat detection, not just a browser performance detail.
A question worth separating out:
Q: Who is accountable when phishing files lead to code execution?
A: Accountability usually spans email security, endpoint security, and the business owner of the exposed workflow. If a malicious attachment can reach a user and then create persistent execution, the control failure is shared across delivery, inspection, and host hardening. Frameworks such as CIS Controls and NIST SP 800-53 expect that shared boundary to be governed.
👉 Read our full editorial: Cache smuggling turns ClickFix phishing into a fileless delivery path
