GSocket: Encrypted C2 over Shared Relays and Multi-Layer Persistence Following Public Web Application Compromise

1. Overview

• Article: The global socket: how threat actors are weaponizing GSocket for stealthy C2
• Publisher: Microsoft Security
• Published Date: 2026-11-11
• Collection Date: 2026-11-12T07:30:45+09:00
• Source: Microsoft Security
• Related Sources: None
• Related Malware: GSocket
• Related Threat Groups: None
• Related CVE: CVE-2026-43284
• Related Products and Technologies: Linux web servers, Global Socket Relay Network
• Severity: High
• Severity Justification: Threat actors maintained access without fixed C2 IOCs even after public web application patching, and multiple persistence mechanisms as well as root escalation attempts via Dirty Frag were observed.

2. Executive Summary

Microsoft identified multiple instances where threat actors deployed GSocket, a legitimate open-source remote access tool, on Linux web servers. Using shared secrets and the Global Socket Relay Network, the attackers retained the ability to reconnect without a fixed C2 address while establishing multiple persistence mechanisms through cron, systemd, and shell profiles.

3. Attack Flow

This flow generalizes multiple incidents observed by Microsoft. Not all phases occurred in every incident.

From Web Application Compromise to GSocket Persistence (Generalized Flow across Multiple Incidents)

1. The attacker exploits an internet-facing web application to execute commands under the web service account.
2. The attacker retrieves a deployment script using curl, profiles the host, and places an architecture-specific GSocket client in paths such as /dev/shm.
3. The attacker generates a shared secret to establish an encrypted outbound C2 connection from the victim host to the Global Socket Relay Network.
4. The attacker masquerades the process name to resemble a kernel thread and establishes multiple persistence mechanisms using cron, systemd, shell profiles, watchdogs, and redundant copies.
5. In some instances, the attacker attempts root privilege escalation using Dirty Frag.

4. Attacker Position and Execution Location

• A remote attacker who can reach the internet-facing web application. After intrusion, the attacker uses outbound C2 via the relay network.

5. Visibility for Victims and Administrators

Victim Perspective

• Backdoor access may persist even after patching and remediating the web application.

Administrator Perspective

• Indicators include execution from paths such as /dev/shm, processes masquerading as kernel threads, unrecognized cron or systemd entries, and persistent outbound TLS traffic.

6. Conditions for Success and Failure

Success Conditions

• Initial code execution is achieved in the web application.
• The server can make outbound connections to the deployment script source and the relay network.
• The attacker can write to persistence locations. The required permission depends on the destination: administrator privileges are needed for system-level systemd configurations, while user privileges are sufficient for user-level paths such as ~/.profile.

Failure Conditions and Mitigation

• Remediate the initial vulnerability.
• Restrict execution from temporary and memory-backed paths, and limit outbound traffic to necessary destinations.
• Restrict write access and modifications to persistence locations through the principle of least privilege and change management (baseline comparisons for cron, systemd, shell profiles, and watchdogs should be performed separately for detection and auditing).

7. Outcomes upon Success

• Encrypted remote access without a fixed C2 address.
• Multiple persistence mechanisms that remain active even after application patching.
• Root privilege escalation if successful.

8. Observable Logs

• Email: No email-specific vectors have been publicly disclosed.
• Proxy/SWG/DNS: Script retrieval via curl and continuous outbound TLS traffic to relay infrastructure.
• Endpoint/EDR: Execution from paths such as /dev/shm, process names mimicking kernel threads, modifications to cron, systemd, or profiles, redundant binaries, unexpected commands executed by web service accounts, and root escalation attempts (within endpoint telemetry scope).
• Identity/IdP: No specific information has been publicly disclosed.
• SaaS/Cloud: No specific information is available in public materials.
• Network: Long-lived outbound connections without an inbound listener, utilizing a relay network.

9. Confirmation of Attack Success

Confirmation of Malware Execution or Authentication Success

• Public Information: Microsoft confirmed GSocket client execution, relay connections, and persistence across multiple incidents (the exact scope of confirmation per phase varies by incident).
• Scope of Confirmation: Linux servers analyzed via Microsoft Defender for Endpoint telemetry.

Confirmation of Subsequent Compromise

• Public Information: GSocket access persisted even after initial vulnerabilities were patched. Root escalation using Dirty Frag was attempted, but the number of successful attempts was not disclosed.
• Scope of Confirmation: Compromise incidents investigated by Microsoft.

10. Investigation Playbook

• Trigger: Curl execution following a web exploit, execution from /dev/shm, unrecognized cron or systemd entries, and relay egress.
• Initial Review: Review initial web logs, download URLs, shared secret artifacts, processes, and persistence mechanisms.
• Endpoint: Preserve memory, process trees, temporary paths, cron jobs, systemd services, profiles, and watchdogs.
• Identity and Cloud: Check web service accounts, SSH keys, root access, and notification tokens.
• Subsequent Operations: Track root escalation, credential theft, additional payloads, and lateral movement.
• Containment: Isolate the host from the network, terminate processes, remove persistence mechanisms and GSocket clients that use the affected shared secret, block reconnection, apply patches, and rebuild the host if necessary.
• Classification Boundaries: Separate web exploits, GSocket execution, relay connections, persistence, and root escalation.

11. Defense and Detection Ideas

• Single Events: Curl invoked by a web process, binaries in /dev/shm, unrecognized systemd units, and user processes resembling kernel threads.
• Time-Series Correlation: Correlate RCE commands, file downloads, relay connections, and cron or systemd modifications.
• Hunting Perspective: Search for GSocket binaries or scripts, environment variables like GS_TG_TOKEN or GS_TG_CHATID, Discord or webhook notifications, and redundant copies.
• Log Gaps: Combine process, service, and egress patterns rather than relying solely on IP blocklists.
• Priority Mitigations: Prioritize host rebuild decisions, egress allowlists, noexec restrictions on temporary paths, and local privilege escalation patches.

12. Facts, Inference, and Hypothesis

Facts

• Microsoft confirmed GSocket deployments across multiple compromised Linux servers.
• Threat actors exploited public web applications, retrieved and executed scripts via curl, and placed architecture-specific clients into paths such as /dev/shm.
• GSocket derives connection identifiers and authentication material from shared secrets; both the victim host and the operator connect outbound to a shared relay network.
• Cron jobs, systemd services, shell profiles, watchdogs, and redundant copies were used for persistence, disguised with process names resembling kernel threads.
• Root privilege escalation via CVE-2026-43284 (Dirty Frag) was attempted in some instances.
• Microsoft describes this as a generalized attack flow across multiple incidents; not all phases occurred in every incident, and post-reboot persistence or relay session establishment was not confirmed in every case.

Inference

• Blocking fixed IP addresses and domains alone is insufficient to adequately prevent reconnections utilizing relay networks and shared secrets.

Hypothesis

• None

13. MITRE ATT&CK Mapping

14. Unknowns and Additional Research

• The specific vulnerabilities used for initial access, the number of organizations affected by GSocket deployments, the success count of Dirty Frag escalations, and operator attribution remain undisclosed.

15. Impact on SOCs and Organizations

Simply patching Linux web servers is insufficient because GSocket and persistence mechanisms remain present; comprehensive host investigation and egress verification are required. Focus on process, file, and service behaviors under the assumption that shared relays are utilized.

16. Summary by Persona

• For SOCs: Correlate curl execution following web exploits, execution from /dev/shm, kernel thread-like processes, cron and systemd modifications, and relay egress.
• For Administrators: In addition to updating applications, isolate hosts, remove GSocket and persistence artifacts, enforce egress allowlists, and rebuild hosts when necessary.
• For End Users: This attack does not rely on ordinary end-user actions. Follow instructions regarding service suspension and credential updates.