GSocket gives attackers persistent access to compromised Linux servers
Threat actors are deploying GSocket, an open-source remote access tool, on compromised Linux servers to preserve access after the vulnerabilities used to break in have been fixed. Microsoft reports that the activity has affected internet-facing web applications and hosting environments, where a foothold in a web-service process can be extended into a separate, persistent command-and-control channel.
The technique complicates incident response because patching the exposed application does not remove GSocket or the persistence mechanisms installed on the host. Microsoft Defender for Endpoint telemetry recorded a 356.2% increase in devices with GSocket-related detections from March through August 2026, measured against March. The increase was not consistent month to month, and the figures describe detections in Microsoft’s telemetry rather than a measure of all affected systems.
A relay replaces attacker-owned infrastructure
GSocket uses the Global Socket Relay Network (GSRN) to connect a compromised host and an operator. Both endpoints initiate outbound connections to the shared relay, which pairs them over an end-to-end encrypted session. The model does not require the victim server to accept an inbound connection or have a publicly reachable address. Network address translation and inbound firewall rules therefore do not, by themselves, prevent the connection.
Unlike a conventional reverse shell tied to an operator-controlled IP address, GSocket identifies endpoints through a shared secret. An operator with that secret can reconnect without knowing the server’s current IP address or hostname. Because the relay is shared infrastructure rather than a dedicated attacker server, defenders may have no attacker-owned domain or address to block. Egress controls and monitoring can still help limit or detect outbound connections.
The tool’s deployment script can also support concealment and persistence. In observed activity, threat actors staged files in writable or memory-backed locations, used names resembling system processes, and established recurring execution through mechanisms such as cron jobs, systemd services, shell profiles or watchdogs. Some activity included removal of staging files and other traces. These behaviors mean that stopping a running process alone may not eliminate access.
Web applications dominate observed incidents
Web applications and hosting accounted for 87.1% of attributable incidents in the analyzed Defender for Endpoint telemetry. Within that group, PHP web applications and cPanel hosting represented 63.9% of incidents, while Apache accounted for 24.3%. Education and research organizations made up 30.7% of affected organizations, followed by technology and telecommunications at 22.9%.
Those sector figures do not establish that attackers deliberately selected particular industries. Microsoft points instead to potential exposure factors, including large, decentralized web estates that may be harder to inventory and patch. The findings should be treated as a view of activity visible in the analyzed telemetry, not a complete measure of the threat across all organizations.
In the observed intrusion sequence, attackers exploited an internet-facing application, gathered information about the host, and deployed the relay tooling. Some incidents also involved persistence and attempted privilege escalation. In a few observed cases, attackers attempted to exploit CVE-2026-43284, known as Dirty Frag, to move from a web-service account to root. The source does not indicate that this escalation succeeded in every case.
Response must cover the host, not just the application
For incident responders, the central implication is that remediation must extend beyond fixing the initial vulnerability. Teams should investigate the affected Linux host for GSocket clients, staged files, suspicious process identities, altered timestamps and changes to cron, systemd and shell startup configuration. Because persistence may be layered, investigators should verify that related mechanisms have been removed and that unexpected outbound connections have stopped.
Organizations should keep internet-facing applications, content management systems, plugins and application servers current, while removing unused components and restricting unnecessary administrative or file-upload paths. Host-level controls also matter: where feasible, restrict execution from temporary or memory-backed directories and monitor web-service processes for unusual child processes or command activity.
Network teams can apply deny-by-default egress rules where operationally practical, allowing only required destinations and monitoring outbound traffic for unexpected relay communications. Blocking a single IP address or domain is unlikely to be a complete response when the connection depends on a shared relay. Defender for Endpoint detections described by Microsoft include suspicious shell execution from web applications, GSocket or gs-netcat activity, suspicious cron or Linux service creation, and communications associated with remote access behavior. Alerts should be correlated with process ancestry, host changes and network activity; a single alert does not establish how access began or prove that every stage succeeded.
Microsoft also provides Advanced Hunting queries for Defender XDR customers to identify GSocket-related process activity, installer downloads, distribution-host connections, known file hashes, and selected staging or persistence artifacts. Such matches are investigative leads, not proof of compromise. Taken together, the findings show why Linux server response needs to address both the exposed application and the independent access channel that may remain after the original flaw is patched.
