Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и информационной безопасности, преподаю в учебных центрах и пишу статьи и книги.

В новостях мы периодически можем увидеть сообщения о том, что та или иная компания была взломана хакерами, однако обычно, сколько-нибудь значительных технических подробностей не приводится. В этой статье мы попробуем исправить эту оплошность и приведем технический разбор атаки на цепочку поставок компании Salesoft Drift. 

Salesloft Drift представляет собой платформу для интеграции ИИ-чат-бота Drift с инстансом Salesforce. Она позволяет организациям синхронизировать разговоры, лиды и обращения в поддержку со своей CRM.

В августе 2025 года группировка UNC6395, получив доступ к GitHub-репозиторию Salesloft, смогла переместиться в облако компании и похитила OAuth refresh-токены Salesforce, которыми владело приложение Drift. С 8 по 18 августа злоумышленники использовали эти легитимные токены для обхода MFA и политик доступа, осуществив масштабное похищение данных у более чем 700 организаций. Причем, здесь речь идет не о какой-то Zero-day уязвимости, а компрометации всей цепочки доверия нечеловеческих идентичностей (NHI).

В отличие от людей, NHI (сервисные аккаунты, API-ключи, ИИ-агенты) работают автоматически, и из-за этого возникает риск, так как неявное доверие к ним может привести к утечкам, и цепочка как раз помогает это контролировать.  При реализации взлома атакующие унаследовали легитимную личность Drift, которой «молча делегировали» права сотни арендаторов.

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

Разбор цепочки атаки

По данным проведенного после атаки расследования, атакующие получили доступ к GitHub-аккаунту Salesloft в период с марта по август 2025 года.

При этом, наблюдаемая активность включала в себя скачивание содержимого приватных репозиториев, добавление гостевых пользователей и создание новых GitHub workflows.

Первый этап представлял собой компрометацию репозитория, после которого атакующие  перемещались в связанную, но независимую среду приложения Drift. Ключевая слабость облачной среды, использованной Salesoft это жестко захардкоженные AWS-ключи, хранившиеся в доступном репозитории.

Здесь важно понимать, что это были не спящие vault-учётки, а «идентичности в транзите», активно используемые процессами деплоя.

Боковое перемещение в AWS и похищение токенов

Итак, атакующим удалось похитить учетные данные из GitHub, в результате чего, они смогли проникнуть в AWS-среду Drift. После этого они обнаружили главную цель, долгоживущие OAuth refresh-токены Salesforce, выданные для интеграции Drift.

И здесь, все становится еще интереснее, потому что Drift как Connected App в Salesforce имел права api, refresh_token, offline_access и обычно запрашивал полный набор scope. Эти refresh-токены хранились на стороне Salesloft в инфраструктуре интеграции, так что, их компрометация одновременно обнажала Salesforce-тенанты всех клиентов, у которых был включён Drift.

Обход всех человеческих контролей

Теперь, получив refresh-токен и consumer key/secret приложения Drift, атакующие могли бесконечно генерировать короткоживущие bearer-токены для доступа к клиентским эндпоинтам login.salesforce.com.

Однако, здесь необходимо было решить серьезную проблему использования OAuth-токенов. Дело в том, что данный токен представляет идентичность приложения, а не пользователя. А MFA, SSO и политики условного доступа Salesforce нацелены на человеческий вход и не применяются к NHI.

Помимо этого, политика refresh-токенов Salesforce по умолчанию действительна до отзыва, без каких-либо временных границ и большинство Connected App от ISV используют именно это значение.

При выполнении атаки API-вызовы атакующих маскировались под легитимный трафик Drift и в логах выглядели совершенно нормально. Но, при этом, нельзя сказать, что действия хакеров были совсем не видны стороне защиты. Так Cloudflare смогла увидеть действия атакующих внутри Salesforce.

Их целевые объекты запросов включали в себя тикеты, аккаунты клиентов, контакты и информацию о пользователях.

Также они смогли увидеть методы работы хакеров. В частности, было обнаружено выполнение SOQL-запросов с последующим экспортом результатов через Bulk API в виде пакетных заданий, и применение выделенного пользователя приложения Drift для экспорта. Хотя последнее атакующие и не пытались особо скрыть.

Атака по классике была распределена во времени. Так 9 августа была проведена начальная разведка, затем 13 августа масштабы разведки были расширены, и наконец 17 августа была выполнена финальная выгрузка данных.

Охота за секретами: истинная цель

Хотя похищение данных уже можно назвать существенным результатом, для атакующих оно не было конечной целью. Они выполнили постобработку извлечённых данных, разыскивая в текстах тикетов строковые паттерны следующего вида:

AKIA          → префикс AWS Access Key ID

password      → пароли в открытом виде

secret        → универсальные секреты

xoxb         → префикс Slack Bot Token

BEGIN PRIVATE KEY  → приватные ключи

snowflakecomputing.com  → учётные данные Snowflake

Стратегический замысел хакеров очевиден: они собирались использовать тикеты Salesforce как «склад» утечек учётных данных. Клиенты, обращаясь в поддержку, часто вставляют в текст кейса AWS-ключи, Snowflake-токены, пароли, и здесь атакующим не нужно взламывать AWS или Snowflake, вместо этого им просто достаточно найти ключи в тех данных, которые клиенты сами передали.

При этом, по данным Cloudflare, 104 API-токена были обнаружены в текстах тикетов, переданных клиентами, и компания ротировала все эти токены в течение 72 часов.

Антидетект и зачистка следов

Для того, чтобы скрыть свои действия атакующие использовали Tor, а после выполнения удалили выполненные query jobs. Также для снижения заметности они ограничили ритм запросов до пары запроса/сек на тенант, что не выходило за пороги аномалий Salesforce.

Salesforce Event Monitoring (платная надстройка, включённая у меньшинства клиентов) могла бы показать аномальную активность Bulk API от Connected App Drift, но Drift сам по себе является высокочастотным приложением, и активность атакующих скрылась в нормальном шуме.

Межплатформенный каскад

Атакующие не ограничились Salesforce и также воспользовались интеграцией Drift Email с Google Workspace, прочитав письма в «очень небольшом числе» почтовых ящиков. Google впоследствии отозвал токены Drift Email и сбросил интеграцию.

И здесь обнажается уже структурная проблема, а именно то, что один украденный токен позволяет одновременно получить доступ к двум платформам Tier-1 SaaS, поскольку обе используют один и тот же якорь доверия OAuth.

Выводы для защиты

Разобрав суть самой атаки перейдем к рассмотрению тех выводов, которые защитникам пришлось сделать после ее разбора. Начнем с управления жизненным циклом токенов. Здесь Refresh-токены Connected App в Salesforce не должны использовать политику по умолчанию «до отзыва». Вместо этого необходимо установить максимальный срок жизни (например, 30 или 90 дней и обеспечить принудительную регулярную ротацию. А кроме этого, регулярно проводить очистку неиспользуемых Connected App.

Сужение прав Connected App

Как мы упомянули ранее, в процессе описания атаки, Drift запрашивал полный scope, и клиенты при авторизации это не проверяли. Для того, чтобы предотвратить подобное, следует соблюдать принцип минимальных привилегий, то есть предоставляя только реально необходимые для бизнеса права.

Еще один важный момент, это то, что классический анализ поведения пользователей не обнаруживает злоупотребление NHI. И для выявления подобных активностей нужны специальные меры. Например, необходимо построить базовые профили поведения для каждого Connected App, а также оповещать об аномальных объёмах SOQL-запросов, API-вызовах из неожиданных IP-диапазонов и использовании токенов в нерабочее время. Также нужно включить NHI в систему управления идентичностями с назначением ответственного владельца и постоянным аудитом

Еще одним важным уроком атаки, является то, что все данные, добавленные в тикеты Salesforce, могут стать ключом для атакующего.  Для предотвращения подобных ситуаций нужно регулярно сканировать кастомные поля Salesforce, записи конфигурации и метаданные на предмет открытых учётных данных. Ну и не стоит забывать о цифровой гигиене при работе с тикетами. Например, нужно запретить вставку plaintext-ключей в тексты тикетов.

Также важно внедрить процессы быстрой ротации для потенциально скомпрометированных облачных учётных данных.

Итог

С технической точки зрения инцидент Salesloft Drift представляет собой похищение и повторное использование «идентичности». Атакующие не взламывали шифрование, не использовали zero-day, а просто унаследовали идентичность приложения, которой уже доверяли сотни организаций. Это признак зрелости атак на цепочки поставок SaaS: цель смещается от «взломать одного арендатора» к «взломать слой интеграции, которому доверяют многие.

Для тех, кто работает с ИБ на практике, разбор подобных инцидентов полезен не только как ретроспектива: он помогает понять, где появляются новые точки риска и какие меры стоит пересматривать в своих системах. Продолжить тему можно на двух бесплатных вебинарах Otus:

• 6 октября в 20:00. «Безопасность ИИ-агентов: новые векторы атак и практики защиты». Записаться

• 19 октября в 20:00. «ИБ-законодательство: ключевые изменения лета–осени 2026». Записаться