Microsoft said on 11th November, 2026 that threat actors are installing GSocket, an open source remote access tool, on compromised Linux servers. The foothold holds even after admins patch the flaws used to break in.
The Brief
- Microsoft Defender for Endpoint telemetry shows devices with GSocket-related detections rose 356.2% from March through August 2026.
- PHP web applications and cPanel hosting made up most incidents inside the web and hosting group Microsoft analyzed.
- GSocket relays traffic through the public Global Socket Relay Network, so defenders have no attacker-owned IP address or domain to block.
- A few intrusions included attempts to exploit CVE-2026-43284, one of the recent Linux kernel flaws known as Dirty Frag, to reach root.
Patching the web app leaves GSocket running
A web application exploit gives an attacker command execution as the web server process. That access normally ends once the app is patched or the service restarts. GSocket breaks the link because the client runs apart from the exploited app with its own persistence, Microsoft said in its Security blog analysis.
Older persistence options each carry a cost. Administrators spot SSH keys in authorized_keys during audits. Defenders can block or sinkhole the servers behind reverse shells, and custom implants need constant upkeep. GSocket sidesteps those drawbacks, which Microsoft said helps explain why multiple unrelated threat actors have adopted it.
The company’s remediation advice is blunt: “Do not treat application patching as complete remediation.” Teams need to remove the GSocket client, its persistence and its staged files, then confirm that outbound connections to the relay have stopped.
Patching a flaw may not end the intrusion. Attackers are using GSocket to keep hidden access to hacked Linux servers, with persistence through cron jobs, systemd services and other ways. Microsoft reported a 356.2% rise in GSocket-related detections from March to August 2026. https://t.co/WWm5iVX6JR
— SQ Magazine (@sqmagazine_news) November 12, 2026
Detections clustered on PHP and cPanel hosting
Microsoft measured the detection jump against a March baseline and noted it was not consistent month to month. The figures describe what Defender telemetry saw, rather than every Linux compromise worldwide.
| Measure | Share |
|---|---|
| Web applications and hosting, of attributable incidents | 87.1% |
| PHP web applications and cPanel hosting, within that group | 63.9% |
| Apache, within that group | 24.3% |
| Education and research, of affected organizations | 30.7% |
| Technology and telecommunications, of affected organizations | 22.9% |
Microsoft cautioned that the sector split doesn’t show attackers picking education on purpose. Exposure is the likelier driver, the company said. Academic institutions often run large, decentralized web estates outside central IT, and those are harder to inventory and patch.
The hosting skew fits a pattern in Microsoft’s own research. Its April write-up on cookie-controlled PHP webshells in Linux hosting environments covered the same kind of shared PHP stack. Hosting operators running cPanel have also had to deal with a separate cPanel root flaw.
A shared secret replaces the C2 address
GSocket identifies endpoints by a shared secret instead of an IP address or hostname. The deployment script usually generates a random secret and prints it to standard output. Operators can read it from the console, pull it from a temp file before deletion, or get it via Telegram, Discord or a webhook.
Both the hacked server and the operator then connect outbound to the Global Socket Relay Network (GSRN). The relay pairs the two sessions over an end-to-end encrypted channel. Neither side needs a public IP address or an inbound listener. Network address translation doesn’t stop the link, and inbound firewall rules never see the traffic.
Blocking an IP address or domain is therefore unlikely to cut access. The relay is third-party infrastructure the attacker doesn’t own. Microsoft said organizations can still restrict access to it and catch the traffic with egress filtering and outbound monitoring.
Attackers dressed the client up as kernel threads
The intrusions followed a similar sequence after initial access, Microsoft said, though not every stage appeared in every case. Attackers exploited an internet-facing web application and used curl to pull and run a remote script. That script profiled the host, picked a GSocket client matching the system architecture and staged it in paths such as /dev/shm.
Microsoft’s artifact list gets specific. One GsNetcat binary ran as systemd-remount-d, a service-like name, and bash used exec -a to launch /usr/bin/defunct under the fake name [kaluad]. Payloads sat in the hidden /dev/shm/.gs-0 directory, and touch commands backdated /usr/bin/defunct and defunct.service.
Persistence came in layers, spread across:
- cron entries
- systemd units with plausible service names
- shell startup files
- watchdog processes and redundant payload copies
Killing the running process alone therefore leaves access in place. A few intrusions went further, with attackers trying CVE-2026-43284 to move from the web-service account to root. Microsoft didn’t say whether any attempt succeeded.
Separately, Microsoft FORGE Lab recently documented 59 Linux kernel bug reports. Researchers demonstrated local root exploits for eight of those vulnerabilities in controlled environments.
Admins need to clean the host, beyond the app
Anyone who patched an exploited web app should still check the server itself. Microsoft’s hunting queries flag gs-netcat or gsocket in process names and command lines. Its indicator list adds the domains gsocket[.]io, cdn[.]gsocket[.]io and gsgg[.]b-cdn[.]net. Microsoft notes those hosts distribute the tool and aren’t attacker-owned C2.
Files under /dev/shm/.gs- and names such as systemd-remount-d, .gsn_ora or defunct.service also deserve a look.
Microsoft also recommends deny-by-default egress rules and mounting temporary and memory-backed directories as non-executable where feasible. It advises patching local privilege-escalation bugs first on internet-facing servers. Each step helps reduce risk, and none removes an installed client by itself.
The post leaves real gaps. How many devices sit behind the percentage, and which application flaws gave attackers their first foothold? Did any CVE-2026-43284 attempt reach root? Who are the unrelated actors running these campaigns?
For any Linux host that ran an exploited web app, the concrete next step is a host review of cron, systemd and shell profiles. After that comes a check that outbound relay traffic has stopped. Until both are done, anyone holding the shared secret can reconnect without knowing the server’s IP address.
