Part 11: Real-World Attacks — Core Signaling (SS7 / Diameter / GTP)

Learning Objective: Understand how real-world attackers exploit the SS7, Diameter, and GTP signaling planes of cellular networks — where in the network these attacks originate, the step-by-step attack sequences, and how to detect and mitigate them.

Table of Contents

• 1. SS7-Based SMS OTP Theft for Bank Fraud
• 2. SS7 Location Tracking of High-Value Targets
• 3. Diameter Exploitation for US Subscriber Tracking
• 4. Commercialized SS7 Interception as Access-Broker Service
• 5. GTP and Roaming-Plane Abuse for Fraud and Stealth Traffic
• Signaling Attack Summary
• Lab Exercises

How SS7/Diameter/GTP Interconnect Works

Before diving into individual attacks, it is critical to understand why these attacks are possible. The global mobile network is built on a trust model where operators exchange signaling messages to support roaming, SMS delivery, and call setup.

graph TB
    subgraph "Home Network (Operator A)"
        HLR_HSS[(🔐 HLR/HSS
Subscriber DB)]
        MSC_MME[🎛️ MSC/VLR · MME
Switching / Mobility]
        SMSC[📨 SMSC
SMS Center]
    end

    subgraph "Visited Network (Operator B — Roaming Partner)"
        V_MSC[🎛️ Visited MSC/MME]
        V_SGSN[📦 SGSN/SGW]
    end

    subgraph "Signaling Network (SS7/Diameter)"
        STP[🔀 STP/DRA
Signal Transfer Point /
Diameter Routing Agent]
    end

    subgraph "GTP Roaming Plane"
        GRX[🌐 GRX/IPX
GPRS Roaming Exchange]
    end

    Attacker[🔴 Attacker
Rogue operator /
Leased SS7 access]

    V_MSC <-->|MAP/Diameter
via SS7/IP| STP
    STP <-->|MAP/Diameter| HLR_HSS
    STP <-->|MAP| SMSC
    V_SGSN <-->|GTP-C| GRX
    GRX <-->|GTP-C/U| MSC_MME

    Attacker -.->|❌ Purchased
SS7/Diameter
access| STP
    Attacker -.->|❌ Rogue
GTP peer| GRX

    style Attacker fill:#ff6666,color:#fff
    style STP fill:#ffaa66
    style GRX fill:#ffaa66
    style HLR_HSS fill:#ffee66
    style SMSC fill:#ffee66

1. SS7-Based SMS OTP Theft for Bank Fraud (S, I, E)

Executive Summary

In 2017, attackers exploited SS7 signaling access — obtained through a foreign mobile operator — to intercept SMS-based two-factor authentication codes sent to German bank customers by O2-Telefónica. The attackers first harvested banking credentials via phishing, then used SS7 to redirect victims' SMS messages to attacker-controlled numbers, authorizing fraudulent wire transfers that drained accounts.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Victim's Home Network (O2-Telefónica Germany)"
        HLR[(🔐 HLR
Home Location Register)]
        SMSC[📨 SMSC
SMS Center]
        MSC_Home[🎛️ Home MSC/VLR]
    end

    subgraph "SS7 Interconnect"
        STP[🔀 STP
Signal Transfer Point]
    end

    subgraph "Attacker Infrastructure"
        Rogue_MSC[🔴 Rogue MSC
Attacker-controlled
via leased SS7 GT]
        Attacker_Phone[🔴 Attacker Phone
Receives redirected SMS]
    end

    subgraph "Victim Side"
        Victim_UE[📱 Victim UE
German bank customer]
        Bank[🏦 Online Bank
Sends mTAN via SMS]
    end

    Bank -->|"1. Sends mTAN SMS
to victim MSISDN"| SMSC
    SMSC -->|"2. Queries HLR:
SRI-for-SM"| HLR
    HLR -.->|"3. Returns ATTACKER's
MSC address
(poisoned by UpdateLocation)"| SMSC
    SMSC -.->|"4. Routes SMS to
attacker's MSC"| STP
    STP -.->|"5. Delivers SMS"| Rogue_MSC
    Rogue_MSC -.->|"6. OTP received"| Attacker_Phone

    Victim_UE -.->|"❌ Never receives SMS"| MSC_Home

    style Rogue_MSC fill:#ff6666,color:#fff
    style Attacker_Phone fill:#ff6666,color:#fff
    style HLR fill:#ffaa66
    style SMSC fill:#ffaa66
    style Victim_UE fill:#ffee66
    style Bank fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Attacker
    participant SS7 as 🔀 SS7 Network
    participant HLR as 🔐 HLR (O2)
    participant SMSC as 📨 SMSC (O2)
    participant Bank as 🏦 Bank
    participant Victim as 📱 Victim

    Note over Attacker: Phase 1: Credential Harvesting
    Attacker->>Victim: Phishing email/SMS with fake bank login
    Victim->>Attacker: Enters bank username + password

    Note over Attacker: Phase 2: SS7 Subscriber Hijack
    Attacker->>SS7: MAP UpdateLocation
(IMSI=victim, new MSC=attacker GT)
    SS7->>HLR: Forward UpdateLocation
    HLR->>SS7: UpdateLocation ACK
(Victim now "roaming" at attacker MSC)

    Note over Attacker: Phase 3: Trigger and Intercept OTP
    Attacker->>Bank: Login with stolen credentials
    Bank->>SMSC: Send mTAN SMS to victim MSISDN
    SMSC->>HLR: SendRoutingInfo-for-SM (SRI-SM)
    HLR->>SMSC: Returns attacker's MSC address
    SMSC->>SS7: MT-ForwardSM (SMS to attacker MSC)
    SS7->>Attacker: SMS delivered with mTAN code

    Note over Attacker: Phase 4: Cash-Out
    Attacker->>Bank: Submit mTAN → authorize wire transfer
    Bank->>Bank: Transfer approved ✅

    Note over Victim: ❌ Victim never receives SMS
❌ Victim unaware until funds gone

Technical Deep Dive

The attack exploits two SS7 MAP (Mobile Application Part) operations:

1. UpdateLocation (UL): Normally sent by a visited MSC/VLR when a subscriber roams to a new network. It tells the HLR: "this subscriber is now registered at my MSC." The HLR updates its records and returns the subscriber profile. There is no authentication — the HLR trusts any UpdateLocation from any SS7-connected node.

2. SendRoutingInfo-for-SM (SRI-SM): When the SMSC needs to deliver an SMS, it queries the HLR for the current serving MSC address. After the malicious UpdateLocation, the HLR returns the attacker's MSC address instead of the legitimate one.

Protocol-level detail:

MAP UpdateLocation Request:
  IMSI: 262-02-XXXXXXXXX  (victim's IMSI)
  MSC Number: +XXX-XXXX   (attacker's Global Title)
  VLR Number: +XXX-XXXX   (attacker's Global Title)

HLR Response:
  UpdateLocation ACK
  (HLR now records victim as served by attacker GT)

The attacker needs:

• The victim's IMSI (obtainable via SS7 SendRoutingInfo or from breached carrier data)
• An SS7 Global Title (leased from a compliant or corrupt operator, or purchased from a signaling-as-a-service provider)

Detection Indicators

• Anomalous UpdateLocation from unexpected Global Titles: HLR receives UL from an operator the subscriber has never roamed to
• Rapid location changes: Subscriber appears to "teleport" between countries within minutes
• SRI-SM returning foreign MSC for domestic subscribers: SMS routing queries returning unexpected serving nodes
• SMS delivery failures followed by fraud reports: Temporal correlation between missing SMS and unauthorized bank transactions
• SS7 firewall alerts: Category 1 (info gathering) and Category 3 (fraud) message patterns per GSMA FS.11

STRIDE Assessment

Mitigation

• ✅ SS7 firewall (GSMA FS.11 Category 1-3 filtering) — block unexpected UpdateLocation/SRI-SM from untrusted origins
• ✅ Home Routing for SMS — SMSC delivers to an SMS router in the home network first, not directly to the serving MSC
• ✅ Replace SMS-based 2FA with app-based TOTP, FIDO2/WebAuthn, or push notifications
• ✅ Real-time velocity checks on HLR — flag UL from a new country if subscriber was domestic seconds ago
• ⚠️ Subscriber notification — alert users when their HLR record changes (rarely implemented)
• ⚠️ CAT (CAMEL Application Toolkit) triggers — use CAMEL to validate location changes (complex to deploy)

References

• Terrazone: SS7 Security Vulnerabilities, Attacks & Prevention
• GSMA FS.11: SS7 Interconnect Security Monitoring Guidelines
• GSMA FS.19: Diameter Interconnect Security
• 3GPP TS 29.002: MAP Protocol Specification
• Süddeutsche Zeitung (2017): Reporting on O2-Telefónica SS7 bank fraud

2. SS7 Location Tracking of High-Value Targets (I)

Executive Summary

State intelligence agencies and criminal organizations have repeatedly used SS7 signaling queries — specifically SendRoutingInfo (SRI) and ProvideSubscriberInfo (PSI) — to track the real-time geographic location of journalists, activists, political dissidents, and other high-value targets. These attacks turn every mobile phone into a persistent tracking beacon, requiring only the target's phone number.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Target's Home Network"
        HLR[(🔐 HLR
Home Location Register)]
        MSC[🎛️ MSC/VLR
Serving the target]
        BTS[📡 BTS/eNB
Cell tower serving target]
    end

    subgraph "SS7 Interconnect"
        STP[🔀 STP
Signal Transfer Point]
    end

    subgraph "Attacker (Surveillance Operator)"
        Attacker_Node[🔴 SS7 Node
Intelligence agency /
surveillance vendor]
        Analyst[🔴 Analyst
Plots target location
on map over time]
    end

    subgraph "Target"
        Target_UE[📱 Target Phone
Journalist / Activist]
    end

    Target_UE -.->|"Connected to cell"| BTS
    BTS <--> MSC
    MSC <--> HLR

    Attacker_Node -.->|"1. SRI: Where is
MSISDN +49XXX?"| STP
    STP -.->|"2. Query HLR"| HLR
    HLR -.->|"3. Returns:
MSC addr + IMSI"| STP
    STP -.->|"4. SRI Response"| Attacker_Node

    Attacker_Node -.->|"5. PSI: Give me
exact cell + TA"| STP
    STP -.->|"6. Query MSC"| MSC
    MSC -.->|"7. Cell-ID + LAC
+ Timing Advance"| STP
    STP -.->|"8. Location data"| Attacker_Node
    Attacker_Node -->|"9. Plot on map"| Analyst

    style Attacker_Node fill:#ff6666,color:#fff
    style Analyst fill:#ff6666,color:#fff
    style STP fill:#ffaa66
    style HLR fill:#ffaa66
    style MSC fill:#ffaa66
    style Target_UE fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Surveillance Node
    participant SS7 as 🔀 SS7 Network
    participant HLR as 🔐 HLR
    participant MSC as 🎛️ Serving MSC
    participant Target as 📱 Target

    Note over Attacker: Only needs target's phone number

    Attacker->>SS7: MAP SendRoutingInfo (SRI)
(MSISDN=target phone number)
    SS7->>HLR: Forward SRI
    HLR->>SS7: SRI Response
(IMSI, serving MSC address)
    SS7->>Attacker: IMSI + MSC address

    Note over Attacker: Now knows target's IMSI and serving network

    Attacker->>SS7: MAP ProvideSubscriberInfo (PSI)
(IMSI=target, RequestInfo=location)
    SS7->>MSC: Forward PSI
    MSC->>SS7: PSI Response
(Cell-ID, LAC, Age of Location)
    SS7->>Attacker: Cell-ID=4521, LAC=1003, Age=2min

    Note over Attacker: Maps Cell-ID → GPS coordinates
via public cell tower databases

    Note over Attacker: Repeats every 5-15 minutes
to build movement pattern

    loop Every 5-15 minutes
        Attacker->>SS7: MAP PSI (IMSI=target)
        SS7->>MSC: Forward PSI
        MSC->>SS7: Updated Cell-ID + LAC
        SS7->>Attacker: New location
    end

    Note over Attacker: Builds timeline:
Home → Office → Meeting → Airport

Technical Deep Dive

Two primary SS7 MAP operations are used:

1. SendRoutingInfo (SRI) — Input: target MSISDN (phone number). Output: IMSI and current serving MSC/VLR address. Originally designed for call routing but gives the attacker the target's IMSI and which MSC currently serves them.

2. ProvideSubscriberInfo (PSI) — Input: IMSI. Output: current Cell-ID, Location Area Code (LAC), and "age of location" (how recently the location was updated). Originally designed for lawful intercept and emergency services. Cell-ID maps to a specific cell tower sector, providing location accuracy of 50m–2km depending on cell density.

Additional techniques:

• AnyTimeInterrogation (ATI): A single query that returns both routing info and location. Blocked by some operators but still widely functional.
• Triangulation: By correlating Cell-ID + Timing Advance (TA) from multiple queries or by triggering handovers, attackers can refine position to ~50m in urban areas.
• Silent SMS (Type 0): Send a "silent" SMS that doesn't appear on the target's phone but forces a location update in the MSC, giving a fresh Cell-ID. Often combined with PSI.

Detection Indicators

• High-frequency SRI/PSI queries for the same IMSI from a single source
• SRI/PSI from Global Titles not associated with any legitimate roaming or interconnect agreement
• ATI queries from non-CAMEL origins — ATI should only come from CAMEL service platforms
• Silent SMS (TP-PID=0x40) bursts to the same subscriber preceding PSI queries
• Subscriber location queries outside business hours or from unexpected geographic origins

STRIDE Assessment

Mitigation

• ✅ SS7 firewall with Category 1 filtering (GSMA FS.11) — block SRI/PSI/ATI from unauthorized origins
• ✅ Home Routing — proxy SRI responses through home network, hiding true serving MSC
• ✅ GSMA SISS (Signaling Intelligence and Security Service) — industry threat intelligence sharing
• ✅ Monitor and alert on anomalous query patterns — rate-limit SRI/PSI per source GT
• ⚠️ Carrier-level opt-in location privacy — some operators offer VIP subscribers enhanced location query blocking
• ⚠️ Use a secondary phone/eSIM for sensitive communications — changes IMSI linkage

References

• EFF: SS7 is Vulnerable and Telecoms Must Acknowledge It (2024)
• GSMA FS.11: SS7 Interconnect Security Monitoring Guidelines
• Citizen Lab: "Running in Circles" — NSO Group / Circles surveillance infrastructure
• 3GPP TS 29.002: MAP Protocol (SRI, PSI, ATI operations)
• Tobias Engel, 31C3 (2014): "SS7: Locate. Track. Manipulate."

3. Diameter Exploitation for US Subscriber Tracking (I)

Executive Summary

In 2022, US government cybersecurity officials disclosed that unauthorized parties had attempted to exploit Diameter signaling — the 4G successor to SS7 — to retrieve location data of US mobile subscribers. The attacks used Diameter routing agents connected via the IPX (IP eXchange) roaming backbone to query Home Subscriber Servers (HSS) at US carriers, demonstrating that the move from SS7 to Diameter did not eliminate signaling-plane surveillance capabilities.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "US Carrier (Home Network)"
        HSS[(🔐 HSS
Home Subscriber
Server)]
        MME[🎛️ MME
Mobility Management]
        eNB[📡 eNodeB]
    end

    subgraph "Diameter Interconnect (IPX)"
        DRA_Home[🔀 Home DRA
Diameter Routing Agent]
        IPX[🌐 IPX Backbone
IP eXchange]
        DRA_Visited[🔀 Visited DRA]
    end

    subgraph "Attacker Infrastructure"
        Attacker_DRA[🔴 Rogue Diameter
Client / Proxy
via compromised or
leased IPX access]
    end

    subgraph "Target"
        Target_UE[📱 Target UE
US subscriber]
    end

    Target_UE -.-> eNB
    eNB <--> MME
    MME <-->|S6a Diameter| DRA_Home
    DRA_Home <-->|Diameter| IPX

    IPX <--> DRA_Visited

    Attacker_DRA -.->|"❌ Diameter queries
via IPX"| IPX

    style Attacker_DRA fill:#ff6666,color:#fff
    style IPX fill:#ffaa66
    style DRA_Home fill:#ffaa66
    style HSS fill:#ffee66
    style Target_UE fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Rogue Diameter Client
    participant IPX as 🌐 IPX Backbone
    participant DRA as 🔀 Home DRA
    participant HSS as 🔐 HSS (US Carrier)
    participant MME as 🎛️ MME

    Note over Attacker: Attacker has IPX interconnect access
(via leased or compromised Diameter peer)

    Attacker->>IPX: Diameter S6a:
Authentication-Information-Request (AIR)
(IMSI=target)
    IPX->>DRA: Route Diameter message
    DRA->>HSS: Forward AIR

    alt No DRA Filtering
        HSS->>DRA: Authentication-Information-Answer
(Auth vectors: RAND, AUTN, XRES, KASME)
        DRA->>IPX: Forward AIA
        IPX->>Attacker: Auth vectors received
        Note over Attacker: ⚠️ Can now derive session keys
    else DRA Filtering Active
        DRA->>Attacker: Diameter Error:
DIAMETER_AUTHORIZATION_REJECTED
        Note over Attacker: ❌ Blocked by DRA policy
    end

    Note over Attacker: Location query attempt

    Attacker->>IPX: Diameter S6a:
Notify Request (NOR) with
Alert-Reason=UE_PRESENT
    IPX->>DRA: Route message
    DRA->>HSS: Forward NOR
    HSS->>MME: Triggers location update procedure
    MME->>HSS: Update-Location-Request
(includes serving eNB / cell info)
    HSS->>DRA: Notify Answer
(location data in response)
    DRA->>IPX: Forward response
    IPX->>Attacker: Cell-level location obtained

    Note over Attacker: Alternative: Insert-Subscriber-Data
to modify subscriber profile

Technical Deep Dive

Diameter (defined in RFC 6733 and 3GPP TS 29.272 for S6a) was designed to replace SS7 MAP for 4G/LTE. While it uses TCP/SCTP and supports TLS, the protocol has several exploitable properties:

Key Diameter commands abused:

Why Diameter is still vulnerable:

• TLS is optional — many IPX peers negotiate without TLS
• DRA (Diameter Routing Agent) policies are often permissive — operators whitelist all roaming partners rather than restricting per-command
• IPX backbone is shared — multiple operators and MVNOs share IPX connectivity, increasing the attack surface
• No per-subscriber authorization — any Diameter peer can query any IMSI

Detection Indicators

• Diameter messages from unexpected Diameter identities (Origin-Host / Origin-Realm not matching known roaming partners)
• AIR/ULR for domestic subscribers from foreign Diameter peers — domestic subscribers should not trigger foreign S6a queries
• High-frequency location-related commands (NOR, IDR) for the same IMSI
• Diameter messages without TLS from IPX-connected peers
• DRA logs showing routing anomalies — messages for subscribers not associated with the source realm

STRIDE Assessment

Mitigation

• ✅ Diameter Edge Agent (DEA) / Diameter firewall — filter messages by command type, origin realm, and destination IMSI
• ✅ Mandatory TLS on all Diameter peering — enforce at IPX interconnect level
• ✅ Per-command authorization policies — only allow AIR/ULR from contracted roaming partners for their subscribers
• ✅ GSMA FS.19 compliance — implement Diameter interconnect security recommendations
• ✅ Anomaly detection on DRA — alert on unexpected command patterns per origin
• ⚠️ IPX provider contractual enforcement — require IPX providers to validate all connected peers (inconsistently enforced)

References

• EFF: SS7 is Vulnerable and Telecoms Must Acknowledge It (2024)
• GSMA FS.19: Diameter Interconnect Security
• 3GPP TS 29.272: Diameter-based S6a/S6d Interface
• NIST SP 800-187: Guide to LTE Security
• FCC CSRIC Best Practices for SS7 and Diameter Security

4. Commercialized SS7 Interception as Access-Broker Service (S, I, E)

Executive Summary

Underground platforms — exemplified by services like fastsms[.]su — have industrialized SS7-based SMS interception, selling it as a commodity service. Threat actors pay to receive OTPs and verification codes sent to any mobile number, enabling at-scale account takeover across banking, email, social media, and cloud services. This represents the evolution of SS7 exploitation from targeted espionage to mass-market cybercrime infrastructure.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Legitimate Mobile Network"
        HLR[(🔐 HLR/HSS)]
        SMSC[📨 SMSC]
        MSC[🎛️ MSC/MME]
        BTS[📡 BTS/eNB]
    end

    subgraph "SS7 Interconnect"
        STP[🔀 STP]
    end

    subgraph "Access-Broker Infrastructure"
        SS7_Gateway[🔴 SS7 Gateway
Leased interconnect]
        SIM_Farm[🔴 SIM Farm
Thousands of SIMs
for number rental]
        C2[🔴 C2 Server
Manages OTP
delivery pipeline]
        Web_Portal[🔴 Web Portal
fastsms.su etc.
Customer self-service]
        Telegram_Bot[🔴 Telegram Bot
OTP delivery
channel]
    end

    subgraph "Criminal Customers"
        Buyer[👤 Buyer
Pays for OTP
interception]
    end

    subgraph "Victim Services"
        Bank_App[🏦 Bank]
        Email[📧 Email Provider]
        Cloud[☁️ Cloud/SaaS]
    end

    Bank_App -->|"SMS OTP"| SMSC
    Email -->|"SMS OTP"| SMSC
    Cloud -->|"SMS OTP"| SMSC

    SMSC --> HLR
    HLR -.->|"Routing info
(poisoned or
SIM farm number)"| SMSC
    SMSC -.-> STP
    STP -.-> SS7_Gateway
    SS7_Gateway --> C2

    SIM_Farm -->|"Registered numbers
on real network"| BTS
    BTS --> MSC

    C2 --> Web_Portal
    C2 --> Telegram_Bot
    Buyer -->|"1. Select number
2. Pay crypto
3. Receive OTP"| Web_Portal
    Telegram_Bot -->|"OTP delivered"| Buyer

    style SS7_Gateway fill:#ff6666,color:#fff
    style SIM_Farm fill:#ff6666,color:#fff
    style C2 fill:#ff6666,color:#fff
    style Web_Portal fill:#ff6666,color:#fff
    style Telegram_Bot fill:#ff6666,color:#fff
    style Buyer fill:#ff6666,color:#fff
    style HLR fill:#ffaa66
    style SMSC fill:#ffaa66

Attack Sequence — Step by Step

sequenceDiagram
    participant Buyer as 👤 Criminal Buyer
    participant Portal as 🔴 OTP Service Portal
    participant C2 as 🔴 C2 Infrastructure
    participant SS7_GW as 🔴 SS7 Gateway
    participant SMSC as 📨 Target SMSC
    participant Service as 🏦 Bank / Email / SaaS

    Buyer->>Portal: 1. Browse available numbers
by country + carrier
    Portal->>Buyer: 2. Number list + pricing
(~$0.50-$5.00 per OTP)
    Buyer->>Portal: 3. Select number + pay (crypto)

    Buyer->>Service: 4. Request account creation
or password reset with
purchased number

    Service->>SMSC: 5. Send SMS OTP to number
    SMSC->>SS7_GW: 6. SMS routed via SS7
(or delivered to SIM farm)
    SS7_GW->>C2: 7. OTP captured

    C2->>Portal: 8. OTP available
    Portal->>Buyer: 9. OTP displayed
(or via Telegram bot)

    Buyer->>Service: 10. Enter OTP → account created/hijacked

    Note over Buyer,Service: Entire flow takes 30-120 seconds
Buyer can repeat for unlimited accounts

Technical Deep Dive

The access-broker ecosystem operates through multiple parallel interception channels:

Channel 1 — SS7 Interception (highest capability):

• Operator purchases SS7 access through a corrupt or complicit telco
• Uses UpdateLocation + MT-ForwardSM interception (same as Attack #1)
• Scales to any subscriber on any network reachable via SS7

Channel 2 — SIM Farm (most common):

• Operator purchases prepaid SIMs in bulk across many countries
• SIMs are inserted into GSM modem banks connected to servers
• Numbers are rented to buyers; incoming SMS is read directly from the SIM
• Does not require SS7 access — uses the legitimate network

Channel 3 — Android Malware (widest reach):

• 107,000+ malware samples distributed via fake apps, malvertising, and Telegram
• Malware requests SMS permission, then forwards all incoming SMS to C2
• Infected phones become unwitting participants in the OTP interception network
• Zimperium documented OTP theft for 600+ brands across 113 countries

Business model:

• Customers interact via Telegram bots or web portals
• Pricing: $0.50–$5.00 per OTP depending on country and carrier
• Some services offer subscriptions for continuous SMS forwarding
• Cryptocurrency payments for anonymity

Detection Indicators

• Multiple OTP requests from the same number in short succession for different services
• Numbers that receive OTPs but never make calls or send SMS (SIM farm pattern)
• Sudden increase in SMS delivery to specific MSC addresses (SS7 redirection)
• Android devices with SMS permission granted to unknown apps sending data to C2 domains
• Service-side signals: New account registrations from the same number for different user identities

STRIDE Assessment

Mitigation

• ✅ Eliminate SMS as a primary 2FA channel — migrate to TOTP, FIDO2, or push-based authentication
• ✅ Service-side number intelligence — flag numbers known to belong to SIM farms (services like Telesign, IPQualityScore)
• ✅ Device binding — bind MFA to a specific device, not just a phone number
• ✅ SS7 firewall (addresses SS7 interception channel only)
• ✅ Google Play Protect / app store enforcement — flag apps requesting SMS permissions without legitimate need
• ⚠️ User education — users should avoid granting SMS permissions to untrusted apps
• ⚠️ Rate limiting OTP issuance — limit how many OTPs a single number can receive per hour

References

• SecurityWeek: Massive OTP-Stealing Android Malware Campaign Discovered (2024)
• Zimperium zLabs: "SMS Stealer" campaign analysis (107,000+ samples, 113 countries)
• GSMA FS.11: SS7 Interconnect Security
• 3GPP TS 29.002: MAP Protocol (SMS interception operations)

5. GTP and Roaming-Plane Abuse for Fraud and Stealth Traffic (S, T, I, E)

Executive Summary

The GPRS Tunneling Protocol (GTP) — used across 2G, 3G, 4G, and 5G for user-plane tunneling and control-plane signaling between operators — has no built-in authentication or encryption. Malicious or compromised roaming partners have exploited GTP to inject traffic, create unauthorized data sessions, bypass billing, and establish covert communication channels through the roaming interconnect (GRX/IPX). These attacks are harder to detect than SS7 abuse because GTP traffic is high-volume and looks like legitimate roaming data.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Home Operator Network"
        HSS[(🔐 HSS)]
        MME[🎛️ MME]
        SGWC[⚙️ SGW-C]
        SGWU[📦 SGW-U]
        PGWC[⚙️ PGW-C/SMF]
        PGWU[📦 PGW-U/UPF]
        Internet[🌐 Internet]
    end

    subgraph "GTP Roaming Interconnect"
        GRX[🌐 GRX/IPX
GPRS Roaming
Exchange]
    end

    subgraph "Legitimate Roaming Partner"
        V_SGSN_OK[📦 Visited SGSN/MME
Legitimate partner]
    end

    subgraph "Attacker (Malicious Roaming Partner)"
        V_SGSN_Bad[🔴 Rogue SGSN/MME
Malicious or
compromised partner]
        Attacker_UPF[🔴 Rogue User Plane
Traffic injection]
    end

    V_SGSN_OK <-->|"GTP-C (legitimate
roaming sessions)"| GRX
    V_SGSN_Bad -.->|"❌ GTP-C: Fake
Create Session Request
(spoofed IMSI)"| GRX
    Attacker_UPF -.->|"❌ GTP-U: Injected
tunneled traffic
(spoofed TEID)"| GRX

    GRX <-->|"GTP-C"| SGWC
    GRX <-->|"GTP-U"| SGWU

    SGWC <--> MME
    SGWC <--> PGWC
    SGWU <--> PGWU
    MME <--> HSS
    PGWU <--> Internet

    style V_SGSN_Bad fill:#ff6666,color:#fff
    style Attacker_UPF fill:#ff6666,color:#fff
    style GRX fill:#ffaa66
    style SGWC fill:#ffaa66
    style SGWU fill:#ffaa66
    style PGWU fill:#ffee66
    style Internet fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Rogue Roaming Partner
    participant GRX as 🌐 GRX/IPX
    participant SGW as ⚙️ SGW-C (Home)
    participant PGW as ⚙️ PGW-C (Home)
    participant UPF as 📦 PGW-U/UPF (Home)
    participant HSS as 🔐 HSS (Home)
    participant Internet as 🌐 Internet

    Note over Attacker: Scenario A: Fraudulent Session Creation

    Attacker->>GRX: GTP-C: Create Session Request
(IMSI=spoofed, APN=internet
RAT=EUTRAN)
    GRX->>SGW: Forward Create Session Request
    SGW->>PGW: Create Session Request
(allocate IP, create GTP-U tunnel)
    PGW->>UPF: PFCP Session Establishment
(install forwarding rules)
    UPF->>PGW: PFCP Response (UE IP: 10.45.0.X)
    PGW->>SGW: Create Session Response
(GTP-U TEID for data plane)
    SGW->>GRX: Create Session Response
    GRX->>Attacker: Session established
(TEID + UE IP allocated)

    Note over Attacker: Attacker now has a GTP-U tunnel
through home operator to Internet
— billed to spoofed subscriber or operator

    Attacker->>GRX: GTP-U: Encapsulated IP packets
(using assigned TEID)
    GRX->>UPF: Forward GTP-U packets
    UPF->>Internet: Decapsulate → forward to Internet

    Note over Attacker: Scenario B: TEID Spoofing / Session Hijack

    Attacker->>GRX: GTP-U: Packets with
spoofed TEID of legitimate session
    GRX->>UPF: Injected into existing
subscriber's tunnel
    UPF->>Internet: Attacker traffic exits via
legitimate subscriber's IP

    Note over Attacker: Scenario C: Billing Bypass
    Note over Attacker: Create sessions with APN=free-tier
or exploit zero-rated data partners

Technical Deep Dive

GTP has two planes, both vulnerable:

GTP-C (Control Plane — UDP port 2123):

• Create Session Request / Create PDP Context Request — establishes new data sessions
• Modify Bearer Request — changes tunnel endpoints
• Delete Session Request — tears down sessions
• No authentication: Any GTP-C peer can create sessions for any IMSI
• No integrity protection: Messages can be spoofed or replayed

GTP-U (User Plane — UDP port 2152):

• Carries encapsulated user IP packets inside GTP tunnels
• Identified by TEID (Tunnel Endpoint Identifier) — a 32-bit value
• TEIDs are not cryptographically bound: If an attacker knows a TEID, they can inject packets
• No encryption: All user data visible inside the GTP tunnel

Attack variants:

Detection Indicators

• GTP-C sessions from unexpected GRX/IPX peers — Create Session Requests from operators not in roaming agreements
• IMSIs in Create Session Requests that don't match the source operator's IMSI range (MCC/MNC mismatch)
• GTP-U traffic volume anomalies — unusually high data volume from roaming sessions
• TEID reuse or collision — same TEID used from different source IPs
• Sessions with no corresponding authentication on S6a/Diameter — GTP session created without AIR/AIA exchange
• Asymmetric traffic patterns — data sessions with high download but no corresponding subscriber activity

STRIDE Assessment

Mitigation

• ✅ GTP firewall at GRX/IPX border — validate IMSI ranges, rate-limit session creation, block unknown peers
• ✅ IPsec on GTP interfaces (S1-U, S5-U, GRX-facing) — encrypt and authenticate GTP traffic
• ✅ TEID validation — cross-reference GTP-U TEIDs with active GTP-C sessions
• ✅ Correlate GTP-C with Diameter/S6a — ensure every session has corresponding authentication
• ✅ GSMA IR.88 — GTP security recommendations for roaming
• ⚠️ IPX provider filtering — depends on IPX provider enforcing source validation (inconsistent)
• ⚠️ GTP-U sequence number validation — provides limited replay protection but not widely enforced

References

• P1 Security: SMS-Based Attacks — The Hidden Threat Still Exploiting Mobile Networks
• GSMA IR.88: LTE and EPC Roaming Guidelines
• GSMA FS.20: GTP Security
• 3GPP TS 29.274: GTPv2-C Protocol Specification
• 3GPP TS 29.281: GTPv1-U Protocol Specification
• P1 Security: "GTP Security" research publications

Signaling Attack Summary

Attack Comparison Matrix

Combined STRIDE Profile

✅ = Primary impact, ⚠️ = Secondary/moderate impact

Standards Mapping

Lab Replicability

🔬 Lab Exercises

Using the Docker lab from Part 4, try these exercises to understand signaling attack surfaces:

Exercise 1: Observe Diameter S6a Authentication

# Capture Diameter traffic between MME and HSS
docker exec -it open5gs_mme tcpdump -i any -w /tmp/diameter_s6a.pcap tcp port 3868
# Attach a UE with UERANSIM, then open capture in Wireshark
# Filter: diameter
# Look for: Authentication-Information-Request (AIR) containing IMSI
# Look for: Authentication-Information-Answer (AIA) containing RAND, AUTN, XRES
# Question: Is TLS negotiated? (Look for Capabilities-Exchange-Request TLS AVP)

Exercise 2: Capture GTP-U and Inspect User Plane

# Capture GTP-U traffic on the UPF
docker exec -it open5gs_upf tcpdump -i any -w /tmp/gtpu.pcap udp port 2152
# Generate traffic: docker exec -it ueransim_ue ping -c 5 8.8.8.8
# Open in Wireshark, filter: gtp
# Observe: Inner IP packets (UE's traffic) visible in cleartext inside GTP-U tunnel
# Find the TEID in the GTP header — this is the only session identifier
# Question: What prevents an attacker from injecting packets with this same TEID?

Exercise 3: Examine GTP-C Session Creation

# Capture GTP-C signaling (control plane)
docker exec -it open5gs_smf tcpdump -i any -w /tmp/gtpc.pcap udp port 2123
# Trigger a PDN session by registering a UE
# Filter: gtpv2
# Look for: Create Session Request (IMSI, APN, RAT type)
# Look for: Create Session Response (allocated IP, TEID)
# Question: What authentication exists in GTP-C to prevent spoofed Create Session Requests?

Exercise 4: Simulate GTP-U Injection with Scapy

# On a machine with access to the Docker network:
pip install scapy
python3 -c "
from scapy.all import *
from scapy.contrib.gtp import GTPHeader

# Craft a GTP-U packet with a known TEID (from Exercise 2)
pkt = IP(dst='UPF_IP') / UDP(dport=2152) / GTPHeader(teid=0x12345678) / IP(dst='8.8.8.8') / ICMP()
send(pkt)
# If the UPF accepts this, the packet will be forwarded — demonstrating lack of source validation
"

3GPP and Industry References

Summary

• ✅ SS7 signaling attacks remain the most impactful telecom threat due to the protocol's inherent lack of authentication
• ✅ The move from SS7 to Diameter (4G) did not eliminate signaling-plane attacks — it changed the protocol but not the trust model
• ✅ GTP attacks are harder to detect than SS7/Diameter because they blend with legitimate high-volume roaming traffic
• ✅ The commercialization of SS7 interception (OTP-as-a-service) has lowered the barrier from nation-state to commodity cybercrime
• ✅ Effective defense requires signaling firewalls (SS7, Diameter, GTP) combined with industry coordination (GSMA, IPX providers)

Next: Part 12: Real-World Attacks — Subscriber Identity & SIM →