Lab 10: 5G Threat Modeling Exercise

Module: 8 — 5G Core Network and Protocol Security
Points: 20
Time estimate: 90 min lab + 3 hr independent
Deliverable: lab-10-report.md

Objectives

1. Map three 5G attack classes to MITRE ATT&CK for Mobile using the Navigator.
2. For each attack, identify which NSM data type (Bejtlich four-types) could detect it.
3. Write detection logic (Zeek script or Suricata rule) for one of the three attacks in the Open5GS simulator environment.

Prerequisites

• Lab 9 completed; Open5GS + UERANSIM environment running
• MITRE ATT&CK Navigator accessible (https://mitre-attack.github.io/attack-navigator/)
• Zeek installed with standard scripts; or Suricata

Part A: ATT&CK for Mobile Mapping (45 min)

MITRE ATT&CK for Mobile (v15, 2024) covers adversary techniques against mobile devices and telecommunications infrastructure. The 5G attack classes from Week 8 map to specific techniques.

The three attack classes to map:

Task: Open the MITRE ATT&CK Navigator for Mobile. For each attack class A, B, and C:

1. Identify the most specific ATT&CK for Mobile technique that applies (technique ID + name).
2. Record the tactic that technique belongs to.
3. Note whether there is a listed mitigation for this technique.

Expected technique matches (verify yours):

• FBS → look in the "Network Effects" tactic area for techniques involving SIM/cellular interception
• SUPI timing → look in "Collection" for techniques involving subscriber identity enumeration
• SS7 residual → look in "Network Effects" for SS7-related techniques

Deliverable: A table with columns: Attack Class | ATT&CK Technique ID | Technique Name | Tactic | Listed Mitigation (Y/N).

Part B: NSM Data Type Mapping (30 min)

Bejtlich defines four NSM data types in The Practice of Network Security Monitoring Ch 1:

Task: For each of the three 5G attack classes, answer:

1. Which NSM data type(s) could detect this attack?
2. What specific artifact would appear in that data type? (e.g., "Session data: abnormally high number of short-duration SCTP connections to AMF port 38412 from UE IP block")
3. What NSM data type is NOT useful for detecting this attack, and why?

Reference: The Week 8 lecture, specifically the section on "5G Attack Classes" and the NSM sensor placement framing from Weeks 6-7.

Part C: Detection Logic Implementation (60 min)

Choose one of the three attack classes and implement detection logic in either Zeek or Suricata. The detection must be testable against the Open5GS lab environment.

Option 1: FBS Detection — NAS Registration Reject Rate (Suricata)

A fake base station that cannot complete 5G-AKA (because it lacks the subscriber's K) will trigger Registration Rejects from the AMF. A high rate of Registration Rejects from a single IP block in a short window is the detection signal.

Starting point from Lab 9's Part C Suricata rule -- extend it:

# Enhanced FBS indicator: Registration Reject burst with geographically anomalous source
alert tcp any any -> any 38412 (
    msg:"NET-301 FBS Indicator - NAS Registration Reject burst";
    content:"|44|";          # NAS Registration Reject type byte
    threshold: type both, track by_src, count 10, seconds 30;
    classtype:attempted-recon;
    metadata: technique_id T1449, attack_class FBS;
    sid:8000002; rev:1;
)

Modify this rule to also alert when the source IP is outside the expected UE IP range (your lab subnet). Test it against a crafted capture or a live Open5GS session.

Option 2: SS7 Residual — DIAMETER Anomaly (Zeek)

In a 5G NSA environment, DIAMETER protocol (the 4G authentication protocol) remains active between the MME/AMF and the HSS/UDM. An SS7 residual attack using DIAMETER would appear as unexpected MAP or DIAMETER messages in the S6a/S6d interface.

Write a Zeek script that logs all DIAMETER connections and flags any S6a Location Updating requests from IP addresses outside the expected MME/AMF range:

# lab10-diameter-monitor.zeek
# Monitor DIAMETER S6a Update Location Requests from unexpected sources

module NET301_5G;

export {
    redef enum Notice::Type += { Unexpected_DIAMETER_Source };
    const expected_mme_nets: set[subnet] = { 10.0.0.0/8 } &redef;
}

event diameter_request(c: connection, hdr: Diameter::Header, avps: Diameter::AVP_Data)
    {
    # Application-ID 16777251 = 3GPP S6a (MME-HSS interface)
    if ( hdr$app_id == 16777251 )
        {
        if ( c$id$orig_h !in expected_mme_nets )
            {
            NOTICE([$note=Unexpected_DIAMETER_Source,
                    $conn=c,
                    $msg=fmt("DIAMETER S6a request from unexpected source: %s",
                             c$id$orig_h),
                    $identifier=cat(c$id$orig_h)]);
            }
        }
    }

Option 3: SUPI Timing — Registration Timing Anomaly (Zeek)

SUPI de-anonymization via timing exploits correlation between SUCI transmission timing and network-observable events. A basic timing anomaly detector flags UEs that complete registration in statistically unusual time (too fast: possible pre-computed SUCI; too slow: possible relay attack adding latency).

Write a Zeek script that measures the elapsed time between Registration Request and Registration Complete for each NGAP UE session and logs sessions outside the 0.5-5.0 second normal range:

# lab10-registration-timing.zeek
# Flag 5G registration sequences with anomalous timing

module NET301_5G;

export {
    redef enum Notice::Type += { Registration_Timing_Anomaly };
    const reg_min_secs: double = 0.5 &redef;
    const reg_max_secs: double = 5.0 &redef;
}

global pending_registrations: table[string] of time;

# Track Registration Request start time (NGAP Initial UE Message)
event ngap_initial_ue_message(c: connection, ...)
    {
    local ue_id = cat(c$id);
    pending_registrations[ue_id] = network_time();
    }

# Measure elapsed time at Registration Complete
event ngap_uplink_nas_transport(c: connection, ...)
    {
    local ue_id = cat(c$id);
    if ( ue_id in pending_registrations )
        {
        local elapsed = network_time() - pending_registrations[ue_id];
        if ( elapsed < reg_min_secs || elapsed > reg_max_secs )
            NOTICE([$note=Registration_Timing_Anomaly,
                    $conn=c,
                    $msg=fmt("Registration timing anomaly: %.2f seconds (expected %.1f-%.1f)",
                             elapsed, reg_min_secs, reg_max_secs)]);
        delete pending_registrations[ue_id];
        }
    }

Lab Report

Create lab-10-report.md with:

1. ATT&CK Mapping Table (Part A): three rows, one per attack class, with all four columns filled in. For the FBS technique, quote the technique description from ATT&CK in one sentence.

2. NSM Data Type Analysis (Part B): for each attack class, one paragraph identifying: which NSM types are useful (with specific artifact description), which type is not useful, and the reasoning.

3. Detection Implementation (Part C):

   • Which attack class did you choose?
   • Paste the complete rule or Zeek script
   • Show the test output (fast.log excerpt, or Zeek notice.log excerpt, or an explanation of why no alerts fired during your test and what would need to change for them to fire)

4. Defense limitation question: The detection logic in Part C catches one specific manifestation of the attack class. Name one evasion that would prevent your rule from firing against the same attack, and describe what additional detection logic would be needed to cover the evasion.

Grading