Сразу три исследовательские группы за одну неделю показали, что атаки на passkeys уже можно строить без взлома FIDO2 и без «магии» против криптографии. В одном случае хватило старых подписанных данных из Windows, в другом злоумышленник добирался до приватных ключей синхронизированных passkeys, в третьем использовал ключ Windows Hello for Business без нового PIN-кода или биометрии. Для российских команд это плохая, но полезная новость: passkeys по-прежнему сильнее паролей, однако ошибки вокруг них теперь выглядят не как академическая экзотика, а как вполне прикладной риск для SSO, браузеров и корпоративных Windows-окружений.
По данным The Hacker News, речь идет о трех отдельных исследованиях с разным радиусом поражения. SpecterOps разобрала цепочку на Windows и Microsoft Entra ID, которая позволяла выдавать себя за привилегированного пользователя и при этом проходить требования phishing-resistant MFA. Unit 42 из Palo Alto Networks атаковала систему синхронизированных passkeys в Google Password Manager для Chrome на Windows. Независимый исследователь Dirk-jan Mollema показал, что вредонос в уже открытой Windows-сессии может использовать аппаратно защищенный ключ Windows Hello for Business без повторного запроса у пользователя. Общий вывод неприятный: математика не сломана, но обвязка вокруг нее местами оставляет слишком много удобных лазеек.
Самая громкая история пришла от SpecterOps. Главный исследователь компании Майкл Графнеттер представил работу Pass-the-Passkey на Black Hat USA 2026 5 августа. По его данным, Windows сохраняла прошлые подписи YubiKey в открытом виде, и их могли читать аутентифицированные непривилегированные пользователи, включая удаленных. Дальше включалась вторая часть цепочки: слабости в валидации passkeys на стороне Microsoft Entra ID позволяли использовать эти подписи повторно и impersonate пользователя даже там, где политика требовала phishing-resistant MFA. Уязвимость в Windows Event Logging Service получила идентификатор CVE-2026-34348 и оценку Microsoft 6,5 балла по CVSS. Компания уже выпустила июльские обновления Windows, и SpecterOps теперь считает, что полная цепочка Windows-to-Entra сломана именно этими патчами: записи WebAuthn в логах больше нельзя удобно переиспользовать для replay-атаки.
Но на этом история не заканчивается. Исследователи SpecterOps отдельно говорили, что по состоянию на 10 августа Entra, по их наблюдениям, все еще использует JSON Web Tokens в роли WebAuthn challenge вместо псевдослучайных nonce и, похоже, не привязывает challenge к session cookie. Именно это, по их версии, и оставляет почву для повторного воспроизведения assertion. Microsoft подтвердила изданию, что применила дополнительные меры для проблемы с passkey relay assertions, но технических деталей о границах этих изменений не раскрыла. Для администраторов это означает простую вещь: закрытый CVE на стороне Windows не гарантирует, что вся история с replay и challenge-binding исчерпана на уровне облачной аутентификации.
Где passkeys ломаются после компрометации конечной точки
Линейка Unit 42 бьет уже по другой болевой точке: по модели «синхронизировали ключи в облако, зато пользователю удобно». Их исследование Pass-ta-key нацелено на Google Password Manager в Chrome на Windows. Во всех трех сценариях злоумышленник уже сидит на машине жертвы, но без повышения до администратора. Первый путь злоупотребляет механизмом device identity в Chrome и получает подписи, которые позволяют притвориться легитимным клиентом Google Password Manager без нового разблокирования устройства и без участия пользователя. Этот вариант исследователи демонстрировали против eBay, хотя сайт запрашивал user verification; после уведомления eBay изменила проверку флага WebAuthn user-verification.
Самый тяжелый сценарий Unit 42 называется Golden Pass-ta-key. Его цель — Security Domain Secret, 32-байтовый мастер-ключ, который защищает синхронизированные passkeys. Сначала команда нашла этот секрет в device logging Chrome; после репорта Google убрала его из логов. Но исследователи утверждают, что во время повторной регистрации секрет все еще временно присутствует в памяти процесса Chrome. Если до него добраться, можно восстановить приватные ключи синхронизированных passkeys жертвы. И вот здесь становится особенно неуютно: Unit 42 пишет, что у текущей реализации Google нет механизма ротации или отзыва Security Domain Secret. То есть это уже не история про «перехватили один логин», а про более долговременный компромисс пользовательского пула ключей.
Работа Dirk-jan Mollema выглядит менее зрелищно, но для корпоративного Windows-мира она очень практична. Он исследовал Windows Hello for Business, где ключ, как правило, защищен TPM и не подлежит простому экспорту. Однако неэкспортируемый не значит неиспользуемый. Mollema показал, что процесс с низкими привилегиями внутри уже скомпрометированной пользовательской сессии может через стандартные криптографические интерфейсы Windows воспользоваться этим ключом без нового PIN или биометрии. После этого ключ применялся как FIDO2-учетка против Microsoft Entra ID. В его сценарии challenge Entra действовал пять минут и не был привязан к сессии, пользователю или тенанту. Поэтому challenge можно было запросить на машине атакующего, отнести на машину жертвы, подписать там с помощью Windows Hello key и вернуть обратно в виде WebAuthn assertion. Итоговый вход удовлетворял правилам Conditional Access, требующим phishing-resistant authentication.
Что это меняет для бизнеса и команд разработки
Главный вывод из всех трех историй довольно приземленный: спор «синхронизированные или device-bound passkeys» сам по себе уже не спасает. Unit 42 показывает, что после заражения endpoint облачная синхронизация может превратиться в источник более стойкого ущерба. Mollema показывает, что аппаратная привязка ключа к устройству не мешает вредоносу использовать его из живой пользовательской сессии. SpecterOps добавляет третий слой: даже надежный аппаратный токен вроде YubiKey не поможет, если ОС и облачный IdP неправильно обращаются с уже созданными assertion и challenge. Иными словами, атаки на passkeys теперь нужно обсуждать не как замену паролей, а как часть всей цепочки: клиент, браузер, логи, память процесса, IdP, правила access control и телеметрия.
Практические выводы тоже достаточно конкретны. Для Windows-инфраструктуры базовый шаг — поставить обновления Microsoft, закрывающие CVE-2026-34348. Для сервисов, принимающих WebAuthn, важно реально проверять те требования user verification, которые они сами же и запрашивают, а не просто надеяться на флажок в ответе. Для Entra-администраторов имеет смысл отдельно мониторить необычные аутентификации Windows Hello for Business без device ID и неожиданные device registration events, особенно если из них можно вырасти в Primary Refresh Token и закрепление в среде. А командам, которые продвигают passkeys как «почти неуязвимую» замену паролям, придется аккуратнее формулировать обещания: passkeys хорошо режут фишинг и reuse паролей, но не лечат зараженный endpoint и не прощают слабые реализации на стороне платформы.
И это особенно важно на фоне планов Microsoft. С 1 сентября 2026 года пользователям Entra ID, у которых сейчас включены SMS или голосовая аутентификация, компания начнет автоматически предлагать passkeys и подталкивать к их регистрации. А поддержка SMS и voice-каналов от Microsoft должна завершиться 1 февраля 2027 года. Значит, рынок будет ускоренно мигрировать на passkeys именно в тот момент, когда исследователи начали массово разбирать их эксплуатацию на уровне инфраструктурных деталей. Для безопасников это сигнал не тормозить переход, а перестать смотреть на passkeys как на волшебную таблетку. Переключение на новый фактор без ревизии браузеров, логирования, endpoint-защиты и логики проверки challenge может дать красивый отчет о modern auth, но слишком старые проблемы под новым ярлыком.