Pass-ta-key: дослідники показали, як шкідливе ПЗ краде passkeys із Google Password Manager

Дослідники Unit 42 (Palo Alto Networks) описали три атаки, які дозволяють шкідливій програмі на вже зараженому компʼютері з Windows зловживати синхронізованими ключами доступу (passkeys) у Google Password Manager. У найлегшому сценарії зловмисник входить в акаунт жертви без відбитка пальця, PIN-коду й будь-якої взаємодії з користувачем, у найважчому — викрадає майстер-ключ і розшифровує всі синхронізовані passkeys. Криптографію самих ключів доступу дослідники не зламали.

Звіт «Pass the Passkey: A Novel Attack Surface in Passwordless Authentication» опубліковано 3 серпня 2026 року. Усі три техніки мають спільну назву Pass-ta-key і працюють лише за умови, що шкідливе ПЗ уже виконується на пристрої жертви. Дослідники повідомили про знахідки Google та сервіси, яких вони стосуються, до публікації.

Що таке passkeys і чому їх вважають надійнішими за паролі

Passkey — це метод безпарольної автентифікації, що спирається на пару криптографічних ключів. Публічний ключ зберігає сервіс, приватний залишається на боці користувача, а вхід підтверджується розблокуванням пристрою: відбитком пальця, сканом обличчя або PIN-кодом.

Passkeys вважають стійкішими за паролі, бо їх не можна вгадати, повторно використати чи виманити фішингом. Довідка Google описує їх як облікові дані, які неможливо передати, скопіювати, записати чи випадково повідомити сторонній особі.

Google додатково посилила цю модель: приватні ключі генеруються та використовуються всередині ізольованого хмарного середовища (cloud authenticator), а доступ до криптографічних операцій контролюють апаратні ключі, привʼязані до конкретного пристрою. Саме цю конструкцію й перевіряли дослідники.

Умови атак: заражений Windows, Chrome і TPM

Дослідження стосується Google Password Manager у браузері Chrome на пристроях з Windows, обладнаних модулем TPM. Кожен сценарій починається з того, що на компʼютері вже працює шкідлива програма — з правами звичайного користувача, без адміністраторських привілеїв.

Жоден зі сценаріїв не ламає криптографію WebAuthn. Натомість вони використовують проміжні механізми: як Chrome зберігає ключі пристрою, як він проходить повторну реєстрацію після втрати локального стану і чи перевіряє сервіс, що користувача справді було ідентифіковано.

Розвідка теж не потребує підвищених прав. Chrome тримає синхронізовані записи passkey у локальній базі LevelDB усередині профілю користувача. З них видно, на яких сервісах жертва користується ключами доступу, під якими іменами та які ідентифікатори мають ці облікові дані.

Pass-ta-key: підміна довіреного пристрою

Перша техніка імітує звичайну поведінку Chrome. Браузер зберігає ключ ідентичності пристрою у вигляді зашифрованого TPM блоба у файлі стану passkey_enclave_state. Шкідлива програма зчитує цей блоб і через стандартні криптографічні інтерфейси Windows (CNG) змушує TPM підписати запит зловмисника.

Хмарний автентифікатор Google сприймає такий запит як звернення з довіреного компʼютера жертви й повертає дійсну підписану відповідь. Її достатньо, щоб увійти в акаунт — без згоди користувача, без біометрії, без розблокування пристрою.

Обмеження в цієї атаки одне: у відповіді залишається нульовим прапорець User Verified (UV) — один біт, який засвідчує, що користувач підтвердив особу PIN-кодом або біометрією. Його призначення описане у специфікації W3C Web Authentication (Level 2), а перевіряти цей прапорець має сервіс, у який виконується вхід.

На практиці перевіряють не всі. Спроба ввійти в акаунт GitHub провалилася: сервіс коректно відхилив відповідь без підтвердження користувача. А на eBay атака спрацювала — платформа вимагала перевірку користувача, але не перевіряла сам прапорець, фактично зводячи багатофакторну автентифікацію до одного фактора. Після звернення дослідників eBay усунув цю прогалину.

Silver Pass-ta-key: підроблений ключ підтвердження особи

Друга техніка розрахована на сервіси, які перевіряють прапорець UV коректно. Замість того щоб діставати доступ до легітимного ключа підтвердження, зловмисник змушує систему зареєструвати власний.

Для цього шкідлива програма анулює наявний ключ: надсилає команду про «забування» пристрою або просто видаляє файл passkey_enclave_state — жодних вбудованих механізмів, які б цьому завадили, немає. Під час наступного використання passkey Chrome змушений заново пройти реєстрацію пристрою.

Тут спрацьовує особливість Windows-реалізації: щоб не показувати користувачеві два запити на PIN поспіль, Chrome відкладає створення ключа підтвердження до наступного використання passkey, а пристрій тимчасово перебуває у стані очікування. Саме в цей момент зловмисник реєструє власний відкритий ключ — хмарний автентифікатор не перевіряє, чи походить новий ключ із захищеного апаратного модуля.

Після цього будь-який підпис ключем зловмисника сприймається як доказ того, що користувач розблокував пристрій. Доступ стає багаторазовим: атакувати можна з власного середовища, і компʼютер жертви для цього вже не потрібен.

Golden Pass-ta-key: викрадення майстер-ключа

Третя і найважча техніка спрямована на security domain secret (SDS) — 32-байтовий симетричний майстер-ключ, яким зашифровані всі синхронізовані passkeys акаунта. За задумом він недоступний клієнту: на пристрої зберігається лише зашифрована копія, яку може розшифрувати тільки хмарний автентифікатор.

Дослідники виявили, що під час реєстрації пристрою секрет потрапляв у відкритому вигляді до внутрішнього журналу Chrome, доступного за адресою chrome://device-log/FIDO. Google прибрала його з журналів після звернення Unit 42, однак, за даними дослідників, SDS і далі надсилається клієнту та тимчасово залишається в памʼяті процесу браузера.

Звідси й будується атака: зловмисник примусово запускає повторну реєстрацію, відстежує зміну файлу стану, знімає дамп памʼяті Chrome і дістає SDS. Далі цим ключем розшифровуються локальні записи синхронізованих passkeys, а приватні ключі можна перенести на власну систему та входити від імені жертви.

Найсерйозніший наслідок — довговічність такого доступу. Викрадений SDS дозволяє розшифрувати не лише наявні, а й усі майбутні ключі доступу акаунта. За даними Unit 42, у поточній реалізації Google немає способу змінити або відкликати цей секрет, тож навіть виявлений злам не дає повноцінного шляху до відновлення.

Що це означає для користувачів

Дослідники наголошують: passkeys залишаються значно безпечнішими за паролі. Вони усувають цілі класи атак — фішинг, повторне використання й витоки паролів. Жодна з описаних технік не працює проти користувача, чий пристрій не заражено.

Але висновок дослідження інший: passkeys не скасовують ризиків, які створює шкідливе ПЗ на кінцевому пристрої. Синхронізований ключ доступу успадковує захищеність найслабшого з пристроїв, між якими він синхронізується, — і це властивість синхронізації, а не самої технології passkeys.

Що радять виправити розробникам і сервісам

• Сервісам — вимагати параметр userVerification зі значенням required і обовʼязково перевіряти прапорець UV у кожній відповіді автентифікатора.
• Менеджерам облікових даних — перевіряти походження та атестацію нових ключів пристрою, а не приймати довільні ключі.
• Посилити процедури відновлення та повторної реєстрації пристроїв, зокрема відстежувати повторні запуски цих сценаріїв після видалення або зміни локальних файлів стану.
• Не передавати майстер-ключ на бік клієнта — ні в журнали, ні в памʼять процесу.
• Обмежити доступ до локальних даних passkey рівнем процесу браузера.
• Покращити виявлення аномального використання ключів: у синхронізованих системах лічильник підписів здебільшого статичний, тож сервіси майже не бачать ознак копіювання облікових даних.

Чому це важливо для українських користувачів

Спільна передумова всіх трьох сценаріїв — заражений компʼютер з Windows. Для України це не гіпотетична умова. У березні–квітні 2026 року CERT-UA фіксувала зростання інтенсивності кібератак на заклади охорони здоровʼя, органи місцевого самоврядування та операторів FPV. Серед використаного інструментарію фахівці називали CHROMELEVATOR — засіб для викрадення автентифікаційних даних саме з інтернет-браузерів.

Тобто ланка, від якої залежить безпека синхронізованих passkeys, в українському контексті атакується регулярно й цілеспрямовано. Для акаунтів із підвищеними вимогами — банківських, робочих, повʼязаних з обороною чи критичною інфраструктурою — розумніше покладатися на апаратний ключ безпеки FIDO2, приватний ключ якого не синхронізується між пристроями.

Що можна зробити вже зараз

• Оновлювати операційну систему та Chrome і не відкладати перезапуск браузера після оновлення.
• Не запускати виконувані файли з архівів, отриманих поштою чи в месенджерах, навіть якщо відправник виглядає знайомим.
• Для найважливіших акаунтів використовувати апаратний ключ безпеки FIDO2 замість синхронізованого passkey.
• Насторожитися, якщо Chrome несподівано просить PIN відновлення Google Password Manager під час звичайного входу: такі запити нормальні для налаштування нового пристрою, а не для щоденної автентифікації.
• Періодично переглядати перелік пристроїв і ключів доступу в налаштуваннях безпеки акаунта Google і видаляти зайві.

Часті запитання

Чи означає це дослідження, що passkeys небезпечні?

Ні. Дослідники прямо зазначають, що passkeys залишаються значно безпечнішими за паролі й усувають цілі класи атак. Криптографію ключів доступу не зламано, а всі описані сценарії потребують шкідливого ПЗ, яке вже працює на пристрої користувача.

Чи стосується це власників iPhone та пристроїв на Android?

Дослідження зосереджене на Google Password Manager у Chrome на Windows із модулем TPM. Інші браузери, операційні системи та менеджери облікових даних дослідники не тестували, тому висновки не варто автоматично поширювати на них — але й вважати їх захищеними лише на цій підставі не можна.

Чи можна замінити майстер-ключ, якщо його викрали?

За даними Unit 42, у поточній реалізації Google немає механізму ротації або відкликання security domain secret. Це означає, що наявні й майбутні синхронізовані passkeys залишаються захищеними тим самим секретом.

Що робити, якщо Chrome раптом просить PIN відновлення Google Password Manager?

Такий запит доречний під час налаштування нового пристрою або відновлення доступу. Якщо він зʼявляється під час звичайного входу за passkey, варто перевірити пристрій на наявність шкідливого ПЗ і переглянути список зареєстрованих пристроїв в акаунті Google.