Пасс-ключи против фишингового релея: почему привязка к домену сильнее одноразовых кодов
Фишинговые наборы, которые встраиваются между пользователем и настоящей страницей входа, стали одним из самых надёжных способов обхода многофакторной аутентификации. Жертва вводит одноразовый код, набор за секунды пересылает его настоящему сайту, а атакующий забирает вернувшуюся сессию. Пасс-ключ разрывает эту цепочку так, как не умеет ни один метод с кодами: копировать на экране просто нечего.
Как наборы AiTM пожирают одноразовые коды
Механику подробно описала Microsoft: компания отследила кампанию, затронувшую более 10 000 организаций начиная с сентября 2021 года. Атакующий запускает обратный прокси, который раздаёт пиксель-в-пиксель копию настоящей страницы входа со своего домена и держит два TLS-соединения: с жертвой и с настоящим сайтом. Пароли и cookie сессии текут через середину, и атакующий входит от имени пользователя. Microsoft подчеркнула, что это не уязвимость MFA: код подлинный, вход подлинный, а набор просто забирает то, что пользователь сам отдаёт (Microsoft). Техника не исчезла. В январе 2026 года исследователи Microsoft описали многоэтапную AiTM-кампанию против организаций энергетического сектора, приходившую через злоупотреблённые ссылки SharePoint и заканчивавшуюся финансовым мошенничеством (Microsoft). Годовой массив телеметрии Kaspersky, опубликованный в августе 2026-го, насчитал более 390 000 фишинговых страниц на легитимных облачных платформах — многие с прокси-библиотеками с открытым кодом и окнами browser-in-the-browser, подделывающими адресную строку (Kaspersky). Современный набор пересылает код, push-подтверждение и итоговый cookie в реальном времени. Всё, кроме URL, подлинно.Привязка к домену: адрес — часть самого ключа
WebAuthn — стандарт, на котором работают пасс-ключи, — устроен иначе. При регистрации сайт и браузер создают пару из открытого и закрытого ключей, привязанную к идентификатору проверяющей стороны (Relying Party ID), на практике — к домену сайта. Закрытый ключ никогда не покидает устройство, а браузер предлагает учётные данные, только если origin страницы совпадает с этим идентификатором. Документация Mozilla формулирует следствие прямо: атакующий, создавший поддельный сайт входа, не сможет войти от имени пользователя, потому что подпись меняется вместе с origin сайта (Mozilla). Альянс FIDO описывает пасс-ключи как уникальные для каждого сайта или приложения — именно это оставляет credential stuffing без материала (FIDO Alliance). Cisco Talos показал, что это значит для прокси-наборов: жертва, попавшая на поддельный домен, изображающий её банк, вообще не может завершить церемонию WebAuthn, потому что браузер не предложит учётные данные, привязанные к настоящему домену, на поддельном. Аутентификация проваливается до того, как какой-либо секрет уйдёт в сеть (Cisco Talos).Прокси-набор может переслать всё, что вводит пользователь. Он не может переслать учётные данные, которые браузер вообще не предлагает.Даже там, где церемония проходит, по проводу не идёт ничего многоразового. Сервер присылает большой случайный challenge, аутентификатор подписывает его закрытым ключом, и подпись доказывает владение, не раскрывая никакого секрета, — как отмечено в спецификации Mozilla. Прокси может переслать подпись дальше, но настоящий сайт тогда увидит ответ, претендующий на origin, который он никогда не обслуживал, с данными, привязанными к идентификатору проверяющей стороны, который он как раз на это и проверяет. Ни кода, гонящегося с тридцатисекундным таймером, ни cookie, отчеканенного на стороне атакующего.