GSocket Abuse on Linux Hosting Servers

GSocket abuse can give attackers persistent remote access to Linux hosting servers even after administrators patch the vulnerability used to gain access. On 11 November 2026, Microsoft reported that multiple threat actors had deployed GSocket, a legitimate open-source relay tool, on compromised Linux servers.

Web applications and hosting accounted for 87.1% of attributable incidents in the Microsoft Defender for Endpoint telemetry analyzed for the report. Within that group, PHP web applications and cPanel hosting accounted for 63.9%, and Apache accounted for 24.3%. For hosting providers, the findings highlight the importance of checking the underlying server after a web application compromise.

How GSocket abuse works

In the web application attacks Microsoft analyzed, attackers first gained code execution through an internet-facing application and then used that access to download and run a GSocket installer. Microsoft observed files staged in writable or memory-backed locations such as /dev/shm. Some GSocket processes used names that resembled Linux kernel threads.

Attackers also used cron jobs, systemd services, and shell startup files to maintain access. An unexpected unit such as defunct.service warrants investigation. For any unfamiliar service, check what it launches, which account it runs under, and when it appeared. Review the referenced executable and correlate its creation time with activity in the web and system logs.

The compromised server and the remote operator each initiate an outbound connection to the public Global Socket Relay Network, which pairs the two sessions. The relay connection can work without an inbound listener on the compromised server. Egress monitoring helps administrators identify unexpected relay traffic, and egress filtering can restrict access to the relay.

Microsoft also observed attempts to exploit a Linux kernel vulnerability to escalate privileges from a web-service account to root. Check for activity outside the affected hosting account when investigating a suspected compromise.

BitNinja WAF rules for GSocket abuse

The GSocket-related rule IDs are 409023 for WAF 2.0 and 409024 for WAF Pro.

The BitNinja Web Application Firewall inspects incoming HTTP requests to protected web applications. WAF coverage in this attack chain applies to requests that pass through the WAF and match an active rule. If a compromised server initiates an installer download or opens a relay connection, investigate that traffic using egress logs and host-level monitoring.

For WordPress environments, see the BitNinja guide to patching vulnerabilities and blocking web attacks.

What Linux hosting administrators should check

• Staged files. Look for unexpected files matching /dev/shm/.gs-* and recently created executables in directories writable by web-service accounts.
• Persistence. Review cron jobs, systemd units, and shell startup files. Check which accounts own them, what commands they run, and which files they reference.
• Running processes. Investigate unfamiliar processes with kernel-thread-like names. Check the executable path, owning account, and parent process.
• Outbound traffic. Review DNS, proxy, and firewall logs for unexpected connections to installer domains or GSocket relay infrastructure. Where possible, correlate each connection with the process that opened it.
• Initial access. Review web access and application logs to identify the affected site and entry point. Patch the vulnerable CMS, plugin, or application and apply relevant Linux kernel updates.

How to investigate GSocket abuse after patching

If you find evidence of compromise, isolate the affected host and preserve relevant logs and other evidence. Build a timeline from web requests, file creation, process launches, and outbound connections. Compare the earliest suspicious activity with the time the application was patched. Relay activity after that point can help identify persistence that survived the patch.

On shared hosting servers, check whether the activity stayed within one hosting account or reached other sites, shared directories, or system services. Use those findings to determine which credentials to rotate and which systems need further investigation. If attackers gained root access or you cannot establish the scope of the compromise, consider rebuilding the server from a trusted image. Before restoring normal service, verify that the entry point is fixed, identified persistence has been removed, and unexpected outbound activity has stopped.

For the observed attack chains and additional investigation guidance, see Microsoft’s research on GSocket abuse.