IMSI, MSISDN, and the Protocols That Connect Them
Understand the two key identifiers used in mobile networks, why both exist, and how legacy protocols let anyone with network access resolve one from the other.
- Explain the difference between a MSISDN (phone number) and an IMSI (network identity)
- Describe the role of the HLR/HSS as the mapping database between the two
- Name the SS7 and Diameter commands used to look up an IMSI from a phone number
- Trace the step-by-step flow a requesting node uses to resolve an IMSI from a phone number
- Apply these concepts in the hands-on challenge
Key terms appear highlighted like this throughout — click any to see its definition.
The Phone Number You Know: MSISDN
A MSISDN (Mobile Station ISDN Number) is simply a subscriber's phone number — the string of digits you dial or share with someone. The name comes from ISDN, an older digital telephone standard, but in practice a MSISDN is what every carrier uses to route calls and SMS to a specific subscriber.
Every MSISDN is structured in three parts defined by the ITU-T E.164 standard. Click each segment to explore its role:
| Part | Name | Description | Example |
|---|---|---|---|
CC |
Country Code | Identifies the country (1–3 digits) | 1 (USA) |
NDC |
National Destination Code | Area code / network prefix | 555 |
SN |
Subscriber Number | Unique number within the NDC | 1234567 |
The full MSISDN is at most 15 digits. In international format it is prefixed with + — for example, +15551234567.
The Identity the Network Knows: IMSI
An IMSI (International Mobile Subscriber Identity) is the true internal identifier for a subscriber. It is a number of up to 15 digits (commonly 15) stored on the SIM card and not normally exposed to the subscriber or outside parties. Networks use temporary identifiers (TMSI/GUTI) for most signaling, but the phone still presents its IMSI when the network has no valid temporary identity for it — for example on first attach.
IMSI anatomy — click each segment to explore:
| Part | Name | Description | Example |
|---|---|---|---|
MCC |
Mobile Country Code | Identifies the country (3 digits) | 310 (USA) |
MNC |
Mobile Network Code | Identifies the operator (2–3 digits) | 260 (T-Mobile US) |
MSIN |
Mobile Subscription ID Number | Fills out the IMSI to at most 15 digits — up to 9 digits when the MNC is 3 digits (as here), up to 10 when the MNC is 2 | 123456789 |
Where it lives: The IMSI is stored in the SIM card's secure element and in the carrier's subscriber database. It does not change when you get a new phone, but it does change when you get a new SIM.
MSISDN vs. IMSI — Why Both Exist
| MSISDN | IMSI | |
|---|---|---|
| Visible to | Everyone | Carrier's internal systems |
| Can change? | Yes — number porting, reassignment | Only with a new SIM |
| Purpose | External addressing (calls, SMS) | Internal network identity and authentication |
| Stored on | Carrier databases, contact lists | SIM card + carrier HLR/HSS |
A subscriber can change their phone number (MSISDN) without getting a new SIM, and can get a new SIM (new IMSI) while keeping the same number. The carrier's subscriber database bridges the two.
The Mapping Database: HLR and HSS
The database responsible for mapping MSISDN → IMSI (and tracking where a subscriber currently is) is called the:
- HLR (Home Location Register) — used in 2G (GSM) and 3G (UMTS) networks
- HSS (Home Subscriber Server) — the 4G/LTE (and IMS) subscriber database; same role as the HLR but reached over Diameter instead of SS7. A native 5G core uses the UDM/UDR/AUSF functions instead, though the HSS lives on in EPC, IMS, and 5G non-standalone/interworking deployments
When a call or SMS arrives for +15551234567, the network queries the HLR to find:
- Which IMSI owns that number
- Which serving node the subscriber is currently attached to — the network equipment closest to where the phone is right now. The node type depends on the network generation:
| Node | Full Name | Generation | Role |
|---|---|---|---|
MSC |
Mobile Switching Center | 2G / 3G | Routes voice calls |
VLR |
Visitor Location Register | 2G / 3G | Temporary subscriber cache co-located with the MSC |
SGSN |
Serving GPRS Support Node | 2G / 3G | Handles packet (internet) data — the data-plane counterpart to the MSC |
MME |
Mobility Management Entity | 4G / LTE | Replaces the MSC and VLR; manages registration, authentication, and handoffs between towers |
The SS7 Protocol Commands That Bridge the Gap
SS7 (Signaling System No. 7) is the protocol suite that has run the world's telephone networks since the 1970s. It handles call setup, teardown, SMS routing, and subscriber database lookups. Despite being decades old, SS7 still underpins most carrier infrastructure worldwide and interconnects 2G, 3G, and 4G networks at the roaming layer.
SS7 uses a sub-protocol called MAP (Mobile Application Part) for interactions between mobile network nodes. Two MAP operations are particularly relevant here.
MAP SendRoutingInfo (MAP-SRI)
Originally designed to route incoming calls to a subscriber, MAP-SRI asks the HLR: "I want to route a call to this phone number — where is the subscriber and what is their IMSI?"
The HLR responds with:
- The subscriber's IMSI
- Routing information for the call — a roaming number (MSRN) that points at the subscriber's current MSC
MAP SendRoutingInfoForSM (MAP-SRI-SM)
Similar to MAP-SRI but designed for SMS routing. It asks the HLR where to deliver an SMS for a given phone number. The response again includes the IMSI and the current serving node.
Summary of Relevant Commands
| Command | Protocol | Original Purpose | Data Returned |
|---|---|---|---|
SendRoutingInfo |
SS7 MAP | Route incoming voice calls | IMSI + roaming number (MSRN) |
SendRoutingInfoForSM |
SS7 MAP | Route incoming SMS | IMSI + serving MSC (2G/3G voice node) or SGSN (3G data node) address |
AnyTimeInterrogation |
SS7 MAP | Query subscriber info for value-added services | IMSI + location cell ID |
User-Data-Request |
Diameter (Sh) | Retrieve subscriber data over Sh (Application Server ↔ HSS) | Selected profile data, which can include IMSI |
Send-Routing-Info-for-SM |
Diameter (S6c) | Route incoming SMS in LTE — the Diameter parallel to MAP SendRoutingInfoForSM | IMSI + serving node |
Diameter: The 4G Evolution
Diameter is the protocol that replaced SS7's MAP for 4G/LTE network signaling. Where SS7 uses a layered stack of protocols (MTP for raw transport → SCCP for routing → TCAP for transactions → MAP for mobile operations), Diameter is an IP-based protocol designed for telecom-grade reliability and scalability — think of it as a purpose-built messaging system where network nodes send structured request/response messages to each other over TCP or SCTP (Stream Control Transmission Protocol — a transport similar to TCP but designed for telecom signaling, with built-in multi-path support).
In 4G networks the HSS exposes its MSISDN → IMSI mapping through two Diameter interfaces:
- Sh interface — connects Application Servers (IMS, LCS) to the HSS. The application issues a User-Data-Request (UDR); the data set returned depends on what it asks for, but it can include the underlying IMSI for a subscriber it knows only by phone number.
- S6a interface — connects the MME (the 4G node that manages which cell a phone is attached to) to the HSS. Every time a phone turns on or moves to a new area, the MME asks the HSS over S6a to authenticate the subscriber and download their profile — a process that also exchanges the IMSI.
There is no single "MSISDN in, IMSI out" routing command on Sh the way MAP-SRI works in SS7. Instead, an Application Server issues a User-Data-Request (UDR) over Sh to pull subscriber data — which can include the IMSI. The closest direct parallel to MAP-SRI-SM is Send-Routing-Info-for-SM on the separate S6c interface, used for LTE SMS delivery.
The Full Lookup Flow
Putting it all together, here is the end-to-end path from a known phone number to a retrieved IMSI. Press Play to trace the lookup flow step by step:
Because the IMSI is the internal handle for all subscriber operations, uncontrolled access to this lookup exposes several capabilities the protocol was never designed to guard against:
- Cell-ID disclosure — the IMSI can be used to query MAP-ATI (AnyTimeInterrogation) or Provide Subscriber Info against the serving MSC, returning the subscriber's serving cell tower ID
- SMS routing manipulation — a rogue node can register a fake MSC for that IMSI, redirecting incoming SMS
- Call signaling redirection — combined with IMSI-level roaming messages, call routing can be altered at the signaling layer
Hands-On Challenge
CTF Challenge
Try It Yourself
You have been given a phone number. Use what you've learned about how SS7 MAP lookups work to retrieve the corresponding IMSI from a simulated HLR environment.
Tools available
sigtran-shell— a command-line SS7 signaling tool pre-configured with the workshop's test SCTP endpoints
Success criteria
- You retrieve a valid 15-digit IMSI from the HLR response
- Submit the IMSI to the challenge portal to claim the flag
There's Another Way In: Over-the-Air IMSI Disclosure
The SS7 and Diameter lookups you just practiced work by querying the network's database. But there is a second path: asking the phone itself. When a handset connects to a cellular tower, part of the registration exchange involves the phone transmitting its IMSI directly over the radio link. The network uses this to look up the subscriber before setting up an encrypted session.
How a Phone Decides Which Tower to Use
Phones continuously scan for available base stations and select the one broadcasting the strongest signal with a matching network identifier (MCC+MNC). In 2G (GSM) the phone authenticates to the network but the network does not authenticate to the phone, so a rogue base station broadcasting a stronger signal than the legitimate tower simply wins the connection. 3G (UMTS) added mutual authentication, but downgrade-to-2G and pre-authentication identity requests keep the attack viable in practice.
Once the phone connects, the rogue station issues an Identity Request — an over-the-air message that asks the phone to send its IMSI in plaintext. The phone, following the standard, responds with its IMSI before any session key is exchanged.
| Generation | Phone auth to network? | Network auth to phone? | IMSI sent in cleartext? |
|---|---|---|---|
2G (GSM) |
Yes | No | Yes — on request |
3G (UMTS) |
Yes | Yes (mutual auth) | Yes — on initial attach |
4G (LTE) |
Yes | Yes (mutual auth) | Only if TMSI unknown |
5G (NR) |
Yes | Yes (mutual auth) | No — SUCI concealment |
The Rogue Base Station (IMSI Catcher)
An IMSI catcher — sometimes called a "Stingray" after a commercial product — is a device that impersonates a legitimate cell tower to collect IMSIs from nearby phones. The attack flow:
- 1 Broadcast a strong fake signal — the rogue BTS broadcasts on a legitimate MCC+MNC with higher power than nearby real towers. Phones in range connect automatically.
- 2 Issue an Identity Request — the rogue station sends a standard GSM/3GPP Identity Request message before establishing encryption, asking the phone for its IMSI.
- 3 Collect the IMSI response — the phone complies, sending its IMSI in plaintext. The attacker now has the IMSI without touching any carrier network.
- 4 Relay or drop the connection — the rogue BTS can silently relay the phone to a real tower (passive collection) or drop it, forcing a reconnect. More advanced attacks intercept and manipulate traffic in between.
Section 2 builds on this concept with a hands-on simulation. You'll see how a rogue base station harvests IMSIs from nearby devices — and how attackers layer that access to intercept one-time passwords sent over SMS.
Continue to Section 2 →