Позвонили и просят обновить ключ доступа. Почему это крадёт сессию, а не сам Passkey

Сначала одним предложением — ответ на запрос

Ключ доступа (Passkey) по WebAuthn держит закрытый ключ на этом устройстве или в синхронизированной связке и привязывает его к источнику relying party. Поддельный хост входа этот ключ не вывезет. В этом диапазоне фраза «устойчив к фишингу» верна. Вне этого диапазона: вас торопят закончить вход, и токен сессии оказывается у них; либо вы вводите продиктованный код на настоящей странице Microsoft, и токен выдают клиенту, которым они управляют.

Заметка для тех, кто уже записал passkey и всё равно получает звонок или SMS «обновите его», и для разработчиков с администраторами, которым нужно объяснить коллегам, почему Passkey — не индульгенция от вишинга. Это не замена разбора Microsoft и не инструкция «как выключить ключи доступа». Унести отсюда стоит другое: какой слой закрывает сценарий, какой слой забирают сессия и код устройства, почему смены пароля мало и что можно сверить на этом устройстве, когда трубку уже положили.

Какие слои развело это уведомление

9 сентября 2026 Microsoft Security Research опубликовала английский разбор. Они сопровождают продолжающиеся взломы облачной идентичности: странные входы, затем методы проверки, которые добавил противник, плотный трафик Microsoft Graph, загрузки из SharePoint и OneDrive, сбор почты через REST API. В тексте прямо сказано: активность наблюдают с мая 2026.

Начало — не аккуратное фишинговое письмо. Начало — звонок или SMS на личный мобильный. Звонящий представляется корпоративной службой поддержки и создаёт срочность: ключ доступа, многофакторную проверку или единый вход нужно обновить сразу, иначе учётная запись «сломается». Ссылка часто приходит вторым SMS на тот же личный телефон. Microsoft пишет жёстко: хотя сценарий крутится вокруг Passkey, записать ключ доступа часто не цель. История нужна, чтобы провести человека в один из двух технических путей — фишинг «человек посередине» (AiTM) или выдачу доступа по коду устройства.

Путь AiTM снимает учётные данные и токены сессии. В пути кода устройства жертву уговаривают ввести короткий код на собственной странице проверки Microsoft; токен выдают клиенту противника, поэтому украсть cookie браузера уже не нужно. Любой из путей может потом пропускать MFA. Если ссылку открыли на личном телефоне, который не стоит на Defender, телеметрия конечной точки почти пустая. Тогда воспоминание человека о звонке или SMS часто оказывается самым ранним — и иногда единственным — доказательством, откуда начался взлом.

Инфраструктуру собирают «на знакомый взгляд». В разборе названы тематические хосты passkeyhelpdesk.com, setupmypasskey.com, add-passkey.com, secure-passkey.com, плюс имя компании в поддомене, например contoso.add-passkey.com. То же имя может сидеть и под SSO-хостом вроде integratedsso.com. Домен поднимают через несколько часов после регистрации — окно блокировки короткое. В части случаев уже взломанный аккаунт коллеги шлёт в Teams то же «обновите ключ доступа» и накладывает внутреннее доверие поверх телефонного звонка.

Первичный доступ Microsoft связывает с несколькими кластерами, среди них Storm-3121 и Storm-3032. Storm-3121 часто кормит вымогательство ShinyHunters и Falcon. Storm-3032 описан как откол от BlackFile, который теперь ходит под вывеской Helix. Это экология, а не доказательство, что каждый «звонок из ИТ» — одна и та же группа. В памятку для передачи смены кладут сценарий и два технических пути, а не имя банды.

Ключ доступа останавливает поддельный хост. Отданную сессию — нет

Читать «устойчив к фишингу» как «меня нельзя уговорить» — значит сварить слой учётных данных и слой сессии в одну фразу. Ключ доступа при записи привязывают к источнику сайта. Двойник страницы входа Microsoft на другом хосте всё равно не вытащит закрытый ключ, который вы сохранили для login.microsoftonline.com. Это настоящее преимущество относительно повторного пароля. Отыгрывать его не нужно.

Одна шкала времени в расследовании показывает, где преимущество кончается. На T+0 минут неуправляемый контекст бьёт в OfficeHome и получает ошибку 50074 — просят второй фактор. На T+1 MFA проходит: в разборе это AiTM плюс MFA, которая не устойчива к фишингу, затем 50140 прерывает «оставаться в системе». В ту же минуту проверка проходит, сессия встаёт. Следующий час та же сессия открывает My Apps, профиль, управление согласованиями и сведения для защиты, затем идёт по SharePoint и Outlook через Graph. Как только сессия есть, ваш passkey им больше не нужен.

Поэтому «у меня уже есть Passkey» держит только узкий вывод: поддельный хост вряд ли вывезет этот закрытый ключ. Оно не держит: вас не заставят снова ввести пароль или SMS-код на двойнике; схема «человек посередине» не заберёт токен, который только что выдал вход; в сведениях для защиты не вырастет их authenticator. Последние фразы требуют других доказательств: тот ли это официальный хост входа, и нет ли в сведениях для защиты устройства, которого вы не добавляли.

Почему код устройства срабатывает на настоящем хосте

Схеме «человек посередине» всё же нужна страница, похожая на вход. Код устройства снимает и этот слой. Официальный поток такой: клиент показывает короткий код; вы в браузере открываете страницу входа устройства Microsoft; вводите код; этим одобряете, чтобы «тот клиент» действовал от вашего имени. Страница настоящая. Сертификат настоящий. Адресная строка выдерживает вопрос «это Microsoft?». Обман переезжает на другой вопрос: кто сгенерировал этот код и какое приложение получит разрешение.

Вторая последовательность в разборе — ровно это: после сценария про passkey жертва вводит код, который дал противник, на законной странице проверки, и токен выдают их клиенту. Дальше токен проигрывают, перечисляют каталог и файлы и обходят и кражу cookie, и ещё один запрос MFA. Тому, кого учили смотреть на замок и имя хоста, это сложнее поймать в моменте: слой, который вас учили проверять, зелёный.

Поэтому «в адресной строке Microsoft» держит только: вы не ввели пароль на двойник вроде add-passkey.com. Оно не держит: этот код принадлежит вашему ноутбуку; после одобрения токен останется в вашей вкладке. Код, который продиктовали по телефону, прислали в SMS или кинули в чат, по умолчанию считайте их клиентом — а не «официальная страница, значит безопасно».

Почему смена пароля не закрывает уже записанный authenticator

После входа первый ход часто не «ещё файлы». Первый ход — вписать свой метод проверки в вашу идентичность. В разборе: новый номер телефона, приложение-authenticator или программный одноразовый токен. Живой образец аудита от 4 сентября 2026 показывает новую запись: имя устройства NO_DEVICE, метка SoftwareTokenActivated, поле хеш-функции hmacsha1. Это не «они поставили ещё один пароль». Это «следующий второй фактор могут пройти они».

Реагирование Microsoft при подтверждённом захвате — одна последовательность: отозвать активные сессии и токены обновления, сбросить учётные данные, удалить методы, которые они записали, снять почтовые правила, которые они добавили, и заново записать устойчивый к фишингу способ. Сменить пароль и не открыть сведения для защиты — оставить ключ, который они уже подогнали. Третья последовательность в расследовании показывает: через несколько дней они возвращаются с PhoneAppOTP, который записали раньше, и идут по Graph автоматизацией на Node.js — пароль верный, второй фактор «прошёл», и фактор их.

Локальная проверка пароля сверяет строку с публичным списком частых слитых паролей. Проверяемый пароль не загружается, и это не общесетевой поиск Have I Been Pwned. Она скажет, что строка слишком обычная. Она не скажет, что в сведениях для защиты выросла строка NO_DEVICE, и не докажет, что звонок был фальшивым. Слабый пароль и угнанная сессия — разные столбцы данных. Один другим не подменять.

Положили трубку. Какие слои сверить сразу

Слоган — не доказательство. Сверяйте только то, чем вы управляете: шёл ли звонок по уже доверенному каналу, какое имя хоста вы собираетесь открыть, и не выросло ли в сведениях для защиты устройство. Не открывайте ссылку из звонка на боевом аккаунте «для опыта».

1. Положите трубку. Пишите в ИТ через портал заявок, внутренний сайт или номер обратного звонка, который компания опубликовала письменно. Не перезванивайте на только что прозвучавший номер. Не жмите ссылку в SMS. Microsoft советует работодателям дать сотрудникам проверенный канал для сообщений о непрошеных запросах на проверку.
2. Если ссылку уже открыли: смотрите только имя хоста. Имя компании в поддомене и суффикс вроде add-passkey.com, setupmypasskey.com или secure-passkey.com — это не хост входа Microsoft. На этой странице не вводите пароль, SMS-код и не подтверждайте ключ доступа.
3. Если просят «ввести код на официальном сайте»: спросите, какое приложение и какое устройство его сгенерировали. Код, который вам продиктовали, — их клиент. Официальная страница кода устройства может быть настоящей, а разрешение всё равно уйдёт их приложению.
4. Войдите по пути, которому доверяете, откройте сведения для защиты / My Sign-Ins и прочитайте каждый метод. Лишние номера, authenticator и программные токены — особенно устройство, которое не ваш телефон, — отзывают сессию и удаляют по процессу администратора. На смене пароля не останавливайтесь.
5. Когда короткий одноразовый секрет всё же нужно отдать уже проверенному коллеге, переходите на путь шифротекста. Откройте самоуничтожающуюся ссылку и напишите одноразовую канарейку, например canary-fp-20260921-passkey-lure. Откройте в DevTools панель Network и включите Preserve log. После создания ссылки ищите эту канарейку: в теле POST /secrets должны быть шифротекст, срок и число прочтений — не открытый текст и не ключ после #. Форма ссылки — s.html?id={id}#{key}. RFC 9110 говорит: целевой URI запроса не включает fragment.

Первые четыре шага закрывают канал, которым забирают идентичность. Пятый закрывает другую частую ошибку: снять «код, который просило ИТ», или временный пароль в чат. Хостинги картинок и альбомы хранят пиксели и часто OCR. Предыдущая заметка это уже разбирала. Самоуничтожающаяся ссылка загружает только шифротекст; ключ остаётся после #. Два канала не мешайте: не снимайте кадр в чат и потом не вклеивайте полный URL обратно на ту же картинку.

Три способа перечитать «у меня есть Passkey»

Первое: читать «устойчив к фишингу» как «устойчив к социальной инженерии». Ключ доступа привязан к источнику. Это бьёт по поддельной странице входа, которая хочет вывезти закрытый ключ. Звонок, SMS или внутренний чат обходят этот слой и сажают вас в AiTM или код устройства. В собственном списке смягчений Microsoft рядом с «принудительно включить MFA, устойчивую к фишингу» стоит обучение против голосового и почтового фишинга — и отдельно: блокировать поток кода устройства, если он вам не нужен.

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

Третье: читать смену пароля как закрытие инцидента. Пароль, сессия, authenticator, который записали они, и правила пересылки почты — разные выключатели. Разбор просит обработать их вместе. Локально сгенерировать новый пароль закрывает только сервисы, которые всё ещё живут на пароле: откройте генератор паролей — сразу готов, длина 6–128, по умолчанию 16, короче 8 — пометка, что защита слабее, счёт в браузере, ничего не загружается. Это не отзывает сессии. Это не удаляет метод, который вы не записывали.

Частые вопросы

Ключ доступа уже записан. Этот звонок всё равно сработает?

Да, и чаще не потому, что Passkey скопировали. Сценарий использует ключ доступа как предлог. Нужна сессия, которую снимает схема «человек посередине», или код устройства, который вы вводите на настоящем хосте Microsoft для их клиента. Passkey привязан к источнику relying party. Это мешает поддельной странице входа вывезти закрытый ключ. Это не мешает вам самим выдать доступ их приложению.

Если в адресной строке Microsoft, код устройства можно вводить?

Страница входа по коду устройства как раз должна быть настоящим хостом Microsoft. Риск не в том, «подделка ли это». Риск в том, «кто сгенерировал этот код и какое приложение получит разрешение». Код, который продиктовали по телефону или прислали в SMS, выдаёт доступ их клиенту, а не вашей вкладке.

Если сменить пароль, инцидент уже закрыт?

Нет. Microsoft пишет: после входа они записывают свой номер, authenticator или программный токен. Смена пароля без отзыва сессий и удаления этих методов оставляет фактор, которым они уже владеют. Лишние устройства на странице сведений для защиты снимают официальными шагами реагирования.

Коллега в чате просит одноразовый код. Можно отправить скриншот?

Не кладите действующий OTP или код устройства в альбом чата. Короткий текст зашифруйте в этой вкладке алгоритмом AES-256-GCM и передайте самоуничтожающейся ссылкой: ключ стоит после #. Форма — s.html?id={id}#{key}. Создавать и читать можно сразу, аккаунт не нужен. Сначала подтвердите человека по каналу, который компания уже опубликовала, а не по только что прозвучавшему «звонку из ИТ». Материал больше 32 КБ — в шифрование файлов: один файл до 5 ГБ, на выходе .lock / .enc.

Короткий секрет переведите на путь, который сразу готов

Если нужна страница, где граница вычислений написана открыто, чтобы потренировать «вернуть пароль, не снимать кадр», откройте самоуничтожающуюся ссылку FastPwd. Регистрация не нужна. Вставьте канарейку выше, число прочтений оставьте 1, создайте ссылку и сверьте Network как в пятом шаге: в теле должен быть шифротекст, а не открытый текст и не ключ после решётки. Этим путём пользуйтесь только когда коллега уже проверен. Сначала не снимайте кадр. Не диктуйте код устройства незнакомцу в трубку.

Если в переписке или в тикете ещё лежат телефоны и номера документов, сначала прогоните маскирование по правилам в очистке ссылок и только потом решайте, отправлять ли. Очистка идёт на этом устройстве. Исходный текст не уходит как рабочие данные и не пишется в аналитику. Для сайтов, которые всё ещё живут на пароле, соберите уникальный локально. Не повторяйте строку, которую только что торопил звонящий. Проверка пароля отвечает только на «это публично частый слабый пароль». На «был ли звонок фальшивым» она не отвечает.

В следующий раз, когда скажут «срочно обновите ключ доступа», оставьте себе три предложения. Первое: Passkey в сценарии часто только предлог; им нужна сессия или разрешение по коду устройства. Второе: настоящий хост не мешает выдать токен чужому приложению. Третье: закрытие — сведения для защиты плюс отзыв сессий, а не одна смена пароля. Эти три фразы можно положить в памятку для передачи смены. «Я включил ключи доступа, значит на звонок можно не смотреть» — нельзя.

Что ещё почитать

После того как пароль попал кадром на хостинг картинок, хеш входа не закрывает OCR-открытый текст и Image ID: см. Почему OCR-открытый текст и Image ID с хостинга скриншотов опаснее хеша пароля. Самоуничтожающаяся ссылка доказывает, что сервер удалил шифротекст; она не доказывает, что получатель не сделал скриншот: см. Почему самоуничтожающаяся ссылка доказывает, что сервер удалил шифротекст, но не то, что получатель не сделал скриншот. Почему кусок после # не входит в HTTP: см. Почему после решётки в URL можно класть ключ и когда эта защита ломается.