GTPDOOR Linux Malware Exploiting GPRS Protocol For Stealthy C2 Communication

Threat actors exploit Linux malware due to the widespread use of Linux servers in critical infrastructure and web hosting. 

Linux’s prevalence makes it an attractive target for cybercriminals seeking to compromise systems, steal data, or launch distributed denial-of-service (DDoS) attacks.

Cybersecurity researcher specialist in mobile security and IoT security research, HaxRob(@haxrob) recently discovered GTPDOOR, a Linux malware that was found exploiting GPRS protocol for stealthy C2 communication.

GTPDOOR Linux Malware Exploiting GPRS Protocol

GTPDOOR targets telco networks near GRX, and it communicates C2 traffic via GTP-C signaling by blending it with normal traffic. 

The below diagram depicts a potential use case where actors exploit established persistence to access compromised hosts through GTP-C Echo Request messages:-

GTPDOOR supports remote code execution and can be beaconed by sending TCP packets to its host.

The beacon response hides specific information in a TCP header flag by enhancing its stealth.

This malware has been named “GTPDOOR” for employing a port-knocking technique similar to BPFDOOR.

Unlike BPFDOOR, GTPDOOR uses GTP-C echo request/response messages and filters on UDP and GTP header values. 

It’s likely linked to UNC1945 / LightBasin, known for using GTP protocol to encapsulate tinyshell traffic.

GTPDOOR targets GTP-C signaling messages with its own extended structure. 

Besides this, the binaries contain the name “dnsd.c,” and a CrowdStrike presentation suggests the existence of a Solaris version.

A “closed” network links global telecom operators for interconnectivity. Systems like eDNS, SGSN, GGSN, P-GW, STP, and DRA require direct GRX network access for roaming-related signaling and user plane traffic. 

GTPDOOR could exploit all these functions and gain direct entry into a telco’s core network. Likely targets include systems supporting GTP-C over GRX, like:-

• SGSN
• GGSN
• P-GW

Here’s the visual presentation of the packet:-

The TCP probe feature allows external hosts to check GRX’s TCP packets.

A subnet filter compares the source IP, and if there is no match, then a reply is sent, which indicates that the implant is active. 

The beacon response is crafted using a raw socket by copying relevant IP and TCP header fields.

The client distinguishes an open port by checking the urgent pointer flag in the TCP header. 

While no service needs to listen on the TCP beaconing port:-

Probe responses use ACK/RST flags and urgent pointer flags for covert message encoding in the TCP header.

The ACL purpose is unclear, with considerations like avoiding threat actor C2 infrastructure in memory or specifying internal victim networks. 

However, any GRX host can scan operator IPs by sending the TCP SYN packets on non-standard ports.

Recommendations

Here below we have mentioned all the recommendations:-

• Open UDP port selectively on GRX for necessary systems, with explicit firewall rules dropping packets for non-GTP protocol users.
• Employ strict rules to block unnecessary inbound TCP connections via GRX.
• Consider dropping TCP packets with the RST/ACK flag set on the GRX firewall as a precaution.

You can block malware, including Trojans, ransomware, spyware, rootkits, worms, and zero-day exploits, with Perimeter81 malware protection. All are incredibly harmful, can wreak havoc, and damage your network.

Stay updated on Cybersecurity news, Whitepapers, and Infographics. Follow us on LinkedIn & Twitter.