Microsoft’s security team dropped a warning on November 11: threat actors are planting GSocket — a legitimate open-source remote access tool — on Linux servers during initial compromise, and those backdoors survive patching. Detections rose 356.2% between March and August 2026. If you patched the original CVE but skipped a post-compromise investigation, your server may still have an active backdoor sitting quietly on the relay network.
What GSocket Is (and Why It’s Hard to Stop)
GSocket, short for Global Socket, is a real tool with real legitimate uses. Network engineers and sysadmins use it to reach machines behind strict firewalls without a VPN. What makes it dangerous when weaponized is the same thing that makes it useful: it routes traffic through the public Global Socket Relay Network, with both endpoints connecting outbound. There is no attacker-owned server, no IP address, no domain to block.
Sessions are matched by a shared secret. That means once a GSocket client is planted on your server, an attacker can reconnect from anywhere, at any time, using just that secret. Egress filtering, IP blocklists, and DNS sinkholes are all useless unless you deny outbound by default and explicitly block the relay domains.
The Attack Chain: Why Patching Isn’t Enough
The sequence plays out like this: attackers exploit an unpatched PHP or cPanel application, gain access, plant GSocket, set up persistence, and leave. The victim discovers the original CVE, patches it, and considers the incident closed. The attacker reconnects via GSocket relay the next day. Nothing has changed on their end.
According to Microsoft’s analysis, GSocket persists via cron jobs, systemd services, shell startup files (.bashrc, .profile), and watchdog processes — often with multiple redundant copies. Binaries are disguised as kernel threads: one sample ran as systemd-remount-d, another used bash’s exec -a to launch under the name [kaluad]. Unless you go looking for these artifacts specifically, you won’t find them during a routine patch cycle.
| Traditional Backdoor | GSocket |
|---|---|
| Attacker-owned C2 server | No attacker infrastructure |
| IP or domain to block | Shared secret only — nothing to block |
| Requires inbound listener | Outbound-only, bypasses firewalls and NAT |
| One persistence mechanism | Five or more redundant persistence layers |
The Dirty Frag Escalation
Some attackers pair GSocket with CVE-2026-43284, a Linux kernel privilege escalation bug dubbed Dirty Frag. The flaw has been in the kernel since version 4.11.0 — that’s 2017 — and carries a CVSS score of 8.8. It exploits unsafe in-place decryption of socket buffer fragments during ESP processing via splice(2) or sendfile(2), giving an attacker an arbitrary page cache write that escalates an unprivileged shell to root.
Exploitation only requires the ability to create user namespaces and access to one setuid binary — sudo, passwd, or fusermount on most Linux systems. If your kernel isn’t on 5.15.206, 6.1.172, or 6.6.138, you’re exposed.
Who Is Being Targeted
Web application and hosting environments account for 87.1% of GSocket incidents, with PHP applications and cPanel hosting making up 63.9% of that group and Apache servers another 24.3%. The heaviest targeting by sector falls on education and research organizations, followed by technology and communications, manufacturing, and government entities. If you run Linux PHP hosts in any of those sectors, this is not theoretical.
Detection and Remediation
Microsoft’s hunting queries flag gs-netcat or gsocket in process names and command lines. Beyond that, check the following indicators on any server that was recently compromised:
# Paths to inspect
/dev/shm/.gs-*/ # GSocket staging directory
/dev/shm/.gs-0/gs-netcat_mini-linux-x86_64
# Suspicious process names to look for
systemd-remount-d
defunct.service
[kaluad]
# Domains to block egress to
gsocket[.]io
cdn[.]gsocket[.]io
gsgg[.]b-cdn[.]netRemove the GSocket binary and all persistence entries — cron, systemd, startup files, watchdogs — then verify that outbound connections to the relay domains have stopped. Microsoft’s recommendation: if the full scope of compromise is unclear, rebuild the host.
Hardening Steps
To reduce exposure going forward:
- Apply deny-by-default egress rules and explicitly block the GSocket relay domains
- Mount
/dev/shmand/tmpwithnoexecto prevent execution of staged binaries from memory-backed directories - Patch Dirty Frag: kernel 5.15.206, 6.1.172, or 6.6.138 (see Ubuntu’s patch guide)
- Add post-compromise investigation to your incident response playbook — not just patching the disclosed CVE
Patching the initial vulnerability is table stakes, not remediation. Any intrusion that reached your server should be treated as a potential GSocket installation until proven otherwise. The 356% detection spike is not a statistical curiosity — it reflects a systematic shift in how post-compromise persistence works. Treat it accordingly.
