iAuthFlow v2 може перетворити один успішний фішинговий вхід до Google на доступ, який зберігається навіть після скидання пароля. У демонстрації продавця, яку проаналізувала Abnormal AI, набір інструментів передавав вхід Google через браузер під контролем зловмисника, а потім використовував цю автентифіковану сесію, щоб додати новий ключ доступу. Скидання пароля й відкликання перехопленої сесії не видалили доданий спосіб входу.
Ця атака не зламує криптографію passkey і не робить законні ключі доступу небезпечними. Спочатку людина має завершити фішинговий вхід із паролем і кодом підтвердження, переданим через посередника. Практичний висновок вужчий, але важливий: після фішингу акаунта недостатньо лише змінити пароль, якщо зловмисник устиг змінити способи входу або відновлення.
Як працює атака iAuthFlow v2
Abnormal побудувала аналіз на дописах продавця на форумі, матеріалах Telegram і записаних демонстраціях. Дослідники не запускали набір інструментів і не відтворювали вхід. У тесті жертва взаємодіяла зі сторінкою в стилі Google, а окремий браузер під контролем оператора завершував справжній вхід Google. Такий посередник передавав між двома браузерами адресу, пароль, запити Google і код із застосунку автентифікації.
Після автентифікації браузера оператора iAuthFlow v2 залишав жертву на екрані “Verification, Processing”. Журнал продавця показав створення ключа доступу через шість секунд після входу. Нові облікові дані не залежали від пароля та перехопленої сесії, тому згодом оператор міг вибрати “Спробувати інший спосіб” і ввійти через доданий ключ.
Чи означає це, що ключі доступу Google зламано?
Ні. Passkey зазвичай протистоїть фішингу, бо прив’язаний до справжнього сайту й не вводиться у фальшиву форму. iAuthFlow v2 не просить жертву передати вже наявний ключ. Натомість набір використовує слабші резервні способи — пароль і переданий одноразовий код — щоб отримати справжню сесію, а потім додає нові облікові дані так, ніби це зробив власник акаунта.
Продемонстрований механізм також має обмеження. Google може повторно перевірити особу перед важливою зміною, затримати довіру до нового ключа, а також вимкнути підозрілий passkey і попередити користувача. Abnormal називає спосіб зберігання ключа технічно можливим, але не доведеним. Звіт описує контрольовані тести продавця, а не кількість жертв чи підтверджену масову кампанію проти Google.
Спочатку визначте стан контакту
| Що сталося | Ризик і наступна дія |
|---|---|
| Ви отримали або відкрили посилання, але нічого не вводили | Закрийте сторінку. Відкрийте Google через відому закладку чи застосунок і перегляньте нещодавні події безпеки. |
| Ви ввели адресу або пароль | На чистому пристрої змініть пароль і перевірте пристрої, сесії, способи відновлення та події. |
| Ви завершили MFA або довго бачили “Processing” | Вважайте акаунт скомпрометованим. Видаліть невідомі ключі, відкличте сесії та перевірте пошту й доступ застосунків. |
| Google попередив про новий або підозрілий passkey | Відкрийте сторінку безпеки Google Account напряму. Не підтверджуйте спосіб, якщо не впізнаєте пристрій і час. |
| Зловмисник повертається після зміни пароля | Відновлюйте акаунт із надійного пристрою, видаліть усі невідомі способи входу й відновлення та зверніться до адміністратора Workspace або підтримки Google. |
Як видалити чужий ключ доступу Google
- Скористайтеся чистим надійним пристроєм. Не відновлюйте акаунт через те саме посилання, повідомлення чи вкладку браузера.
- Відкрийте Google Account напряму. Перейдіть до Безпека й вхід, а потім до Ключі доступу та ключі безпеки. Видаліть passkey або апаратний ключ, який не впізнаєте. Android може автоматично реєструвати законні ключі, тому спочатку перевірте пристрій.
- Завершіть невідомі сесії. Якщо кілька сесій мають однакову назву пристрою і їх неможливо розрізнити, завершіть усі.
- Змініть пароль. Створіть унікальний пароль на надійному пристрої. Це припиняє доступ через пароль, але не завершує відновлення.
- Перевірте відновлення. Видаліть невідомі резервні телефони й адреси, делегований доступ до пошти та паролі застосунків.
- Відкличте підключені застосунки й дозволи OAuth. Скидання пароля може не видалити кожне стороннє підключення.
- Перевірте Gmail. Перегляньте пересилання, фільтри, заблоковані адреси, делегатів, надіслані й видалені листи.
- Перегляньте події та важливі акаунти. Якщо Gmail був доступний стороннім, відновіть фінансові, хмарні, соціальні акаунти й менеджер паролів, що залежать від цієї пошти.
Якщо у вас є лише підозріле посилання й ви ще не вводили дані, перевірка через Gridinsoft Website Reputation Checker може додати контекст про домен. Чистий результат не доводить безпечність динамічного тунелю або щойно створеної сторінки, тому адресний рядок і стан контакту залишаються важливими.
Як організаціям зменшити ризик
Адміністраторам Workspace слід перевірити події passkey, двоетапної перевірки, входу, OAuth, пересилання Gmail і способів відновлення після перехопленої сесії. Якщо організація може вимагати фішингостійку автентифікацію, варто вимкнути слабші резервні методи для користувачів із високим ризиком. Налаштування Google “Лише ключ безпеки” підтримує апаратні ключі та passkey, а Advanced Protection додає суворіші правила входу й доступу застосунків.
Не плутайте цю кампанію з атакою Pass-ta-key. Pass-ta-key починається зі шкідливого коду, який уже працює у Windows, і націлюється на синхронізовані ключі Google Password Manager. iAuthFlow v2 починається з переданого фішингового входу й використовує автентифіковану сесію, щоб додати новий ключ під контролем зловмисника.
Джерела
- Callie Baron і Piotr Wojtyla. “iAuthFlow v2 Enrolls Google Passkeys That Survive Password Resets.” Abnormal AI, 20 серпня 2026 року. abnormal.ai
- Google Account Help. “Sign in with a passkey instead of a password.” Google, перевірено 2 вересня 2026 року. support.google.com
- Google Account Help. “Secure a hacked or compromised Google Account.” Google, перевірено 2 вересня 2026 року. support.google.com
