MODULE ID: DIAMETER-ULR-LOCATION-DISCLOSURE
CONFIDENTIAL LEVEL: HIGH

Diameter S6a ULR Subscriber Location Disclosure

SENTRY:TelcoSec Research
TIMESTAMP:
ANALYSIS TIME16 MIN

When 4G/LTE networks replaced SS7 with Diameter, the marketing pitch was simple: TLS, peer authentication, and a modern AAA framework would close the interconnect trust gap that made SS7 location tracking possible. In practice, the S6a interface between the Mobility Management Entity (MME) and the Home Subscriber Server (HSS) inherited the same structural weakness — implicit trust in whoever shows up on the interconnect claiming to be a roaming partner. The result is an attack that looks almost identical to SS7's SendRoutingInfo abuse, except it returns more data: a full subscription profile, QoS entitlements, lawful-intercept gateway addresses, and the exact MME currently serving the subscriber.

This research dissects the Diameter S6a Update-Location-Request (ULR) attack — how the interconnect is enumerated, how the message is forged, exactly what the Update-Location-Answer (ULA) discloses, and the GSMA FS.19 controls that close the gap.

This research traces the full kill chain of a Diameter S6a ULR attack against an LTE/EPC HSS: DNS-based Diameter realm enumeration, Capabilities-Exchange forgery, ULR construction with a spoofed Origin-Host, and the subscriber data returned in the ULA response. We map the technique to documented industry testing results and detail the GSMA FS.19 controls — mutual TLS, MME whitelisting, and Diameter Edge Agent inspection — that operators use to close the gap.

I. The S6a Trust Model

The S6a interface carries authentication vector retrieval and location management traffic between the MME (in the visited or serving network) and the HSS (in the subscriber's home network). RFC 6733 specifies that Diameter peers authenticate each other via TLS during the Capabilities-Exchange-Request/Answer (CER/CEA) handshake — in theory, no HSS should accept signaling from an MME it hasn't cryptographically verified.

In deployed roaming architectures, that verification frequently happens one hop too late. Traffic between operators crosses the IPX/GRX interconnect through Diameter Routing Agents (DRAs) and Diameter Edge Agents (DEAs), and the HSS itself typically only validates the Destination-Realm on inbound messages — not the actual identity of the originating MME.

┌─────────────────────────────────────────────────────────────────────┐
│                      LTE ROAMING ARCHITECTURE                       │
│                                                                      │
│  HOME PLMN                 IPX PROVIDER            VISITED PLMN     │
│                                                                      │
│  [HSS] ──S6a── [DRA] ──── [DEA/IPX] ──── [DRA] ──S6a── [MME]      │
│                                                                      │
│  HSS trusts        IPX = trusted        MME authenticates           │
│  DRA peer          intermediary         via DRA only                 │
│                                                                      │
│  ATTACK SURFACE: compromise or spoof ANY node in this chain         │
│  to forge valid Diameter S6a messages to the HSS                    │
└─────────────────────────────────────────────────────────────────────┘
Most HSS deployments enforce policy at the level of the Destination-Realm AVP — "does this message claim to be addressed to us?" — rather than validating that the Origin-Host presenting the ULR is an MME the operator actually has a roaming relationship with. That distinction is the entire attack surface documented in this case study.

II. Diameter Realm Enumeration

Unlike SS7's opaque Global Title space, Diameter infrastructure is partially discoverable through standard DNS. 3GPP TS 23.003 §19.3 mandates a predictable FQDN structure derived directly from an operator's MCC/MNC:

# IMSI prefix 26207 → MCC 262, MNC 07 → target operator's EPC realm
epc.mnc007.mcc262.3gppnetwork.org

From there, standard SRV lookups reveal the Diameter routing endpoint handling roaming S6a traffic:

<CodeBlock language="bash" is-terminal code="# Query for Diameter over SCTP (primary transport per 3GPP) dig SRV _diameter._sctp.epc.mnc007.mcc262.3gppnetwork.org

Query for Diameter over TCP (fallback transport)

dig SRV _diameter._tcp.epc.mnc007.mcc262.3gppnetwork.org

Response:

_diameter._sctp.epc.mnc007.mcc262.3gppnetwork.org.

300 IN SRV 10 50 3868 dra01.epc.mnc007.mcc262.3gppnetwork.org.

dra01.epc.mnc007.mcc262.3gppnetwork.org.

300 IN A 213.X.X.X # DRA/DEA public roaming endpoint"

/>

With the DRA endpoint known, an attacker completes a Capabilities-Exchange-Request to confirm S6a application support before attempting to forge signaling:

CER → dra01.epc.mnc007.mcc262.3gppnetwork.org:3868
  Origin-Host: attacker.msisdn-research.example
  Vendor-Specific-Application-Id:
    Vendor-Id: 10415 (3GPP)
    Auth-Application-Id: 16777251   ;; S6a application

CEA (response):
  Result-Code: DIAMETER_SUCCESS
  Auth-Application-Id: 16777251     ;; S6a confirmed supported
  Product-Name: Nokia DRA 5.0
Because Diameter realm FQDNs are derivable directly from MCC/MNC pairs — public, standardized identifiers — an attacker never needs insider knowledge of an operator's network to find their signaling entry point. This is a meaningful difference from SS7 recon, where Global Title ranges must be inferred or purchased from gray-market signaling brokers. The Diameter realm structure removes that first barrier entirely.

III. Forging the Update-Location-Request

With a live DRA endpoint and confirmed S6a support, the attack proceeds by establishing a peer session using a spoofed but plausible-looking Origin-Realm — typically one matching a real roaming partner's FQDN pattern:

cer = {
    'Origin-Host': 'mmec01.mnc009.mcc234.3gppnetwork.org',  ;; spoofed roaming MME
    'Origin-Realm': 'epc.mnc009.mcc234.3gppnetwork.org',
    'Vendor-Id': 10415,
    'Auth-Application-Id': 16777251,  ;; S6a
}

If the DRA does not bind the TLS client certificate to a specific, pre-authorized MME FQDN, this CER is accepted and the attacker is now a trusted peer for S6a traffic. The Update-Location-Request (Command-Code 316) is then constructed with the target IMSI:

If the HSS has no MME whitelist enforcement, it responds with a full Update-Location-Answer — and that response is where the real damage is.

IV. What the ULA Response Discloses

The ULA carries the subscriber's Subscription-Data AVP grouping, which is considerably richer than anything an SS7 SendRoutingInfo response returns:

ULA ← HSS
  Result-Code: DIAMETER_SUCCESS
  Subscription-Data:
    MSISDN: +49176XXXXXXXX             ;; phone number
    APN-Configuration-Profile:
      APN: internet                    ;; data APN
      APN: ims                         ;; VoLTE APN
      QoS-Subscribed: [...]            ;; bandwidth / priority class
    LCS-Info:
      GMLC-Number: +49...               ;; LCS gateway address
      LCS-PrivacyExceptionList: [...]
    Serving-Node:
      MME-Name: mmec01-DE-MNC07        ;; current serving MME FQDN
      MME-Realm: epc.mnc007.mcc262.3gppnetwork.org
      MME-Number: +4917600001

The Serving-Node AVP is functionally the LTE equivalent of the SS7 MSC/VLR address returned by SendRoutingInfo — each MME typically serves a defined Tracking Area Identity (TAI) list, which maps to a specific geographic footprint. An attacker who repeats ULR queries against the same IMSI over time can build a movement profile the same way SS7 operators do with repeated SRI/PSI queries, just against a Diameter-based target.

Beyond location, a successful ULR exposes:

  • APN configuration — reveals whether the subscriber has a corporate APN, IMS/VoLTE provisioning, or premium data tier
  • QoS-Subscribed profile — bandwidth and priority class, useful for identifying high-value or enterprise targets
  • LCS-Info / GMLC-Number — the Gateway Mobile Location Center address, which can enable follow-on OMA SUPL location-request abuse
  • Regional-Subscription-Zone-Code — reveals roaming restrictions and home-region assignment

V. Real-World Impact

Positive Technologies' 2019 assessment of 28 operators found that **71% (20 of 28)** were vulnerable to ULR-based subscription profile disclosure, and **71%** were also vulnerable to MME-level location tracking via the same message. **54%** permitted forced subscriber deregistration via Cancel-Location-Request (CLR), and **32%** allowed subscription data injection via Insert-Subscriber-Data-Request. The report's stated root cause: most operators deployed Diameter with peer TLS optional, or with self-signed certificates that were never validated against a trusted PKI — leaving DRA routing decisions based solely on Destination-Realm matching, with no Origin-Host binding to an authorized MME whitelist.

Attack Impact Summary

FindingOperators Affected (2019 study)Consequence
ULR subscriber data disclosure71% (20/28)Full subscription profile exposed
MME-level location tracking71% (20/28)Geographic movement profiling
CLR forced deregistration54% (15/28)Subscriber service disconnection
ISD data injection32% (9/28)Unauthorized subscription modification

MITRE FiGHT Mapping

TTP IDNameMaps To
FGT5034Diameter Location TrackingULR + Serving-Node AVP disclosure
FGT5034.001Update-Location-Request AbuseDirect forged S6a ULR
FGT5037Forced Subscriber DeregistrationFollow-on S6a CLR abuse

VI. Mitigation

Closing the S6a ULR gap requires layered enforcement — no single control is sufficient on its own: - **Mutual TLS on every S6a peer connection.** The DRA must validate the client certificate's CN/SAN against a maintained list of authorized MME FQDNs, not simply accept any presented certificate as proof of identity. - **HSS-side MME whitelist.** The HSS must reject any ULR whose Origin-Host is not on an explicit list of authorized MME identities, returning `DIAMETER_UNKNOWN_PEER (5018)` rather than processing the request. - **Diameter Edge Agent (DEA) inspection at the IPX boundary.** The DEA should drop ULR traffic from Origin-Realm values that don't match an active GSMA IREG bilateral roaming agreement, and rate-limit ULR volume per Origin-Host. - **Serving-Node suppression where feasible.** Operators handling high-risk subscriber categories can configure the HSS to omit the Serving-Node AVP from ULA responses to reduce location-tracking exposure, even when the ULR itself is accepted as legitimate roaming traffic.
# Open5GS HSS configuration example - MME whitelist enforcement
hss:
  s6a:
    mme_whitelist:
      - mmec01.mnc007.mcc262.3gppnetwork.org
      - mmec02.mnc007.mcc262.3gppnetwork.org
    reject_unknown_mme: true
DEA RuleActionGSMA Reference
ULR from non-whitelisted Origin-RealmDROPFS.19 §5.4.1
CER from unrecognized peer certificateREJECTFS.19 §5.2.1
CLR from non-HSS Origin-HostDROPFS.19 §5.5.1
ULR rate exceeds 10/min per Origin-HostALERTFS.19 §6.2

Verification Checklist (Authorized Lab Assessment)

# Test 1: ULR from an unregistered peer
# Expected: DIAMETER_UNKNOWN_PEER (5018) or connection refused at DRA

# Test 2: ULR from a known peer without a valid TLS certificate
# Expected: TLS handshake failure — no Diameter session established

# Test 3: ULR from an authorized MME
# Expected: DIAMETER_SUCCESS, with Serving-Node present only if policy allows it

# Test 4: CLR from a non-HSS source
# Expected: dropped at the DEA, no response delivered

This same architectural pattern — trusting the interconnect rather than the individual peer — underlies the broader Diameter attack surface beyond S6a, including S9 policy injection and Gy/Ro charging fraud. Operators auditing one interface should treat the assessment as a template for the others.

VII. Frequently Asked Questions

They target the same outcome — subscriber location and profile disclosure — through structurally similar trust gaps, but the ULR attack against the HSS returns considerably more data than an SS7 SendRoutingInfo response: full APN configuration, QoS entitlements, LCS gateway addresses, and regional subscription data, in addition to the serving-node location equivalent.

3GPP TS 23.003 mandates a standardized FQDN format for Diameter realms derived directly from an operator's MCC/MNC, resolvable through public DNS SRV records. SS7's Global Title space has no equivalent standardized public discovery mechanism, so enumeration typically requires inferred ranges or gray-market signaling access.

No. TLS proves the connecting peer holds a valid certificate, but unless the DRA/HSS specifically binds that certificate to an authorized MME identity — and the HSS separately enforces an MME whitelist — a peer with any valid roaming-partner certificate can still forge ULR traffic for subscribers outside their actual serving relationship.

The LCS-Info GMLC-Number is arguably the highest-value field, since it can enable follow-on OMA SUPL location-request abuse beyond the one-time Serving-Node disclosure. The Serving-Node AVP itself is the most directly comparable to SS7-era location tracking, since it identifies the subscriber's current MME and, by extension, their approximate geographic area.

A structured telecom penetration test that includes DRA peer enumeration, CER/CEA capability probing, and forged ULR submission from an unauthorized Origin-Host is the standard approach. TelcoSec's dedicated lab environments provide an isolated Diameter/EPC test bed for this assessment without touching production signaling.


Conclusion & Next Steps

The S6a ULR attack demonstrates that migrating from SS7 to Diameter did not, by itself, close the interconnect trust gap — it just moved the same problem to a richer protocol with a bigger data payload. Whichever signaling generation an operator runs, the underlying failure mode is identical: accepting a peer's claimed identity without binding it to cryptographic proof and an explicit authorization list.

The defense roadmap is straightforward to state and harder to enforce consistently:

  1. Immediate: Enforce mutual TLS with certificate-to-MME binding on every S6a peer connection.
  2. Short-term: Deploy an HSS-side MME whitelist rejecting any unregistered Origin-Host.
  3. Medium-term: Add Diameter Edge Agent inspection rules per GSMA FS.19, including ULR rate limiting.
  4. Ongoing: Validate the control stack through recurring telecom pentesting methodology engagements — a control that passed audit two years ago may have quietly regressed.

REPORT FEEDBACK PROTOCOL

Help refine threat intelligence feeds

Related Articles