Малварь угоняет синхронизированные passkey Google — атаки Pass-ta-key

Коротко о главном

3 августа 2026 года Unit 42 (Palo Alto Networks) раскрыла три атаки под общим названием Pass-ta-key, которые позволяют уже присутствующей на устройстве малвари угонять синхронизированные passkey из Google Password Manager в Chrome на Windows. Атаки не ломают криптографию passkey — они злоупотребляют тем, как Chrome и облачный аутентификатор Google выстраивают доверие к устройству, восстановление и синхронизацию. Самое неприятное: 32-байтовый мастер-ключ, шифрующий все passkey в аккаунте, проходит через память процесса Chrome в открытом виде, а после кражи его нельзя ни повернуть, ни отозвать.

Для команд разработки и безопасности вывод такой: passkey остаются гораздо надёжнее паролей против фишинга и утечек баз, но перестают быть «серебряной пулей», если рабочая станция уже заражена. Модель угроз смещается — риск теперь не в перехвате ключа по сети, а в компрометации самой конечной точки, поэтому защита endpoint и валидация признаков верификации на стороне сервиса выходят на первый план. Это повод пересмотреть информационную безопасность продукта и порядок пентеста, а не отказываться от passwordless.

Что произошло

Исследователи Unit 42 опубликовали разбор трёх методов, которые в связке назвали Pass-ta-key. Все три требуют одного стартового условия — вредоносный код уже выполняется на компьютере жертвы под Windows с модулем TPM, где Chrome используется как менеджер passkey. То есть это не удалённый взлом «из интернета», а пост-эксплуатация: атака показывает, что происходит с passwordless-аутентификацией после того, как endpoint скомпрометирован обычным стилером или трояном.

Ключевой тезис работы — passkey защищены сильной криптографией, но обвязка вокруг них (регистрация устройства, восстановление доступа, облачная синхронизация между машинами) содержит слабости, которые малварь эксплуатирует без прав администратора, без биометрии и без взаимодействия с пользователем. Google, по данным Unit 42, уведомлена и уже выкатила часть смягчений, однако корневая проблема с доступностью мастер-ключа в памяти сохраняется.

Три варианта атаки

Unit 42 описывает три сценария нарастающей тяжести. Каждый решает свою задачу — от разовой подмены ответа аутентификации до полного захвата всех синхронизированных ключей.

Pass-ta-key. Малварь читает локальную базу синхронизации Chrome, находит защищённые passkey аккаунты, восстанавливает ключ идентичности устройства (привязанный к TPM) и с помощью криптографических API Windows формирует валидные подписи, которые облачный аутентификатор Google принимает как «ответ доверенного устройства». Всё это — без прав администратора, биометрии и разблокировки. Метод бессилен против сервисов, которые корректно требуют и проверяют флаг верификации пользователя (например, GitHub), но сработал против eBay до устранения проблемы.

Silver Pass-ta-key. Атакующий вынуждает Chrome заново пройти регистрацию устройства и регистрирует собственный ключ верификации в облачном аутентификаторе. Поскольку облако не проверяет, что новый ключ исходит из доверенного оборудования, злоумышленник может подделать доказательство ввода PIN или биометрии и в дальнейшем аутентифицироваться уже с другой машины.

Golden Pass-ta-key. Самый тяжёлый вариант: малварь извлекает security domain secret — мастер-ключ, которым зашифрованы все синхронизированные passkey. Google убрала его из FIDO-логов, но, как отмечает Unit 42, секрет по-прежнему передаётся клиенту и остаётся доступен в памяти процесса Chrome. Получив его, атакующий расшифровывает текущие и будущие синхронизированные passkey, а сам мастер-ключ невозможно повернуть или отозвать — скомпрометированный аккаунт остаётся уязвимым бессрочно.

Что это значит для команд разработки

Первый вывод — верификация пользователя перестаёт быть «галочкой». Разница между устоявшим GitHub и поддавшимся eBay в том, что первый строго требует и проверяет user verification, а второй — нет. Если вы встраиваете вход по passkey в свой продукт, недостаточно просто «поддержать WebAuthn»: сервер обязан проверять флаги UV/UP и не принимать ответы без подтверждённой верификации там, где она заявлена. Это прямая задача для тех, кто проектирует аутентификацию в веб-приложениях.

Второй вывод — endpoint снова в центре модели угроз. Pass-ta-key не обходит криптографию, а паразитирует на заражённой рабочей станции, поэтому базовая гигиена конечных точек (EDR, контроль запуска процессов, защита памяти браузера, ограничение прав) напрямую снижает риск. Для корпоративных сценариев это аргумент в пользу аппаратных ключей (security keys), которые не синхронизируются в облако и не хранят экспортируемый мастер-секрет, — как минимум для администраторов и привилегированных аккаунтов.

Третий вывод — passwordless не отменяется, а взрослеет. Массовый пользователь по-прежнему выигрывает от passkey против фишинга и брутфорса, и отказываться от них из-за Pass-ta-key было бы ошибкой. Но для чувствительных ролей стоит проектировать защиту в глубину: непривязанные к синхронизации ключи, серверная проверка признаков верификации, мониторинг аномальных перерегистраций устройств и повторная аутентификация на критичных действиях.

Как действовать сейчас

Практический порядок для продуктовых и security-команд. Ничто из перечисленного не требует ждать «большого патча» от Google.

Проверьте серверную валидацию user verification во всех местах, где у вас включён вход по passkey, и запретите приём ответов без подтверждённой верификации, если она заявлена флоу.

Для администраторов и привилегированного доступа перейдите на аппаратные security keys или другие непривязанные к облачной синхронизации методы вместо синхронизируемых passkey.

Усильте защиту конечных точек: EDR, контроль целостности процессов браузера, ограничение прав приложений и мониторинг доступа к памяти Chrome. Заражённая машина — обязательное условие атаки.

Настройте мониторинг событий повторной регистрации устройств и добавления новых ключей верификации: внезапная перерегистрация — сигнал сценария Silver Pass-ta-key.

Требуйте повторной аутентификации (step-up) на критичных операциях — смене платёжных данных, экспорте, административных действиях, — чтобы одной украденной сессии было недостаточно.

Часто задаваемые вопросы

Passkey всё ещё безопаснее паролей? Да. Pass-ta-key не ломает криптографию passkey и не работает удалённо — атака требует, чтобы малварь уже выполнялась на устройстве. Против фишинга, брутфорса и утечек баз паролей passkey по-прежнему заметно надёжнее.

Кто под угрозой? Пользователи Google Password Manager с синхронизацией passkey в Chrome на Windows с TPM, чьи машины скомпрометированы. Аппаратные security keys, не синхронизируемые в облако, этим набором атак не затрагиваются.

Почему мастер-ключ так критичен? 32-байтовый security domain secret шифрует все синхронизированные passkey и проходит через память процесса Chrome в открытом виде. После кражи (сценарий Golden Pass-ta-key) его нельзя повернуть или отозвать, поэтому доступ сохраняется бессрочно.

Что уже сделала Google? По данным Unit 42, Google уведомлена и выкатила часть смягчений (в том числе убрала секрет из FIDO-логов), но корневая доступность мастер-ключа в памяти на момент публикации сохраняется.

Стоит ли отказываться от passkey? Нет. Для массовых сценариев passkey остаются рекомендованным способом входа. Разумнее усилить защиту endpoint, серверную проверку верификации и использовать аппаратные ключи для привилегированных аккаунтов.

Источники

Palo Alto Networks Unit 42 — Pass-ta-key: Attacks Against Google's Synced Passkeys, 3 августа 2026 года (первоисточник).

BleepingComputer — New Pass-ta-key attacks let malware hijack Google-synced passkeys, август 2026 года.

SecurityWeek — New Attack Methods Enable Malware to Hijack Passkey-Protected Accounts, август 2026 года.