Журнал "Information Security/ Информационная безопасность" #2, 2026

Причина, по сути, связана не с отсут- ствием MFA, а с изменением самих атак. Фишинг уже перестал быть просто попыткой выманить пароль через под- дельную форму входа – злоумышленни- ки активно используют атаки типа Adver- sary-in-the-Middle (AiTM). В этом сценарии фишинговый сайт выступает посредни- ком между пользователем и реальным сервисом, проксируя процесс аутенти- фикации. Выглядит это так. Пользователь вво- дит учетные данные на фишинговом сайте и подтверждает вход вторым фак- тором, полагая, что взаимодействует с легитимным сервисом. Однако посколь- ку вся процедура проходит через инфра- структуру атакующего, злоумышленник получает не только пароль, но и актив- ную сессию пользователя. Как видно, факт сам по себе использования MFA не предотвращает компрометацию. Поэтому в профессиональной среде появился термин Phishing-Resistant MFA – многофакторная аутентификация, устой- чивая к фишинговым атакам. Почему так получилось? Большинство распространенных фак- торов аутентификации создавались во времена, когда основной угрозой счита- лась кража пароля. Второй фактор дол- жен был подтвердить, что пользователь действительно владеет устройством или каналом связи. Однако архитектура тех решений допускает воспроизведение фактора вне контекста конкретного сер- виса. Код из СМС, одноразовый пароль из приложения-аутентификатора или пуш-подтверждение могут быть введены на любом сайте. С точки зрения системы они выглядят корректно, если введены в допустимый интервал времени. Именно этим пользуются атакующие в сценариях проксирования аутентификации. Другими словами, проблема в том, что традиционная MFA не проверяет, где именно пользователь проходит про- цедуру входа. Если злоумышленник спо- собен принять запрос от пользователя и передать его настоящему сервису в реальном времени, второй фактор будет принят так же, как и при легитимном входе. Да, традиционная MFA по-прежнему защищает, например, от перебора паро- лей или от утечек учетных данных. Но при этом они оказываются уязвимыми к современному фишингу. Phishing-Resistant MFA Термин Phishing-Resistant MFA описы- вает принципиально иной подход к аутен- тификации. Здесь важен не просто вто- рой фактор, а архитектура подтвержде- ния личности пользователя. Главное отличие заключается в том, что подтверждение входа привязывается к конкретному домену сервиса и кон- кретному устройству. Устройство поль- зователя получает запрос от сервиса и выполняет его криптографическую под- пись запроса. Если пользователь находится на под- дельном сайте, подпись не будет сфор- мирована. Устройство проверяет адрес ресурса и не позволит использовать ключ для другого домена. Таким обра- зом, посредник не может воспроизвести процедуру аутентификации. На практике такие механизмы обычно реализуются на базе стандартов FIDO2 и WebAuthn. Они используют пару крип- тографических ключей: закрытый ключ хранится на устройстве пользователя, а открытый ключ – на стороне сервиса. Закрытый ключ никогда не передается в инфраструктуру аутентификации и не может быть извлечен злоумышленником. Именно поэтому подобные методы счи- таются устойчивыми к фишинговым ата- кам. Даже если пользователь попадает на поддельный сайт, злоумышленник не получает пригодный для использова- ния второй фактор. Внедрение Phishing-Resistant MFA обычно строится вокруг аппаратных или платформенных аутентификаторов. Это могут быть физические ключи безопас- ности, а также встроенные механизмы устройств, например TPM или Secure Enclave. При регистрации пользовательского устройства создается уникальная пара ключей. Закрытый ключ остается на устройстве и используется для подписи запросов аутентификации. Открытый ключ сохраняется в системе управления идентификацией и используется для проверки подписи. При попытке входа сервис формирует криптографический вызов. Устройство пользователя подпи- сывает его закрытым ключом и возвра- щает результат. Если подпись корректна, система подтверждает аутентификацию. В корпоративной инфраструктуре такие решения, как правило, интегри- руются с существующими каталогами пользователей и системами управления доступом. Чаще всего речь идет о взаи- модействии с каталогами учетных запи- сей, корпоративными приложениями и инфраструктурой удаленного доступа. Впрочем, криптография – безусловно надежный, но не единственный способ бороться с AiTM-атаками. Второй меха- низм – разделение каналов передачи аутентификационных данных: в одном происходит передача логина и пароля, а во втором – подтверждение второго фактора. Например, пользователь вво- дит логин и пароль в браузере, а под- тверждение второго фактора выполняет через отдельное мобильное приложение. Но при этом важно, чтобы запрос на второй фактор инициировался доверен- ной системой через защищенный API. Отметим, что на практике даже если современная аутентификация исполь- зуется для основных сервисов, уязви- мости могут сохраняться из-за наследо- ванных компонентов инфраструктуры (то что называют термином "легаси"). Наиболее типичными проблемами ста- новятся: l использование резервных методов входа через СМС или одноразовые коды; l наличие устаревших протоколов доступа; 46 • СПЕЦПРОЕКТ Многофакторная аутентификация, устойчивая к фишингу ногие уже внедрили второй фактор для доступа к корпора- тивным сервисам, это практически стандарт в ИБ. И, каза- лось бы, проблема компрометации учетных записей должна была заметно сократиться. Однако согласно статистике, атаки на учетные записи продолжают оставаться одним из наиболее распространенных сценариев компрометации. М Виктор Чащин, директор по стратегическому развитию, МУЛЬТИФАКТОР Фото: МУЛЬТИФАКТОР