Доверяй по умолчанию: межаккаунтный доступ Qubole скомпрометирован в «дикой природе»

Сторонние интеграции — один из самых распространенных способов, с помощью которых организации предоставляют сторонним лицам доступ к своим облачным средам. Работая с Sentra и Mandiant, специалисты Wiz зафиксировали использование злоумышленником IAM-учетных данных из AWS-аккаунта, связанного с Qubole, в период с 14 по 26 октября 2026 года. Злоумышленник использовал эти учетные данные для принятия IAM-ролей, которые клиенты создали для доверия аккаунту Qubole. Проникнув в несколько зараженных сред AWS, злоумышленник провел перечисление ресурсов, собрал конфигурации и секретные данные, получил доступ к данным в S3 и проверил дополнительные учетные данные, обнаруженные в процессе.

Компания Sentra выявила подозрительную активность в нескольких средах своих клиентов, распознала в ней масштабную атаку на цепочку поставок и поделилась информацией с Wiz, что и послужило поводом для данного расследования. В этой статье описывается то, что зафиксировала компания Wiz, как защитники могут обнаружить эту угрозу и как снизить риски, связанные с доверительными отношениями между сторонними аккаунтами. Клиенты Wiz могут обратиться к нашему бюллетеню Центра разведки угроз (Threat Intel Center) по поводу данной активности.

Предыстория: как работает межаккаунтный доступ вендоров

Многие SaaS-платформы, работающие внутри AWS-аккаунта клиента (включая платформы обработки данных вроде Qubole), используют межаккаунтные IAM-роли. Во время настройки клиент создает роль в своем собственном аккаунте с политикой доверия, которая позволяет AWS-аккаунту вендора принимать ее, обычно с ограничением по внешнему идентификатору (External ID):

Когда вендору необходимо выполнить действия в среде клиента, сущность в аккаунте вендора вызывает sts:AssumeRole с ARN роли и внешним идентификатором (External ID), после чего получает временные учетные данные, ограниченные рамками роли клиента.

Что мы зафиксировали

Первичный доступ: принятие роли из аккаунта вендора

Первая активность, зафиксированная CIRT Wiz, произошла 14 октября, когда IP-адрес, принадлежащий Mullvad VPN (45.83.220[.]211), вызвал AssumeRole для ролей интеграции в клиентских средах. Вызовы исходили из AWS-аккаунта 805246085872, который, как мы наблюдаем, используется платформой Qubole для принятия ролей в клиентских средах, и использовали IAM-пользователя AIDA3W7DIFLYOLTK63SFS. Во всех затронутых средах CIRT Wiz не фиксировала этого IAM-пользователя ни в какой другой активности, кроме той, которая связана с данным злоумышленником.

Начиная с 15 октября большая часть активности исходила от VPS, размещенного у хостинг-провайдера OVH (57.129.54[.]120). 18 октября злоумышленник начал использовать второго IAM-пользователя из того же аккаунта — AIDAJYRRH5Y3A7AAJM2HW, через который также проходит легитимный трафик платформы Qubole из инфраструктуры AWS. В тот же день второй адрес Mullvad (185.209.199[.]73) быстро друг за другом принял роли интеграции в нескольких целевых средах. Каждый запрос AssumeRole, который мы отнесли к активности злоумышленника, содержал внешний идентификатор (External ID) и каждый из них завершился успешно.

Большинство ролей, которые принял злоумышленник, в остальное время не использовались. В подавляющем большинстве сред, зафиксированных CIRT Wiz, запросы злоумышленника были единственной активностью AssumeRole со стороны аккаунта вендора за весь октябрь. Политики доверия по-прежнему действовали, поэтому запросы завершились успешно.

Разведка

Злоумышленник использовал имена сеансов ролей, которые соответствовали единому формату: префикс quiam-, за которым следовал суффикс, описывающий выполненные действия. Сюда входят такие имена сеансов, как quiam-enum и quiam-scope-full.

Оказавшись внутри среды, злоумышленник провел масштабное перечисление по всем сервисам, включая:

• Хранилища и данные: ListBuckets, ListObjects, GetDatabases, ListTables, DescribeClusters

Хранилища и данные: ListBuckets, ListObjects, GetDatabases, ListTables, DescribeClusters

• Вычислительные ресурсы: DescribeInstances, DescribeImages, DescribeSecurityGroups, DescribeVpcs

Вычислительные ресурсы: DescribeInstances, DescribeImages, DescribeSecurityGroups, DescribeVpcs

• Базы данных: DescribeDBInstances, DescribeDBSnapshots

Базы данных: DescribeDBInstances, DescribeDBSnapshots

• Учетные записи и ключи: ListRoles, ListKeys, ListAliases, DescribeKey, GetKeyPolicy

Учетные записи и ключи: ListRoles, ListKeys, ListAliases, DescribeKey, GetKeyPolicy

Сбор учетных данных и проверка секретов

Злоумышленник нацелился на типичные места хранения учетных данных в AWS:

• Lambda: злоумышленник перечислил функции Lambda и вызвал GetFunctionConfiguration для каждой из них, что возвращает переменные окружения функций.

Lambda: злоумышленник перечислил функции Lambda и вызвал GetFunctionConfiguration для каждой из них, что возвращает переменные окружения функций.

• Secrets Manager: ListSecrets с последующим вызовом GetSecretValue

Secrets Manager: ListSecrets с последующим вызовом GetSecretValue

• SSM Parameter Store: DescribeParameters и GetParameter.

SSM Parameter Store: DescribeParameters и GetParameter.

Злоумышленник использовал TruffleHog для проверки учетных данных, обнаруженных в средах жертв. Они принадлежали пострадавшим организациям, а не вендору:

• AWS: TruffleHog вызвал GetCallerIdentity с обнаруженными ключами доступа IAM-пользователя. Этот вызов не требует никаких разрешений и подтверждает валидность ключа. Злоумышленник проверял ключи из нескольких AWS-аккаунтов всплесками длительностью в несколько секунд.

AWS: TruffleHog вызвал GetCallerIdentity с обнаруженными ключами доступа IAM-пользователя. Этот вызов не требует никаких разрешений и подтверждает валидность ключа. Злоумышленник проверял ключи из нескольких AWS-аккаунтов всплесками длительностью в несколько секунд.

• Entra ID: TruffleHog выполнил вход в качестве принципалов службы Entra ID, используя обнаруженные секреты клиента.

Entra ID: TruffleHog выполнил вход в качестве принципалов службы Entra ID, используя обнаруженные секреты клиента.

• Okta: TruffleHog запросил токены OAuth, используя обнаруженные учетные данные клиента Okta.

Okta: TruffleHog запросил токены OAuth, используя обнаруженные учетные данные клиента Okta.

Доступ к данным и их эксфильтрация

Используя принятые роли интеграции, злоумышленник эксфильтровал данные из S3. Последовательность была одинаковой во всех средах: принять роль, вызвать ListBuckets, чтобы посмотреть, к чему у роли есть доступ, вызвать ListObjects и HeadObject для перечисления и проверки содержимого, а затем вызвать GetObject для их скачивания. Похоже, что злоумышленник действовал оппортунистически. Вместо поиска конкретных данных он считывал информацию из любых бакетов, к которым у каждой роли был доступ, в некоторых случаях скачивая целые бакеты за один сеанс.

Для обнаружения подобной эксфильтрации организациям следует убедиться, что для бакетов, содержащих конфиденциальные данные, включены события данных S3 в CloudTrail или логи доступа к серверам S3. События управления CloudTrail фиксируют принятие роли и перечисление бакетов, но не чтение объектов, из которого состоит эксфильтрация данных.

Образ .iso намекает на дополнительные операции

В дополнение к вышеупомянутым вторжениям, Wiz Research через Validin обнаружила ISO-файл, который размещался по IP-адресу 57.129.54[.]120 в то время, когда он контролировался злоумышленником. Этот файл, sso_agent.iso (SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4), представляет собой загрузочный образ Linux, который, по нашему мнению, предназначен для удаленной загрузки на машине жертвы. При запуске ISO-образ запускает 90-минутный таймер, собирает системную информацию и загружает списки интерфейсов, дисков и разделов на IP-адрес 57.129.54[.]120. Затем он опрашивает тот же IP-адрес через TCP-порт 23458 для получения входных данных и выполняет их как shell-скрипт. Этот опрос продолжается до истечения 90-минутного таймера, после чего инициируется принудительная перезагрузка, стирающая любые следы вредоносного ISO-образа. Хотя команда опроса может выполнить любой отправленный ей скрипт, ISO-образ настроен на загрузку драйвера ntfs3 при запуске, что позволяет предположить, что он предназначен для атак на операционные системы Windows.

Wiz не выявила случаев развертывания этого ISO-образа и не может подтвердить, использовался ли он и каким образом.

Атрибуция и мотивация

Wiz не обнаружила никаких связей между этой кампанией и другой публично известной активностью. Выбор целей и кража данных выглядят оппортунистическими и не соответствуют типичным приоритетам, поддерживаемым государством; однако у нас нет прямого понимания мотивации злоумышленника или того, как он может использовать украденные данные.

Дополнительная активность, связанная с Qubole

Wiz также выявила отдельный набор вредоносной активности, связанной с интеграциями Qubole. Нам не удалось связать ее с активностью по принятию ролей (role assumption), описанной выше.

С 8 по 11 октября злоумышленник использовал принадлежащие клиентам ключи доступа AWS, которые, как мы полагаем, были созданы для интеграций с Qubole. 8 октября злоумышленник протестировал все эти ключи в течение одного часа. В ряде случаев злоумышленник перешел к компрометации облачной среды жертвы.

Обнаружение и поиск угроз

Организациям, использующим интеграцию с Qubole, следует проверить журналы CloudTrail начиная с 1 октября 2026 года в каждой учетной записи, где есть роль интеграции:

• События AssumeRole, где userIdentity.accountId — 805246085872, а sourceIPAddress не является адресом AWS. Весь легитимный трафик платформы, который мы наблюдали, исходил из инфраструктуры AWS.

События AssumeRole, где userIdentity.accountId — 805246085872, а sourceIPAddress не является адресом AWS. Весь легитимный трафик платформы, который мы наблюдали, исходил из инфраструктуры AWS.

• События AssumeRole, где userIdentity.principalId — AIDA3W7DIFLYOLTK63SFS. В наблюдаемых нами средах этот IAM-пользователь использовался только злоумышленником, поэтому любая активность от его имени требует расследования.

События AssumeRole, где userIdentity.principalId — AIDA3W7DIFLYOLTK63SFS. В наблюдаемых нами средах этот IAM-пользователь использовался только злоумышленником, поэтому любая активность от его имени требует расследования.

• События AssumeRole, где userIdentity.principalId — AIDAJYRRH5Y3A7AAJM2HW, а sourceIPAddress не является адресом AWS. Этот IAM-пользователь также передает легитимный трафик платформы из инфраструктуры AWS, поэтому используйте фильтрацию по исходному адресу, чтобы отделить действия злоумышленника от нормальной активности.

События AssumeRole, где userIdentity.principalId — AIDAJYRRH5Y3A7AAJM2HW, а sourceIPAddress не является адресом AWS. Этот IAM-пользователь также передает легитимный трафик платформы из инфраструктуры AWS, поэтому используйте фильтрацию по исходному адресу, чтобы отделить действия злоумышленника от нормальной активности.

• Любая активность с IP-адресов, указанных в таблицах IOC ниже. Адреса Mullvad являются общими выходными узлами VPN, поэтому активность только с них не является окончательным доказательством.

Любая активность с IP-адресов, указанных в таблицах IOC ниже. Адреса Mullvad являются общими выходными узлами VPN, поэтому активность только с них не является окончательным доказательством.

• Вызовы GetCallerIdentity с пользовательским агентом TruffleHog в сочетании с любым IP-адресом из IOC, которые показывают учетные данные, которые злоумышленник пытался проверить. Проверьте журналы входа в систему вашего поставщика идентификационных данных на наличие того же пользовательского агента.

Вызовы GetCallerIdentity с пользовательским агентом TruffleHog в сочетании с любым IP-адресом из IOC, которые показывают учетные данные, которые злоумышленник пытался проверить. Проверьте журналы входа в систему вашего поставщика идентификационных данных на наличие того же пользовательского агента.

Для каждого найденного сеанса роли просмотрите всю последующую активность этого сеанса, особенно в Secrets Manager, SSM Parameter Store, Lambda и S3. Если злоумышленник принял роль интеграции, смените все секреты, параметры и переменные окружения Lambda, которые могла прочитать эта роль, и отзовите активные сеансы для этой роли. Смена учетных данных не завершает временные сеансы, которые уже были выданы.

Клиенты Wiz Defend, загружающие данные CloudTrail, увидят угрозы Wiz Threats для событий «IAM Role Assumed From New or Inactive Account» (Роль IAM принята из новой или неактивной учетной записи) и «Unusual non-human access to AWS through third-party VPN» (Необычный нечеловеческий доступ к AWS через сторонний VPN).

Рекомендации для специалистов по защите

• Проведите инвентаризацию сторонних доверительных отношений. Определите каждую роль IAM, политика доверия которой разрешает доступ внешней учетной записи. Клиенты Wiz могут использовать Security Graph для перечисления ролей, которые доверяют внешним учетным записям AWS, а также разрешений и данных, к которым эти роли могут получить доступ. Security Graph Query

Проведите инвентаризацию сторонних доверительных отношений. Определите каждую роль IAM, политика доверия которой разрешает доступ внешней учетной записи. Клиенты Wiz могут использовать Security Graph для перечисления ролей, которые доверяют внешним учетным записям AWS, а также разрешений и данных, к которым эти роли могут получить доступ. Security Graph Query

• Удалите доверие для интеграций, которые вы больше не используете. Во многих скомпрометированных средах во время этой активности не было легитимного трафика от поставщиков. Эти роли все равно принимали запросы злоумышленника. Удалите роли интеграции, которые вы больше не используете, или удалите учетную запись поставщика из их политик доверия.

Удалите доверие для интеграций, которые вы больше не используете. Во многих скомпрометированных средах во время этой активности не было легитимного трафика от поставщиков. Эти роли все равно принимали запросы злоумышленника. Удалите роли интеграции, которые вы больше не используете, или удалите учетную запись поставщика из их политик доверия.

• Сузьте круг доверенных субъектов. Там, где это поддерживает поставщик, замените субъект account:root на конкретный субъект IAM, который использует поставщик. Добавьте условие aws:SourceIp или aws:SourceVpce, которое ограничивает принятие роли сетевыми диапазонами, задокументированными поставщиком. При наличии этих условий действительный внешний идентификатор (External ID) из неожиданного источника или сети будет отклонен. В данной активности условие по исходному IP-адресу само по себе заблокировало бы каждое наблюдавшееся нами принятие роли.

Сузьте круг доверенных субъектов. Там, где это поддерживает поставщик, замените субъект account:root на конкретный субъект IAM, который использует поставщик. Добавьте условие aws:SourceIp или aws:SourceVpce, которое ограничивает принятие роли сетевыми диапазонами, задокументированными поставщиком. При наличии этих условий действительный внешний идентификатор (External ID) из неожиданного источника или сети будет отклонен. В данной активности условие по исходному IP-адресу само по себе заблокировало бы каждое наблюдавшееся нами принятие роли.

• Считайте внешний идентификатор (External ID) несекретным. Он регистрируется в виде открытого текста в CloudTrail, а также часто сохраняется поставщиком и в конфигурациях инфраструктуры как кода (infrastructure-as-code). Не полагайтесь на него как на единственный элемент управления. После такого инцидента выполните его ротацию по согласованию с поставщиком и используйте уникальное значение для каждой роли, где это поддерживается.

Считайте внешний идентификатор (External ID) несекретным. Он регистрируется в виде открытого текста в CloudTrail, а также часто сохраняется поставщиком и в конфигурациях инфраструктуры как кода (infrastructure-as-code). Не полагайтесь на него как на единственный элемент управления. После такого инцидента выполните его ротацию по согласованию с поставщиком и используйте уникальное значение для каждой роли, где это поддерживается.

• Ограничьте область действия ролей интеграции. Проверьте разрешения, привязанные к ролям поставщиков. Доступ к конфигурации Lambda, Secrets Manager, параметрам SSM и широкое чтение из S3 часто предоставляются из соображений удобства. Убедитесь, что соблюдается принцип наименьших привилегий.

Ограничьте область действия ролей интеграции. Проверьте разрешения, привязанные к ролям поставщиков. Доступ к конфигурации Lambda, Secrets Manager, параметрам SSM и широкое чтение из S3 часто предоставляются из соображений удобства. Убедитесь, что соблюдается принцип наименьших привилегий.

• Настройте оповещения о принятии сторонних ролей из новых сетей. Трафик поставщиков обычно поступает из определенного набора облачных сетей. Вызов AssumeRole из учетной записи поставщика через VPN или хостинг-провайдер, который поставщик никогда ранее не использовал, является высоконадежным признаком обнаружения.

Настройте оповещения о принятии сторонних ролей из новых сетей. Трафик поставщиков обычно поступает из определенного набора облачных сетей. Вызов AssumeRole из учетной записи поставщика через VPN или хостинг-провайдер, который поставщик никогда ранее не использовал, является высоконадежным признаком обнаружения.

• Убедитесь, что ваши журналы охватывают каждую учетную запись. Используйте организационный трек (organization trail), охватывающий все учетные записи и регионы, и включите события данных S3 или журналы доступа к серверу S3 для конфиденциальных бакетов. В нескольких затронутых средах отсутствие журналов привело к тому, что специалисты по реагированию не смогли увидеть, какие объекты S3 прочитал злоумышленник.

Убедитесь, что ваши журналы охватывают каждую учетную запись. Используйте организационный трек (organization trail), охватывающий все учетные записи и регионы, и включите события данных S3 или журналы доступа к серверу S3 для конфиденциальных бакетов. В нескольких затронутых средах отсутствие журналов привело к тому что специалисты по реагированию не смогли увидеть, какие объекты S3 прочитал злоумышленник.

• Поставщики SaaS, ограничьте принципалы, которым доверяют ваши клиенты. Клиенты доверяют принципалам в вашей учетной записи, поэтому эти принципалы фактически являются учетными данными для всех клиентских сред одновременно. Принимайте роли клиентов из ролей рабочей нагрузки с помощью временных учетных данных, а не долгосрочных ключей пользователей IAM; ограничивайте места использования этих принципалов с помощью условий aws:SourceIp или aws:SourceVpc; публикуйте свои диапазоны исходящего трафика, чтобы клиенты могли зафиксировать свои политики доверия, а также контролируйте собственный CloudTrail на предмет вызовов AssumeRole в учетные записи клиентов из неожиданных сетей.

Поставщики SaaS, ограничьте принципалы, которым доверяют ваши клиенты. Клиенты доверяют принципалам в вашей учетной записи, поэтому эти принципалы фактически являются учетными данными для всех клиентских сред одновременно. Принимайте роли клиентов из ролей рабочей нагрузки с помощью временных учетных данных, а не долгосрочных ключей пользователей IAM; ограничивайте места использования этих принципалов с помощью условий aws:SourceIp или aws:SourceVpc; публикуйте свои диапазоны исходящего трафика, чтобы клиенты могли зафиксировать свои политики доверия, а также контролируйте собственный CloudTrail на предмет вызовов AssumeRole в учетные записи клиентов из неожиданных сетей.

Индикаторы компрометации

Сетевые индикаторы

Индикаторы учетных записей

Агенты пользователя

Индикаторы хоста

MD5: 086d4a83181971e883c53a4c44f46da2 SHA-1: 1c7437dac21630f53c0b888b50662c6487e23fd7 SHA-256: 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4