mrk336/from-foothold-to-domain-admin-weaponizing-cve-2025-54918-in-real-world-devopsSimulierte Ausnutzung und Eindämmung von CVE-2025-54918 (Windows-NTLM-Schwachstelle). Enthält Erkennungsskripte, Ansible-Patching und CI/CD-Härtung. Demonstriert Privilegieneskalation von niedrigem Zugang zu SYSTEM in hybriden Cloud-Umgebungen.
Simulierte Ausnutzung und Eindämmung von CVE-2025-54918 (Windows NTLM-Fehler). Enthält Erkennungsskripte, Ansible-Patching und CI/CD-Härtung. Demonstriert Privilegieneskalation von niedrigem Zugang zu SYSTEM in hybriden Cloud-Umgebungen.
Von Mark Mallia
In den heutigen hybriden Cloud-Umgebungen ist die Grenze zwischen Benutzerinteraktion und Systemkompromittierung dünner denn je. Dieser Artikel untersucht eine reale Angriffskette, die mit einem scheinbar harmlosen Grafikfehler beginnt – CVE-2025-55226, eine Race-Condition im Windows-Grafikkernel – und über CVE-2025-54918, eine kritische NTLM-Authentifizierungsumgehung, zur vollen SYSTEM-Kontrolle eskaliert.
Zusammen zeigen diese Schwachstellen, wie Angreifer in nur wenigen Schritten von Remote-Code-Ausführung zur Privilegieneskalation übergehen können. Aber noch wichtiger: Sie zeigen, wie ein Senior DevOps Engineer solche Bedrohungen mit Automatisierung, CI/CD-Integration und Infrastructure-as-Code erkennen, entschärfen und überwachen kann.
Veröffentlicht: 16. September 2025 (Patch Tuesday)
Die neueste Sicherheitswarnung von Microsoft identifiziert einen schwerwiegenden Fehler in win32k.sys, dem zentralen Grafikkernel, der sowohl von Desktop- als auch von Servereditionen von Windows verwendet wird. Die Schwachstelle ist eine Race-Condition, die es einem Angreifer ermöglicht, Remote-Code-Ausführung (RCE) auf jedem System auszulösen, auf dem der anfällige Treiber läuft. Da der Treiber im Herzen der GDI (Graphics Device Interface) sitzt, kann er missbraucht werden, um beliebigen Code im Kernel-Modus auszuführen – eine Privilegienstufe, die den gesamten Rechner kompromittieren kann.
Warum das wichtig ist:
- Es betrifft ein Kernsubsystem, das jede grafische Benutzeroberfläche antreibt, von gewöhnlichen Bürocomputern bis hin zu leistungsstarken Servern.
- Ein am Dienstag veröffentlichter Patch bietet eine sofortige Behebung, aber nur, wenn Administratoren wissen, wie sie ihn rechtzeitig erkennen, bereitstellen und überwachen können.
Der folgende Ausschnitt zieht die aktuelle Version von win32k.sys aus der Registrierung, vergleicht sie mit der gepatchten Version und protokolliert Abweichungen in eine CSV-Datei, die in Excel oder Tableau importiert werden kann.
# DetectWin32k.ps1 – check for vulnerable win32k.sys
$target = 'Microsoft-Windows-GraphicsKernel'
$patchVersion = '6.0.22.7' # Expected patched version
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\$target"
$currentVer = Get-ItemProperty $regPath | Select-Object -ExpandProperty ImagePath
$kernelFile = Join-Path $env:SystemRoot \System32\win32k.sys
$fileVersion = (Get-ChildItem $kernelFile).VersionInfo.FileVersion
if ($fileVersion -ne $patchVersion) {
Write-Output "vulnerable: $currentVer (actual=$fileVersion, expected=$patchVersion)" | Out-File -Encoding ascii .\report.csv
}
Was es tut:
Die folgende YAML-Datei weist Ansible an, das win32k.sys-Update anzuwenden und den GDI-Dienst auf allen Zielhosts neu zu starten.
---
- name: Deploy Windows graphics kernel patch
hosts: windows_servers
gather_facts: yes
tasks:
- name: Copy new win32k.sys
copy:
src: /tmp/patches/win32k.sys
dest: C:\Windows\System32\
mode: '0644'
force: yes
- name: Restart GDI service
win_service:
name: w32k
state: restarted
Was es tut:
windows_servers).Erstellen Sie ein einfaches Panel, das die GDI-Objekt-Tabellennutzung im Zeitverlauf visualisiert.
# grafana-dashboard.yml
apiVersion: 1
dashboard:
title: “GDI Usage”
panels:
- name: “Objects in use”
type: graph
targets:
- query: "SELECT timestamp, gdi_objects FROM win32k_stats WHERE $__timeFilter()"
Was es tut:
win32k_stats) und zeigt sie auf einem Grafana-Panel an. Sie können Warnungen einrichten, wenn die Nutzung einen Schwellenwert überschreitet – ein früher Indikator für Treiberregressionen.Fügen Sie Ihrer Jenkins- oder GitHub-Actions-Pipeline einen Testschritt hinzu, der den Patch durch Fuzzing von win32k.sys mit einem leichten Tool (z.B. wdfuzz) überprüft.
# .github/workflows/cve55226.yml
name: CVE‑2025‑55226 CI
on:
push:
branches:
- main
jobs:
test_and_deploy:
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Run fuzzer
run: |
wdfuzz.exe -t win32k.sys -c config.yaml
if ($LASTEXITCODE -eq 0) { Write-Host "Fuzz passed" }
- name: Deploy patch
uses: ansible/[email protected]
with:
playbook: DetectWin32k.ps1
Was es tut:
main landet.Es beginnt mit einem einzigen Fehler in der Grafikengine. Ein Angreifer findet einen Weg, eine Race-Condition im Windows-Kernel auszunutzen, wie oben gezeigt, entkommt den Abwehrmaßnahmen und führt Code aus der Ferne aus. Das ist CVE-2025-55226. Aber die eigentliche Gefahr entfaltet sich, wenn sie ihn mit CVE-2025-54918 kombinieren, einer Schwachstelle in der NTLM-Authentifizierung. Plötzlich sind sie nicht nur drin – sie haben die Kontrolle.
Was als Grafikfehler begann, wird zu einer vollwertigen Privilegieneskalation, die ihnen SYSTEM-Zugriff verschafft. Diese Ereigniskette ist nicht nur theoretisch. Sie ist eine Erinnerung daran, dass Schwachstellen in heutigen hybriden Umgebungen selten isoliert existieren.
Veröffentlicht: 9. September 2025 (Patch Tuesday)
CVSS v3.1 Score: 8.8 (Hoch)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE: CWE‑287 – Fehlerhafte Authentifizierung
Betroffene Komponente: Windows NTLM (New Technology LAN Manager)
Der Fehler ist ein Logikfehler in der Art und Weise, wie NTLM Authentifizierungsdaten validiert. Ein Angreifer, der einen Host über ein Netzwerk erreichen kann, selbst mit minimalen Berechtigungen, kann das System dazu bringen, SYSTEM‑Level-Rechte zu gewähren. Das bedeutet, dass ein Angreifer nach der Kompromittierung einer Workstation oder eines Domänencontrollers Anwendungen installieren, vertrauliche Dateien exfiltrieren und neue Administratorkonten erstellen kann – im Grunde die volle Kontrolle über das Ziel.
Die Schwachstelle folgt einem wachsenden Muster im Jahr 2025: Zwei andere NTLM-Fehler wurden bereits gemeldet (CVE‑2025‑53778, CVE‑2025‑21311). Microsofts Patch für dieses Problem behebt eine falsche Vergleichsroutine, die bestimmte Hash-Werte fälschlicherweise akzeptiert.
# Find hosts with vulnerable NTLM settings
$target = "dc01.company.local"
Invoke-Command -ComputerName $target -ScriptBlock {
Get-WmiObject -Class Win32_OperatingSystem |
Select-Object CSName, Version, BuildNumber
} | Out-File -FilePath C:\temp\nlm_detection.txt
# Check the NTLM policy value
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon" |
Select-Object "LmCompatibilityLevel"
# Export to CSV for quick review
$report = @()
foreach ($item in Get-WmiObject -Class Win32_Service | Where { $_.Name -eq "netlogon"}) {
$report += [pscustomobject]@{
Service = $item.Name
LmCompat = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon").LmCompatibilityLevel
}
}
$report | Export-Csv -Path C:\temp\nlm_report.csv -NoTypeInformation
Das Skript zieht den aktuellen OS-Build, überprüft, ob der Netlogon-Schlüssel auf einen von Microsoft empfohlenen Wert (3) gesetzt ist, und schreibt die Ergebnisse in eine einfach zu konsumierende CSV.
---
- name: Patch NTLM for Windows servers
hosts: windows_dc01, windows_dc02, windows_dc03
gather_facts: true
tasks:
- name: Enable Netlogon compatibility level
win_regedit:
path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon
key: LmCompatibilityLevel
value: 3
datatype: dword
- name: Install Microsoft patch KB5000000
win_updates:
category_name: Security
search_keyword: KB5000000
reboot_after: true
Stellen Sie das Playbook auf allen Domänencontrollern bereit. Die Aufgabe stellt sicher, dass die Richtlinie korrekt gesetzt ist und installiert das neueste Sicherheitsupdate, sodass der Logikfehler nicht mehr ausnutzbar ist.
Mit Responder und Impacket können Sie einen realen NTLM-Relay-Angriff nachahmen:
secretsdump.py erfasst Authentifizierungsdaten.# Start Responder on the attack box
responder -i eth0 -f
# Dump credentials from the victim
python3 impacket/secretsdump.py <victim-ip> <domain-admin-username>
# Replay hash to the target
python3 impacket/ntlmrelay.py <victim-ip> <target-ip>
Führen Sie das Skript in einer kontrollierten Umgebung aus und validieren Sie, dass Sie SYSTEM-Zugriff erhalten.
Fügen Sie Ihrer Pipeline eine NTLM-Härtungsaufgabe hinzu:
- name: Validate Netlogon compatibility level
win_regedit:
path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon
key: LmCompatibilityLevel
value: 3
datatype: dword
state: present
# Trigger when new patches are applied
- name: Reboot if required and restart services
win_reboot:
reboot_timeout_sec: 120
Die Aufgabe wird automatisch ausgeführt, sobald die Pipeline durch einen neuen Patch-Build ausgelöst wird.
Erstellen Sie einen Alarm, der ausgelöst wird, wenn sich ein Host mit NTLM-Authentifizierung anmeldet, die dem anfälligen Hash-Muster entspricht:
input {
beats {
type => "winlogbeat"
}
}
filter {
if [event_id] == "4624" and [logon_type] =~ /NTLM/ {
mutate {
add_field => { "[ntlm_match]" => "true" }
}
}
}
output {
elasticsearch {
hosts => ["es.company.local"]
index => "ntlm_audit"
}
}
Der Alarm geht an Sentinel zur Visualisierung, sodass die Zuständigen sehen können, dass die Behebung angewendet wird und überwacht wird.
Sicherheit bedeutet nicht nur das Patchen von Schwachstellen – es geht darum, zu verstehen, wie sie zusammenhängen, wie sie sich entwickeln und wie sie auf Weisen bewaffnet werden können, die nicht sofort offensichtlich sind. Durch die Verkettung von CVE-2025-55226 und CVE-2025-54918 habe ich gezeigt, wie ein einzelner Fehler in einem Grafiktreiber die Tür zu einer vollständigen Systemkompromittierung öffnen kann. Aber noch wichtiger: Ich habe demonstriert, wie ein DevOps-Ingenieur nicht nur mit technischen Korrekturen, sondern auch mit Weitsicht, Automatisierung und Resilienz reagieren kann.