In early September, Palo Alto Networks publicly acknowledged that Secure Web Gateways (SWGs) are architecturally unable to defend against Last Mile Reassembly attacks. SquareX first discovered and disclosed Last Mile Reassembly attacks at DEF CON 32 last year, warning the security community of 20+ attacks that allow attackers to bypass all major SASE/SSE solutions to smuggle and reassemble malicious sites, scripts and files in the browser.

Despite numerous responsible disclosure efforts, most major vendors maintained complete ignorance, offering no customer warnings about these critical exposures for over a year. However, as attackers increasingly weaponize Last Mile Reassembly techniques to target enterprises, SASE/SSE vendors are finally acknowledging that traditional proxy-based defenses fall short when it comes to browser-native threats. In the same press release, the industry giant also recognized that “the browser is becoming the new operating system for the enterprise, the primary interface for AI and cloud applications” and that “securing it is not optional”.

This article will provide a recap of Last Mile Reassembly Attacks, its impact on organizations and 5 questions you should ask your SASE/SSE vendor.

What are Last Mile Reassembly Attacks?

Last Mile Reassembly attacks leverage various methods to smuggle site source codes, malicious scripts and files, before reconstructing them as functional malicious scripts, phishing sites and malware in the victim’s browser. These techniques exploit architectural limitations of SWGs, leading to a complete bypass. These include:

Smuggling Malicious Sites with Canvas Engine

Instead of full blown malicious sites, attackers can deliver a stream of pixel coordinates, which is then used by the canvas engine to “draw” the malicious site. Combined with its ability to capture interactions like keystrokes and mouse clicks, this enables attackers to assemble any malicious site, including phishing sites, in the victim’s browser. In other words, instead of shipping the “painting”, this technique ships the “painter” into the victim’s browser.

Smuggling Malicious Scripts with Web Assembly

Malicious scripts can be smuggled as malicious payloads in WASM modules, which are not inspected by SWGs. Once it lands on the victim’s browser, these malicious scripts can be extracted and assembled into a functioning malicious script to exfiltrate data, steal credentials and session tokens.

Smuggling Malicious Files with Various Techniques

There are multiple ways to smuggle files into the victim browser, including file chunking, embedding encryption and encoding. File chunking involves breaking malware into “chunks” that individually do not contain a malicious signature. File embedding involves hiding files in web elements like CSS, Javascript and images using steganography techniques. Regardless of which technique is used, the file is then reassembled into a functional malware which can be loaded in the browser or downloaded to the victim’s endpoint.

Unmonitored Channels

Attackers can smuggle malicious scripts, site MHTML/HTMLs and files via binary channels like WebRTC, gRPC and WebSockets. These are common communication channels used by web apps like video conferencing and streaming tools, but are completely unmonitored by SWGs. In fact, many SWGs publicly admit this on their website and recommend their customers disable these channels.

Why are SWGs Unable to Detect Last Mile Reassembly Attacks?

As a proxy solution, SWGs work primarily by inspecting network traffic, with no direct visibility into what the user scripts, sites and files the user interacts with in the browser.

Lack of Visibility into the Browser

SWGs identify malicious sites through URL filtering and running the site’s HTML/CSS/JS against its ML model trained on the web markups of known malicious sites. Neither of these techniques allow direct visibility into what the user sees in the browser. The canvas engine attack exploits this technique, “drawing” malicious/phishing sites in the victim’s browser with pixel coordinates without needing to send any actual HTML/CSS/JS.

No Web Assembly Inspection

Similar to communication channels, Web Assembly is a relatively new browser component that remains uninspected by SWGs. Given that there is no static or dynamic analysis performed, attackers can freely smuggle malicious scripts through WASM modules, disguising itself as a legitimate functionality in the browser.

Limitations in File Inspection

SWGs typically work by using heuristics like HTTP headers to identify file download requests. When a file download request is detected, it will then send a copy of the file to its cloud for inspection, blocking the download if any malicious file signature is detected. Last Mile Reassembly attacks exploit architectural vulnerabilities in each of these steps by preventing SWGs from detecting a file download (e.g. unmonitored channels, embedding) and/or inspecting the file properly (e.g. encryption, encoding, chunking). Once the file, or components of it, reaches the victim’s browser, SWGs have limited visibility on how it is modified, reassembled and the form it takes when it is finally downloaded onto the victim’s device.

Unmonitored Channels

Browser communication channels like WebRTC and gRPC are relatively new browser features popularized long after SWGs were invented. Thus, SWGs do not monitor any of these channels, making them prime avenues for attackers to smuggle malicious components. Most SASE/SSE vendors have attempted to solve this problem by advising their customers to block all browser communication channels. However, this is an unrealistic solution as most modern web apps, including enterprise apps, rely on these channels to function.

Test Your SWG Against Last Mile Reassembly Attacks Now

To see if you are vulnerable to LMRs, visit scan.browser.security to get a free Web Security Posture Assessment on how your SWG performs against LMR attacks.

Why are SASE/SSE Vendors Highlighting this Vulnerability Now?

Unfortunately, attackers have been increasingly exploiting enterprises with Last Mile Reassembly techniques. While we are unlikely to ever see a public admission, it is highly probable that SASE/SSE vendors are seeing more of their customer base fall prey to LMR attacks despite having full SWG protection. In fact, many of our customers are from this exact demographic — existing SASE/SSE customers who realize they are still being exploited by browser-based attacks like LMR.

There has also been evidence that attackers are using similar techniques to exfiltrate sensitive data out of organizations. Termed Data Splicing Attacks, the SquareX research team disclosed multiple attacks at BSides SF this year that allow insider threats to effectively copy-paste any data and upload any file to the browser. In the talk, researchers showed Data Splicing completely bypassing both SASE/SSE cloud DLP and endpoint DLP solutions.

This presents a two-pronged challenge for SASE/SSE vendors, which hundreds of thousands of enterprises rely on to protect themselves from both web threats and data loss. Thus, several vendors, such as Palo Alto Networks and Netskope, have become the first to embrace the inevitable and face the issue head on by buying or building their own browser security solution.

Unfortunately, these attacks are far from only browser-native attacks that are affecting enterprises. One major attack is Browser Native Ransomware, which combines identity attacks and agentic AI to systemically exfiltrate and hold sensitive data from enterprise SaaS apps as ransom. These ransomwares require no local files and processes, allowing them to completely evade traditional anti-ransomware solutions. Similarly, there has been an uptick in malicious extensions that exfiltrate data, monitor users and steal credentials without being detected by traditional enterprise security solutions.

What are SASE/SSE vendors doing to mitigate LMR?

There are two categories of SASE/SSE vendors. The first category, which unfortunately includes the majority, is still in complete denial of the rise of browser-based attacks. The second category, recognizes the shift it attack surface towards the browser and has branded themselves to be “first movers” in browser security among incumbent SASE/SSEs. This includes Palo Alto Networks, who purchased Talon (now known as Prisma Access Browser) and Netskope, who built their own Netskope Enterprise Browser.

Unfortunately, both solutions are met with significant adoption challenges due to the change management and productivity hindrance involved in migrating all employees to a dedicated enterprise browser. According to Gartner, enterprise browsers have only seen a 10% adoption rate at best due to resistance from both end users and IT teams. Most importantly, these enterprise browsers are primarily designed for application access control, and thus are unable to protect against bleeding edge browser-based attacks like Last Mile Reassembly.

How does SquareX protect against LMR?

SquareX’s Browser Detection and Response (BDR) extension acts as an “EDR in the browser” to secure any browser on any device, including unmanaged devices and AI browsers. This includes:

Full Visibility of User View for Canvas Engine Attacks

As a browser-native solution, SquareX has full visibility into what the user sees, including sites that are assembled using canvas engine. This allows SquareX to perform OCR and run each site rendered on the user’s browser through our advanced phishing detection engine, protecting users against malicious sites that go undetected by SWGs.

Granular Script Inspection for Malicious Scripts Smuggled via WASM

SquareX inspects every script running on in the user’s browser, be it those smuggled through WASM modules or injected by a malicious extension. Thus, regardless of how the script gets loaded on the site, SquareX is able to inspect and block any malicious scripts from running.

Client-side File Scanner for Reassembled Files

SquareX built the industry’s first client-side file scanner. In addition to latency benefits, this allows SquareX to scan every file download at the last mile to identify malicious, after any reassembly activities have occurred in the browser. With a single policy, SquareX blocks the download of any file containing malicious macros and/or executables. SquareX can even inspect encrypted files by forcing the users to enter the password before each download, which is often delivered separately by the attacker.

Last Mile Protection for Communication Channels

As SquareX has full visibility into the final site, script and file that the user/user’s browser interacts with, this allows SquareX to provide last mile protection against any malicious site MHTML/HTML, scripts and files that are smuggled through communication channels that go unmonitored by SWGs.

In addition to Last Mile Reassembly attacks, SquareX also protects against other bleeding edge browser threats such as Data Splicing Attacks, Browser Native Ransomware, malicious extensions, identity attacks, rogue AI agents and GenAI data loss. Furthermore, SquareX’s browser extension is compatible with all browsers, allowing enterprises to have browser-native protection without the overhead and productivity risks involved with enterprise browsers.

What Should I Do to Mitigate LMRs?

To begin, here are three actionable steps that we recommend to mitigate LMRs:

1. Visit scan.browser.security to get a free assessment on your LMR exposure
2. Speak to your SASE/SSE provider about how they are mitigating LMR attacks (question guide below)
3. Adopt a browser-native solution that protect against LMR attacks

5 Questions to Ask Your SASE/SSE Vendors

1. Last Mile Reassembly attacks were disclosed at DEF CON last year, can you provide the documentation on how your product protects against these?
2. As communication channels like gRPC and WebRTC are essential to modern web apps, do you have any solution to prevent malicious components from being smuggled via these channels without disabling them?
3. LMR allows attackers to smuggle malware into our employees’ browsers, including known malware. Does this break your SLA that promises to protect against all known malware?
4. [If your vendor has an enterprise browser] Your enterprise browser claims to protect against LMR, why does the report from scan.browser.security still show multiple bypasses?
5. What is your strategy/product roadmap to defend against other emerging browser-based threats? How soon are you planning to launch or integrate a browser security solution?

For industry consortium representatives and enterprise security leaders who would like to learn more, contact us at [email protected]. We would be more than happy to provide a technical deep dive with our researchers and answer any questions over an in-depth conversation.

Why SASE Vendors Are Finally Admitting the Need for Browser Security Solutions was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from SquareX Labs - Medium authored by SquareX. Read the original post at: https://labs.sqrx.com/why-sase-vendors-are-finally-admitting-the-need-for-browser-security-solutions-1789d950f122?source=rss----f5a55541436d---4