В последние месяцы исследователи информационной безопасности зафиксировали принципиальную эволюцию фишинговых атак. Традиционные методы, основанные на поддельных доменах и подозрительных адресах отправителей, уступают место новому подходу. Злоумышленники больше не строят собственную инфраструктуру - они используют те облачные сервисы, которым организации доверяют по умолчанию. Это меняет правила игры для всей отрасли.
Описание
Новый класс угроз получил название Trusted Infrastructure Phishing, или сокращённо TIP. В переводе на русский это означает "фишинг с использованием доверенной инфраструктуры". Речь идёт не об отдельной технике, а о целой операционной доктрине. Атакующие проводят все этапы атаки - от доставки письма до закрепления в сети - исключительно через легитимные облачные платформы. Это могут быть хранилища данных, офисные пакеты, сервисы автоматизации рабочих процессов, API календарей и системы аутентификации. Вредоносный замысел не порождает никаких аномалий на уровне инфраструктуры. Атака выглядит как обычный трафик, потому что на сетевом уровне она им и является.
Чтобы понять, почему TIP стал доминирующей моделью, нужно взглянуть на предшествующие изменения. Фишинг с использованием вредоносных вложений и макросов терял эффективность по мере совершенствования антивирусных средств и почтовых фильтров. В ответ злоумышленники переключились на кражу учётных данных и токенов доступа. Им больше не нужны файлы, которые можно обнаружить. Параллельно компании массово внедрили облачные платформы вроде Microsoft 365 и Google Workspace. Они потратили огромные средства на защиту конечных точек и почтовых шлюзов. Но почти не уделили внимания управлению разрешениями OAuth-приложений, потокам аутентификации через код устройства и контролю доступа к облачным хранилищам. Именно эту брешь и нашли злоумышленники.
В новом исследовании специалисты подробно описали пять стадий атаки. На первом этапе фишинговое письмо отправляется не с подозрительного сервера, а через легитимные облачные сервисы автоматизации рабочих процессов. Такие сообщения проходят все проверки подлинности - SPF, DKIM и DMARC - без каких-либо изменений, потому что их действительно отправляет почтовая система провайдера. Шлюзы электронной почты, оценивающие репутацию отправителя, просто не видят повода для блокировки. Содержание письма тщательно подобрано: уведомление о задаче, запрос на согласование документа, оповещение о платеже. Всё выглядит как обычное внутреннее сообщение, на которое сотрудник привык реагировать без лишних вопросов.
На втором этапе жертву перенаправляют на фишинговую страницу, размещённую в легальном облачном хранилище. Это может быть Azure Blob Storage, SharePoint или OneDrive. Эти сервисы имеют действующие SSL-сертификаты на весь домен провайдера. Браузер показывает зелёный замок и знакомое имя хоста. URL-фильтры и прокси, проверяющие репутацию ссылок, не находят ничего подозрительного - домен принадлежит Microsoft. Страница выглядит как точная копия интерфейса входа в систему с корпоративной символикой.
Третий этап - самый технически сложный. Вместо размещения фишинговой страницы на сервере атакующие конструируют её прямо в браузере жертвы. Они используют встроенные JavaScript-функции для создания Blob-объекта (двоичного объекта, хранящегося в памяти). Страница никогда не передаётся по сети как HTTP-ответ. Она существует только в оперативной памяти браузера в виде адреса blob:https://. Ни один файл не записывается на диск. Ни одна запись в прокси-логах не фиксирует запрос к фишинговой странице. Единственным артефактом остаётся первоначальный запрос к файлу-загрузчику, который сам может быть размещён на безобидном ресурсе.
Четвёртый этап нацелен на кражу OAuth-токенов и обход многофакторной аутентификации (MFA). Исследователи выявили два активных метода. Первый - атака "злоумышленник посередине". Обратный прокси-сервер встраивается между жертвой и легитимным сервером аутентификации. Он ретранслирует весь процесс входа в реальном времени. Жертва проходит полноценную проверку с MFA, но прокси перехватывает полученную сессионную cookie и использует её для доступа к облачной среде. Со стороны провайдера аутентификация выглядит совершенно законной. Второй метод использует механизм Device Authorization Grant (поток аутентификации для устройств с ограниченным вводом). Атакующий инициирует поток, получает код устройства, а затем в письме просит жертву ввести этот код на официальном портале провайдера. Жертва, думая, что проходит обычную процедуру, предоставляет токен доступа и токен обновления. Ни в одном из методов атакующий не знает пароля жертвы. MFA не помогает. В журналах входа фиксируется рядовая успешная аутентификация.
Пятый этап - жизнь в облаке после компрометации. Получив доступ, злоумышленники не переходят на внешнюю инфраструктуру. Они остаются внутри облачной среды жертвы и используют её легитимные сервисы как операционную платформу. В течение нескольких минут после получения доступа создаются правила для обработки почты: пересылка писем, тихое удаление, сортировка по ключевым словам. Это позволяет закрепиться в системе без каких-либо файловых артефактов. В более сложных случаях скомпрометированный облачный арендатор превращается в фишинговую инфраструктуру для атак на деловых партнёров. Государственные хакеры, как отмечается в отчёте, даже создавали скрытые каналы управления через легитимные API календарей. Команды управления встраивались в обычные вызовы календаря, которые на сетевом уровне неотличимы от штатной работы приложений.
Последствия таких атак значительны. В расследованных инцидентах многофакторная аутентификация не смогла защитить организации. В ряде случаев в SIEM-системах (классе программ для сбора и корреляции событий безопасности) в момент компрометации не было ни одного аномального события. Токен доступа атакующего выглядел так же, как токен легитимного пользователя. О вторжении узнавали только при посмертном анализе, иногда спустя недели после первоначального доступа. Для обнаружения таких атак требуются принципиально иные методы: поведенческий анализ почтового трафика, мониторинг событий blob:https:// в браузерах, отслеживание необычных запросов на аутентификацию через код устройства и создание базовых профилей нормального поведения SaaS-приложений.
Новый фишинг не просто обходит защиту - он становится неотличимым от обычной работы. Организациям придётся пересмотреть саму архитектуру своей безопасности, сместив фокус с периметра на поведенческие аномалии внутри доверенных облачных сред.
Индикаторы компрометации
IPv4
- 104.238.159.149
- 107.191.58.76
- 13.107.213.38
- 13.107.246.38
- 20.44.241.109
- 96.9.125.147
