Февральский Patch Tuesday закрыл CVE-2026-21510 - CVSS 8.8, активная эксплуатация APT28, обход SmartScreen через .lnk-файлы. После публикации исследования Akamai я развернул стенд: Windows 10 21H2 до и после патча, Responder на атакующей машине, тот же weaponized .lnk. Код не выполнился - патч работает. Но Responder поймал Net-NTLMv2-хеш. Машина аутентифицировалась на моём сервере так, будто обновления не было. Точно такое же наблюдение сделал Маор Дахан из Akamai и зарепортил Microsoft. Так родился CVE-2026-32202 - zero-click уязвимость Windows Shell для кражи учётных данных, которую CISA добавила в каталог Known Exploited Vulnerabilities 29 апреля 2026 года с дедлайном на исправление до 12 мая.
Хронология: от CVE-2026-21510 к zero-click вектору CVE-2026-32202
Чтобы разобрать CVE-2026-32202, нужно размотать цепочку с января 2026 - именно тогда APT28 начала использовать связку из двух уязвимостей в кампании против Украины и стран ЕС.Январь 2026. По данным CERT-UA (через отчёт Akamai), APT28 (Fancy Bear / Forest Blizzard) запускает целевую кампанию. Атака строится на связке двух CVE:
- CVE-2026-21513 (MSHTML Framework, CVSS 8.8, CWE-693) - обход защитных механизмов MSHTML Framework. Неавторизованный атакующий получает bypass security features через сеть. Используется для обхода Mark of the Web и SmartScreen при обработке вредоносного контента.
- CVE-2026-21510 (Windows Shell, CVSS 8.8, CWE-693) - обход защитных механизмов Windows Shell. Вектор CVSS: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - полный компромисс конфиденциальности, целостности и доступности.
10 февраля 2026 (Patch Tuesday). Microsoft выпускает патчи для обеих CVE. CVE-2026-21510 - одна из шести активно эксплуатируемых zero-day, закрытых в этом обновлении. Патч добавил проверку SmartScreen для CPL-файлов, загружаемых через UNC-путь из LNK, и заблокировал вектор RCE.
Февраль–март 2026. Дахан и коллеги из Akamai тестируют февральский фикс. Ключевое наблюдение - цитирую Дахана (по данным The Register): «While testing the patch, we noticed something interesting: The victim machine was still authenticating to the attacker's server.» Патч устранил выполнение кода и обход SmartScreen, но не затронул механизм аутентификации. Windows Shell продолжал резолвить UNC-путь из .lnk и инициировать SMB-хендшейк на сервер атакующего.
14 апреля 2026 (Patch Tuesday). Microsoft публикует CVE-2026-32202 с CVSS 4.3 (MEDIUM). Описание из NVD: «Protection mechanism failure in Windows Shell allows an unauthorized attacker to perform spoofing over a network.» CWE-693 (Protection Mechanism Failure). В первой публикации индекс эксплуатируемости и CVSS-вектор были указаны неверно.
27 апреля 2026. Microsoft обновляет бюллетень: исправляет индекс эксплуатируемости, CVSS-вектор, добавляет флаг «Exploitation Detected».
29 апреля 2026. CISA добавляет CVE-2026-32202 в каталог KEV с дедлайном 12 мая для федеральных агентств.
Итог: неполный патч февраля превратил high-severity RCE (CVSS 8.8) в medium-severity spoofing (CVSS 4.3), но zero-click вектор кражи учётных данных остался. Стало безопаснее - но не безопасно.
Механика zero-click атаки: как Windows Shell обрабатывает LNK-файлы
Окно между path resolution и trust verification
Суть LNK-файл уязвимости - в порядке операций внутри Windows Shell.При встрече с ярлыком (.lnk) Windows Shell выполняет namespace parsing - разбор целевого пути, на который указывает ярлык. Если путь содержит UNC-ссылку (вида
\\attacker.com\share\payload.cpl), Shell пытается его резолвить. А резолвинг UNC-пути - это установка SMB-соединения с удалённым сервером.Критическая деталь: этот процесс происходит рано в цепочке обработки - до проверки доверия (trust verification), которую выполняет SmartScreen. По описанию Akamai, при вызове
ShellExecuteExW - API-функции, через которую Windows Shell обрабатывает объекты - UNC-путь резолвится и SMB-соединение инициируется ещё до того, как SmartScreen или MotW-проверки успевают вмешаться. Дахан описывает это как «gap between path resolution and trust verification».На практике последовательность такая:
- Атакующий создаёт .lnk-файл с целевым путём на UNC-ресурс под его контролем
- Файл доставляется жертве (фишинг, сетевая шара, USB)
- Жертва открывает папку, содержащую .lnk, в Windows Explorer
- Explorer автоматически парсит .lnk для отображения иконки и метаданных
- При парсинге Shell резолвит UNC-путь, инициирует SMB-соединение, отправляет NTLM-хендшейк
- SmartScreen не вмешивается - аутентификация произошла на этапе path resolution
Отличие от предшественника CVE-2026-21510: тот давал полноценный bypass SmartScreen защиты с последующим RCE. CVE-2026-32202 не позволяет выполнить код - только принуждает систему к аутентификации. Но принуждённая аутентификация в доменной среде с NTLM - это credential harvesting, а дальше relay или offline-подбор.
Почему CVSS 4.3 не отражает реальную опасность
CVSS-вектор CVE-2026-32202 по данным NVD:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N.| Компонент | Значение | Интерпретация |
|---|---|---|
| AV:N | Network | Атака через сеть |
| AC:L | Low | Низкая сложность эксплуатации |
| PR:N | None | Привилегии не требуются |
| UI:R | Required | Требуется действие пользователя |
| C:L | Low | Частичная утечка конфиденциальных данных |
| I:N | None | Целостность не нарушается |
| A:N | None | Доступность не нарушается |
UI:R - Microsoft в бюллетене формулирует: «Злоумышленнику необходимо отправить жертве вредоносный файл, который жертва должна будет запустить.» На практике (и это показали атаки APT28, и исследование Akamai) Windows обрабатывает .lnk автоматически при навигации в папку. «Запуск» здесь - открытие папки в Explorer, а не двойной клик по файлу. По документам UI:R, по факту - zero-click уязвимость Windows.
C:L (Low Confidentiality) тоже занижает картину. Утекает «только» Net-NTLMv2-хеш, но с ним можно:
- Провести NTLM relay на другие сервисы в домене (lateral movement через NTLM hash)
- Запустить offline-подбор пароля (
hashcat -m 5600или John the Ripper) - Аутентифицироваться от имени жертвы в системах, принимающих NTLM
NTLM coercion через Windows Shell: от UNC-пути до lateral movement
Что происходит на сетевом уровне
Когда Windows Shell резолвит UNC-путь из .lnk, ОС инициирует SMB-соединение к указанному хосту. Для внешних IP Kerberos недоступен, поэтому SMB падает на NTLM. Дальше - стандартный challenge-response:- Клиент (жертва) отправляет NEGOTIATE_MESSAGE на SMB-сервер атакующего
- Сервер отвечает CHALLENGE_MESSAGE с 8-байтовым nonce
- Клиент вычисляет ответ на основе хеша пароля и отправляет AUTHENTICATE_MESSAGE - в нём содержится Net-NTLMv2-хеш
ntlmrelayx.py из fortra/impacket) для перехвата третьего сообщения. Весь процесс - миллисекунды. Пользователь не видит ни окон, ни предупреждений.NTLM relay и offline-подбор: что делать с украденным хешем
NTLM relay (внутренний пентест, lateral movement). Перехваченный Net-NTLMv2-хеш передаётся в реальном времени на целевой сервис - Exchange, LDAP, SMB-шару, web-приложение с NTLM-аутентификацией.ntlmrelayx.py автоматизирует relay. Атакующий аутентифицируется от имени жертвы без знания пароля.Ограничения: relay работает только при отсутствии Extended Protection for Authentication (EPA) или SMB Signing на целевом сервисе. В legacy-инфраструктурах (Windows Server 2012/2016 без hardening) - обычное дело. В modern-средах с принудительным SMB signing relay блокируется. На практике я чаще встречаю первое, чем второе.
Offline-подбор (любой контекст). Net-NTLMv2-хеш подвергается brute-force или dictionary-атаке. Скорость зависит от сложности пароля и GPU: слабый пароль (8 символов, без спецсимволов) на средней GPU подбирается за часы. Сложный пароль с 12+ символами может оказаться нецелесообразным для подбора.
| Сценарий | Внешний пентест | Внутренний пентест |
|---|---|---|
| NTLM relay | Нет (нет маршрута к внутренним сервисам) | Да (при отсутствии SMB signing/EPA) |
| Offline-подбор | Да | Да |
| Credential harvesting → VPN/RDP | Да (подобранный пароль для initial access) | Да (lateral movement к другим хостам) |
Цепочка APT28: Windows Shell spoofing атака в реальных кампаниях
APT28 использовала этот класс уязвимостей в подтверждённой кампании. По данным Akamai и CERT-UA, kill chain выглядел так:- Initial access - фишинговое письмо с темой про украинский гидрометцентр (social engineering под актуальную повестку - классика APT28)
- Delivery - weaponized LNK-файл во вложении, эксплуатирующий CVE-2026-21513 (MSHTML, CVSS 8.8) для обхода MotW-проверок
- Exploitation - цепочка с CVE-2026-21510 (Windows Shell, CVSS 8.8) для обхода Defender SmartScreen и выполнения кода
- Post-exploitation - закрепление и сбор данных на скомпрометированных системах
С точки зрения MITRE ATT&CK цепочка покрывает:
- Impair Defenses (T1562, Defense Evasion) - обход SmartScreen и защитных механизмов Shell
- Exploitation for Client Execution (T1203, Execution) - эксплуатация клиентского ПО через обработку .lnk
Воспроизведение CVE-2026-32202 в изолированной лабе
Требования к окружению
Воспроизведение - только в изолированной лабе, на собственных системах. Эксплуатация .lnk файлов на чужих системах без письменного разрешения - уголовное преступление.
Что засветится в EDR и SIEM при эксплуатации LNK-уязвимости
Для пентестеров, верифицирующих детект на стороне заказчика, и для blue team - ключевые индикаторы эксплуатации CVE-2026-32202.Исходящий SMB к нетипичным хостам. Explorer.exe инициирует TCP 445 к внешнему IP или незнакомому хосту внутри сети. В штатном режиме Explorer не устанавливает SMB-соединения с внешними адресами. Sysmon Event ID 3 (Network Connection) от
explorer.exe с портом назначения 445 на нелокальный адрес - один из надёжных индикаторов.Отсутствие дочерних процессов. В отличие от CVE-2026-21510, где после обхода SmartScreen запускался payload, CVE-2026-32202 не порождает дочерних процессов. Process tree выглядит чисто - только сетевая активность explorer.exe. Это головная боль для EDR, заточенных под process creation events.
Windows Event Logs. Event ID 4648 (Logon using explicit credentials) и 4624 type 3 (Network logon) могут зафиксировать факт аутентификации, но только при включённом аудите Logon Events. В legacy-инфраструктурах этот аудит часто ограничен.
Что с этим делать:
- Правило в SIEM:
explorer.exeс outbound TCP 445 к адресу вне internal subnet list - высокоприоритетный алерт - Блокировка исходящего SMB (TCP 445, TCP 139) на периметровом firewall - закрывает внешний вектор NTLM coercion
- Отключение NTLM через GPO с переходом на Kerberos-only аутентификацию - радикально, но закрывает весь класс NTLM relay атак Windows, не только CVE-2026-32202
- Включение SMB Signing и EPA на всех серверах - блокирует relay даже при утечке хеша
Ограничения техники и контекст применимости
| Условие | Эксплуатация CVE-2026-32202 |
|---|---|
| Windows 10 до апрельского патча 2026 | Работает |
| Windows 10 с апрельским патчем | Не работает |
| NTLM отключён (Kerberos-only GPO) | Не работает - нет NTLM-хендшейка |
| Исходящий SMB заблокирован на firewall | Не работает для внешнего вектора |
| SMB Signing + EPA включены | Coercion работает, но relay невозможен |
| macOS / Linux | Не применимо - уязвимость в Windows Shell |
Современные EDR (CrowdStrike Falcon, Microsoft Defender for Endpoint, Elastic Security) способны детектировать аномальные сетевые подключения от explorer.exe. Но конкретный результат зависит от конфигурации: если EDR мониторит только process creation, а не network connections - NTLM coercion пройдёт незамеченным. Defender for Endpoint после обновления сигнатур детектирует конкретно этот CVE, но в zero-day окне (до публикации сигнатуры) приходится полагаться на behavior-based правила для explorer.exe с outbound SMB.
Неполные патчи - не единичный баг, а системная проблема подхода Microsoft к исправлению уязвимостей Windows Shell. Разработчик февральского фикса сосредоточился на блокировке RCE - самого очевидного результата эксплуатации. Аутентификационный побочный эффект не попал в модель угроз патча. Дахан обнаружил CVE-2026-32202 буквально при тестировании фикса - это не глубокий ресёрч, а стандартная проверка «всё ли закрыли», которую, судя по результату, внутри Microsoft не провели. Обидно? Да. Удивительно? Нет.
Для offensive-исследователя здесь два практических вывода. Каждый патч для уязвимостей класса CWE-693 (Protection Mechanism Failure) в компонентах Windows Shell и MSHTML стоит тестировать не только на заявленный вектор, но и на побочные: коммуникация с сервером, утечка метаданных, DNS-резолвинг. И второе - NTLM coercion через LNK-файлы не новый класс атак. PetitPotam, PrinterBug, DFSCoerce - все эксплуатируют один принцип: Windows-сервис автоматически аутентифицируется по NTLM без осознанного действия пользователя. CVE-2026-32202 добавил ещё один путь к тому же результату - через Shell namespace parsing. Пока NTLM не отключён в домене, каждый новый UNC-вектор - потенциальный credential theft. CVSS 4.3 усыпляет бдительность, а реальный импакт определяется не score, а тем, что атакующий сделает с хешем в конкретной инфраструктуре. Если хочешь отработать NTLM coercion и relay в контролируемой среде - на HackerLab есть лаба, где это разворачивается end-to-end без подсказок.
