T-CVSS: INFO
SIGNALING ATTACKS
RF
AUTHOR ID:Ruben F. Silva

Research Analyst | PROTOCOL ANALYST

Telecom OSINT: A Reconnaissance Methodology for Carrier Infrastructure

AUTHOR:TelcoSec Research
UPDATED:
20 MIN READ
Reconnaissance map showing public data sources — PLMN registries, BGP tables, DNS records — converging into a reconstructed carrier signaling topology
SIGNALING ATTACKS

Every telecom security assessment — offensive or defensive — begins the same way: with an attacker who has never touched the target network learning everything it will let them learn for free. Long before a single SS7 message or Diameter request reaches a production node, an operator's PLMN assignments, interconnect partners, IP backbone, and even parts of its signaling topology are already sitting in public registries, DNS records, and BGP tables. This is OSINT — open-source intelligence — and in telecom it is unusually productive, because the industry's own standardization bodies publish the very data an adversary needs to build a target map.

This piece documents the reconnaissance methodology TelcoSec's research team uses to build that map: four sequential phases running from purely passive data collection through low-noise active queries, subscriber-level attribution, and finally full topology reconstruction. Every technique described here operates on public or semi-public sources — GSMA registries, ITU-T numbering plans, RIPE/ARIN/APNIC allocations, DNS, and certificate transparency logs. Nothing in Phase 1 or Phase 4 requires touching a live production node; Phase 2 and Phase 3 begin to cross that line, and we flag exactly where. This companion piece expands Phase 1 of the telecom penetration testing lifecycle into a standalone reference — the reconnaissance depth that phase actually requires before any RAN, signaling, or core assault work begins.

This report defines a four-phase OSINT methodology for telecom infrastructure reconnaissance: Passive Recon (PLMN/BGP/DNS enumeration from public registries), Active Probing (low-noise DNS and signaling-adjacent queries), Subscriber Mapping (IMSI/SUPI attribution and VLR correlation), and Topology Reconstruction (rebuilding STP mesh, Diameter routing, and IPX peering graphs from collected intelligence). Each phase is scoped by what it discloses, what source it draws on, and — critically — whether it remains passive or crosses into active querying of production infrastructure.

I. Phase One: Passive Reconnaissance

Passive reconnaissance enumerates operator infrastructure exclusively from public sources: PLMN databases, GSMA's roaming registry, BGP looking-glass servers, and DNS. No packet reaches the target operator's network. This phase alone typically discloses more about a carrier's core topology than most operators realize.

Unlike enterprise IT, where an attacker has to actively scan to learn anything, telecom standardization requires operators to publish interconnect data so roaming works at all. GSMA IR.21, ITU-T's E.212/E.164 registries, and 3GPP's standardized DNS naming scheme exist precisely so that thousands of other operators can find each other's infrastructure automatically. That same design goal makes the data equally usable by a researcher — or an adversary — outside the roaming community.

PLMN and Network Identity Intelligence

The starting point for any operator profile is resolving its Public Land Mobile Network (PLMN) identity — the MCC+MNC pair that anchors everything else. GSMA's IR.21 "Network Interworking and Roaming" extracts, portions of which circulate publicly through roaming-broker and research channels, list an operator's assigned PLMNs, declared roaming partners, HLR/STP Global Title prefixes, and SMSC addressing blocks. Cross-referencing an IMSI's leading digits against the ITU-T E.212 mobile country/network code registry resolves the Home PLMN (HPLMN) instantly, and the same MCC+MNC pair unlocks the operator's declared roaming partnerships — which, in turn, seeds the topology-reconstruction phase later.

BGP and IP Backbone Mapping

An operator's IP backbone is reconstructed entirely from routing registries. RIPE NCC, ARIN, and APNIC publish Autonomous System Number (ASN) allocations and prefix announcements; RADB and other Internet Routing Registries (IRRs) publish route objects; and RPKI validates which of those announcements are cryptographically authorized. Enumerating an operator's ASNs surfaces its core/edge IP ranges, its GRX/IPX transit relationships (visible as consistent upstream ASNs across an operator's announced prefixes), and — via peering-database entries — its physical interconnect points.

<CodeBlock language="bash" is-terminal code=" # Resolve an operator's ASN footprint and announced prefixes whois -h whois.radb.net -- '-i origin AS12345'

Cross-reference IP-to-network mapping via RIPEstat

curl -s 'https://stat.ripe.net/data/network-info/data.json?resource=203.0.113.10'

Validate whether an announced prefix has a matching RPKI ROA

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS12345&prefix=203.0.113.0/24'

Enumerate peering relationships declared in PeeringDB

curl -s 'https://www.peeringdb.com/api/net?asn=12345'"

DNS and Certificate Transparency Intelligence

3GPP standardized a predictable DNS naming scheme for operator infrastructure (TS 23.003 §19), which means most core-facing hostnames follow a fixed pattern: <service>.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org for public-facing 3GPP interfaces, or the .epc. / .5gc. equivalents for internal realms occasionally leaked through misconfigured public DNS. Combined with SIP SRV records for IMS Call Session Control Functions (P-CSCF, I-CSCF, S-CSCF), NRF DNS-SD entries for 5G, and ENUM (e164.arpa) delegation records, DNS alone frequently maps an operator's entire externally-reachable core footprint. Certificate transparency logs (crt.sh, censys) add coverage for management portals and API gateways that were never intended to be publicly indexed but were issued a publicly-logged TLS certificate anyway.

<CodeBlock language="bash" is-terminal code=" # 3GPP-standard public realm naming (TS 23.003 sec 19.2) - resolves IMS/EPC entry points dig SRV _sip._udp.ims.mnc001.mcc001.pub.3gppnetwork.org dig A epdg.epc.mnc001.mcc001.pub.3gppnetwork.org

Certificate transparency sweep for operator subdomains

curl -s 'https://crt.sh/?q=%.operator.example&output=json' | jq -r '..name_value' | sort -u

ENUM / e164.arpa delegation lookup for a number range

dig NAPTR $(echo '491761234567' | rev | sed 's/./&./g')e164.arpa"

RF Spectrum and Cell Infrastructure Intelligence

Public cell-tower databases (OpenCelliD, Mozilla Location Services) let a researcher enumerate an operator's eNodeB/gNB identifiers and map TAC/TAI areas to physical coverage zones without transmitting anything — the data is crowd-sourced from opted-in devices. Decoding an operator's active ARFCN/EARFCN/NR-GSCN values from a passive SDR capture and cross-referencing them against a national spectrum regulator's public license database (FCC ULS, Ofcom's spectrum register, and equivalents) additionally confirms exact band allocations and licensed bandwidth per operator, without the SDR ever transmitting a single symbol.

Passive SourceDisclosesAccess Requirement
GSMA IR.21 public extractsHLR/STP GT ranges, roaming partners, SMSC addressingCirculated publicly, no interconnect needed
ITU-T E.212 / E.164 registriesMCC/MNC assignment, numbering planFully public
RIPE NCC / ARIN / APNIC + RPKIASNs, IP allocations, GRX/IPX relationshipsFully public
DNS (SRV, A, NAPTR)IMS/EPC/5GC node hostnames, ENUM delegationFully public, passive query
Certificate TransparencyManagement portals, API gateways, internal hostnamesFully public log data
OpenCelliD / Mozilla Location ServiceseNodeB/gNB IDs, TAC/TAI coverage zonesPublic, crowd-sourced
National spectrum regulator registersLicensed bands, bandwidth, operator assignmentFully public

II. Phase Two: Active Probing

Active probing introduces low-noise queries that touch the target's infrastructure directly, but stop short of exploiting anything — DNS resolution against operator-owned name servers, SCTP association discovery, and protocol-compliant handshake probes. This is where reconnaissance begins to leave a trace, even though every technique here uses standard, RFC-compliant protocol behavior rather than malformed or exploit traffic.

Diameter Realm and DRA Discovery

3GPP's DNS naming convention makes Diameter realm discovery a straightforward SRV lookup: querying _diameter._sctp and _diameter._tcp records against an operator's public realm surfaces the Diameter Routing Agents (DRA) and Diameter Edge Agents (DEA) that front the S6a, Cx, Rx, and Gx interfaces. Fingerprinting the responding stack by its supported Application-IDs (visible in a Capabilities-Exchange-Answer) and mapping which SCTP endpoints actually accept associations narrows an operator's Diameter exposure to a specific set of nodes and vendor implementations — intelligence the Diameter protocol overview covers from the exploitation side once this discovery step is complete.

IMS/VoLTE Node Enumeration

SIP OPTIONS is a protocol-compliant "are you alive" probe with no authentication requirement by design — RFC 3261 explicitly permits unauthenticated OPTIONS pings for capability discovery, which makes it the standard low-noise technique for confirming a P-CSCF endpoint is live and fingerprinting its SIP stack from the response headers. Combined with DNS-derived Gx/Rx realm names, this identifies PCRF and P-GW/PCEF exposure, and — notably — the E.164 emergency-services routes (112/911) that every IMS deployment must expose at its network edge.

<CodeBlock language="bash" is-terminal code=" # Diameter realm discovery via SRV records (3GPP TS 23.003) dig SRV _diameter._sctp.mnc001.mcc001.pub.3gppnetwork.org

SCTP association discovery on Diameter / S1AP / NGAP ports

nmap -sY -p 3868,36412,38412

Protocol-compliant SIP OPTIONS ping against a P-CSCF (RFC 3261, unauthenticated by design)

sipsak -O -s sip:[email protected]

Unauthenticated 5G NRF service-discovery query (authorized testing only)

curl -s 'http://nrf.mnc001.mcc001.5gc.mnc001.mcc001.pub.3gppnetwork.org/nnrf-disc/v1/nf-instances?target-nf-type=AMF'"

5G Core Service Discovery

5G's Service-Based Architecture exposes its Network Repository Function (NRF) as an HTTP/2 REST API by design — every other Network Function registers with it and discovers its peers through it. Where an NRF's discovery endpoint (nnrf-disc) is reachable without authentication (a misconfiguration that recurs across early SA deployments), a single unauthenticated query harvests live AMF, SMF, UPF, and AUSF NF profiles, complete with their IP addresses and supported service versions — turning what should be an internal service mesh into an externally-readable core inventory.

NRF profile responses frequently include the `nfServices` block describing each NF's OAuth2 token-issuance endpoint for SBI authorization. Even when the actual API calls are properly authenticated, this metadata alone confirms which OAuth flow variant the deployment uses and whether client-credential grants are exposed on a routable interface — a detail that meaningfully narrows the next phase of an authorized 5G core assessment. Everything above still stays within RFC-compliant, unauthenticated protocol behavior — no credential is guessed, no malformed message is sent, and no subscriber data is requested. But it is no longer passive: packets are reaching the target's infrastructure. Treat Phase 2 as the boundary requiring at minimum a documented rules-of-engagement understanding with the target, even in a research context.

III. Phase Three: Subscriber Mapping

Subscriber mapping infers attachment and mobility state from indirect signaling indicators: MSC/VLR addressing patterns in MAP responses, TMSI structures observed in signaling captures, and IMSI/SUPI prefix attribution. This is the phase where reconnaissance stops being defensible as "public data collection" — resolving an individual subscriber's identity or location requires an actual signaling query against production HLR/UDM infrastructure, which is precisely the mechanism documented in the SRI-for-SM subscriber geolocation case study.

IMSI/SUPI Prefix Attribution

The passive half of this phase is entirely legitimate: ITU-T E.212 assignments map any IMSI's leading MCC+MNC digits to its Home PLMN operator, and E.164 MSISDN range allocations resolve a number block to its assigned carrier — both public numbering-plan lookups requiring no interconnect access. Decoding a 5G SUPI/SUCI format (protection scheme identifier, home network public key ID, and the encrypted or cleartext MSIN) similarly requires no live query; it is a format-parsing exercise against a value already in hand.

Attribution TechniqueData RequiredPassive or Active
IMSI → HPLMN (E.212)MCC+MNC prefixPassive — public registry lookup
MSISDN → carrier (E.164)Number range allocationPassive — public registry lookup
SUPI/SUCI format decodingCaptured or provided valuePassive — parsing only
MAP SRI subscriber resolutionLive TCAP dialogue to target HLRActive — production query
GT-based VLR correlationLive MAP response analysisActive — production query

Where the Line Actually Sits

SendRoutingInfoForSM and its relatives resolve a subscriber's IMSI and serving-MSC/VLR address — but only by sending a live MAP query to the target operator's HLR and receiving a response containing that subscriber's real identity. That is not OSINT by any reasonable definition; it is an unauthenticated signaling query against a production system that happens to succeed because MAP has no requester authentication. The SRI-for-SM case study walks through exactly what that exchange looks like and what GSMA FS.11 controls stop it. Any assessment methodology — including this one — that presents subscriber-level resolution as a routine "recon step" is describing an attack, not intelligence gathering, and should be scoped, authorized, and executed accordingly.

IV. Phase Four: Topology Reconstruction

The final phase synthesizes everything collected in Phases 1–3 into a coherent map of the operator's core topology: the Signaling Transfer Point (STP) mesh, Diameter routing hierarchy, and roaming interconnect graph. Done correctly, this phase remains almost entirely passive — it is data fusion, not new querying.

STP Mesh and Global Title Translation Patterns

An operator's STP topology can be substantially inferred from Global Title Translation (GTT) patterns visible in publicly-documented GT range assignments: which GT prefixes route through which STPs is a function of the operator's own numbering plan design, and published signaling-security research (SigPloit datasets, P1 Security and similar research corpora) has cataloged GT ranges for a large share of major carriers. Combined with the IR.21-derived HLR/STP prefixes from Phase 1, this reconstructs the logical routing mesh without a single signaling query being sent.

Diameter DRA Enumeration and IPX Peer Graphs

The DRA/DEA nodes discovered via DNS SRV records in Phase 2 map directly onto an operator's Diameter routing hierarchy; cross-referencing which realms each DRA serves reconstructs the internal routing topology. Roaming and IPX topology mapping closes the loop: identifying which IPX/GRX carriers (Syniverse, BICS, HGC, Tata Communications, and similar Tier-1 interconnect providers) an operator uses is visible through consistent upstream ASN relationships in the BGP data from Phase 1, and GSMA IR.34/IR.35 bilateral roaming agreement structures — where disclosed — confirm which STP interconnect points those relationships route through.

┌──────────────────────────────────────────────────────────────────┐
│                 OSINT → TOPOLOGY SYNTHESIS FUNNEL                │
│                                                                    │
│  IR.21 + E.212/E.164   →   PLMN identity, GT/SMSC ranges         │
│           ↓                                                       │
│  RIPE/ARIN/APNIC + RPKI →   ASNs, IP backbone, IPX relationships  │
│           ↓                                                       │
│  DNS + Cert Transparency →  IMS/Diameter/5GC node hostnames       │
│           ↓                                                       │
│  SigPloit/P1 GT datasets →  STP mesh + GTT routing inference      │
│           ↓                                                       │
│  MITRE FiGHT overlay     →  Attack-surface profile by TTP         │
└──────────────────────────────────────────────────────────────────┘

Attack Surface Profiling

The last step cross-references the reconstructed topology against the MITRE FiGHT (5G Hierarchy of Threats) catalogue and 3GPP TS 33.xxx security specifications, mapping which discovered nodes correspond to which documented TTPs. This produces the same kind of operator attack-surface profile that anchors the telecom penetration testing lifecycle's FiGHT tactic mapping — OSINT output becomes the scoping input for every subsequent assessment phase.

Phase 1 techniques — querying public registries, resolving DNS, reading BGP tables — carry essentially no legal exposure in any jurisdiction TelcoSec operates in; this is public data, collected the way it was designed to be collected. Phase 2 (active probing) and Phase 3 (subscriber mapping) are a different matter entirely. Transmitting SCTP association requests, SIP OPTIONS probes, or — especially — live MAP/Diameter queries against a production operator's infrastructure without written authorization can constitute unauthorized access to a computer system under the U.S. Computer Fraud and Abuse Act, the EU's Directive 2013/40/EU on attacks against information systems, the UK Computer Misuse Act, and equivalent statutes elsewhere — regardless of whether the query is "read-only" or uses only standard, non-malformed protocol messages. The fact that MAP and Diameter lack sender authentication makes the query technically possible; it does not make it lawful.

Before any Phase 2 or Phase 3 activity against a live network: obtain a signed engagement letter or rules-of-engagement document explicitly scoping which techniques and which target ranges are authorized, confirm whether local telecom regulators require separate notification for interconnect testing (several jurisdictions do), and default to performing SIP/Diameter/NRF probing and subscriber-resolution testing exclusively against sandboxed lab infrastructure or an explicitly-scoped production test environment rather than live subscriber-facing systems. TelcoSec's own private LTE/5G lab guide exists specifically so that Phase 2–3 techniques can be practiced without ever touching a real operator's network.

VI. Reducing Your Own OSINT Exposure

Sanitize IR.21 distribution: Redact HLR/STP Global Title ranges and SMSC addressing blocks from IR.21 extracts shared beyond the minimum roaming-partner set required for interconnect setup; full disclosure to every GSMA member is broader than most bilateral roaming relationships actually require.

Suppress SIP/Diameter banner verbosity: Configure P-CSCF and DRA/DEA nodes to omit vendor and version strings from SIP User-Agent/Server headers and Diameter Vendor-Id AVPs in responses to unauthenticated OPTIONS or Capabilities-Exchange requests — this alone removes most fingerprinting value from Phase 2 probing.

Restrict NRF discovery to authenticated SEPP peers: In 5G roaming deployments, ensure the NRF's nnrf-disc endpoint is reachable only through the Security Edge Protection Proxy (N32-c) with mutual TLS enforced, not directly routable from any external network path.

Maintain RPKI and IRR hygiene: Publish accurate ROAs for every announced prefix and keep route objects current in the relevant IRR — this closes route-hijack reconnaissance value without changing the fact that ASN/prefix data is inherently public.

Monitor your own certificate transparency logs: Alert on any newly-logged certificate for your domains; this catches both accidental internal-hostname exposure and unauthorized certificate issuance in the same monitoring pass.

None of these controls require an architecture redesign — they are data-hygiene and configuration changes that reduce how much of Phases 1–2 an outside party can complete, without breaking the interconnect and roaming functionality the underlying protocols exist to serve.

VII. Frequently Asked Questions

The techniques overlap — DNS enumeration, certificate transparency, BGP mapping — but telecom adds several sources that don't exist in enterprise IT: GSMA's roaming registries (IR.21), ITU-T's global numbering plan (E.212/E.164), and 3GPP's standardized DNS naming convention (TS 23.003), all of which exist because interconnect and roaming require operators to publish infrastructure data to each other. That standardization is what makes telecom OSINT unusually productive compared to a typical corporate footprint.

Largely, yes — Phases 1 and 4 (passive recon and topology reconstruction) are pure data fusion across public registries and require zero packets to the target. Phase 2 (active probing) does send RFC-compliant queries — DNS, SCTP handshakes, SIP OPTIONS — directly to the target's infrastructure, so a fully passive assessment stops at the end of Phase 1, augmented by whatever Phase 2 data other researchers have already published (e.g., cataloged GT ranges).

TS 23.003 defines a fixed pattern — <service>.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org for public-facing interfaces — specifically so that any operator's core-facing nodes (IMS, Diameter realms, 5G core NFs) can be discovered automatically by roaming partners without manual coordination. The predictability that makes automated roaming interoperability possible is the same predictability that makes the same nodes trivially enumerable by anyone who knows an operator's MCC/MNC.

The line sits between Phase 2 and Phase 3. Active probing (Phase 2) uses only unauthenticated, protocol-compliant behavior explicitly permitted by the relevant RFCs and 3GPP specs — a SIP OPTIONS ping or an NRF discovery query is not exploiting anything. Subscriber mapping (Phase 3) requires an actual MAP or Diameter query that returns a real subscriber's IMSI, SUPI, or location — at that point you are exercising a design flaw in an unauthenticated protocol against production infrastructure, which is a signaling attack, not intelligence gathering, and requires explicit authorization.

It changes the exposure surface, not the fact that one exists. SS7/E.212/IR.21-derived intelligence becomes less relevant if legacy interworking is fully retired, but 5G SA introduces its own OSINT surface — NRF discovery endpoints, SEPP N32 interconnect metadata, and SBI OAuth token-endpoint disclosure — that this methodology's Phase 2 techniques target directly. Most current deployments retain SS7/Diameter interworking for roaming compatibility, so in practice both surfaces coexist; see the Diameter protocol overview for how the legacy interworking gateway extends this exposure into 5G subscribers.


Conclusion

The uncomfortable truth about telecom OSINT is that most of an operator's core topology is discoverable before an assessor writes a single line of exploit code — because the same standardization that makes global roaming work (IR.21, E.212/E.164, 3GPP's DNS conventions, public BGP registries) also makes that infrastructure legible to anyone who knows where to look. The methodology here is not a novel discovery; it is the reconnaissance phase every serious telecom penetration test already runs, documented as its own discipline because it deserves the same rigor — and the same authorization boundaries — as the signaling and RAN attacks it feeds into.

TelcoSec runs full OSINT-to-topology reconstruction engagements as the scoping phase of every signaling and core security assessment — validating exactly how much of your network a motivated researcher, or adversary, can map without ever touching your production systems.

WAS THIS ARTICLE HELPFUL?

Help us improve our developer education

Related Articles