Исследователи Unit 42 разобрали, как вредонос на уже заражённом ПК с Windows может злоупотребить пасскеями, которые Chrome синхронизирует через Google Password Manager. Нюанс важный: это не удалённый взлом «по щелчку», а посткомпрометационная атака, когда код злоумышленника уже работает на устройстве.
Для пользователей и администраторов вывод простой: сами пасскеи не «сломались», но заражённый Windows-компьютер всё ещё может стать точкой обхода защиты. Если устройство уже под контролем атакующего, удобство синхронизации начинает работать против владельца.
Проблема связана с доверенным устройством, а не с криптографией
В материале Unit 42 речь идёт о скрытом облачном компоненте Google Cloud Authenticator, через который Chrome на Windows, macOS, Linux и ChromeOS обслуживает синхронизированные пасскеи. Исследователи показали, что браузер хранит на компьютере служебное состояние устройства и использует аппаратно-защищённые ключи, PIN Google Password Manager и локальную проверку пользователя для работы с этими данными.
Слабое место здесь не в самой схеме FIDO или WebAuthn. Атака строится вокруг уже доверенного устройства: если злоумышленник закрепился в Windows, он может попытаться использовать или подменить локальное состояние Chrome, чтобы выполнять операции с пасскеями от имени жертвы.
Что именно вызывает тревогу
Исходный текст слишком смело утверждал, что вредонос «извлекает ключи» и просто заходит в аккаунт. По доступным материалам точнее сказать так: исследование описывает архитектуру и сценарии злоупотребления доверенным устройством, а не кражу приватных ключей в лоб. Это неприятнее для защитников, потому что выглядит как легитимная работа уже зарегистрированного клиента.
Отсюда и главный риск для бизнеса: пасскеи хорошо защищают от фишинга и перехвата паролей, но не спасают, если рабочая станция уже заражена. Для компаний это особенно чувствительно в связке с Chrome, корпоративным Google-аккаунтом и синхронизацией учётных данных между устройствами.
Практические меры для пользователей и ИБ-команд
Если Windows-машина вызывает подозрения, одной смены пароля мало. Нужны переустановка или глубокая проверка устройства, выход из Chrome на подозрительных машинах, ревизия сохранённых пасскеев и доверенных устройств, а также контроль за входами в аккаунт. Для администраторов разумный минимум — жёсткая защита конечных точек, ограничение локальных прав и мониторинг аномальной активности в браузере.
В открытых источниках на 4 августа 2026 года отдельный CVE для этой исследовательской работы не фигурирует. Первоисточник: Unit 42. Дополнительный контекст по серии исследований: RSAC 2026.
Следующий логичный шаг — ждать, как Google и исследовательское сообщество будут ужесточать защиту именно вокруг регистрации и доверия к устройствам, потому что в эпоху пасскеев атака всё чаще смещается туда.