mrk336/from-foothold-to-domain-admin-weaponizing-cve-2025-54918-in-real-world-devopsSfruttamento e mitigazione simulati di CVE-2025-54918 (vulnerabilità NTLM di Windows). Include script di rilevamento, patch Ansible e hardening CI/CD. Dimostra l'escalation dei privilegi da accesso di basso livello a SYSTEM in ambienti cloud ibridi.
Sfruttamento e mitigazione simulati di CVE-2025-54918 (vulnerabilità NTLM di Windows). Include script di rilevamento, applicazione di patch con Ansible e hardening CI/CD. Dimostra l'escalation dei privilegi da accesso di basso livello a SYSTEM in ambienti cloud ibridi.
Di Mark Mallia
Negli ambienti cloud ibridi di oggi, il confine tra interazione dell'utente e compromissione del sistema è più sottile che mai. Questo articolo esplora una catena di attacco reale che inizia con un difetto grafico apparentemente innocuo, CVE-2025-55226, una race condition nel kernel grafico di Windows, e scala fino al pieno controllo a livello SYSTEM tramite CVE-2025-54918, un bypass critico dell'autenticazione NTLM.
Insieme, queste vulnerabilità dimostrano come gli attaccanti possano passare dall'esecuzione remota di codice all'escalation dei privilegi in pochi passaggi. Ma, cosa più importante, mostrano come un Senior DevOps Engineer possa rilevare, mitigare e monitorare tali minacce usando automazione, integrazione CI/CD e infrastruttura come codice.
Pubblicata: 16 settembre 2025 (Patch Tuesday)
L'ultimo advisory di sicurezza di Microsoft identifica un grave difetto in win32k.sys, il kernel grafico centrale utilizzato sia dalle edizioni desktop sia da quelle server di Windows. La debolezza è una race condition che consente a un attaccante di innescare un'esecuzione remota di codice (RCE) su qualsiasi sistema in cui è in esecuzione il driver vulnerabile. Poiché il driver si trova al centro della GDI (Graphics Device Interface), può essere abusato per eseguire codice arbitrario in modalità kernel, un livello di privilegio che può compromettere l'intera macchina.
Perché è importante:
- Prende di mira un sottosistema centrale che alimenta ogni interfaccia grafica, dai normali computer da ufficio ai server ad alte prestazioni.
- Una patch rilasciata martedì fornisce un fix immediato, ma solo se gli amministratori sanno come scoprirla, distribuirla e monitorarla in tempo.
Il seguente frammento recupera la versione corrente di win32k.sys dal registro, la confronta con la versione patchata e registra le discrepanze in un file CSV che può essere importato in Excel o Tableau.
# 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
}
Cosa fa:
Il seguente file YAML indica ad Ansible di applicare l'aggiornamento di win32k.sys e di riavviare il servizio GDI su tutti gli host target.
---
- 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
Cosa fa:
windows_servers).Crea un pannello semplice che visualizza l'utilizzo della tabella degli oggetti GDI nel tempo.
# 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()"
Cosa fa:
win32k_stats) e le visualizza su un pannello Grafana. Puoi configurare avvisi quando l'utilizzo supera una soglia, un primo indicatore di regressioni del driver.Aggiungi uno step di test alla tua pipeline Jenkins o GitHub Actions che verifica la patch eseguendo fuzzing su win32k.sys con uno strumento leggero (ad es. wdfuzz).
# .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
Cosa fa:
main.Tutto inizia con un singolo difetto nel motore grafico. Un attaccante trova un modo per sfruttare una race condition nel kernel di Windows, come dimostrato sopra, superando le difese ed eseguendo codice da remoto. Questa è CVE-2025-55226. Ma il pericolo reale si manifesta quando la combina con CVE-2025-54918, una debolezza nell'autenticazione NTLM. Improvvisamente, non è solo dentro: ha il controllo.
Quello che è iniziato come un bug grafico diventa una vera e propria escalation dei privilegi, concedendo accesso a livello SYSTEM. Questa catena di eventi non è solo teorica. È un promemoria del fatto che negli ambienti ibridi di oggi le vulnerabilità raramente esistono in isolamento.
Pubblicata: 9 settembre 2025 (Patch Tuesday)
Punteggio CVSS v3.1: 8.8 (Alto)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE: CWE‑287 – Autenticazione non corretta
Componente interessata: Windows NTLM (New Technology LAN Manager)
Il difetto è un errore logico nel modo in cui NTLM valida i dati di autenticazione. Un attaccante che riesce a raggiungere un host sulla rete, anche con privilegi minimi, può ingannare il sistema facendogli concedere diritti a livello SYSTEM. Ciò significa che, dopo aver compromesso una workstation o un domain controller, un avversario può installare applicazioni, esfiltrare file riservati e creare nuovi account amministratore: in pratica, il pieno controllo del target.
La vulnerabilità fa parte di un pattern crescente nel 2025: sono già stati segnalati altri due bug NTLM (CVE‑2025‑53778, CVE‑2025‑21311). La patch di Microsoft per questo problema corregge una routine di confronto errata che accetta in modo scorretto determinati valori hash.
# 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
Lo script recupera la build corrente del sistema operativo, verifica che la chiave Netlogon sia impostata su un valore consigliato da Microsoft (3) e scrive i risultati in un CSV di facile consultazione.
---
- 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
Distribuisci il playbook su tutti i domain controller. L'attività garantisce che il criterio sia impostato correttamente e installa l'ultimo aggiornamento di sicurezza, così che lo stesso errore logico non sia più sfruttabile.
Usando Responder e Impacket puoi replicare un attacco NTLM relay reale:
secretsdump.py di Impacket cattura i dati di autenticazione.# 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>
Esegui lo script in un ambiente controllato e verifica di ottenere accesso a livello SYSTEM.
Aggiungi un'attività di hardening NTLM alla tua pipeline:
- 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
L'attività viene eseguita automaticamente ogni volta che la pipeline viene attivata da una nuova build della patch.
Crea un avviso che scatta quando un host accede con autenticazione NTLM che corrisponde al pattern di hash vulnerabile:
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"
}
}
L'avviso confluisce in Sentinel per la visualizzazione, consentendo ai reclutatori di vedere che il fix è stato applicato ed è monitorato.
La sicurezza non consiste solo nell'applicare patch alle vulnerabilità: significa capire come si collegano tra loro, come si evolvono e come possono essere armate in modi che non sono immediatamente evidenti. Concatenando CVE-2025-55226 e CVE-2025-54918, ho mostrato come un singolo difetto in un driver grafico possa aprire la porta alla compromissione totale del sistema. Ma, cosa più importante, ho dimostrato come un DevOps engineer possa rispondere non solo con fix tecnici, ma con lungimiranza, automazione e resilienza.