Skip to main content

Cyberattacks on 5G Telecom Networks: Threat Mapping and Defense

Cover image

Article Metadata

Ecosystem Fit​

This page mirrors the original Medium article into the 1200km.com Docusaurus ecosystem. The original article flow, images, screenshots, infographics, and technical blocks are preserved from the export.

This research provides an in-depth analysis of cyber threats targeting 5G telecom core networks, mapping real-world and theoretical attack techniques to the MITRE ATT&CK and FiGHT frameworks. It includes practical detection methods and mitigation strategies, tailored specifically for Ericsson systems and infrastructure.​

Article image

Introduction​

Telecommunications providers are prime targets for cyberattacks, from nation-state espionage to criminal fraud. Modern mobile networks (4G LTE EPC and 5G core) carry critical voice and data traffic, making any compromise potentially devastating. This report analyzes known and theoretical threats across the end-to-end connection flow — from user equipment (UE) through the Radio Access Network (RAN) and Core, out to the Internet. We map each threat to specific network functions and interfaces (e.g. S1-MME in 4G, N2/N3 in 5G, SGi/N6 towards the internet, etc.), and align adversary tactics with the MITRE ATT&CK® framework and the MITRE FiGHT™ 5G threat framework. Real-world examples (nation-state APT campaigns, criminal exploits, insider abuse) are included alongside theoretical attack models. For each stage, we discuss how adversaries execute attacks, how to detect them using logs (including Ericsson event logs) and monitoring tools (SIEM, NIDS, DPI), and how to prevent or mitigate these threats. The analysis is tailored to Ericsson’s infrastructure where applicable, highlighting relevant security features and best practices.

Research about 4G/LTE here

Threats in 5G Core (Service-Based Architecture) Connection Flow​

5G’s core network introduces a Service-Based Architecture (SBA) with new functions and interfaces. The key network functions include the Access and Mobility Management Function (AMF, analogous to 4G MME), Session Management Function (SMF, analogous to MME/SGW control-plane), User Plane Function (UPF, analogous to SGW/PGW user-plane), Unified Data Management (UDM, similar to HSS), Authentication Server Function (AUSF), Policy Control Function (PCF, akin to PCRF), and others like NEF, NRF, etc. Instead of many point-to-point interfaces, 5G uses service-based interfaces (HTTP/2 APIs within the core) and reference points (N1, N2, etc.) between access and core or core and UE. Major interfaces:N1(UE–AMF NAS signalling),N2(gNB–AMF control plane, replacing S1-MME),N3(gNB–UPF user plane, replacing S1-U),N4(SMF–UPF, replacing S11),N6(UPF–Data network, replacing SGi),N7(SMF–PCF, replacing Gx),N8(UDM–AMF, similar to HSS connection),N10(UDM–SMF),N11(AMF–SMF), etc., plus the service-based interfaces among core functions via an API bus (often secured with TLS and OAuth2). Many threats from LTE carry over, but 5G also has new attack surfaces due to virtualization, slicing, and the SBA’s reliance on web technologies.

Article image

> Note: We structure 5G threats by analogous stages (Access, Registration, Session, User-Plane, and new considerations like slicing). Many 4G threats remain relevant, but 5G has enhanced security (e.g. SUPI concealment, mutual authentication between NFs) that mitigate some attacks; meanwhile new services can introduce fresh vulnerabilities.

Stage 1: 5G Radio Access (UE to gNB, NG-RAN)​

Threats & Techniques:​

The 5G New Radio (NR) access inherits most wireless threats from LTE:RF jammingremains possible (no wireless tech is immune to sufficiently strong interference)nitrd.govpar.nsf.gov, causing denial of service.Rogue base station (fake gNB)attacks areharderin 5G because 5G UEs verify a gNB’s identity via broadcasted certificates and because the IMSI (now called SUPI) is transmitted in an encrypted form (SUCI). However, if the home network’s public key for IMSI encryption is not provisioned or if the attacker forces a fallback to LTE, they could still attempt an IMSI catch or downgrade attackfight.mitre.orgfight.mitre.org. Another RAN-specific threat in 5G isslicing-related DoS: if network slicing is used (with gNB scheduling resources per slice), an attacker could attempt to exhaust slice resources. For example, a malicious IoT device could join a network slice and consume excessive RAN bandwidth or signaling capacity (like sending continuous registration signaling in a slice meant for low-power devices, preventing legitimate traffic — a form ofResource Exhaustion). There is also the concept ofgNB compromise— 5G base stations are often software-driven and may even run on general-purpose hardware at cell sites. If an attacker exploits a vulnerability in the gNB (e.g., its OAM software), they could manipulate it to send invalid control messages or disable encryption (though user-plane encryption between UE and gNB is mandated, an attacker controlling gNB might attempt man-in-the-middle at the termination point of that encryption). Such an attacker could then sniff or alter traffic before it enters the core. This aligns with ATT&CK techniques ofSupply Chain Compromise(if malicious firmware is inserted into gNB) orEndpoint Compromise,leading to network effects.MITRE FiGHTaddresses many of these under tactics like Denial (e.g.,Radio jamming/spoofingas FGT5xxx series) and Access (rogue base stations, etc.). For instance, FiGHT has specific techniques forJam Radio ChannelandRogue Base Stationin the 5G context (all considered either theoretical or observed in testing).

Adversary Exploitation:​

Adversaries might deploy jamming equipment targeting 5G frequencies (which are higher, including mmWave, but still jam-able with the right gear). They might focus on synchronization signals or control channels to maximize disruption with minimal powerfight.mitre.org. For rogue gNB, an advanced attacker could set up a fake gNB that either exploits a misconfiguration (like lack of proper certificate checking on the UE, or using a real-but-stolen gNB certificate). If some UEs don’t correctly validate the network identity (or if they are in a scenario where they accept provisional connectivity before full authentication), a fake gNB could pretend to be a legitimate cell to at least induce a temporary denial (though getting user data might be infeasible due to 5G’s strong link security). A compromised gNB is more plausible via insider or supply chain — e.g., malware introduced in the gNB’s baseband unit could instruct it to send malicious messages upstream. For slice exhaustion, an attacker with a bunch of UEs (or SIMs) associated with a particular slice could orchestrate simultaneous high-load behavior (like continuous dummy traffic or repeated reattachments within that slice), consuming disproportionate resources. If the slice is not properly isolated, this could even bleed over to degrade overall cell performance (a “slice-aware DoS”).

Detection:​

5G gNBs and AMFs produce extensive logs and PM counters.Jammingcan be inferred from RAN metrics: e.g., sudden drop in RSRP/SINR (signal quality) across many UEs, many radio link failures, or handsets camped but failing to complete registration. Ericsson’s RAN nodes can raise alarms for RF interference. A SIEM integrating RAN OSS data could detect an anomaly like multiple base stations in an area all experiencing high interference simultaneously.Rogue gNBdetection might rely on UE reports — newer phones can report if a cell’s authentication failed or if it presented no credentials (there are 5G procedures for the UE to alert the network if it encountered a suspicious cell). Monitoring those UE-initiated reports can tip off operators. Also, theNRF (Network Repository Function)in 5G keeps track of authorized NFs (including gNBs via N2). If a rogue gNB tried to connect to an AMF, it should fail authentication (if proper 5G security is on, e.g., via secured NGAP). Logs might show repeated NGAP setup attempts from an unknown IP — essentially an unauthorized node trying to interface. NIDS on the N2 interface could flag unknown source IPs.Slice DoSwould reflect in slice-specific KPIs — e.g., one network slice ID showing unusual load or many connection attempts. Ericsson’s management systems for slicing (such as their orchestration and slice manager) should output alerts if slice SLA thresholds are breached. These can be fed to security monitoring. In the ATT&CK/FIGHT matrix, such detection would be categorized underAnomalous Activity: Denial of Servicedetection. Tools like DPI can’t do much at RF, but for slice-level analysis a tool that correlates control-plane messages per slice could identify something like “Slice X has 10x more NAS requests than normal”.

Prevention & Mitigation:​

Mitigating jamming is tough — besides traditional approaches (use highly directional antennas, frequency hopping, power control to overcome interference), 5G can use diverse spectrum (including fallback to LTE or other bands) to route around jammed frequencies. Ericsson’s adaptive beamforming in 5G can help because jamming a narrow beam is more difficult than an omnidirectional signal. Deployjamming detection systems— e.g., spectrum analyzers at cell sites — to quickly locate a jammer. Law enforcement action is often the ultimate solution. For rogue base stations, 5G’s built-in mutual authentication is key: ensure all UEs have the correct public keys for home network (to validate any network identity). Operators should also educate users and possibly provide apps that can alert if the phone connects to a suspicious cell (though 5G reduces this risk).Certificate managementin 5G is crucial: make sure gNBs and AMFs use the 5G security features (e.g., Security Edge Protection Proxy for interconnect, and access authentication for RAN nodes). If non-public networks or shared gNBs are used, usesecure roaming agreementsso that even gNB from another operator has to authenticate via standardized 5G procedures. To mitigate slice abuse, implementslice-specific admission control— if a slice is meant for IoT devices that send one packet a day, cap the rate of signaling or data per UE for that slice. Use network analytics (maybe AI/ML) to detect deviations in slice usage patterns and automatically throttle or isolate offending UEs. Ericsson’s slice management solutions could enforce resource quotas per slice so one slice can’t starve others (this is part of slice QoS management in 3GPP). If a slice is under attack, the operator could even temporarily shut it down or reallocate resources. Ensure slice isolation at all levels (RAN, core, transport) — use dedicated or QoS-guaranteed resources so that a flood in one slice doesn’t crash a shared component. Keep gNB software updated to patch any vulnerabilities that malware could exploit. Since gNBs may be deployed at cell sites or edge data centers, secure their OAM channels (e.g., via encrypted backhaul, jump-server access only). Zero-trust principles apply: treat gNB as potentially exposed devices — give them only least privilege access into core (the AMF should strictly validate all messages). These measures align with embracing theZero Trust Architecturefor telecom, as Ericsson advocates (micro-segmentation, continuous verification of network entities)technologymagazine.com.

Stage 2: Core Network Registration & Authentication (N1, N2, N8 interfaces)​

When a 5G UE powers on, it establishes an N1 NAS connection with the AMF via the gNB, and undergoes authentication (with AUSF/UDM). The AMF then registers the UE and sets up a context. This is analogous to the attach procedure in 4G, but in 5G the signaling is over Service-Based Interfaces and HTTP/2 for core internals.

Threats & Techniques:​

Many threats here mirror the 4G attach stage, albeit 5G has improved security: for instance, 5G-AKA mutual authentication and SUPI confidentiality mitigate IMSI catching and certain spoofing. However, possible threats includeRegistration Floods— a malicious IoT botnet could initiate frequent 5G registration/deregistration to swamp the AMF (just as in 4G’s attach flood). Researchers have noted that without proper controls, a surge of NAS registration requests can overload an AMF or the AUSF (auth server), constituting asignaling DoS. This aligns withATT&CK T1498 (Network DoS)again. Another threat isexploiting SBA protocols: the 5G core uses HTTP/2 and JSON messaging between NFs (for example, AMF communicates with AUSF/UDM over N8/N10 using RESTful APIs). An attacker who gains access to the SBA network (perhaps by compromising one NF or via a cloud vulnerability) could send forged API requests. For instance, if an attacker compromises the AMF (or steals its credentials/cert), they could call the UDM’s API to fetch or modify subscriber data (akin to how in 4G an attacker abused Diameter in HSS). This would beAPI manipulation— mapping to ATT&CKT1190 (Exploit Application Protocol)orInitial Access via Valid Accounts (if using legitimate NF credentials). MITRE FiGHT addresses this under techniques like**“Compromise Core Network Function”and“Abuse Service-Based Interface”(the FiGHT framework explicitly considers adversaries interacting with 5G’s HTTP-based services). For example, an attacker could performNetwork Function Registration Hijack**: trick the NRF (Network Resource Function, the registry of services) by registering a rogue service instance. If they succeed, other NFs might send traffic to the attacker’s service, enabling MITM or disruption. This is theoretical but possible if authentication of NF registration is weak. Also,trust in 5G: if the network uses default or poorly managed certificates for NF communication, an attacker might slip in a fake NF. Another threat at this stage isAuthentication bypass or downgrade: while 5G has robust AKA, a misconfigured network might allow fallbacks (e.g., accepting a weaker algorithm or even null authentication in test scenarios). An adversary might exploit that to gain network access without proper credentials (though no known wide-scale vuln exists, it’s a risk if operators leave test modes enabled). Insiders with knowledge of core signaling could abuse internal APIs to, say, mark a rogue device as “permanently registered” or disable certain security checks (this again maps to misuse of legitimate access).

Adversary Exploitation:​

A compromised device army (like Mirai-like botnet on 5G IoT devices) could coordinate sending waves of registration attempts. 5G’s design might handle scaling better via network slicing (e.g., IoT slice separate from eMBB slice), but if targeted at the same AMF, it can still cause overload. Historically, signaling storms have occurred unintentionally (e.g., buggy phones causing massive attach retries); attackers can weaponize this intentionally. For SBA, consider an example: an attacker gains a foothold in the 5G core by compromising a secondary function (say, an exposure function or a poorly secured NEF). From there, they pivot onto the service bus and attempt to impersonate an AMF by registering with NRF (if NRF didn’t enforce proper cert chain, etc.). They could then receive some messages intended for the real AMF or send false messages (like telling SMF that a UE deregistered when it didn’t, causing service drop). If an attacker exploited a vulnerability in the HTTP/2 stack of an NF (like a buffer overflow in the API parsing), they might crash that NF (DoS) or execute code (takeover). In 2022, researchers demonstrated some vulnerabilities in 5G core network function implementations, though none publicly catastrophic; it remains an area of concern. A nation-state actor could deploy malware inside the telco’s 5G core cloud — once they have that access, all bets are off, as they can then leverage internal API calls to manipulate registrations, perhaps stealthily track users or create ghost users. One could imagine an attacker abusing theUE Registration Acceptstage — if they intercept or guess the security tokens, they might attempt to produce a fake Registration Accept to a UE, though 5G encryption and integrity on NAS should prevent outsiders from doing so.

Detection:​

5G core NFs (AMF, SMF, etc.) are software-based and typically run on cloud infrastructure; they output logs (often to a centralized data lake or analytics system).Registration floodwould be evident in AMF logs: a spike inInitialUEMessageorRegistrationRequestevents. AMF might also log if it rejects many UEs (e.g., cause codes for overload). The Ericsson 5G Core’sExperience Managementor similar analytics could trigger an alarm for unusual registration failure rates. At the AUSF/UDM, excessive auth attempts (especially failures) is a red flag. Those can be monitored similarly to 4G (with 5G specific counters).API abuse detection: since SBA uses HTTP/2, one can deploy API gateways or use the NRF as a choke point. If an attacker tries to register a fake NF, the NRF should log an unrecognized certificate attempt. Security monitoring should ingest logs of authentication failures between NFs (like “AMF X presented invalid credentials to NRF” events). Tools can also monitor foranomalous API calls: e.g., an SMF requesting data for a subscriber it normally wouldn’t (maybe via UE ID mismatches). Because 5G core is cloud-native, solutions from IT (like API intrusion detection, WAFs for microservices) can be applied – these might detect unusual patterns or known bad payloads in NF communications. The FiGHT framework suggests monitoring for things like abnormal service discovery queries or NF overload signals as potential indicators. If an attacker has compromised an NF, one might seesystem log anomalieson that NF’s host (like a new process running in a container, or unusual syscalls if they broke out). So integrating cloud security posture and runtime monitoring (e.g., Kubernetes audit logs, container security alerts) into the telecom SIEM is crucial. Ericsson’s cloud core likely has an orchestrator – any changes to NF configuration (like a new NF instance coming online unexpectedly) should be treated as an event to verify.

Prevention & Mitigation:​

Zero-trust service mesh— treat every NF-to-NF communication in 5G core as potentially untrusted. Concretely, use mutual TLS with proper PKI for all service-based interfaces (the 3GPP standards mandate this, but operators must implement it with care: manage certificates, rotate keys, etc.)ericsson.comericsson.com. Ensure the NRF and SCP (Service Communication Proxy, if used) enforce authentication and authorization: only known NFs with valid certs can register or query services. Employ an API gateway or service mesh (like istio with policy rules) to police API calls (e.g., an AMF should only call certain services with valid parameters).Rate-limitat the API level too — if an AMF suddenly issues an excessive number of requests to UDM, throttle it (in case it’s compromised or malfunctioning). For registration floods, the 5G equivalent of overload control is essential: AMF can signal backpressure to gNBs. Configure the AMF’s overload settings to handle spikes gracefully. Possibly use network slicing to isolate IoT traffic — so even if there’s a flood on a massive IoT slice, it doesn’t impact the eMBB (smartphone) slice.Web security best practices: since 5G core uses web tech, apply protections like you would in an enterprise API environment: input validation (to thwart injection attacks on JSON), well-configured HTTP/2 servers (to prevent resource exhaustion via many streams, etc.), and up-to-date libraries to patch known vulns. Regularpenetration testingof SBA interfaces is advisable — ensure no accidental open endpoints. Leverage Ericsson’s security tools for 5G core: for example,Ericsson Security Managercan automate security policies and compliance in the core network functions. It might help in ensuring proper certificate management and monitoring config drift. Finally, apply cloud security: isolate the network function containers/VMs in secure segments (even within the cluster, e.g., using Kubernetes network policies to only allow needed NF-to-NF traffic). This way, if one NF is compromised, lateral movement is harder. Use robust IAM — the operations personnel should have fine-grained access (so an insider can’t just call an API to get all subscriber info unless their role explicitly permits it). Summarily, mitigating 5G registration/auth threats involvesstronger enforcement of authentication for every core interactionanddesigning for surge handling, building on improvements 5G already made over 4G.

Stage 3: Session Establishment & Management (AMF/SMF/PCF to UPF — N11, N4, N7 interfaces)​

This stage in 5G corresponds to setting up PDU sessions (the 5G equivalent of bearers) and managing them. The UE, after registering, requests a PDU session via the AMF, which passes it to the SMF (N11 interface). The SMF then interacts with the UPF (via N4, similar to GTP-C, but typically using PFCP protocol over UDP) to establish the user-plane tunnel, and with the PCF (via N7, a Diameter or HTTP/2 based interface for policy, analogous to Gx). Also, the SMF may fetch subscriber session data from UDM (N10) and liaise with the AF (application function) via NEF for certain services.

Threats & Techniques:​

Many of the threats from the LTE session setup carry into 5G:GTP-U/PFCP issues, user impersonation, fraud— because in 5G Non-Standalone or roaming scenarios, GTP is still used on N3 and possibly N9 (inter-UPF). However, focusing on pure 5G SBA:PFCP (Packet Forwarding Control Protocol)is used between SMF and UPF to manage tunnels. PFCP, like GTP-C, might be abused if not secured — an attacker with access could send fake PFCP Session Establishment or Deletion messages, similar to the GTP attacks (this again relates toNetwork DoS or manipulation). If an attacker compromised an SMF or impersonated one, they could tell the UPF to reroute a user’s traffic to a different endpoint (like a malicious intercept point). That would be a potentman-in-the-middlevector (aligning with ATT&CKT1557). Another threat:Policy injection— an attacker messing with PCF could alter how traffic is treated (e.g., remove throttling for his device or apply a filter that diverts traffic). In 5G, PCF might be part of the SBA (with N7 as an API call or a Diameter message if backward compatibility). If PCF is compromised or if someone breaches the interface between SMF and PCF, they could manipulate charging or QoS rules (a form offinancial fraud or service quality attack). A subtle threat in 5G isnetwork slice hopping: if an attacker’s session is on one slice but they find a way to get resources from another — for instance, if there’s a misconfigured UPF that serves multiple slices and doesn’t enforce separation, an attacker might craft traffic that uses a different slice’s QoS or IP range. This is more of a misconfig scenario than a known exploit, but it’s theorized in academic circles (ensuring slice isolation is still new). Also, as everything is virtualized, threats likecontainer breakoutin a UPF or SMF could allow an attacker to control that function and then all sessions on it. Realize that a UPF compromise is extremely serious — it handles actual user packets, so a malicious UPF could copy all traffic or inject malware into unencrypted streams. This could be achieved by an insider planting backdoors or an attacker exploiting a zero-day in the UPF software (maybe via a malformed packet as trigger). MITRE FiGHT includes techniques around compromising user-plane function and tampering with data forwarding.

Adversary Exploitation:​

Consider an adversary who has gotten inside the 5G core network (maybe through an OAM system or via lateral movement from an IT breach). They might target the SMF first, as it’s the brain of session management. If they can impersonate the SMF’s identity, they might directly send PFCP commands to the UPF (since UPFs typically accept commands from their assigned SMF). If mutual authentication isn’t enforced on N4 (some deployments might rely on IPsec or network isolation rather than strong auth at PFCP level), an attacker could spoof SMF’s IP and send a message like “delete session for user X”, cutting off service for that user (DoS), or “add forwarding rule for user Y’s traffic to mirror to Z endpoint” (surveillance). Alternatively, compromise of UPF (which may be less likely internet-exposed but could be vulnerable via maintenance interfaces) gives full control — an attacker could then, for example, create “cloned” sessions: they could maintain two active endpoints for one session, one being a spy sink. For PCF, an attacker could push a malformed policy rule that triggers a crash or forces the SMF to behave incorrectly. Or they might simply turn off certain filters — e.g., allow previously blocked content or services (if they want, say, to enable an otherwise prohibited activity for a malicious purpose). If an attacker found a vulnerability in PFCP implementation, they could craft an abnormal message that the UPF doesn’t handle well, causing a crash (thus knocking out data service for a slice or area — a direct DoS). Positive Technologies (a security firm) reported that many tested 5G cores still exhibited vulnerabilities reminiscent of GTP ones if interworking is ontechmonitor.aip1sec.com, implying some carriers might not fully secure PFCP/GTP in 5G either. A nation-state might not attack 5G core in isolation but use it as one step — e.g., compromise core, alter sessions of a target individual to remove encryption (maybe force 5G to hand down a rule to not use integrity on user plane — though normally user-plane isn’t E2E encrypted beyond air interface, but perhaps in 5G some service might be). The possibilities are complex, but the core idea: if core control can be subverted, user sessions can be controlled.

Detection:​

Monitoring PFCP is similar to monitoring GTP-C: have logs of SMF commands to UPF. The SMF should log all PFCP transactions (success/failure). If an attacker attempts unauthorized PFCP, a well-configured UPF might log it as an error (unknown peer or unexpected sequence). Those logs should be flagged. Use of aPFCP/N4 firewallcan log and drop unexpected messages (similar to GTP firewall concept, some vendors extend it to PFCP). On the API side (N7, N10, etc.), ensure that PCF logs any abnormal policy change. If PCF is issuing rules that don’t match subscriber profiles, an analytics system might catch that (comparing actual policy state vs expected). Since slicing and multiple networks complicate matters, having a unified view in SIEM helps — e.g., cross-check that the slice identifier for a session remains consistent across SMF and UPF logs (if not, something’s wrong possibly). Another detection approach:Integrity verification— some operators consider using blockchain or secure logs for critical session changes. Not mainstream yet, but conceptually, detecting if session state was changed without proper authorization. For container escapes or NF compromises, integrateCNF (Cloud-native function) security monitoring: if a UPF container suddenly opens a network connection to an unusual address (like exfiltrating data or connecting to attacker C2), that should trigger an alert. Also, because 5G core might run on COTS hardware, leverage traditional IDS on the platform — for instance, a Snort rule could detect if someone tries to exploit a known vulnerability in the HTTP/2 API of SMF. Essentially, combine telecom-specific monitors with conventional IT security monitors. Ericsson event logs, if similar to the provided ones, would include entries for control transactions. For example, if an attacker was toggling session states, you might see a high count of events like “Session Modified” or error responses. A baseline of normal counts (perhaps only a few hundred per hour) vs thousands could indicate mischief. Finally, user-plane QoS anomalies (like a user unexpectedly getting max bandwidth) could be detected by analytics comparing usage to subscription profile — a drastic deviation might imply someone removed limits via policy manipulation.

Prevention & Mitigation:​

Secure the SMF-UPF interface (N4): Use IPSec or TLS for PFCP if supported, or at least network-layer ACLs so only the genuine SMF’s IP can talk to UPF on that port. The UPF should implement message authentication (some deployments use pre-shared keys or certificates for PFCP peers). Update UPF software promptly for any PFCP parsing bugs.Validate configurations— e.g., the UPF should reject commands that don’t make sense (like altering a session that wasn’t authorized by the right SMF). Employ aPCF/Policy firewallconcept: just as Diameter firewalls protect Gx in 4G, ensure that in 5G the PCF’s inputs (from NF or OSS systems) are sanitized. Only allow policy changes through official channels (no developer backdoor APIs open). Also restrict PCF admin interfaces (someone shouldn’t be able to just log into PCF DB and flip bits). For slicing, enforceslice-level security: each slice could have its own SMF/UPF instances — this limits the blast radius of a compromise. If one slice’s SMF is compromised, it shouldn’t affect another slice. Use inter-slice isolation via the hypervisor or container network so that even if attacker gets root on one slice’s NF, they can’t easily reach others. Some operators use separate cloud clusters per slice (especially for very sensitive slices like enterprise networks). If that’s too heavy, at least logically separate via strong multi-tenancy controls.Mutual authentication for NFs: again, the theme — all core NFs, including SMF to UPF, should mutually authenticate. PCF to SMF (N7) typically uses OAuth2 tokens — ensure those tokens are scoped and short-lived so they can’t be stolen and reused widely.Monitoring and anomaly response: implement closed-loop mitigation where possible. For instance, if a certain user’s session starts behaving abnormally (maybe because an attacker messed with it), automatically trigger a session release and force the user to re-establish under clean conditions. While disruptive, it limits the window of compromise. Maintain robust backups of subscriber profiles and session info in case an attacker tries to manipulate or wipe them (for recovery). As with 4G, many mitigations come down tobest practices and using the security features available: e.g., 3GPP provided Security Edge Protection Proxy (SEPP) for securing inter-operator service-based messages — use it to prevent outsider attacks via roaming interfaces. Similarly, follow standards like 3GPP TS 33.501 which outlines security for 5G systems, ensuring compliance in Ericsson’s products (Ericsson’s 5G core is designed to meet these standards, but configuration matters). In summary, mitigation in stage 3 is aboutfortifying the control instructions for user plane— authenticate every command, segment responsibilities, and minimize any one component’s ability to wreck havoc without detection or permission.

Stage 4: User-Plane Traffic in 5G (UE to Data Network via UPF — N3, N6 interfaces)​

Once sessions are established, the user-plane flows through the 5G UPF to the external network (N6 interface, analogous to SGi). In many respects, this stage’s threats resemble the LTE user-plane stage, but 5G adds nuance with features like ULCL (uplink classifier), multi-hop UPFs, and edge computing.

Threats & Techniques:​

The user-plane can be attacked byDDoSsimilarly — adversaries might target the UPF or the data network by sending floods. With 5G’s increased bandwidth and IoT scale, the impact of botnets could be even larger (imagine many 5G devices concurrently attacking an internet target or conversely a huge volumetric attack on a UPF’s IP).Edge computing (MEC) abuse: if 5G has Mobile Edge Computing nodes (which interface with the UPF to local breakout traffic), an attacker could target those applications to either get into the telco network or to use them as pivot points (for example, a vulnerable MEC app could be used to send commands to the UPF if not properly separated). Also, 5G’s higher speed and capacity may enable new tactics: e.g., an attacker could use a single 5G device as a high-bandwidth rogue — downloading or uploading enormous data (perhaps trying to cause billing issues or hide exfiltration in normal traffic). Another threat isexposed IP services: in 5G, especially with IPv6, devices might run services reachable from the internet. A misconfigured firewall or open exposure could let attackers directly compromise devices (which then become platform for further attacks). One relevant new angle isapplication layer attacks over 5G: as 5G is used for critical services (telemedicine, industrial control), an attacker might not attack the network per se but use the network to deliver specific malicious payloads (like sending malicious commands to an IoT actuator). From the network perspective, detecting that can be hard if it looks like legitimate traffic. This strays into application security, but a telecom operator concerned with critical IoT might need to inspect traffic for known malicious patterns (DPI for ICS protocols, etc.).MITRE ATT&CKdoesn’t have telecom-specific network user-plane exploits beyond generic sniffing and DoS, but FiGHT likely includes techniques like**“Abuse of 5G QoS/traffic steering”**— an adversary might attempt to exploit how the UPF steers traffic. For example, some traffic can be redirected to lawful intercept or analytics by rules; if an attacker can trigger those rules inappropriately, they might cause misrouting (maybe send a victim’s traffic to a server the attacker controls by abusing a policy routing flaw).

Adversary Exploitation:​

If a device is compromised (through OS vulnerability or user action), the adversary might install a toolkit to use it as a stepping stone — possibly scanning internally (if on a private APN) or participating in attacks. For instance, a compromised phone with high bandwidth could launch malware distribution (using its cellular link which is generally trusted by some network filters) — not directly an attack on the network, but the network could be used to shield or amplify it. There have been cases where mobile devices were part of botnets (though more often WiFi/PC-based bots are used, one can’t ignore mobile botnets). Another exploitation could involve the attacker subscribing to a 5G service and then taking advantage of any uncapped usage to perform massive DDoS. If the operator’s detection is slow, they could push terabytes of traffic, maybe causing peering link congestion or incurring cost to the operator. On the flip side, an external adversary might do a reflective attack where they send traffic that causes many UEs to respond simultaneously, flooding the cell or core (imagine abusing some protocol like sending packets that solicit large responses from many IoT devices). Intercepting traffic at the user-plane in 5G is theoretically harder if end-to-end encryption is used by apps, but if not, a sophisticated attacker could still attempt atraffic correlationattack (e.g., track a user by their unencrypted metadata or patterns, even if not reading content). If an attacker can deploy a malicious UPF in a network slice (say an enterprise slice that allows third-party network functions), they could potentially siphon data. This is an extreme scenario likely prevented by network integrity checks, but as networks slice out to enterprise control, the risk of mismanaged user-plane function by a customer could be a concern.

Detection (Ericsson Logs & Tools):​

Many detection methods remain the same as 4G for user-plane: DDoS detection systems, traffic analytics for anomalies. However, 5G’s service-based monitoring might provide better insights. For instance, network data analytics function (NWDAF) in 5G can gather data from core NFs and look for patterns (the intention is for optimization, but it could assist security by spotting unusual traffic loads). An NWDAF configured for anomaly detection might flag if a particular device’s traffic deviates from its norm drastically. This info can feed into a security analytics platform. Ericsson’s 5G core likely integrates NWDAF or similar telemetry which could be used by a SIEM to raise alerts (e.g., NWDAF reports slice X throughput is 5x expected). For direct attacks: if an attacker tries to overwhelm the UPF, the UPF’s metrics (CPU, queue length) will spike. Logs might show packet drops or buffer overflow events. If the UPF supports telemetry via IPFIX or similar, sudden changes in flow counts or an explosion in number of flows could indicate scanning or worm activity. Also, since 5G often coexists with cloud, one might use cloud networking logs — many 5G deployments on AWS/Azure use cloud native logs of VPC flow or load balancers. Those can show large traffic bursts or connections that could be suspicious. So a telecom SOC should ingest cloud infra logs as well. In terms of ATT&CK, detecting data exfiltration might involve noticing a device sending data to an unusual country or over an uncommon port — which a combination of DPI (to decode protocols) and threat intelligence (to flag known C2 servers) can achieve. The provided Ericsson event log sample is more core-signaling oriented, but if similar logging exists for user-plane events (like volume of data per user, or any alerts), those would be instrumental. A SIEM correlation could be: if one UE’s data volume jumps to 100x normal and at the same time network experiences some degrade, highlight that UE for investigation (maybe it’s compromised and being used maliciously).

Prevention & Mitigation:​

Network-level protections: employ robustGI-firewalls/DDoS protectionfor N6 in 5G just as in 4G. Many vendors offer combined SGi/N6 firewalls that handle both GTP and general IP traffic. They should be configured to automatically mitigate common floods (UDP floods, ICMP, etc.) and have high capacity to handle 5G-scale traffic.Throttling and tiering: make sure no single subscriber or slice can consume absurd amounts of resources unchecked — set burst limits and have plans that if exceeded, trigger review or slow down. 5G allows flexible QoS, which can be used defensively: in a DDoS scenario, you could assign suspect traffic a lower priority QoS flow to protect others.Edge security: if using MEC, treat MEC apps as untrusted relative to core — even though they are co-located, strictly firewall what MEC can do (e.g., a video analytics app at the edge likely needs only to see certain traffic, not query the core directly). Use segmentation so if a MEC server is compromised, it can’t talk to core NFs except via defined APIs.Device security: encourage strong endpoint security on 5G devices (EPP, mobile threat defense apps), especially for enterprise IoT on 5G. A compromised device is both a risk to itself and a launchpad into the network (some operators provide managed security services to enterprise IoT which could be mentioned as a strategy).Encryption and Integrity: 5G introduced the option for user-plane integrity protection (to prevent tampering with user traffic on sensitive slices, albeit it’s not always used due to performance). For extremely critical communications (e.g., control commands in industrial use case), enabling user-plane integrity and even encryption between UE and UPF might be considered — this would stop an attacker who somehow got into the transport from injecting or altering those packets. It’s not standard for all traffic due to overhead, but on a case-by-case it’s a mitigation against on-path tampering.Continuous monitoring: treat the 5G network as IT infrastructure in terms of security lifecycle — patch management, vulnerability scanning, zero-trust access for admins. Many user-plane issues can be pre-empted by keeping the underlying OS/hypervisor secure so attackers can’t get a foothold. Employ deception perhaps — deploy honeypot devices or fake services in the network (like a decoy IoT device that if touched indicates scanning) to catch attackers early. Finally, work closely with internet service providers and IXs: have agreements so if a huge DDoS is detected, upstream mitigation can be done (telcos often partner with anti-DDoS cloud providers).

**References: **Industry Standards and Frameworks

MITRE ATT&CK® Framework MITRE FiGHT™ Framework GSMA FS.19 Diameter Interconnect Security Guidelines GSMA FS.20 GTP Security Recommendations Research and Reports 5. Cybereason — Operation Soft Cell: A Worldwide Campaign Against Telecommunications Providers 6. P1 Security — Diameter & SS7 Security Reports 7. Positive Technologies — Telecom Security Threat Landscape Reports 8. ENISA Threat Landscape for 5G Networks 9. Bitdefender — Security Assessment of LTE Networks 10. Nokia Threat Intelligence Report — 5G Security

Ericsson Documentation 11. Ericsson 5G Security Whitepaper 12. Ericsson Diameter Signaling Controller Security Guide 13. Ericsson Mobility Management Entity (MME) Security Guidelines

Academic and Technical Papers 14. Khan, M.A., & Mitchell, C.J. (2018). Security Issues in the 5G Network. IEEE Communications Surveys & Tutorials, 20(4), 3516–3533. 15. Ahmad, I., et al. (2019). Overview of 5G Security Challenges and Solutions. IEEE Communications Standards Magazine, 3(1), 36–43. 16. Shaik, A., et al. (2016). Practical Attacks Against Privacy and Availability in 4G/LTE Mobile Communication Systems. NDSS Symposium.