GSocket Linux backdoor: detections up 356% on web servers
Attackers keep access through an outbound relay, so patching the entry point does nothing

GSocket Linux backdoor: detections up 356% on web servers

Microsoft's security research team reported on 11 November that several unrelated threat actors are installing GSocket, a legitimate open-source remote access tool, on Linux servers they have already broken into. The tool gives them an encrypted way back in that survives the patch that closed the original hole.

What happened

GSocket (the gs-netcat client) does not listen on a port. Both the compromised server and the operator open outbound connections to the Global Socket Relay Network, which matches the two sessions by a shared secret rather than by IP address or hostname. There is no inbound listener, no public IP required, and NAT does not interfere.

That design removes the usual cleanup wins. There is no fixed command-and-control domain to block, no attacker IP to add to a deny list, and restarting the web service changes nothing. Microsoft's Defender telemetry shows GSocket detections rising 356.2 percent between March and August 2026. Of the incidents it could attribute, 87.1 percent involved web applications and hosting, with PHP applications on cPanel accounting for 63.9 percent and Apache for 24.3 percent.

In the observed intrusions, attackers reached an internet-facing application, used curl to pull a script, and dropped architecture-specific clients into hidden directories such as /dev/shm/.gs-0/. Persistence came from cron jobs, systemd services and shell startup files, with processes renamed to look like kernel threads. Some actors then tried to escalate to root with the Linux kernel flaw tracked as CVE-2026-43284.

Who is affected

Any organisation running Linux web servers, particularly shared hosting and cPanel estates:

  • Hosting providers and resellers running PHP applications behind Apache or LiteSpeed.
  • Businesses whose site was compromised earlier this year and then "cleaned" by deleting a webshell.
  • Anyone who treated a defacement or a spam-relay incident as closed once the visible payload was gone.
  • Servers running unpatched kernels, since the root escalation step depends on a local kernel flaw.

What to do now

Hunt for the tool itself, not just the vulnerability that let it in. If you find it, treat the host as compromised and rebuild from a known-good image rather than deleting files in place.

  • Search for gs-netcat binaries and hidden staging directories, starting with /dev/shm, /tmp and /var/tmp, and check for noexec on those paths.
  • Audit cron entries, systemd units and shell profiles such as .bashrc and .profile for entries you did not create.
  • Restrict outbound traffic to known destinations; only egress filtering and outbound monitoring see this traffic.
  • Patch the kernel for CVE-2026-43284 so a web-shell foothold cannot become root.
  • Rotate credentials and secrets stored on any host where GSocket is found, then verify relay connections have stopped.

What this means for South African businesses

Most South African SME websites sit on shared PHP hosting or a single cPanel VPS, which is exactly the profile in Microsoft's data. The uncomfortable part is the timeline: an SME that paid for a malware clean-up months ago may still be reachable, because removing the webshell does not remove a relay client hidden in /dev/shm. If you cannot show that a previously compromised server was rebuilt, assume the access is still there.

Source: Microsoft Security Blog - The global socket: how threat actors are weaponizing GSocket for stealthy C2.

Also on the blog

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.

Zoom Workplace for Windows CVE-2026-108186: CVSS 9.6, fixed in 7.1.8
Two unauthenticated privilege escalation flaws patched in the Windows client