Фишинг через Google получил неприятный апгрейд: атакующие выстраивают цепочку редиректов через несколько легитимных сервисов Google, чтобы почтовые шлюзы и URL-сканеры видели «чистые» домены. Для русскоязычных IT-команд это не экзотика из чужой ленты, а напоминание: доверенный домен в ссылке больше не равен безопасной ссылке.
О продолжающейся кампании сообщает Dark Reading со ссылкой на исследование KnowBe4, опубликованное 4 сентября. Сценарий на поверхности выглядит буднично: пользователю приходит письмо под деловым предлогом, он кликает по ссылке, попадает на посадочную страницу и либо вводит учетные данные, либо запускает установку инструмента удаленного доступа. Отличие в маршруте: вместо одного подозрительного URL злоумышленники используют многоступенчатую цепочку переходов через инфраструктуру Google.
По данным KnowBe4, исследователи Прабхакаран Равичандхиран и Дживан Сингх Джалал описали трехшаговую схему редиректов, в которой фигурируют Google Meet, рекламная инфраструктура DoubleClick, Google Custom Search, Google Image Search, Google Tag Manager и Google Analytics. Смысл простой и неприятно практичный: когда защитный инструмент проверяет отправителя, вложенную ссылку или промежуточные переходы, он видит знакомые домены Google. Фильтр получает ровно то, что привык считать нормальным.
Сам прием с редиректами через легитимную инфраструктуру не новый. Им давно пользуются в фишинге, malvertising и атаках на корпоративную почту. Новое здесь — плотность «белой» обвязки: несколько сервисов Google используются последовательно, чтобы замаскировать конечную фишинговую страницу. Это усложняет жизнь не только автоматическим шлюзам, но и аналитикам SOC: при беглом разборе письмо выглядит менее токсичным, чем ссылка на свежезарегистрированный домен с набором случайных символов.
На финальной странице сценарии расходятся. В одних случаях жертве показывают фальшивую корпоративную форму входа и собирают логин с паролем. В других — через поддельную проверку личности запускают установку ScreenConnect, легитимного инструмента удаленного доступа, который в руках атакующего превращается в удобный канал закрепления в системе. Для бизнеса это особенно неприятная категория риска: RMM- и remote access-инструменты часто разрешены в инфраструктуре, поэтому их злоупотребление сложнее отличить от админской рутины.
Фишинговая страница тоже не выглядит собранной на коленке. После клика JavaScript динамически строит форму кражи учетных данных, используя один только email жертвы. За формой может появляться актуальный скриншот корпоративного сайта организации, чтобы пользователь видел знакомый визуальный контекст и меньше сомневался. Интерфейс поддерживает локализацию под местоположение жертвы. Иными словами, это уже не письмо «ваш аккаунт будет заблокирован» с кривым переводом, а персонализированная ловушка, рассчитанная на усталого сотрудника между двумя созвонами.
Темы приманок тоже разные: проверка документов, истечение срока действия учетных данных, доставка посылки, уведомление о платеже, государственные выплаты, голосовая почта. Такой набор удобен для атакующих: он покрывает офисные процессы, личные ожидания и финансовые триггеры. После ввода данных они, по наблюдениям KnowBe4, уходят оператору в Telegram-канал за считанные секунды вместе с IP-адресом, геолокацией, строкой браузера и подтвержденными MX-записями организации.
Еще одна важная деталь — адрес жертвы кодируется в base64 и прячется во фрагменте URL после символа #. Браузеры не отправляют этот фрагмент на сервер, поэтому он часто не попадает в серверные логи и остается невидимым для части URL-сканеров. Для защитников это сигнал: если в ссылке после # спрятан email или похожая на него строка, перед вами может быть не массовая рассылка «на удачу», а заранее подготовленный фишинг через Google против конкретного адресата.
Практические выводы здесь приземленные. Командам безопасности стоит проверять не только домен первого перехода, но и всю цепочку до конечной посадочной страницы, где это возможно. KnowBe4 рекомендует блокировать индикаторы компрометации на уровне DNS-фильтров, прокси и SIEM, искать обращения к Telegram Bot API, сбрасывать пароли пользователей, которые могли получить такие письма, и отдельно охотиться за несанкционированными установками ScreenConnect. Пользователям, в свою очередь, нужно объяснять не абстрактное «не кликайте по подозрительному», а конкретный прием с URL-фрагментом и доверенными промежуточными доменами.
Для разработчиков и продуктовых команд это еще один аргумент в пользу нормальной защиты аккаунтов: MFA, устойчивой к фишингу, ограничений на удаленный доступ, контроля новых RMM-инсталляций и аккуратной телеметрии по переходам. Пока корпоративная почта остается главным входом в рабочий день, атакующие будут не ломать дверь, а приносить бейджик с логотипом Google. Следующий виток борьбы пройдет не вокруг вопроса «можно ли доверять домену», а вокруг умения быстро понять, кто и зачем ведет пользователя через этот домен дальше.