Executive Summary
Recently, we published a blog series based on a threat actor pivot to a tactic for initial execution called FileFix. The techniques deployed in this attack took an interesting turn, but our team was prepared for it.
Previously, FileFix and its predecessor, ClickFix, were known to abuse LOLBins like PowerShell Download Cradles, CertUtil, Microsoft HTML Application Host (MSHTA), and others during the nascent stages of infection to download malware to a victim (called ingress).
Cache Smuggling is a technique that has been murmured for a few years, but has only recently been spotted in conjunction with a FileFix campaign1. As the name implies, with Cache Smuggling, an attacker will embed a malicious payload in an image file on a website they control, your browser will automatically store this image file (in an effort to make browsing faster), ergo “smuggling” a payload to your computer without the need for code execution to do so. With this abuse in the wild, an attacker has demonstrated they can lure an unsuspecting user to extract and run code that was automatically stored by the browser instead of using techniques for ingress, which are quite well documented and easier to identify.
In this post, we’ll break down the tactical pivot, visit emulation, and highlight means of detection.
Abuse: Initial access
With increasing intensity over the past few years, we’ve observed Threat Actors (TA) cloning websites and providing users with malware-laden software through a tactic called Search Engine Optimization (SEO) or Ad Hijacking. This is where a TA will abuse affiliate link programs through an advertiser or pay to promote a cloned website that seemingly hosts software a user may be looking for. Well-known examples are PDF Software and VPN clients. This was highlighted in the sample we’re referencing.
We’ve created an emulation for this activity by making a quick and dirty fake web page (which builds off our last FileFix example) saying “HR Has Requested a VPN Compliance Check”. The page will provide the user with instructions on how to run the “compliance check”, but that’s just instructions to grab the cached image, scrape out, and decode a payload from that image. We’ve gone into detail about the code being pasted in our ClickFix and FileFix blogs. So, we won’t rehash the semantics of those. We’ll focus on what’s changed and how EDR traditional detections may miss the mark for it.
At this point, you may ask, “How does it know how to retrieve malware from the page?” In basic terms, when your browser visits a page, it will store images so they can be accessed quickly the next time you visit that page. Custom settings may interfere with this, but regular users rarely make configuration changes that hinder the effectiveness of this technique. For Chrome the TAs figured out their image would cache in:
C:\Users\<UserName>\AppData\Local\Google\Chrome\User Data\Default\Cache\Cache_Data\
With the understanding that Chrome is going to save images from websites to a specific path, the concept of this tactic changes. You no longer need a script with a Download Cradle (or similar) to pull more payloads to the box. The threat actor can make a short PowerShell script to do the following:
- Access that location and write its contents to a file readable, writeable, and executable location on disk.
- Write out the contents of those files using the Get-ChildItem PowerShell module (sometimes aliased to GCI).
- Search the contents for two unique strings that indicate the start of the malware and the end of the malware (using regex).
- If the strings match, write everything that was between them to a file.
- Execute the file.
Abuse: Hidden Ingress Avoids Known Detections
As a defender, this is an extremely interesting pivot from Living off the Land to Living off the Browser by abusing built-in functionality of cached images. For a TA, it has the added benefit of bypassing detections that have been created for widely observed PowerShell Download cradles and other LOLBins.
Detection Strategy
Luckily, at CyberMaxx, we pay attention to the current threat landscape, and when we see something with a likelihood of being used by another TA, we try to get ahead of that adversary abuse in the wild.
In the case of this adversarial payload:

https://x.com/P4nd3m1cb0y/status/1970796711816605782/photo/2
Conhost with a “headless” parameter; methods for WriteAllBytes and ReadAllBytes; and suspicious file writes are identifiable techniques which we’ve created watchlists that would alert our SOC during Execution:
- Force Headless Conhost
- Masquerading in world rwx file path (C:\users\public)
- Suspicious Directory Creation
- Write Byte Array from Disk
It may seem like we’re being intentionally vague. But, the methods for WriteAllBytes and ReadAllBytes are deployed frequently enough during custom routines for encryption, DLL (or Binary) Chunking, and general process injection that we’ve broken them up to categorize these for our SOC analysts, and won’t be listing them here exhaustively.
The watchlists represent granular technique categories that take place at varying parts of a Kill Chain, not just initial access. They also go above and beyond what traditional EDR agents may be looking for. Since they can also be used by multiple TAs, malware, or command and control frameworks, we don’t tie them to one actor. Our analysts are trained to understand the picture these alerts help paint of the potential attack chain, which may be occurring on a victim, so impact is localized and minimized, and importantly an appropriate response measures can be taken.
For anyone looking for guidance on how to create detections like this, start by reviewing our previous posts, which help emulate the commands observed here.
The links there can be used to deploy emulation and gather data from your own telemetry sources, like SIEM and EDR. If your platform allows, you can identify Windows events, process event telemetry, and other such data that are deployed in the attack.
When you find those, make queries that alert on the telemetry. For good measure, tie them to MITRE so that detection engineers who come behind you can maintain parity.
Conclusion
In this post, we analyzed a TA pivot to abuse built-in browser functionality, which has the potential to bypass known detection methods for very popular ClickFix and FileFix campaigns. We broke down initial access, technical differences in the campaigns, and how you may identify them. We also touched on CyberMaxx’s detection strategy and how one detection created looking at another technique may help ID a broad swath of actors. We hope you enjoyed.