You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## 9. 5G NAS Registration Attacks: SUCI leaks, downgrade to EEA0/EIA0, and NAS replay
145
+
146
+
The 5G registration procedure runs over NAS (Non-Access Stratum) on top of NGAP. Until NAS security is activated by Security Mode Command/Complete, initial messages are unauthenticated and unencrypted. This pre-security window enables multiple attack paths when you can observe or tamper with N2 traffic (e.g., on-path inside the core, rogue gNB, or testbed).
147
+
148
+
Registration flow (simplified):
149
+
- Registration Request: UE sends SUCI (encrypted SUPI) and capabilities.
Expected: UE/USIM must transmit SUCI (SUPI encrypted with the home-network public key). Finding a plaintext SUPI/IMSI in the Registration Request indicates a privacy defect enabling persistent subscriber tracking.
164
+
165
+
How to test:
166
+
- Capture the first NAS message in InitialUEMessage and inspect the Mobile Identity IE.
167
+
- Wireshark quick checks:
168
+
- It should decode as SUCI, not IMSI.
169
+
- Filter examples: `nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci` should exist; absence plus presence of `imsi` indicates leakage.
170
+
171
+
What to collect:
172
+
- MCC/MNC/MSIN if exposed; log per-UE and track across time/locations.
173
+
174
+
Mitigation:
175
+
- Enforce SUCI-only UEs/USIMs; alert on any IMSI/SUPI in initial NAS.
176
+
177
+
### 9.2 Capability bidding-down to null algorithms (EEA0/EIA0)
178
+
Background:
179
+
- UE advertises supported EEA (encryption) and EIA (integrity) in the UE Security Capability IE of the Registration Request.
180
+
- Common mappings: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 are null algorithms.
181
+
182
+
Issue:
183
+
- Because the Registration Request is not integrity protected, an on-path attacker can clear capability bits to coerce selection of EEA0/EIA0 later during Security Mode Command. Some stacks wrongly allow null algorithms outside emergency services.
184
+
185
+
Offensive steps:
186
+
- Intercept InitialUEMessage and modify the NAS UE Security Capability to advertise only EEA0/EIA0.
187
+
- With Sni5Gect, hook the NAS message and patch the capability bits before forwarding.
188
+
- Observe whether AMF accepts null ciphers/integrity and completes Security Mode with EEA0/EIA0.
189
+
190
+
Verification/visibility:
191
+
- In Wireshark, confirm selected algorithms after Security Mode Command/Complete.
192
+
- Example passive sniffer output:
193
+
```
194
+
Encyrption in use [EEA0]
195
+
Integrity in use [EIA0, EIA1, EIA2]
196
+
SUPI (MCC+MNC+MSIN) 9997000000001
197
+
```
198
+
199
+
Mitigations (must):
200
+
- Configure AMF/policy to reject EEA0/EIA0 except where strictly mandated (e.g., emergency calls).
201
+
- Prefer enforcing EEA2/EIA2 at minimum; log and alarm on any NAS security context that negotiates null algorithms.
202
+
203
+
### 9.3 Replay of initial Registration Request (pre-security NAS)
204
+
Because initial NAS lacks integrity and freshness, captured InitialUEMessage+Registration Request can be replayed to AMF.
205
+
206
+
PoC rule for 5GReplay to forward matching replays:
207
+
208
+
```xml
209
+
<beginning>
210
+
<propertyvalue="THEN"
211
+
property_id="101"
212
+
type_property="FORWARD"
213
+
description="Forward InitialUEMessage with Registration Request">
214
+
215
+
<!-- Trigger on NGAP InitialUEMessage (procedureCode == 15) -->
216
+
<eventvalue="COMPUTE"
217
+
event_id="1"
218
+
description="Trigger: InitialUEMessage"
219
+
boolean_expression="ngap.procedure_code == 15"/>
220
+
221
+
<!-- Context match on NAS Registration Request (message_type == 65) -->
222
+
<eventvalue="COMPUTE"
223
+
event_id="2"
224
+
description="Context: Registration Request"
225
+
boolean_expression="nas_5g.message_type == 65"/>
226
+
227
+
</property>
228
+
</beginning>
229
+
```
230
+
231
+
What to observe:
232
+
- Whether AMF accepts the replay and proceeds to Authentication; lack of freshness/context validation indicates exposure.
233
+
234
+
Mitigations:
235
+
- Enforce replay protection/context binding at AMF; rate-limit and correlate per-GNB/UE.
236
+
237
+
### 9.4 Tooling pointers (reproducible)
238
+
- Open5GS: spin up an AMF/SMF/UPF to emulate core; observe N2 (NGAP) and NAS.
239
+
- Wireshark: verify decodes of NGAP/NAS; apply the filters above to isolate Registration.
240
+
- 5GReplay: capture a registration, then replay specific NGAP + NAS messages as per the rule.
241
+
- Sni5Gect: live sniff/modify/inject NAS control-plane to coerce null algorithms or perturb authentication sequences.
This forged certificate will be **valid** until the end date specified and as **long as the root CA certificate is valid** (usually from 5 to **10+ years**). It's also valid for **machines**, so combined with **S4U2Self**, an attacker can **maintain persistence on any domain machine** for as long as the CA certificate is valid.\
46
46
Moreover, the **certificates generated** with this method **cannot be revoked** as CA is not aware of them.
47
47
48
+
### Operating under Strong Certificate Mapping Enforcement (2025+)
49
+
50
+
Since February 11, 2025 (after KB5014754 rollout), domain controllers default to **Full Enforcement** for certificate mappings. Practically this means your forged certificates must either:
51
+
52
+
- Contain a strong binding to the target account (for example, the SID security extension), or
53
+
- Be paired with a strong, explicit mapping on the target object’s `altSecurityIdentities` attribute.
54
+
55
+
A reliable approach for persistence is to mint a forged certificate chained to the stolen Enterprise CA and then add a strong explicit mapping to the victim principal:
56
+
57
+
```powershell
58
+
# Example: map a forged cert to a target account using Issuer+Serial (strong mapping)
59
+
$Issuer = 'DC=corp,DC=local,CN=CORP-DC-CA' # reverse DN format expected by AD
60
+
$SerialR = '1200000000AC11000000002B' # serial in reversed byte order
61
+
$Map = "X509:<I>$Issuer<SR>$SerialR" # strong mapping format
- If you can craft forged certificates that include the SID security extension, those will map implicitly even under Full Enforcement. Otherwise, prefer explicit strong mappings. See
67
+
[account-persistence](account-persistence.md) for more on explicit mappings.
68
+
- Revocation does not help defenders here: forged certificates are unknown to the CA database and thus cannot be revoked.
69
+
48
70
## Trusting Rogue CA Certificates - DPERSIST2
49
71
50
72
The `NTAuthCertificates` object is defined to contain one or more **CA certificates** within its `cacertificate` attribute, which Active Directory (AD) utilizes. The verification process by the **domain controller** involves checking the `NTAuthCertificates` object for an entry matching the **CA specified** in the Issuer field of the authenticating **certificate**. Authentication proceeds if a match is found.
51
73
52
-
A self-signed CA certificate can be added to the `NTAuthCertificates` object by an attacker, provided they have control over this AD object. Normally, only members of the **Enterprise Admin** group, along with **Domain Admins** or **Administrators** in the **forest root’s domain**, are granted permission to modify this object. They can edit the `NTAuthCertificates` object using `certutil.exe` with the command `certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA126`, or by employing the [**PKI Health Tool**](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store#method-1---import-a-certificate-by-using-the-pki-health-tool).
74
+
A self-signed CA certificate can be added to the `NTAuthCertificates` object by an attacker, provided they have control over this AD object. Normally, only members of the **Enterprise Admin** group, along with **Domain Admins** or **Administrators** in the **forest root’s domain**, are granted permission to modify this object. They can edit the `NTAuthCertificates` object using `certutil.exe` with the command `certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA`, or by employing the [**PKI Health Tool**](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store#method-1---import-a-certificate-by-using-the-pki-health-tool).
75
+
76
+
Additional helpful commands for this technique:
77
+
78
+
```bash
79
+
# Add/remove and inspect the Enterprise NTAuth store
certutil -dspublish -f C:\Temp\CERT.crt CA # CN=AIA
87
+
```
53
88
54
89
This capability is especially relevant when used in conjunction with a previously outlined method involving ForgeCert to dynamically generate certificates.
55
90
91
+
> Post-2025 mapping considerations: placing a rogue CA in NTAuth only establishes trust in the issuing CA. To use leaf certificates for logon when DCs are in **Full Enforcement**, the leaf must either contain the SID security extension or there must be a strong explicit mapping on the target object (for example, Issuer+Serial in `altSecurityIdentities`). See {{#ref}}account-persistence.md{{#endref}}.
92
+
56
93
## Malicious Misconfiguration - DPERSIST3
57
94
58
95
Opportunities for **persistence** through **security descriptor modifications of AD CS** components are plentiful. Modifications described in the "[Domain Escalation](domain-escalation.md)" section can be maliciously implemented by an attacker with elevated access. This includes the addition of "control rights" (e.g., WriteOwner/WriteDACL/etc.) to sensitive components such as:
@@ -64,7 +101,19 @@ Opportunities for **persistence** through **security descriptor modifications of
64
101
65
102
An example of malicious implementation would involve an attacker, who has **elevated permissions** in the domain, adding the **`WriteOwner`** permission to the default **`User`** certificate template, with the attacker being the principal for the right. To exploit this, the attacker would first change the ownership of the **`User`** template to themselves. Following this, the **`mspki-certificate-name-flag`** would be set to **1** on the template to enable **`ENROLLEE_SUPPLIES_SUBJECT`**, allowing a user to provide a Subject Alternative Name in the request. Subsequently, the attacker could **enroll** using the **template**, choosing a **domain administrator** name as an alternative name, and utilize the acquired certificate for authentication as the DA.
Practical knobs attackers may set for long-term domain persistence (see {{#ref}}domain-escalation.md{{#endref}} for full details and detection):
68
105
106
+
- CA policy flags that allow SAN from requesters (e.g., enabling `EDITF_ATTRIBUTESUBJECTALTNAME2`). This keeps ESC1-like paths exploitable.
107
+
- Template DACL or settings that allow authentication-capable issuance (e.g., adding Client Authentication EKU, enabling `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`).
108
+
- Controlling the `NTAuthCertificates` object or the CA containers to continuously re-introduce rogue issuers if defenders attempt cleanup.
69
109
110
+
> [!TIP]
111
+
> In hardened environments after KB5014754, pairing these misconfigurations with explicit strong mappings (`altSecurityIdentities`) ensures your issued or forged certificates remain usable even when DCs enforce strong mapping.
70
112
113
+
114
+
115
+
## References
116
+
117
+
- Microsoft KB5014754 – Certificate-based authentication changes on Windows domain controllers (enforcement timeline and strong mappings). https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
118
+
- Certipy – Command Reference and forge/auth usage. https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference
0 commit comments