AWS - CloudTrail Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS CloudTrail реєструє та моніторить активність у вашому середовищі AWS. Він захоплює детальні журнали подій, включаючи, хто що зробив, коли і звідки, для всіх взаємодій з ресурсами AWS. Це забезпечує слід змін і дій, що допомагає в аналізі безпеки, аудиті відповідності та відстеженні змін ресурсів. CloudTrail є важливим для розуміння поведінки користувачів і ресурсів, покращення безпеки та забезпечення відповідності регуляторним вимогам.
Кожна зафіксована подія містить:
Назву викликаного API: eventName
Викликану службу: eventSource
Час: eventTime
IP-адресу: SourceIPAddress
Метод агента: userAgent
. Приклади:
Signing.amazonaws.com - З AWS Management Console
console.amazonaws.com - Користувач root облікового запису
lambda.amazonaws.com - AWS Lambda
Параметри запиту: requestParameters
Елементи відповіді: responseElements
Події записуються в новий файл журналу приблизно кожні 5 хвилин у файлі JSON, вони зберігаються CloudTrail, а в кінцевому підсумку файли журналів доставляються в S3 приблизно через 15 хвилин. Журнали CloudTrail можуть бути агреговані між обліковими записами та регіонами. CloudTrail дозволяє використовувати цілісність файлів журналів, щоб мати можливість перевірити, що ваші файли журналів залишилися незмінними з моменту їх доставки CloudTrail. Він створює SHA-256 хеш журналів у файлі дайджесту. SHA-256 хеш нових журналів створюється щогодини. При створенні Trail селектори подій дозволять вам вказати, які події слід реєструвати: управлінські, дані або події аналітики.
Журнали зберігаються в кошику S3. За замовчуванням використовується шифрування на стороні сервера (SSE-S3), тому AWS розшифрує вміст для людей, які мають до нього доступ, але для додаткової безпеки ви можете використовувати SSE з KMS та вашими власними ключами.
Журнали зберігаються в кошику S3 з таким форматом імені:
BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD
Ім'я кошика: aws-cloudtrail-logs-<accountid>-<random>
Приклад: aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/
У кожній папці кожен журнал матиме ім'я, що відповідає цьому формату: AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz
Конвенція іменування файлів журналів
Крім того, файли дайджесту (для перевірки цілісності файлів) будуть у тому ж кошику в:
Створіть Trail в обліковому записі AWS, куди ви хочете, щоб файли журналів були доставлені
Застосуйте дозволи до кошика S3 призначення, дозволяючи доступ між обліковими записами для CloudTrail і дозволяючи кожному обліковому запису AWS, який потребує доступу
Створіть новий Trail в інших облікових записах AWS і виберіть використання створеного кошика на етапі 1
Однак, навіть якщо ви можете зберігати всі журнали в одному кошику S3, ви не можете агрегувати журнали CloudTrail з кількох облікових записів у журнали CloudWatch, що належать одному обліковому запису AWS.
Пам'ятайте, що обліковий запис може мати різні Trails з CloudTrail увімкненими, зберігаючи однакові (або різні) журнали в різних кошиках.
При створенні CloudTrail можливо вказати активувати CloudTrail для всіх облікових записів в організації та отримати журнали в лише 1 кошик:
Таким чином, ви можете легко налаштувати CloudTrail у всіх регіонах усіх облікових записів і централізувати журнали в 1 обліковому записі (який ви повинні захистити).
Ви можете перевірити, що журнали не були змінені, запустивши
CloudTrail може автоматично надсилати логи до CloudWatch, щоб ви могли налаштувати сповіщення, які попереджають вас про підозрілі дії. Зверніть увагу, що для того, щоб CloudTrail міг надсилати логи до CloudWatch, потрібно створити роль, яка дозволяє цю дію. Якщо можливо, рекомендується використовувати стандартну роль AWS для виконання цих дій. Ця роль дозволить CloudTrail:
CreateLogStream: Це дозволяє створювати потоки логів CloudWatch
PutLogEvents: Доставляти логи CloudTrail до потоку логів CloudWatch
Історія подій CloudTrail дозволяє вам переглядати в таблиці логи, які були зафіксовані:
CloudTrail Insights автоматично аналізує події управління записами з трас CloudTrail і сповіщає вас про незвичайну активність. Наприклад, якщо є збільшення подій TerminateInstance
, яке відрізняється від встановлених базових значень, ви побачите це як подію Insight. Ці події роблять знаходження та реагування на незвичайну активність API легшими ніж будь-коли.
Інсайти зберігаються в тому ж бакеті, що й логи CloudTrail у: BucketName/AWSLogs/AccountID/CloudTrail-Insight
AWS Access Advisor покладається на останні 400 днів логів AWS CloudTrail для збору своїх інсайтів. CloudTrail фіксує історію викликів API AWS та пов'язаних подій, що відбулися в обліковому записі AWS. Консультант доступу використовує ці дані, щоб показати, коли сервіси востаннє використовувалися. Аналізуючи логи CloudTrail, Консультант доступу може визначити, які сервіси AWS використовував користувач або роль IAM і коли цей доступ відбувався. Це допомагає адміністраторам AWS приймати обґрунтовані рішення щодо удосконалення дозволів, оскільки вони можуть виявити сервіси, які не використовувалися протягом тривалого часу, і потенційно зменшити надто широкі дозволи на основі реальних патернів використання.
Отже, Консультант доступу інформує про необхідні дозволи, що надаються користувачам, щоб адміністратор міг їх видалити
Можливо виконати CVS-ін'єкцію в CloudTrail, яка виконає довільний код, якщо журнали експортуються у форматі CSV і відкриваються в Excel. Наступний код згенерує запис журналу з поганою назвою Trail, що містить корисне навантаження:
Для отримання додаткової інформації про CSV-ін'єкції перегляньте сторінку:
Для отримання додаткової інформації про цю конкретну техніку перегляньте https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/
Honeytokens створюються для виявлення ексфільтрації чутливої інформації. У випадку з AWS, це ключі AWS, використання яких контролюється, якщо щось викликає дію з цим ключем, то хтось, напевно, вкрали цей ключ.
Однак Honeytokens, такі як ті, що створені Canarytokens, SpaceCrab, SpaceSiren, або використовують впізнаване ім'я облікового запису, або використовують один і той же ідентифікатор облікового запису AWS для всіх своїх клієнтів. Тому, якщо ви можете отримати ім'я облікового запису та/або ідентифікатор облікового запису без того, щоб Cloudtrail створював будь-який журнал, ви могли б дізнатися, чи є ключ honeytoken чи ні.
Pacu має деякі правила для виявлення, чи належить ключ Canarytokens, SpaceCrab, SpaceSiren:
Якщо canarytokens.org
з'являється в імені ролі або ідентифікатор облікового запису 534261010715
з'являється в повідомленні про помилку.
Тестуючи їх нещодавно, вони використовують обліковий запис 717712589309
і все ще мають рядок canarytokens.com
в імені.
Якщо SpaceCrab
з'являється в імені ролі в повідомленні про помилку
SpaceSiren використовує uuids для генерації імен користувачів: [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}
Якщо ім'я виглядає як випадково згенероване, є високі ймовірності, що це HoneyToken.
Ви можете отримати ідентифікатор облікового запису з закодованого всередині ключа доступу, як пояснено тут і перевірити ідентифікатор облікового запису зі своїм списком Honeytokens AWS облікових записів:
Check more information in the оригінальному дослідженні.
Найефективніша техніка для цього насправді є простою. Просто використайте ключ, який ви щойно знайшли, щоб отримати доступ до якоїсь служби у вашому власному обліковому записі зловмисника. Це змусить CloudTrail згенерувати журнал у ВАШОМУ ВЛАСНОМУ обліковому записі AWS, а не у жертви.
Справа в тому, що вихід покаже вам помилку, що вказує на ідентифікатор облікового запису та ім'я облікового запису, тому ви зможете побачити, чи це Honeytoken.
У минулому існували деякі AWS сервіси, які не надсилають журнали до CloudTrail (знайдіть список тут). Деякі з цих сервісів відповідають з помилкою, що містить ARN ключової ролі, якщо хтось несанкціонований (ключ Honeytoken) намагається отримати до них доступ.
Таким чином, зловмисник може отримати ARN ключа, не викликавши жодного журналу. У ARN зловмисник може побачити ідентифікатор облікового запису AWS та ім'я, легко дізнатися ідентифікатор облікових записів компаній HoneyToken та їхні імена, тому таким чином зловмисник може визначити, чи є токен HoneyToken.
Зверніть увагу, що всі публічні API, виявлені як такі, що не створюють журнали CloudTrail, тепер виправлені, тому, можливо, вам потрібно знайти свої власні...
Для отримання додаткової інформації перегляньте оригінальне дослідження.
Деякі сервіси AWS створюють певну інфраструктуру, таку як Бази даних або кластери Kubernetes (EKS). Користувач, який безпосередньо спілкується з цими сервісами (наприклад, API Kubernetes), не використовуватиме API AWS, тому CloudTrail не зможе побачити цю комунікацію.
Отже, користувач з доступом до EKS, який виявив URL API EKS, може згенерувати токен локально і спілкуватися з API-сервісом без виявлення Cloudtrail.
Більше інформації в:
У першому прикладі надається один селектор подій у вигляді масиву JSON з одним об'єктом. "ReadWriteType": "ReadOnly"
вказує на те, що селектор подій повинен захоплювати лише події тільки для читання (тому CloudTrail insights не буде перевіряти запис події, наприклад).
Ви можете налаштувати селектор подій відповідно до ваших конкретних вимог.
Видалити S3 бакет
Змінити політику бакету, щоб заборонити будь-які записи з сервісу CloudTrail
Додати політику життєвого циклу до S3 бакету для видалення об'єктів
Вимкнути ключ kms, що використовується для шифрування журналів CloudTrail
Ви можете згенерувати асиметричний ключ і змусити CloudTrail зашифрувати дані цим ключем і видалити приватний ключ, щоб вміст CloudTrail не можна було відновити. Це в основному S3-KMS ransomware, пояснене в:
Ransomware KMS
Це найпростіший спосіб виконати попередню атаку з іншими вимогами до дозволів:
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)