Search Česky

Actively exploited Security news

Attackers abuse GSocket for stealthy access to Linux servers

On 11 November 2026 Microsoft published an analysis of intrusions in which attackers, after breaking in through a vulnerable web application, install the legitimate open-source tool GSocket on Linux servers. The connection goes out through a shared relay network, so inbound firewall rules never see it, and the attackers keep access even after the original flaw is patched. The write-up includes paths, hashes, domains and hunting queries.

Kyberkit editorial team · · event date · reading time 5 minutes · For admins and analysts

Actively exploited: GSocket

Key points

  • Microsoft describes attackers who, after a web application breach, fetch the GSocket install script (curl | bash) and run the gs-netcat client from a hidden directory under /dev/shm.
  • Both the server and the operator connect outbound to the Global Socket Relay Network (GSRN), which pairs them over an encrypted channel. Inbound firewalls see nothing, and the attacker needs no IP address or domain of their own.
  • The attackers disguise the process as a systemd service or kernel thread, layer persistence (cron, systemd, shell profiles) and backdate file timestamps. In some cases they tried to get root through the kernel flaw CVE-2026-43284.
  • Patching the web application does not remove the access. The host has to be cleaned and you need to confirm the relay connections have stopped.

What happened

On 11 November 2026 Microsoft published an analysis of a series of intrusions in which attackers deployed GSocket, a legitimate open-source remote access tool from The Hacker's Choice, on compromised Linux servers. They use it to keep access after the administrator patches the vulnerability that let them in.

According to Microsoft Defender for Endpoint telemetry, GSocket-related detections rose 356.2% between March and August 2026, though not steadily month to month. Of the incidents where the entry point could be attributed, 87.1% involved web applications and hosting: PHP applications and cPanel hosting made up 63.9% and Apache 24.3%. The most affected sectors were education and research (30.7% of organizations) and technology and telecommunications (22.9%). Microsoft puts this down to large, decentralized web estates rather than deliberate targeting.

Microsoft does not name any threat actors in the write-up, nor the vulnerabilities used for initial access.

How the attack works

How a GSocket intrusion on a Linux server unfolds1. Attacker exploits a vulnerable web application and runs commands as the web server account; 2. Fetches the GSocket install script with curl and pipes it to bash; 3. gs-netcat is staged in a hidden /dev/shm directory and connects out to the relay network; 4. Persistence via cron, systemd and shell profiles, plus masquerading and timestomping; 5. Attacker returns through the relay at will using the shared secret1Attacker exploits a vulnerable webapplication and runs commands as theweb server account2Fetches the GSocket install scriptwith curl and pipes it to bash3gs-netcat is staged in a hidden/dev/shm directory and connects outto the relay network4Persistence via cron, systemd andshell profiles, plus masquerading andtimestomping5Attacker returns through the relay atwill using the shared secret
Based on Microsoft's analysis (11 November 2026)
  • Initial access: attackers exploited internet-facing web applications to get command execution as the web server process. Commands therefore run as children of web server or application runtime processes (PHP, Java, Node.js).
  • Installation: a script fetched with curl and run with bash profiles the host and picks a client build that matches its architecture. Payloads are staged in writable or memory-backed paths, mainly /dev/shm.
  • Privilege escalation: in a few incidents the attackers tried to go from the web service account to root using the Linux kernel flaw CVE-2026-43284 (which Microsoft calls "Dirty Frag"; NVD describes it as a bug in the ESP packet input path, published on 8 May 2026, with CVSS 3.1 scores up to 8.8).
  • Connectivity: both the server and the operator connect outbound to the Global Socket Relay Network (GSRN), which pairs the two sessions over an encrypted channel. The server needs no open port or public IP, so inbound firewall rules never see the traffic; only egress controls can. Endpoints are matched by a shared secret, not an address. The install script generates the secret, and the attacker reads it from the output, saves it to a temporary file, or has it sent via Telegram (the GS_TG_TOKEN and GS_TG_CHATID variables), Discord or a webhook.
  • Masquerading and persistence: the process ran under a service-like name (systemd-remount-d), or as /usr/bin/defunct launched under the name [kaluad] to look like a kernel thread. Persistence was often layered (cron, a defunct.service systemd unit, shell profiles, watchdogs and redundant copies), so killing the process alone did not remove access. The attackers deleted staging files and backdated file timestamps with touch.

How to tell if you were compromised

Indicators published by Microsoft (defanged). Microsoft stresses that they reflect the telemetry it analyzed and are not a complete inventory. It published no IP addresses, because the relay is shared infrastructure, not attacker servers. The domains below distribute the tool; they are not attacker C2.

Domains and URLs (script and client downloads):
gsocket[.]io
cdn[.]gsocket[.]io
gsgg[.]b-cdn[.]net
hxxps://gsocket[.]io/y
hxxps://gsocket[.]io/install.sh
hxxps://gsgg[.]b-cdn[.]net/bin/gs-netcat_mini-linux-x86_64
hxxps://cdn[.]gsocket[.]io/bin/gs-netcat_mini-linux-aarch64
Paths:
/dev/shm/.gs-0/gs-netcat_mini-linux-x86_64
/dev/shm/.gs-0/gs-netcat_mini-linux-aarch64
/tmp/systemd-remount-d
/usr/bin/systemd-remount-d
/tmp/.gsn_ora
/usr/bin/defunct
defunct.service (linked into multi-user.target.wants)
Process name: [kaluad]

SHA-256:
d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa  gs-netcat_mini-linux-x86_64
f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5  gs-netcat_mini-linux-aarch64
55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f  systemd-remount-d
12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c  .gsn_ora

Microsoft Defender flags the client as HackTool:Linux/GsNetcat.A!MTB or HackTool:Linux/GsNetcat!rfn. The write-up also includes Defender XDR advanced hunting queries (gs-netcat/gsocket processes, download commands for the domains above, network connections to them, hashes and paths).

Our tips for checking a server without EDR:

  • Look for processes and files named gs-netcat, gsocket, systemd-remount-d or defunct, and for hidden /dev/shm/.gs-* directories. A process with a bracketed, kernel-thread-style name that has an executable on disk is suspicious.
  • Review every user's crontab, including the web server account, systemd units with plausible names, and .profile, .bashrc and /etc/profile.d/.
  • In web server logs, look for requests after which the web server process spawned a shell, curl or wget. On your proxy or firewall, look for outbound connections to gsocket.io.
  • Paste logs and exports into our IOC extractor to pull out domains and hashes right in your browser.

What to do

  1. Clean the host, not just the application. Remove the GSocket client, every persistence layer and staged files, then confirm the relay connections have stopped. If compromise is confirmed, consider rebuilding the server and rotating any passwords, keys and secrets the web server account could reach.
  2. Update internet-facing web applications, CMS platforms, plugins and application servers, remove unused components, and restrict upload and admin paths.
  3. Restrict outbound traffic from servers: deny by default, allow only required destinations and monitor connections to the relay network.
  4. Harden the runtime: where feasible, mount temporary and memory-backed directories (/tmp, /dev/shm) with noexec, and alert on execution from hidden or world-writable paths.
  5. Patch kernel privilege-escalation flaws on internet-facing servers, including CVE-2026-43284.

Timeline

Timeline of GSocket abuse according to MicrosoftMar–Aug 2026: GSocket detections in Defender rise 356.2%; 8 May 2026: Kernel flaw CVE-2026-43284, tried in some intrusions, is published; 11 Nov 2026: Microsoft publishes its GSocket analysis and indicatorsMar–Aug 2026GSocket detections inDefender rise 356.2%8 May 2026Kernel flaw CVE-2026-43284,tried in some intrusions, ispublished11 Nov 2026Microsoft publishes itsGSocket analysis andindicators
Key dates (Microsoft, NVD)

Updates

  • 12 November 2026 – first version.

FAQ

Is GSocket malware?

No. It is a legitimate open-source tool for connecting two machines behind NAT or firewalls. Attackers abuse it precisely because signature-based antivirus may not flag it and its traffic looks like ordinary outbound connections. Microsoft Defender reports it as the GsNetcat hacktool.

Can I just block the attacker's IP address?

No. The attacker connects through GSocket's shared relay network, so there is no attacker-owned IP address or domain to block. Restricting server egress to required destinations and monitoring connections to the relay network are what help.

I've patched the vulnerable application. Is the server clean?

Not necessarily. Microsoft points out that attackers use GSocket precisely so they keep access after patching. Check the server as described under How to tell if you were compromised, remove the client and every persistence layer, and confirm the relay connections have stopped.

Microsoft didn't name the exploited vulnerabilities. What should I patch?

The write-up names no specific initial access flaw, only application types (PHP, cPanel, Apache, Java and Node.js). Update every internet-facing web application, CMS, plugin and application server, remove unused components, and install the kernel fix for CVE-2026-43284.

Sources

  1. Microsoft Security Blog – The global socket: how threat actors are weaponizing GSocket for stealthy C2 (11 November 2026)
  2. The Hacker's Choice – GSocket (Global Socket Toolkit) on GitHub
  3. NVD – CVE-2026-43284 (Linux kernel, ESP)

Spotted a mistake? Let us know and we will correct it openly.