Mandiant revealed a technique to bypass browser isolation using QR codes, enabling command transmission from C2 servers.
Browser isolation is a security measure that separates web browsing from the user’s device by running the browser in a secure environment (e.g., cloud or VM) and streaming visuals.
Mandiant has identified a new technique for bypassing browser isolation technology and using QR codes to send commands from C2 to compromised devices.
C2 communications often rely on the HTTP protocol, implants request commands from a C2 server, execute them, and send results back. However, browser isolation systems complicate this, as they stream only the visual content of web pages to local devices, preventing the implants from decoding original HTTP responses.
Mandiant researchers devised a method to bypass browser isolation by embedding C2 data in a QR code displayed on a legitimate web page. A malicious implant uses a headless browser to render the page, captures a screenshot, and decodes the QR code to retrieve data, enabling communication with the attacker-controlled server.
“Mandiant’s Red Team developed a novel solution to this problem. Instead of returning the C2 data in the HTTP request headers or body, the C2 server returns a valid web page that visually shows a QR code. The implant then uses a local headless browser (e.g., using Selenium) to render the page, grabs a screenshot, and reads the QR code to retrieve the embedded data.” reads the advisory published by Mandiant. “By taking advantage of machine-readable QR codes, an attacker can send data from the attacker-controlled server to a malicious implant even when the web page is rendered in a remote browser.”
Below is the new C2 loop devised by Mandiant:
- The implant “sleeps” for a while, then repeats the cycle.
- The implant controls a local headless browser via the DevTools protocol.
- The implant retrieves the web page from the C2 server via the headless browser. This request is forwarded to the remote (isolated) browser and ultimately lands on the C2 server.
- The C2 server returns a valid HTML web page with the command data encoded in a QR code (visually shown on the page).
- The remote browser returns the pixel streaming engine back to the local browser, starting a visual stream showing the rendered web page obtained from the C2 server.
- The implant waits for the page to fully render, then grabs a screenshot of the local browser. This screenshot contains the QR code.
- The implant uses an embedded QR scanning library to read the QR code data from the screenshot, thereby obtaining the embedded data.
- The implant executes the command on the compromised device.
- The implant (again through the local browser) navigates to a new URL that includes the command output encoded in a URL parameter. This parameter is passed through to the remote browser and ultimately to the C2 server (after all, in legitimate cases, the URL parameters may be required to return the correct web page).The C2 server can decode the command output as in traditional HTTP-based C2.
- The implant “sleeps” for a while, then repeats the cycle.
Mandiant researchers created a proof-of-concept implant leveraging Puppeteer and Google Chrome in headless mode to demonstrate their novel C2 technique.
The researchers also integrated their PoC implant with Cobalt Strike’s External C2 feature, allowing the use of the technique with the popular post-exploitation tool.
The proof-of-concept (PoC) demonstrated the feasibility of QR code-based C2, but the experts also highlighted the following limitations of the technique:
- Data Capacity: Maximum data capacity (2,953 bytes) was unusable due to poor visual stream quality. Researchers reduced it to 2,189 bytes per QR code for reliable scanning.
- Latency and Throughput: The process introduces significant latency. Transferring a 323 KiB BEACON payload takes ~12m20s, making certain operations, like SOCKS proxying, impractical. The experts pointed out that there are some limitations related to the throughput, the technique is slow (~438 bytes/s) for basic C2.
- Additional Security Measures: Features like domain reputation and data loss prevention remain obstacles for offensive operators in browser-isolated environments.
“While this technique proves that browser isolation technologies have weaknesses, Mandiant still recommends browser isolation as a strong protection measure against other types of attacks (e.g., client-side browser exploitation, phishing, etc).” concludes the report. “Organizations should not solely rely on browser isolation to protect themselves from web-based threats, but rather embrace the “defense in depth” strategy and establish a well-rounded cyber defense posture.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, browser isolation)
