Fixing the vulnerable website did not evict the intruder. Microsoft has documented attackers installing GSocket on compromised Linux servers so they could return after the original web application flaw was patched. The separate remote-access client used a shared relay network, while cron jobs, services and other startup changes could keep it coming back.
The November 11 investigation describes multiple intrusions, not one newly discovered vulnerability or one named gang. Its central warning is practical for anyone running a website or hosting account: closing the entry point and removing an attacker’s foothold are different jobs.
From a web request to a separate foothold
In the observed chains, an exposed web application gave the attacker command execution under the web service’s account. The next step was to retrieve a deployment script. That script checked the host, selected a client for its architecture and placed files in writable locations, including the memory-backed /dev/shm directory.
This is where the incident stopped being only an application problem. The deployed gs-netcat client could communicate independently of the vulnerable website. Updating the application’s PHP, plugin or other affected component remained necessary, but did not uninstall that second program. The same distinction matters in the PHP2Shell runtime-update and incident-review workflow: a fixed runtime closes an entry route; it does not account for everything executed before the fix.
GSocket itself is a legitimate open-source remote-access tool. Its presence needs context: an approved administration tool is different from a client launched by a web worker, hidden in a temporary directory and paired with an unexplained service.
Both sides call out, so an inbound firewall is not enough
A conventional reverse shell commonly contains the address of a server operated by the attacker. GSocket uses a shared secret to identify the connection instead. The compromised server and the operator each initiate an outbound connection to the Global Socket Relay Network, which pairs them into an end-to-end encrypted session. The operator does not need the victim’s public IP address or an open inbound port.
The installation script can generate the secret and print it for the operator to collect; supported notification channels can also carry it. With the secret, someone using a compatible client can reconnect later. Changing the website’s address or looking only for a dedicated attacker domain therefore misses the mechanism.
This does not make the traffic uncontainable. Administrators can restrict outbound access to the relay infrastructure and investigate which process initiated it. The important distinction is between an attacker-owned destination, which may be absent, and the shared third-party relay service being abused.
A familiar-looking process can conceal an unfamiliar program
Microsoft observed files such as /tmp/systemd-remount-d, /usr/bin/systemd-remount-d and /tmp/.gsn_ora. Another execution used /usr/bin/defunct while presenting a kernel-thread-like process name. Some activity changed timestamps or deleted staging files, weakening the usefulness of a quick check for recently created downloads.
Persistence appeared in cron, systemd, shell startup files and watchdog arrangements. Those mechanisms explain why terminating one process can be an incomplete response: another launch point or redundant copy may start it again. They are investigation leads, not instructions to delete every similarly named legitimate service.
The researchers also saw attempts to gain root through the Linux kernel flaw CVE-2026-43284, known as Dirty Frag, in a few incidents. That escalation was a follow-on step, not the initial web entry. Microsoft cautions that not every observed chain included every stage, and successful relay connections or survival across reboot were not established in every case.
What the telemetry does—and does not—measure
Devices with GSocket-related detections increased 356.2% between March and August 2026 in Microsoft’s telemetry. That is a change in detected devices within its visibility, not a count of all compromised Linux systems. Web applications and hosting represented 87.1% of attributable incidents in the analysis; PHP applications and cPanel hosting were prominent within that group.
The report was published in November, but those measurements describe March through August. They do not establish that infections suddenly rose by that amount this week, or that every use of the tool is malicious.
Finish the host investigation after patching
For an affected server, preserve the relevant evidence and connect the web request, child process, downloaded client, startup change and outbound session into one timeline. Investigate unauthorized cron entries, systemd units and shell profiles together; remove the unauthorized client and its launch mechanisms, then verify that relay connections have stopped. Patch exposed applications and local privilege-escalation flaws, and constrain unnecessary outbound traffic.
A customer using managed hosting should ask the provider whether remediation covered the host and persistence, as well as the application update. A clean patch report answers which version is running. Closing the incident also requires an answer about the independent access channel left behind.
References
- Gund, Y., Maniath, S., and Microsoft Security Research. The global socket: how threat actors are weaponizing GSocket for stealthy C2. Microsoft Security Blog, November 11, 2026; accessed November 12, 2026. GSocket deployment, persistence and relay investigation.
