mrk336/from-foothold-to-domain-admin-weaponizing-cve-2025-54918-in-real-world-devopsExploitation simulée et atténuation de CVE-2025-54918 (vulnérabilité NTLM Windows). Inclut des scripts de détection, le correctif Ansible et le durcissement CI/CD. Montre l'escalade de privilèges d'un accès de bas niveau à SYSTEM dans des environnements cloud hybrides.
Exploitation simulée et correction de CVE-2025-54918 (faille NTLM Windows). Comprend des scripts de détection, du patching Ansible et du durcissement CI/CD. Démontre l'escalade de privilèges d'un accès de bas niveau à SYSTEM dans des environnements cloud hybrides.
Par Mark Mallia
Dans les environnements cloud hybrides d'aujourd'hui, la frontière entre interaction utilisateur et compromission système est plus mince que jamais. Cet article explore une chaîne d'attaque réelle qui commence par une faille graphique apparemment anodine, CVE-2025-55226, une condition de course dans le noyau graphique Windows, et escalade jusqu'au contrôle complet du niveau SYSTEM via CVE-2025-54918, un contournement critique de l'authentification NTLM.
Ensemble, ces vulnérabilités montrent comment les attaquants peuvent passer de l'exécution de code à distance à l'escalade de privilèges en seulement quelques étapes. Mais plus important encore, elles illustrent comment un Ingénieur DevOps Senior peut détecter, atténuer et surveiller ces menaces en utilisant l'automatisation, l'intégration CI/CD et l'infrastructure en tant que code.
Date de publication : 16 septembre 2025 (Patch Tuesday)
Le dernier bulletin de sécurité de Microsoft identifie une faille sérieuse dans win32k.sys, le noyau graphique principal utilisé à la fois par les éditions de bureau et serveur de Windows. La faiblesse est une condition de course qui permet à un attaquant de déclencher une Exécution de Code à Distance (RCE) sur tout système où le pilote vulnérable est en cours d'exécution. Étant donné que le pilote se trouve au cœur de l'interface GDI (Graphics Device Interface), il peut être abusé pour exécuter du code arbitraire en mode noyau – un niveau de privilège qui peut compromettre toute la machine.
Pourquoi c'est important :
- Il cible un sous-système central qui alimente chaque interface utilisateur graphique, des ordinateurs de bureau ordinaires aux serveurs haute performance.
- Un correctif publié mardi dernier fournit une solution immédiate, mais seulement si les administrateurs savent comment le découvrir, le déployer et le surveiller à temps.
L'extrait suivant récupère la version actuelle de win32k.sys depuis le registre, la compare à la version corrigée, et enregistre les discordances dans un fichier CSV importable dans Excel ou Tableau.
# DetectWin32k.ps1 – vérifie la présence de win32k.sys vulnérable
$target = 'Microsoft-Windows-GraphicsKernel'
$patchVersion = '6.0.22.7' # Version corrigée attendue
$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 "vulnérable: $currentVer (réel=$fileVersion, attendu=$patchVersion)" | Out-File -Encoding ascii .\report.csv
}
Ce qu'il fait :
Le fichier YAML suivant indique à Ansible d'appliquer la mise à jour de win32k.sys et de redémarrer le service GDI sur tous les hôtes cibles.
---
- name: Déployer le correctif du noyau graphique Windows
hosts: windows_servers
gather_facts: yes
tasks:
- name: Copier le nouveau win32k.sys
copy:
src: /tmp/patches/win32k.sys
dest: C:\Windows\System32\
mode: '0644'
force: yes
- name: Redémarrer le service GDI
win_service:
name: w32k
state: restarted
Ce qu'il fait :
windows_servers).Créez un panneau simple qui visualise l'utilisation de la table d'objets GDI au fil du temps.
# grafana-dashboard.yml
apiVersion: 1
dashboard:
title: “Utilisation GDI”
panels:
- name: “Objets en cours d'utilisation”
type: graph
targets:
- query: "SELECT timestamp, gdi_objects FROM win32k_stats WHERE $__timeFilter()"
Ce qu'il fait :
win32k_stats) et les affiche sur un panneau Grafana. Vous pouvez configurer des alertes lorsque l'utilisation dépasse un seuil – un indicateur précoce de régressions du pilote.Ajoutez une étape de test à votre pipeline Jenkins ou GitHub Actions qui exerce le correctif en fuzzant win32k.sys avec un outil léger (par exemple, wdfuzz).
# .github/workflows/cve55226.yml
name: CI CVE‑2025‑55226
on:
push:
branches:
- main
jobs:
test_et_deploiement:
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Exécuter le fuzzer
run: |
wdfuzz.exe -t win32k.sys -c config.yaml
if ($LASTEXITCODE -eq 0) { Write-Host "Fuzz réussi" }
- name: Déployer le correctif
uses: ansible/[email protected]
with:
playbook: DetectWin32k.ps1
Ce qu'il fait :
main.Tout commence par une seule faille dans le moteur graphique. Un attaquant trouve un moyen d'exploiter une condition de course dans le noyau Windows comme démontré ci-dessus, contournant les défenses et exécutant du code à distance. C'est CVE-2025-55226. Mais le véritable danger se dévoile lorsqu'il l'associe à CVE-2025-54918, une faiblesse dans l'authentification NTLM. Soudain, il n'est pas seulement entré – il a le contrôle.
Ce qui a commencé comme un bug graphique devient une escalade de privilèges à part entière, lui donnant un accès de niveau SYSTEM. Cet enchaînement d'événements n'est pas seulement théorique. C'est un rappel que dans les environnements hybrides d'aujourd'hui, les vulnérabilités existent rarement de manière isolée.
Publié le : 9 septembre 2025 (Patch Tuesday)
Score CVSS v3.1 : 8.8 (Élevé)
Vecteur : CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE : CWE‑287 – Authentification incorrecte
Composant affecté : NTLM Windows (New Technology LAN Manager)
La faille est une erreur de logique dans la manière dont NTLM valide les données d'authentification. Un attaquant pouvant accéder à un hôte via un réseau, même avec des privilèges minimaux, peut tromper le système pour lui accorder des droits de niveau SYSTEM. Cela signifie qu'après avoir compromis une station de travail ou un contrôleur de domaine, un adversaire peut installer des applications, exfiltrer des fichiers confidentiels et créer de nouveaux comptes administrateur – essentiellement un contrôle total de la cible.
La vulnérabilité s'inscrit dans une tendance croissante en 2025 : deux autres bugs NTLM ont déjà été signalés (CVE‑2025‑53778, CVE‑2025‑21311). Le correctif de Microsoft pour ce problème corrige une routine de comparaison incorrecte qui acceptait certaines valeurs de hachage de manière erronée.
# Trouver les hôtes avec des paramètres NTLM vulnérables
$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
# Vérifier la valeur de la politique NTLM
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon" |
Select-Object "LmCompatibilityLevel"
# Exporter vers CSV pour une révision rapide
$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
Le script récupère la version actuelle du système d'exploitation, vérifie que la clé Netlogon est définie sur une valeur recommandée par Microsoft (3), et écrit les résultats dans un fichier CSV facile à consommer.
---
- name: Corriger NTLM pour les serveurs Windows
hosts: windows_dc01, windows_dc02, windows_dc03
gather_facts: true
tasks:
- name: Activer le niveau de compatibilité Netlogon
win_regedit:
path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon
key: LmCompatibilityLevel
value: 3
datatype: dword
- name: Installer le correctif Microsoft KB5000000
win_updates:
category_name: Security
search_keyword: KB5000000
reboot_after: true
Déployez le playbook sur tous les contrôleurs de domaine. La tâche garantit que la politique est correctement définie et installe la dernière mise à jour de sécurité, de sorte que la même faille logique ne soit plus exploitable.
En utilisant Responder et Impacket, vous pouvez imiter une attaque de relais NTLM réelle :
secretsdump.py d'Impacket capture les données d'authentification.# Démarrer Responder sur la machine d'attaque
responder -i eth0 -f
# Extraire les identifiants de la victime
python3 impacket/secretsdump.py <ip-victime> <nom-utilisateur-admin-domaine>
# Rejouer le hachage vers la cible
python3 impacket/ntlmrelay.py <ip-victime> <ip-cible>
Exécutez le script dans un environnement contrôlé et validez que vous obtenez un accès de niveau SYSTEM.
Ajoutez une tâche de durcissement NTLM à votre pipeline :
- name: Valider le niveau de compatibilité Netlogon
win_regedit:
path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon
key: LmCompatibilityLevel
value: 3
datatype: dword
state: present
# Déclenché lorsque de nouveaux correctifs sont appliqués
- name: Redémarrer si nécessaire et redémarrer les services
win_reboot:
reboot_timeout_sec: 120
La tâche s'exécute automatiquement chaque fois que le pipeline est déclenché par une nouvelle version de correctif.
Créez une alerte qui se déclenche lorsqu'un hôte se connecte avec une authentification NTLM correspondant au modèle de hachage vulnérable :
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'alerte est envoyée à Sentinel pour visualisation, permettant aux responsables de voir que le correctif a été appliqué et est surveillé.
La sécurité ne consiste pas seulement à corriger des vulnérabilités, mais à comprendre comment elles se connectent, comment elles évoluent et comment elles peuvent être utilisées comme armes d'une manière qui n'est pas immédiatement évidente. En enchaînant CVE-2025-55226 et CVE-2025-54918, j'ai montré comment une seule faille dans un pilote graphique peut ouvrir la porte à une compromission complète du système. Mais plus important encore, j'ai démontré comment un ingénieur DevOps peut répondre non seulement avec des correctifs techniques, mais aussi avec prévoyance, automatisation et résilience.