Why this module exists: if you understand how an attack works, the defence becomes obvious. Every attack below is explained as mechanism → why it works → what it looks like in the network → defence. The descriptions are at the level of public GSMA, academic and conference material (Engel, Nohl, Positive Technologies, AdaptiveMobile, ENISA). Nothing here replaces authorisation: only test on your own lab or with written permission.
0. The root cause in one sentence
Telecom signalling was designed in the 1980s for a closed club of trusted operators. A message is believed because it arrived from the interconnect, not because the sender proved anything. Anyone who gets a signalling address (leased Global Title, hacked operator, insider, rogue partner) can talk as an operator.
How an attacker gets access
| Route | Explanation | Defence |
|---|---|---|
| GT leasing | A legitimate operator leases a Global Title (and a point of access) to a third party who then sends any traffic | GSMA FS.52 code of conduct, due diligence, contract terms, monitoring of leased GTs |
| Rogue / small operator | Licence in a low-oversight country gives full interconnect rights | Counterparty risk lists, firewall rules per partner, throttling |
| Compromised operator or vendor | Real attack on a partner network (e.g. via management system) | Firewall at the border and distrust of "friendly" partners |
| Insider | Employee or contractor with signalling access | Role separation, logging, four-eyes |
| Aggregator / hub | An intermediate carrier forwards unfiltered traffic | Require filtering by hubs; screen by origin not just by next hop |
| SIGTRAN exposed to Internet | Misconfigured SCTP/M3UA endpoints | Never expose; allow-listing; VPN/IPsec |
| SMS or radio-side (no signalling access needed) | Fake base station, malicious SMS | Radio and SIM defences (Module 27) |
1. SS7 / MAP attacks
SS7 layers (Module 4): MTP → SCCP → TCAP → MAP/CAP/ISUP. An attacker sends well-formed messages with the wrong intent, so a firewall must judge intent and context, not syntax.
1.1 Subscriber discovery — "what is the IMSI / where is the phone?"
| Item | Detail |
|---|---|
| Message abused | SendRoutingInfoForSM (SRI-SM) (also SRI, SendIMSI) |
| Mechanism | The attacker asks the subscriber's home HLR "where do I deliver an SMS to +385…?" The HLR answers (as designed) with the IMSI and the address of the serving MSC/VLR |
| Why it works | SMS routing must work for every sender in the world, so the HLR answers any caller |
| What it gives | The IMSI (needed for most other attacks) and the country/network where the phone is (coarse location); also whether the number is active, roaming, ported |
| Looks like | A burst of SRI-SM from one GT with no SMS following (real senders follow with MT-ForwardSM); sequential or random number ranges |
| Defence | SMS Home Routing — HLR returns the operator's own SMSC address plus a fake/ID-masked IMSI so the sender never learns the real IMSI or MSC; block unknown GTs; velocity limits per source; sanity: "does the source GT belong to an SMSC of a real SMS operator?" |
1.2 Location tracking
| Item | Detail |
|---|---|
| Messages abused | AnyTimeInterrogation (ATI), ProvideSubscriberInfo (PSI), SRI + PRN side effects, SendRoutingInfo for LCS |
| Mechanism | ATI asks the HLR for the subscriber's current location and state; PSI goes to the VLR/MSC and returns the Cell ID (precision of a few hundred metres in cities) |
| Why it works | ATI was meant for service nodes inside the network (e.g. gsmSCF), but interconnect may not block it; PSI is a normal HLR→VLR operation, so a spoofed "HLR" gets an answer |
| Looks like | ATI or PSI from outside the home network; PSI from a GT that is not the subscriber's HLR |
| Defence | Category 1 blocking of ATI from external sources; PSI only from the subscriber's own HLR GT; HLR disabled for ATI except from known internal GTs; correlate with the location-update history (Category 2) |
1.3 Interception of SMS (and therefore OTP / 2FA)
| Item | Detail |
|---|---|
| Message abused | UpdateLocation (UL) → HLR, and InsertSubscriberData (ISD) back |
| Mechanism (conceptual) | The attacker, posing as a VLR/MSC of a foreign network, tells the home HLR "this IMSI is now in my area". The HLR updates the subscriber's location to the attacker's address and sends future MT-SMS to that address. The real phone still shows signal because its own VLR is not told (until a cancel location) |
| Why it works | The HLR trusts location updates from any GT; it does not verify that the phone is physically there |
| Needs | Victim's IMSI (see 1.1) |
| Real-world impact | OTP and banking mTAN theft — documented in 2017 when criminals used SS7 to drain German bank accounts (reported by Süddeutsche Zeitung) |
| Looks like | UpdateLocation from a foreign GT for a subscriber who is demonstrably at home (their own VLR was seen minutes ago); two registrations in different countries within seconds |
| Defence | Category 2/3 consistency checks: reject UL when the claimed VLR/MSC cannot be reached in the time since the last update (impossible travel); "subscriber is home" flag; alerting on UL from non-roaming-partner GT; push for non-SMS authentication (app/FIDO) in banks |
1.4 Interception and redirection of calls
| Item | Detail |
|---|---|
| Messages abused | InsertSubscriberData (to set call-forwarding numbers or CAMEL triggers), ProvideRoamingNumber (PRN), RegisterSS / ActivateSS |
| Mechanism | By inserting an unconditional call-forwarding target or a CAMEL (CAP) trigger that sends call control to an attacker-run service node, incoming/outgoing calls are routed through the attacker. PRN with a controlled MSC lets calls be sent to a rogue number |
| Defence | Block ISD/ISD-like operations from outside; allow only the subscriber's home HLR; block external CAMEL subscription data; alarm on new forwarding numbers; Category 1 for ActivateSS/RegisterSS from interconnect |
1.5 Denial of service and disruption
| Attack | Mechanism | Defence |
|---|---|---|
| Cancel Location flood | Repeated CancelLocation/PurgeMS for a victim forces re-registration; phone loses service or calls fail | Allow CancelLocation only from the registered HLR; rate limit per IMSI |
| ISD with barring data | Insert "barring all calls" into the VLR's copy | Category 1 for external ISD |
| SMS delivery refusals | Attacker answers absent subscriber / reports ReportSMDeliveryStatus failures so the SMSC thinks the phone is unreachable | Validate that delivery status comes from the real serving node |
| Signalling storm | Mass of valid messages (e.g. SRI, UL) that exhausts HLR CPU | Per-GT and per-operator throttling, overload control |
| SCCP management flood | Spoofed SSP/SSA/SST messages make STPs believe nodes are down | Authenticate SCCP management; filter SCMG from outside |
| MTP3 spoofing / DPC fuzzing | Fake point codes or unknown DPCs cause misrouting | Screening at MTP3 on OPC/DPC allow-lists |
1.6 USSD abuse
| Item | Detail |
|---|---|
| Message | ProcessUnstructuredSS-Request (PUSSR) to the HLR or MSC |
| Mechanism | An external party sends a USSD string that the operator would normally accept only from its own subscribers (balance, top-up, call-forward codes) |
| Defence | Allow USSD only from the subscriber's serving network, block from foreign GTs; require home-routing of USSD |
1.7 SMS injection and spoofing (MO-ForwardSM, MT-ForwardSM)
| Item | Detail |
|---|---|
| Mechanism | Injecting MT-ForwardSM with an arbitrary originating address, or MO-ForwardSM as if from a subscriber, so the message appears to come from "BANK" or a friend |
| Why it works | MAP does not check that the claimed originator is the real one |
| Defence | SMS firewall rules: MT-ForwardSM must come from an SMSC GT registered for that subscriber's SRI-SM session (correlation: SRI-SM followed by MT-ForwardSM from the same GT); IMSI/MSC checks; sender-ID registries; blocking spoofed domestic senders from international links |
1.8 SS7 plus CAMEL: toll fraud and prepaid abuse
Manipulating CAMEL initial detection points or CAP messages can zero the cost of calls or redirect prepaid charging. Defence: CAP only from gsmSCF peers, GT/IMSI validation, fraud management on CDRs.
1.9 ISUP attacks (the voice side)
| Attack | Mechanism | Defence |
|---|---|---|
| CLI (caller ID) spoofing | The Calling Party Number in the IAM is set freely | Reject international calls claiming a national CLI; CLI validation against origin; STIR/SHAKEN in SIP |
| IAM flooding / SIP-ISUP gateway overload | Mass of IAMs exhaust circuits | Rate limit per trunk; congestion control |
| REL injection | A spoofed REL drops a live call | Circuit/CIC consistency checks, secure transport |
| Number harvesting | ACM/ANM patterns reveal live numbers | Throttle probes |
1.10 SIGTRAN transport attacks
| Attack | Mechanism | Defence |
|---|---|---|
| SCTP INIT flood / association hijack | SCTP handshake abuse | SCTP cookies, firewalls, IPsec, allow-list by IP |
| M3UA ASP-UP/DUPU spoofing | Fake "unavailable" for point codes | Authenticate peers; network segregation |
| Unfiltered SCTP on public IPs | Direct access to SIGTRAN from internet | Never expose; private IPX only |
2. Diameter attacks (4G / IMS)
Diameter (RFC 6733) runs over TCP/SCTP and uses Origin-Host / Origin-Realm and application IDs. It supports security (TLS/IPsec) but interconnect usually runs without end-to-end authentication, so the same trust problem returns.
| Attack | Mechanism | Why it works | Defence |
|---|---|---|---|
| Subscriber discovery | S6c SRI-SM (SMS home routing in LTE) or Send-Routing-Info for SM via Diameter-SS7 interworking asks for IMSI and serving MME | Same design reason as SS7 | Diameter home routing; block from untrusted realms |
| Location tracking | ULR-like or IDR to ask the HSS/MME, Provide-Location-Request (PLR, SLg), S6a Insert-Subscriber-Data | MME/HSS reply to a peer that looks legitimate | Realm/host verification, allow only roaming partners, block LCS ops from outside |
| Auth-vector harvesting | Authentication-Information-Request (AIR) sent to HSS to obtain RAND/AUTN/XRES/KASME (the partner is entitled to ask for vectors for its roamers) | Over-broad permission lets an attacker request vectors for any IMSI | Authorise AIR only for real roaming relationships; ratio checks (vectors per IMSI); vector reuse limits |
| Denial of service | Cancel-Location-Request (CLR), Purge-UE-Request, Insert-Subscriber-Data with barring, Delete-Subscriber-Data; Result-Code 5004/5420 responses | HSS/MME believe peer; subscribers lose service | CLR only from the registered HSS; rate limits; Origin-Realm = home realm checks |
| Subscriber profile manipulation | ISD to change APN, QoS, barring or AMBR for free data | Trusting inbound ISD | Block ISD from roaming partners |
| Fraud via roaming | Tampering with Gx/Gy (charging/policy) is internal, but a malicious visited network can lie in CDRs (TAP) | Roaming fraud monitoring (NRTRDE), steering/limits | |
| Diameter ↔ SS7 interworking | An IWF (interworking function) converts Diameter into MAP, so a Diameter attacker reaches SS7 weaknesses | Weak filters at IWF | Treat IWF as border; firewall after conversion |
| Replay / spoofing of Session-Id | Sessions hijacked | Lack of message integrity | TLS/IPsec, Diameter DEA with whitelist |
| Loop / route manipulation | Misuse of Route-Record, Redirect-Host | Proxy trusts headers | Verify path, strip untrusted headers |
| Overload | Floods of CER/DWR or AIR | Weak protection of peer endpoints | Rate limits, DOIC (Diameter Overload Indication) |
DEA / DRA firewall rules (conceptual): 1. Is the Origin-Realm a known roaming partner for this IMSI's PLMN? 2. Is the command allowed from outside? (e.g. IDR, CLR, PLR → no) 3. Does the IMSI belong to this operator (home subscriber) or to the partner (visited)? 4. Is time/location consistent with the subscriber's last known attach? 5. Is the rate per IMSI/realm acceptable?
3. GTP attacks (2G/3G/4G data roaming)
GTP-C (control) uses UDP 2123, GTP-U (user) 2152. Roaming runs over GRX/IPX (S8 for LTE, Gp for 2G/3G). An attacker who can send GTP to your SGW/PGW/GGSN can:
| Attack | Mechanism | Defence |
|---|---|---|
| Fake session creation (data theft) | Create Session Request with a victim's IMSI from a roaming link — the home PGW builds a session, charges the victim, and gives the attacker internet | Validate IMSI belongs to the claimed roaming partner and that the session is consistent with the subscriber's actual attach (Diameter S6a records) |
| Session hijacking / TEID guessing | TEID (tunnel ID) is 32 bits; weak randomisation or predictable allocation lets an attacker send GTP-U or Modify Bearer messages that redirect traffic | Randomised TEIDs, source IP/TEID check, anti-spoofing at GRX edge |
| Session deletion DoS | Delete Session Request with guessed TEID drops the subscriber | Same plus rate-limits |
| Subscriber enumeration | Probing Create PDP Context or Echo/Version-Not-Supported to learn whether an IMSI exists (different error causes leak existence) | Normalise error responses; block probing from non-partners |
| Network scanning via the data plane | A roaming PDP context gives IP access to internal management networks if APN/firewalling is wrong | Isolate Gi/SGi; ACLs; no internal routes to roaming APNs |
| Billing manipulation | Spoof Charging ID, QoS parameters | Verify charging records at the home side |
| Echo / path attacks | Floods of GTP echo | Rate limiting |
| GTP-U injection | Inject packets into someone else's tunnel (spoofed TEID) | Ingress filtering, GTP firewall that tracks established tunnels (stateful) |
GTP firewall: stateful — it records which sessions were legitimately created and drops GTP-U/Modify/Delete not matching an existing tunnel; checks IMSI ↔ source PLMN, APN allow-lists, RAT type, Cause codes and message-rate.
4. SIP / IMS attacks
SIP (RFC 3261) is text-based, widely scanned, and often runs over UDP.
| Attack | Mechanism | Defence |
|---|---|---|
| Scanning & enumeration | Automated OPTIONS/REGISTER to find live SIP servers and valid users (responses differ for existing/non-existing users) | Uniform replies, rate limit, hide behind SBC |
| Registration brute force / hijack | Guess digest passwords on REGISTER; once registered, the attacker makes calls | Strong credentials, fail2ban-like blocking, IMS-AKA (SIM-based) for VoLTE |
| INVITE flood (DoS) | Mass INVITEs consume CPU/ports | SBC rate limits, overload control, connection tracking |
| Toll fraud / IRSF via compromised PBX | Attacker uses hacked PBX/softphone to call premium numbers | Spend limits, destination barring, anomaly detection on CDRs |
| Caller ID spoofing | From / P-Asserted-Identity is accepted from untrusted trunks |
STIR/SHAKEN (Authentication Services sign Identity header), SBC strips untrusted headers |
| SPIT (Spam over IP Telephony), robocalls | High-volume automated calls | Call analytics, reputation, call labelling |
| Header / SDP injection, malformed messages | Fuzzing causes crashes (older stacks) | SBC protocol normalisation, patching |
| RTP bleed / injection / eavesdropping | Media streams predictable; no encryption | SRTP/DTLS-SRTP, SBC media anchoring, port randomisation |
| Registration/INVITE through SBC bypass | Direct access to core nodes from the internet | Only expose the SBC; IP allow-lists |
| VoLTE roaming abuse | S8HR trust: the visited network's P-CSCF may lie about identity or location | IBCF/ATCF screening, IR.92/IR.65 guidelines |
| Emergency-call abuse | Fake 112 calls overload PSAPs (swatting), or location spoofing | Caller verification, CLI checks, rate limits |
5. 5G core attacks (service-based architecture)
The 5G SBA uses HTTP/2 + JSON with OAuth2 and mTLS, so the attack surface moves from telecom-specific protocols to web and cloud security.
| Attack | Mechanism | Defence |
|---|---|---|
| NF impersonation | Rogue function registers in NRF or reuses a stolen access token | mTLS between NFs, OAuth2 scopes, short-lived tokens, NRF authorisation policy |
| Token theft / replay | Capturing Authorization: Bearer |
TLS everywhere, binding tokens to client cert |
| API abuse of NEF | Third-party apps misuse exposure APIs (location, monitoring, QoS requests) | API gateway, OAuth, rate limits, per-app authorisation, logging |
| SBA injection / parameter tampering | JSON/URL manipulation of SMF/AMF calls | Input validation, schema checks, WAF at SCP |
| HTTP/2 specific DoS | e.g. Rapid Reset (CVE-2023-44487), stream floods | Patch, concurrency limits, rate limits |
| N32 / roaming attacks | Manipulating inter-PLMN signalling to the SEPP; downgrade attempts; misconfigured PRINS | Mutual TLS N32-c, correct JWS/JWE protection modes, strict SEPP policy |
| N4 (PFCP) attacks | Forged Session Modification/Deletion with guessed SEID from a rogue node | Isolated N4 network, IPsec, UPF-side peer allow-list |
| N2/NGAP abuse | Rogue gNB or compromised radio site sending to AMF | IPsec on backhaul (NG interface), gNB authentication (certificates) |
| Slice isolation breach | Misconfigured S-NSSAI policies or shared components allow cross-slice access | Strict separation, per-slice policies, tests, monitoring |
| SUCI/SUPI attacks | Poorly configured null scheme (SUCI sent unencrypted) exposes SUPI | Disable null scheme, home network public-key provisioning |
| Bidding-down | Forcing the UE to 4G/3G/2G where weaker protections apply | Policy to disable 2G, minimum security levels, network settings |
| Cloud-native attacks | Container escape, exposed Kubernetes API, vulnerable images, secrets leakage, Log4Shell-style library bugs | Container hardening, image scanning (SBOM), network policies, secrets vault, runtime detection |
| Supply-chain | Backdoors or malicious updates in vendor software | Vendor assurance (NESAS/SCAS), code signing, EU 5G Toolbox measures |
The MITRE FiGHT knowledge base (5G adversary tactics and techniques) and ATT&CK are useful frameworks for mapping these attacks to detections.
6. Attack chains (how single steps combine)
Chain A — SMS-OTP theft (classic SS7)
- Discover IMSI (SRI-SM) →
- Re-register subscriber at attacker address (UpdateLocation) →
- Victim requests password reset by SMS; the SMS goes to the attacker (MT-ForwardSM) →
- Attacker logs in, optionally restores location (cancelling).
Break the chain: hide IMSI (home routing) · block external UL for home subscribers · detect impossible travel · stop using SMS as the only second factor.
Chain B — Tracking
IMSI discovery → PSI/ATI repeated every minute → Cell-ID database lookup → movement profile. Break: block PSI/ATI; alert on repeated queries per MSISDN.
Chain C — Data theft and fraud via GTP
IMSI known → Create Session Request on the roaming link → free internet charged to victim. Break: validate IMSI vs. partner PLMN; cross-check with S6a attach.
Chain D — Voice interception via CAMEL
IMSI → ISD inserting CAMEL trigger → calls pass through attacker's gsmSCF. Break: block external ISD/CAMEL data; monitor subscription changes.
7. Detection cheat sheet (signals the SOC looks for)
| Signal | Possible attack |
|---|---|
| Many SRI-SM/SRI/ATI from one GT, no follow-up MT-ForwardSM | Reconnaissance, tracking |
| UpdateLocation for a home subscriber from foreign GT | SMS/call interception |
| PSI/ATI where source is not the subscriber's HLR | Location tracking |
| ISD with CAMEL/forwarding data from outside | Call interception |
| Impossible travel between registrations | Spoofed location updates |
| AIR volume per IMSI far above normal | Vector harvesting |
| CLR/Purge waves | DoS |
| Create Session from IMSI that is not attached via S6a | Fake GTP session |
| Spike in TEID errors / Delete Session | GTP hijack attempt |
SIP OPTIONS or REGISTER from many IPs with 401/403 |
SIP scanning/brute force |
| International traffic with national CLI | Spoofing |
| Sudden rise in premium-destination calls at night | IRSF / PBX fraud |
| NF registrations with new certificates/IDs | Possible rogue NF |
| 429/503 storms in SBA | HTTP/2 DoS |
Remember this: every signalling attack is a legitimate message in the wrong context — wrong sender, wrong place, wrong frequency or wrong order. Defence is therefore context checking: who is asking, for whom, from where, how often, and does it match what I know about that subscriber?