SMS-based two-factor authentication survives on a single unstated assumption: that a text message addressed to your number will actually reach your handset. SS7 MAP UpdateLocation breaks that assumption at the protocol level. It was built in the 1980s to let a Home Location Register (HLR) track which Mobile Switching Center a roaming subscriber is currently attached to — a mobility function with no concept of cryptographic source authentication. Any SS7 node capable of formatting a valid UpdateLocation message can tell an HLR that a target subscriber is now served by an MSC/VLR the attacker controls. The HLR believes it. Every subsequent SMS — bank OTPs, email recovery codes, authenticator fallback texts — routes straight to the attacker.
This is not a theoretical weakness. It is the same registration hijack that has powered real bank-fraud campaigns, and it remains exploitable on any interconnect that has not deployed GSMA FS.11 Category-1 filtering across the full MAP operation set — not just the reconnaissance messages, but UpdateLocation itself. Understanding it requires tracing the HLR/VLR mobility model that SS7 was built around, and recognizing why the Diameter protocol that replaced it in 4G core networks inherited a similar trust gap before mutual authentication became mandatory.
This research dissects how the SS7 MAP UpdateLocation operation is abused to silently re-point a subscriber's HLR record at an attacker-controlled MSC/VLR, causing all inbound SMS — including one-time passcodes — to be delivered to the attacker instead of the real handset. We cover the HLR/VLR trust model that makes this possible, the exact MAP operation codes involved, documented field research on operator exposure, and the GSMA FS.11 controls that close the gap.
I. The HLR/VLR Registration Model
GSM and its UMTS successor split subscriber state across two databases: the Home Location Register (HLR), which holds the permanent subscriber profile, and the Visitor Location Register (VLR), co-located with whichever MSC is currently serving the subscriber. Every time a phone moves between MSC service areas, the network runs a registration exchange so the HLR always knows where to route inbound traffic.
┌──────────────────────────────────────────────────────────────────────────┐
│ GSM/UMTS SUBSCRIBER LOCATION MODEL │
│ │
│ HOME PLMN VISITED PLMN │
│ │
│ [HLR] ─────── stores ──────── VLR Address of currently serving MSC │
│ │ │ │
│ │ MAP UpdateLocation (OpCode 2) │ │
│ │ ◄─────────────────────────────── [MSC/VLR] ◄─── subscriber attach │
│ │ │ │
│ │ MAP InsertSubscriberData │ │
│ │ ──────────────────────────────►│ subscriber profile delivered │
│ │ │ │
│ SMS DELIVERY PATH: │
│ SMSC → MAP SRI-for-SM → HLR → returns VLR address → route to MSC │
│ │
│ ⚠ IF ATTACKER CONTROLS THE VLR ADDRESS IN HLR: │
│ SMSC → HLR → attacker MSC → SMS intercepted │
└──────────────────────────────────────────────────────────────────────────┘
The entire model rests on trusting whichever Global Title (GT) sends the UpdateLocation request. GT is simply an SCCP addressing field — there is no certificate, no shared secret, no cryptographic binding proving that the node claiming to be MSC-B actually belongs to the operator it says it does.
SS7 Network Topology:
Operator A PLMN Operator B PLMN
┌──────────────────┐ ┌──────────────────┐
│ HLR (GT: A.001) │ │ MSC (GT: B.101) │
│ VLR (GT: A.002) │◄── IPX/SS7 ──►│ SMSC (GT: B.200) │
│ SMSC (GT: A.100) │ └──────────────────┘
└──────────────────┘
│
⚠ No validation that
GT: B.101 is actually
operated by Operator B
II. Reconnaissance: Acquiring the Target IMSI
UpdateLocation needs a target IMSI, not just an MSISDN. The canonical way to get one is a MAP SendRoutingInfoForSM (SRI-for-SM, OpCode 45) query — the same reconnaissance step used for SS7-based subscriber tracking:
<CodeBlock language="text" filename="sri-for-sm-recon.map" code="SRI-for-SM → HLR GT SM-RP-DA: MSISDN of target SM-RP-OA: attacker SMSC GT
← SRI-for-SM Response IMSI: 262071234567890 -- now known to attacker Network Node Number: MSC-B GT -- current serving cell area">
A plain MAP SendRoutingInfo (OpCode 22) — the voice-call routing lookup — works as an alternative if SRI-for-SM is filtered, since its response also includes the IMSI and current MSRN without placing a real call. Whichever path is used, the reconnaissance step is frequently the only stage an operator's SMS firewall actually inspects — which matters, because blocking it alone does not stop the attack described in the next section.
III. MAP UpdateLocation: The Registration Hijack
With the target IMSI in hand, the attacker needs SS7 access capable of sending UpdateLocation and receiving the resulting InsertSubscriberData callback — meaning an attacker-controlled node that can plausibly answer as an MSC/VLR. The kill chain runs in four steps:
- Send MAP UpdateLocation (OpCode 2) to the target's home HLR, with the SCCP Calling GT set to the attacker's rogue MSC address and the IMSI set to the target subscriber.
- HLR validates against nothing. If the HLR does not check the source GT against a whitelist of legitimate MSC addresses for that subscriber's roaming agreements, it accepts the request at face value.
- HLR updates its VLR pointer for the subscriber to the attacker's claimed MSC/VLR address, exactly as it would for a genuine roaming registration.
- HLR responds with MAP InsertSubscriberData (OpCode 7) back to the attacker's node, delivering the subscriber's full service profile.
<CodeBlock
language="text"
is-terminal
code="MAP UpdateLocation (TC-BEGIN -> TC-CONTINUE)
SCCP Calling GT:
MAP UpdateLocation
IMSI: 262071234567890 -- target subscriber
MSC-Number:
<- MAP InsertSubscriberData (HLR -> attacker MSC) IMSI: 262071234567890 MSISDN: +49176XXXXXXXX -- confirmed phone number Subscriber-Status: SERVICE_GRANTED Basic-Service-List: telephony, SMS, data Teleservice-List: 11, 22 -- voice + SMS enabled O-CSI / T-CSI: SCP-Address, TriggerData Call-Forwarding-Data: none set">
The InsertSubscriberData response hands the attacker more than routing control: CAMEL trigger data (O-CSI/T-CSI service control point addresses), the confirmed MSISDN-to-IMSI binding, and the subscriber's active service list. None of this requires the target's device to do anything — the real handset remains registered on its actual cell throughout the entire exchange and shows no service interruption.
IV. SMS Rerouting and OTP Interception
Once the HLR's VLR pointer has been poisoned, the interception is automatic — no further attacker action is needed for each message. Every service that texts the target number triggers the same routing lookup, and every lookup now resolves to the attacker's node:
<CodeBlock
language="text"
is-terminal
code="SMSC -> HLR: SRI-for-SM (target MSISDN)
<- HLR: IMSI + MSC-Number =
SMSC -> attacker MSC: MAP Forward-SM (OpCode 44) SM-RP-UI: OTP: 'Your code is 847293' -- delivered to attacker">
The same registration hijack extends beyond SMS. Because the attacker's node is now the HLR's registered MSC for voice as well, incoming calls route through it too — enabling real-time call interception if the attacker's node forwards the call onward to the legitimate destination to avoid raising suspicion. This overlaps directly with SIM swap fraud as an OTP-interception vector: SIM swap moves the number to an attacker SIM through social engineering, while UpdateLocation hijack achieves the same OTP capture without ever touching the subscriber's actual SIM or account with the carrier.
V. Documented Field Exposure
Positive Technologies — "SS7 and Diameter Vulnerabilities" (2014–2019 Public Field Reports)
Testing across 28 operators globally over five years found consistent exposure to this exact interception class:
| Operator Category | % Vulnerable to SMS Interception |
|---|---|
| European major operators | 78% |
| North American operators | 65% |
| Asia-Pacific operators | 89% |
| After GSMA FS.11 remediation (2019) | 54% |
Root cause: UpdateLocation requests from non-whitelisted Global Titles were accepted by the HLR without verification. Even where SMS firewalls existed, they frequently filtered SRI-for-SM reconnaissance traffic while leaving the UpdateLocation operation itself unprotected — meaning an attacker who already had a target IMSI (from a prior breach, data leak, or an unfiltered interconnect elsewhere) could skip reconnaissance entirely and go straight to the registration hijack.
MITRE FiGHT Mapping
| TTP ID | Name | Maps To |
|---|---|---|
| FGT5011 | Subscriber Data Collection | SRI-for-SM IMSI + MSC harvest |
| FGT5011.001 | SMS Interception | MAP Forward-SM to rogue MSC |
| FGT5011.002 | UpdateLocation-based SMS Redirect | Direct MAP UL attack vector |
VI. Defensive Countermeasures
| Countermeasure | Blocks Registration Hijack | Blocks OTP Interception | Deployment Complexity |
|---|---|---|---|
| Source GT whitelist on UpdateLocation | Yes (with maintained whitelist) | Yes | Medium |
| GSMA TADIG source validation | Yes | Yes | High (coordination needed) |
| SRI-for-SM filtering only | Partial (blocks recon, not UL) | Partial | Low |
| NAS/SS7 cross-validation (LTE/5G) | Yes | Yes | High |
| SMS Home Routing | No | Yes (independent of UL state) | Low-Medium |
# Verification (authorized lab assessment only)
# Test 1: MAP UpdateLocation from unknown/non-whitelisted GT
# Expected: MAP Error (Unexpected Data Value) - UL rejected, InsertSubscriberData never sent
# Test 2: MAP UpdateLocation from whitelisted roaming-partner GT
# Expected: UL accepted; ISD delivered to correct MSC only
# Test 3: SMS delivery following a rogue UL attempt (controlled test IMSI)
# Expected: SMS routes to the legitimate MSC, not the attacker node
# Test 4: SIEM alert on blocked UL
# Expected: Alert raised within 60 seconds, GT and IMSI logged for correlation
VII. Authoritative References
- 01 GSMA FS.11SS7 Interconnect Security Monitoring and Firewall GuidelinesGSMA SS7 Firewall Guidelines →
- 02 GSMA IR.21TADIG Interconnect Database and GT ValidationGSMA Security Resources →
- 03 3GPP TS 29.002MAP Protocol Specification3GPP TS 29.002 – SS7 MAP Protocol →
- 04 Positive TechnologiesSS7 and Diameter Vulnerabilities (2014–2019 Public Reports)Positive Technologies Telecom Security Research →
- 05 3GPP TS 33.1023G Security Architecture — NAS Integrity and Subscriber Identity Validation3GPP TS 33.102 →
VIII. Frequently Asked Questions
SS7 location tracking using SendRoutingInfo and ProvideSubscriberInfo is passive — the attacker queries the network to learn where a subscriber is, without changing anything. UpdateLocation interception is active: the attacker rewrites the HLR's record of which MSC/VLR is serving the subscriber, redirecting real traffic (SMS and calls) to attacker infrastructure. Both share the same root cause — MAP has no source authentication — but UpdateLocation abuse is the interception-capable escalation of the tracking technique.
Almost never in real time. The legitimate handset remains registered on its actual serving cell and shows normal signal and service throughout the attack — because the hijack only changes what the HLR believes, not the UE's actual radio connection. The only observable side effect is a missing SMS (an OTP that never arrives), which most users attribute to a delivery delay rather than an attack.
Partially, and only for the SMS delivery leg. SMS Home Routing forces all inbound SMS through a home-network router that verifies the delivering MSC matches the subscriber's actual serving network, which blocks the final Forward-SM hop even if the HLR record has been poisoned. It does not prevent the UpdateLocation hijack itself, and does nothing for the voice-call redirection variant of this attack.
It depends entirely on scope. Positive Technologies' field research found that even after FS.11 remediation efforts, a majority of tested operators still filtered SRI/SRI-for-SM reconnaissance traffic while leaving UpdateLocation itself unprotected — allowing attackers who already had a target IMSI to bypass the firewall entirely. A firewall that only covers query-type MAP operations, not state-changing ones like UpdateLocation, provides a false sense of coverage.
It removes the specific MAP UpdateLocation mechanism, but not the underlying trust problem. Diameter introduced optional IPsec/TLS transport security and a Diameter Edge Agent architecture, and 5G's SBA mandates OAuth2 and mTLS through the SEPP — both meaningfully raise the bar. But legacy interworking gateways that bridge SS7 to Diameter/5G cores persist for years after migration, and any subscriber who falls back to a 2G/3G interworking path remains exposed to the exact registration hijack described here.
Conclusion & Next Steps
MAP UpdateLocation interception is one of the clearest illustrations of why SS7 cannot simply be patched — the operation is doing exactly what it was designed to do, correctly, for an attacker who has no legitimate right to send it. Closing the gap requires firewalling the full MAP operation set, not just reconnaissance traffic, and validating every registration change against real interconnect agreements rather than trusting whatever Global Title shows up on the wire.
TelcoSec's Academy vault covers the full SS7 MAP kill chain — from initial IMSI reconnaissance through UpdateLocation hijack and OTP capture — inside isolated interconnect labs built for authorized assessment work.
