
Зловмисники використали довірений доступ Qubole до AWS для зламу клієнтських облікових записів і викрадення даних
Зловмисники використали довірений обліковий запис Qubole в AWS для прийняття на себе ролей IAM клієнтів між 14 і 26 жовтня та викрали секрети й дані з S3, Secrets Manager і середовищ Lambda, за даними хмарної безпекової компанії Wiz.
Зловмисники використали довірений обліковий запис Qubole в AWS, щоб прийняти на себе ролі IAM клієнтів між 14 і 26 жовтня, та викрали облікові дані й дані з кількох хмарних сервісів.
Деталі атаки
Вторгнення використало ідентифікатор облікового запису платформи Qubole 805246085872. Кожен запит AssumeRole містив дійсний зовнішній ідентифікатор, який AWS вважає несекретним і який видно в журналах CloudTrail. Зловмисники отримали доступ до змінних середовища Lambda, Secrets Manager і SSM Parameter Store, а потім перевірили викрадені ключі за допомогою TruffleHog. Дані копіювали з будь-якого бакета S3, який могла прочитати прийнята роль, іноді завантажуючи цілі бакети за один сеанс. Окрема кампанія з 8 по 11 жовтня використовувала власні ключі доступу AWS клієнтів, налаштовані для Qubole, і скомпрометувала кілька середовищ.
Рекомендації з виявлення
Організаціям слід шукати в подіях керування CloudTrail від 1 жовтня далі запити AssumeRole, де ідентифікатор облікового запису, що запитує, дорівнює 805246085872, а вихідна IP-адреса не є адресою AWS. Ключові індикатори включають ідентифікатори суб'єктів IAM AIDA3W7DIFLYOLTK63SFS і AIDAJYRRH5Y3A7AAJM2HW, коли джерело є зовнішнім, адреси IP 57.129.54.120, 2001:41d0:70d:7800::, 45.83.220.211, 185.209.199.73, 89.37.63.175, назви сеансів, що починаються з quiam-, і агент користувача TruffleHog у викликах GetCallerIdentity. Перегляньте всі дії після будь-якого підозрілого сеансу, особливо в Secrets Manager, SSM Parameter Store, Lambda і S3. Увімкніть події даних S3 або журнали доступу сервера, щоб фіксувати читання на рівні об'єктів.
Кроки з пом'якшення
Якщо роль Qubole було прийнято на себе, ротуйте всі секрети, параметри й змінні середовища Lambda, до яких роль могла дістатися, і відкличте активні сеанси. Видаліть невикористовувані ролі Qubole або вилучіть обліковий запис Qubole з політики довіри ролі. Якщо можливо, замініть кореневий суб'єкт рівня облікового запису в політиці довіри на конкретний суб'єкт IAM, який використовує Qubole, і додайте умову aws:SourceIp або aws:SourceVpce, що обмежує AssumeRole задокументованими мережевими діапазонами Qubole. Змініть зовнішні ідентифікатори після інциденту і використовуйте унікальне значення для кожної ролі. Перевірте дозволи, надані ролям постачальника, які часто включають широке читання S3, Lambda, Secrets Manager і SSM. Налаштуйте сповіщення про запити AssumeRole, що надходять від VPN або хостинг-провайдерів, які постачальник не використовує, і забезпечте журналювання CloudTrail у масштабах організації з подіями даних S3 для чутливих бакетів.
Джерела: The Hacker News · The Register
SiTech — веброзробка з підтримкою AI
Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.