Global Socket: How Threat Actors Are Weaponizing GSocket for Stealthy C2

Cybercriminals are increasingly abusing legitimate networking tools to maintain access to compromised systems. One example highlighted in new research from Microsoft is GSocket, an open-source remote access tool that threat actors are using to establish stealthy command-and-control (C2) communications with compromised Linux servers.

In its November 11, 2026, security research, Microsoft describes multiple incidents in which attackers deployed GSocket after exploiting internet-facing web applications. Rather than relying on traditional attacker-controlled servers, the operators used the Global Socket Relay Network (GSRN) to maintain remote access.

The concerning aspect of this activity is that fixing the original vulnerability does not necessarily remove the attacker's access. Once GSocket has been installed and persistence mechanisms have been established, the compromised server may remain accessible even after administrators patch the vulnerable application.

Microsoft's findings highlight why incident response must go beyond vulnerability patching and include investigations into suspicious processes, persistence mechanisms, and outbound network connections.

Why GSocket Is Becoming an Attractive Tool for Threat Actors

GSocket is an open-source networking tool designed to establish connections between systems through a shared relay network.

Although the technology has legitimate remote-access applications, Microsoft observed threat actors abusing it to maintain access to compromised Linux environments.

Traditional command-and-control infrastructure often relies on an attacker-controlled server. A compromised machine connects to a specific IP address or domain, allowing defenders to investigate and potentially block that destination.

However, GSocket introduces a different connection model.

Instead of requiring attackers to operate their own dedicated C2 infrastructure, GSocket uses the Global Socket Relay Network. Both the compromised machine and the operator establish outbound connections to the shared relay, which connects the two sessions through an encrypted channel.

Microsoft identifies three characteristics that make this approach useful to attackers:

• Shared relay infrastructure: Attackers do not need to register or maintain their own C2 IP addresses or domains.

• Outbound-only connections: Both sides connect outward to the relay, meaning the compromised server does not require an inbound listener or publicly accessible IP address.

• Built-in evasion and persistence: Deployment scripts can disguise processes, stage files in memory-backed directories, and establish mechanisms that survive system reboots.

These characteristics make conventional IP-based blocking less effective. Defenders must also investigate outbound connections and activity on the compromised endpoint.

Microsoft Reports a Significant Increase in GSocket-Related Activity

Microsoft's research indicates that GSocket abuse is not limited to isolated incidents.

According to Microsoft Defender for Endpoint telemetry, detections associated with GSocket increased substantially between March and August 2026.

The company reported a 356.2% increase in devices with GSocket-related detections during this period, measured against the March baseline. Microsoft also clarified that the increase was not consistent from month to month.

Web applications and hosting environments represented 87.1% of attributable incidents in the analysed telemetry.

Within this category:

• PHP web applications and cPanel hosting represented 63.9% of incidents.

• Apache accounted for 24.3%.

Education and research organizations represented the largest share of affected organizations at 30.7%, followed by technology and telecommunications at 22.9%.

Microsoft cautioned that these figures do not establish that attackers deliberately selected particular industries. Exposure is a more likely contributing factor, particularly where organizations operate large and decentralized web environments that may be difficult to inventory and maintain.

These findings demonstrate the importance of securing internet-facing applications and maintaining visibility across Linux hosting infrastructure.

How Attackers Deploy GSocket on Compromised Linux Servers

Microsoft identified a recurring sequence of activities in the investigated intrusions.

The attacks generally began with the exploitation of an internet-facing application vulnerability. Once attackers obtained remote code execution, they used the compromised web server to download and execute a GSocket deployment script.

The script then prepared the environment and established the remote communication channel.

The observed process included several stages.

Initial access through vulnerable web applications

Attackers exploited vulnerabilities in internet-facing applications to execute commands within the context of the web server process.

This initial access could provide an opportunity to execute shell commands and investigate the compromised host.

Downloading and deploying GSocket

Microsoft observed attackers using tools such as curl to retrieve remote installation scripts.

The deployment script profiled the compromised system, identified its architecture, and selected an appropriate GSocket client.

The downloaded client was then placed in writable or memory-backed locations, including directories such as /dev/shm.

Establishing command-and-control communication

After deployment, the GSocket client established an encrypted outbound connection through the Global Socket Relay Network.

This allowed the attacker to communicate with the compromised server without maintaining a dedicated public-facing C2 server.

Establishing persistence

Some observed intrusions included additional mechanisms designed to preserve access.

These included cron jobs, systemd services, shell startup profiles, watchdog processes, and redundant copies of the deployed tooling.

Not every stage occurred in every investigated incident.

How GSocket Maintains Access Without a Fixed C2 Address

One of the most important findings in Microsoft's research concerns how GSocket identifies and reconnects to compromised systems.

Traditional reverse shells commonly depend on a predefined attacker-controlled IP address or hostname. Security teams can investigate those destinations and potentially block communications at the network perimeter.

GSocket uses a different approach.

Instead of identifying the compromised endpoint through a fixed IP address or hostname, GSocket uses a shared secret.

During installation, the deployment script typically generates a random secret. The operator can retrieve it through different supported methods, including console output, temporary files, or configured notification channels.

Microsoft identifies Telegram, Discord, and webhooks as possible notification channels used to deliver this information.

With the shared secret, an operator can reconnect through a compatible GSocket client without needing to know the compromised server's current IP address, hostname, or network location.

The connection works through the following process:

1. GSocket is deployed on the compromised Linux server.

2. The deployment process generates a shared secret.

3. The operator obtains the secret.

4. Both the compromised server and operator connect outbound to the Global Socket Relay Network.

5. The relay matches the two sessions.

6. An encrypted communication channel allows remote interaction.

This architecture creates a challenge for defenders because blocking a single attacker-controlled IP address may not terminate the communication channel.

However, organizations can still restrict access to the relay infrastructure through appropriate outbound network controls and monitoring.

Process Disguise and Persistence Techniques

Microsoft also documented several techniques used to conceal GSocket activity on compromised Linux systems.

Attackers attempted to make malicious processes appear similar to legitimate system processes.

For example, Microsoft observed GSocket binaries executing under names such as systemd-remount-d and defunct.

These names can make suspicious processes less obvious during routine system inspections.

Attackers also used hidden directories and temporary storage locations to stage their payloads.

One observed location was:

/dev/shm/.gs-0

This memory-backed directory can be used to store files during execution. Microsoft also identified hidden files under /tmp.

Persistence was another important part of the observed activity.

The investigated deployment scripts used several mechanisms:

• Cron jobs: Scheduled tasks that can execute malicious processes repeatedly.

• Systemd services: Service entries designed to restart or maintain malicious processes.

• Shell profiles: Startup configurations that can execute commands when a user session begins.

• Watchdog mechanisms: Processes that help maintain the availability of the deployed tooling.

• Redundant copies: Multiple copies that can make complete removal more difficult.

Microsoft also observed attempts to remove staging files, modify file timestamps, and clear command history.

These techniques highlight why defenders should not rely on checking only running processes or deleting a suspicious executable.

Privilege Escalation: Attempts to Gain Root Access

In a small number of the observed incidents, Microsoft identified attempts to exploit CVE-2026-43284, also known as Dirty Frag.

The vulnerability is a Linux kernel issue that attackers attempted to use to escalate privileges from the web-service account to root.

This matters because initial exploitation of a web application may provide attackers with access under a restricted service account.

Privilege escalation attempts can potentially provide broader control over the compromised operating system.

Microsoft's findings demonstrate that defenders should investigate activity following the initial compromise, including attempts to exploit local privilege-escalation vulnerabilities.

The company also highlighted separate Linux kernel security research conducted by its FORGE Lab.

However, the reported GSocket incidents do not establish that every attacker successfully achieved root privileges.

How Organizations Can Detect and Mitigate GSocket Activity

Microsoft recommends a broader incident-response approach that addresses both the original vulnerability and the additional access mechanisms introduced by attackers.

Simply patching the vulnerable application is not sufficient if malicious tooling and persistence mechanisms remain on the server.

Organizations should consider the following defensive measures.

1. Patch and secure internet-facing applications

Keep web applications, content management systems, plugins, and application servers updated.

Remove unused components and restrict access to administrative interfaces and file-upload functionality.

2. Investigate the compromised host

If an application has been compromised, inspect the entire system rather than focusing exclusively on the vulnerable software.

Investigate suspicious GSocket clients, staged files, persistence entries, and outbound connections.

Verify that communications with the relay infrastructure have stopped.

3. Restrict outbound network traffic

Implement egress filtering and allow only the outbound destinations required for business operations.

Monitor suspicious connections to shared relay infrastructure and investigate unexpected outbound communication from web server processes.

4. Harden temporary and memory-backed directories

Where feasible, configure temporary and memory-backed directories as non-executable.

Generate alerts for suspicious executable activity involving hidden or world-writable directories.

5. Audit Linux persistence mechanisms

Inspect cron entries, systemd services, shell startup files, and other locations where unauthorized execution mechanisms may be configured.

Removing a running process alone may not eliminate the attacker's ability to reconnect.

6. Prioritize Linux kernel security updates

Keep Linux kernels updated and prioritize vulnerabilities that could allow local privilege escalation on internet-facing servers.

7. Enable endpoint detection and monitoring

Microsoft recommends enabling Microsoft Defender for Endpoint on Linux with real-time protection, cloud-delivered protection, and behaviour monitoring.

Security teams should pay particular attention to unusual child processes launched by web services and processes disguised as legitimate system components.

8. Microsoft Defender Detection and Investigation Capabilities

Microsoft also outlined several detection opportunities available through Microsoft Defender for Endpoint.

The observed alerts cover multiple stages of the attack, including initial access, execution, payload delivery, persistence, defence evasion, discovery, and command-and-control activity.

Examples include:

• Suspicious shell execution from PHP applications.

• Suspicious remote command execution through Java and Node.js web applications.

• Detection of GsNetcat tooling.

• Suspicious cron job creation.

• Suspicious Linux service creation.

• Hidden file execution.

• Attempts to clear command history.

• Suspicious communication with remote targets.

Microsoft also published Advanced Hunting queries for Microsoft Defender XDR customers.

These queries help security teams investigate:

• GSocket and gs-netcat process activity.

• Installer download activity.

• Connections to observed distribution hosts.

• Known malicious file hashes.

• Suspicious staging directories and persistence artifacts.

The research also provides specific file paths, domains, and SHA-256 hashes associated with the investigated activity.

Microsoft emphasizes that individual alerts should be examined alongside process ancestry, execution context, persistence changes, and network activity. A single detection does not independently confirm that every stage of an intrusion occurred.

What This Means for Linux Server Security

Microsoft's findings highlight a broader cybersecurity challenge: attackers do not always need custom malware or dedicated infrastructure to maintain access to compromised systems.

Legitimate tools can become part of an attack when they are deployed without authorization.

GSocket illustrates how shared relay infrastructure, encrypted communication, and built-in persistence mechanisms can complicate traditional detection and response strategies.

For enterprises, hosting providers, and organizations operating Linux-based web applications, this means security monitoring must extend beyond known malicious IP addresses and vulnerability scanning.

Security teams need visibility into process execution, application behaviour, persistence mechanisms, and outbound network connections.

The research also reinforces an important incident-response principle: removing the initial vulnerability does not automatically remove an attacker's presence.

A successful recovery requires investigating the compromised host, identifying additional access mechanisms, removing unauthorized components, and verifying that suspicious communications have stopped.

Conclusion

Microsoft's investigation into GSocket abuse demonstrates how threat actors are adapting legitimate networking technologies for persistent access and stealthy command-and-control operations.

By using the Global Socket Relay Network, attackers can avoid depending on dedicated C2 infrastructure and reconnect to compromised Linux systems through shared secrets.

The combination of outbound-only communication, process disguise, hidden payload staging, and multiple persistence mechanisms creates additional challenges for security teams.

Organizations should respond by combining vulnerability management with endpoint monitoring, outbound traffic controls, Linux system hardening, and comprehensive incident investigation.

The central lesson is clear: patching a vulnerability is only one part of securing a compromised server. Organizations must also identify and remove any access mechanisms attackers may have installed.