SignDrop: як захист Windows CLFS перетворили на повні права SYSTEM

Що сталося

У вівторок, 10 листопада 2026 року — того самого дня, коли Microsoft випустила планові оновлення безпеки за листопад — дослідник Абдельгамід Насері (відомий під псевдонімами MSNightmare, Nightmare Eclipse та Chaotic Eclipse) опублікував на GitHub експлойт під назвою SignDrop. Це локальна вразливість підвищення привілеїв (local privilege escalation) у драйвері Common Log File System (CLFS) — компоненті Windows, який працює в режимі ядра.

Ключова особливість SignDrop у тому, що він б'є не по самому CLFS, а по захисному механізму аутентифікації лог-файлів, який Microsoft додала рівно для того, щоб зупинити експлуатацію CLFS. «Все, що зробила Microsoft, зроблено правильно, але сама логіка дозволяє зловживання», — написав дослідник у технічному розборі.

Станом на момент публікації Microsoft не підтвердила вразливість, не призначила їй CVE-ідентифікатор і не випустила виправлення. Експлойт протестовано на Windows 11 26H2, експериментальній збірці Windows 11 26H2 та Windows Server 2025. За оцінкою самого дослідника, уразливими можуть бути близько 80% інсталяцій Windows у світі.

Що таке CLFS і чому його постійно атакують

Common Log File System — це вбудована в Windows підсистема логування, яка зберігає записи у структурованих «контейнерах» і «лог-файлах». Вона працює в режимі ядра (clfs.sys) і парсить складні бінарні структури — саме тому історично стала улюбленою мішенню для атак на підвищення привілеїв.

Масштаб проблеми показовий: у каталозі Known Exploited Vulnerabilities (KEV) американського агентства CISA числиться десять вразливостей CLFS, які, як підтверджено, експлуатувалися в реальних атаках. Одна з них — CVE-2025-29824 — у квітні 2025 року використовувалася в кампаніях програм-вимагачів: зловмисники підвищували привілеї через CLFS, скидали системні кущі реєстру (SAM, SYSTEM, SECURITY) і створювали власного користувача з правами адміністратора.

Історія експлуатації CLFS багата на конкретні епізоди. Атаку з CVE-2025-29824 зафіксував Microsoft Threat Intelligence Center — це був рідкісний випадок, коли 0-day підвищення привілеїв використали саме оператори програм-вимагачів (за даними Symantec, з цією активністю пов'язували угруповання Play). Роком раніше, у 2024-му, з експлуатацією CLFS-вразливості CVE-2024-26169 пов'язували угруповання Black Basta, а у 2025-му ще одна активно експлуатована вада CVE-2025-32701 (use-after-free) дозволяла підвищити привілеї до рівня SYSTEM. Спільна риса всіх цих атак — вони перетворюють скромний обліковий запис звичайного користувача на повний контроль над хостом, після чого вимикають засоби захисту та розгортають основне корисне навантаження.

Чому CLFS такий «вдячний» для експлуатації? Драйвер змушений парсувати дані, які частково контролює звичайний користувач, — лог-файли можна створювати без жодних спеціальних прав. Найменша помилка в розборі структури перетворюється на пошкодження пам'яті ядра, а звідти — на виконання коду з правами SYSTEM.

Як Microsoft намагалася закрити CLFS

Щоб приборкати цю атакувальну поверхню, з 28 жовтня 2025 року Microsoft почала розгортати механізм аутентифікації лог-файлів CLFS у релізному каналі — для Windows 11 25H2, 26H1 та Windows Server 2025.

Суть захисту така: до кожного лог-файлу додається код аутентифікації повідомлень на основі хешу (HMAC), побудований з даних логу та ключа, унікального для кожної машини. Драйвер після цього парсить лише ті лог-файли, які сам записав, — а чужі чи підроблені відкидає. Поруч із кожним логом зберігається супровідний файл з розширенням .cnpf, що містить дані відновлення, і створюється він із тими самими атрибутами безпеки, що й оригінал.

Розгортання відбувалося у два етапи. Перші 90 днів система працює в режимі навчання (learning mode), збираючи інформацію про легітимні лог-файли. Після завершення цього періоду драйвер автоматично переходить у режим примусового захисту (enforcement mode), у якому кожен лог-файл повинен мати дійсний код аутентифікації.

Саме цей захисний механізм, покликаний звести нанівець експлуатацію CLFS, і став мішенню SignDrop. Після впровадження мітігації кількість публічно експлуатованих вразливостей CLFS різко впала — але, як з'ясувалося, сама мітігація принесла нову вразливість.

Технічний розбір: як працює SignDrop

Вразливість криється в тому, як clfs.sys обробляє створення аутентифікаційного файлу .cnpf. Ключову поведінку Насері описує так: якщо новий асоційований файл-контейнер порожній, CLFS спробує підписати його незалежно від того, чи існує файл підпису.

Ланцюжок експлуатації виглядає так:

1. Підготовка. Звичайний користувач (без адміністративних прав) створює CLFS-лог і контейнер із шляхами, які сам контролює.
2. Примус до відкриття. Відкриття лог-файлу не потребує жодних спеціальних прапорців у виклику NtCreateFile — достатньо вказати правильний шлях. Тому атакуючий «примушує» привілейований процес відкрити підготовлений лог.
3. Зміна контексту. Оскільки лог відкриває вже не початковий користувач, а привілейований процес, супровідний файл створюється від імені цього процесу — тобто з правами SYSTEM.
4. Перенаправлення. За допомогою символьних посилань Object Manager зловмисник перенаправляє створення .cnpf-файлу в потрібне йому місце.
5. Запис. Файл .cnpf успадковує DACL (список контролю доступу) оригінального логу, тож звичайний користувач отримує право записувати в нього. Результат — файл, створений як SYSTEM, у який може писати звичайний користувач.
6. Ескалація. Це поєднується в ланцюжок, який завершується запуском оболонки з правами SYSTEM.

Технічна деталь, яка робить атаку можливою: CLFS перевіряє права доступу коректно лише тоді, коли процес створює власні лог-файли — у цьому випадку вказується прапорець OBJ_FORCE_ACCESS_CHECK, і нові об'єкти залишаються в контексті процесу, що їх створив. Але коли лог-файл має асоційований контейнер, відкриття оригінального файлу автоматично відкриває й пов'язаний — і саме в цей момент контекст безпеки «з'їжджає» на привілейований процес. Тому підписаний файл створюється не від імені користувача, який підготував лог, а від імені того, хто його відкрив.

Windows Defender — мимовільний співучасник

Особливо іронічний елемент SignDrop — вибір «привілейованого процесу». У опублікованому коді цю роль виконує служба Windows Defender (MsMpEng).

Атакуючий викликає RPC-інтерфейс оновлення сигнатур ServerMpUpdateEngineSignature. Defender у контексті свого антивірусного рушія відкриває підготовлений CLFS-контейнер, іде за шляхом, записаним у контейнері, відкриває асоційований файл — і, якщо файл підпису відсутній, створює його з правами SYSTEM.

Це означає, що механізм самої системи безпеки використовується проти неї ж. Як зауважує дослідник, той самий прийом можна застосувати проти будь-якого антивірусного рушія чи EDR: довільне створення файлів відбувається «в контексті» самого захисного процесу, тож з погляду його kernel-драйверів запит виглядає як легітимний і проходить повз механізми самозахисту (self-defense / tamper protection). Це робить вразливість унікальною — вона дозволяє, зокрема, вимикати антивіруси та EDR.

Хто вразливий і як це перевірити

Важливе застереження: SignDrop — це локальне підвищення привілеїв. Тобто зловмиснику спершу потрібен доступ до машини з правами звичайного користувача — через фішинг, викрадені облікові дані, вразливість віддаленого виконання коду чи інший вектор. SignDrop перетворює такий «обмежений» доступ на повний контроль над системою.

Перевірити, чи потрапляє ваша система в заявлену зону ураження, можна через реєстр. Відкрийте гілку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication

і подивіться на значення параметра Mode:

• 0 (примусовий режим) або 1 (режим навчання) — за твердженням дослідника, система вразлива;
• 2 або 3 — мітігацію вимкнено, і система виходить за межі заявленої атаки.

Оскільки через ~90 днів після встановлення система автоматично переходить з режиму навчання в режим примусового захисту, типова конфігурація «усталених» інсталяцій — саме та, на яку націлений експлойт. Насері формулює це прямо: «ви загалом уразливі, якщо вашій інсталяції Windows понад 90 днів», і додає з іронією, що «можна сміливо припустити, що кожен, хто це читає, — уразливий». Практичний наслідок для адміністраторів: якщо значення Mode на ваших машинах — 0 або 1, варто виходити з того, що система потрапляє в заявлену зону ураження, і готуватися до позачергового оновлення.

Чому вимикати захист — погана ідея

Формально вимкнення мітігації (значення Mode 2 або 3) прибирає шлях атаки SignDrop. Але і сам дослідник, і документація Microsoft застерігають від цього: вимкнення змушує CLFS знову парсувати неперевірені лог-файли, відкриваючи ті самі вразливості пошкодження пам'яті, від яких захист і мав рятувати.

Інакше кажучи, вибір стоїть між двома поганими варіантами, і «вимкнути захист» — не рішення. Насері підсумовує: «наразі, на жаль, вимкнення мітігації наражає вашу машину на вразливості пошкодження пам'яті, оскільки CLFS досі погано обробляє лог-файли — саме тому ця мітігація взагалі існує. Тож поки що єдиний вихід — чекати патч від Microsoft».

Як захиститися

Оскільки офіційного виправлення ще немає, практичні кроки зводяться до зниження ризику на рівні процесів і моніторингу.

1. Стежте за MSRC. Офіційне місце, де з'явиться відповідь Microsoft, — Security Update Guide (msrc.microsoft.com/update-guide). Щойно вийде патч — встановлюйте його позачергово, не чекаючи планового циклу оновлень.

1. Зменшіть поверхню локального доступу. Оскільки експлойт потребує облікового запису звичайного користувача, критично обмежити можливості атакуючого отримати такий доступ: дотримуйтесь принципу найменших привілеїв, використовуйте багатофакторну автентифікацію, навчайте персонал розпізнавати фішинг. Детальніше про базову гігієну — у нашому матеріалі «Кібербезпека: навчання».

1. Не вимикайте мітігацію CLFS. Як пояснено вище, вимкнення аутентифікації лог-файлів (Mode 2/3) відкриває старі вразливості пошкодження пам'яті. Залиште значення 0 або 1.

1. Моніторте аномалії. Звертайте увагу на несподівані виклики RPC-інтерфейсів оновлення сигнатур, створення .cnpf-файлів у нетипових місцях та спроби маніпуляцій із символьними посиланнями Object Manager. Для досвідчених команд це можна покрити правилами EDR/SIEM.

1. Сегментуйте та оновлюйте. Тримайте системи в актуальному стані (останні кумулятивні оновлення, зокрема листопадові, які Microsoft випустила 10 листопада) і сегментуйте мережу так, щоб компрометація однієї робочої станції не відкривала шлях до критичних серверів.

Висновок

SignDrop — показовий приклад того, як навіть продуманий захисний механізм може стати вектором атаки. Microsoft зробила CLFS помітно безпечнішим, але в самій логіці створення аутентифікаційних файлів залишився зазор, який дозволяє привілейованому процесу створювати файл від імені SYSTEM у місці, контрольованому атакуючим.

Наразі вразливість не має ні CVE, ні патча, але експлойт уже публічний — а це означає, що «вікно» між публікацією PoC і появою атак у дикій природі може виявитися коротким. Для українських організацій, де Windows домінує і на робочих станціях, і на серверах, головне зараз — не панікувати, але й не відкладати: стежити за MSRC, тримати системи оновленими та посилити контроль локального доступу. Щойно Microsoft випустить виправлення — це стане позачерговим пріоритетом для кожної команди безпеки.