mrk336/from-foothold-to-domain-admin-weaponizing-cve-2025-54918-in-real-world-devopsСимулированная эксплуатация и устранение уязвимости CVE-2025-54918 (недостаток Windows NTLM). Включает скрипты обнаружения, исправление с помощью Ansible и усиление CI/CD. Демонстрирует повышение привилегий от низкоуровневого доступа до SYSTEM в гибридных облачных средах.
Симулированная эксплуатация и митигирование CVE-2025-54918 (уязвимость Windows NTLM). Включает скрипты обнаружения, Ansible-патчинг и усиление CI/CD. Демонстрирует повышение привилегий от низкоуровневого доступа до SYSTEM в гибридных облачных средах.
Автор: Mark Mallia
В современных гибридных облачных средах грань между действиями пользователя и компрометацией системы тоньше, чем когда-либо. В этой статье рассматривается реальная цепочка атак, которая начинается с, казалось бы, безобидного графического дефекта CVE-2025-55226 (состояние гонки в графическом ядре Windows) и приводит к полному контролю уровня SYSTEM через CVE-2025-54918 — критический обход аутентификации NTLM.
Вместе эти уязвимости показывают, как атакующие могут перейти от удаленного выполнения кода к повышению привилегий всего за несколько шагов. Но, что более важно, они демонстрируют, как Senior DevOps-инженер может обнаруживать, смягчать и отслеживать такие угрозы с помощью автоматизации, интеграции CI/CD и инфраструктуры как кода.
Дата выпуска: 16 сентября 2025 г. (вторник обновлений)
В последнем бюллетене безопасности Microsoft указана серьезная уязвимость в win32k.sys — ядре графической подсистемы, используемом как в настольных, так и в серверных выпусках Windows. Слабость представляет собой состояние гонки, которое позволяет атакующему вызвать удаленное выполнение кода (RCE) на любой системе, где работает уязвимый драйвер. Поскольку драйвер находится в центре GDI (Graphics Device Interface), его можно использовать для выполнения произвольного кода в режиме ядра — уровне привилегий, который может поставить под угрозу всю машину.
Почему это важно:
- Он затрагивает ключевую подсистему, обеспечивающую работу каждого графического интерфейса — от обычных офисных компьютеров до высокопроизводительных серверов.
- Выпущенный во вторник патч дает немедленное исправление, но только если администраторы знают, как вовремя его обнаружить, развернуть и отслеживать.
Следующий фрагмент получает текущую версию win32k.sys из реестра, сравнивает ее с пропатченной версией и записывает несовпадения в CSV-файл, который можно импортировать в Excel или 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
}
Что это делает:
Следующий YAML-файл указывает Ansible применить обновление win32k.sys и перезапустить службу GDI на всех целевых хостах.
---
- 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
Что это делает:
windows_servers).Создайте простую панель, которая визуализирует использование таблицы объектов GDI с течением времени.
# 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()"
Что это делает:
win32k_stats) и отображает их на панели Grafana. Вы можете настроить оповещения на случай, когда использование превышает порог, — это ранний индикатор регрессий драйвера.Добавьте в конвейер Jenkins или GitHub Actions тестовый шаг, который проверяет обновление с помощью фаззинга win32k.sys легковесным инструментом (например, 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
Что это делает:
main.Все начинается с единственной ошибки в графическом движке. Атакующий находит способ эксплуатировать состояние гонки в ядре Windows, как показано выше, обходит защиту и удаленно выполняет код. Это CVE-2025-55226. Но настоящая опасность проявляется, когда она сочетается с CVE-2025-54918 — уязвимостью в аутентификации NTLM. Внезапно атакующий не просто проникает в систему — он получает контроль.
То, что начиналось как графическая ошибка, превращается в полноценное повышение привилегий и дает доступ уровня SYSTEM. Эта цепочка событий не просто теоретическая. Это напоминание о том, что в современных гибридных средах уязвимости редко существуют по отдельности.
Опубликовано: 9 сентября 2025 г. (вторник обновлений)
Оценка CVSS v3.1: 8.8 (высокая)
Вектор: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE: CWE‑287 – Неправильная аутентификация
Затронутый компонент: Windows NTLM (New Technology LAN Manager)
Ошибка заключается в логической погрешности проверки аутентификационных данных NTLM. Атакующий, способный подключиться к хосту по сети, даже с минимальными привилегиями, может обмануть систему и получить права уровня SYSTEM. Это означает, что после компрометации рабочей станции или контроллера домена злоумышленник может устанавливать приложения, похищать конфиденциальные файлы и создавать новые учетные записи администратора — по сути, полностью управлять целью.
Эта уязвимость является частью растущей тенденции 2025 года: уже сообщалось о двух других ошибках NTLM (CVE‑2025‑53778, CVE‑2025‑21311). Патч Microsoft для этой проблемы исправляет некорректную процедуру сравнения, которая ошибочно принимает определенные хэш-значения.
# 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
Скрипт получает текущую сборку ОС, проверяет, что ключ Netlogon имеет рекомендованное Microsoft значение (3), и записывает результаты в удобный для чтения 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
Разверните плейбук на всех контроллерах домена. Задача гарантирует правильную настройку политики и установку последнего обновления безопасности, чтобы та же логическая ошибка больше не была эксплуатируемой.
Используя Responder и Impacket, вы можете воспроизвести реальную NTLM relay-атаку:
secretsdump.py из Impacket захватывает аутентификационные данные.# 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>
Запустите скрипт в контролируемой среде и убедитесь, что вы получаете доступ уровня SYSTEM.
Добавьте задачу усиления безопасности NTLM в свой конвейер:
- 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
Задача выполняется автоматически при каждом запуске конвейера после сборки нового обновления.
Создайте оповещение, которое срабатывает, когда хост выполняет вход с аутентификацией NTLM, соответствующей уязвимому шаблону хэша:
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"
}
}
Оповещение попадает в Sentinel для визуализации, позволяя ответственным специалистам видеть, что исправление применено и находится под мониторингом.
Безопасность — это не только установка обновлений. Это понимание того, как уязвимости связаны, как они развиваются и как их можно превратить в оружие способами, которые не очевидны на первый взгляд. Связав CVE-2025-55226 и CVE-2025-54918, я показал, как единственная ошибка в графическом драйвере может открыть дверь к полной компрометации системы. Но, что более важно, я продемонстрировал, как DevOps-инженер может реагировать не только техническими исправлениями, но и предвидением, автоматизацией и устойчивостью.