Одним із найнебезпечніших моментів квітня стала публікація робочого експлойта для Windows Defender.
CISA додала CVE-2026-33825 до каталогу Known Exploited Vulnerabilities після публічного випуску робочого proof-of-concept. Організаціям, які використовують Microsoft Defender Antimalware Platform версій до 4.18.26020.6, слід негайно встановити виправлення.
Передумови: межа терпіння дослідника
2 квітня 2026 року дослідник безпеки, який діє під псевдонімом Chaotic Eclipse, публічно оприлюднив BlueHammer. Це повністю функціональний proof-of-concept експлойта для локального підвищення привілеїв у Windows. Публікація не була запланована, скоординована або проведена в межах будь-якого процесу відповідального розкриття. Як стверджується, зрештою це стало проявом розчарування процесом повідомлення про вразливості в Microsoft.
Наслідки були миттєвими. BlueHammer з’явився на GitHub і форумах із безпеки. Його швидко проаналізували, адаптували для практичного використання в атаках і додали до інструментарію зловмисників. Протягом двох тижнів після початкової публікації Chaotic Eclipse оприлюднив ще дві вразливості Microsoft Defender під назвами RedSun і UnDefend. Це суттєво подовжило період підвищеного ризику.
Особливу увагу в BlueHammer привертає його витонченість. Експлойт поєднує кілька довірених підсистем Windows у такий спосіб, що традиційне виявлення стає вкрай складним.
CVE-2026-33825: Microsoft Defender Antimalware Platform – підвищення привілеїв
Локальний зловмисник із низькими привілеями може підвищити їх до рівня NT AUTHORITY\SYSTEM. Для цього він зловживає довіреним процесом обробки файлів у Microsoft Defender і отримує довільний дескриптор читання до бази даних SAM. Уражені версії: Microsoft Defender Antimalware Platform до 4.18.26020.6.
Ланцюжок атаки: крок за кроком
BlueHammer найкраще розглядати як багатоетапний експлойт, який зловживає неявною довірою Windows до власних процесів безпеки. Кожен етап розроблено так, щоб він виглядав довіреним. Здебільшого він таким і є, принаймні з погляду ядра.
Крок 1: розвідка щодо оновлення
Експлойт починає роботу із завантаження довіреного вмісту оновлень Microsoft Defender із CDN Microsoft. Це створює непідозрілий контекст виконання. Завдяки цьому наступні етапи виглядають як частина звичайного процесу оновлення сигнатур.
Крок 2: запуск Defender і створення тіньової копії
Тестовий файл EICAR розміщується в системі, щоб спровокувати активність сканування Defender. Одночасно розміщується RstrtMgr.dll із batch oplock, який використовується як часовий маркер. Робочий потік відстежує появу нових об’єктів HarddiskVolumeShadowCopy. Це підтверджує, що Defender увійшов у цільовий робочий процес і новий знімок VSS готовий.
Крок 3: призупинення роботи Defender через Cloud Files API
Робочий каталог реєструється як підроблений корінь хмарної синхронізації за допомогою CfRegisterSyncRoot і CfConnectSyncRoot. Ці API зазвичай використовуються OneDrive та подібними сервісами. Усередині розміщується файл .lock. Коли Defender звертається до нього, спрацьовує callback CfCallbackFetchPlaceHolders. Він перевіряє, що викликом керує служба WinDefend, і утримує Defender у призупиненому стані за допомогою скоординованого batch oplock. Так створюється точне часове вікно.
Крок 4: Гонитва TOCTOU – перенаправлення до бази даних SAM
Поки Defender перебуває в призупиненому стані, експлойт запускає механізм оновлення Defender за допомогою довірених файлів. Коли Defender створює новий каталог визначень і обробляє mpasbase.vdm, експлуатується стан гонитви Time-of-Check to Time-of-Use (TOCTOU). Уже визначений шлях підміняється так, щоб Defender відкрив базу даних SAM усередині тіньової копії замість очікуваного файлу оновлення.
Крок 5: витягування облікових даних із SAM
Отримавши дескриптор читання до куща SAM, експлойт реконструює ключ завантаження Windows із HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Після цього він розшифровує матеріал шифрування паролів SAM і відновлює локальні NTLM-хеші.
Крок 6: запуск SYSTEM shell і замітання слідів
Відновлені NTLM-хеші використовуються для тимчасової зміни пароля облікового запису локального адміністратора. Тимчасова служба Windows повторно запускає PoC від імені NT AUTHORITY\SYSTEM. У поточному сеансі користувача запускається консоль SYSTEM. Після цього початковий пароль відновлюється за допомогою відновленого хешу. Облікові дані користувача залишаються незмінними, а атака – значною мірою непомітною.
Чому традиційне виявлення не спрацьовує
Небезпека BlueHammer полягає в тому, що на кожному етапі він використовує довірені компоненти Windows. Експлойт не записує нові шкідливі бінарні файли. Він не викликає явно підозрілі API ізольовано. Натомість він зловживає неявною довірою, яку операційна система надає власним компонентам безпеки.
Механізм оновлення Defender, служба Volume Shadow Copy Service і Cloud Files API є довіреними, підписаними компонентами. Їхня робота з підвищеними привілеями є очікуваною. Організовуючи ланцюжок легітимних взаємодій, BlueHammer створює шлях для підвищення привілеїв. Статичні інструменти аналізу та традиційні поведінкові правила погано пристосовані для його виявлення.
Складна проблема: три вразливості за два тижні
Якби історія обмежувалася лише BlueHammer, цього вже було б достатньо для серйозного занепокоєння. Але протягом 14 днів після публікації BlueHammer Chaotic Eclipse оприлюднив ще дві вразливості Defender: RedSun і UnDefened. Така швидка послідовність створила незвичну ситуацію. Захисники намагалися терміново закрити одну активно експлуатовану вразливість, тоді як ще два публічні експлойти вже поширювалися.
Ця схема відображає відомий, але недооцінений ризик у відповідальному розкритті вразливостей. Коли дослідники розчаровуються строками реагування вендора, неформальні норми скоординованого розкриття можуть швидко руйнуватися. У результаті виникає асиметричне інформаційне середовище. Зловмисники одразу отримують доступ до робочих експлойтів, тоді як команди безпеки все ще оцінюють вплив.
Пом’якшення ризику
Microsoft Defender Antimalware Platform слід оновити до версії, новішої за 4.18.26030.3011. Це оновлення постачається через Windows Update і оновлення платформи Microsoft Defender.
Для організацій із середовищами оновлення, керованими через WSUS або SCCM, слід визначити це оновлення платформи як пріоритетне для прискореного розгортання. Не варто покладатися лише на перевірки оновлень сигнатур. Ураженим компонентом є версія платформи Defender, а не база визначень.
Слід відстежувати індикатори компрометації, зокрема неочікувані події створення тіньових копій томів, незвичну взаємодію процесів із VSS, а також будь-які попередження про локальне підвищення привілеїв від платформ виявлення на кінцевих пристроях.
Щоб посилити виявлення та реагування на кінцевих пристроях, можна використовувати Cynet. XDR платформа допомагає командам безпеки централізовано аналізувати події на рівнях endpoint, network, identity та cloud, а також автоматизувати розслідування й реагування на загрози. Якщо ви бажаєте отримати безкоштовну пробну версію Cynet, будь ласка, залиште свої контактні дані у формі нижче і наша команда зв’яжеться з вами.
