GSocket backdoor on Linux web servers: check PHP, cPanel and Apache hosts for compromise

What happened

On 11 November 2026 Microsoft published research on several separate groups of attackers who install GSocket on compromised Linux servers. BleepingComputer reported on it on 12 November 2026. GSocket is a legitimate open-source remote access tool. Once it runs on a server, both the server and the attacker make outbound connections to a public relay service, the Global Socket Relay Network. The relay then joins the two into an encrypted session. The server needs no open port and no public IP address. The attackers do not run any infrastructure of their own, so there is no attacker IP address or domain to block.

This is not a vulnerability in GSocket. The attackers first break into an internet-facing web application, then install GSocket to keep their access. Because GSocket runs separately from the application, patching the application does not remove it. Microsoft says GSocket-related detections in its telemetry rose by 356.2% between March and August 2026.

Microsoft describes the attacks as follows:

• The attackers exploit a web application and use curl to download and run an install script.
• The script places the GSocket client in writable or memory-backed paths such as /dev/shm.
• The process is disguised under names that look like kernel threads, for example [kaluad], or under system-like names such as systemd-remount-d and /usr/bin/defunct.
• Persistence is set up through cron jobs, systemd services, shell startup files, watchdogs and extra copies. Staging files are then deleted and file timestamps backdated.
• In a few cases the attackers tried to gain root through the Linux kernel flaw CVE-2026-43284, known as "Dirty Frag".

Who is affected

Linux servers that run internet-facing web applications that were compromised at some point. In Microsoft's data, 87.1% of incidents involved web applications and hosting. Within that group, PHP web applications and cPanel hosting made up 63.9% and Apache 24.3%. Microsoft also lists alerts for shells started from Java and Node.js web applications. Servers where a web application flaw was found and patched recently are especially worth checking, because the attackers may have got in before the patch.

Servers whose web applications were never compromised are not affected. GSocket installed on purpose by your own team is not a sign of compromise in itself.

What to do now

1. Check every internet-facing Linux web server using the steps in the next section. Start with servers where a web application, CMS, plugin or hosting panel flaw was patched in recent months.
2. If you find GSocket, treat the server as compromised. Stop the process. Then remove the binary, every copy and every autostart entry: cron, systemd units, shell startup files and watchdog scripts. Microsoft notes that the persistence is often layered, so killing the process alone does not remove access. If the attackers may have gained root, for example through CVE-2026-43284, the safest choice is to rebuild the server from a clean image or a backup made before the compromise.
3. Change the credentials on an affected server: database passwords, application secrets, API keys and SSH keys. Also check authorized_keys for unknown entries.
4. Find and close the way in. Update web applications, CMS platforms, plugins and application servers. Remove components you do not use and restrict file-upload and admin paths.
5. Patch the kernel against CVE-2026-43284 ("Dirty Frag") with your distribution's kernel update, and reboot into the new kernel.
6. Restrict outbound traffic. Where you can, block outbound connections by default and allow only the destinations a server needs. GSocket traffic is outbound only, so inbound firewall rules do not catch it.
7. Harden temporary directories. Where it is practical, mount /tmp and /dev/shm with noexec.
8. Verify afterwards that the server no longer connects to the GSocket relay or the domains listed below.

How to check whether you are affected

Run these checks as root. A hit is not proof on its own, but it should be investigated.

Files and paths named by Microsoft:

ls -la /dev/shm/.gs-* /tmp/.gsn_ora /tmp/systemd-remount-d /usr/bin/systemd-remount-d /usr/bin/defunct 2>/dev/null
find / -xdev \( -name 'gs-netcat*' -o -name 'defunct.service' -o -name 'defunct' -o -name 'systemd-remount-d' \) 2>/dev/null

Running processes:

ps -eo pid,ppid,user,args | grep -Ei 'gs-netcat|gsocket|defunct|remount-d' | grep -v grep

Real kernel threads have no executable file. If a process with a bracketed name such as [kaluad] points to a file, it is suspicious:

for p in /proc/[0-9]*; do n=$(cat $p/cmdline 2>/dev/null | tr '\0' ' '); case "$n" in \[*) e=$(readlink $p/exe 2>/dev/null); [ -n "$e" ] && echo "${p#/proc/} $n -> $e";; esac; done

Persistence:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
systemctl list-unit-files --type=service | grep -Ei 'defunct|remount'
grep -sEl 'gs-netcat|gsocket|defunct|GS_' /etc/profile /etc/profile.d/* /etc/bash.bashrc /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile

Look carefully at systemd units whose names look plausible but that you did not create. Check the home directories of web-service accounts such as www-data, apache and nobody, and of cPanel users.

Known file hashes (SHA-256) from Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Network and logs: Search DNS, proxy and firewall logs for gsocket.io, cdn.gsocket.io and gsgg.b-cdn.net. These domains are used to download the tool. Also search shell history and web server logs for commands that fetch gsocket.io/y or gsocket.io/install.sh with curl. Look for shells started by the web server or PHP processes. Use ss -tnp to check which processes hold outbound connections, and look into any you cannot account for. Keep in mind that the attackers delete staging files and command history, so missing traces in one place do not prove the server is clean.

Sources

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/