Security teams managing Linux infrastructure are facing a subtle but dangerous trend: the weaponization of GSocket (Global Socket), a legitimate open-source networking tool, by multiple threat actors to establish persistent access. Unlike traditional malware that relies on known-bad signatures, GSocket's dual-use nature allows attackers to blend into administrative traffic while maintaining encrypted command-and-control (C2) channels that survive patch cycles and credential rotations.

This campaign matters because it demonstrates a shift toward "living off the land" binaries (LOLBins) on Linux systems. Once attackers gain initial access—often through unpatched web applications, exposed SSH services, or supply-chain compromises—they deploy GSocket to create encrypted reverse connections to attacker-controlled infrastructure. The tool's legitimate codebase and valid TLS encryption make it exceptionally difficult to distinguish from authorized administrative traffic without behavioral analytics.

For defenders, the risk is clear: standard vulnerability management and patching will not evict these actors. You must hunt for the specific artifacts and network patterns associated with GSocket deployment, validate the integrity of running processes, and implement controls to prevent unauthorized binary execution.

Technical Analysis

The Tool

GSocket is an open-source project designed to facilitate secure communication between systems behind NAT or firewalls. It creates encrypted TCP connections using SSL/TLS and can operate in reverse connection mode—exactly the capabilities that make it attractive to system administrators managing distributed infrastructure, and equally attractive to threat actors seeking stealthy persistence.

The tool typically consists of two binaries:

gs-netcat (the client) for outbound connections
gsocket (the daemon/listener) for incoming connections

Attack Chain

Based on observed incidents, the attack flow follows this pattern:

Initial Access: Exploitation of a public-facing vulnerability (often in web applications, CMS platforms, or remote access services) or brute-force compromise of weak SSH credentials.
Persistence Deployment: Download of GSocket binaries to writable directories (/tmp, /dev/shm, /var/tmp) or masqueraded as legitimate system binaries in /usr/local/bin/ or /opt/.
C2 Establishment: Execution of gs-netcat with parameters specifying:
- A secret/password for authentication (often visible in command-line arguments)
- Connection to external relay servers or direct peer-to-peer modes
- Persistence via systemd services, cron jobs, or shell profile modifications
Beaconing: Regular outbound connections over TCP ports 443 or 80, encapsulated in valid TLS traffic, bypassing basic egress filtering.

Why Traditional Defenses Fail

Signature Evasion: GSocket binaries are legitimate, signed code. Hash-based detection fails when attackers compile from source or use slightly modified versions.
Encryption: All traffic uses strong TLS encryption, preventing deep packet inspection from identifying malicious payloads.
Process Masquerading: Attackers often rename binaries to mimic legitimate services (e.g., systemd-network, kworker, sshd) or hide them in memory using process hollowing techniques.
Persistence Mechanisms: Systemd service files and cron entries ensure the implant survives reboots and user logouts.

Detection & Response

The following detection content targets the specific artifacts, network behaviors, and persistence mechanisms associated with GSocket abuse.

SIGMA Rules

YAML

---
title: GSocket Binary Execution Detected
id: 7f8e9d2a-4b5c-6d7e-8f9a-0b1c2d3e4f5a
status: experimental
description: Detects execution of GSocket binaries commonly abused for persistent access on Linux systems
references:
  - https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/gs-netcat'
      - '/gsocket'
  selection_name:
    Image|contains:
      - 'gs-netcat'
      - 'gsocket'
  condition: selection_img or selection_name
falsepositives:
  - Legitimate GSocket usage by system administrators
  - Authorized remote access tools with similar names
level: high
---
title: GSocket Persistence via Systemd Service
id: 8a9b0c1d-2e3f-4a5b-6c7d-8e9f0a1b2c3d
status: experimental
description: Detects creation of systemd services executing GSocket binaries for persistence
references:
  - https://attack.mitre.org/techniques/T1543/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1543.002
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|startswith:
      - '/etc/systemd/system/'
      - '/usr/lib/systemd/system/'
      - '/lib/systemd/system/'
  selection_content:
    TargetFilename|endswith: '.service'
  condition: selection_path and selection_content
falsepositives:
  - Legitimate service installations during software deployment
  - Package manager operations
level: medium
---
title: Suspicious GSocket Command Line Arguments
id: 9b0c1d2e-3f4a-5b6c-7d8e-9f0a1b2c3d4e
status: experimental
description: Detects GSocket execution with secret key or listener arguments indicating C2 configuration
references:
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/gs-netcat'
      - '/gsocket'
  selection_cli:
    CommandLine|contains:
      - '-s '
      - '--secret'
      - '-k '
      - '--key'
      - '-l'
      - '--listen'
      - '-d'
      - '--daemon'
  condition: selection_img and selection_cli
falsepositives:
  - Administrative usage with visible command lines
  - Debugging sessions
level: high

KQL (Microsoft Sentinel / Defender)

This query hunts for GSocket execution and network patterns across Linux endpoint data ingested into Sentinel. It correlates process creation events with network connections to identify beaconing behavior.

KQL — Microsoft Sentinel / Defender

// Hunt for GSocket execution and associated network activity
let gsocket_binaries = dynamic(["gs-netcat", "gsocket"]);
let lookback = 7d;
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(lookback)
    | where ProcessName in~ (gsocket_binaries)
    | project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP),
    (DeviceProcessEvents
    | where TimeGenerated > ago(lookback)
    | where FileName in~ (gsocket_binaries)
    | project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName),
    (DeviceNetworkEvents
    | where TimeGenerated > ago(lookback)
    | where InitiatingProcessFileName in~ (gsocket_binaries)
    | where RemotePort in (443, 80, 8080)
    | project TimeGenerated, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Connections=count() by DeviceName, FileName, RemoteIP, RemotePort
| extend SuspicionScore = case(
    Connections > 50, 3,
    Connections > 10, 2,
    1
)
| sort by SuspicionScore desc, Connections desc

Velociraptor VQL

Use this artifact to hunt for active GSocket processes, their network connections, and file system artifacts across your Linux fleet.

VQL — Velociraptor

-- Hunt for active GSocket processes and network connections
LET processes = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'gs-netcat|gsocket'
   OR CommandLine =~ 'gs-netcat|gsocket'
   OR Exe =~ 'gs-netcat|gsocket'

LET connections = SELECT Pid, Name, RemoteAddress, RemotePort, State
FROM netstat()
WHERE Pid IN (SELECT Pid FROM processes)

SELECT 
    p.Pid,
    p.Name,
    p.CommandLine,
    p.Exe,
    p.Username,
    p.CreateTime,
    c.RemoteAddress,
    c.RemotePort,
    c.State
FROM processes p
LEFT JOIN connections c ON p.Pid = c.Pid

-- Also check for systemd persistence artifacts
LET service_files = SELECT FullPath, Size, Mtime
FROM glob(globs='/etc/systemd/system/*.service')
WHERE FullPath =~ 'gsocket|gs-netcat'

SELECT * FROM service_files

Remediation Script

Run this Bash script on suspected Linux servers to detect, terminate, and remove GSocket persistence mechanisms.

Bash / Shell

#!/bin/bash
# GSocket Detection and Eradication Script
# Run as root or with sudo

echo "[+] Starting GSocket detection and remediation scan..."

# 1. Identify running GSocket processes
echo "[*] Checking for running GSocket processes..."
GSOCKET_PIDS=$(pgrep -f "gs-netcat|gsocket")
if [ -n "$GSOCKET_PIDS" ]; then
    echo "[!] Found GSocket processes running: $GSOCKET_PIDS"
    ps -fp $GSOCKET_PIDS
    echo "[*] Terminating processes..."
    kill -9 $GSOCKET_PIDS 2>/dev/null
    echo "[+] Processes terminated"
else
    echo "[+] No running GSocket processes found"
fi

# 2. Remove binaries
echo "[*] Searching for GSocket binaries..."
find /tmp /var/tmp /dev/shm /usr/local/bin /opt /home -type f \( -name "gs-netcat" -o -name "gsocket" \) 2>/dev/null | while read -r binary; do
    echo "[!] Found binary: $binary"
    rm -f "$binary"
    echo "[+] Removed $binary"
done

# 3. Check systemd services
echo "[*] Checking for malicious systemd services..."
systemctl list-unit-files | grep -E "gsocket|gs-netcat" | while read -r service; do
    service_name=$(echo $service | awk '{print $1}')
    echo "[!] Found suspicious service: $service_name"
    systemctl stop "$service_name" 2>/dev/null
    systemctl disable "$service_name" 2>/dev/null
    rm -f "/etc/systemd/system/$service_name"
    rm -f "/usr/lib/systemd/system/$service_name"
    echo "[+] Removed service $service_name"
done
systemctl daemon-reload

# 4. Check cron jobs
echo "[*] Checking cron jobs for GSocket persistence..."
crontab -l 2>/dev/null | grep -E "gs-netcat|gsocket" && echo "[!] Found GSocket in root crontab"
for user in $(cut -f1 -d: /etc/passwd); do
    crontab -u $user -l 2>/dev/null | grep -E "gs-netcat|gsocket" && echo "[!] Found GSocket in $user crontab"
done

# 5. Network connections
echo "[*] Checking for established GSocket connections..."
netstat -tulpn 2>/dev/null | grep -E "gs-netcat|gsocket" || ss -tulpn | grep -E "gs-netcat|gsocket"

# 6. Check bash history for installation commands
echo "[*] Checking bash history for GSocket installation..."
for user_home in /root /home/*; do
    if [ -f "$user_home/.bash_history" ]; then
        grep -E "gs-netcat|gsocket|curl.*gsocket|wget.*gsocket" "$user_home/.bash_history" 2>/dev/null && \
        echo "[!] Suspicious commands found in $user_home/.bash_history"
    fi
done

echo "[+] Scan complete. Review any findings marked with [!]"

Remediation

If you discover GSocket persistence on your systems, immediate action is required to prevent data exfiltration or lateral movement.

Immediate Actions

Isolate the Host: Disconnect the affected server from the network immediately to sever the C2 channel. Do not shut down the system—preserve memory for forensic analysis if possible.
Preserve Evidence: Capture memory dumps (/dev/mem or using LiME), running processes (ps auxef), network connections (ss -tulpn), and file system artifacts before remediation.
Credential Rotation: Assume all credentials on the affected system are compromised. Rotate SSH keys, service account passwords, and any API keys stored on the system.

Eradication Steps

Remove Persistence:
- Delete systemd service files: /etc/systemd/system/gs*.service, /usr/lib/systemd/system/gs*.service
- Remove cron entries from all users: crontab -e for each user, check /etc/crontab and /etc/cron.d/
- Check shell profiles: /etc/profile, ~/.bashrc, ~/.bash_profile, /etc/profile.d/
Remove Binaries: Delete GSocket binaries from:
- /tmp/, /var/tmp/, /dev/shm/
- /usr/local/bin/, /opt/
- User home directories
- Any world-writable directories
Verify Integrity: Use package manager verification to ensure system binaries haven't been replaced:
Bash / Shell

Debian/Ubuntu

dpkg -V

RHEL/CentOS

rpm -Va

Code


### Prevention Strategies

1. **Application Whitelisting**: Implement `fapolicyd` (File Access Policy Daemon) or similar tools to prevent execution of unauthorized binaries in `/tmp`, `/var/tmp`, and `/dev/shm`.

2. **Egress Filtering**: Restrict outbound TCP connections to known-good destinations. Alert on any process (especially non-browser, non-update processes) establishing outbound TLS connections to unknown IPs on port 443.

3. **File Integrity Monitoring**: Deploy AIDE, Tripwire, or Wazuh to monitor for unauthorized file creation in system directories and alert on new systemd service installations.

4. **SSH Hardening**: 
   - Disable password authentication; use key-based auth only
   - Implement fail2ban or similar to prevent brute-force attacks
   - Restrict SSH access to specific source IPs via firewall rules or `AllowUsers` in sshd_config

5. **Monitoring**: Ensure process execution logging is enabled (auditd with `execve` rules) and forwarded to your SIEM. Monitor specifically for:
   - Processes executing from `/tmp` or `/dev/shm`
   - Binaries making outbound connections that don't match expected baselines
   - Systemd unit file creation events

### Verification

After remediation, verify the absence of GSocket artifacts:
- Confirm no processes matching `gs-netcat` or `gsocket` are running: `ps aux | grep -E "gs-netcat|gsocket"`
- Verify no listening ports are associated with unknown binaries: `ss -tulpn`
- Check recent systemd service modifications: `find /etc/systemd/system -name "*.service" -mtime -7`

## Related Resources

[Security Arsenal Managed SOC Services](https://securityarsenal.com/services/mdr)
[AlertMonitor Platform](https://securityarsenal.com/products/alertmonitor)
[Book a SOC Assessment](https://securityarsenal.com/contact)
[soc-mdr Intel Hub](https://securityarsenal.com/intel/mdr)

GSocket Abuse on Linux Servers: How to Detect and Eradicate Persistent Access