Browser isolation is a security approach that separates web browsing activities from the user’s local device by running the browser in a secure environment, such as a cloud server or virtual machine, after which the visual content is streamed to the user’s device.
Organizations frequently employ browser isolation to combat phishing attempts, shield the device from browser-delivered attacks, and discourage common command-and-control (C2 or C&C) strategies employed by attackers.
In this blog post, Mandiant presents a new method for controlling a malicious implant via C2 that can get around the three types of browser isolation that are currently in use: local, on-premises, and remote. Mandiant demonstrates how attackers can transmit commands from a server under their control to a victim device via machine-readable QR codes.
An Overview of Browser Isolation
By sandboxing the web browser in a secure environment (local or remote) and streaming the visual information back to the user’s local browser, browser isolation shields users from web-based threats. The end user has (hopefully) complete transparency over the experience. The majority of documentation states that there are three different kinds of browser isolation.
Browser Isolation Avoids Common Command-and-Control Systems
The capacity of an attacker to remotely control compromised systems through malicious implants is known as command and control (C2 or C&C). HTTP requests are the most used method for sending commands to and from a victim device:
- Through an HTTP request (for example, in the HTTP parameters, headers, or request body), the implant asks the attacker-controlled C2 server for a command.
- The command to be executed in the HTTP response (for example, in the response body or headers) is returned by the C2 server.
- After decoding the HTTP response, the implant carries out the directive.
- The implant sends another HTTP request with the command output back to the C2 server.
- After a period of “sleep,” the implant resumes the cycle.
When using a browser isolation system, this method can be problematic because the local browser only receives the HTTP response that includes the streaming engine needed to render the visual page contents of the distant browser. Only the remote browser has access to the original HTTP response (from the web server). Only a stream of pixels is supplied to the local browser to visually depict the web page; the HTTP response is rendered in the remote browser. Because the local device is unable to interpret the HTTP answer, this avoids standard HTTP-based C2.
C2 Data Transmission Using Pixels
Mandiant’s Red Team came up with a creative way to solve this issue. The C2 server provides a legitimate web page that visually displays a QR code in place of returning the C2 data in the HTTP request headers or body. After rendering the website in a local headless browser (such as Selenium), the implant takes a screenshot and scans the QR code to extract the encoded data. Even when the web page is displayed in a distant browser, an attacker can use machine-readable QR codes to transmit data from the attacker-controlled server to a malicious implant.
The implant visually produces the webpage (using the browser isolation‘s pixel streaming engine) and decodes the command from the QR code that appears on the page, rather of decoding the HTTP response for the command to run. The following is the new C2 loop:
- The implant uses the DevTools protocol to control a local headless browser.
- Through the headless browser, the implant accesses the webpage from the C2 server. The remote (isolated) browser receives this request before it finally reaches the C2 server.
- A legitimate HTML webpage containing the command data encoded in a QR code is returned by the C2 server.
- A visual stream displaying the rendered web page that was retrieved from the C2 server is initiated when the distant browser sends the pixel streaming engine back to the local browser.
- After the page has finished rendering, the implant takes a screenshot of the local browser. The QR code can be found in this screenshot.
- The embedded data is obtained by the implant by reading the QR code data from the screenshot using an embedded QR scanning library.
- The implant uses the compromised gadget to carry out the order.
- The command output is encoded in a URL parameter, and the implant navigates to a new URL (again via the local browser). Since the URL parameters might be necessary in valid situations to deliver the right web page, this parameter is sent to the distant browser and then to the C2 server.As with conventional HTTP-based C2, the command output can be decoded by the C2 server.
- After a period of “sleep,” the implant resumes the cycle.
Using Puppeteer and the Google Chrome browser in headless mode, Mandiant created a proof-of-concept (PoC) implant (but any contemporary browser may be used). In order to enable the use of Cobalt Strike’s BEACON implant while interacting via HTTP queries and QR code responses, we even went one step further and integrated the implant with the External C2 functionality.
This method works in all three types of browser isolation (local, on-premises, and remote) since it depends on the visual content of the webpage.
Although the PoC showed that this method is feasible, there are a few things to keep in mind and disadvantages:
- Using QR codes with the maximum data capacity (2,953 bytes, 177×177 grid, Error Correction Level “L”) was not practicable during Mandiant’s testing because the local browser’s visual stream of the webpage was not good enough to successfully read the contents of the QR code. Mandiant was compelled to rely on QR codes with a content limit of 2,189 bytes. Note: Depending on the Error Correction Level (ECL), a QR code may hold up to 2953 bytes per occurrence. Although they decrease the maximum data amount, higher ECL settings make the QR code easier to read.
- Each request takes about 5 seconds to successfully show and scan the QR code because of the overhead of utilizing Chrome in headless mode, the startup time of the distant browser, the needs for page rendering, and the stream of visual content from the remote browser back to the local browser. The C2 channel experiences considerable delay as a result. For instance, a BEACON payload is around 323 KiB at the time of writing. An entire BEACON payload is sent in about 12m20s at a rate of 2,189 bytes per QR code and 5s each request (~438 bytes/s, assuming every QR code is correctly scanned and every network request is processed without any issues).Even though this speed is unquestionably adequate for standard C2 tasks, other methods (like SOCKS proxying) become impractical.
- This blog post does not take into account other browser isolation security features like domain reputation, URL scanning, data loss prevention, and request heuristics. When working in browser isolation situations, offensive security experts will also need to get past these defenses.
Concluding remarks and suggestions
Mandiant illustrated a new method for establishing C2 in the event of browser isolation in this blog post. Even though this method demonstrates the shortcomings of browser isolation technology, Mandiant nevertheless suggests browser isolation as a robust defense against other kinds of assaults (such as phishing and client-side browser exploitation). To defend against web-based threats, organizations should adopt the “defense in depth” approach and create a comprehensive cyber defense posture rather than merely relying on browser isolation. Mandiant suggests the following safeguards:
- Even when browser isolation is being used, enterprises should nevertheless examine network traffic and keep an eye out for unusual usage. Due to the poor bandwidth of the C2 approach outlined in this paper, numerous HTTP requests will be necessary to transfer even tiny datasets.
- Watch for browsers in automation mode: By looking at the process command line, organizations can keep an eye on when browsers are being used in automation mode, as demonstrated in the aforementioned video. Chromium-based browsers allow other processes to manage the browser via the DevTools protocol by using parameters like –enable-automation and –remote-debugging-port. While creating a process, organizations can keep an eye out for these indicators.
Mandiant has developed a thorough grasp of the various ways attackers might compromise their targets through a number of adversarial emulation exercises and Red Team and Purple Team evaluations. For additional information, see our Technical Assurance services and get in touch with us.
