Attacking the 5G core: what a Standalone network looks like to an attacker

5G is usually sold on three promises: more speed, lower latency, more capacity. The more consequential change is structural — and it reshapes the attack surface in ways earlier generations never had to worry about.

This article walks through the 5G Standalone (SA) core from a security perspective: how its functions communicate, why HTTP/2 changes the kind of exposure operators face, and what a structured assessment of that environment reveals. It's written to explain risk and how to mitigate it — not as an intrusion guide.

01 / ARCHITECTUREWhat is a 5G Standalone core, in practice?

In the 5G SA model defined by 3GPP (TS 23.501 and TS 23.502), the core is a set of Network Functions (NFs), each owning a specific responsibility: access and mobility AMF, session management SMF, user-plane routing UPF, authentication AUSF, subscriber data UDM/UDR, policy PCF, and service discovery NRF.

The NRF deserves special attention. In a service-based architecture, a function that wants to consume a service first has to discover which function provides it. The NRF is the registry for that process — which makes it, defensively, both a single point of knowledge and a potential single point of abuse.

// The NRF (mint) is where every function looks to find every other function.

02 / PROTOCOLSWhy does HTTP/2 change the picture?

Earlier generations relied on telco-specific signaling: MAP/CAP over SS7 in 2G/3G, Diameter over SCTP in 4G — both with a long documented history of abuse. The 5G control plane instead uses APIs built on HTTP/2, with messages structured as JSON and protection expected via TLS.

That word — expected — is the whole point. When control-plane traffic between functions isn't encrypted and authorized, it becomes readable and potentially modifiable by anyone positioned to observe it. And unlike SS7, the skills to understand it are no longer niche: they're standard web-security skills.

2G / 3G

MAP / CAP

TCAP

SCCP

MTP / M3UA

SCTP

PHY

4G

DIAMETER

SCTP

IP

PHY

5G

JSON

HTTP / 2

TLS

TCP

IP

PHY

// The control plane moves from telco-only signaling to the IT stack. TLS is the layer that's often missing.

03 / METHODOLOGYWhat does a structured assessment reveal?

Assuming a controlled scenario where an assessor already has a foothold inside the core, a natural methodology follows: observe first, then discover, then evaluate impact.

Passive reconnaissance starts with capturing internal traffic and asking a simple question — can it be understood? In a lab core running OpenAirInterface without TLS, HTTP/2 control-plane traffic is legible JSON: it can expose identifiers, registration data, and enough structure to reconstruct the logical topology and identify the NRF.

From there, impact is assessed across three dimensions:

04 / FINDINGThe uncomfortable finding: most cores ship unprotected

The assessment looked at whether encryption and authorization are actually implemented across open-source cores and commercial vendor implementations. The mechanisms exist in the standard — they simply aren't switched on.

Commercial vendors anonymized. The pattern is consistent across both open-source and industry implementations: protection between network functions is largely absent by default.

05 / DEFENSEHow should a 5G core be protected?

Against misuse of the HTTP/2 control plane, two controls do most of the work — and around them, the discipline that cloud-native deployments demand.

The 5G core is a complex environment to operate and defend: multiple layers, multiple vendors, a service-based design that trades isolation for flexibility. The encouraging part is that the gap is mostly one of configuration and operational rigor — not missing technology.

FAQCommon questions