Ключи Windows Hello стали лазейкой для входа в Entra ID

Исследователь в области безопасности Дирк-ян Моллема (Dirk-jan Mollema) продемонстрировал сценарий атаки, при котором вредоносное ПО, уже работающее в активном сеансе Windows, может без ведома пользователя использовать ключи Windows Hello for Business для аутентификации в Microsoft Entra ID.

Запущенный код действует от имени жертвы. Он обращается к криптографическим операциям через штатные механизмы Windows. Система «считает», что запрос подписывает легитимный владелец.

Как работает атака

На устройствах с доверенным платформенным модулем (TPM) злоумышленник не извлекает приватный ключ. Ему не нужен ни PIN-код, ни биометрическое подтверждение. Windows ticketing сохраняет возможность выполнения криптоопераций, пока пользователь интерактивно авторизован в системе.

Код, оказавшийся в сессии, просто запрашивает подписание данных для аутентификации. Привилегий администратора не требуется. Это следствие архитектуры Windows Hello for Business. Microsoft документирует такое поведение, но не считает его уязвимостью.

«Данный метод не использует баг или эксплойт. Это прямое следствие того, как работает Windows Hello for Business. Злоумышленник лишь использует доверенное окружение, в которое он уже попал».

Ранее, в 2024 году на DEF CON 32, Моллема уже показывал похожий подход. Тогда для получения Primary Refresh Token (PRT) требовался доступ к устройству, зарегистрированному в Entra ID. Новая техника снимает это ограничение.

Превращение ключа Hello в пасскей FIDO2

Исследователь рассматривает ключ Windows Hello for Business как passkey-устройство в контексте WebAuthn. Пятиминутный challenge, который Entra ID выдает для аутентификации, не привязан к сессии, пользователю или арендатору (tenant).

Злоумышленник может запросить такой challenge на своем хосте, инициировав вход через браузер. Затем вредоносный скрипт на машине жертвы заставляет систему подписать вызов — и возвращает подписанное утверждение (assertion) атакующему.

Инструментарий ROADtools — открытый фреймворк для взаимодействия с Entra ID — применяет полученное утверждение. Набор скриптов способен запросить токены доступа или открыть браузерную сессию от имени жертвы.

Изучив структуру токена, Моллема выяснил, что в нем отсутствует идентификатор устройства (device ID). Без этой привязки атакующий может:

• Зарегистрировать новое устройство в Entra ID
• Запросить для него Primary Refresh Token
• Получить доступ к облачным сервисам Microsoft

PRT действителен 90 дней и автоматически продлевается, пока жертва активно пользуется устройством. Это открывает широкое окно для сохранения персистентного доступа.

Обход политик и ограничений

Аутентификация через WebAuthn способна удовлетворить даже строгие политики условного доступа (Conditional Access). Она может требовать устойчивую к фишингу аутентификацию (phishing-resistant authentication strength). По данным исследователя, подписанное утверждение проходит проверку как «свежая» многофакторная аутентификация (MFA).

Это позволяет злоумышленнику добавлять новые методы входа на контролируемом устройстве. Например, ключи Windows Hello for Business или пасскеи. Однако цепочка может прерваться, если в организации внедрены проверки состояния устройства (device compliance) или дополнительные политики.

Обнаружение подобной активности осложнено. Один из индикаторов — попытки входа через Windows Hello for Business с пустым идентификатором устройства. Но такая же картина наблюдается при использовании приватных окон браузера или сессий без единого входа (SSO).

Мониторинг неожиданных регистраций новых устройств — наиболее практичная рекомендация. PowerShell-скрипты с доказательством концепции (PoC) Моллема опубликовал в репозитории ROADtools: файлы fido_assertion.ps1 и hellopoc.ps1 доступны для изучения.

На момент написания материала CVE, связанный с описанной техникой, в базе Microsoft Security Update Guide, NVD и CVE.org не зарегистрирован. Официального рекомендательного документа от Microsoft не выпущено. Запросы журналистов в Microsoft и к исследователю остаются без ответа.

Случай вновь подсвечивает фундаментальное ограничение концепций устойчивой к фишингу аутентификации. Аппаратно привязанные учетные данные остаются неэкспортированными, но вредонос внутри живой сессии может заставить систему подписывать всё, что нужно злоумышленнику.

Читайте также: Компьютерные вирусы: что это, как работают и чем опасны

Источник: The Hacker News