The Patch Landed. The Backdoor Stayed.

You patched the hole. You closed the vulnerability, updated the server, and moved on. The attacker is still inside — because the tool they left behind does not need the hole anymore. That is the story Microsoft’s Defender team is telling about GSocket: a legitimate open-source remote access tool that multiple threat actors are now abusing to keep a grip on Linux servers long after the original break-in is fixed. Detections of malicious GSocket activity are up 356.2% since March, and the reason is simple — this backdoor does not wait to be found. It calls out.

The trick: both sides call out

Most backdoors work like a burglar leaving a window unlocked: the attacker knocks on the server’s door, and something on the inside answers. GSocket flips that around. It intercepts network connections and replaces the program’s normal IP-layer communication with its own transport layer, routing traffic through the Global Socket Relay Network. Both the compromised server and the attacker connect outbound to the relay, which matches the two sessions and brokers an end-to-end encrypted connection between them.

Think of it as two people both dialing the same switchboard. The switchboard connects them, and neither one ever has to publish an address. That is why the attacker can reconnect without knowing the server’s IP address or hostname — and why the usual defenses fall flat. IP- or domain-based access control lists cannot disrupt a connection whose endpoints neither side can name in advance. Inbound firewall rules do not catch it, because nothing is coming inbound. The server needs no inbound listener implant, no public IP address, and network address translation does not prevent the connection. It does not even need a dedicated command-and-control server of its own — the public relay network does that job.

The one thing that can catch it is watching what leaves the building. Microsoft’s researchers are explicit: egress filtering and outbound monitoring can spot this traffic. A server that has no business opening outbound connections to a relay network is a server worth investigating.

Web hosting is the hunting ground

The numbers show where this is landing. Of the detected incidents, 87.1% related to web applications and hosting. PHP web apps and cPanel hosting accounted for 63.9% of cases, and Apache for 24.3%. That is not a coincidence: shared hosting and web-facing servers run the PHP applications attackers break into first, and once GSocket is planted, the original web flaw can be patched without disturbing the attacker’s access.

The most-targeted sector is education and research, followed by technology and communications, manufacturing, and government entities. Universities and research labs run many Linux web servers, often with sprawling hosting environments and limited security staffing — the ideal combination for a persistence tool built to be forgotten.

How it hides on the box

GSocket does not just survive patching; it works hard not to be noticed while it does. The researchers observed attackers disguising it as kernel threads — the background processes every Linux system runs, the kind of thing an admin glances past a hundred times a day. For persistence, it leans on the three most ordinary mechanisms on a Linux box: cron jobs, systemd services, and shell startup files. Nothing exotic, nothing that trips a signature on its own. Each one is a legitimate feature doing exactly what it was designed to do, pointed at the wrong program.

That hiding-in-plain-sight approach is a pattern we have seen before on Linux servers — a backdoor that hid inside a control panel and left no trace in the logs used the same logic: the best hiding place is a feature nobody questions. In some GSocket cases, the attackers went further and attempted to exploit the “Dirty Frag” Linux kernel flaw, CVE-2026-43284, to gain root privileges on the host — turning a quiet foothold into full control. Kernel flaws are the fastest route from access to ownership, as a recent 9.8-rated Linux TCP flaw showed.

What to do now

Patching the original vulnerability is necessary — and, on its own, no longer sufficient. Microsoft’s advice starts with the tool itself: remove GSocket and its associated files from any potentially impacted server, then verify that outbound connections to its relay network have actually stopped. A removal that leaves a scheduled job behind is not a removal.

Then close the door it used. Restrict outbound traffic to predetermined destinations — servers should only be able to reach the places they need — and audit cron jobs, systemd services, and shell startup files for rogue additions. Those three spots are where this tool lives, and a five-minute review of each is the fastest way to confirm a clean box. Finally, keep the operating system and applications up to date, including patching CVE-2026-43284, the Dirty Frag kernel flaw some of these attackers tried to exploit for root.

The uncomfortable lesson here is about what patching does and does not do. A patch closes the way in. It says nothing about what the intruder left behind on the way through. GSocket is built for exactly that gap: a legitimate tool, abused to turn a patched vulnerability into a permanent address. The fix is not a harder patch. It is looking at what is running, what is scheduled, and what is calling out — and asking whether any of it should be there at all.