AWS - GuardDuty 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)
Згідно з документацією: GuardDuty поєднує машинне навчання, виявлення аномалій, моніторинг мережі та виявлення шкідливих файлів, використовуючи як AWS, так і провідні джерела третіх сторін для захисту робочих навантажень і даних на AWS. GuardDuty здатний аналізувати десятки мільярдів подій з кількох джерел даних AWS, таких як журнали подій AWS CloudTrail, журнали Flow Amazon Virtual Private Cloud (VPC), журнали аудиту та системні журнали Amazon Elastic Kubernetes Service (EKS), а також журнали запитів DNS.
Amazon GuardDuty виявляє незвичну активність у ваших облікових записах, аналізує безпекову значущість активності та надає контекст, у якому вона була викликана. Це дозволяє відповідальному особі визначити, чи варто витрачати час на подальше розслідування.
Сповіщення з'являються в консолі GuardDuty (90 днів) та CloudWatch Events.
Коли користувач вимикає GuardDuty, він перестає моніторити ваше середовище AWS і не генеруватиме нових виявлень, а існуючі виявлення будуть втрачені. Якщо ви просто зупините його, існуючі виявлення залишаться.
Розвідка: Активність, що вказує на розвідку зловмисником, така як незвична активність API, підозрілі спроби входу в базу даних, внутрішньо-VPC сканування портів, незвичні шаблони невдалих запитів на вхід, або пробивання незаблокованих портів з відомого поганого IP.
Компрометація інстансу: Активність, що вказує на компрометацію інстансу, така як майнінг криптовалюти, активність командного та контрольного (C&C) доступу, шкідливе ПЗ, що використовує алгоритми генерації доменів (DGA), вихідна активність відмови в обслуговуванні, незвично високий обсяг мережевого трафіку, незвичні мережеві протоколи, вихідна комунікація інстансу з відомим шкідливим IP, тимчасові облікові дані Amazon EC2, що використовуються зовнішньою IP-адресою, та ексфільтрація даних за допомогою DNS.
Компрометація облікового запису: Загальні шаблони, що вказують на компрометацію облікового запису, включають виклики API з незвичної геолокації або анонімного проксі, спроби вимкнути ведення журналів AWS CloudTrail, зміни, що послаблюють політику паролів облікового запису, незвичні запуски інстансів або інфраструктури, розгортання інфраструктури в незвичному регіоні, крадіжка облікових даних, підозріла активність входу в базу даних та виклики API з відомих шкідливих IP-адрес.
Компрометація бакету: Активність, що вказує на компрометацію бакету, така як підозрілі шаблони доступу до даних, що вказують на зловживання обліковими даними, незвична активність Amazon S3 API з віддаленого хоста, несанкціонований доступ до S3 з відомих шкідливих IP-адрес, та виклики API для отримання даних у S3 бакетах від користувача без попередньої історії доступу до бакету або викликані з незвичного місця. Amazon GuardDuty постійно моніторить та аналізує події даних AWS CloudTrail S3 (наприклад, GetObject, ListObjects, DeleteObject), щоб виявити підозрілу активність у всіх ваших бакетах Amazon S3.
Доступ до списку всіх виявлень GuardDuty за адресою: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html
Ви можете запросити інші облікові записи до іншого облікового запису AWS GuardDuty, щоб кожен обліковий запис моніторився з одного GuardDuty. Головний обліковий запис повинен запросити облікові записи учасників, а потім представник облікового запису учасника повинен прийняти запрошення.
Ви можете призначити будь-який обліковий запис у межах організації делегованим адміністратором GuardDuty. Тільки обліковий запис управління організацією може призначити делегованого адміністратора.
Обліковий запис, який призначається делегованим адміністратором, стає обліковим записом адміністратора GuardDuty, автоматично має увімкнений GuardDuty у призначеному регіоні AWS і також має дозвіл на увімкнення та управління GuardDuty для всіх облікових записів в організації в цьому регіоні. Інші облікові записи в організації можуть бути переглянуті та додані як облікові записи учасників GuardDuty, пов'язані з цим делегованим адміністративним обліковим записом.
Спробуйте дізнатися якомога більше про поведінку облікових даних, які ви збираєтеся використовувати:
Час, коли вони використовуються
Локації
User Agents / Сервіси (Вони можуть використовуватися з awscli, webconsole, lambda...)
Дозволи, які регулярно використовуються
З цією інформацією, відтворіть якомога більше той же сценарій для використання доступу:
Якщо це користувач або роль, доступна користувачем, спробуйте використовувати її в ті ж години, з тієї ж геолокації (навіть з того ж ISP та IP, якщо можливо)
Якщо це роль, яку використовує сервіс, створіть той же сервіс в тій же області та використовуйте його звідти в ті ж часові проміжки
Завжди намагайтеся використовувати ті ж дозволи, які використовував цей принципал
Якщо вам потрібно використовувати інші дозволи або зловживати дозволом (наприклад, завантажити 1.000.000 файлів журналу cloudtrail), робіть це повільно і з мінімальною кількістю взаємодій з AWS (awscli іноді викликає кілька API для читання перед записом)
guardduty:UpdateDetectorЗ цим дозволом ви можете вимкнути GuardDuty, щоб уникнути спрацьовування сповіщень.
guardduty:CreateFilterЗловмисники з цим дозволом мають можливість використовувати фільтри для автоматичного архівування знахідок:
iam:PutRolePolicy, (guardduty:CreateIPSet|guardduty:UpdateIPSet)Зловмисники з попередніми привілеями могли б змінити Список довірених IP GuardDuty, додавши свою IP-адресу до нього та уникнути генерації сповіщень.
guardduty:DeletePublishingDestinationЗловмисники можуть видалити призначення, щоб запобігти сповіщенням:
Видалення цього публікаційного призначення не вплине на генерацію або видимість висновків у консолі GuardDuty. GuardDuty продовжить аналізувати події у вашому середовищі AWS, виявляти підозрілу або несподівану поведінку та генерувати висновки.
Зверніть увагу, що існує десятки висновків GuardDuty, однак, як Red Teamer, не всі з них вплинуть на вас, і що краще, у вас є повна документація на кожен з них в https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html, тому ознайомтеся з нею перед виконанням будь-яких дій, щоб не бути спійманим.
Ось кілька прикладів обходу специфічних висновків GuardDuty:
GuardDuty виявляє запити AWS API з поширених інструментів тестування на проникнення та активує PenTest Finding. Це виявляється за назвою агента користувача, яка передається в запиті API. Отже, модифікація агента користувача може запобігти виявленню атаки GuardDuty.
Щоб запобігти цьому, ви можете знайти скрипт session.py у пакеті botocore і змінити агента користувача, або налаштувати Burp Suite як проксі для AWS CLI та змінити агента користувача за допомогою MitM, або просто використати ОС, таку як Ubuntu, Mac або Windows, що запобігатиме спрацьовуванню цього сповіщення.
Витягування облікових даних EC2 з сервісу метаданих та використання їх поза середовищем AWS активує сповіщення UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. У свою чергу, використання цих облікових даних з вашого EC2 екземпляра активує сповіщення UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS. Проте, використання облікових даних на іншому скомпрометованому EC2 екземплярі в межах того ж облікового запису залишається непоміченим, не викликаючи жодного сповіщення.
Отже, використовуйте ексфільтровані облікові дані зсередини машини, де ви їх знайшли, щоб не активувати це сповіщення.
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
