Фішинг Passkey у Хмарі Microsoft: Тріщина в Рівні Ідентифікації

Кожен керівник платформи, який погодив впровадження passkey протягом останніх дванадцяти місяців, цього тижня має переглянути своє рішення. Microsoft задокументував дві активні кампанії, що використовують сам процес реєстрації passkey як поверхню атаки, і економіка стеку захисту щойно змінилася. Твердження вендорів про те, що passkeys усувають фішинговий ризик, завжди було лише напівправдою; інша половина тепер видна в даних про інциденти.

Що Сталося

Між 3 і 5 серпня 2026 року зловмисники розіслали понад мільйон шахрайських електронних листів через сторонню інфраструктуру доставки, видаючи себе за CEO цільових компаній і тиснучи на команди кредиторської заборгованості, щоб ті переказали ACH-платежі за фіктивну річну підписку ServiceNow. Як повідомляє The Hacker News, оператори використовували генеративний AI для складання персоналізованих шаблонів електронних листів, реєстрували домени для імперсонації, включно з service-nowinc[.]com і domainlify[.]net, та заповнювали підписи справжніми іменами CEO, CFO і президентів компаній, здобутими з публічних джерел. Основною ціллю були американські підприємства у сфері IT-послуг, споживчих товарів, нерухомості та дискретного виробництва.

Друга кампанія, що триває з травня 2026 року, є більш цікавою з архітектурної точки зору. Зловмисники телефонують або надсилають SMS на особистий телефон користувача, представляються внутрішньою IT-службою підтримки та інструктують оновити конфігурацію passkey, MFA або SSO. Жертви перенаправляються на підроблені сторінки входу Microsoft і або передають облікові дані через проксі «зловмисник посередині», або підтверджують потік автентифікації через код пристрою, що надає зловмиснику токен без жодного розкриття пароля.

Після проникнення всередину схема послідовна: підозрілий вхід, після чого зловмисник реєструє власний метод автентифікації (новий номер телефону, застосунок-автентифікатор або програмний OTP), потім — масова активність Microsoft Graph, завантаження з SharePoint і OneDrive та збір поштових скриньок через REST API. Microsoft описує це як автоматизований збір даних зі скомпрометованих хмарних ідентифікацій з використанням інфраструктури, пов'язаної з проксі. Активність перетинається з кіберзлочинним кластером, що відстежується під назвами Cordial Spider, O-UNC-045, PREY-0058 і UNC6671; Microsoft приписує початковий доступ Storm-3121 і Storm-3032. Storm-3121 пов'язаний з ShinyHunters і вимагацьким угрупованням Falcon; Storm-3032 (UNC6671) відокремився від групи BlackFile і тепер діє під брендом вимагання Helix.

Технічна Анатомія

Основний обман експлуатує розрив між тим, як вендори ідентичності описують passkeys, і тим, як кінцеві користувачі їх сприймають. Passkey є фішингостійким на криптографічному рівні: приватний ключ ніколи не покидає пристрій, а браузер прив'язує твердження до джерела. Ця властивість реальна. Що не є фішингостійким — так це процедура реєстрації, потік відновлення та ментальна модель користувача щодо того, що взагалі означає «оновити passkey». Зловмисники виявили цей розрив і активно його використовують.

Список зареєстрованих доменів показує, наскільки це навмисно: passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, syncmykey[.]com, portalsetuphub[.]com. Схема — субдомени, специфічні для компанії, що накладаються на загальні корені з темою passkey, тож ціль бачить acme.passkeyhelpdesk[.]com і розпізнає бренд, а не домен. Mandiant, що належить Google, минулого місяця зафіксував ту саму техніку для UNC6671.

Два вектори атаки несуть основне навантаження. У шляху AitM фальшивий портал проксує справжній вхід Microsoft і перехоплює як облікові дані, так і файл cookie сеансу після MFA. У шляху device-code зловмисник ініціює запит авторизації пристрою до власних кінцевих точок Microsoft, а потім за допомогою соціальної інженерії змушує жертву ввести код зловмисника на справжній сторінці Microsoft. Саме цей другий потік мають зрозуміти CISO: жертва ніколи не відвідує фішинговий сайт, ніколи не вводить облікові дані в нічого підозрілого, і MFA завершується нормально. Власна інфраструктура Microsoft видає дійсний токен пристрою зловмисника. Це чітко відповідає технікам, задокументованим у MITRE ATT&CK для фішингу та зловживання дійсними обліковими записами, але варіант з device-code обходить більшість політик умовного доступу, які вважають саму сторінку входу межею довіри.

Персистентність — це історія другого етапу. Microsoft спостерігав, як зловмисник реєструє новий метод MFA під своїм контролем одразу після початкового доступу, перетворюючи компрометацію на рівні сеансу на невизначену присутність. В одному задокументованому інциденті зловмисники використали облікові дані з попередньої події, щоб зареєструвати метод на основі телефону та повністю обійти MFA при наступних входах. В іншому — аномальний вхід з некерованого пристрою до Microsoft Office Home було доповнено розширенням через Graph API до SharePoint Online і OneDrive.

Хто Постраждає

Почнемо з фінансового підрозділу. ACH-кампанія спеціально спрямована на персонал кредиторської заборгованості американських підприємств у сфері IT-послуг, споживчих товарів, нерухомості та дискретного виробництва. Це команди, де середній термін роботи AP-клерка коротший за середній термін відносин з постачальником, і де рахунок-фактура на продовження ServiceNow від когось, чиє ім'я та email-домен збігаються з CEO, виглядає цілком правдоподібно. Будь-який CFO, чий процес залучення постачальників досі спирається на підтвердження електронною поштою, фактично страхує збиток, який не буде покритий страховим полісом від кіберзлочинів у більшості юрисдикцій.

По-друге, команди з ідентифікації в будь-якій організації, що нещодавно впровадила passkeys як «фішингостійкий» контроль. У презентації для ради директорів говорилося, що passkeys вирішують проблему фішингу. Дані про інциденти свідчать, що passkeys вирішують один вузький варіант крадіжки облікових даних, водночас відкриваючи два нові вектори соціальної інженерії: маніпуляції з реєстрацією та зловживання відновленням. VP Engineering, відповідальний за дорожню карту ідентичності, має пояснити аудиторському комітету, чому контроль, що позиціонувався як остаточне рішення, тепер сам підробляється на зареєстрованих lookalike-доменах.

По-третє, і це недооцінений аспект, — тенанти Microsoft 365, що сприймають активність Graph API як фоновий шум. Спостережувана схема — масові виклики Graph, пакетні завантаження SharePoint і OneDrive та перерахування поштових скриньок через REST-кінцеві точки. Якщо ваш SIEM не встановлює базовий рівень кількості викликів Graph на ідентичність і не спрацьовує при реєстрації нового методу MFA з некерованого пристрою, у вас немає поверхні виявлення для цієї кампанії. Керівник платформи, чий бюджет на логування скорочувався двічі протягом останніх чотирьох кварталів, незабаром дізнається, що саме було урізано.

Кожна пара CFO і General Counsel цього тижня має запитати свого CISO: який у нас задокументований процес, коли співробітник повідомляє про підозрілий дзвінок від когось, хто стверджує, що є IT-фахівцем, і чи включає цей процес автоматичне анулювання будь-якого методу автентифікації, зареєстрованого за попередні двадцять чотири години? Якщо відповідь — знизування плечима або PDF-документ з політикою, який ніхто не читав з часів онбордингу, значить, контракт на реагування на інциденти вже згорає.

План Дій для Команд Безпеки

Заблокуйте ініційовану користувачем реєстрацію MFA з некерованих пристроїв. Якщо passkey, номер телефону або застосунок-автентифікатор можна додати до корпоративної ідентичності з особистого пристрою поза вашою MDM-системою, ви вже програли боротьбу за персистентність. Маршрутизуйте реєстрацію через керований пристрій або верифікацію в службі підтримки особисто, і прийміть пов'язані незручності.

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

Вимкніть потоки автентифікації через device-code для облікових записів користувачів, якщо немає задокументованої бізнес-потреби. Більшість підприємств увімкнули це одного разу для CLI-інструменту і більше не переглядали політику. Умовний доступ може обмежити це конкретними застосунками та довіреними мережами. Зробіть це цього тижня.

На боці ACH — зобов'яжіть позасмугову верифікацію для будь-якої зміни платежу постачальнику або нового рахунку-фактури вище порогу, встановленого вашим CFO. Голосовий зворотний дзвінок на номер з бази даних, а не на номер з листа. Це контроль 1990-х років, що вирішує атаку 2026 року, бо атака — це атака 1990-х років з генеративним AI-лоском.

Нарешті, шукайте доменні патерни. Заблокуйте вихідний DNS до passkey-тематичних коренів, опублікованих Microsoft, і додайте правило проксі для будь-якого субдомену, що містить назву вашої компанії на домені, зареєстрованому протягом останніх дев'яноста днів. Одне це правило зупинило б значну частину зафіксованих вторгнень.

Ключові Висновки

• Passkeys є криптографічно фішингостійкими, але потоки реєстрації та відновлення залишаються повністю вразливими до соціальної інженерії, і зловмисники індустріалізували цей розрив.
• Фішинг через device-code обходить MFA без крадіжки облікових даних або файлів cookie, і більшість політик умовного доступу не перехоплюють його за замовчуванням.
• ACH-кампанія охопила понад мільйон поштових скриньок за три дні, використовуючи генеративний AI для складання шаблонів і публічні джерела для імперсонації керівників.
• Персистентність забезпечується методами MFA, зареєстрованими зловмисником одразу після початкового доступу; виявлення реєстрації нового методу тепер є контролем першого рівня.
• Кластер загроз охоплює Storm-3121, Storm-3032, UNC6671, Cordial Spider і пов'язаний з брендами вимагання ShinyHunters, Falcon та Helix, тобто початковий доступ тут фінансує програми-вимагачі далі по ланцюжку.

Команди, що оцінюють розгортання passkey протягом наступних 90 днів, тепер мають ставити собі інше питання. Не «чи усуває це фішинг», а «хто відповідає за процедуру реєстрації і скільки коштує зробити цю процедуру ворожою для зловмисників?» Відповідь проявиться у кількості персоналу, у переробці процесів служби підтримки та у розмові з вендором про ліцензування умовного доступу, яку ніхто не закладав у бюджет.