На проверке Обнаружение угроз в облаке: настройка GuardDuty, CloudTrail и Defender for Cloud для охоты на атакующих

Понедельник, 9:15 утра. В Slack-канал SOC прилетает алерт GuardDuty: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. Кто-то вытащил временные credentials с EC2-инстанса через Instance Metadata Service и использует их с внешнего IP. Через 40 минут в CloudTrail появляются вызовы DescribeInstances и ListBuckets из региона, в котором у компании нет ни одного ресурса. Ещё через два часа - GetObject к S3-бакету с клиентскими данными. Итого: от первого алерта до эксфильтрации - менее трёх часов. SOC среагировал после обеда, и компания с миллиардным оборотом получила оборотный штраф по 152-ФЗ за утечку персональных данных.

Цепочка стандартная: Cloud Instance Metadata API (T1552.005, Credential Access) для кражи временных credentials, затем Cloud Accounts (T1078.004, Initial Access / Persistence) и Data from Cloud Storage (T1530, Collection). Такие кейсы повторяются с завидной регулярностью. Разберём, как настроить обнаружение угроз в облаке так, чтобы между алертом и реакцией проходили минуты, а не часы.

CloudTrail - фундамент мониторинга безопасности в AWS​

CloudTrail - аудиторский журнал AWS. Каждый вызов API, от RunInstances до PutBucketPolicy, фиксируется с указанием кто, когда, откуда и с какими параметрами выполнил действие. По умолчанию CloudTrail записывает management events в каждом регионе, но для полноценного обнаружения атак в AWS этого мало: data events (обращения к содержимому S3-бакетов, вызовы Lambda) отключены, и именно они покрывают сценарий эксфильтрации из кейса выше. Подробнее - в нашем статье о мисконфигурация облака атаки.

Что настроить до первого инцидента​

Создайте organization-level trail с записью management и data events во всех регионах, включая те, где вы не разворачиваете инфраструктуру. Атакующие целенаправленно лезут в нетипичные регионы, рассчитывая на отсутствие мониторинга - это техника Cloud Infrastructure Discovery (T1580, Discovery). Я видел случай, когда майнер крутился в ap-southeast-1 три недели, потому что trail был включён только в eu-west-1 и eu-central-1.

Агрегируйте логи в централизованный S3-бакет с включённым Object Lock в Compliance mode и versioning (альтернатива - MFA Delete, но обе опции одновременно AWS не поддерживает). Зачем? Первое действие продвинутого атакующего после компрометации - попытка отключить логирование. Техника Disable or Modify Cloud Logs (T1562.008, Defense Evasion) реализуется вызовами StopLogging или DeleteTrail. Защищённый от удаления бакет не позволит уничтожить уже собранные доказательства.

Для анализа подключите Amazon Athena к CloudTrail-бакету - SQL-запросы по миллионам событий без отдельной инфраструктуры. Пример запроса для поиска API-вызовов из нетипичных регионов:

SELECT eventTime, eventName, sourceIPAddress, awsRegion, userIdentity.arn
FROM cloudtrail_logs
WHERE awsRegion NOT IN ('eu-west-1', 'eu-central-1')
  AND eventTime > current_timestamp - interval '24' hour
ORDER BY eventTime DESC
LIMIT 100;

Замените список регионов на те, где реально работает ваша инфраструктура. Всё за пределами - кандидат на расследование.

Ключевые CloudTrail-события для detection​

Привяжем конкретные API-вызовы к техникам MITRE ATT&CK Cloud Matrix:

Техника ATT&CK	API-вызов CloudTrail	Что искать
Cloud Account (T1136.003, Persistence)	CreateUser, CreateAccessKey	Новые IAM-пользователи и ключи, созданные не через IaC-пайплайн
Additional Cloud Roles (T1098.003, Privilege Escalation)	AttachUserPolicy, PutUserPolicy	Назначение AdministratorAccess или wildcard-политик
Disable or Modify Cloud Logs (T1562.008)	StopLogging, DeleteTrail	Любое изменение trail - критический алерт
Data from Cloud Storage (T1530)	GetObject, ListObjects	Массовые чтения из S3 с нетипичных IP или ролей
Compute Hijacking (T1496.001, Impact)	RunInstances	Запуск GPU-инстансов (p3, p4, g5) в нетипичных регионах - криптомайнинг
Cloud Infrastructure Discovery (T1580)	DescribeInstances, ListBuckets	Серия describe/list-вызовов за короткий период - разведка
Cloud Account (T1087.004, Discovery)	ListRoles, ListUsers	Перечисление IAM-сущностей - разведка облачных аккаунтов

AWS GuardDuty - настройка и разбор алертов​

GuardDuty - ML-движок, который анализирует foundational data sources (CloudTrail management events, VPC Flow Logs, DNS-логи), а через отдельно тарифицируемые Protection Plans - ещё и S3 Protection, EKS Protection, Malware Protection, RDS Protection, Lambda Protection и Runtime Monitoring (EC2/ECS/EKS). Под капотом - ML и threat intelligence от AWS и партнёров.

Требования к окружению:

• Аккаунт AWS с правами администратора (или делегированный admin через AWS Organizations)
• GuardDuty включается per-region - активируйте во ВСЕХ регионах, включая неиспользуемые
• Для multi-account: delegated administrator через AWS Organizations
• Стоимость зависит от объёма анализируемых событий с волюмными скидками - актуальные цены на aws.amazon.com/guardduty/pricing

Категории обнаружения и управление ложными срабатываниями​

GuardDuty покрывает следующие категории:

• Compromised EC2 - C2-коммуникации, криптомайнинг, сканирование портов
• Compromised IAM - необычные API-вызовы, impossible travel, обращения через TOR
• Reconnaissance - зондирование сетевых портов, аномальные DNS-запросы
• S3 exfiltration - аномальные паттерны доступа, отключение public access block
• EKS/ECS Runtime - побег из контейнера, privilege escalation в Kubernetes
• Lambda compromise - нетипичные паттерны вызовов Lambda-функций
• RDS - brute force и credential stuffing для Aurora

Сырой поток алертов содержит шум. Два инструмента для его снижения:

Suppression Rules - фильтры для известных легитимных активностей. Типичный случай: сканеры уязвимостей с известных IP генерируют Recon:EC2/PortProbeUnprotectedPort. Suppression rule по serviceRole или sourceIPAddress сканера убирает эти findings из активной очереди. Без этих правил SOC утонет в шуме за первую неделю.

Trusted IP Lists - перечни IP-адресов (офисы, VPN-шлюзы, CI/CD runners), которые GuardDuty исключает из анализа. Не путайте с threat lists: trusted списки исключают из detection, threat списки добавляют IOC.

GuardDuty findings поступают в EventBridge, откуда маршрутизируются в Lambda для автоматического реагирования на инциденты в облаке. Базовый playbook: при алерте severity HIGH на InstanceCredentialExfiltration - Lambda отзывает все активные сессии скомпрометированной роли и шлёт уведомление в SOC. Findings агрегируются в AWS Security Hub вместе с результатами Inspector, Macie и IAM Access Analyzer. Для полноценного threat hunting данные экспортируются в SIEM через S3-коннектор или Kinesis.

Преимущество	Ограничение	Когда использовать	Когда НЕ использовать
ML на нативной телеметрии, zero-config	Только AWS, нет CSPM, нет multi-cloud	Мониторинг AWS-only среды	Как единственный инструмент без threat hunting
Покрытие всех нативных data sources	Высокая стоимость при большом объёме API-вызовов	Multi-account через Organizations	Нужна видимость в Azure или GCP
EventBridge для автоматизации	Нет кастомных detection rules	Baseline detection в дополнение к SIEM	Замена полноценного облачного SOC

Microsoft Defender for Cloud - обнаружение атак в мультиоблачной среде​

Если в инфраструктуре есть Azure-компоненты или мультиоблачная архитектура, Microsoft Defender for Cloud закрывает detection-задачи за пределами AWS. Defender for Cloud работает как CNAPP, объединяя CSPM (Cloud Security Posture Management) и CWP (Cloud Workload Protection).

Требования к окружению:

• Подписка Azure с Contributor-правами
• Для AWS-подключения: доступ к AWS-аккаунту для развёртывания CloudFormation-стека с cross-account IAM role
• Foundational CSPM - бесплатно; Defender CSPM - ~$0.007 за billable resource/час; Defender for Servers Plan 2 - ~$20/месяц за сервер (по данным документации Microsoft)

Ключевое отличие от GuardDuty​

GuardDuty - чистый threat detection. Defender for Cloud - detection плюс posture management. Бесплатный тир CSPM выдаёт рекомендации по security baseline и маппит на CIS, NIST CSF, PCI DSS. Платный Defender CSPM добавляет attack path analysis - визуализацию цепочек от exposed ресурса до критичных данных. На практике это выглядит так: Defender показывает, что публичный Load Balancer ведёт к VM с устаревшим агентом, у которой есть доступ к Key Vault с секретами базы данных. Такие цепочки руками собирать - дни работы.

По данным сравнительного анализа Sysdig, GuardDuty точнее детектит угрозы для AWS-нативных сервисов, чем Defender for Cloud при подключении через AWS-коннектор. Defender for Cloud сильнее в Azure-нативном detection и в задачах cloud security monitoring при мультиоблачном развёртывании. Выбор между ними - не «или-или», а вопрос архитектуры: AWS-only = GuardDuty, мультиоблако = оба.

Defender for Cloud подключается к AWS через CloudFormation-стек. Для GCP - через Workload Identity Federation с деплоем ресурсов Terraform-скриптом, генерируемым порталом Defender for Cloud.

Threat hunting через Sentinel и KQL​

Defender for Cloud передаёт алерты в Microsoft Sentinel (cloud-native SIEM). Для охоты на атакующих в Sentinel используется KQL. Пример запроса для корреляции высокоприоритетных облачных алертов:

SecurityAlert
| where AlertType has_any ("Cloud", "IAM", "S3", "EC2")
| where TimeGenerated > ago(24h)
| where AlertSeverity in ("High", "Medium")
| project TimeGenerated, AlertName, Description, RemediationSteps
| order by TimeGenerated desc

Sentinel объединяет сигналы от Defender XDR, Defender for Cloud и сторонних источников на единой панели инцидентов. Это закрывает требования DE.AE-01 (NIST CSF v2.0) - установление baseline сетевых операций и ожидаемых потоков данных, а также DE.AE-02/DE.AE-03 - корреляция и анализ аномалий.

Threat hunting в облаке: сценарии и detection-чеклист​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

- подозрителен.

Detection-чеклист для SOC​

1. CloudTrail trail включён во ВСЕХ регионах с data events для S3 и Lambda
2. GuardDuty активен во всех регионах, включая неиспользуемые
3. StopLogging и DeleteTrail порождают алерт P1 с немедленным уведомлением дежурного
4. Все CreateUser / CreateAccessKey без IaC-тега направляются на ручной триаж
5. AttachUserPolicy / PutUserPolicy с wildcard порождают алерт P2
6. RunInstances с GPU-типами в нетипичных регионах - алерт P2 (криптомайнинг, T1496.001)
7. Массовые GetObject / ListObjects - корреляция с baseline, порог 3x
8. GuardDuty findings HIGH severity - автоматический revoke через EventBridge + Lambda
9. Экспорт CloudTrail в SIEM с retention минимум 90 дней (контроль AU-11 Audit Record Retention, NIST SP 800-53 Rev 5)
10. Для мультиоблачных сред: Defender for Cloud подключён к AWS через native connector

Большинство облачных инцидентов, которые я разбирал, имели одну общую черту: CloudTrail работал, GuardDuty был включён, но никто не смотрел в алерты систематически. Инструменты стояли в режиме «включил и забыл». Findings копились в Security Hub, дашборд показывал сотни medium-severity алертов, и SOC перестал на них реагировать - классический alert fatigue.

Самая опасная иллюзия в облачной безопасности AWS - что включённый managed-сервис равен работающему detection. GuardDuty не видит, что происходит внутри ОС на EC2. Defender for Cloud при подключении AWS через коннектор даёт менее точное покрытие, чем нативный GuardDuty. CloudTrail без Athena-запросов - просто дорогое хранилище JSON-файлов в S3.

Каждый из этих инструментов закрывает свой слой, и ни один не закрывает все. Реальное обнаружение начинается там, где SOC-инженер садится и пишет кастомные запросы под TTPs своей среды - с учётом того, какие роли используются, какие регионы легитимны, какой baseline нормальной активности. Через полгода такой работы количество false positive падает втрое, а mean time to detect - на порядок. Если интересно как другие команды строят cloud threat hunting pipeline - на codeby.net есть тред, где обсуждают адаптацию Athena-запросов и корреляцию CloudTrail-событий с конкретными SIEM-стеками.