Злам Qubole: як довірений AWS-доступ відкрив дані клієнтів

9 листопада 2026 року команда дослідників компанії Wiz (спільно з Sentra та Mandiant, підрозділом Google Cloud) опублікувала звіт про кампанію, яка демонструє небезпечний клас атак на хмарну інфраструктуру: зловмисник не зламував компанії напряму — він зайшов через «двері», які ті самі компанії залишили відчиненими для стороннього вендора.

Що сталося

Між 14 та 26 жовтня 2026 року невідомий зловмисник використав IAM-креденшели (ключі доступу) від AWS-акаунта, пов'язаного з платформою Qubole, щоб отримати доступ до хмарних середовищ одразу кількох її клієнтів. Qubole — це хмарна платформа обробки даних (data lake), що належить компанії Idera. Усередині AWS-акаунтів клієнтів вона працює через механізм крос-акаунтних IAM-ролей.

Атакуючий, отримавши ці креденшели, викликав API sts:AssumeRole і «приміряв» на себе ролі, які клієнти колись створювали, щоб довіряти акаунту Qubole. Опинившись усередині чужих AWS-середовищ, він перелічував ресурси, збирав конфігурації та секрети, читав дані зі сховищ S3 і перевіряв додаткові облікові дані, які знаходив дорогою.

Ключовий момент: більшість ролей, які атакуючий «приміряв», були неактивними. Платформу давно перестали використовувати, але самі ролі ніхто не видалив, і вони все ще довіряли акаунту Qubole. Саме ці «забуті двері» й відчинив зловмисник.

Як працює крос-акаунтний доступ Qubole

Щоб стороння SaaS-платформа могла працювати у вашому AWS-акаунті, ви зазвичай створюєте IAM-роль із так званою trust policy (політикою довіри). Вона дозволяє акаунту вендора «приміряти» цю роль. Типова політика виглядає так:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam:::root" },
  "Action": "sts:AssumeRole",
  "Condition": { "StringEquals": { "sts:ExternalId": "" } }
}

Запит AssumeRole приймається, якщо він надходить від довіреного акаунта та містить правильний External ID. І тут криється поширена хибна думка: багато хто вважає External ID «паролем». Насправді, згідно з офіційною документацією AWS, External ID — не секрет. Це лише ідентифікатор, який допомагає уникнути плутанини між ролями (так званої «confused deputy» атаки), але будь-хто, хто має доступ до ролі, може просто його побачити.

External ID вигадали для вирішення іншої задачі. Уявіть, що одна й та сама довірча роль використовується двома різними вендорами або двома сервісами. Якщо один із них скомпрометовано, зловмисник міг би «приміряти» роль і в іншому контексті. External ID просто дає змогу розрізняти, кому саме належить конкретний запит, — але він не шифрує доступ і не замінює справжню автентифікацію. У цій атаці він зіграв роль рівно настільки, наскільки й може: зловмисник, який мав доступ до ролі, безперешкодно прочитав потрібний ідентифікатор.

У випадку з Qubole дослідники Wiz підтвердили: кожен запит AssumeRole від зловмисника містив валідний External ID і був прийнятий. Тобто атакувальнику навіть не довелося обходити цей механізм — він просто мав правильний ідентифікатор.

Хронологія атаки

Wiz відстежив активність до 14 жовтня. Перший запит AssumeRole надійшов з IP-адреси, що належить VPN-сервісу Mullvad (45.83.220.211). Виклики йшли з AWS-акаунта 805246085872 — саме його Qubole використовує для роботи з клієнтськими ролями — і використовували IAM-користувача з ідентифікатором AIDA3W7DIFLYOLTK63SFS. Показово: у всіх досліджених середовищах Wiz не бачив жодної активності цього користувача, крім дій атакуючого.

З 15 жовтня більшість трафіку йшла з VPS-сервера хостингу OVH (57.129.54.120). 18 жовтня зловмисник почав використовувати другого IAM-користувача того ж акаунта — AIDAJYRRH5Y3A7AAJM2HW, який паралельно несе й легітимний трафік самої платформи Qubole. Того ж дня друга адреса Mullvad (185.209.199.73) швидко «приміряла» ролі одразу в кількох середовищах жертв.

Окремо Wiz зафіксував другу хвилю активності з 8 по 11 жовтня: там атакуючий використовував вже не роль, а довгоживучі AWS access keys, які клієнти свого часу створювали для інтеграції з Qubole. Упродовж однієї години 8 жовтня він протестував усі ці ключі, і в невеликій кількості випадків дійшов до компрометації середовища. Зв'язати дві хвилі дослідники не змогли.

Що викрав атакуючий

Послідовність дій була однаковою в усіх середовищах: приміряти роль → викликати ListBuckets, щоб побачити, до чого роль має доступ → ListObjects і HeadObject для переліку та огляду вмісту → GetObject, щоб завантажити файли. Зловмисник діяв опортуністично: не шукав конкретних даних, а читав усе, до чого могла дотягнутися кожна роль, подекуди вивантажуючи цілі S3-бакети за одну сесію.

Окрім даних, атакуючий полював на облікові дані:

• витягував секрети з AWS Secrets Manager — включно з токенами самих вендорів та ExternalId;
• читав розшифровані параметри з SSM Parameter Store (ключі моніторингових і сканувальних агентів);
• збирав змінні оточення Lambda-функцій;
• вискрібав user data інстанцій EC2 — стартові скрипти, де часто зберігаються токени та паролі.

Знайдені креденшели він проганяв через відкритий сканер секретів TruffleHog, перевіряючи власні AWS-ключі жертв, client secrets Microsoft Entra ID та Okta-креденшели. Інструмент викликав GetCallerIdentity — запит, що не потребує жодних прав і просто підтверджує, чи ключ робочий.

Дослідники також знайшли на сервері атакуючого завантажувальний образ Linux sso_agent.iso. За припущенням Wiz, його створили, щоб віддалено завантажувати на машинах жертв: після запуску образ надсилає на сервер атакуючого відомості про систему та диски й очікує команд на порту 23458.

Як дослідники вистежили атаку

Першою підозрілу активність помітила компанія Sentra — на кількох середовищах своїх клієнтів. Ланцюжок доказів вибудувався завдяки тому, що хмарні сервіси лишають сліди навіть там, де їх не очікуєш побачити. Ключовим індикатором стали логи шифрування: щоразу, коли завантажується зашифрований файл, хмара має його розшифрувати, і кожне таке розблокування фіксується з ім'ям файлу. Зіставивши ці записи з сесіями атакуючого, дослідники змогли точно встановити, які саме файли витекли. Файли з дефолтним шифруванням такого сліду не лишають, тож реальні обсяги, ймовірно, більші.

Другий слід — самі секрети: кожен прочитаний пароль чи ключ лишав власний запис, що дало точний список того, що потрібно ротувати. І саме через призму зовнішніх довірчих ідентичностей Sentra звузила коло підозрюваних до одного вендора: Qubole був єдиним зовнішнім принципалом, який мав доступ до більшості вихідних S3-бакетів.

Забуті інтеграції — головна вразливість

Технічно ця атака належить до класу, який у MITRE ATT&CK описано як T1199 «Trusted Relationship» (зловживання довірчими відносинами). Суть проста: зламавши вендора, атакуючий успадковує весь доступ, який цьому вендору надали його клієнти.

Wiz формулює це ще жорсткіше: довірені принципали SaaS-провайдерів — «фактично креденшели одразу до середовища кожного клієнта». Одна скомпрометована обліківка вендора перетворюється на ключ до десятків організацій.

Найнебезпечніше — саме «забуті» інтеграції. Багато організацій залишили trust policy активними навіть після того, як перестали користуватися Qubole. Роль не потрібна бізнесу, її ніхто не моніторить, але вона досі дозволяє чужому акаунту приміряти її — і саме ці ролі атакуючий використав найчастіше.

Як перевірити, чи ви постраждали

Wiz радить переглянути логи CloudTrail починаючи з 1 жовтня у кожному AWS-акаунті, де є роль для Qubole. Ознаки атаки:

• Акаунт: запити AssumeRole, де userIdentity.accountId дорівнює 805246085872, а sourceIPAddress — не AWS-адреса. Легітимний трафік Qubole, за спостереженнями Wiz, іде лише з інфраструктури AWS.
• IAM-принципал: AIDA3W7DIFLYOLTK63SFS — будь-яка активність цього користувача має бути досліджена (ним користувався лише атакуючий).
• IAM-принципал: AIDAJYRRH5Y3A7AAJM2HW — фільтруйте на не-AWS джерела IP, оскільки ним ходить і легітимний трафік Qubole.
• IP-адреси: 57.129.54.120 і 2001:41d0:70d:7800:: (OVH); 45.83.220.211, 185.209.199.73, 89.37.63.175 (Mullvad VPN). Зауважте: адреси Mullvad спільні для багатьох користувачів VPN, тож сам по собі збіг — ще не доказ.
• Ім'я сесії: сесії ролей, що починаються з quiam- (наприклад, quiam-enum).
• User agent: TruffleHog у викликах GetCallerIdentity з вищевказаних IP. Той самий user agent варто шукати й у логах входу вашого identity-провайдера.

Якщо ви знайшли сліди компрометації, окремо перевірте, чи ваші облікові дані вже фігурують у публічних витоках, — наприклад, через безкоштовний чекер витоків cyberpeople.tech.

Як захиститися

Навіть якщо ви ніколи не користувалися Qubole, ці правила стосуються будь-якої сторонньої SaaS-інтеграції у вашому AWS-акаунті:

1. Ротуйте все, до чого роль мала доступ. Змініть секрети, параметри Parameter Store та змінні оточення Lambda. Окремо відкликайте активні сесії ролі: ротація креденшелів не завершує вже видані сесії.
2. Видаляйте непотрібні ролі. Якщо інтеграція більше не використовується — приберіть роль або вилучіть акаунт вендора з trust policy.
3. Звужуйте principal. Замість загального :root вказуйте в trust policy конкретний IAM-принципал вендора, якщо це підтримується.
4. Додайте умову на джерело запиту. Використовуйте aws:SourceIp або aws:SourceVpce, щоб обмежити AssumeRole документованими мережевими діапазонами вендора. За словами Wiz, у цій атаці «однієї лише умови на source IP було б достатньо, щоб заблокувати кожен рол, який ми спостерігали».
5. Увімкніть S3 data events. Події керування (management events) у CloudTrail фіксують сам факт примірювання ролі та перелік бакетів, але не фіксують читання об'єктів. Саме data events у CloudTrail або S3 server access logs покажуть, які файли реально завантажили.

Загальна порада — регулярний аудит зовнішніх довірчих відносин і принцип мінімальних привілеїв: роль має отримувати доступ рівно до тих ресурсів, які потрібні вендору, і ні байтом більше.

Висновок

Атака на клієнтів Qubole — яскравий приклад того, що ланцюг постачання хмарних сервісів давно став самостійним вектором, не менш небезпечним за пряме зламування периметра. Слабке місце тут не вразливість у коді, а довіра, яку організації видають стороннім вендорам — і про яку забувають, щойно сервіс перестає бути потрібним.

Поки вендори не публікують офіційних заяв (ні Qubole, ні Idera на момент виходу звіту Wiz не відповіли, а джерело компрометації креденшелів Qubole не розкрите), головний висновок для команд безпеки один: провести ревізію всіх сторонніх інтеграцій у своєму AWS-акаунті прямо зараз. Кожна забута роль із довірчою політикою — це потенційно відчинені двері, якими одного дня скористається хтось інший.

Варто розуміти масштаб: якщо у вас є бодай кілька SaaS-вендорів, інтегрованих із хмарою, ваша реальна поверхня атаки — це не лише ваші власні системи, а й стан безпеки кожного з цих вендорів. Перевірте trust policy, приберіть зайві ролі, звужте принципалів і додайте умови на джерело запиту. Це дешевше й швидше, ніж розслідувати витік даних постфактум.