фишинг
Облачные платформы, вроде Cloudflare Workers, Netlify и GitHub Pages, очень удобны, когда требуется быстро и недорого запустить сайт или веб-приложение. Не нужно платить за собственные серверы, настраивать инфраструктуру и базовые средства защиты. Правда, пользуются этими преимуществами не только законопослушные разработчики. Злоумышленники создают на облачных платформах фишинговые страницы, с помощью которых за несколько шагов могут похитить сессию авторизованного пользователя, даже если его учетная запись защищена многофакторной аутентификацией (MFA). В посте рассказываем, какие платформы чаще всего используют злоумышленники, как они обходят защитные механизмы и что нужно компании, чтобы не стать жертвой сложной целевой атаки.
Облачные платформы в руках хакеров
Облачные платформы служат для злоумышленников удобным инструментом, чтобы быстро и с минимальными затратами развернуть фишинговый сайт, веб-приложение или отдельную страницу. Так, на многих из них действуют бесплатные тарифы, а регистрация занимает считаные минуты и часто не требует дополнительной верификации. Это значит, что в случае блокировки одного аккаунта любой пользователь может сразу создать новый.
Опасность заключается в том, что инструменты, полагающиеся на фиды фишинговых адресов, скорее всего, не распознают опасный ресурс: поддомены создаются с такой скоростью, что вендоры защитных решений далеко не всегда успевают отследить и внести их в список блокируемых. Помогают злоумышленникам и встроенные механизмы защиты облачных платформ, позволяющие скрыть реальный IP сервера. На внимательность пользователей тоже не стоит рассчитывать: даже если кто-то и обратит внимание на адрес страницы, то знакомый домен не вызовет подозрений.
Один из наиболее опасных сценариев использования вредоносных доменов на известных облачных платформах — атака с применением техники Adversary-in-the-Middle (AiTM, разновидность Man-in-the-Middle). Используя фишинговую страницу, злоумышленник встраивается в коммуникацию между пользователем и легитимным сервисом. Когда жертва входит в свой аккаунт, атакующий перехватывает сессионный токен, который подтверждает уже пройденную аутентификацию и позволяет использовать активную сессию пользователя. Никакая MFA от такой атаки не спасет.
Подобная утечка учетных данных может долго оставаться незамеченной, а злоумышленник тем временем успевает продать их в даркнете. Если данные окажутся в руках опытных хакеров, например APT-группировки, компания может столкнуться с длительной целевой атакой. Злоумышленники получат возможность нарушить работу критических систем и сервисов или похитить информацию, представляющую коммерческую или технологическую ценность.
Как проходит атака с применением AiTM
Рассмотрим подробнее, как выглядит AiTM-атака, о которой мы говорили выше, на примере реально выявленного нашими экспертами кейса. Если вам интересен детальный разбор механики с фрагментами кода, то вы можете найти его на экспертном блоге Securelist.
Этап 1. Выбор жертвы
Первым делом злоумышленник рассылает потенциальным жертвам фишинговые письма с вредоносной ссылкой. Предлог может быть самым стандартным, например просьба подписать некие рабочие документы. Из огромной базы, по которой ведется рассылка, фишеру нужно выделить действительно используемые адреса. Именно поэтому ссылка из письма ведет не сразу на основной фишинговый ресурс, а на страницу с псевдокапчей, где нужно ввести e-mail.
Чтобы не вызвать подозрений ни у пользователя, ни у защитных инструментов, злоумышленники, как правило, используют на этом этапе взломанные легитимные сайты. При этом даже если «песочница» или анализатор зафиксируют нарушение и HTML-страница будет заблокирована, то злоумышленник почти ничего не потеряет — такие ресурсы используются как расходники.
Ложная капча запрашивает электронную почту пользователя
Разобравшись с «капчей», пользователь переходит на вторую страницу, созданную с помощью облачной платформы.
Этап 2. Создание прозрачного прокси
Здесь тоже капча, но уже настоящая — в отличие от первой, она не собирает персональные данные, а защищает фишинговую страницу от краулеров. После прохождения проверки в браузере жертвы запускается скрипт для перехвата трафика и разворачивается специальная библиотека для создания веб-прокси. Так формируется прозрачный прокси, за счет которого все данные, введенные пользователем на следующем этапе, автоматически продублируются злоумышленнику. Подтвердив, что он не робот, пользователь попадает на третью страницу.
После прохождения второй капчи в браузере жертвы создается прозрачный прокси
Этап 3. Подмена окна браузера
Теперь к подмене трафика добавляется подмена интерфейса (Browser-in-the-Browser, BiTB). Суть в том, что внутри легитимной веб-страницы открывается блок, стилизованный под настоящее всплывающее окно. Внутри него загружается реальная форма авторизации (например, на сайте Microsoft). Когда жертва вводит логин, пароль и код MFA внутри такого «браузера в браузере», прокси-скрипт перехватывает учетные данные и сессионные токены.
Данные, которые пользователь вводит в реальной форме авторизации, дублируются злоумышленнику
После успешной аутентификации прокси отправляет команду на закрытие окна и перекидывает жертву на страницу с системной ошибкой, например Session Expired. Этот шаг вновь направлен на то, чтобы усыпить бдительность пользователя. Жертва думает, что произошел технический сбой, и пытается войти снова, в то время как мошенник уже получил полный доступ к сессии и может продолжить атаку внутри корпоративной сети.
Немного расскажу о секретах маскировки фишеров. На первом этапе почтовый адрес передается в хеше URL, чтобы следующая страница могла получить его без обращения к серверу злоумышленника. Вторая страница извлекает e-mail жертвы из хеша URL и сохраняет во временном хранилище браузера. Формируя URL-адрес для переадресации на третью страницу, скрипт злоумышленника возвращает сохраненный e-mail из временного хранилища в хеш. На третьей странице почтовый адрес автоматически подставляется в качестве логина в соответствующую форму в окне BiTB. Предполагается, что предзаполненное поле сделает внешний вид страницы более убедительным. Таким образом, почтовый адрес может быть передан через хеш три этапа подряд, ни разу не попав на радары систем детектирования сетевых атак.
«Облачный фишинг» в цифрах
За последние 12 месяцев (с июля 2025 года по июнь 2026 года) мы выявили почти 400 тыс. ссылок на фишинговые страницы, размещенные на популярных облачных платформах и в децентрализованных сетях. Чаще всего злоумышленники используют домены pages.dev и vercel.app — присваивающие их платформы Cloudflare и Vercel предлагают бесплатные тарифы, автоматическую выдачу SSL-сертификатов и глобальные CDN. В топ-3 с незначительным отрывом вошел также github.io (платформа GitHub Pages). На нем размещено множество легитимных проектов, поэтому массовая блокировка фишинговых страниц была бы невозможна без ущерба для добросовестных пользователей.
Популярностью пользуется и децентрализованная сеть IPFS (InterPlanetary File System, «межпланетная файловая система»). Используя этот протокол связи, злоумышленник может размещать фишинговые страницы прямо у себя на компьютере и предоставлять доступ к ним через специальный IPFS-шлюз. Такими шлюзами являются домены dweb.link и ipfs.io (пятое и шестое место). Главная опасность заключается в том, что даже при блокировке одного шлюза фишинговая страница остается доступной через другие узлы сети.
В десятку лидеров также вошли визуальные конструкторы Wix и Webflow. На них можно довольно быстро создавать страницы без глубоких знаний кода, что снижает порог входа для злоумышленников, не слишком подкованных с технической точки зрения.
Топ-3 домена по популярности у фишеров: pages.dev, vercel.app и github.io
Как защититься
Атаки с использованием облачных платформ не так просто разглядеть и остановить, поэтому подход к их предотвращению должен быть комплексным. Первый и самый очевидный шаг — это обеспечить нейтрализацию фишинговых ссылок еще до того, как их получат пользователи. Справиться с этой задачей поможет наше решение для корпоративной почты Kaspersky Secure Mail Gateway. Для многоуровневой защиты конечных устройств используйте Kaspersky Endpoint Security. Чтобы минимизировать риски возможных атаках, важно также научить сотрудников критически относиться к любому запросу на ввод учетных данных, даже если окно, запрашивающее почту, выглядит совершенно безопасным.
