Microsoft says attackers use GSocket to keep Linux access after patching; devices with detections up 356.2%

Devices with GSocket detections rose 356.2% between March and August, and Microsoft prints no count

Microsoft's post, by Microsoft Threat Intelligence and Microsoft Security Research and dated 11 November 2026 (19:49 UTC in the page's own data), says Defender for Endpoint telemetry shows devices with GSocket related detections up 356.2% from March through August 2026, "although the increase was not consistent month to month". Derived: that is 4.56 times the March level. In the post's Figure 2 the monthly figures run +106.2% (April), +212.5% (May), +318.8% (June), +212.5% (July) and +356.2% (August), so July fell back by 106.3 percentage points (318.8 less 212.5, derived) before August set the high.

The headline claim sits above the number. Microsoft says threat actors used GSocket, an open source remote access tool, on compromised Linux servers "to maintain access even after the vulnerabilities used for initial compromise were remediated". Patching closed the door the actor came in by. The tool left behind keeps working, and Microsoft says there is "no threat actor-owned IP address or domain to block".

What the number does not establish: the post gives no count of devices, incidents, hosts, organisations or victims anywhere, only percentages against a March baseline. It names no actor ("multiple unrelated threat actors" is as far as it goes), no country, and no web application flaw used for initial access. The telemetry window ends in August; the post appeared in November.

This site's inference, not Microsoft's: each monthly figure is a whole number of sixteenths above March (17, 34, 51 and 57 sixteenths, up to rounding), which is consistent with a small March baseline such as 16 devices or a multiple of 16. The post gives no baseline, so the inference cannot be checked.

What Microsoft says happened, in the order it gives

The post describes the intrusions as one generalised chain: threat actors "compromised an internet-facing application, profiled the host, transferred and concealed the relay tooling, and used the resulting channel for command and control". Some intrusions also had persistence and privilege escalation. The post adds: "Not every stage occurred in every intrusion." The diagram follows its Figure 5 order.

Zoom

Initial access and deployment. Exploiting a web application "gives a threat actor command execution in the context of the web server process". Threat actors then used curl to fetch and run a remote script, which profiled the host, chose a client to match the architecture and staged it in a writable or memory backed path such as /dev/shm. The post's Figure 6 shows the process tree: a PHP FastCGI worker, php-fpm7.4, starting sh, then bash, then curl. This brief does not reproduce the command line in that figure.

Disguise and persistence. The post lists 5 persistence mechanisms: cron, systemd, shell profiles, watchdogs and redundant copies (derived count). Its Figure 7 prints 12 bracketed names used to make the process look like a kernel thread (derived count), among them [kswapd0] and [kaluad]. Afterwards the threat actors "removed staging files and other deployment indicators". Two limits Microsoft states itself: cron entries were created "in the same detection window" as the deployment script, which it calls "consistent with persistence", and "persistence across reboot and successful relay session establishment" were "not confirmed in every case".

Privilege escalation. "In few observed incidents", threat actors attempted to exploit CVE-2026-43284, which the post calls "also known as Dirty Frag", to reach root. Attempted is the post's verb: it does not say how many attempts succeeded. The CVE record (read the same day) was published on 8 May 2026, which is 187 days before the post (derived). Its CNA title, from the Linux CNA, is technical and does not use the nickname; Red Hat's supplier entry in the same record does, and gives "Made public" as 7 May 2026. The record carries three CVSS 3.1 base scores for one flaw: 8.8, HIGH, from the Linux CNA, and 7.8, HIGH, from each of CISA's enrichment entry and Red Hat, all with a local attack vector. The vectors differ, so the scores are not a disagreement about severity class but about complexity and scope.

A local attack vector means the attacker needs code running on the host first. In these intrusions the web service foothold supplies that; this is this site's reading, not a sentence in the post. The post also says, separately, that Microsoft FORGE Lab "recently documented 59 Linux kernel bug reports", eight of them with demonstrated local root exploits in controlled environments. That is context from the post, not a finding about these intrusions.

Why the post says actors choose this tool. It sets out three drawbacks of the usual options: SSH keys in authorized_keys are "easy for administrators to find during an audit", reverse shells "depend on threat actor-controlled servers that defenders can block or sinkhole", and custom implants "require ongoing development and maintenance". "GSocket addresses these drawbacks, which helps explain why multiple unrelated threat actors have adopted it." That explanation is Microsoft's inference; the post does not show the actors' reasons.

How it reconnects without an address of the actor's own

GSocket "identifies endpoints by a shared secret instead of an IP address or hostname". The deployment script typically generates a random secret and prints it; the operator can read it from the console, take it from a temporary file before the file is deleted, or have it sent through a notification channel, "such as Telegram (configured with GS_TG_TOKEN and GS_TG_CHATID), Discord, or a webhook". Later, "anyone with the shared secret can reconnect through the relay without knowing the compromised host's IP address or hostname". The host and the operator each connect outbound to the Global Socket Relay Network, which pairs them in an end to end encrypted session. No inbound listener or public address is needed on the host.

Zoom

"No attacker owned address" is not the same as "nothing to block". The post is careful about this, and the table sets out each address type it mentions.

The defender's control, on the post's own account, therefore sits on the host and on egress, not on a list of actor addresses. The same relay model also "supports legitimate remote administration", which is why a block on the tool's name or address is a policy choice for each organisation and not a guaranteed catch.

What the telemetry says about scale

Scale is shown only as shares. Two denominators are in play and the post does not join them: application categories are shares of "attributable" Defender for Endpoint incidents, and sectors are shares of affected organisations.

Zoom

Zoom

Derived: PHP and cPanel hosting is 55.7% of all attributable incidents and Apache 21.2%, which is 76.8% together (88.2% of the web group times 87.1%). Database services and remote access over SSH or SFTP make up the other 12.9% (derived). So the story is mostly about web applications, but not only: Microsoft's lede frames a web application compromise, while about one incident in eight in its chart is neither.

Education and research (30.7%) and technology and telecommunications (22.9%) together are 53.6% (derived). Microsoft cautions that "these figures reflect the share of affected organizations and do not indicate that threat actors selected these sectors deliberately", and offers a reason: "Exposure is the more likely factor", because academic institutions often run large, decentralised web estates outside central IT. That reason is Microsoft's inference. No country is named anywhere in the post.

"Patched" names a fix to a flaw, not to a host

An incident record that reads "vulnerability remediated" describes the application. The post's point is that the host has its own status: "Remediate the host as well as the vulnerability. Do not treat application patching as complete remediation." A ticket closed on the patch date can sit beside a relay client that is still running.

Two more labels do the work of evidence. A process list that shows [kswapd0] reads like the kernel. This site's suggestion: kernel threads are children of process 2 and have no executable file behind them, so a bracketed name with a binary path and a different parent deserves a look. And "remote access tool" or "open source" says nothing about intent: the post itself says the relay model supports legitimate remote administration, so the control has to be behaviour (what spawned it, where it lives, who it talks to), not the tool's name.

What the post states, and what it does not

Indicators of compromise are given: 16 entries (derived) of four kinds, namely 3 domains, 4 URLs, 5 file paths and 4 SHA-256 hashes, and no IP addresses. Microsoft says they "represent specific observations from these intrusions rather than a complete inventory of GSocket tooling or infrastructure", and marks one installer URL as "successful retrieval not established".

Where the post pulls two ways

No second source is used here, so these are tensions inside Microsoft's own post. They stay unresolved.

What to do, in order

Microsoft sells Defender for Endpoint, Defender XDR and Security Copilot, and the post recommends or describes all three; read its detection advice with that selling interest in mind. The first list is Microsoft's, in the post's order, with the page's repeated first item counted once.

Technical details

Everything below is printed in Microsoft's post unless marked derived. The post prints no exploit code, and this brief adds none. It also does not reproduce the encoded command in Figure 6 or the command sequence in Figure 5, because both are the tool's installer path; they are described by category above. Domains in the indicator list are defanged as Microsoft prints them. The hunting queries are copied exactly, so they contain the plain domain strings that match telemetry: treat them as text to search for and never open them.

Indicators. The post's indicator table, 16 entries, in its own defanged form. A defender searches telemetry for the paths and hashes and blocks or monitors the domains where policy allows. The post says the installer URL for the first script was a retrieval target and that successful retrieval was not established.

Domain    gsocket[.]io
Domain    cdn[.]gsocket[.]io
Domain    gsgg[.]b-cdn[.]net
URL       hxxps://gsocket[.]io/y
URL       hxxps://gsocket[.]io/install.sh
URL       hxxps://gsgg[.]b-cdn[.]net/bin/gs-netcat_mini-linux-x86_64
URL       hxxps://cdn[.]gsocket[.]io/bin/gs-netcat_mini-linux-aarch64
Filepath  /dev/shm/.gs-0/gs-netcat_mini-linux-x86_64
Filepath  /dev/shm/.gs-0/gs-netcat_mini-linux-aarch64
Filepath  /tmp/systemd-remount-d
Filepath  /usr/bin/systemd-remount-d
Filepath  /tmp/.gsn_ora
SHA256    d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
SHA256    f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
SHA256    55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
SHA256    12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

File, process and environment names. The names and paths the post prints in its text and figures, gathered in one place for a defender to search. Environment variable names are printed without values. The process chain is derived from Figure 6, with the command omitted.

# Staging and hidden paths
/dev/shm/.gs-0/             hidden staging directory (the staged gs-netcat file was removed afterwards)
/tmp/.gsn_ora               hidden file identified as a GsNetcat file
# Service like names
systemd-remount-d           GsNetcat binary executed under this name (/tmp and /usr/bin)
/usr/bin/defunct            renamed payload, chmod 700, argument zero shown as [kaluad]
defunct.service             unit referenced, with a multi-user.target.wants link
<install_dir>/defunct.dat   secret written to disk (Figure 8)
# Environment variable names
GS_TG_TOKEN   GS_TG_CHATID   (notification channel settings, text of the post)
GS_HOST   GS_OWNER   GSOCKET_ARGS   (named in Figure 5)
# Process chain (derived from Figure 6, command omitted)
php-fpm7.4 -> sh -> bash -> curl

Kernel thread names. Figure 7 of the post lists twelve bracketed names used to disguise the process. A defender compares any process presented under one of them with the facts of a real kernel thread: no executable file, parent process 2. Transcribed by this site from the figure image.

[kstrp]   [watchdogd]   [ksmd]   [kswapd0]   [card0-crtc8]
[netns]   [rcu_preempt]   [kworker]   [raid5wq]   [slub_flushwq]
[mm_percpu_wq]   [kaluad]

Persistence entries. Figure 8 shows the entries created during deployment. A systemd unit described as a "D-Bus System Connection Bus" with restart settings, an hourly cron entry, three shell startup files and a file that holds the secret. The figure's ExecStart line, which shows how the unit presents the process, is left out here. A defender reviews unit descriptions, restart settings and startup files on any host that ran a compromised web application.

Description=D-Bus System Connection Bus
Restart=always ; RestartSec=300

0 * * * *  <launcher>             # crontab
~/.bashrc , ~/.zshrc , ~/.profile   # shell startup files
<install_dir>/defunct.dat          # secret written to disk

Alerts Microsoft names. 27 alert titles (derived count) grouped by the post's tactic labels. An alert is a lead to investigate and, in the post's words, "does not establish the initial access method or confirm that every stage of an intrusion succeeded".

Initial access, Execution
  Possible Web Server compromise activity
  Suspicious shell execution from PHP application
  Suspicious shell execution from web server application
  Suspicious shell execution from a scripting application runtime
  Suspicious remote command execution via Java Web application
  Suspicious remote command execution through Node web application

Execution
  'GsNetcat' hacktool was prevented
  'GsNetcat' hacktool was blocked and was active
  An active 'GsNetcat' hacktool was blocked
  An active 'GsNetcat' hacktool process was detected while executing and terminated

Execution, Payload delivery
  Suspicious shell command execution
  Suspicious piped command launched
  Suspicious script launched
  Executable permission added to file or directory
  Suspicious file dropped and launched
  Suspicious file or content ingress

Persistence
  Suspicious cron job creation
  Suspicious Linux service created

Defense evasion
  Hidden file executed
  Suspicious file or information obfuscation detected
  Suspicious deletion of launched process binary
  Attempt to clear command history
  Suspicious timestamp modification

Discovery
  Reconnaissance activity
  Suspicious process collected data from local system

Command and control
  Possible reverse shell
  Suspicious communication with a remote target

Hunting queries. Four of the post's five Advanced Hunting queries, for Microsoft Defender XDR: process activity by name or command line, installer download activity, connections to the distribution hosts, and staging and persistence artifacts. The fifth matches the four SHA-256 values above and is not repeated. Run each in context: the post says matches should be investigated with process ancestry, execution context, persistence changes and network activity.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName has_any ("gs-netcat", "gsocket")
    or ProcessCommandLine has_any ("gsocket.io", "gs-netcat", "gsnetcat")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
    ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "gsocket.io"
    or ProcessCommandLine has "gsgg.b-cdn.net"
| project Timestamp, DeviceName, AccountName, FileName,
    ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("gsocket.io", "gsgg.b-cdn.net")
| project Timestamp, DeviceName, ActionType, RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessFileName, InitiatingProcessAccountName
| order by Timestamp desc

DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath startswith "/dev/shm/.gs-"
    or FileName in~ ("systemd-remount-d", ".gsn_ora", "defunct", "defunct.service")
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256,
    InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

The question the post leaves open

If an actor's access needs no address of its own, which log in your estate would show a web server holding a long lived outbound session to a relay it has no business using, and who reads that log after the patch ticket is closed?

Key facts