TELCOBREAK
Workshop · DEF CON 34
Challenge 3 · Slice Enumeration · MITRE FiGHT FGT5019

CH3 — Slice Census

The NSSF reveals every virtual network carved out of the 5G core — including slices that were never meant to be visible.

FGT5019 · NSSF Slice Enumeration 150 pts Medium NSSF NRF Discovery Network Slicing
1

What Is Network Slicing?

One physical 5G core — many virtual networks

Network slicing is one of 5G's defining architectural features. A single physical 5G core can be partitioned into multiple independent virtual networks — each with its own QoS guarantees, security policies, and subscriber base. A slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information), which contains an SST (Slice/Service Type) value and an optional SD (Slice Differentiator).

The NSSF (Network Slice Selection Function) is the function that knows about all slices and decides which slice a subscriber or session should be placed into. Every available slice is registered as a profile in the NSSF — and that registration is visible through the NRF. A decoy NSSF profile advertising a RESTRICTED internal slice (S-NSSAI sst=3) has been planted in this lab. Its identity is the flag.

Standard 5G Slice Types — and the hidden one
SST=1 · eMBB
Consumer Broadband
Enhanced Mobile Broadband — high throughput for smartphones, tablets, home internet.
SST=2 · URLLC
Ultra-Low Latency
Ultra-Reliable Low Latency — autonomous vehicles, industrial control, remote surgery.
SST=3 · mMTC
Massive IoT
Massive Machine-Type Communications — sensor networks, smart meters, connected devices at scale.
SST=3 · RESTRICTED
Internal Slice
Private enterprise or government slice — never meant to be advertised externally. The flag is hidden here.
Planted Decoy
MITRE FiGHT FGT5019 — NSSF Slice Enumeration: This technique describes an adversary querying the NRF for NSSF instances and then walking the registered slice profiles to learn the operator's full slice topology. The prerequisite is SBI network access — provided here by your WireGuard tunnel. In a production network, this requires OAuth2 authorization. In this lab, there is none.

2

The Vulnerability

Unauthenticated NSSF enumeration via the NRF

In a production 5G deployment, only authorized Network Functions — identified by their OAuth2 client credentials and NF-type — may query the NRF for NSSF registrations or walk individual NSSF profiles. The NRF validates every request. In this lab, every query is accepted without any authorization check. An attacker with SBI network access can enumerate the full slice topology in two HTTP requests.

🔒

Production NSSF

3GPP TS 29.531 compliant
NRF query authOAuth2 token required
NSSF profile accessNF-type claim gated
TransportMutual TLS (mTLS)
Slice topology exposureInternal only
Internal slice leakNot possible externally
🔓

Your Lab (Open5GS)

Development mode — auth disabled
NRF query authNone — open to all
NSSF profile accessAny caller, no token
TransportPlain HTTP/2, no TLS
Slice topology exposureAll slices, all SDs
Internal slice leakComplete — fqdn revealed
This attack chains off CH1. You already know the NRF address (10.100.200.20:7777) from the service catalog challenge. Now you use that same NRF to filter by NSSF and walk the profiles, looking for a slice that should not be advertised to the public.

3

The Attack

Two curl commands — NRF filter then profile walk

This challenge builds on CH1 (NRF enumeration). You query the NRF with a filter for nf-type=NSSF to get the list of registered NSSF instances, then fetch each profile individually by UUID. The planted decoy NSSF profile has the flag in its fqdn field.

HTTP/2 is required: All 5G SBI endpoints run HTTP/2. Pass --http2-prior-knowledge to every curl command or you will receive no response. This is the most common mistake when querying 5G core APIs.
1

Query the NRF for NSSF instances

Use the ?nf-type=NSSF filter to get only NSSF profiles. The response is a JSON array of matching NF instances — note each nfInstanceId UUID. There may be more than one NSSF registered.

2

Walk each NSSF profile by UUID

Fetch the full profile for each NSSF instance using its UUID. The full profile includes more detail than the list response — including the fqdn field where the flag is embedded. Look for the profile where fqdn contains TWIN{}.

Step 1 — Query NRF for NSSF instancescurl --http2-prior-knowledge \ "http://10.100.200.20:7777/nnrf-nfm/v1/nf-instances?nf-type=NSSF" # Returns JSON array of NSSF profiles # Note each nfInstanceId UUID
Step 2 — Fetch individual NSSF profile by UUIDcurl --http2-prior-knowledge \ "http://10.100.200.20:7777/nnrf-nfm/v1/nf-instances/<UUID>" # Repeat for each UUID — look for "fqdn" containing TWIN{}
Example Profile Response — flag field highlighted
{ "nfInstanceId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "nfType": "NSSF", "nfStatus": "REGISTERED", "fqdn": "TWIN{xxxxxxxxxxxx}.nssf.5gc.mnc070.mcc999.3gppnetwork.org", <-- FLAG "sNssais": [{ "sst": 3 }], "ipv4Addresses": ["10.100.200.30"] }
Tip — filter and pretty-print with jq: Pipe the NRF response through | jq '.[] | select(.nfType=="NSSF")' to filter only NSSF entries and see them clearly. To pull just the fqdn from each result: | jq -r '.[].fqdn'

4

Real World Impact

What NSSF enumeration reveals in a real carrier network

In a production carrier 5G deployment, the NSSF knows about every slice — including those that operators would strongly prefer remain internal. An attacker who can enumerate the NSSF gains a detailed map of the operator's network architecture and customer commitments.

Slice topology is sensitive operational data. In a real carrier, the full list of S-NSSAIs, their associated FQDNs, and the NSSF configuration would be treated as internal-only. Exposing it via an unauthenticated NRF query is equivalent to publishing the operator's internal network architecture diagram.

5

Flag Format

Where to look and what to submit
CH3 Flag Format
TWIN{xxxxxxxxxxxx}
12 lowercase hexadecimal characters inside the braces.

The flag is embedded in the fqdn field of the planted NSSF profile returned by the NRF. The full fqdn string looks like a valid 3GPP FQDN: TWIN{xxxxxxxxxxxx}.nssf.5gc.mnc070.mcc999.3gppnetwork.org

Extract only the TWIN{xxxxxxxxxxxx} prefix and submit that as your flag. The planted NSSF profile advertises an S-NSSAI with sst=3 — look for this value to identify the decoy among the registered NSSF instances.
Submission tip: Submit the full TWIN{...} string including braces and the 12 hex characters. Do not include the .nssf.5gc.mnc070... suffix — that is just the FQDN wrapper used as camouflage.