Как легитимные облачные платформы помогают фишерам обходить многофакторную аутентификацию

Злоумышленники все чаще используют легитимные сервисы, чтобы избежать обнаружения и упростить создание мошеннической инфраструктуры. Особое место среди таких сервисов занимают облачные платформы и децентрализованные сети, на которых они размещают фишинговые страницы и сайты. В 2025–2026 годах наблюдается устойчивый переход фишеров на такие платформы, как Cloudflare Workers, Vercel, Netlify, GitHub Pages и IPFS. В этой статье мы не только разберем механику реальной AitM-атаки (Adversary-in-the-Middle) в облачной инфраструктуре, но и предоставим подробную статистику: какие именно платформы и домены злоумышленники выбирают для размещения фишинга чаще всего.

Облака как укрытия для фишеров

Причины, по которым злоумышленники выбирают PaaS (платформа как услуга) и другие облачные (или распределенные) сервисы для размещения фишинговых сайтов, во многом аналогичны тем, которыми руководствуются легальные разработчики.

• Доверие и репутация: фишинговые страницы, опубликованные на легитимных платформах, выглядят надежнее и вызывают меньше подозрений у потенциальных жертв.
• Доступность: большинство платформ предлагает бесплатные тарифы с щедрыми лимитами для разработчиков, а регистрация занимает минуты и часто проходит без процедуры KYC (Know Your Customer, или «Знай своего клиента», — процесс проверки личности пользователя), что позволяет одному злоумышленнику создать сотни аккаунтов.
• Защита и анонимность: мошенники используют встроенные механизмы защиты и скрывают реальный IP сервера за CDN, чтобы усложнить вендорам средств защиты задачу по их обнаружению.

Отдельно необходимо отметить, что подобные платформы предоставляют пользователям свои поддомены, на которых одновременно размещаются миллионы легитимных проектов и сайтов. Это делает блокировку домена или поддоменов невозможной без ущерба для добросовестных пользователей, чем активно пользуются злоумышленники. Для противодействия таким атакам вендорам необходимо развивать методы обнаружения угроз на основе анализа содержимого (контентный анализ).

Многоступенчатая AitM-атака

Рассмотрим современную фишинговую кампанию, построенную по схеме AitM с использованием популярной облачной платформы Cloudflare Workers. Атака реализуется через несколько HTML-страниц, размещенных злоумышленниками на взломанном сайте и на этой платформе. Каждая из страниц выполняет свою роль: сбор email-адресов жертв, инициализация прокси-инфраструктуры и подмена окна аутентификации для перехвата MFA-сессии.

Этап 1. Получение реальных контактов и обход сетевого мониторинга

В фишинговом письме злоумышленники, как правило, прибегают к убедительному предлогу, чтобы жертва перешла по ссылке. Это может быть, например, просьба коллеги посмотреть документы.

После перехода по фишинговой ссылке жертва попадала на страницу с псевдо-капчей, размещенной мошенником на легитимном взломанном сайте (в данной атаке использовался сайт вида https://t......e.com, но он может быть любым). В данном случае взломанная страница использовалась как расходный материал (как правило, вендоры быстрее блокируют фишинговые ссылки, полученные в письмах), чтобы не допустить быстрого обнаружения основного фишингового контента, размещенного на Cloudflare.

Если пользователь вводил email и нажимал кнопку Continue, такая фальшивая капча считала его человеком и перекидывала дальше. Основная цель этого этапа — собрать email-адреса, отсеять примитивных ботов и перенаправить реального пользователя на URL-адрес .workers.dev. Подобные адреса автоматически и бесплатно предоставляются на Cloudflare Workers. При этом email жертвы передавался в хэше URL (после знака решетки), чтобы страница по адресу  .workers.dev могла получить email без обращения к серверу злоумышленника и избежать обнаружения.

Этап 2. Инициализация прозрачного прокси

В браузере пользователя открывалась страница вида .workers.dev/.. #user@business.com. Жертве показывалась настоящая капча — на этом этапе злоумышленникам необходимо было убедиться, что страницу посещает реальный человек, а не песочница.

Еще одна капча, на этот раз настоящая

После прохождения капчи в браузере жертвы регистрировался Service Worker (сервис-воркер) — специальный JavaScript-файл, который работает в фоне и может перехватывать все сетевые запросы в текущей вкладке. Данный скрипт является фундаментом технологии прогрессивных веб-приложений (Progressive Web Apps, PWA) — он ускоряет загрузку данных и позволяет веб-приложению функционировать без интернета. Браузер рассматривает Service Worker как штатную работу сайта и при работе веб-ресурса по HTTPS не спрашивает подтверждения для начала работы скрипта.

На базе этого сервис-воркера разворачивалась легитимная библиотека Ultraviolet с открытым исходным кодом, предназначенная для создания веб-прокси. Злоумышленники использовали ее для динамической подмены на лету всех ссылок и форм на странице, чтобы запросы (включая ввод учетных данных на сайте Microsoft) шли не напрямую к оригинальным сервисам, а транзитом через сервер злоумышленников.

Сразу после загрузки страница извлекала email жертвы из хэша URL и сохраняла во временном хранилище браузера (sessionStorage), чтобы не затереть его при подгрузке капчи. Кроме того, это позволяло автоматически подставить логин в форму для заполнения логина. Вид предзаполненного поля повышал доверие жертвы и делал страницу более убедительной. После успешного прохождения капчи скрипт злоумышленника формировал URL-адрес для переадресации на третий шаг, возвращая сохраненный email из sessionStorage в хэш. Таким образом, email передавался через хэш три этапа подряд и не попадал на радары систем детектирования сетевых атак.

Регистрация Service Worker для перехвата трафика

Создание «прозрачного прокси» с помощью отдельной библиотеки

Этап 3. Перехват сессии с подменой окна браузера

Финальный этап таки разворачивался на третьей странице — к технике AitM (Adversary-in-the-Middle, атака на уровне трафика) здесь добавлялась BitB (Browser-in-the-Browser, атака на уровне подмены интерфейса). Суть техники BitB в следующем: внутри легитимной веб-страницы открывается блок, стилизованный под настоящее всплывающее окно.

В нашем случае скрипт, размещенный на странице злоумышленника, генерировал всплывающее окно, визуально идентичное системному окну браузера (вместе с поддельной адресной строкой, где указан доверенный URL Microsoft, и кнопками управления). Внутри этого окна в iframe загружалась реальная форма авторизации, проксируемая через настроенный на втором этапе Service Worker. Когда жертва вводила логин, пароль и код MFA внутри «браузера в браузере», прокси-скрипт перехватывал не только учетные данные, но и сессионные токены. Комбинация BitB с AitM делает атаку наиболее опасной, так как BitB создает доверенную визуальную оболочку (жертва видит правильный URL и логотипы), а спрятанный за этой оболочкой AitM-прокси выполняет работу по перехвату трафика и краже сессионных токенов.

После успешной аутентификации прокси отправляет команду на закрытие окна и перенаправляет жертву на страницу с системной ошибкой (например, SessionExpired). Это усыпляет бдительность пользователя: он думает, что произошел технический сбой, и пытается войти снова, в то время как злоумышленник уже получил полный доступ к сессии.

Статистика фишинговых атак на облачных платформах

Мы проанализировали фишинговые ссылки, размещенные на популярных облачных платформах (Cloudflare, Netlify, Github Pages и др.) за последние 12 месяцев (с августа 2025 года по июль 2026 года). Ниже представлена динамика количества уникальных доменов третьего уровня, через которые распространялся фишинговый контент. Наши решения в сумме за последние 12 месяцев заблокировали 224 984 уникальных домена третьего уровня на облачных и децентрализованных сервисах, используемых для фишинговых атак.

Количество уникальных доменов третьего уровня
(скачать)

На основе этих данных мы также сформировали TOP 10 облачных доменов, наиболее часто используемых в фишинговых кампаниях за указанный период.

Количество фишинговых ссылок

Безоговорочными лидерами стали платформы Cloudflare и Vercel, что закономерно: они предлагают бесплатные тарифы, автоматическую выдачу SSL-сертификатов и глобальные CDN. GitHub Pages также входит в тройку лидеров. Популярность домена github.io создает сложности для массовой блокировки фишинговых страниц на нем без риска ограничения доступа к легитимным проектам.

Отдельного внимания заслуживают децентрализованные сети (в 2023 году мы выпускали статью по этой теме): домены ipfs.io и dweb.link являются IPFS-шлюзами. Главная опасность таких платформ состоит в устойчивости контента: даже при блокировке одного шлюза фишинговая страница остается доступной через другие узлы сети.

Также в TOP 10 вошли визуальные конструкторы Wix и Webflow (8-е и 9-е места соответственно). Они позволяют быстро создавать фишинговые страницы без глубоких технических знаний кода, что снижает порог входа для менее подготовленных злоумышленников.

За последние 12 месяцев мы зафиксировали более 390 тысяч фишинговых страниц, размещенных на легитимных облачных платформах и в децентрализованных сетях (IPFS). Полученные данные подтверждают, что злоумышленники активно эксплуатируют доверие к легитимным PaaS-(Cloudflare Workers, Vercel, Netlify, GitHub Pages) и IPFS-сервисам. Высокая репутация этих платформ, бесплатные тарифы и встроенные средства маскировки позволяют фишерам эффективно развертывать многоступенчатые AitM атаки и перехватывать MFA-сессии.

Рекомендации

Традиционных методов защиты (вроде проверки «зеленого замочка» или блокировки доменов по черным спискам) в подобных случаях недостаточно. Основной домен провайдера остается доверенным, тогда как вредоносные поддомены создаются автоматически и массово.

Для противодействия подобным угрозам необходим комплексный подход.

• Проявляйте осторожность при неожиданных входящих запросах, даже если они поступают с доверенных доменов или страница отображает валидный SSL-сертификат.
• Как правило, капчи не запрашивают личные данные (в нашем случае email-адрес). Если просят пройти проверку на робота, указав личные данные, это, скорее всего, признак мошенничества.
• Внимательно проверяйте URL в адресной строке основного окна браузера (в самом верху окна). При атаках типа Browser-in-the-Browser злоумышленники могут нарисовать фейковое всплывающее окно и вписать в него любой адрес, в том числе легитимный. Однако реальная адресная строка, которая размещена в верху экрана и содержит кнопки навигации («Назад», «Вперед», «Обновить»), по-прежнему будет отображать реальный домен злоумышленника.
• Не вводите данные во внезапно появившиеся окна. Если форма ввода пароля или MFA-кода появилась без вашего явного действия, закройте вкладку и перейдите на нужный сервис вручную, введя адрес в браузере.
• Дополнительную защиту помогут обеспечить надежные решения для электронной почты, гарантирующие безопасность корпоративной (Kaspersky Secure Mail Gateway) и личной (Kaspersky Premium) переписки, нейтрализуя фишинговые ссылки еще на этапе доставки письма.