С 14 по 26 октября злоумышленники использовали скомпрометированные IAM-учётные данные платформы Qubole, чтобы проникать в AWS-окружения её клиентов и выгружать данные из доступных S3-бакетов. Доступ Qubole к AWS оказался достаточно широким, чтобы затронуть десятки компаний: история важна не взломом самого облака, а тем, как одна доверенная интеграция превратилась в точку входа для чужих аккаунтов.
По данным BleepingComputer, атакующие получили контроль как минимум над двумя IAM-пользователями, связанными с AWS-аккаунтом Qubole. Qubole — корпоративная платформа обработки больших данных и аналитики, которая помогает запускать вычислительные и ML-нагрузки в облаке. Её клиенты могли заранее создать межаккаунтные IAM-роли, разрешающие аккаунту поставщика временно принимать эти роли через механизм AWS STS AssumeRole. Именно эти старые или малоиспользуемые доверительные связи и стали маршрутом атаки.
Схему обнаружили специалисты Wiz после сигналов от компании Sentra, работающей с защитой и управлением данными; к расследованию также подключилась Mandiant. Исследователи не раскрыли способ компрометации учётных записей Qubole и точное число пострадавших. Sentra, однако, подтвердила десятки жертв и сообщила, что только у одного клиента были похищены миллионы файлов.
Технически атака не требовала экзотического эксплойта. Получив права внешнего AWS-аккаунта, злоумышленник принимал разрешённую ему роль в окружении клиента и действовал в пределах выданных ей полномочий. Затем он проверял доступные ресурсы, искал секреты в AWS Secrets Manager и SSM Parameter Store, а также читал переменные окружения AWS Lambda. В облачных командах такие переменные нередко содержат токены, ключи к API и параметры подключения: удобная практика для быстрого деплоя, которая в инциденте быстро становится удобной и для атакующего.
От доверенной роли — к массовой выгрузке
Найденные учётные данные проверялись с помощью TruffleHog. Среди них были ключи AWS, клиентские секреты Microsoft Entra ID и реквизиты приложений Okta. Это позволяло расширять доступ уже за пределами первоначальной роли. По оценке Sentra, атакующие извлекали около 100 паролей и ключей за семь минут — темп, при котором ручная реакция после первых алертов рискует оказаться запоздалой.
Дальше кампания выглядела почти механически: список бакетов, перечисление объектов, проверка метаданных, затем скачивание файлов. Исследователи Wiz описывают подход как оппортунистический: злоумышленники не искали один конкретный набор данных, а забирали содержимое всех S3-бакетов, до которых позволяли дотянуться права роли. Для бизнеса это неприятный, но полезный критерий оценки ущерба: если роль умеет читать весь бакет, нельзя рассчитывать, что атакующий ограничится несколькими интересными каталогами.
В AWS подчеркнули, что сервисы компании не были скомпрометированы и сработали штатно: угрозу создали учётные данные третьего поставщика и настройки доверия, выбранные самими клиентами. Это не попытка снять ответственность с провайдера, а точное описание модели shared responsibility. Межаккаунтная роль нужна многим SaaS-платформам, подрядчикам по данным и MSP, но её доверительная политика — не формальность, которую можно настроить при внедрении и забыть на годы.
Что проверить командам, использующим внешние AWS-интеграции
Администраторам, у которых Qubole имела или всё ещё имеет доступ, рекомендовано изучить CloudTrail начиная с 1 октября: прежде всего вызовы AssumeRole от аккаунта поставщика, а после них обращения к Secrets Manager, SSM, Lambda и S3. При признаках несанкционированной активности необходимо отозвать активные сессии ролей и заменить потенциально раскрытые ключи, пароли и клиентские секреты. Простая смена одного IAM-ключа здесь не закрывает проблему, если атакующий уже успел получить токены иных сервисов.
Для российских команд вывод шире конкретного поставщика. Доступ Qubole к AWS — лишь наглядный пример того, что надо регулярно инвентаризировать все внешние principals в trust policy: SaaS для аналитики, CI/CD, подрядчиков, системы резервного копирования и сервис-дески. Неиспользуемые интеграции стоит удалять, а активным ролям выдавать только минимальные права. AWS отдельно советует ограничивать доверие условиями, включая разрешённые исходные IP-адреса; там, где это возможно, полезны также короткие сессии, отдельные роли для разных задач и уведомления о необычных AssumeRole-цепочках.
Этот инцидент добавляет веса не новой технологии защиты, а дисциплине доступа. Чем больше облачный ландшафт опирается на внешние сервисы, тем ценнее становится не список подключённых продуктов, а ответ на скучный вопрос: кто именно может принять каждую роль и что он сумеет прочитать в первые десять минут. Доступ Qubole к AWS показал, что у этого вопроса может быть очень дорогой ответ.
