A single MAP message, sent from anywhere in the world with nothing more than a rented Global Title, is enough to learn a stranger's permanent subscriber identity and the mobile switch currently serving their handset. No malware, no physical proximity, no interaction from the target. This is SendRoutingInfoForSM (SRI-for-SM) — a routine SMS-delivery lookup that has become the opening move in the majority of documented SS7 surveillance operations.
SRI-for-SM is not an obscure edge case. It is the reconnaissance step that every downstream SS7 attack depends on: the IMSI and serving-node address it returns are the raw material for AnyTimeInterrogation cell-level tracking, UpdateLocation SMS hijacking, and call redirection. Understanding this one message — why it exists, why it leaks what it leaks, and how it is stopped — explains most of what is wrong with legacy signaling security.
This case study builds on the broader SS7 location-tracking overview by walking through a single attack end to end: the reconnaissance an operator's SS7 footprint permits, the exact message exchange that discloses subscriber identity and location, the documented real-world incident that forced regulatory action, and the specific controls (GSMA FS.11 Category 1) that close the gap.
This report dissects SendRoutingInfoForSM (MAP OpCode 45) — the single most-abused SS7 message for subscriber geolocation. We cover the Global Title reconnaissance that precedes an attack, the exact request/response fields that leak IMSI and serving-MSC data, the escalation path to cell-level positioning via AnyTimeInterrogation, the 2017 O2-DE demonstration that made this attack a matter of public record, and the GSMA FS.11 Category 1 controls that stop it.
I. Why SRI-for-SM Is Exploitable by Design
SendRoutingInfoForSM is a legitimate MAP (Mobile Application Part) operation. Its intended purpose is mundane: when an SMSC (Short Message Service Center) needs to deliver a text message, it first asks the recipient's Home Location Register (HLR) which Mobile Switching Center is currently serving that subscriber. The HLR replies with the subscriber's IMSI and the address of the serving MSC/VLR, so the SMSC knows where to forward the message.
The vulnerability is not a coding defect in any single HLR — it is that MAP has no concept of requester authentication. The HLR cannot distinguish a legitimate SMSC operated by a roaming partner from a rogue node run by a surveillance vendor, because MAP was standardized in an era when the only entities with SS7 interconnect access were a handful of state telecom monopolies. Any node that can route a TCAP dialogue to the target HLR's Global Title is treated as trusted.
┌─────────────────────────────────────────────────────────────────┐
│ ATTACKER NODE SS7 NETWORK TARGET OPERATOR │
│ │
│ [Rogue SMSC/GT] ──────▶ [IPX/GRX] ──────▶ [STP] ──▶ [HLR] │
│ ↑ │
│ Rented commercial GT No sender auth on IMSI + MSC-B │
│ (Global Title) the MAP layer leaks here │
└─────────────────────────────────────────────────────────────────┘
By 2014, the number of entities holding some form of SS7 interconnect access had grown from a handful of state carriers to thousands — MVNOs, SMS aggregators, IPX brokers, VoIP gateways, and commercial signaling resellers. GSMA now estimates over 1,200 such entities globally. Every one of them is, by protocol design, "trusted" enough to send an HLR a SRI-for-SM query.
II. Reconnaissance: Finding the Target's SS7 Footprint
Before sending a single MAP message, an attacker (or an authorized assessor) needs to resolve the target's operator and the Global Title of that operator's HLR. This information is substantially public.
| Data Source | What It Reveals |
|---|---|
| GSMA IREG Database | Operator TADIG codes, MCC/MNC assignments, STP/HLR GT prefixes |
| ITU-T E.214 Registry | Mobile numbering plan, GT address block allocations |
| SigPloit / P1 Security research | Published GT ranges for major carriers |
| Number portability (MNP) queries | Which operator currently serves a given MSISDN after a port |
| Public interconnect filings | Peering and bilateral roaming disclosures |
A practical reconnaissance sequence in an authorized assessment looks like this:
<CodeBlock language="text" filename="sri-sm-recon.txt" code="# Step 1 - Resolve PLMN from the MSISDN MSISDN +49-176-XXXXXXXX -> MCC 262 (Germany), MNC 07 (target operator)
Step 2 - Resolve HLR Global Title from GSMA TADIG / IREG data
Typical HLR GT block: 491760000000 (E.164-format prefix)
Step 3 - Confirm dialogue establishment (authorized lab only)
Send a TCAP Begin toward the HLR GT and confirm an SCCP-routable path exists before attempting any MAP operation."
None of this requires access to the target operator's network — it is entirely OSINT against public numbering and interconnect registries. The actual attack begins once a routable path to the HLR's Global Title is confirmed.
III. The Attack: SRI-for-SM Message Flow
The core exchange is a single TCAP dialogue carrying one MAP operation.
<CodeBlock
language="text"
filename="sri-for-sm-exchange.map"
code="SMSC (attacker GT) -> HLR: MAP SendRoutingInfoForSM (OpCode 45)
msisdn: +49-176-XXXXXXXX
sm-RP-PRI: true
serviceCentreAddress:
HLR -> SMSC: MAP SRI-for-SM response imsi: 262070123456789 -- permanent subscriber identity locationInfoWithLMSI: networkNode-Number: +491761000000 -- serving MSC/VLR Global Title lmsi: 0A1B2C3D -- local ID at that MSC"
The HLR is functioning exactly as specified: it believes it is helping a legitimate SMSC route a text message. In practice it has just disclosed the target's permanent identity (IMSI) and the address of the MSC currently serving them — which, on its own, already narrows the subscriber's location to an MSC service area (typically a city or metro region).
Escalating to Cell-Level Precision with ATI
The IMSI and serving-MSC address from the SRI-for-SM response are the prerequisite for a second, more precise query: AnyTimeInterrogation (ATI, OpCode 71), sent directly to the serving MSC.
<CodeBlock language="text" filename="ati-escalation.map" code="Attacker -> MSC-B GT (+491761000000): MAP ATI (OpCode 71) subscriberIdentity: imsi 262070123456789 requestedInfo: locationInformation, subscriberState, currentLocation
MSC -> Attacker: MAP ATI Ack locationInformation: cellGlobalId: { mcc: 262, mnc: 07, lac: 0x1A2B, ci: 0x3C4D } ageOfLocationInformation: 5 -- seconds since last update subscriberState: active"
Cross-referencing the returned Cell ID against a public cell-tower database such as OpenCelliD or Mozilla Location Services converts that Cell ID into physical coordinates, typically accurate to 50–500 meters in urban deployments.
Every later step in a full SS7 kill chain — SMS interception via UpdateLocation, or call redirection — depends on first having the IMSI and serving-node address this exchange discloses. SRI-for-SM is the reconnaissance step the rest of the chain cannot proceed without.
IV. Documented Real-World Impact
This is not a theoretical attack path. It has been publicly and repeatedly demonstrated against live subscribers.
The escalation path from a single SRI-for-SM query to full account compromise follows a consistent pattern:
┌─────────────────────────────────────────────────────────────────┐
│ IMPACT ESCALATION PATH │
│ │
│ SRI-for-SM → IMSI + serving-MSC GT (identity disclosure) │
│ ↓ │
│ ATI / PSI → Cell-ID + coordinates (real-time geolocation) │
│ ↓ │
│ UpdateLocation → serving-MSC hijack (SMS/call redirection) │
│ ↓ │
│ SMS interception → OTP capture → account takeover │
└─────────────────────────────────────────────────────────────────┘
| TTP ID | Name | Maps To |
|---|---|---|
| FGT5005 | Subscriber Location Tracking | SRI-for-SM + ATI |
| FGT5005.001 | Cell Identification Geolocation | ATI Cell-ID + public cell-database lookup |
| FGT5011 | Subscriber Data Collection | SRI-for-SM IMSI harvest |
Commercial surveillance platforms have industrialized exactly this chain. Citizen Lab's 2024 investigation into the Circles platform (linked to NSO Group) documented SS7-based tracking capability sold to at least 25 government clients worldwide — built on the same SRI-for-SM/ATI primitives described above, not a novel exploit.
V. Defensive Countermeasures
The GSMA FS.11 framework defines the control set that stops this specific attack class without disrupting legitimate SMS routing.
SMS Home Routing (GSMA IR.73): Deploy an SMS Home Router between the interconnect and the HLR. It intercepts every incoming SRI-for-SM request and answers with a synthetic routing number instead of the real IMSI — the HLR itself is never exposed to the requesting GT.
SCCP Global Title screening: Enforce a Global Title allowlist at the STP/Signaling Gateway. SRI-for-SM responses should only be released to GTs belonging to the operator's own SMSCs or verified bilateral roaming partners (per GSMA IR.21 TADIG records). Everything else is dropped before it reaches the HLR.
ATI/PSI blocking from external GTs: AnyTimeInterrogation and ProvideSubscriberInfo have no legitimate external use case. These operations should be dropped unconditionally from any GT outside the operator's own internal network.
| Rule | Action | Rationale |
|---|---|---|
| SRI-for-SM from unregistered GT | DROP | No legitimate reason for an unknown GT to query the HLR |
| ATI from any external GT | DROP | ATI has no valid external use case |
| PSI from non-bilateral GT | DROP | PSI discloses cell-level location |
| SRI-for-SM/ATI pair from same GT within 60s | ALERT | Classic geolocation pattern — flag for review |
Category 2 (detection-layer) controls add a signaling firewall correlating request velocity per source GT — multiple SRI-for-SM + ATI pairs targeting the same IMSI in a short window is a strong geolocation-attempt signature even when the individual messages pass GT screening.
Verification Checklist for Authorized Assessment
| Check | Pass Criteria |
|---|---|
| SRI-for-SM from non-bilateral GT | Dropped at STP; no HLR response reaches the requester |
| SRI-for-SM from an authorized SMSC GT | IMSI absent from the response (SMS Home Router active) |
| ATI from an external GT | Dropped; no MSC response |
| Bulk SRI-for-SM (10+ requests/minute, single IMSI) | Monitoring/firewall alert fires |
None of these controls require breaking backward compatibility with legitimate SMS delivery — they require the operator to actually enforce the GSMA rulesets that have existed since FS.11 was first published. The persistence of this attack class more than a decade after public disclosure is a deployment gap, not a standards gap.
VI. Frequently Asked Questions
SRI-for-SM is entirely legitimate — it is how SMSCs are supposed to locate a subscriber's serving MSC for SMS delivery. The attack is not in the message itself but in the absence of sender authentication: any Global Title, not just verified SMSCs, can send the same query and receive the same IMSI-disclosing response.
Historically, MAP was designed for a closed network of trusted state carriers, so returning the IMSI in a routing-info response carried no perceived risk. As SS7 interconnect access expanded to thousands of MVNOs, aggregators, and resellers, that design assumption stopped holding — but the message format itself was never revised, since doing so would break SMS interoperability across every operator that hasn't deployed SMS Home Routing.
SRI-for-SM returns region/MSC-level location and the subscriber's IMSI — it is the reconnaissance step. AnyTimeInterrogation (or ProvideSubscriberInfo) is the escalation step: sent to the serving MSC using the IMSI obtained from SRI-for-SM, it returns the actual serving Cell ID, which resolves to physical coordinates. You cannot run ATI/PSI meaningfully without first running SRI-for-SM (or an equivalent lookup) to obtain the IMSI and serving-node address.
Correctly deployed SMS Home Routing closes it — the SMS Home Router answers SRI-for-SM queries with a synthetic routing number and never discloses the real IMSI or serving-MSC address to the requesting GT, which removes the raw material the ATI escalation step depends on. The residual risk is deployment: FS.11 Category 1 controls must be active on every interconnect the operator maintains, since a single unprotected peering point reintroduces the exposure for all of that operator's subscribers.
Yes, if the device or network falls back to 2G/3G/4G radio with SS7/Diameter core interworking, which remains common during international roaming and in regions with incomplete 5G Standalone deployment. A 5G Standalone core with no SS7 interworking gateway removes this specific attack surface entirely, but most current deployments retain legacy interworking for roaming compatibility. See the SS7 protocol overview for how this exposure carries forward through each network generation.
Conclusion
SRI-for-SM abuse endures not because it is technically sophisticated, but because it exploits a protocol assumption — implicit trust between signaling nodes — that most SS7 interconnects still have not fully corrected more than a decade after the O2-DE demonstration made the risk a matter of public record. The fix is not a redesign of MAP; it is consistent enforcement of controls that already exist: SMS Home Routing to stop IMSI disclosure at the source, and SCCP Global Title screening to stop unauthorized queries from ever reaching the HLR.
TelcoSec provides SS7 security assessments that validate exactly these controls — SMS Home Routing effectiveness, GT screening rule coverage, and signaling-firewall detection of the SRI-for-SM/ATI escalation pattern — against your live interconnects.
