The XG Files: Falcon C2 Flying Under The (Browser) Radar
Palo Alto Networks researchers have identified Falcon, a command and control framework that compromises victims' browsers by running malicious JavaScript. The actor leveraged Falcon to compromise visitors of webmail portals and government web applications by placing malicious JavaScript directly within these sites.
The Falcon framework is designed to remain semi-hidden, with management panels displaying a blank page that disables the right-click context menu. To deter casual inspection, the login form stays hidden until the F9 key is pressed three consecutive times; any other keystroke resets the counter.
Once triggered, the page displays a branded Falcon panel featuring a stylized bird logo and credential input fields. This operational security mechanism ensures that it does not directly expose the login page to bots, unintended visitors, and automated systems that grab webpage screenshots.
Falcon is written in NodeJS and has two listeners, one for the management panel interface on TCP port 8080 and the victim-facing listener on TCP port 443. On the victim-facing listener, the attackers observed a JavaScript-based version of the classic game Tetris serving as the default page, designed to blend in further.
Another instance hosted a game of Snake, creating a deceptive environment that appears harmless to casual visitors. This dual-use of gaming content serves as a sophisticated cover for the malicious activities occurring behind the scenes.
Technical overlaps with PeckBirdy
In January 2026, Trend Micro reported on a scripting framework dubbed PeckBirdy, which exploited living-off-the-land binaries. Our comparison with PeckBirdy revealed that it shares near-identical URL structures, payload delivery mechanisms, and communication protocols with Falcon.
Both frameworks use the same payload delivery sequence to execute HTA, HTML, or JScript payloads, with the primary distinction being Falcon's inclusion of the /config/ path prefix. Both frameworks also use AES for data encryption, with PeckBirdy relying solely on AES with a predetermined encryption key, whereas Falcon negotiates an AES session key with the server, encrypted with RSA.
Most significantly, both frameworks store their persistent session ID using the same Baidu-mimicking naming convention. PeckBirdy writes its session ID to a browser cookie prefixed with Hm_lvt_, while Falcon employs the same prefix for the same purpose, saving it as Hm_lvt_$ in the browser's local storage and Hm_lvt__ within a browser cookie.
Based on these extensive technical overlaps, we assess with high confidence that Falcon and PeckBirdy represent variants of the same core framework.
How the implant works
When someone visits a website affected by Falcon, the website sends a request to the Falcon C2 server, which generates an implant uniquely obfuscated for that browser session. The implant is generated by two files: victim_common.js, which holds the configuration block, and victim.js, which contains common functions for communication and command execution.
The two files are combined and then passed through an obfuscation routine that XOR encodes each character in the implant with a one-byte key and converts the result into an integer. This results in a script with a large list of integers and a small section of code to decode and execute itself.
The implant generates a persistent 32-character lower case alphanumeric session identifier per victim using a three-tier storage strategy designed to survive session restarts. This includes browser local storage, a cookie with an expiry date of the year 2099, and the Falcon extension storage cache if the victim has the extension installed.
The implant establishes a TLS encrypted WebSocket connection to maintain a persistent connection as long as the browser tab of the affected webpage is open. It sends a heartbeat message every minute to keep the connection alive, resetting the timer on every inbound message so an actively engaged session never emits standalone heartbeats.
The implant leverages the browser's native Web Crypto API to encrypt all exchanged data using AES. If the Web Crypto API is unavailable, the implant falls back to URL-encoding and Base64. The key exchange proceeds in five steps, beginning with the server offering its RSA public key upon WebSocket connection.
Following the key exchange, the implant registers with the server by sending information about its current execution environment. The data includes the current URL and domain of the tab within which the Falcon implant is running, as well as the browser's User-Agent string and client IP address.
The implant first attempts to read the remark from the browser’s local storage, specifically from the _domain_google_mark field. If unsuccessful, it then searches for the string _domain_google_mark= within the current webpage’s cookies to retrieve the remark.
The run command enables an operator to execute arbitrary JavaScript code through evaluation by calling eval. The set_remark command applies a remark to the session, helping the operator organize the sessions in the management panel. The implant implements four main command APIs that attackers can use in custom modules to exfiltrate data, notify an operator, or annotate the session in the Falcon database.
Related
