Voice over LTE runs on an entirely different signaling core than the circuit-switched voice it replaced. Instead of a Mobile Switching Center answering a call setup request, an IP Multimedia Subsystem (IMS) resolves every incoming call and SMS-over-IP message against a single piece of state: which Contact URI is currently bound to the subscriber's public identity in the Serving-Call Session Control Function (S-CSCF). That binding is established once, at SIP REGISTER time, and it is supposed to be gated behind IMS-AKA — the same challenge-response cryptography that secures the radio access network. When an operator's IMS deployment weakens or skips that gate, the registration binding becomes something any attacker on the P-CSCF signaling path can claim for themselves.
This is not a theoretical footnote. USENIX Security researchers who tested VoLTE deployments across multiple countries in 2016 found that a meaningful fraction of operators accepted SIP REGISTER transactions without a valid AKA response at all. A 2020 CVE against a widely deployed IMS platform showed the same class of bug persisting under specific race conditions years later. The result in both cases is identical: every inbound VoLTE call and SMSoIP message for the targeted number is silently delivered to the attacker's SIP user agent, with the legitimate subscriber's phone showing no ring, no missed-call notification, and no indication that anything happened. Because IMS also carries the Cx interface back to the same HSS/HLR subscriber store that Diameter attacks target, a REGISTER hijack sits at the intersection of two attack surfaces this research series has already mapped — and it inherits the interconnect exposure problems documented for SS7 and Diameter roaming alike.
This research examines how the IMS SIP REGISTER transaction — the mechanism that binds a subscriber's public identity to a reachable SIP contact — is exploited when IMS-AKA authentication is weakened, bypassed, or downgraded to legacy Digest-MD5. We trace the P-CSCF/S-CSCF/HSS trust chain, the specific misconfigurations that let an attacker claim a victim's identity, the real-world research and CVE record behind this attack class, and the 3GPP TS 33.203 controls that close it.
I. IMS Architecture: The SIP Registration Trust Chain
IMS is the signaling core underneath VoLTE, VoNR (5G voice), and SMSoIP. Unlike the circuit-switched voice core it replaced, IMS routes everything through a chain of Call Session Control Functions, each with a distinct trust role:
| Node | Role | Security Relevance |
|---|---|---|
| P-CSCF | Proxy — first point of contact for the UE's SIP signaling | Entry point for all SIP transactions; TLS termination for the UE leg |
| I-CSCF | Interrogating — routes REGISTER to the correct S-CSCF via HSS query | Performs the Cx User-Authorization-Request to discover S-CSCF capability |
| S-CSCF | Serving — owns the registration binding and enforces authentication policy | The actual authority that accepts or rejects a REGISTER; issues the AKA challenge |
| HSS | Subscriber store — supplies authentication vectors over Cx | Same subscriber database targeted by Diameter S6a attacks |
The registration flow itself is a two-round SIP transaction:
The security-critical step is the last comparison: the S-CSCF must validate the RES the UE computed against the XRES the HSS supplied over Cx, using the same K/OPc key material that secures the radio-layer AKA exchange. If that step is skipped, weakened, or replaced with an unauthenticated shortcut, the "identity" in IMS reduces to whatever string an attacker types into a To: header.
II. IMS-AKA and the REGISTER Challenge-Response Gap
A correctly configured S-CSCF always answers a first-attempt REGISTER with 401 Unauthorized and an AKA challenge — never a bare 200 OK. The vulnerability class documented here exists because that "always" is a deployment choice, not a protocol guarantee that gets enforced automatically:
<CodeBlock language="text" is-terminal code="REGISTER sip:ims.mnc007.mcc262.3gppnetwork.org SIP/2.0 Via: SIP/2.0/TLS attacker.example.com:5061;branch=z9hG4bK-attacker001 From: tel:+49176XXXXXXXX;tag=attacker-tag-1 To: tel:+49176XXXXXXXX Call-ID: [email protected] CSeq: 1 REGISTER Contact: sip:[email protected]:5060 Expires: 3600
Expected (secure) response:
SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="ims.mnc007.mcc262.3gppnetwork.org", algorithm=AKAv1-MD5, nonce="<RAND+AUTN base64>", qop="auth"
Vulnerable response — no AKA challenge issued at all:
SIP/2.0 200 OK Contact: tel:+49176XXXXXXXX;expires=3600" />
Two distinct misconfigurations produce this gap, and both were documented in production networks:
- No-auth acceptance — the S-CSCF answers the very first REGISTER with
200 OK. The registration is complete on the first packet; the attacker's Contact URI is bound the instant the message is processed. - Digest-MD5 downgrade — the S-CSCF issues a challenge, but accepts legacy
algorithm=MD5Digest authentication instead of requiringAKAv1-MD5. Because MD5 Digest only validates a shared password rather than SIM-derived key material, and operators that enabled it for "legacy device compatibility" frequently left the associated password blank or default, the challenge becomes brute-forceable or trivially bypassable.
III. REGISTER Spoofing Mechanics: Claiming the Victim's Identity
With the authentication gap identified, hijacking the registration is a short sequence:
- Send the spoofed REGISTER. The attacker's SIP client sends a REGISTER for the victim's IMPU (a
tel:URI or SIP URI) with its own IP address in theContactheader. No prior relationship with the victim's device or SIM is required — the REGISTER only needs to reach the P-CSCF. - Exploit the specific misconfiguration. If the S-CSCF accepts the REGISTER outright, the hijack is already complete. If it issues a Digest-MD5 challenge instead of an AKA challenge, the attacker computes
MD5(username:realm:password)against a blank or well-known default password and resubmits. - Confirm the binding. A SIP
OPTIONSrequest to the target IMPU returns the currently bound Contact — now the attacker's address — confirming the hijack succeeded without generating any signal on the victim's device:
<CodeBlock language="text" is-terminal code="OPTIONS sip:[email protected] SIP/2.0 From: sip:[email protected] To: tel:+49176XXXXXXXX
SIP/2.0 200 OK Contact: sip:[email protected]:5060 # attacker's contact confirmed" />
- Intercept inbound traffic. Every subsequent
INVITEfor the victim's number now routes to the attacker's SIP user agent instead of the legitimate device, and every SMSoIPMESSAGE— including one-time-password delivery — is delivered the same way:
<CodeBlock language="text" code="Caller -> S-CSCF: INVITE tel:+49176XXXXXXXX -> S-CSCF binding lookup: Contact = sip:[email protected]:5060 -> INVITE forwarded to attacker UA; RTP media flows attacker <-> caller
SMS-SC -> S-CSCF: MESSAGE tel:+49176XXXXXXXX Body: "Your verification code is 847293" -> Delivered to attacker contact; OTP captured, account takeover proceeds" />
The registration persists until the Expires timer lapses or the legitimate UE happens to re-register — which, on a device that is powered on and camped normally, can be minutes to hours away, and which the S-CSCF's own registration-refresh timer will not shorten on its own.
IV. Impact: What a Hijacked IMPU Actually Exposes
| Consequence | Detail |
|---|---|
| Call interception | All inbound VoLTE (and VoNR, on 5G networks sharing the same IMS core) calls to the number route to the attacker |
| SMSoIP / OTP theft | SIP MESSAGE delivery — including SMS-based 2FA codes — is captured before it ever reaches the subscriber |
| Zero victim-side signal | The legitimate UE shows no ring, no missed-call badge, and no registration error; the attack is invisible without server-side monitoring |
| Emergency call exposure | If the P-CSCF is in scope, urn:service:sos emergency routing can be intercepted alongside normal traffic |
| Persistence window | Binding remains valid for the full Expires interval (commonly up to one hour) or until a competing re-registration overwrites it |
| Cross-generation reach | The vulnerability is IMS-layer, not RAN-layer — it affects 4G VoLTE and 5G VoNR subscribers on any core sharing the same S-CSCF |
MITRE FiGHT classifies this technique as FGT5062 — IMS Registration Hijack: a SIP REGISTER transaction completed with a spoofed IMPU due to insufficient authentication enforcement at the S-CSCF.
- Mandatory IMS-AKA, no fallback. The S-CSCF must issue a
401withalgorithm=AKAv1-MD5on every first-attempt REGISTER, disable Digest-MD5 as an acceptable authentication scheme entirely, and validate RES against the HSS-supplied XRES before returning200 OK. Emergency-only bypass (urn:service:sos) should be the sole exception, and it should be logged distinctly from normal registrations. - TLS on every P-CSCF-facing signaling leg. SIP over plaintext port 5060 should be disabled on external interfaces; SIPS on 5061 with a TLS 1.2+ certificate chain prevents on-path interception of both the REGISTER and the AKA challenge itself.
- Duplicate-binding detection. Alert whenever the same IMPU registers from two distinct Contact URIs within a short window (the 2016 USENIX study found zero operators doing this — the cheapest control in the list was also the one nobody had). Correlate against the UE's expected operator-assigned IP range to catch registrations originating outside normal subscriber address space.
None of these controls is exotic — they are what TS 33.203 already specifies. The exposure documented here exists purely where deployment lagged the standard.
V. Frequently Asked Questions
No. The attacker only needs network-layer reachability to the operator's P-CSCF and knowledge of the victim's IMPU (their phone number in tel: URI form). No SIM cloning, no physical proximity, and no interaction with the victim's device is required — the REGISTER transaction is sent entirely from the attacker's own infrastructure.
Under normal circumstances, they wouldn't. The UE's own registration state is unaffected — it continues to believe it is correctly registered, because the S-CSCF simply overwrote (or never validated) the binding on its side. There is no client-side indicator. Detection depends entirely on operator-side duplicate-binding monitoring, which the referenced 2016 study found was absent across every operator tested.
Related in outcome, different in mechanism. SIM swap fraud socially engineers the carrier into moving a number to an attacker-controlled physical SIM. SIP REGISTER hijacking never touches the SIM or the carrier's account records — it exploits a signaling-layer authentication gap to redirect SIP traffic while the subscriber's SIM and account remain completely untouched. Both defeat SMS-based two-factor authentication through different attack surfaces.
No — it only raises the cost of Scenario B. The specification-correct control is disabling Digest-MD5 as an acceptable REGISTER authentication scheme entirely, because it validates a shared secret rather than SIM-derived AKA key material and was never intended as a long-term production authentication path. Any Digest-MD5 acceptance path, however well-configured, remains weaker than the mandatory IMS-AKA challenge it was meant to temporarily substitute for.
Not on its own. VoNR uses the same IMS core and the same SIP REGISTER / IMS-AKA flow as 4G VoLTE — the vulnerability is in the IMS signaling layer, not the underlying radio access network. A 5G SA subscriber is exposed identically to a 4G subscriber if the shared S-CSCF has the same authentication misconfiguration. Full remediation requires IMS-AKA enforcement at the core regardless of which RAN generation is serving the call.
VI. Authoritative References
- 01 3GPP TS 33.203Access Security for IP-Based Services (IMS Security Architecture)3GPP TS 33.203 – IMS Access Security →
- 02 3GPP TS 24.229IP Multimedia Call Control Protocol Based on SIP and SDP3GPP TS 24.229 – IMS SIP/SDP Call Control →
- 03 GSMA FS.37Signaling Surveillance and Fraud Monitoring GuidelinesGSMA Security Resources & Guidelines →
- 04 USENIX Security 2016Weaponizing Femtocells: The Effect of Rogue Devices on Mobile TelecommunicationsUSENIX Security Publications →
- 05 CVE-2020-3161IMS P-CSCF Authentication Bypass AdvisoryNIST National Vulnerability Database →
Conclusion & Next Steps
IMS was built to give VoLTE the same cryptographic guarantee that GSM/UMTS gave voice calls — that only the holder of the correct SIM key material can claim a subscriber's identity. That guarantee only holds if IMS-AKA is mandatory in practice, not just in specification. Where operators left Digest-MD5 fallback active, or accepted REGISTER transactions without any AKA challenge, the SIP registration binding becomes exactly as trustworthy as the string in a To: header — and every inbound call and OTP-carrying SMS follows it wherever the attacker points it.
The fix is not a new protocol. It is enforcement of the one that already exists: mandatory IMS-AKA with no authentication downgrade path, TLS on every P-CSCF-facing leg, and duplicate-binding alerting that the 2016 field data shows almost no operator had deployed. Because the same HSS that supplies IMS authentication vectors over Cx also backs the Diameter S6a interface this research series has documented separately, a comprehensive assessment of one signaling core should never stop at the boundary of a single protocol.
