Patching the Web App Does Not Evict GSocket. Microsoft Shows Attackers Planting It on Linux Servers, Some Then Trying Dirty Frag for Root. What to Hunt, and Why Blocklists Miss It
If you patched a PHP application, a cPanel account or an Apache site on Linux this year after a remote code execution bug, patching was not the end of the job. Check the server itself for GSocket today. Look for a process named [kaluad] or another fake kernel-thread name that has an executable file behind it, for files named defunct, defunct.dat, defunct.service or systemd-remount-d, for a hidden directory named /dev/shm/.gs-0, and for any cron, systemd or shell-startup line you did not write. Then make sure the kernel is patched for CVE-2026-43284, the Dirty Frag bug, because some of these intruders tried it to become root.
Microsoft published this on November 11. Its central sentence: threat actors "used GSocket to maintain access even after the vulnerabilities used for initial compromise were remediated." GSocket is a free, open-source remote-access tool that connects two machines through a shared public relay. Nothing about it needs the original hole to stay open.
What Microsoft reported
The primary source is a Microsoft Security blog post of November 11, 2026, "The global socket: how threat actors are weaponizing GSocket for stealthy C2," by Yash Gund, Sumith Maniath and Microsoft Security Research. We read it in full. BleepingComputer's November 12 report is built on it, so this is one source.
The sequence. Attackers exploited internet-facing web applications and "used curl to download and execute a remote script." The script "profiled the host, selected a GSocket client matching the system architecture, staged it in writable or memory-backed paths such as /dev/shm," and opened an encrypted outbound channel through the Global Socket Relay Network.
Hiding and staying. They "disguised GSocket with kernel-thread-like process names, persisted through cron, systemd, shell profiles, watchdogs, and redundant copies, then removed staging files." Named examples: a binary running as systemd-remount-d; /usr/bin/defunct started under the name [kaluad]; a defunct.service unit with a multi-user.target.wants link; chmod 700 on the binary; touch used to back-date it.
Root. "In few observed incidents, threat actors attempted to exploit CVE-2026-43284, one of the recent Linux kernel vulnerabilities also known as Dirty Frag, to elevate privileges to root." Microsoft says attempted. It does not say how often it worked.
How much. Across Microsoft Defender for Endpoint telemetry, "devices with GSocket-related detections increased 356.2%" from March through August 2026, "although the increase was not consistent month to month." That is growth against Microsoft's March baseline, among devices running Defender, not a count of victims. Web applications and hosting were 87.1% of attributable incidents; within those, PHP applications and cPanel hosting were 63.9% and Apache 24.3%. Education and research was the largest share of affected organizations at 30.7%, then technology and telecommunications at 22.9%. Microsoft adds that this reflects exposure, "not that threat actors selected these sectors deliberately."
Who. Microsoft names no actor. It says multiple unrelated threat actors use the tool.
Why blocklists miss it
A normal reverse shell calls home to an address the attacker owns. Block the address and the shell dies. GSocket does not work that way. Both the infected server and the operator connect outward to the shared relay, which pairs them, and the session is end-to-end encrypted. The operator finds the server again using only a secret the install script generates, which Microsoft says can be read from the console, dropped in a temporary file, or sent to the attacker over Telegram (set with GS_TG_TOKEN and GS_TG_CHATID), Discord or a webhook.
Microsoft's conclusion: "blocking an IP address or domain is unlikely to cut off access." There is no attacker server to put on a list. What does work is controlling what your servers may connect out to.
What to do
Hunt processes. Look for gs-netcat or gsocket by name or command line, and for anything shown as a bracketed kernel thread that has an executable on disk (real kernel threads have none). Microsoft names [kaluad] and systemd-remount-d. The public GSocket deploy script, which we read on GitHub today, picks its fake name from a list that includes [kstrp], [watchdogd], [ksmd], [kswapd0], [kworker], [rcu_preempt], [netns] and [kaluad], so do not hunt one name only. Attackers can also choose their own name.
Hunt files. /dev/shm/.gs-0 and anything under /dev/shm/.gs-*, /tmp/.gsn_ora, /tmp/systemd-remount-d, /usr/bin/systemd-remount-d, /usr/bin/defunct, and a defunct.service unit. The deploy script's defaults put the secret next to the binary in a file named after it plus .dat (so defunct.dat), and may install under the user's ~/.config when it cannot write /usr/bin. The security firm Sansec has documented defunct.dat on compromised sites.
Hunt persistence. Read every user's crontab, /etc/rc.local, systemd units with plausible names and their multi-user.target.wants links, and each account's .profile and .bashrc, including the web-server account. In the public deploy script, the line it adds carries the comment "DO NOT REMOVE THIS LINE. SEED PRNG." and sets GS_ARGS with -liqD. Microsoft warns that persistence "is often layered across several mechanisms, so stopping the running process alone does not remove access."
Match the four hashes Microsoft published, all SHA-256: d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa (x86-64 client), f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5 (AArch64 client), 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f (systemd-remount-d) and 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c (/tmp/.gsn_ora). A different build gives a different hash, so a miss here proves nothing.
Look at outbound traffic and command lines for gsocket.io, cdn.gsocket.io and gsgg.b-cdn.net, where Microsoft saw the script and binaries downloaded from, and the download command itself, for example curl fetching gsocket.io/y.
If you find it, treat the server as compromised, not just the app. Keep a copy for investigation, remove the binary, the .dat secret and every persistence entry, then confirm that outbound relay traffic has stopped. Rotate whatever the web account could read. The script's own uninstall switch only helps if you trust the copy on the box. Rebuilding from a known-good image is the safer finish.
Restrict outbound traffic. Web servers rarely need to start connections to arbitrary internet hosts. Deny by default and allow only what the server needs. Microsoft also recommends mounting temporary and memory-backed directories (/tmp, /dev/shm) as non-executable where you can, and alerting on anything executed from a hidden or world-writable path.
Patch the kernel for Dirty Frag. CVE-2026-43284 is a page-cache write flaw in the kernel's ESP (IPsec) receive path, disclosed by Hyunwoo Kim on May 8, 2026 with a working exploit, and fixed in the stable kernel trees; the NVD entry lists ten stable commits. Install your distribution's fixed kernel and reboot into it. If you cannot yet, the interim workaround published with the disclosure is to unload and block the esp4, esp6 and rxrpc kernel modules, which breaks IPsec VPNs and AFS file systems on that host. We covered the chain it belongs to in May and the related Fragnesia flaw on October 29.
Dirty Frag and the federal list
We read CISA's Known Exploited Vulnerabilities catalog file this morning, version 2026.11.10 with 1,779 entries. CVE-2026-43284 is not in it, and neither is CVE-2026-43500, the RxRPC half of Dirty Frag. Microsoft's word is "attempted," which is not a confirmed successful exploitation, and that may be why. Its sibling Fragnesia, CVE-2026-46300, was added on Wednesday, October 28, with a due date of Saturday, October 31. If your patch program only follows that list, it will not prompt you for Dirty Frag yet. Patch it anyway: a web shell plus a local root bug is the exact pairing Microsoft describes.
What is not known
Which web applications or bugs were used to get in; Microsoft gives the category, not a list. How many organizations were hit; Microsoft gives percentages and a growth rate, not a count. Whether any Dirty Frag attempt succeeded. Who the attackers are. The process-name picture in Microsoft's post is an image, so the full list of disguised names it observed is not in the text we could read.
How we know, and how we checked
We read Microsoft's post in full, the BleepingComputer report, the NVD entry for CVE-2026-43284, the CISA catalog file, and the GSocket README and deploy script on GitHub. We ran nothing from GSocket. The deploy-script details above come from the current public script; an attacker can run an older version or change it.
Our edge: GSocket traffic is outbound from the victim to a relay. Our instruments sit in front of our own websites and see inbound web requests, so they cannot observe a GSocket session on anyone's server, including the relay connection itself. The one place it could touch us is an exploit attempt that carries the download command in a URL. We scanned our edge records since August 1 for gsocket, gs-netcat and gsgg.b-cdn: 368,702 blocked requests, 121,910 decoy hits and 5,594 requests that reached our origin. None matched. That zero is weak: Microsoft shows the command arriving encoded, and a plain-text search cannot read an encoded payload. Dirty Frag is a local kernel bug and has no web signature at all.
Our feed: all four hashes were already in our corpus before today. Our automated vendor-blog reader picked up three of them from Microsoft's post on November 11, and the x86-64 client hash was already held from Unit 42's October report on CL-UNK-1211 and an earlier Cisco Talos report, which tells you the same stock GSocket build turns up in unrelated intrusions. Today we added all four under one campaign tag, manual-batch-gsocket-msft-2026-11, at confidence 80, labeled GSocket and credited to Microsoft, so this activity can be audited later. These are Microsoft's indicators, not our observations. Because GSocket is a public tool, a hash match also fires on a legitimate install. A match means GSocket is on the machine, then find out who put it there.
The download domains: the same vendor-blog reader also added gsocket.io, cdn.gsocket.io and gsgg.b-cdn.net at confidence 70, and they ship in our default domains file labeled as malware. Microsoft says plainly that these are "tool distribution endpoints, not threat actor-owned command and control." Blocking them stops new GSocket downloads on your network, legitimate ones included, and does not cut an existing session, which runs through the relay. On a production web server that trade is usually worth it. On a network where admins use GSocket on purpose, it is not. Decide on purpose, not by default.
Earlier coverage: we wrote about the Dirty Frag chain in May, about the related Fragnesia flaw on October 29 (https://www.dugganusa.com/post/the-firewall-chain-needed-two-bugs-cisa-put-a-deadline-on-one-of-them-the-other-has-been-public-si), about Unit 42's CL-UNK-1211 campaign, which also used GSocket, on November 2 (https://www.dugganusa.com/post/unit42-cl-unk-1211-linux-espionage-checks-php-sudo-systemd), and about the cPGuard update-channel backdoor, where a GSocket backdoor turned up on the vendor's own server, on November 4 (https://www.dugganusa.com/post/cpguard-update-channel-root-backdoor).
Sources
Microsoft Security blog, "The global socket: how threat actors are weaponizing GSocket for stealthy C2," Yash Gund, Sumith Maniath and Microsoft Security Research, November 11, 2026, microsoft.com/en-us/security/blog/2026/11/11/global-socket-how-threat-actors-weaponizing-gsocket-stealthy-c2/. BleepingComputer, "Hackers plant GSocket on Linux servers for persistent access," Bill Toulas, November 12, 2026. BleepingComputer, Dirty Frag disclosure report, May 8, 2026. NVD, CVE-2026-43284. CISA Known Exploited Vulnerabilities catalog, version 2026.11.10. The Hacker's Choice, GSocket README and deploy script, github.com/hackerschoice/gsocket. Sansec, "Found defunct.dat on Your Site? You've Got a Problem," sansec.io/research/gsocket. Our May Dirty Frag post: https://www.dugganusa.com/post/dirty-frag-plus-nginx-rift-plus-cve-2026-43284-the-may-2026-kill-chain-nobody-is-calling-a-kill-cha
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments