In December 2024, researchers at Mandiant (Google Cloud) published a technical report that sent quiet shockwaves through the cybersecurity community. Titled “(QR) Coding My Way Out of Here: C2 in Browser Isolation Environments,” this work demonstrates that establishing a functional command and control (C2) channel through certain Remote Browser Isolation (RBI) implementations is possible—including, crucially, the so-called “transparent” ones.

For security teams who deployed an RBI solution thinking they had solved the malicious web traffic problem, this report demands a careful read. Above all, it calls for a re-evaluation of the chosen architecture.

What Mandiant Discovered: C2 via QR Code

The premise of Remote Browser Isolation relies on a simple promise: the remote browser executes the web code (JavaScript, HTML, active content), and only an encrypted pixel stream is sent back to the user’s workstation. HTTP requests cannot be decoded on the client side, which theoretically prevents a malicious implant from retrieving instructions from a C2 server.

Mandiant bypassed this protection using an approach as ingenious as it is unsettling: rather than encoding C2 commands in the headers or body of an HTTP response, the attacking server returns a webpage displaying a QR code. The implant, installed on the compromised machine, drives a headless browser in automation mode (via the Chrome DevTools Protocol), captures a screenshot of the page rendered by the isolation system, and then decodes the QR code to extract the instructions.

The pixel stream, supposed to guarantee isolation, hereby becomes the vector for transmitting commands. What is transmitted “in plain sight” is perfectly readable by the machine.

The throughput is limited (~438 bytes/second in Mandiant’s tests), but sufficient for standard C2: lightweight data exfiltration, command execution, and staging additional implants. The technique was even integrated with Cobalt Strike via its External C2 mechanism, validating its real-world operability.

Critical point: This technique is applicable as soon as a Chrome browser is present and accessible on the user’s workstation—which is exactly the case for all so-called “transparent” RBI solutions.

The Vulnerability’s Entry Point: What is Transparent RBI?

To understand why some solutions are more exposed than others, we must revisit a fundamental architectural distinction, often underestimated when selecting a solution: transparent vs. non-transparent RBI.

Transparent RBI aims to make isolation completely invisible to the user. Practically, this means isolated browsing occurs within the Chrome browser already installed on the workstation—typically in a new tab, via an extension, or through transparent proxy redirection. The user continues to use their regular Chrome, without changing their habits. This is precisely the sales pitch for many solutions on the market: zero friction, zero tool changes.

But this transparency comes with a heavy architectural price. Since a local Chrome instance is running on the workstation, the Chrome DevTools Protocol is available by definition—the very same protocol Mandiant uses in its demonstration to drive the browser, capture the pixel stream, and decode the QR codes containing C2 commands. An implant capable of enumerating local processes can detect Chrome in automation mode (--enable-automation, --remote-debugging-port) and use it as a communication channel with an attacking server, even if the web content is technically “isolated” server-side.

In other words: the content is isolated, but the rendering channel remains exploitable. Content isolation is not enough if the communication vector itself is accessible from the compromised workstation.

This is precisely why Mandiant recommends, in its conclusions, monitoring Chrome processes using automation flags—a recommendation that wouldn’t be necessary if no local Chrome were involved.

A Matter of Design Philosophy, Not Configuration

The answer to this class of threats does not lie in a patch or an additional detection rule. It stems from a design choice made from the very beginning: should the local browser exist on the workstation, or not?

At Reemo, this choice was settled by design: we do not implement transparent RBI. The user does not interact with a local Chrome; they access a browsing session that runs entirely server-side, in a dedicated, ephemeral remote environment. What the user’s workstation receives is solely an encrypted pixel stream, rendered in a lightweight client interface that possesses no autonomous browsing capabilities.

No local Chrome in automation mode, no DevTools Protocol exposed on the workstation, no browsing process controllable by an implant. The residual attack surface on the client side is reduced to the strict minimum.

This architecture directly addresses Mandiant’s recommendations:

• Monitor abnormal network traffic: Without a controllable local browsing session, the described C2 vector has no entry point on the workstation.
• Detect browsers in automation mode: No Chrome process with --remote-debugging-port runs on the client side, because no local Chrome is deployed.
• The remote session is ephemeral: At the end of each session, the environment is destroyed. No traces, no persistent state, no exploitable artifacts.

What This Means for Your Security Posture

Mandiant’s publication should be treated as an audit opportunity, not just a news bulletin. Here are the questions to ask your current RBI vendor—or to prioritize during an evaluation:

What is the residual attack surface on the user’s workstation?

In a non-transparent RBI implementation, it should be close to zero on the browsing side: no browser executable, no plugin, no automation process.

Is your RBI solution transparent?

If the user browses in their usual Chrome without changing tools or interfaces, chances are you are dealing with a transparent RBI. In this case, the QR code C2 vector described by Mandiant is technically applicable to your environment.

Is a Chrome process running on the user’s workstation during isolated browsing?

If yes, the Chrome DevTools Protocol is potentially accessible. The presence of --enable-automation or --remote-debugging-port flags in active processes confirms the exposure.

Is the remote browsing environment truly separated from the client workstation?

The answer must be architectural. “Web content is executed remotely” is not enough if the final rendering goes through a controllable local browser.

Conclusion

Mandiant’s research does not condemn Remote Browser Isolation as a technology; in fact, it validates its relevance as a defense layer against standard web threats. What it challenges is the implicit security assumption of transparent RBI: the idea that isolation can be total while remaining invisible within the user’s existing local browser.

Transparency, in this context, is not a security feature. It is a commercial compromise, and like all compromises, it has a cost that Mandiant’s research has now concretely quantified.

For CISOs and Information Security Directors managing exposed environments (third-party access, high-risk browsing, OSINT, sensitive workstations), the question is no longer “do we have an RBI?”, but rather: “Does our RBI leave a local browser exposed on the workstation?”

Schedule a demo of Reemo today!

---

Sources :

• Mandiant / Google Cloud Threat Intelligence : “(QR) Coding My Way Out of Here: C2 in Browser Isolation Environments”, décembre 2024
• Reemo Remote Browser Isolation