Облачные платформы стали привычным инструментом для быстрого запуска сайтов и приложений — ими ежедневно пользуются миллионы разработчиков по всему миру. Однако те же преимущества, что делают эти сервисы удобными для законопослушных пользователей, привлекают и злоумышленников. Фишеры всё чаще разворачивают поддельные страницы входа именно на облачных площадках, маскируя свои ресурсы под знакомые домены и обходя даже многофакторную аутентификацию
Облачные сервисы вроде Cloudflare Workers, Netlify и GitHub Pages отлично подходят для быстрого и дешевого запуска сайтов и веб-приложений. Не нужно тратиться на собственные серверы, настраивать инфраструктуру и базовые системы защиты. Однако этими возможностями пользуются не только добросовестные разработчики. Преступники разворачивают на облачных площадках фишинговые страницы, которые позволяют за несколько шагов украсть сессию авторизованного пользователя, даже если его аккаунт защищен многофакторной аутентификацией (MFA).
Облачные платформы как инструмент хакеров
Для злоумышленников облачные сервисы — это удобный способ быстро и с минимальными затратами развернуть фишинговый сайт, веб-приложение или отдельную страницу. Многие платформы предлагают бесплатные тарифы, регистрация занимает минуты и зачастую не требует дополнительной проверки. Это означает, что при блокировке одного аккаунта пользователь может мгновенно создать новый.
Опасность в том, что инструменты, ориентированные на фиды фишинговых адресов, скорее всего, не заметят вредоносный ресурс: поддомены появляются так быстро, что производители защитных решений не всегда успевают их отследить и добавить в черные списки. Злоумышленникам помогают и встроенные механизмы защиты облачных платформ, скрывающие реальный IP сервера. На внимательность пользователей тоже рассчитывать не стоит: даже если кто-то и посмотрит на адрес страницы, знакомый домен не вызовет подозрений.
Один из самых опасных сценариев использования вредоносных доменов на известных облачных платформах — атака с применением техники Adversary-in-the-Middle (AiTM, разновидность Man-in-the-Middle). Через фишинговую страницу злоумышленник вклинивается в обмен данными между пользователем и легитимным сервисом. Когда жертва входит в аккаунт, атакующий перехватывает сессионный токен, который подтверждает пройденную аутентификацию и позволяет использовать активную сессию. Никакая MFA от такой атаки не спасет.
Подобная утечка учетных данных может долго оставаться незамеченной, а злоумышленник тем временем успевает продать их в даркнете. Если данные попадут к опытным хакерам, например к APT-группировке, компания может столкнуться с затяжной целевой атакой. Злоумышленники получат возможность нарушить работу критических систем и сервисов или похитить информацию, представляющую коммерческую или технологическую ценность.
Как проходит атака с применением AiTM
Сначала злоумышленник рассылает потенциальным жертвам фишинговые письма с вредоносной ссылкой. Повод может быть самым обычным, например просьба подписать рабочие документы. Из огромной базы рассылки фишеру нужно выделить действительно используемые адреса. Именно поэтому ссылка из письма ведет не сразу на основной фишинговый ресурс, а на страницу с псевдокапчей, где нужно ввести e-mail.
Чтобы не вызвать подозрений ни у пользователя, ни у защитных инструментов, злоумышленники на этом этапе обычно используют взломанные легитимные сайты. При этом даже если «песочница» или анализатор зафиксируют нарушение и HTML-страница будет заблокирована, злоумышленник почти ничего не потеряет — такие ресурсы используются как расходники.
Далее создается прозрачный прокси. Здесь тоже капча, но уже настоящая — в отличие от первой, она не собирает персональные данные, а защищает фишинговую страницу от краулеров. После прохождения проверки в браузере жертвы запускается скрипт для перехвата трафика и разворачивается специальная библиотека для создания веб-прокси. Так формируется прозрачный прокси, благодаря которому все данные, введенные пользователем на следующем этапе, автоматически дублируются злоумышленнику. Подтвердив, что он не робот, пользователь попадает на третью страницу.
Теперь к подмене трафика добавляется подмена интерфейса (Browser-in-the-Browser, BiTB). Суть в том, что внутри легитимной веб-страницы открывается блок, стилизованный под настоящее всплывающее окно. Внутри него загружается реальная форма аутентификации (например, на сайте Microsoft). Когда жертва вводит логин, пароль и код MFA внутри такого «браузера в браузере», прокси-скрипт перехватывает учетные данные и сессионные токены. Мошенники используют прозрачный прокси: данные, которые пользователь вводит в реальной форме аутентификации, дублируются злоумышленнику.
После успешной аутентификации прокси отправляет команду на закрытие окна и перекидывает жертву на страницу с системной ошибкой, например Session Expired. Этот шаг снова направлен на то, чтобы усыпить бдительность пользователя. Жертва думает, что произошел технический сбой, и пытается войти снова, в то время как мошенник уже получил полный доступ к сессии и может продолжить атаку внутри корпоративной сети.
За последний год было выявено почти 400 тыс. ссылок на фишинговые страницы, размещенные на популярных облачных платформах и в децентрализованных сетях. Чаще всего злоумышленники используют домены pages_dev и vercel_app — присваивающие их платформы Cloudflare и Vercel предлагают бесплатные тарифы, автоматическую выдачу SSL-сертификатов и глобальные CDN. В топ-3 с небольшим отрывом вошел также github_io (платформа GitHub Pages). На нем размещено множество легитимных проектов, поэтому массовая блокировка фишинговых страниц была бы невозможна без ущерба для добросовестных пользователей.
Популярностью пользуется и децентрализованная сеть IPFS (InterPlanetary File System). Используя этот протокол связи, злоумышленник может размещать фишинговые страницы прямо у себя на компьютере и предоставлять доступ к ним через специальный IPFS-шлюз. Такими шлюзами являются домены dweb_link и ipfs_io (пятое и шестое место). Главная опасность заключается в том, что даже при блокировке одного шлюза фишинговая страница остается доступной через другие узлы сети.
Как защититься
Атаки с использованием облачных платформ не так просто разглядеть и остановить, поэтому подход к их предотвращению должен быть комплексным. Первый и самый очевидный шаг — обеспечить нейтрализацию фишинговых ссылок еще до того, как их получат пользователи. Справиться с этой задачей поможет решение для корпоративной защиты почты. Чтобы минимизировать риски возможных атак, важно также научить сотрудников критически относиться к любому запросу на ввод учетных данных, даже если окно, запрашивающее почту, выглядит совершенно безопасным.
По материалам Касперский