Атака на AWS интеграции стороннего сервиса Qubole позволила неизвестным злоумышленникам проникать в клиентские аккаунты и забирать секреты из Lambda, Secrets Manager, SSM Parameter Store и бакетов S3. Кампания началась как минимум 14 октября, а её главный урок для команд, работающих с AWS: отключённый сервис не перестаёт быть риском, если доверенная IAM-роль всё ещё ждёт его вызова.
По данным The Register, расследование провели специалисты Wiz совместно с реагированием Mandiant после того, как компания Sentra заметила подозрительную активность. Qubole — платформа для обработки данных в облаке — использует кросс-аккаунтные IAM-роли: сервис получает ограниченный доступ к вычислительным и хранилищным ресурсам заказчика, не требуя от него постоянных AWS-ключей. Это удобная схема, пока учётные данные поставщика и политики доверия остаются под контролем. В этой истории скомпрометированным оказался именно внешний контур доверия.
Исследователи связали первые обращения к API sts:AssumeRole с аккаунтом Qubole AWS 805246085872. Через него атакующие запрашивали временные учётные данные для интеграционных ролей, созданных клиентами. В активности фигурировал IAM-пользователь AIDA3W7DIFLYOLTK63SFS; по наблюдениям Wiz, он не использовался ни для чего, кроме действий этой группы. Атака продолжилась 15 октября, а 18 октября злоумышленники задействовали второго IAM-пользователя из того же аккаунта.
После получения временной роли они не ограничивались проверкой доступности инфраструктуры. В пострадавших средах атакующие перечисляли ресурсы AWS и искали ключи, пароли, параметры и переменные окружения. Среди целей оказались AWS Secrets Manager, SSM Parameter Store и Lambda. Для проверки найденных AWS-учётных данных применялся TruffleHog. Кроме того, злоумышленники обнаруживали секреты Microsoft Entra ID и использовали найденные клиентские данные Okta для запроса OAuth-токенов. Иными словами, компрометация одной интеграционной роли могла стать входной точкой к идентификационному контуру компании, а не только к данным в одном облачном проекте.
Доступ к S3 использовался столь же прагматично. Wiz описывает кампанию как широкую и оппортунистическую: в отдельных случаях атакующие скачивали содержимое бакетов целиком, а не искали заранее определённые документы. Сколько организаций затронуто, исследователи не раскрыли, ограничившись формулировкой «несколько» клиентских сред. Атрибуции тоже нет: расследование не установило, какая именно группа стоит за операцией и как она намерена распорядиться похищенными данными.
Отдельно Wiz обнаружила ещё одну подозрительную активность — с 8 по 11 октября. В ней применялись принадлежащие клиентам AWS-ключи, связанные с интеграциями Qubole. Небольшое число таких эпизодов тоже закончилось компрометацией AWS-сред, однако исследователи не готовы однозначно объединить две кампании. Для защитников это неприятная, но важная деталь: расследовать стоит не только один известный индикатор, но и весь период, когда у интеграции существовали права и рабочие ключи.
Для российских DevOps- и security-команд эта атака на AWS интеграции — повод проверить не абстрактную «безопасность облака», а конкретный список доверенных сущностей. Кросс-аккаунтная роль живёт дольше продукта: сервис могли вывести из эксплуатации, контракт — закрыть, а запись в trust policy — забыть. В результате сторонний аккаунт сохраняет возможность вызвать AssumeRole, а организация часто узнаёт об этом только после инцидента. Особенно опасны роли с правами на чтение секретов, параметров, переменных Lambda и S3: они быстро превращают точечный доступ в каскадную компрометацию.
Клиентам Qubole Wiz рекомендует ротировать учётные данные и изучить CloudTrail начиная с 1 октября. Особое внимание следует уделить событиям AssumeRole, где userIdentity.accountId равен 805246085872, а также сессиям, пришедшим не с AWS IP-адресов. Для каждой найденной сессии нужно разобрать последующие обращения к Secrets Manager, SSM Parameter Store, Lambda и S3. Обычной ротации недостаточно: уже выпущенные временные сессии могут продолжать действовать, поэтому их необходимо отозвать, а все доступные роли секреты, параметры и переменные Lambda — заменить.
История Qubole показывает, почему инвентаризация SaaS-интеграций должна быть частью управления идентификацией, а не задачей «на потом» после миграции. Чем больше внешних аккаунтов имеют право принимать роли в AWS, тем важнее регулярно подтверждать необходимость каждого такого доверия, сужать разрешения и заранее знать, какие секреты доступны через роль. В облаке старый trust policy способен быть опаснее забытого API-ключа: он выглядит штатной настройкой и при этом открывает дверь от имени легитимного партнёра.
