Remote Browser Isolation (RBI) represents a significant leap forward in enterprise security and has gained popularity due to its effectiveness. By executing JavaScript code within a cloud-hosted container and streaming only safe pixels or sanitized components to the endpoint, RBI solutions effectively neutralize traditional web-based threats, drive-by downloads, and standard Command & Control (C2) channels.

Because the local browser never executes the remote JavaScript, techniques like HTML-Smuggling are prevented by design. Furthermore, RBI allows organizations to heavily restrict internet access for endpoints to prevent standard C2 communication.

During a recent red team exercise, we encountered an environment protected by an RBI implementation. While navigating and bypassing security measures, such as Application Control, Endpoint Detection and Response (EDR), Attack Surface Reduction (ASR) rules, and more, is a standard, but still challenging, part of our engagements, this post focuses exclusively on how we tackled the specific restrictions of RBI. The following details how we established a functional, external C2 channel: from our initial ideas around clipboard synchronization, through browser instrumentation, to a working proxy architecture that evaded outbound filters using GET-request tunneling and POST-to-PUT rewriting.

The Core Challenge: Communicating Through the Barrier

In a fully integrated RBI architecture, the endpoint’s direct internet access is heavily restricted. Only the RBI browser itself is typically permitted to resolve external DNS or make outbound HTTP connections. For a red team, this means that even if an initial payload successfully executes on the endpoint, the resulting implant is trapped. It cannot call home to the team server using traditional HTTP/S or DNS traffic and is rather easy to detect.

This constraint is a known hurdle in modern offensive operations. As highlighted by SpecterOps in early 2024, RBI effectively breaks traditional callback mechanisms. More recently, Mandiant published research demonstrating how visual data exfiltration via QR codes can be used to bypass these restrictions. Building on these ideas, Redguard’s red team is sharing our own, improved approaches for successfully establishing a robust command-and-control channel through an RBI-secured environment.

Initial Infection and Command Execution

Establishing a C2 channel through RBI is only possible if you can execute code on the local endpoint in the first place. This presents a significant “chicken-and-egg” problem for attackers. RBI solutions typically enforce strict file download profiles, scrutinizing extensions, sizes, entropy, and signatures, while simultaneously intercepting and sanitizing active web content like JavaScript. This inherently breaks techniques like HTML-smuggling or drive-by downloads. While an attacker could theoretically hunt for allowed file types that a user can successfully download and execute, doing so drastically increases the risk of detection.

In their 2024 research, SpecterOps highlighted that successful payload ingress often relies heavily on forcing user interaction. Because an RBI container’s automated sandbox cannot easily supply passwords, solve puzzles, or click user engagement checkboxes during its analysis phase, hiding malicious logic behind interactive gates is a proven method for sneaking payloads past the initial inspection.

While hiding a file download behind a click or a password is an effective tactic, modern threat actors are increasingly taking this reliance on user interaction to its extreme by removing the file download from the browser entirely with techniques like ClickFix. ClickFix abandons technical exploitation in favor of weaponizing user helpfulness. The infection chain completely circumvents multiple classical security measures like download restrictions or application control. During our engagement, the RBI container was bypassed by tricking the user into executing the payload manually in their native operating system shell via malicious copy and paste.

The attack flow typically follows the following pattern:

1. The Lure: The target receives a link to a phishing domain, which can be delivered, for example, via a phishing email, a Microsoft Teams message or a contact form. Depending on the pretext, at some point a highly realistic captcha prompt, inspired, for example, by Google’s reCAPTCHA, will be displayed and will ask for additional verification.
2. Clipboard Hijacking: When the user clicks the “Verify you are human” button, the webpage executes a JavaScript function in the background. Instead of attempting a file download, the script silently copies a malicious, encoded command directly into the user’s local clipboard.
3. User Execution: The webpage then presents the user with simple, step-by-step instructions. Usually, it tells them to open the “Windows Run” dialog (Win + R) or PowerShell, paste the copied text (Ctrl + V), and press Enter.

By convincing the target to copy and execute a command directly via cmd.exe or powershell.exe, the attack jumps the gap. The payload execution occurs entirely outside the restricted browser environment, effectively rendering the RBI blind to the initial compromise. However, even with the implant running, it cannot call back home. Due to the RBI solution, the endpoint’s internet access is heavily restricted.

Calling Home: Anybody out there?

Establishing a successful command-and-control channel through an RBI solution presents a tough challenge during any red team engagement, as any communication must either use a bypass or directly run through the heavily monitored and hardened RBI solution. During the engagement, we opted to go through the RBI solution, as identifying a potential bypass would most likely trigger multiple alerts and endanger the ongoing engagement. We therefore designed and developed three different approaches to hijack the trusted RBI session from the browser and proxy the C2 traffic directly out of the network to the team server.

Approach 1: Communication via the Clipboard

As already confirmed during the initial infection, the RBI solution allowed clipboard synchronization between the cloud container and the local endpoint. This led to the idea of building a C2 channel around the clipboard.

As shown above, we developed a Proof-of-Concept, named ClippyC2, where the local implant and an active browser window share the clipboard as a communication interface. The browser continually checks the C2 server for new commands and copies them into the clipboard. The local implant monitors the clipboard, executes the command, and writes the results back to the clipboard. The browser reads these results and forwards them to the team server, successfully bridging the RBI-isolated internet and local environment.

Although the idea was technically functional, this approach requires the browser tab to remain actively in the foreground for the clipboard to remain accessible, making it operationally impractical in practice. The red team therefore did not follow this approach any further.

Approach 2: Communication via Browser Instrumentation

To create a more robust C2 channel, we shifted our focus to abusing the browser’s native capabilities. Since the browser needs to communicate with the RBI solution for accessing the internet, it is the obvious path to communicate with our team server. In browser automation and testing frameworks, browsers are often instrumented to test applications, which is essentially what we need. Most of these frameworks use the Chrome DevTools Protocol (CDP) to instrument the browser. A clean approach may be to directly use CDP for communicating with the browser over an open debug port. However, due to time constraints, we leveraged a well-known browser automation and testing framework, Microsoft Playwright, with much of the required CDP functionality ready to use to build our Proxy-Implant:

This proxy implant receives local HTTP requests from our C2 implant and dynamically generates JavaScript. Through the open debug port, the proxy injects this JavaScript into an active browser tab, forcing the browser to execute a fetch request to our C2 domain. The RBI processes the request as any other request and forwards the response back to the browser. The proxy then reads the HTTP response back through the debug port and forwards the response to the C2 implant. This approach successfully abuses the existing browser connected to the RBI solution to proxy the C2 implant’s request to the team server.

Approach 3: Fallback via Local WebSocket Connection

The previous instrumentation method relies heavily on an exposed debug port. In mature environments, this is often disabled or heavily monitored (as recommended below). As an alternative when the debug port is closed, we added a fallback method utilizing a WebSocket connection to localhost:

This requires the target person to open a local HTML file (file://local-file.html) in their browser. This file establishes a WebSocket connection on localhost to our proxy-implant. The proxy forwards the received HTTP C2 requests over the WebSocket to the browser, which then executes the outbound request through the RBI solution. Responses are then again forwarded through the WebSocket tunnel to the proxy implant and then further to the C2 implant. It is important to mention that this approach even works if a firewall or proxy completely blocks WebSocket connections. Due to the WebSocket connection being on localhost between the browser and the proxy implant, the WebSocket traffic does not leave the endpoint. All requests sent to the internet are regular HTTP requests.

Bypassing DLP and Request Filters

Hijacking the browser to send requests was a critical milestone for the engagement, but it was not the final hurdle. Even when traffic originates from the trusted RBI container, it must still pass through any Data Loss Prevention (DLP) solution and outbound request filters. Without additional manipulation, our C2 traffic would have most likely been immediately flagged and blocked. To bypass these filters, we implemented two distinct request manipulation techniques directly within the browser context.

Technique 1: GET-Request Tunneling

Most DLP solutions heavily scrutinize POST request bodies for data exfiltration but apply looser thresholds to GET requests, which are intended for data retrieval. To exploit this blind spot, our proxy-implant split large POST requests into multiple smaller chunks:

Using JavaScript injections, we tunneled these fragments out as individual GET requests. A receiver server on our end caught the fragments and reassembled the original POST request before passing it to the team server. By keeping the data chunks small and avoiding request bodies entirely, the traffic blended into standard web telemetry. However, this approach is heavily constrained by standard URL length limits enforced by systems like web servers, requiring extensive data fragmentation that introduces significant latency and high volume of outbound requests for data exfiltration or larger command results.

Technique 2: POST-to-PUT Rewriting

Many security filters are rigidly configured to apply their strictest inspection rules to POST requests, occasionally overlooking less common HTTP verbs. We identified that the RBI solution treated PUT requests with less scrutiny compared to POST and used the existing implant proxy to further change the HTTP verb from POST to PUT.

Once the PUT request successfully bypassed the RBI filter, our external redirector reformatted it back to a POST request before delivering it to the team server.

Unlike GET-request tunneling, PUT requests utilize a request body. This means they are not constrained by the mentioned URL length limits. This eliminates the need for extensive data fragmentation, significantly reducing both latency and the overall volume of outbound requests. However, this method introduces its own operational disadvantages. The PUT method is relatively uncommon in standard user web browsing telemetry. A sudden spike of outbound PUT requests may stand out in logs and could easily trigger anomaly-based detections. Furthermore, this technique heavily depends on how a solution treats PUT requests.

The final architecture

Our working setup chained four layers together. A ClickFix-style lure placed a local implant on the endpoint, outside the RBI container. With direct internet access blocked, a Playwright-based proxy implant on the endpoint received C2 traffic from the implant and injected JavaScript into an active, RBI-backed browser tab via CDP, turning the trusted browser session into an egress path for outbound requests and inbound responses. Finally, POST-to-PUT rewriting ensured that traffic passing through the RBI solution’s DLP and outbound filters looked like ordinary web activity:

It is important to emphasize that navigating the RBI restriction is only one piece of the operational puzzle. In a hardened enterprise environment, dropping the initial payloads and running instrumentation frameworks like Playwright requires chaining additional evasive techniques to successfully establish a command and control channel in the presence of other security controls, such as Endpoint Detection and Response (EDR) and Application Control. The shown techniques and this architecture demonstrate that even the strictest network isolation can be circumvented when attackers successfully weaponize the trusted communication channels natively permitted by the architecture.

Hardening Remote Browser Isolation

RBI is an exceptionally strong barrier against initial infection vectors and automated malware. It makes initial infection, command and control, and data exfiltration significantly harder for attackers. However, the shown techniques prove that a motivated adversary who is aware of the environment’s security stack can explicitly prepare for and bypass these restrictions.

Because RBI forces attackers to rely on complex proxy setups and browser hijacking, the resulting operations generate significant local noise. Relying solely on the network perimeter is insufficient. Organizations must maintain robust endpoint telemetry to detect these bypass mechanisms.

To effectively harden an RBI implementation, we recommend the following adjustments:

• Disable Browser Debugging: Prevent unauthorized browser instrumentation by disabling debugging features via Enterprise Group Policies for all Chromium-based browsers.
• Adopt an “Isolate All” Strategy: Do not limit RBI strictly to certain “dangerous” domain categories, as this is easily bypassed via trusted sites and CDNs even without complex browser instrumentation. Instead, isolate all general web traffic.
• Restrict Clipboard Synchronization: Review RBI-native clipboard policies to either completely disable or strictly restrict clipboard synchronization between the RBI container and the local endpoint.
• Hardening DLP and Request Filtering: Ensure that present DLP solutions and request filtering measures are configured to inspect all HTTP methods including PUT and PATCH and not solely rely on POST request bodies.

Last but not least, organizations should actively monitor endpoint telemetry for specific bypass use cases:

• Browsers in Debug Mode: Alert on Chromium-based browsers in debug mode or processes launching browsers with anomalous command-line arguments like --remote-debugging-port or --enable-automation.
• Anomalous HTTP Traffic: Monitor for anomalous patterns, such as a high volume of PUT requests or rapid bursts of GET requests targeting the same domain.
• Localhost WebSockets: Detect WebSocket connections opened to localhost, which is highly anomalous for standard user endpoints.

Although RBI is no silver bullet, it can be a highly effective security measure to improve your organization’s security posture. However, Redguard recommends not relying solely on security measures like RBI and instead implementing a robust defense-in-depth strategy.

Validate Your Security Posture

Implementing advanced solutions like RBI drastically reduces your attack surface, but validating how these solutions interact with your wider security architecture is crucial. We continue to recommend RBI as a highly effective security measure. However, as with any technology, it is not a silver bullet. If you are interested in testing the resilience of your organization against targeted, manual attacks, reach out to us to discuss a tailored engagement.