Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Microsoft observed multiple incidents in which threat actors deployed GSocket, an open source remote access tool, on compromised Linux servers. Threat actors used Gsocket to maintain access even after the vulnerabilities used for initial compromise were remediated. This turned a single web application compromise into persistent access that outlasted the remediation of the original vulnerabilities. Defenders investigating affected hosts should look for evidence of GSocket deployment, persistence, privilege escalation, and outbound connections, rather than treating application patching alone as complete remediation.
Microsoft Defender for Endpoint telemetry shows this activity growing over recent months and concentrated on web applications and hosting environments. GSocket relays traffic through a shared public network, so there is no threat actor-owned IP address or domain to block.
When one RCE stops being just one RCE
Exploiting a web application vulnerability gives a threat actor command execution in the context of the web server process. That access lasts only while the vulnerability remains unpatched and the service keeps running. Patching the application or restarting the service can remove it.
To keep access, threat actors typically add a persistence mechanism, and each common option has drawbacks. SSH keys added to authorized_keys are easy for administrators to find during an audit. Reverse shells depend on threat actor-controlled servers that defenders can block or sinkhole. Custom implants require ongoing development and maintenance. The same trade-offs apply when initial access comes through remote access services or cloud shell sessions.
GSocket addresses these drawbacks, which helps explain why multiple unrelated threat actors have adopted it.
Shared relay infrastructure. Traffic passes through the Global Socket Relay Network, a public relay service. The threat actor does not register or host any infrastructure, so there is no threat actor-owned IP address or domain to block. Organizations can still restrict access to the relay itself.
Outbound-only connections. The compromised host and the operator both connect outbound to the relay, which bridges the two sessions. The host needs no inbound listener or public IP address, and network address translation does not prevent the connection. Inbound firewall rules do not see this traffic, although egress filtering and outbound monitoring can.
Built-in evasion and persistence. The deployment script can rename the process, stage files in memory-backed directories, and install persistence that survives a reboot, without additional development by the threat actor.
The same relay model that supports legitimate remote administration also gives threat actors a way to maintain access without operating dedicated C2 infrastructure. Once GSocket runs on a compromised server, the server and the operator each connect outbound to the Global Socket Relay Network, which pairs the two sessions over an end-to-end encrypted channel.
Figure 1: After code execution on an internet-facing application, GSocket is deployed and both ends connect outward to the relay.
Because GSocket runs independently of the exploited application, patching the vulnerability does not remove the relay client or its persistence.
Microsoft Defender for Endpoint telemetry shows that this activity is not limited to a single compromise. From March through August 2026, devices with GSocket-related detections increased 356.2%, although the increase was not consistent month to month.
Figure 2: Growth in GSocket-related detections from March to August, measured against the March baseline.
Web applications and hosting accounted for 87.1% of attributable Microsoft Defender for Endpoint incidents in the analysed telemetry. Within that group, PHP web applications and cPanel hosting represented 63.9% of incidents and Apache represented 24.3% (Figure 3).
Figure 3: Distribution of GSocket-related incidents by application category. PHP web applications and Apache account for most incidents within the web applications and hosting group.
Education and research accounted for the largest share of affected organizations (30.7%), followed by technology and telecommunications (22.9%).
Figure 4: Distribution of affected organizations by sector.
These figures reflect the share of affected organizations and do not indicate that threat actors selected these sectors deliberately. Exposure is the more likely factor: academic institutions often run large, decentralized web estates maintained outside central IT, which are harder to inventory and patch.
Observed attack chains
The RCE-based intrusions in this analysis followed a similar sequence after initial access. Threat actors compromised an internet-facing application, profiled the host, transferred and concealed the relay tooling, and used the resulting channel for command and control. Some intrusions also included persistence and privilege escalation. Figure 5 combines these behaviours into a generalized attack chain. Not every stage occurred in every intrusion.
Figure 5: Generalized GSocket attack chain observed across RCE-based intrusions, mapped to MITRE ATT&CK.
How threat actors deploy and operate GSocket
Initial access and deployment: Threat actors exploited internet-facing web applications and used curl to download and execute a remote script. The script profiled the host, selected a GSocket client matching the system architecture, staged it in writable or memory-backed paths such as /dev/shm, and established encrypted outbound command and control through the Global Socket Relay Network.
Figure 6: Encoded RCE command executed through a vulnerable PHP application.
Defense evasion and persistence: Threat actors disguised GSocket with kernel-thread-like process names, persisted through cron, systemd, shell profiles, watchdogs, and redundant copies, then removed staging files and other deployment indicators.
Figure 7: Kernel thread names used to disguise the GSocket process.Figure 8: Persistence entries created during GSocket deployment.
Privilege escalation: After gaining execution as the web-service account, in few observed incidents, threat actors attempted to exploit CVE-2026-43284, one of the recent Linux kernel vulnerabilities also known as Dirty Frag, to elevate privileges to root.
How GSocket reconnects without a fixed C2 address
GSocket identifies endpoints by a shared secret instead of an IP address or hostname. During installation, the deployment script typically generates a random secret and writes it to standard output. The threat actor can choose to read the secret from the console, redirect it to a temporary file and retrieve the file before is deleted, or have it delivered through a supported notification channel, such as Telegram (configured with GS_TG_TOKEN and GS_TG_CHATID), Discord, or a webhook. With this secret, the operator can reconnect later from any compatible GSocket client, without knowing the victim’s IP address, hostname, or network location.
A traditional reverse shell connects to a threat actor-controlled IP address written into the payload. GSocket instead derives its connection identifier and authentication material from the shared secret. The compromised host and the operator each connect outbound to the Global Socket Relay Network (GSRN), which matches them and brokers an end-to-end encrypted session. Neither endpoint needs a public IP address, an inbound listener, or a permissive inbound firewall rule.
As a result, blocking an IP address or domain is unlikely to cut off access. The connection relies on a shared relay service, outbound traffic that is commonly permitted, and a secret that does not need to be hardcoded in the payload. Anyone with the shared secret can reconnect through the relay without knowing the compromised host’s IP address or hostname.
Mitigation and protection guidance
For an affected Linux server, remediation should address both the initial compromise and the GSocket deployment.
Patch and harden internet-facing applications. Keep web applications, CMS platforms, plugins, and application servers current. Remove unused components and restrict file-upload and administrative paths.
Remediate the host as well as the vulnerability. Do not treat application patching as complete remediation. Investigate and remove the GSocket client, associated persistence, and staged files, then verify that outbound connections to the relay infrastructure have stopped
Patch and harden internet-facing applications. Keep web applications, CMS platforms, plugins, and application servers current. Remove unused components and restrict file-upload and administrative paths.
Constrain outbound traffic. Apply deny-by-default egress rules, allow only required destinations, and monitor connections to relay infrastructure.
Harden the host runtime. Mount temporary and memory-backed directories as non-executable where feasible, and alert on execution from hidden or world-writable paths.
Audit persistence surfaces. Review cron entries, systemd units with plausible service names, and shell startup files. Persistence is often layered across several mechanisms, so stopping the running process alone does not remove access.
Prioritize local privilege-escalation patching on internet-facing servers. In the analyzed activity, threat actors attempted to exploit CVE-2026-43284 to escalate from the web-service account to root. Separately, Microsoft FORGE Lab recently documented 59 Linux kernel bug reports, including eight vulnerabilities for which researchers demonstrated local root privilege-escalation exploits in controlled environments.
Enable Microsoft Defender for Endpoint on Linux. Keep real-time and cloud-delivered protection enabled, with behavior monitoring for anomalous child processes of web services and masqueraded process identities.
Microsoft Defender detections
Microsoft Defender for Endpoint provides visibility into activity associated with GSocket-related Linux intrusions, including suspicious shell execution, payload delivery, persistence, defense evasion, and remote communication. The alerts below were observed in the analyzed telemetry. An individual alert does not establish the initial access method or confirm that every stage of an intrusion succeeded.
Tactic
Observed activity
Example alerts observed in analyzed telemetry
Initial access, Execution
Shells and commands launched from web servers and application runtimes
– Possible Web Server compromise activity – Suspicious shell execution from PHP application – Suspicious shell execution from web server application – Suspicious shell execution from a scripting application runtime – Suspicious remote command execution via Java Web application – Suspicious remote command execution through Node web application
Execution
GSocket and gs-netcat tooling launched on the host
– ‘GsNetcat’ hacktool was prevented – ‘GsNetcat’ hacktool was blocked and was active – An active ‘GsNetcat’ hacktool was blocked – An active ‘GsNetcat’ hacktool process was detected while executing and terminated
Execution, Payload delivery
Shell commands and scripts used to retrieve, prepare, and launch payloads
– Suspicious shell command execution – Suspicious piped command launched – Suspicious script launched – Executable permission added to file or directory – Suspicious file dropped and launched – Suspicious file or content ingress
Persistence
Cron jobs and Linux services created for recurring execution and continued access
– Suspicious cron job creation – Suspicious Linux service created
Defense evasion
Hidden file execution, obfuscation, timestomping and removal of binaries or history traces.
– Hidden file executed – Suspicious file or information obfuscation detected – Suspicious deletion of launched process binary – Attempt to clear command history – Suspicious timestamp modification
Discovery
Reconnaissance and collection of local system information
– Reconnaissance activity – Suspicious process collected data from local system
Command and control
Reverse-shell behavior and communication with GSocket domains
– Possible reverse shell – Suspicious communication with a remote target
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate incident response or investigation tasks related to this threat:
Incident investigation: correlate web-service process ancestry, relay client deployment, persistence changes, and outbound activity into a single timeline for the affected host.
Threat actor profile: summarize observed GSocket tradecraft and related tooling seen in the environment.
Device summary: assess the affected Linux host, its exposed application, and follow-on activity after initial execution.
Advanced hunting queries
Microsoft Defender XDR customers can use the following queries to surface GSocket-related activity. The queries use public Advanced Hunting tables populated by Microsoft Defender for Endpoint and cover deployment patterns observed in the analyzed intrusions.
Matches should be investigated in context with process ancestry, execution context, persistence changes, and related network activity.
GSocket process activity
Looks for GSocket tooling by name or command line.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName has_any ("gs-netcat", "gsocket")
or ProcessCommandLine has_any ("gsocket.io", "gs-netcat", "gsnetcat")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc
Installer download activity
Looks for the download-and-execute pattern used to fetch GSocket.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "gsocket.io"
or ProcessCommandLine has "gsgg.b-cdn.net"
| project Timestamp, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc
Connections to observed distribution hosts
These are tool distribution endpoints, not threat actor-owned command and control.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("gsocket.io", "gsgg.b-cdn.net")
| project Timestamp, DeviceName, ActionType, RemoteUrl, RemoteIP, RemotePort,
InitiatingProcessFileName, InitiatingProcessAccountName
| order by Timestamp desc
Known file hashes
Matches the SHA-256 hashes published in the indicators of compromise section.
let badSHA256 = dynamic([
"d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa",
"f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5",
"55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f",
"12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c"
]);
DeviceFileEvents
| where Timestamp > ago(7d)
| where SHA256 in~ (badSHA256)
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
Staging and persistence artifacts
Useful when hashes are missing or a different build is used.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath startswith "/dev/shm/.gs-"
or FileName in~ ("systemd-remount-d", ".gsn_ora", "defunct", "defunct.service")
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
MITRE ATT&CK techniques observed
The following techniques were observed across the analyzed intrusions. Not every technique occurred in every intrusion, and some outcomes, such as persistence across reboot and successful relay session establishment, were not confirmed in every case.
Initial access
T1190 Exploit Public-Facing Application | Internet-facing web applications were exploited to gain command execution in the web service context. Follow-on commands were launched as children of web server and application runtime processes, consistent with exploitation of an exposed application.
T1053.003 Scheduled Task/Job: Cron | Cron entries were created in the same detection window as GSocket deployment script activity, consistent with persistence.
T1036 Masquerading | A GsNetcat binary executed as systemd-remount-d, a system service-like filename. In a separate execution context, bash used exec -a to present /usr/bin/defunct with the argument-zero name [kaluad].
T1105 Ingress Tool Transfer | curl downloaded gs-netcat payloads from GSocket distribution endpoints into /dev/shm/.gs-0.
T1090.002 Proxy: External Proxy | GSocket clients were launched with options that establish outbound sessions to the Global Socket Relay Network, a shared public relay that brokers the connection between the compromised host and the operator. The relay is third-party infrastructure and is not owned by the threat actor.
Indicators of compromise
The indicators below were observed in the analyzed telemetry. They represent specific observations from these intrusions rather than a complete inventory of GSocket tooling or infrastructure.
Indicator
Type
Description
gsocket[.]io
Domain
Script and installer retrieval
cdn[.]gsocket[.]io
Domain
Client binary distribution
gsgg[.]b-cdn[.]net
Domain
Client binary distribution
hxxps://gsocket[.]io/y
URL
Script retrieval in download-and-execute commands
hxxps://gsocket[.]io/install.sh
URL
Installer retrieval target; successful retrieval not established
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
At Microsoft’s FORGE Lab, we used codename MDASH to scan a subset of Linux kernel subsystems from late May to mid-June 2026. One full-time researcher and one intern led this three-month effort, which has so far produced 59 public upstream reports and 33 assigned CVEs. We confirmed working root privilege-escalation exploits for eight of those CVEs, and fixes for 38 of our reports have been merged into mainline.
Finding the bugs was only part of the work. The initial scans produced 26,502 raw findings in about two weeks, but turning those results into reproducible bugs, upstream reports, and patches took months of expert investigation and collaboration with Linux maintainers.
In this post, we look back at how we went from thousands of potential findings to validated vulnerabilities and upstream fixes, and what we learned about scaling vulnerability discovery with AI.
From scans to reports
We focused on several core kernel subsystems, such as networking, filesystems, and security modules. Our selection criteria were straightforward: we picked security-sensitive components with no obvious dependence on specialized hardware, making QEMU-based validation simple and unified. Code scanning mainly used Sonnet 4.6 (71.1% of code-scanning tokens), GPT-5.4 (20.1%), and GPT-5.5 (7.1%).
The codename MDASH scans produced 26,502 raw scan findings in about two weeks on two servers (64 cores/256 GB RAM and 32 cores/128 GB RAM), but turning that output into patches and reports took months of expert work. We filtered out low-confidence claims using codename MDASH’s confidence levels and separate fast screening agents we built, reducing the pool to 11,769 candidates. PoC-generating agents then attempted reproduction in QEMU, mainly using GPT-5.5 (77.3% of reproduction tokens), Opus 4.6 (13.2%), and GPT-5.5-cyber (9.4%). Experts then reviewed the 621 cases with PoC evidence to identify root causes, merge duplicates, and prepare upstream submissions.
Roughly one public upstream report landed from every ten PoC-backed cases: 59 reports from 621 cases (9.5%). Across those cases, the main reasons for not filing a separate new report were:
266 (42.8%) shared a root cause with another case, so one patch could fix them together.
163 (26.2%) were not reported after review, mostly due to limited security impact.
133 (21.4%) were already reported or fixed upstream.
Submission timing explains many of the 133 overlaps. Most of the 621 cases were new when the scans finished (though some may already have been in flight by others). Our first public report went out on June 27, 2026, more than five weeks after scanning started. By September 1, 55 of the 59 had been posted to the public lists; the other four were reported privately during the same window and routed to the public lists by mid-October.
Getting fixes merged
Upstream Linux typically requires vulnerability reports to come with a working patch. Agents helped draft initial fixes, but human validation, subsystem understanding, and iterating with maintainers during review remained essential. So far, fixes for 38 of our reports have been merged into upstream mainline—half on the first submission, and the rest after one to four revisions. Reaching a mainline release from the first public patch took a median of 41 days (up to 108 days), and we are still working with maintainers on the remaining reports.
How old the bugs were
Interestingly, most of the bugs we reported had been in the kernel for years. Across the 59 reports, the average bug was 8.1 years old when we first reported it publicly. One of the oldest, a cls_u32 shift-out-of-bounds bug (CVE-2026-74544), had been there for at least 21 years.
Figure 2 . Age of reported kernel bugs, measured from the bug-introducing commit (the fix’s Fixes tag) to our first public report. Average age 8.1 years across 59 reports; six were 15–19 years old and three were at least 20 years old.
Selected findings
Among the 33 CVEs assigned so far from this batch, 24 are rated High or above (CVSS v3.1 score of at least 7.0). Below are eight CVEs for which we confirmed local root privilege-escalation exploits in controlled laboratory environments, with some cases requiring non-default settings or disabled exploit mitigations:
CVE-2026-64563 is a one-line state-reset bug in rhashtable, the Linux kernel’s shared resizable hash table. Because callers trust the object pointers returned by a table walk, this small library flaw enabled a stable local privilege escalation on Linux—and affected Android with SELinux enforcing—without requiring special kernel configurations or user namespaces.
Many kernel subsystems store live objects, such as sockets, in rhashtable and walk the table when user space asks to list them. Because a large listing may be split across several replies, a walk can pause and resume. Its iterator saves where it stopped, including a pointer to the last visited entry (iter->p). While the walk is paused, however, the table can still change: entries can be removed and freed, and resizing can replace the underlying bucket table.
Old table freed by a resize (iter->walker.tbl == NULL): lines 877–882 switch to the new table, reset slot and skip, and return -EAGAIN early without clearing iter->p:
Old table still present (iter->walker.tbl != NULL): lines 884–919 scan the bucket chain for iter->p and reset iter->p = NULL if the entry was removed.
After that restart, the next call to rhashtable_walk_next() sees iter->p still set and follows iter->p->next instead of starting over at slot = 0. If that entry was freed while the walk was paused, dereferencing iter->p->next reads from freed memory.
Why did this bug go unnoticed for eight years? Triggering it requires three conditions to line up in the same walk: the caller must pause and resume the same iterator across walk_stop() and walk_start(), a table resize must free the old bucket table during that pause, and the entry at iter->p must also be removed and freed before the walk resumes. Most rhashtable walkers finish in a single pass without ever resuming a stopped iterator, and even when a caller does pause and resume, those three events rarely coincide by accident in normal workloads.
The upstream fix simply clears the stale pointer before returning:
+ iter->p = NULL;
From a socket listing to a kernel write
Because rhashtable is a shared library, its callers determine both whether this bug is reachable and how severe its security impact can be. Across the kernel, there are about two dozen files that use the rhashtable walker API, and most walk the table in a single pass and immediately exit. Among those callers, we found two that pause and resume an iterator across batches and can at least cause a crash: TIPC’s socket dump (tipc_nl_sk_walk()) and Netlink’s socket diagnostics (__netlink_diag_dump()).
Of the two, __netlink_diag_dump() is the exploitable caller. It is reachable by unprivileged users on standard kernels, and user space controls the pause between dump replies (via recvmsg()). An attacker can hold a dump paused while resizing the table and freeing the socket at iter->p, then reallocate that memory to control iter->p->next—causing rhashtable_walk_next() to return a fake socket pointer sk.
__netlink_diag_dump() then checks net_eq(sock_net(sk), net) and passes sk to sk_diag_fill() and sock_diag_save_cookie(), which initializes sk->sk_cookie if it is zero. That turns the fake sk pointer into a constrained 64-bit write (when the target 8 bytes are zero and sk->sk_net matches &init_net). Paired with other general exploitation techniques, this write is enough for local privilege escalation.
We thank Yuan Tan of NebuSec, who also independently found this vulnerability. He promptly shared its real severity with us and the maintainers, which helped the upstream fix, and later provided us with his working exploits for both Linux and Android. We also thank Frank Wu of NebuSec, who identified a viable exploitation primitive and developed a working privilege-escalation exploit.
Closing thoughts
Finding bugs and fixing them are drastically out of balance. Two weeks of codename MDASH scanning produced the initial findings, which we narrowed to 621 PoC-backed cases. But it took over four person-months to report 59 of them—and five months later, 38 fixes have been merged. For complex infrastructure like the Linux kernel, keeping humans in the loop is still necessary, making human effort the bottleneck. Both bug hunters and maintainers can be overwhelmed by the volume of real findings, so focusing on genuinely high-severity issues is essential.
More tokens may yield more bugs, but not a secure system. We scanned only a small fraction of the kernel, and further tuning and more tokens could uncover substantially more bugs. But even after fixing all of them, is the system secure? At Microsoft FORGE Lab, we’re using AI to expand the scope of vulnerability research, but our experience shows that discovery is only one part of the work. The more urgent problem is how to build practical security solutions that are operational, cumulative, and economically sensible.
These lessons also extend beyond our research. Through close collaboration with the engineering teams building codename MDASH, we’re applying what we learn from real-world vulnerability discovery and validation to inform how these capabilities evolve. The goal is to bring advances in AI-powered security research into the hands of security teams, helping them identify and address critical vulnerabilities more effectively.
Zoom has released software updates to address two security flaws impacting Zoom Workplace for Windows, including a critical bug that could result in privilege escalation on affected systems.
The vulnerabilities are listed below -
CVE-2026-108186 (CVSS score: 9.6) - An improper input validation vulnerability that could allow an unauthenticated user to conduct an escalation of privilege via network access.
CVE-2026-108187 (CVSS score: 8.1) - An origin validation vulnerability that could allow an unauthenticated user to conduct an escalation of privilege via network access.
Successful exploitation of either of the shortcomings could permit remote attackers to escalate privileges without requiring any special permissions or access.
While CVE-2026-108187 affects Zoom Workplace for Windows before version 7.1.5, CVE-2026-108186 impacts versions starting from 7.1.0 and before 7.1.8.
Earlier this July, the popular videoconferencing platform shipped fixes for another improper input validation flaw impacting Zoom Workplace for Windows (CVE-2026-53412, CVSS score: 9.8) that could enable an unauthenticated user to take control of accounts.
Although Zoom makes no mention of the vulnerabilities being exploited in the wild, users are advised to apply the latest patches to mitigate potential threats.
from The Hacker News https://ift.tt/2lUYBhd
via IFTTT
Cybersecurity researchers have disclosed details of a campaign in which an emerging agentic penetration testing platform called AntiFox has been used to steal Amazon Web Services (AWS) credentials and pivot laterally into compromised environments.
"In several recently observed intrusions, Alibaba Cloud systems hosting AntiFox interfaces were associated with confirmed malicious actions against internet-facing web services and associated AWS environments," Arctic Wolf Labs said in a report shared with The Hacker News.
The activity has been observed chaining together web exploitation and web shell deployment to facilitate configuration discovery, credential validation, cloud-service enumeration, secret access, and storage operations.
AntiFox, available for download from GitHub, has been described as an artificial intelligence (AI)-driven autonomous penetration testing platform. As of writing, the project has been forked 251 times and starred 474 times.
On its README page, the project maintainer states -
Given an authorized target, a planner / worker / main-agent multi-agent system runs the full engagement over a dual-graph core (a global asset graph + a per-task exploration graph) — recon → attack-surface discovery → exploitation → finding capture → report delivery — fully observable, interactive, and deliverable
Unlike most automated pentest tools that are "great at discovery, but stop at discovery," AntiFox puts its weight on delivery — turning what the AI finds into a report that an engineer can understand, reproduce, back with evidence, and hand straight to the client.
According to Arctic Wolf, some of the initial access activity is associated with a compromised internet-facing Internet Information Services (IIS) application. The access is then leveraged to create an ASPX web shell using "w3wp.exe," the IIS worker process, and run operating system commands to perform the following actions -
Run PowerShell commands to locate web.config files and configuration backups
Read application settings and database connection strings
Enumerate debug and error-log directories
Attempts to connect to an internal production database using a credential extracted from the application configuration
Copy configuration and log files into a web-accessible upload directory
"On a compromised IIS server, commands run through w3wp.exe identified the execution context with whoami, enumerated the application directory, checked permissions with icacls, and tested the ability to write files into the web root," Arctic Wolf said.
"The creation of an ASPX web shell by w3wp.exe, followed by command execution through the same IIS worker process, suggests compromise through the affected web application."
The precise vulnerability used to achieve code execution on the IIS server is not known. In other attacks, the threat actor is said to have started with a valid AWS credential obtained through as-yet-undetermined means.
AntiFox Demo
Specifically, this involved abusing valid IAM identities to validate credentials and enumerate dozens of services, including IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB, and Amazon Bedrock.
While a majority of these authenticated cross-service API requests ended up with an "AccessDenied" error, some of the discovery and secret-access operations were successful, according to the cybersecurity company.
In at least some instances, the activity has been observed progressing beyond Secrets Manager enumeration to a successful GetSecretValue request against a production secret. Elsewhere, a valid AWS identity was used for S3 discovery and object operations via API calls.
"Agentic frameworks such as these make penetration testing techniques more accessible to threat actors, while increasing the speed and consistency with which these techniques can be applied in live attacks," Arctic Wolf said.
The disclosure comes as threat actors are increasingly weaponizing AI-powered penetration testing tools like ARTEX to conduct broad-scale attacks across the world, enabling them to automate various stages of an intrusion with minimal human intervention.
The integration of AI has allowed adversaries, both large and small, to adapt established tradecraft and deploy them at machine speed, making it possible to progress from scanning GitHub for secrets to exfiltrating data from an Azure Key Vault in five minutes.
Earlier this week, VECERT disclosed details of a campaign dubbed Operation Ghost-Campus orchestrated by a Chinese threat actor that uses AI agents to maintain perpetual, cost-free access to large language models (LLMs) and eventually perform automated academic fraud and steal data belonging to over 5,000 students enrolled at the Fengxian Campus.
"The agent industrializes the creation of accounts on the search engine fofa.info, scans the global cyberspace for misconfigured servers, extracts API keys for OpenAI and DeepSeek, automatically verifies their financial balances, and injects them into the attacker's development environment," VECERT said.
"This stolen computing power fuels an interactive GoTTY terminal ('Pi — AI Coding Assistant') and, by extension, provides intelligence to the scripts that sustain academic fraud bots ('heartbeat' bots) and extractors of financial data and personally identifiable information (PII) belonging to thousands of students at the Fengxian Campus."
According to data from Censys, there are 1,465 hosts running an exposed ARTEX console as of November 4, 2026, with most of them located in the U.S., Hong Kong, China, Japan, Singapore, and South Korea. However, it's worth noting that not every instance is necessarily malicious in nature.
In a separate report, Check Point Research said it identified 2,557 systems that hosted ARTEX, including 10 misconfigured instances exposing their full databases.
"In many observed cases, ARTEX required remarkably little interaction from its operators once an objective had been established," Check Point said. "Rather than continuously directing attacks step by step, operators frequently issued a goal and left the agent fleet to work toward it. Human interactions were largely limited to checking progress, asking whether a target had been compromised or occasionally adjusting priorities."
The vast majority of the attacks are designed to siphon cryptocurrency, steal Apple code-signing certificates, compromise gaming accounts, and conduct denial-of-service (DoS) attacks against gambling websites. The activity has been found to exploit vulnerabilities related to weak or hard-coded passwords, missing authentication, insecure direct object references, and remote code execution.
In the campaign targeting Apple code-signing certificates, ARTEX agents searched compromised systems for certificate databases, followed by validating the stolen certificates by checking passwords, private keys, Apple revocation status, expiration dates, and associated provisioning profiles.
Ultimately, the activity is estimated to have harvested more than 300 certificates and their passwords, out of which three certificates passed the full validation process and could be used to sign arbitrary iOS applications.
The biggest change brought by agentic hacking to the cyber threat landscape is scale and speed, Check Point cautioned, as a cybercriminal with limited technical skills can task AI agents with investigating a number of targets in parallel and exploiting them using known and zero-day vulnerabilities with less manual effort.
"Its relevance to us lies in its scale, speed and persistence," CERT-EU said in an alert. "ARTEX can test large numbers of low-complexity misconfigurations, including those a human tester would notice but not have time to check, and it can work through long attack chains without the fatigue that limits manual testing."
"The same is true of complex payload crafting. Exploitation paths that need carefully tailored payloads often take more effort than the severity of the finding justifies, so a manual assessment may leave them untested."
Tools like AntiFox and ARTEX are part of a broader set of about 45 open-source agentic attack frameworks that are engineered to connect to an LLM and can act on outputs autonomously. They fall under five broad categories -
Network kill chain capable of end-to-end reconnaissance, exploitation, and post-exploitation: PentAGI, RedAmon, and DarkMoon
Web-app and API: Strix, Shannon, and PentestGPT
C2-integrated: Sage, echidna, Pojun, and FORANG
Harnesses: RAPTOR, CyberStrike, cyber-harness, Nebula and Cybermes
Research prototypes: Incalmo, hackingBuddyGPT, VulnBot, HackSynth, AutoPT, and Ares
"Each framework has public source code and wires a model into a loop that runs tools and acts on their output," GitGuardian said.
"Agentic AI pentesting tools hand their agent a shell and web access, so the model can assemble a pipeline at runtime. A GitHub search, a scanner download, and a found key passed to the next call are all one prompt away, even though none of it ships in the repository."
from The Hacker News https://ift.tt/DbMWcSB
via IFTTT
Unit 42 has identified Falcon (aka XG or Xiàng Gē), which is a command and control (C2) framework that compromises victims' browsers by running malicious JavaScript. An actor leveraged Falcon to compromise visitors of webmail portals and government web applications by placing malicious JavaScript directly within these sites.
Operating entirely inside the browser context, attackers have used the framework to sideload malicious Chrome extensions and steal the following information:
Passwords
Emails
Session cookies
Communications
Falcon also served as a delivery mechanism for an implant we call Antino, which uses Microsoft OneDrive as a C2 channel.
Our analysis identified the compromise of government entities in one Middle Eastern country and four Southeast Asian countries between March and May 2026. The campaigns we observed targeted ministries of foreign affairs, defense and interior, and law enforcement agencies, consistent with strategic intelligence collection objectives.
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:
Falcon C2 management panels are designed to remain semi-hidden. When accessed, the panel displays a blank page with no visible branding or login interface.
To deter casual inspection, the page disables the right-click context menu via a global contextmenu listener that calls preventDefault(). The login form also stays hidden until the F9 key is pressed three consecutive times; any other keystroke resets the counter.
Figure 1 below shows the JavaScript code for this key tracking.
Figure 1. F9 key Tracking.
Once triggered, the page displays a branded Falcon panel featuring a stylized bird logo and credential input fields. This operational security (OPSEC) mechanism ensures that it does not directly expose the login page to bots, unintended visitors and automated systems that grab webpage screenshots.
Figure 2 below shows a screenshot of the login panel.
Figure 2. The Falcon login panel is revealed after pressing F9 three times.
Falcon is written in NodeJS and has two listeners. One listener is for the management panel interface on TCP port 8080 and the victim-facing listener is on TCP port 443.
On the victim-facing listener, we 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. Figure 3 below shows both versions.
Figure 3. JavaScript version of Tetris and Snake hosted on the C2 server.
Overlap with PeckBirdy
In January 2026, Trend Micro reported on a scripting framework dubbed PeckBirdy. They described it as a versatile tool for exploiting living-off-the-land (LotL) binaries (LOLBins).
Our comparison with PeckBirdy revealed that it shares near-identical URL structures, payload delivery mechanisms and communication protocols with Falcon. Table 1 compares the URL structures of the two frameworks.
Falcon
PeckBirdy
Description
hxxps[:]//{domain}/config/{ATTACK_ID}
hxxps[:]//{domain}/{ATTACK_ID}
Standard payload
hxxps[:]//{domain}/config/{ATTACK_ID}/hta
hxxps[:]//{domain}/{ATTACK_ID}/hta
HTA application loader
hxxps[:]//{domain}/config/{ATTACK_ID}/html
hxxps[:]//{domain}/{ATTACK_ID}/html
HTML loader
hxxps[:]//{domain}/config/{ATTACK_ID}/wscript
hxxps[:]//{domain}/{ATTACK_ID}/wscript
JScript loader for HTA
Table 1. URL structure comparison between Falcon and PeckBirdy.
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 use AES for data encryption. PeckBirdy relies 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_
Falcon employs the same prefix for the same purpose, saving it as Hm_lvt_$ in the browser’s local storage and Hm_lvt__<session ID> 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.
The Falcon Implant
When someone visits a website affected by Falcon, the website sends a request to the Falcon C2 server. The server generates an implant uniquely obfuscated for that browser session. The implant is generated by two files: victim_common.js and victim.js.
The first file holds the configuration block described below and the second file 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.
The result is a script with a large list of integers and a small section of code to decode and execute itself. Figure 4 shows an example of the obfuscated script.
Figure 4. Deobfuscation script in Falcon implant.
Figure 5 shows the template configuration block. The $CLIENT_IP is the victim IP address, set by the server as it generates the implant.
Figure 5. Falcon implant configuration.
Victim Persistence and Tracking
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:
Browser local storage: Reading and writing a key Hm_lvt_$, likely mimicking Baidu Analytics tracking identifiers to blend with legitimate Chinese web analytics telemetry
Cookie: Setting Hm_lvt__<session ID>=1 with a path of / and an expiry date of the year 2099
Falcon extension storage cache: Checking whether a storageApi object is defined; if so, the session ID is stored there as well
The storageApi is a dictionary within the Falcon browser extension, meaning it is present only if the victim has the Falcon browser extension installed. We detail the browser extension in the Falcon Browser Extension section.
C2 Communication
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 {"heartbeat":"1"} every minute to keep the connection alive. The implant resets the timer on every inbound message, so an actively engaged session never emits standalone heartbeats.
The code supports a fallback protocol using the Comet communication protocol. If Comet is used, payload data exchanged with the C2 server is not encrypted. The WebSocket functionality supports AES encryption in combination with the TLS transport encryption as described below.
Cryptographic Key Exchange
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:
Step 1: The server offers its RSA public key
Upon WebSocket connection, the server pushes a message with an action pubkey containing a 2048-bit RSA public key in PEM format, as illustrated in Figure 6.
Figure 6. Server pubkey message.
Step 2: The client generates 256-bit AES session key material
The implant generates a 32-byte AES key and a 16-byte initialization vector (IV) using the browser's crypto.getRandomValues. If unavailable, a fallback function generates the key material from an alphanumeric string.
Step 3: The client encrypts the session key material using the server’s RSA public key
Both the AES key and IV are individually encrypted using the server's RSA public key and then Base64-encoded.
Step 4: The client sends the encrypted AES key material to the server
The client sends the encrypted key material to the server in a key_exchange message, as shown in Figure 7.
Figure 7. Client key exchange message.
Step 5: All subsequent exchanges have their payload data encrypted with the session key material using AES-256-CBC.
Command Dispatch
Following the key exchange, the implant registers with the server by sending information about its current execution environment. Figure 8 below shows the data before encryption.
Figure 8. Falcon implant session registration.
The data includes the current URL and domain of the tab within which the Falcon implant is running. The data also includes the browser's User-Agent string and client IP address (set by the backend server during implant generation).
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.
If the implant uses Comet for communication, it only supports the run and nothing commands, with the latter serving no operational purpose.
The run command enables an operator to execute arbitrary JavaScript code through evaluation by calling eval. The set_remark command applies a remark (or label/comment) to the session, helping the operator organize the sessions in the management panel. It updates the remark for the fields _domain_google_mark across the browser's local storage, document cookie and Falcon extension storage.
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. Table 2 below details the APIs.
Function
Purpose
xg_note
Set session label (remark)
xg_send
Send arbitrary JSON to the C2
xg_data
Exfiltrate arbitrary data
xg_notify
Send notification via Telegram
Table 2. Main command APIs.
Falcon Browser Extension
While the browser implant runs purely in the context of the browser tab, Falcon has two browser extensions to facilitate full control of a victim’s browser:
One for Firefox
One for Chrome
The extensions work with the implant.
We are currently unaware of how an operator is deploying these browser extensions. It is likely that they are using an initial implant to trick a target into installing the browser extension and granting the operator unfettered browser access.
The two extensions are functionally identical, this section focuses on the Chrome extension.
The extension masquerades as a PDF reader, as shown in Figure 9, using the name PDF Viewer.
Figure 9. Browser extension icon used by Falcon.
The extension consists of 14 files, as detailed below in Table 3.
File
Description
sandbox.html
C2 command executor, message dispatcher
sandbox.js
page.js
Unused code, likely remnants from development
page.html
offscreen.html
Extension bootstrapping and setting up an internal MessageChannel messaging bus and downloading the Falcon implant.
offscreen.js
background.js
Background service worker that stores collected data in a first in, first out (FIFO) cache such as credentials, network requests and clipboard data.
Monitors the browser’s credentials store for credentials, cookies, history and downloads.
twitter-dm.js
Scrapes username and direct messages from Twitter/X when a user authenticates on x[.]com.
content-script.js
Clipboard manipulation, credential theft, network hooking, web storage theft. Sends data through background.js for exfiltration.
analytics-core.js
Hook fetch and XMLHttpRequest intercept HTTP requests
manifest.json
Extension manifest
icon16.png
Extension icons
icon128.png
icon48.png
Table 3. Falcon Extension Files.
An operator generates the extension bundle in the management panel, which provides the operator a ZIP archive that is ready to install in a victim’s browser. As manually installing an extension in Chrome involves many steps, it is possible that an operator instead socially engineered a victim into downloading and executing a small deployment utility that installed the extension via the command line.
We have observed evidence in the management panel that the operator possesses a utility for silent plugin installation for Chrome and Firefox as Figure 10 below shows. However, we have not been able to recover a sample for further analysis.
Figure 10. Falcon management panel (tools).
The operator can upload tools to the management panel and password protect them, preventing other people from accessing them. The panel shows that there are two tools uploaded. Table 4 below shows the translated columns.
The extension requests a total of 40 permissions that grant the operator full control over the victim’s browser. These permissions include access to credentials, cookies and browser network traffic. Figure 11 below shows the extension manifest.
Figure 11. Falcon browser extension manifest.
The manifest parameters are described below in Table 5.
Parameters
Description
manifest_version
Defines the manifest version (3)
name
Extension name (PDF Viewer)
version
Extension version (2026.5.13.1)
description
Extension description (Portable Document Format)
permissions
Individual permissions required by the extension (40 total)
host_permissions
A list of websites the extension is permitted to interact with and read data from. <all urls> specifies that the extension has access to all visited websites.
background
Defines the filename for the background service worker (background.js)
content_scripts
A list of scripts that should run on every URL that matches a certain criteria. The first script injects a content-script.js in all websites visited by a victim after the page has fully loaded. The second script injects twitter-dm.js on URLs matching x[.]com and twitter[.]com, more details in the Twitter Direct Message Exfiltration section.
sandbox
Defines the context from which untrusted code executes (sandbox.html)
content_security_policy
Defines the sandbox security policy and accessible objects
web_accessible_resources
Declares resources that are world accessible (by other webpages). Extension resources not listed here would result in a cross-origin resource sharing (CORS) error.
Table 5. Falcon extension manifest parameters.
Extension Initialization
When the extension is installed, enabled, or the browser starts, Chrome parses the extension manifest. The background service worker, background.js, runs and creates a hidden or offscreen document from the offscreen.html file.
The offscreen.html file loads offscreen.js (hereafter referred to as offscreen) and creates an iframe to load sandbox.html (which loads sandbox.js, hereafter referred to as sandbox) in parallel.
This structure is common for Chrome extensions that need offscreen documents. The sandbox acts as a code execution environment, allowing eval execution.
Offscreen starts by creating a MessageChannel message bus for communication
between extension components. It delays execution for 2 seconds to allow the message bus to be established before sending a request to the C2 server to download the Falcon implant. The code is passed to the sandbox through the message bus as shown in Figure 12.
Figure 12. Falcon implant code message bus call.
The code is executed by appending a script tag to the sandbox.html document body. The implant code, now running inside the sandbox, establishes a WebSocket connection to the C2 server.
In parallel with the background/offscreen initialization, Chrome automatically injects content-script.js (hereafter referred to as content script) into every page visited by the victim due to its manifest definition in content_scripts.
The twitter-dm.js script is injected only if a victim visits twitter[.]com or x[.]com as defined in the manifest. The content script runs in an isolated context and only has access to the webpage's Document Object Model (DOM), but not to its JavaScript context.
To achieve full page context access, the content script injects a script tag into the page pointing to chrome-extension://<extension ID>/analytics-core.js (hereafter called analytics core). Because the analytics core file is defined in web_accessible_resources in the manifest, it is accessible to web pages and not blocked by CORS.
At this point, the extension has:
Full access to the browser's data store (via chrome.* APIs in background.js)
Full access to the context of every webpage the victim visits (via the content script and analytics core)
Web Proxy
Falcon allows an operator to use a victim’s browser as a proxy server and to use the victim’s browser data store, including session cookies and credentials for requests. An operator creates a proxy and attaches it to the victim’s Falcon session.
The operator then configures the victim’s browser with the Falcon server address and the designated proxy port. The operator is then able to send requests to the Falcon implant within the victim’s browser, with these requests encapsulated in a JavaScript snippet. They will then be sent to the victim’s browser as illustrated below in Figure 13.
Figure 13. Falcon proxy capability overview.
The sandbox receives and executes the JavaScript. This script calls handleProxyRequest with the request data as an argument, which subsequently sends a message on the Chrome runtime message bus as shown in Figure 14.
The background service worker picks up the messages, constructs the request and sets the fetchOptions to use the victim's credential store in the request. Figure 15 below shows this, highlighted in bold.
Figure 15. Falcon browser extension credential store usage.
The response from the request is Base64-encoded and returned in JSON via the C2 WebSocket. This enables an operator to browse resources using the identity of the victim, allowing for session hijacking and access to internal network resources.
Download Intercept
The extension can intercept and replace file downloads according to operator-defined rules. The operator can define broad rules targeting a list of domain and file extensions.
Figure 16 below shows an example rule that intercepts and replaces all executable downloads from google[.]com and dl.google[.]com with an operator-controlled URL.
The background service worker installs an event listener that listens for chrome.downloads.onCreated events. When detected, the background worker sends a message to offscreen over the Chrome runtime message bus, which it relays to the sandbox.
The sandbox applies the intercept rule set to the download URL to determine whether it should modify the URL. While the background service worker has the necessary privileges to intercept and replace downloads, the extension's architectural design keeps the intercept rules and C2 command processing (which requires eval execution) within the sandbox. This design necessitates passing messages across the message buses.
If the URL matches a rule, the extension cancels the original file transfer and removes the download from the Chrome download history. The new URL consists of the target and redirect URL, where the target URL is encoded and appended to the end of the redirect URL as shown below in Figure 17.
Figure 17. Download intercept modified URL.
The download retains the original filename and will appear to the victim as ChromeSetup.exe while the origins will show as evil[.]com.
This technique enables an operator to achieve code execution on the victim’s system by intercepting a legitimate download and replacing it with the operator’s payload. It does so leaving little evidence that the file originated from a malicious source. The operator can use this to deploy additional malware and gain a stronger foothold in the target network.
Network Hooking
The functionality of analytics core is to install a hook for window.fetch, XMLHttpRequest.open and XMLHttpRequest.send. This hook enables the extension to intercept requests made from the current webpage and any third-party scripts loaded on the page. The operator can also define intercept rules that can replace a URL with an operator’s own URL (e.g., to hijack software updates).
For window.fetch, the hook intercepts HTTP requests that result in an HTTP 200 response and sets the content type to application/json or contains text/. The intercepted request and response data is posted to the MessageChannel as shown below in Figure 18.
Figure 18. Intercepted HTTP request (fetch) passed on MessageChannel.
For calls to XMLHttpRequest.send, the hook checks whether the HTTP response code is between 200 and 299, and whether the content type is application/json or contains text/. The hook also checks the responseType attribute to see whether it is text or an empty string.
The intercepted request and response data is posted to the MessageChannel as shown below in Figure 19.
Figure 19. Intercepted HTTP request (xhr) passed on MessageChannel.
The posted message signals the content script to relay the message from the MessageChannel onto Chrome’s runtime message bus using chrome.runtime.sendMessage as shown below in Figure 20.
The background worker picks up the message and stores it in a cache awaiting operator instructions to upload the data to the C2 server. The cache operates in a FIFO fashion and stores a maximum of 500 requests.
Discord Messages and Friends List Exfiltration
An operator can also target Discord chat messages and friend lists. They achieve this using passive network hooking described above, as Discord uses JSON in its HTTP communication. If configured, the operator can intercept requests matching a Discord URL pattern with victim data stored in a separate table.
Zalo Chat Database Exfiltration
Zalo is a chat application similar to WhatsApp that is popular in Vietnam. Falcon supports intercepting Zalo chat message databases using passive network hooking. Targeting Zalo provides additional insights into the targeted audience of the operator.
Gmail Exfiltration
While the ability to exfiltrate Gmail data is not a core functionality of the extension, it does provide an operator with the access needed to compromise a victim’s Gmail account and download email data. An operator issues a command that uploads a JavaScript to the extension, which sends a request to Gmail using the user’s Gmail session cookie to retrieve a list of authenticated users.
An operator can then select the accounts to collect data from, to be uploaded to the C2 server. This action is facilitated by the extension.
The exfiltrated email data includes:
Date
Receiver
Sender
Subject
Email body
Attachments
Clipboard Hijacking
As soon as the extension is installed, loaded or the browser starts, the clipboard hijacker is actively monitoring the victim’s clipboard events. It intercepts every cut, copy and paste event by adding document listeners as shown below in Figure 21.
Figure 21. Clipboard hijacker listeners.
By default, the hijacker runs without any rules. An operator has the option to define pattern matching rules and replacements (e.g., replacing account numbers or cryptocurrency wallet addresses).
The rules are stored in Chrome’s local storage chrome.storage.local in a key clipboard_replacer_rules. Figure 22 below shows an example rule.
Intercepted clipboard events are passed as messages on Chrome’s message bus. These messages are picked up by the background worker and stored in a cache similar to the intercepted HTTP requests. They then await an operator command to upload the data.
X/Twitter Direct Messages Exfiltration
The extension comes with a separate module for scraping direct messages from the X/Twitter social media platform. The module is defined in the extension manifest under content_scripts and is injected into any webpage whose URL matches the patterns *://*.twitter.com/* or *://*.x.com/*.
The module can only scrape direct messages when a victim browses a conversation. It cannot enumerate conversations or open other conversations.
The module is notable for using X and Y coordinate systems to identify messages received (left) and sent by the account owner (right), leveraging X/Twitter’s CSS layout. Along with the messages, the module extracts attachment references (URLs) and the associated timestamp. It attempts to translate the timestamp into a uniform format.
Because X/Twitter uses “today” or “yesterday” instead of timestamps for the most recent messages, the module attempts to convert them into timestamps. We found that the module supports six different languages, as shown below in Table 6.
English
Today
Yesterday
Chinese
今天
昨天
Spanish
Hoy
Ayer
French
Aujourd'hui
Hier
German
Heute
Gestern
Italian
Oggi
Ieri
Table 6. Module language support.
This language support provides insight into the target demographic to extract Twitter/X direct messages.
Continuously Monitoring - Credentials Store, History and Downloads
The extension supports monitoring for sensitive information. It collects some information automatically when the extension is loaded, other information requires an operator to issue a command to enable monitoring. Table 7 shows the various collectors and how they are enabled.
Collector
Collects
Description
Credentials
Passwords, autofill forms
Continuously collects data and stores it in the background service worker’s cache. Only the 500 latest entries are kept in the cache.
Cookies
Cookies
Collects all browser cookies and exfiltrates them to the C2 server. Requires manual issuance of command.
Clipboard
Copy, cut and paste events
As described in the earlier section.
Browser history
Full browser history
Collects full browser history, exfiltrated to the C2 server directly. Requires manual issuance of command.
Download history
Full file download history
Collects detailed history of all downloaded files.
The Falcon framework shows a high level of complexity in both design and capability. However, the overall code exhibits characteristics suggesting the malware authors likely used AI to assist with design and development. This conclusion is based on the coding style, including variable naming and code comments.
There are also inconsistent design choices that make little sense to a human developer. For example, the network hook for XMLHttpRequest checks for an HTTP response code greater than or equal to 200 but less than 300, while the hook for fetch checks against response.ok. Both result in the same outcome while the first is rarely, if ever, used when the response.ok shortcut exists.
Campaign Tracking
Falcon uses unique attack identifiers to organize campaigns. We identified campaigns targeting government entities across at least five countries, as shown in Table 8.
Region
Targets
Middle Eastern Country
Ministry of Defense
Ministry of Interior
Ministry of Foreign Affairs
National Agency for Network Services
Telecom Provider
Government email systems
Southeast Asian country A
Police Entity
Directorate of Intelligence
Department of Corrections
Southeast Asian country B
Justice Entity
Southeast Asian country C
Military Entity
Department of Justice
Southeast Asian country D
Ministry of Foreign Affairs
Table 8. Campaign victims identified.
While all five campaigns leveraged Falcon as their primary C2 framework, each exhibited distinct tradecraft in implant delivery and target selection, demonstrating how the operators tailored their approach to specific environments.
The operator compromised the Middle Eastern country's Ministry of Foreign Affairs Roundcube webmail portal by inserting a script tag that loads the Falcon implant. This enabled the operator to intercept credentials and monitor user sessions.
In Southeast Asian country A, the operator used Falcon to load a custom username-harvesting module. This was followed later by a fake Adobe Flash update prompt that attempted to deliver the Antino implant to pre-selected users.
In Southeast Asian country B, the operator used the Falcon Chrome extension mimicking a PDF viewer to establish persistent access from a browser context.
In Southeast Asian country C, a separate Falcon campaign targeted a military entity.
The following sections detail our analysis of the campaign associated with the Middle Eastern country and Southeast Asian countries A and B.
Middle Eastern Country (Roundcube Webmail)
In April 2026, we observed a Falcon implant residing on the Roundcube webmail portal of a Middle Eastern Ministry of Foreign Affairs. The actor had injected a <script> tag into the portal header as shown in Figure 23.
Figure 23. Falcon implant tag injection.
The resource config_r5lfmqe3 returns the obfuscated JavaScript Falcon implant. This enables the actor to intercept credentials as users sign in. Based on the analyzed data, we assess with high confidence that the script executes on each Roundcube visited by a victim, granting the operator access to a victim’s inbox and account settings.
We observed a total of 39 Roundcube instances being affected within the target country. We have no evidence of any instances affected outside of the target country, suggesting this was a highly targeted campaign.
Southeast Asian Country A - Police Entity (Username Harvesting and Antino Implant Deployment)
In May 2026, we observed the Falcon implant deployed in a web application belonging to a Southeast Asian police entity. The operator deployed a custom Falcon module to harvest usernames and later target specific victims by displaying a fake Adobe Flash Player update prompt with a specific username.
The first module targets the text content of the HTML element with the ID leftusername. It reports the contents to the Falcon C2 using the built-in function xg_note.
This function annotates the session in the Falcon database and sets the implant’s remark attribute. This enables the operator to know which session corresponds to which username. Figure 24 below shows code from this first module.
Figure 24. Falcon custom module for harvesting usernames from internal systems.Figure 25. Falcon custom module for displaying a fake Adobe Flash Player update pop-up.
The module first extracts the text contents of the leftusername element, as the harvesting module does. It compares the username against a hard-coded list of targeted usernames.
If the username matches and the fake Adobe Flash Player pop-up (shown below in Figure 26) has been shown fewer than 10 times, the module displays the pop-up shown below. The pop-up count is stored in the browser’s local storage in a key called popup_count.
Figure 26. Fake Adobe Flash Player update prompt.
Clicking the upgrade button serves the user with an implant, Antino, documented in the section: Antonio Implant. The payload was served from hxxps[:]//microsoft-flash[.]com/download/Adobe_installer.exe.
Southeast Asian Country B - Justice Entity (Falcon Browser Extension)
In early 2026, we identified the compromise of an entity affiliated with a national justice department in a Southeast Asian country. Unlike other campaigns attributed to this actor, this intrusion likely relied on a different initial access vector: a malicious Chrome browser extension.
The extension (ID: mbidcmlcbgbphpoacojjbmfpohcimjji) mimicked a legitimate PDF viewer. It was sideloaded in Chrome's developer mode and ran persistently in the victim's browser with a broad permission set, as documented in the section: Falcon Browser Extension.
Communication with the operator's infrastructure was maintained over a long-lived WebSocket originating from the extension's own sandbox context. The compromised browser checked in every 3-4 minutes for more than 3 weeks.
Beyond ambient data collection, the extension provided the operator with persistent visibility into the victim's day-to-day work inside the national justice department's internal document system. This document system is used to route, print and track official correspondence between high-ranking officials and subordinate staff.
On one occasion, while the victim was actively viewing a routing slip in that system, we observed the operator capture a full-page screenshot of the rendered document. The captured document was a request for the approval of the release of persons deprived of liberty. This demonstrates the actor's willingness to conduct hands-on collection when material of intelligence value appeared during the victim's session, rather than relying solely on the extension's automated telemetry.
Alongside the screenshot, the extension exfiltrated plaintext credentials for the same system and recorded more than 20 additional routing-slip page views spanning late April–mid-May 2026. This demonstrates both the operator's interest in classified internal documents and their ability to independently replay access to the system.
Antino Implant
Antino is written in Rust and dates back to at least Oct. 6, 2025, based on the compilation timestamp of the earliest known sample. The name originates from the filename of the oldest known sample antino-client.exe, along with PDB strings in the binary, such as antino_client.pdb.
The Antino configuration is stored in the .cfg PE section and is XOR-encoded as Figure 27 below shows.
Figure 27. Antino encoded configuration.
The .cfg section is 65,535 bytes while the configuration takes up 262 (0x106) bytes. The first 4 bytes are the length of the XOR-encoded configuration data, 258 (0x102) bytes. Antino decodes the configuration using a 2-byte key 0xABCD. The decoded configuration is in JSON format and contains Microsoft OneDrive credentials and a remark (campaign ID). Table 9 shows the decoded configuration.
Antino Configuration
Field
Value
Description
tenant_id
[REDACTED]
Microsoft OneDrive tenant ID
client_id
[REDACTED]
Microsoft OneDrive client ID
client_secret
[REDACTED]
Microsoft OneDrive client secret
user_id
[REDACTED]
Microsoft OneDrive user ID
remark
[REDACTED]
Actor made remark, likely campaign ID
run
true
Establish persistence
launch_mode
exe
Antino launch mode, determines the behavior based on whether it is running in a DLL context (side loading) or a stand-alone executable
Table 9. Antino configuration.
Persistence
Antino uses passive execution to establish persistence in the Windows Registry. It first copies itself to the hard-coded directory %LOCALAPPDATA%\Windows GatherOSStateKit\tmp<8 char>.exe and attempts to copy two DLLs, DllSafeCheck64.dll and slc.dll, from its current directory.
Antino does not import either of these files, but we have observed it using DllSafeCheck64.dll for sideloading in older versions of Antino. This functionality is likely a remnant from those versions.
The implant then checks for the presence of a file named id. If it exists, Antino reads the contents as the bot ID. If the file does not exist, it generates a UUID string and writes it to the id file.
To achieve passive execution, the implant writes a diagnostic answer file to %TEMP%\SDIAG_<GUID>\result\result.ps1 as shown below in Figure 28. A diagnostic answer file is a configuration file that defines parameters for the diagnosed application.
Figure 28. Diagnostic answer file contents.
Antino executes the Microsoft Scripted Diagnostic Native Host utility (sdiagnhost.exe), which parses the diagnostic answer file. The first XML section highlighted in red defines the header, and the text that follows is the path required to load the Program Compatibility Wizard (PCW). The contents highlighted in purple are the answer file folder name. The contents highlighted in blue are the answer file filename. The PowerShell snippet highlighted in light magenta is ultimately executed in the context of sdiagnhost.exe and adds Antino to the Windows Registry Run key.
Command and Control
Antino uses Microsoft OneDrive for C2 and uploads a heartbeat to the antino/heartbeat/<Bot ID>.json file in the OneDrive folder as a beacon. The heartbeat contains the hostname, username and remark from the Antino configuration.
Antino searches the OneDrive root folder for files following the command_req_<Bot ID>_<timestamp>.json format. Files matching the format indicate that a command has been issued to the bot. Figure 29 below shows an example command, system_info.
Antino supports 10 commands shown below in Table 10.
Command
Description
cmd
Shell command execution
ps
PowerShell execution
system_info
System information collection
list_files
Directory listing
add_to_run
Registry Run key persistence
exit
Client shutdown
load
Download and execute a Rhai script
execute_program
Program execution
upload_file
File exfiltration via OneDrive, uploaded to antino/antino_upload/
download_file
File download from OneDrive, downloaded from antino/antino_upload/
Table 10. Antino commands.
Notably, Antino supports execution of Rhai scripts (embedded scripting for Rust) that easily extend the implants’ capabilities without compiling additional binary shellcode. We have not observed any usage of Rhai scripts in the wild.
Conclusion
Falcon's browser-native approach presents significant challenges for traditional endpoint and network security controls. It operates entirely within the browser sandbox, avoiding persistent file artifacts and encrypting all C2 traffic over WebSocket.
The discovery of Antino, a Rust-based implant that routes its C2 through Microsoft OneDrive, demonstrates further attempts to blend into network traffic. Organizations should monitor for the following anomalous activity:
Browser extensions installed in developer mode, particularly those mimicking common utilities (e.g., PDF viewers) and requesting broad permissions (e.g., <all_urls>, debugger, tabCapture, nativeMessaging, or webRequest)
Hm_lvt_ cookies or local-storage keys on internal or government web applications where Baidu Analytics has no legitimate reason to appear
<script> tags added to the templates or headers of internal webmail, ticketing or case-management portals loading resources from unfamiliar external domains, especially where the response is a heavily numeric JavaScript array with a small decoder loop
OAuth activity to Microsoft OneDrive tenants outside the organization's own tenancy, especially with repeated small JSON writes to paths such as antino/heartbeat/ or antino/antino_upload/
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Cortex Agentic Endpoint Security is designed to help discover every AI artifact and AI agent's activity across the agentic endpoint, assess its risk, enforce prevention and runtime controls and remediate violations.
Prisma Browser is designed to provide multi-layered protection against extension-based threats by preventing the side-loading of unauthorized extensions, as well as detecting, blocking, and removing malicious extensions in the event of manual user installation.’
Idira Endpoint Privilege Manager (EPM) can help enable enterprises to reduce risk, satisfy compliance and streamline operations. It helps implement least privilege via policy-driven elevation and removal of standing admin rights, and blocks risky actions such as executing unvetted applications and access to memory of other processes, while providing audit-ready evidence and unified identity governance.
Idira Identity and Access Management (IAM) can help enable secure, unified access across human, machine and AI identities, balancing granular control with a seamless user experience. Powered by SSO, phishing-resistant MFA, passwordless login and enterprise password management, Idira IAM extends intelligent privilege controls and session security across the broader workforce.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
