mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Merge branch 'master' of github.com:HackTricks-wiki/hacktricks
This commit is contained in:
carlospolop
commit
cbcccd68c4
@ -141,17 +141,127 @@ rm -f /tmp/sh ; history -c
|
||||
* `Microsocks` + `ProxyChains` : lightweight SOCKS5 pivoting
|
||||
* `FRP` (≥0.37) : NAT traversal / asset bridging
|
||||
|
||||
## 9. 5G NAS Registration Attacks: SUCI leaks, downgrade to EEA0/EIA0, and NAS replay
|
||||
|
||||
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).
|
||||
|
||||
Registration flow (simplified):
|
||||
- Registration Request: UE sends SUCI (encrypted SUPI) and capabilities.
|
||||
- Authentication: AMF/AUSF send RAND/AUTN; UE returns RES*.
|
||||
- Security Mode Command/Complete: NAS integrity and ciphering are negotiated and activated.
|
||||
- PDU Session Establishment: IP/QoS setup.
|
||||
|
||||
Lab setup tips (non-RF):
|
||||
- Core: Open5GS default deployment is sufficient to reproduce flows.
|
||||
- UE: simulator or test UE; decode using Wireshark.
|
||||
- Active tooling: 5GReplay (capture/modify/replay NAS within NGAP), Sni5Gect (sniff/patch/inject NAS on the fly without bringing up a full rogue gNB).
|
||||
- Useful display filters in Wireshark:
|
||||
- ngap.procedure_code == 15 (InitialUEMessage)
|
||||
- nas_5g.message_type == 65 or nas-5gs.message_type == 65 (Registration Request)
|
||||
|
||||
### 9.1 Identifier privacy: SUCI failures exposing SUPI/IMSI
|
||||
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.
|
||||
|
||||
How to test:
|
||||
- Capture the first NAS message in InitialUEMessage and inspect the Mobile Identity IE.
|
||||
- Wireshark quick checks:
|
||||
- It should decode as SUCI, not IMSI.
|
||||
- Filter examples: `nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci` should exist; absence plus presence of `imsi` indicates leakage.
|
||||
|
||||
What to collect:
|
||||
- MCC/MNC/MSIN if exposed; log per-UE and track across time/locations.
|
||||
|
||||
Mitigation:
|
||||
- Enforce SUCI-only UEs/USIMs; alert on any IMSI/SUPI in initial NAS.
|
||||
|
||||
### 9.2 Capability bidding-down to null algorithms (EEA0/EIA0)
|
||||
Background:
|
||||
- UE advertises supported EEA (encryption) and EIA (integrity) in the UE Security Capability IE of the Registration Request.
|
||||
- Common mappings: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 are null algorithms.
|
||||
|
||||
Issue:
|
||||
- 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.
|
||||
|
||||
Offensive steps:
|
||||
- Intercept InitialUEMessage and modify the NAS UE Security Capability to advertise only EEA0/EIA0.
|
||||
- With Sni5Gect, hook the NAS message and patch the capability bits before forwarding.
|
||||
- Observe whether AMF accepts null ciphers/integrity and completes Security Mode with EEA0/EIA0.
|
||||
|
||||
Verification/visibility:
|
||||
- In Wireshark, confirm selected algorithms after Security Mode Command/Complete.
|
||||
- Example passive sniffer output:
|
||||
```
|
||||
Encyrption in use [EEA0]
|
||||
Integrity in use [EIA0, EIA1, EIA2]
|
||||
SUPI (MCC+MNC+MSIN) 9997000000001
|
||||
```
|
||||
|
||||
Mitigations (must):
|
||||
- Configure AMF/policy to reject EEA0/EIA0 except where strictly mandated (e.g., emergency calls).
|
||||
- Prefer enforcing EEA2/EIA2 at minimum; log and alarm on any NAS security context that negotiates null algorithms.
|
||||
|
||||
### 9.3 Replay of initial Registration Request (pre-security NAS)
|
||||
Because initial NAS lacks integrity and freshness, captured InitialUEMessage+Registration Request can be replayed to AMF.
|
||||
|
||||
PoC rule for 5GReplay to forward matching replays:
|
||||
|
||||
```xml
|
||||
<beginning>
|
||||
<property value="THEN"
|
||||
property_id="101"
|
||||
type_property="FORWARD"
|
||||
description="Forward InitialUEMessage with Registration Request">
|
||||
|
||||
<!-- Trigger on NGAP InitialUEMessage (procedureCode == 15) -->
|
||||
<event value="COMPUTE"
|
||||
event_id="1"
|
||||
description="Trigger: InitialUEMessage"
|
||||
boolean_expression="ngap.procedure_code == 15"/>
|
||||
|
||||
<!-- Context match on NAS Registration Request (message_type == 65) -->
|
||||
<event value="COMPUTE"
|
||||
event_id="2"
|
||||
description="Context: Registration Request"
|
||||
boolean_expression="nas_5g.message_type == 65"/>
|
||||
|
||||
</property>
|
||||
</beginning>
|
||||
```
|
||||
|
||||
What to observe:
|
||||
- Whether AMF accepts the replay and proceeds to Authentication; lack of freshness/context validation indicates exposure.
|
||||
|
||||
Mitigations:
|
||||
- Enforce replay protection/context binding at AMF; rate-limit and correlate per-GNB/UE.
|
||||
|
||||
### 9.4 Tooling pointers (reproducible)
|
||||
- Open5GS: spin up an AMF/SMF/UPF to emulate core; observe N2 (NGAP) and NAS.
|
||||
- Wireshark: verify decodes of NGAP/NAS; apply the filters above to isolate Registration.
|
||||
- 5GReplay: capture a registration, then replay specific NGAP + NAS messages as per the rule.
|
||||
- Sni5Gect: live sniff/modify/inject NAS control-plane to coerce null algorithms or perturb authentication sequences.
|
||||
|
||||
### 9.5 Defensive checklist
|
||||
- Continuously inspect Registration Request for plaintext SUPI/IMSI; block offending devices/USIMs.
|
||||
- Reject EEA0/EIA0 except for narrowly defined emergency procedures; require at least EEA2/EIA2.
|
||||
- Detect rogue or misconfigured infrastructure: unauthorized gNB/AMF, unexpected N2 peers.
|
||||
- Alert on NAS security modes that result in null algorithms or frequent replays of InitialUEMessage.
|
||||
|
||||
---
|
||||
## Detection Ideas
|
||||
1. **Any device other than an SGSN/GGSN establishing Create PDP Context Requests**.
|
||||
2. **Non-standard ports (53, 80, 443) receiving SSH handshakes** from internal IPs.
|
||||
3. **Frequent Echo Requests without corresponding Echo Responses** – might indicate GTPDoor beacons.
|
||||
4. **High rate of ICMP echo-reply traffic with large, non-zero identifier/sequence fields**.
|
||||
5. 5G: **InitialUEMessage carrying NAS Registration Requests repeated from identical endpoints** (replay signal).
|
||||
6. 5G: **NAS Security Mode negotiating EEA0/EIA0** outside emergency contexts.
|
||||
|
||||
## References
|
||||
|
||||
- [Palo Alto Unit42 – Infiltration of Global Telecom Networks](https://unit42.paloaltonetworks.com/infiltration-of-global-telecom-networks/)
|
||||
- 3GPP TS 29.060 – GPRS Tunnelling Protocol (v16.4.0)
|
||||
- 3GPP TS 29.281 – GTPv2-C (v17.6.0)
|
||||
- [Demystifying 5G Security: Understanding the Registration Protocol](https://bishopfox.com/blog/demystifying-5g-security-understanding-the-registration-protocol)
|
||||
- 3GPP TS 24.501 – Non-Access-Stratum (NAS) protocol for 5GS
|
||||
- 3GPP TS 33.501 – Security architecture and procedures for 5G System
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -45,14 +45,51 @@ certipy auth -pfx administrator_forged.pfx -dc-ip 172.16.126.128
|
||||
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.\
|
||||
Moreover, the **certificates generated** with this method **cannot be revoked** as CA is not aware of them.
|
||||
|
||||
### Operating under Strong Certificate Mapping Enforcement (2025+)
|
||||
|
||||
Since February 11, 2025 (after KB5014754 rollout), domain controllers default to **Full Enforcement** for certificate mappings. Practically this means your forged certificates must either:
|
||||
|
||||
- Contain a strong binding to the target account (for example, the SID security extension), or
|
||||
- Be paired with a strong, explicit mapping on the target object’s `altSecurityIdentities` attribute.
|
||||
|
||||
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:
|
||||
|
||||
```powershell
|
||||
# Example: map a forged cert to a target account using Issuer+Serial (strong mapping)
|
||||
$Issuer = 'DC=corp,DC=local,CN=CORP-DC-CA' # reverse DN format expected by AD
|
||||
$SerialR = '1200000000AC11000000002B' # serial in reversed byte order
|
||||
$Map = "X509:<I>$Issuer<SR>$SerialR" # strong mapping format
|
||||
Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}
|
||||
```
|
||||
|
||||
Notes
|
||||
- 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
|
||||
[account-persistence](account-persistence.md) for more on explicit mappings.
|
||||
- Revocation does not help defenders here: forged certificates are unknown to the CA database and thus cannot be revoked.
|
||||
|
||||
## Trusting Rogue CA Certificates - DPERSIST2
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
Additional helpful commands for this technique:
|
||||
|
||||
```bash
|
||||
# Add/remove and inspect the Enterprise NTAuth store
|
||||
certutil -enterprise -f -AddStore NTAuth C:\Temp\CERT.crt
|
||||
certutil -enterprise -viewstore NTAuth
|
||||
certutil -enterprise -delstore NTAuth <Thumbprint>
|
||||
|
||||
# (Optional) publish into AD CA containers to improve chain building across the forest
|
||||
certutil -dspublish -f C:\Temp\CERT.crt RootCA # CN=Certification Authorities
|
||||
certutil -dspublish -f C:\Temp\CERT.crt CA # CN=AIA
|
||||
```
|
||||
|
||||
This capability is especially relevant when used in conjunction with a previously outlined method involving ForgeCert to dynamically generate certificates.
|
||||
|
||||
> 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}}.
|
||||
|
||||
## Malicious Misconfiguration - DPERSIST3
|
||||
|
||||
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
|
||||
|
||||
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):
|
||||
|
||||
- CA policy flags that allow SAN from requesters (e.g., enabling `EDITF_ATTRIBUTESUBJECTALTNAME2`). This keeps ESC1-like paths exploitable.
|
||||
- Template DACL or settings that allow authentication-capable issuance (e.g., adding Client Authentication EKU, enabling `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`).
|
||||
- Controlling the `NTAuthCertificates` object or the CA containers to continuously re-introduce rogue issuers if defenders attempt cleanup.
|
||||
|
||||
> [!TIP]
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- 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
|
||||
- Certipy – Command Reference and forge/auth usage. https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user