Browser Cache Smuggling 2.0: How Attackers Weaponize the Web to Deliver Stealthy Malware
do son 
Image: SensePost
More than a year after first revealing a novel method for delivering malware via browser cache, researchers at SensePost have returned with an upgrade to the attack: a fully weaponized version of Browser Cache Smuggling, which evades traditional defenses and blends seamlessly into normal user behavior.
“Browsers haven’t changed their behaviour and as such you can still use it for red team assessments,” the author writes, signaling that the vulnerability in caching behavior remains unpatched and exploitable.
The original idea behind Browser Cache Smuggling was to serve malicious payloads—typically DLLs—over a browser session and have them silently stored in the local cache directory. A PowerShell script would then comb through that cache, extract the malicious DLL, and execute it with rundll32.
But as the report notes: “This is anything but good opsec… PowerShell runs rundll32.exe; Sihost.exe spawns calc.exe; Sihost.exe child process communicates on the Internet. All of that really looks suspicious.”
The new approach? Make the malware appear invisible to defenders by injecting it into trusted, HTTPS-communicating applications—specifically Microsoft Teams or OneDrive.
The attack exploits a subtle but dangerous quirk: older versions of Teams and OneDrive install themselves in LocalAppData, a directory modifiable by standard users.
When these apps launch, they follow the Windows DLL search order, which includes their own directory first. If a malicious VERSION.dll is cached and dropped there, it will be loaded by Microsoft Teams itself—no alerts, no warnings, just malware execution inside a trusted process.
To ensure stability and functionality, the malicious DLL is a proxy DLL—a file that both:
- Forwards calls to the real VERSION.dll
- Executes a malicious payload in the background (e.g., a C2 beacon)
“We are going to build a VERSION.dll that is going to: run our beacon and connect to our C2; forward legitimate calls to the WINAPI to the real VERSION.dll.”
The attacker merely needs to deliver the payload via a web page, wait for the browser to cache it, and trigger its relocation into LocalAppData.
Modern defenders can now protect against this attack using an effective countermeasure: auto-deleting browser cache upon session end.
“It is possible to force Chrome to flush its cache (as well as other data)… by configuring the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\ChromeClearBrowsingDataOnExitList.”
By specifying cached_image_and_files and hosted_app_data, enterprises can ensure cached DLLs never persist long enough to be weaponized. Chrome, Firefox, and Edge all support variations of this configuration.
Moreover, SensePost suggests detecting this technique by monitoring for suspicious file access:
“You can create a monitoring rule that raises an alert if any process other than legitimate browsers try to access cached files!”
The Browser Cache Smuggling attack isn’t just back—it’s better disguised and harder to detect. With browsers still caching DLLs by default, and trusted apps like Teams unwittingly loading attacker-controlled files, the delivery vector is viable in 2025.
“We now have a fully working scenario that relies on a more advanced delivery method, a malware and social engineering.”
