The attacker now owns the S1-U GTP-U endpoint for this IMSI's bearer. Every packet the network believes belongs to that subscriber's session — inbound and outbound — flows through attacker-controlled infrastructure:

<CodeBlock language="python" is-terminal code="def send_gtp_u(target_sgw_ip: str, teid: int, payload: bytes) -> None: """Send GTP-U data packet via the hijacked bearer.""" pkt = ( IP(dst=target_sgw_ip) / UDP(sport=2152, dport=2152) / GTP_U_Header(teid=teid) / Raw(payload) ) send(pkt)

Attacker's outbound traffic now flows over the hijacked TEID.

CDRs generated at SGW/PGW attribute this traffic to the victim IMSI."

/>

IV. The IMSI Overbilling Fraud Mechanism

The billing consequence of a hijacked bearer is easy to underestimate until it's mapped out. Charging Data Records (CDRs) are generated at the SGW and PGW based on the bearer context — not on any independent verification of who actually sent the traffic. A CDR records the IMSI the bearer was allocated to, the data volume observed on that TEID, and the session duration. It has no way to know the packets crossing that TEID originated from an attacker rather than the legitimate device.

<CodeBlock language="text" is-terminal code=" Normal flow: UE data → SGW → CDR: IMSI=victim, volume=X, duration=T

Hijacked flow: Attacker data → hijacked TEID → SGW CDR generated: IMSI=victim, volume=LARGE, duration=LONG ↑ Victim billed for the attacker's data consumption Attacker receives free, unattributed data service

Scale: an automated attack against thousands of IMSIs can generate millions in fraudulent CDRs before detection" />

Two fraud patterns follow directly from this. Overbilling attributes an attacker's own data consumption to a victim's account — the attacker gets free service, the victim gets an inflated bill or triggers a false roaming-data-overage alert. Bypass fraud runs the same mechanism in reverse: an attacker with legitimate roaming credentials assigns their own traffic to a hijacked bearer belonging to a low-usage or dormant IMSI specifically to avoid being billed for it at all, since the CDR is generated against a different subscriber's account entirely. Both patterns scale linearly with the number of IMSIs an attacker can enumerate and hijack, and because CDRs "look normal" — correctly formatted, attributed to a real subscriber, generated by legitimate core network elements — post-hoc fraud detection has to rely on statistical anomalies (a sudden data-volume spike on a subscriber who normally makes voice calls) rather than any protocol-level red flag.

V. Exploitation Kill Chain

The end-to-end attack sequence, from a controlled ProLab assessment perspective:

Every step in this chain assumes exactly one condition: the receiving GTP-C node accepts messages from an IP address it hasn't independently validated against a bilateral roaming agreement. Remove that condition and the entire kill chain collapses at step 2.

VI. Real-World Impact: GTPdoor and the GRX Threat Landscape

GTPdoor: When GTP-C Became Malware C2

In early 2024, researcher haxrob published analysis — subsequently covered by Eclecticiq, Kaspersky, and Trend Micro — of a Linux kernel-module backdoor named GTPdoor, found deployed on compromised SGSN and SGW nodes at multiple telecommunications operators. Its defining innovation was using GTP-C Echo Request packets themselves as a covert command-and-control channel.

Attacker ──── GTP Echo Request (embedded C2 payload) ────▶ Compromised SGW
                       UDP port 2123
                       Recovery IE: C2 command bytes

Compromised SGW ◀──── GTP Echo Response (C2 response) ──── kernel module
                       Triggers shell execution, data exfil, or pivot

Rule 1: CSR from SGSN/SGW with Origin-IP in PLMN-A
  → IMSI must have MCC/MNC matching PLMN-A, or an active
    bilateral roaming agreement between PLMN-A and PLMN-B
  → Reject if the IMSI's home PLMN has no bilateral agreement with the sender

Rule 2: CSR MSISDN must match the IMSI's E.164 country code
  → Reject MSISDN/IMSI mismatches (a common artifact of forged tunnels)

Rule 3: GTP Echo Request with non-zero TEID (GTPdoor IOC)
  → Flag and alert; per spec, TEID must be 0 in Echo Requests

# Example GTP-C peer whitelist (production deployments use a
# dedicated GTP firewall, not raw iptables — shown for clarity)
iptables -A INPUT -p udp --dport 2123 -s 10.20.0.0/16 -j ACCEPT   # Partner PLMN A
iptables -A INPUT -p udp --dport 2123 -s 172.16.0.0/12 -j ACCEPT  # Partner PLMN B
iptables -A INPUT -p udp --dport 2123 -j DROP                      # Drop all others