Writable Sys Path +Dll Hijacking Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

• Sieh dir die subscription plans an!
• Tritt der 💬 Discord group, der telegram group bei, folge @hacktricks_live auf X/Twitter, oder schau dir die LinkedIn page und den YouTube channel an.
• Teile hacking tricks, indem du PRs in die HackTricks und HackTricks Cloud github repos einreichst.

Einführung

Wenn du festgestellt hast, dass du in einen System Path-Ordner schreiben kannst (beachte, dass das nicht funktioniert, wenn du in einen User Path-Ordner schreiben kannst), ist es möglich, dass du Privileges im System eskalieren kannst.

Dazu kannst du ein Dll Hijacking ausnutzen, bei dem du eine geladene library hijackst, die von einem Service oder Prozess mit mehr Privileges als deinen geladen wird, und weil dieser Service eine Dll lädt, die wahrscheinlich nicht einmal im gesamten System existiert, wird er versuchen, sie aus dem System Path zu laden, in den du schreiben kannst.

Für mehr Infos darüber, was Dll Hijacking ist, siehe:

Dll Hijacking

Privesc mit Dll Hijacking

Eine fehlende Dll finden

Das Erste, was du brauchst, ist, einen Prozess zu identifizieren, der mit mehr Privileges als du läuft und versucht, eine Dll aus dem System Path zu laden, in den du schreiben kannst.

Denk daran, dass diese Technik von einem Machine/System PATH-Eintrag abhängt, nicht nur von deinem User PATH. Deshalb lohnt es sich, bevor du Zeit mit Procmon verbringst, die Machine PATH-Einträge aufzulisten und zu prüfen, welche davon beschreibbar sind:

$machinePath = [Environment]::GetEnvironmentVariable("Path", "Machine") -split ';' | Where-Object { $_ }
$machinePath | ForEach-Object {
$path = $_.Trim()
if ($path) {
Write-Host "`n[*] $path"
icacls $path 2>$null
}
}

Das Problem in diesen Fällen ist, dass diese Prozesse wahrscheinlich bereits laufen. Um herauszufinden, welche Dlls den Services fehlen, musst du procmon so früh wie möglich starten (bevor Prozesse geladen werden). Um fehlende .dlls zu finden, gehe wie folgt vor:

• Create den Ordner C:\privesc_hijacking und füge den Pfad C:\privesc_hijacking zur System Path env variable hinzu. Du kannst dies manually oder mit PS tun:

# Set the folder path to create and check events for
$folderPath = "C:\privesc_hijacking"

# Create the folder if it does not exist
if (!(Test-Path $folderPath -PathType Container)) {
New-Item -ItemType Directory -Path $folderPath | Out-Null
}

# Set the folder path in the System environment variable PATH
$envPath = [Environment]::GetEnvironmentVariable("PATH", "Machine")
if ($envPath -notlike "*$folderPath*") {
$newPath = "$envPath;$folderPath"
[Environment]::SetEnvironmentVariable("PATH", $newPath, "Machine")
}

• Starte procmon und gehe zu Options –> Enable boot logging und drücke OK in der Eingabeaufforderung.
• Dann neu starten. Wenn der Computer neu gestartet wird, beginnt procmon sofort, Ereignisse aufzuzeichnen.
• Sobald Windows gestartet ist, führe procmon erneut aus. Es teilt dir mit, dass es bereits läuft, und wird fragen, ob du die Ereignisse in einer Datei speichern möchtest. Antworte mit yes und speichere die Ereignisse in einer Datei.
• Nachdem die Datei generiert wurde, schließe das geöffnete procmon-Fenster und öffne die Ereignisdatei.
• Füge diese Filter hinzu und du wirst alle Dlls finden, die ein Prozess versucht hat zu laden aus dem beschreibbaren System Path-Ordner:

Tip

Boot logging ist nur für Services erforderlich, die zu früh starten, um sie sonst beobachten zu können. Wenn du den Ziel-Service/das Ziel-Programm bei Bedarf auslösen kannst (zum Beispiel durch Interaktion mit seiner COM-Schnittstelle, Neustart des Services oder erneutes Starten einer Scheduled Task), ist es normalerweise schneller, einen normalen Procmon-Capture mit Filtern wie Path contains .dll, Result is NAME NOT FOUND und Path begins with <writable_machine_path> beizubehalten.

Missed Dlls

Wenn ich das in einer kostenlosen virtuellen (vmware) Windows 11 machine ausführe, erhalte ich diese Ergebnisse:

In diesem Fall sind die .exe nutzlos, also ignoriere sie. Die fehlenden DLLs waren von:

Nachdem ich das gefunden hatte, stieß ich auf diesen interessanten Blog-Post, der auch erklärt, wie man WptsExtensions.dll für privesc missbrauchen kann. Genau das werden wir jetzt tun.

Other candidates worth triaging

WptsExtensions.dll ist ein gutes Beispiel, aber es ist nicht die einzige wiederkehrende phantom DLL, die in privilegierten Services auftaucht. Moderne Hunting-Regeln und öffentliche Hijack-Kataloge verfolgen weiterhin Namen wie diese:

Betrachte diese Namen als Triage-Hinweise, nicht als garantierte Treffer: Sie sind SKU/build-abhängig, und Microsoft kann das Verhalten zwischen Releases ändern. Die wichtige Erkenntnis ist, nach fehlenden DLLs in privilegierten Services zu suchen, die den Machine PATH durchsuchen, besonders wenn der Service ohne Neustart erneut ausgelöst werden kann.

Exploitation

Um also die privileges zu erhöhen, werden wir die Library WptsExtensions.dll hijacken. Mit dem Pfad und dem Namen müssen wir nur noch die malicious dll erzeugen.

Du kannst versuchen, eines dieser Beispiele zu verwenden. Du könntest Payloads ausführen wie: eine rev shell erhalten, einen Benutzer hinzufügen, einen beacon ausführen…

Warning

Beachte, dass nicht alle Services mit NT AUTHORITY\SYSTEM ausgeführt werden, einige laufen auch mit NT AUTHORITY\LOCAL SERVICE, was weniger privileges hat, und du kannst keinen neuen Benutzer erstellen, um seine Berechtigungen zu missbrauchen.
Allerdings hat dieser Benutzer das seImpersonate-Privilege, sodass du die potato suite zur privilege escalation verwenden kannst. In diesem Fall ist also eine rev shell die bessere Option als zu versuchen, einen Benutzer zu erstellen.

Zum Zeitpunkt des Schreibens läuft der Task Scheduler-Service mit Nt AUTHORITY\SYSTEM.

Nachdem die malicious Dll erzeugt wurde (in meinem Fall habe ich eine x64 rev shell verwendet und eine Shell zurückbekommen, aber Defender hat sie gekillt, weil sie von msfvenom stammte), speichere sie im beschreibbaren System Path unter dem Namen WptsExtensions.dll und starte den Computer neu (oder starte den Service neu oder tue, was auch immer nötig ist, um den betroffenen Service/das betroffene Programm erneut auszuführen).

Wenn der Service neu gestartet wird, sollte die dll geladen und ausgeführt werden (du kannst den procmon-Trick erneut verwenden, um zu prüfen, ob die Library wie erwartet geladen wurde).

References

• Windows DLL Hijacking (Hopefully) Clarified
• Suspicious DLL Loaded for Persistence or Privilege Escalation

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

• Sieh dir die subscription plans an!
• Tritt der 💬 Discord group, der telegram group bei, folge @hacktricks_live auf X/Twitter, oder schau dir die LinkedIn page und den YouTube channel an.
• Teile hacking tricks, indem du PRs in die HackTricks und HackTricks Cloud github repos einreichst.