Дослідники Palo Alto Networks Unit 42 показали три способи, якими шкідливе ПЗ на вже зараженому комп’ютері Windows може зловживати синхронізованими ключами доступу (passkey) у Google Password Manager. У найсильнішому сценарії зловмисник отримує секрет, що захищає синхронізовані ключі, і використовує їх зі свого пристрою. Дослідження не ламає криптографію passkey і не доводить, що достатньо лише відкрити сайт: кожен продемонстрований шлях починається зі зламу Windows-пристрою.[1]
Звіт від 3 серпня стосується Google Password Manager у Chrome на Windows із модулем TPM. Автори назвали сімейство атак Pass-ta-key. Вони відповідально повідомили про знахідки й не описували активну злочинну кампанію.
Кого стосується дослідження Pass-ta-key?
Продемонстрований ризик найреальніший, коли одночасно виконуються такі умови:
- Chrome на Windows увійшов у Google-акаунт і синхронізує ключі доступу через Google Password Manager;
- на комп’ютері вже працює шкідливе ПЗ в обліковому записі користувача, навіть без прав адміністратора;
- зловмисник може читати або змінювати дані профілю Chrome, звертатися до TPM чи переглядати пам’ять процесу Chrome;
- цільовий сайт приймає створену WebAuthn-відповідь.
Unit 42 не перевіряла всі браузери, операційні системи, менеджери паролів і апаратні ключі. Тому апаратний ключ без хмарної синхронізації перебуває поза межами саме цього дослідження, але це не доводить його стійкість до всіх атак на зараженому пристрої. Google пояснює, що синхронізованими ключами доступу можна керувати через Google Password Manager у Chrome та Android.[2]
Цей сценарій також відрізняється від дзвінка чи фішингової сторінки з фальшивим налаштуванням passkey. Соціальна інженерія змушує людину схвалити чужі облікові дані, тоді як Pass-ta-key починається після того, як локальне шкідливе ПЗ уже зробило Windows-пристрій ненадійним. Окремий приклад такого соціального сценарію описано в матеріалі про фальшиве налаштування passkey Microsoft 365.
Чим відрізняються три атаки на ключі доступу Google
Pass-ta-key: доступ через TPM пристрою жертви
Шкідливе ПЗ читає записи синхронізованих облікових даних і загорнутий ключ ідентичності пристрою, після чого просить TPM жертви підписати запит входу. Воно працює зі звичайними правами й не показує запит розблокування пристрою. Цей шлях зазвичай не спрацьовує, коли сайт правильно вимагає та перевіряє підтвердження користувача.
Silver Pass-ta-key: власний ключ перевірки зловмисника
Зловмисник примусово запускає повторну реєстрацію пристрою й додає власний ключ перевірки користувача, поки Chrome очікує завершення налаштування. Після цього вхід можливий без постійного доступу до комп’ютера жертви.
Golden Pass-ta-key: розшифрування синхронізованих passkey
Шкідливе ПЗ запускає повторну реєстрацію, шукає в пам’яті Chrome секрет домену безпеки (SDS) і розшифровує синхронізовані passkey. Unit 42 зазначає, що поточна схема не має ротації або відкликання SDS, тому просте створення нового синхронізованого ключа може не закрити підтверджений Golden-витік.
Перший етап розвідки особливо важливий під час реагування на інцидент. Chrome зберігає синхронізовані WebAuthn-записи за шляхом на кшталт %LocalAppData%\Google\Chrome\User Data\{Profile}\Sync Data\LevelDB. Вони показують, які сервіси й імена користувачів застосовують passkey, хоча приватні ключі залишаються зашифрованими, доки атака не отримає можливість підпису або розшифрування.
Що виправили Google і окремі сайти?
Після повідомлення Unit 42 Google прибрала SDS із видимого журналу chrome://device-log/FIDO. Дослідники стверджують, що під час відновлення той самий секрет досі потрапляє до процесу Chrome і може залишатися доступним у пам’яті. Звіт не називає версію Chrome, яка закриває всі три класи атак.
Базовий Pass-ta-key також залежить від того, як сайт обробляє прапорець перевірки користувача WebAuthn. Під час тестування eBay приймав відповідь без потрібної перевірки, але виправив цю помилку після повідомлення. GitHub відхилив аналогічний запит у тесті дослідників. Отже, успішна демонстрація на одному сервісі не означає однаковий ризик для кожного акаунта з passkey.
Власникам сайтів потрібно запитувати userVerification = required і справді перевіряти повернений UV-прапорець. Постачальникам менеджерів облікових даних також потрібні сильніша перевірка нових ключів пристрою, захист локального стану passkey і виявлення неочікуваної повторної реєстрації.
Що робити, якщо на Windows запускалося шкідливе ПЗ
- Припиніть входити з підозрілого ПК. Від’єднайте його від мережі, якщо невідома активність триває зараз. Не створюйте замінні passkey у тому самому профілі Chrome.
- Використайте надійний телефон або інший чистий комп’ютер. Перевірте події безпеки Google, пристрої, способи відновлення, сторонні підключення й активні сесії. Під час відновлення зламаного акаунта Google радить змінити пароль і прибрати невідомі пристрої або доступ.[3]
- Почніть із пошти та менеджера паролів. Далі захистіть банківські, криптовалютні, робочі, розробницькі, соціальні й торговельні акаунти. Видаліть невідомі passkey і в Google Password Manager, і в налаштуваннях окремого сервісу, де це можливо.
- Очистьте пристрій до нового входу. Захисний інструмент може видалити видимий файл, але залишити loader, заплановане завдання, службу, політику браузера, розширення або інший модуль. Матеріал про ACR Stealer і відновлення після крадіжки облікових даних показує правильну послідовність. Gridinsoft Anti-Malware може перевірити Windows на шкідливе ПЗ і закріплення, але чисте сканування не відкликає вже викрадений passkey або сесію.
- Ескалюйте можливий Golden-витік. Якщо є ознаки дампа пам’яті Chrome, примусової повторної реєстрації passkey або крадіжки SDS, зверніться до відповідного сервісу чи команди реагування. Поки постачальник не підтвердить безпечну ротацію, для цінних акаунтів використовуйте несинхронізований апаратний ключ або інший незалежно захищений спосіб входу.
Якщо доступ повертається після зміни пароля, у налаштуваннях з’явилися чужі passkey або зламано кілька акаунтів, перевірте також викрадення browser cookies і сесій. Матеріал про бекдор Chrome Native Messaging пояснює, чому зміни пароля може бути недостатньо. Якщо ознак шкідливого ПЗ, невідомих сесій чи повторної реєстрації немає, саме дослідження не вимагає видаляти всі ключі доступу: оновлюйте Chrome і Windows та підтримуйте пристрій чистим.
Джерела
- Arie Olshtein. “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication.” Palo Alto Networks Unit 42, опубліковано й оновлено 3 серпня 2026 року. звіт Unit 42.
- Google. «Як керувати ключами доступу в Chrome». Google Chrome Довідка, дата звернення 3 серпня 2026 року. довідка Chrome.
- Google. «Як захистити зламаний або скомпрометований обліковий запис Google». Google Обліковий запис Довідка, дата звернення 3 серпня 2026 року. довідка Google.
