A GSocket backdoor is allowing attackers to retain covert access to compromised Linux servers after the original security flaw has been patched. Microsoft says multiple unrelated threat actors are now using the legitimate remote access toolkit in active attacks.
Microsoft reports rising GSocket backdoor activity
Microsoft published its findings on 11 November 2026 after investigating GSocket-related activity through Microsoft Defender for Endpoint telemetry. The research describes attackers exploiting internet-facing web applications, gaining command execution and then installing GSocket as a separate route back into the server.
The activity is not limited to one campaign or named threat group. Microsoft observed several unrelated actors adopting the same technique, indicating that the toolkit has become a repeatable option for maintaining access to Linux infrastructure.
Detections also increased sharply during 2026. The number of devices with GSocket-related detections rose by 356.2 per cent between March and August 2026, although Microsoft said the growth varied from month to month.
Real-world use predates the November warning. On 20 March 2026, the SANS Internet Storm Center documented a Bash installer deploying gs-netcat, creating cron and shell-profile persistence, and concealing its shared secret in a file made to resemble an SSH key.
Hosting environments account for most incidents
Linux servers supporting web applications and hosting services were the most common environments in incidents where the setting could be identified. Web application and hosting environments represented 87.1 per cent of attributable cases.
PHP applications and cPanel hosting accounted for 63.9 per cent, while Apache environments accounted for 24.3 per cent. These figures describe the environments in which the GSocket backdoor was found. They do not indicate that a particular PHP, cPanel or Apache version contains the initial vulnerability.
Microsoft has not identified one affected product range or a definitive list of vulnerable versions. Initial entry depends on whichever flaw exists in the exposed web application or hosting stack. The common element is what attackers do after obtaining a shell under the web server account.
How the GSocket backdoor survives patching
In the attacks described by Microsoft, the intruder first exploits an internet-facing application to execute commands. A command-line utility such as curl can then retrieve an installer or GSocket client, which is launched using Bash and may be placed in a writable or memory-backed location such as /dev/shm.
The toolkit includes binaries such as gs-netcat and gsocket and can operate across different architectures. Once running, the client creates an outbound connection to the public Global Socket Relay Network rather than waiting for the attacker to connect directly to an exposed port.
The compromised server and the attacker’s client both connect outward and are paired using a shared secret. Sessions are end-to-end encrypted using OpenSSL’s Secure Remote Password protocol, while the relay carries encrypted traffic between the endpoints.
This design makes the GSocket backdoor difficult to disrupt using conventional network indicators. The victim does not need a public IP address or an open inbound port, and the operator does not need to maintain a fixed command and control server.
Inbound firewall rules therefore do not see a direct connection from the attacker. Blocking one IP address or domain is also unreliable because public relay infrastructure is used and its addresses can change. The toolkit additionally supports hostnames ending in .gsocket that are redirected through the relay network.
Why fixing the web application is insufficient
The installed client runs independently from the application used for initial access. Patching the web vulnerability or restarting the affected service may close the original entry point, but it does not necessarily terminate or remove the GSocket backdoor.
If persistence has been established, the client can restart and reconnect to the relay. An attacker who retains the shared secret can return using another compatible GSocket client, even after administrators believe the initial incident has been resolved.
Persistence, concealment and privilege escalation
Microsoft observed several methods intended to make access survive reboots and avoid casual inspection. Attackers created cron jobs, installed systemd services and modified shell startup files so that the GSocket client would launch again automatically.
Some processes were renamed to resemble Linux kernel threads. This process masquerading can make malicious activity appear routine when an administrator performs a quick review of running tasks.
Earlier SANS observations provide further examples of this concealment. The installer created a ~/.ssh/putty directory, placed an ELF binary named id_rsa inside it and used a fake SSH key file to hold the shared secret. The id_rsa name concealed a gs-netcat payload rather than a genuine private key.
The documented installer script had SHA256 hash 6ce69f0a0db6c5e1479d2b05fb361846957f5ad8170f5e43c7d66928a43f3286. The associated gs-netcat ELF payload had SHA256 hash d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa.
Some actors also attempted to escalate from the web server account to root using Dirty Frag Linux kernel vulnerabilities. These flaws affect vulnerable ESP and RxRPC paths, including the esp4, esp6 and rxrpc components. Public exploit code is available, making unpatched kernels a potential post-compromise escalation route.
GSocket backdoor timeline and exploitation status
- 20 March 2026: SANS documents active GSocket deployment through a Bash installer, including cron and shell-profile persistence.
- 27 April 2026: Microsoft’s HackTool:Linux/GSocket.A malware encyclopedia entry is published and updated.
- 6 to 8 May 2026: Dirty Frag is publicly disclosed and analysed, with public proof-of-concept activity reported.
- March to August 2026: Microsoft records a 356.2 per cent increase in devices with GSocket-related detections.
- 11 November 2026: Microsoft publishes dedicated research into the weaponisation of GSocket on compromised Linux servers.
- 12 November 2026: Independent reporting expands public awareness of Microsoft’s findings without introducing new technical evidence.
Exploitation is confirmed in the wild. GSocket itself remains a legitimate open source administration toolkit, but Microsoft detects malicious use under HackTool:Linux/GSocket.A. No specific threat groups were publicly named.
What organisations should investigate now
Administrators should not treat application patching as complete incident remediation where command execution may have occurred. The affected host should be investigated for binaries, persistence entries, stolen secrets and evidence of privilege escalation.
- Search for gs-netcat and gsocket binaries, including files hidden under .ssh directories or writable temporary locations.
- Review cron jobs, systemd services, .profile files and other shell startup scripts for unexpected launch commands.
- Examine processes that imitate kernel thread names and verify their executable paths.
- Monitor outbound relay traffic and .gsocket hostname activity instead of relying solely on static IP blocking.
- Apply relevant Linux kernel updates where Dirty Frag exposure may allow escalation to root.
Where a GSocket backdoor is identified, responders should remove the client, its persistence mechanisms, staging files and stored shared secret. They should also determine how the web application was exploited and review activity performed through the surviving outbound channel.
Originally reported by cybersecuritynews.com.
