На предпоследнем проекте для финтеха мы получили read-only IAM-ключи «для аудита». Через четыре часа - полный доступ к production-бакету с персональными данными. Цепочка:
iam:PassRole на забытой dev-роли, Lambda-функция с execution role, читающей Secrets Manager, оттуда credentials от RDS. Ни одного эксплойта, ни одной CVE - только штатные API-вызовы AWS. ScoutSuite не показал цепочку privesc через PassRole. Prowler - тем более. Нашёл Pacu через iam__privesc_scan, подтвердил руками. Вот типичная реальность облачного пентеста: критический путь проходит не через открытый порт, а через конфигурацию IAM, и автоматика видит лишь отдельные куски мозаики.Почему облачный пентест - отдельная дисциплина
В on-premise привычная логика строится вокруг сетевого маршрута: подсети, открытые порты, SMB, AD, lateral movement через WinRM или RDP. В облаке сетевой слой остаётся, но перестаёт быть основным источником полномочий. EC2-инстанс закрыт от интернета - зато его instance profile даёт доступ к Secrets Manager. Lambda без публичного endpoint имеет execution role с правами на production-бакет. CI/CD-пайплайн запускается из внутреннего GitLab, но его cloud role меняет функции и политики.Вектор смещается от сетевых уязвимостей к уязвимостям конфигурации и управления идентификацией. По данным Wiz State of Cloud Security 2024, более 80% реальных инцидентов в облаке связаны не с уязвимостями ПО, а с ошибками конфигурации: избыточные IAM-права, публично открытые хранилища, отсутствие шифрования, незащищённые API-endpoint. OWASP подтверждает картину - Security Misconfiguration (A05:2021) и Broken Access Control (A01:2021) стабильно в тройке лидеров, и в облаке они проявляются особенно ярко.
Если маппить на MITRE ATT&CK, типичный облачный пентест покрывает: Cloud Accounts (T1078.004, Initial Access / Persistence / Privilege Escalation), Cloud Infrastructure Discovery (T1580, Discovery), Cloud Instance Metadata API (T1552.005, Credential Access), Data from Cloud Storage (T1530, Collection), Additional Cloud Credentials (T1098.001, Persistence), Disable or Modify Cloud Logs (T1562.008, Defense Evasion). Каждая техника - не про «взлом», а про злоупотребление легитимными API. Ни один IDS не сработает на
aws secretsmanager get-secret-value, если вызов идёт от роли с правами.Shared Responsibility Model задаёт границы теста. Провайдер отвечает за инфраструктуру облака (железо, гипервизоры), клиент - за всё внутри аккаунта. Пентест ограничен зоной клиента, и именно там лежат критичные находки. AWS разрешает тестирование без предварительного согласования только для явно перечисленных сервисов (EC2, RDS, Lambda, S3, CloudFront, API Gateway и нескольких других согласно AWS Customer Support Policy for Penetration Testing); для остальных нужна подача формы Simulated Events. Azure и GCP - аналогично, но DDoS-тесты, атаки на DNS и флудинг запрещены у всех трёх.
Методология пентеста облачной инфраструктуры: от разведки до persistence
Разведка облачной поверхности и перечисление ресурсов
Внешняя разведка в облаке нужна не ради таблицы поддоменов. Задача - найти облачные привязки, забытые окружения и ресурсы, которые потом сопоставляются с внутренним инвентарём. CNAME на старый load balancer, object storage endpoint в dev-зоне, сертификат staging-среды - всё это ценно, когда понятно, какой workload за ними стоит и какие права он получает.Требования к окружению:
- ОС: Linux (Kali, Ubuntu 22.04+) или macOS
- AWS CLI v2, Azure CLI, gcloud SDK - через отдельный
--profileдля тестового аккаунта - Python 3.9+ для ScoutSuite (pip install scoutsuite) и Pacu (клонирование из GitHub)
- Минимум 4 ГБ RAM (ScoutSuite при аудите крупного аккаунта жрёт 2-3 ГБ)
- Изолированная VM или Docker-контейнер - не смешивать credentials тестируемого аккаунта с рабочими
- Стабильный интернет (все три инструмента работают через облачные API, offline-режима нет)
subfinder -d target.com), Certificate Transparency, HTTP-fingerprinting (httpx с флагами -title -tech-detect -status-code). Для поиска открытых S3-бакетов - cloud_enum по ключевому слову или s3scanner. GrayHatWarfare покрывает публичные бакеты через веб-интерфейс. Это Cloud Service Discovery (T1526, Discovery).После получения credentials первая команда -
aws sts get-caller-identity. Без фиксации identity отчёт невоспроизводим: одна и та же команда под auditor role, workload role и federated user даёт разные результаты. Дальше - Cloud Infrastructure Discovery (T1580): перечисление EC2 во всех регионах, load balancers, Lambda-функций, S3-бакетов, ECS task definitions. Важен не просто список ресурсов, а граф связей: какая роль привязана к workload, кто может делать sts:AssumeRole, какие trust policies открыты на внешние аккаунты. Без графа вы видите точки, но не цепочки между ними.IAM privilege escalation: цепочки вместо отдельных находок
IAM-эскалация редко выглядит как одинAdministratorAccess на пользователе. Так бывает в учебных лабах, но не в продакшене. Чаще цепочка собирается из формально разрешённых действий: пользователь создаёт Lambda, Lambda получает роль через iam:PassRole, роль читает секрет из Secrets Manager, секрет открывает пайплайн, пайплайн деплоит в production. На каждом шаге API работает штатно, но вся цепочка выводит далеко за исходный уровень доступа. Это техники Additional Cloud Credentials (T1098.001) и Additional Cloud Roles (T1098.003) - persistence и privilege escalation через IAM.Проверка начинается с текущих прав:
Bash:
aws sts get-caller-identity
aws iam list-attached-role-policies --role-name TARGET_ROLE
aws iam list-role-policies --role-name TARGET_ROLE
# Содержимое inline-политики
aws iam get-role-policy --role-name TARGET_ROLE --policy-name POLICY_NAMEAssumeRolePolicyDocument. Если Principal указывает arn:aws:iam::111122223333:root без условия sts:ExternalId - вот вам потенциальный lateral movement в другой аккаунт. Контролируемый вариант ограничивает конкретную роль и требует внешний идентификатор. Подтверждение перехода: aws sts assume-role --role-arn ... --role-session-name pentest-validation, затем повторный get-caller-identity для фиксации новой identity.Отдельная боль - non-human identities: OAuth-приложения, API-ключи, CI/CD-токены, Kubernetes ServiceAccounts. Они живут дольше пользовательских сессий, хуже инвентаризируются и почти всегда получают права шире реального сценария использования. На одном проекте мы нашли CI/CD-токен двухлетней давности с правом
iam:* - его создали «на время миграции» и забыли.[Применимо: grey box (выданные read-only credentials) и white box. В black box - только если обнаружены утечки ключей через OSINT.]
SSRF и metadata endpoint: когда AppSec-баг ведёт к облачной катастрофе
SSRF (OWASP A10:2021) в обычном приложении ограничивается доступом к внутренним HTTP-ресурсам. В облаке тот же баг может привести к workload credentials - и вот это уже совсем другой масштаб. Если приложение работает на EC2 с ролью, metadata endpointhttp://169.254.169.254 становится мостом от веб-уязвимости к Cloud API - Cloud Instance Metadata API (T1552.005, Credential Access).IMDSv1 не требует токен: запрос
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME возвращает AccessKeyId, SecretAccessKey и Token. Просто так, без вопросов. IMDSv2 требует PUT-запрос с заголовком для получения сессионного токена - стандартный SSRF через GET/redirect это не пройдёт (нужен контроль метода и заголовков). Проверка статуса IMDS на инстансе: поле MetadataOptions.HttpTokens в выводе describe-instances. Значение optional - IMDSv1 активен, инстанс уязвим. Значение required - только IMDSv2.В Azure metadata endpoint
http://169.254.169.254/metadata/instance требует заголовок Metadata: true - частичная защита от простого SSRF, но redirect-based атаки обходят это ограничение. В GCP - http://metadata.google.internal с заголовком Metadata-Flavor: Google.Казалось бы, IMDSv2 решает проблему. Но на практике мы регулярно видим
HttpTokens = "optional" на production-инстансах - особенно тех, что создавались до 2021 года и с тех пор не трогались.[Применимо: внешний пентест при наличии SSRF в веб-приложении; внутренний - при доступе к EC2/VM.]
ScoutSuite, Prowler и Pacu: аудит облачной инфраструктуры на практике
Три инструмента решают три разные задачи. Путаница между ними - ошибка, которая стоит времени и качества отчёта.ScoutSuite - первый проход по конфигурации
ScoutSuite (NCC Group, Python, мультиоблачный: AWS/Azure/GCP/Alibaba/OCI; последний релиз - активно поддерживается, ~5k звёзд на GitHub) подключается к облачному API, вычитывает конфигурацию сервисов и генерирует HTML-отчёт с findings по критичности. Запуск для AWS:scout aws --profile pentest-target --report-dir ./report. Для Azure: az login, затем scout azure --cli. Для GCP: gcloud auth application-default login, затем scout gcp --user-account.Что делает хорошо: полная картина конфигурации за 15-30 минут. Открытые S3-бакеты, security groups с
0.0.0.0/0 на SSH/RDP, IAM-пользователи без MFA, незашифрованные EBS-тома, публичные RDS-инстансы. Для первого прохода по аккаунту - самое то.Что пропускает: цепочки privilege escalation (не моделирует атаку), runtime-конфигурацию Lambda (переменные окружения, код функции), детальный анализ resource-based policies (S3, SQS, SNS - частично). ScoutSuite покажет, что security group открыта, но не скажет, можно ли это использовать в цепочке.
Место в kill chain: Discovery / Recon. Запускается первым для построения карты аккаунта.
Prowler - compliance-шум и реальные риски
Prowler (open source, активно развивается, ~10k звёзд на GitHub; поддерживает AWS/Azure/GCP) изначально создавался как инструмент проверки соответствия CIS Benchmarks и AWS Well-Architected Framework. На среднем AWS-аккаунте Prowler генерирует 200-400 findings. Критичных из них - 3-5. Остальное - compliance-шум: отсутствие тегов, не включённый Access Analyzer, CloudTrail без CMK-шифрования. Для compliance-отчёта заказчику - полезно. Для цепочки атаки - шум, который надо фильтровать.Запуск с фильтрацией:
prowler aws --severity critical high -M csv json-ocsf. Prowler сильнее ScoutSuite в granular-проверках по compliance-фреймворкам (PCI DSS, HIPAA), в анализе CloudTrail-конфигурации, в детекции отключённого логирования - а это критично для обнаружения техники Disable or Modify Cloud Logs (T1562.008).Место в kill chain: Recon / Audit. Параллельно со ScoutSuite для перекрёстной проверки.
Pacu - exploitation framework для AWS
Pacu (Rhino Security Labs, Python, только AWS; ~4k звёзд на GitHub, активно поддерживается) - принципиально другой класс инструмента. ScoutSuite и Prowler ищут мисконфигурации. Pacu их эксплуатирует.
Bash:
# В консоли Pacu после set_keys:
run iam__enum_permissions # что может текущая identity
run iam__privesc_scan # ~20 известных IAM-цепочек privesc
run lambda__backdoor_new_roles_assumerole # захват новых ролей через Lambda
run iam__backdoor_users_keys # backdoor access key (с согласия заказчика!)iam__privesc_scan проверяет конкретные комбинации разрешений: iam:PassRole + lambda:CreateFunction, iam:CreatePolicyVersion, iam:AttachUserPolicy, sts:AssumeRole на роли с широкими правами - и выдаёт готовые пути эскалации. Это то, что ScoutSuite и Prowler не делают в принципе.Для Azure аналога такого уровня нет - и это проблема. Ближайшая комбинация - ROADtools для разведки Azure AD + ручная эксплуатация через Azure CLI. Для GCP -
gcloud CLI с кастомными скриптами. PMapper (NCC Group) строит граф IAM-привилегий, но не эксплуатирует цепочки.[Применимо: grey box и white box, только AWS. Минимум read-only access к IAM API.]
Выбор инструмента под задачу
| Задача | ScoutSuite | Prowler | Pacu |
|---|---|---|---|
| Карта аккаунта | Основной | Дополнительный | Нет |
| Compliance-отчёт | Частично | Основной | Нет |
| Цепочки privesc | Нет | Нет | Основной |
| Exploitation / PoC | Нет | Нет | Да |
| Мультиоблачность | AWS/Azure/GCP | AWS/Azure/GCP | Только AWS |
| Время запуска | 15-30 мин | 20-40 мин | По модулю |
| Нужен доступ | Read-only | Read-only | Read-only (минимум) |
Оптимальная последовательность на проекте: ScoutSuite первым (карта), Prowler параллельно (compliance + логирование), Pacu после анализа первичных данных (exploitation целевых цепочек). Менять порядок - терять время.
Типичные находки и цепочки эксплуатации мисконфигураций
Изолированная мисконфигурация - это finding. Цепочка мисконфигураций - это critical. Разница между ними - разница между «у вас тут SSH открыт» и «мы прочитали вашу базу клиентов». Вот паттерны, которые встречаются на проектах регулярно.Что видит CloudTrail и GuardDuty: OPSEC облачного пентестера
Облачный пентест без понимания detection-возможностей заказчика - работа вполсилы. IAM и STS API-вызовы фиксируются в CloudTrail. AWS прямо указывает: CloudTrail захватывает IAM и STS API calls, включая вызовы из консоли и через SDK.Критичные события в CloudTrail:
AssumeRole, CreateAccessKey, AttachRolePolicy, PutRolePolicy, CreatePolicyVersion, UpdateAssumeRolePolicy. Если SOC-команда мониторит CloudTrail через Athena, CloudWatch Logs или SIEM - эти действия видны. Вопрос в том, мониторят ли.GuardDuty детектит автоматически. Finding
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration срабатывает, когда temporary credentials EC2 используются с IP за пределами AWS. Recon:IAMUser/MaliciousIPCaller - API-вызовы с IP из threat intelligence feeds. GuardDuty не нужно настраивать - он или включён, или нет.OPSEC-рекомендации для пентестера:
- Temporary credentials через
sts:AssumeRoleс session name, явно маркирующим пентест (например,pentest-codeby-20260510) - не прятаться, а обеспечить воспроизводимость - Не использовать credentials EC2-роли с внешнего IP - GuardDuty сработает мгновенно
- Работать из региона инфраструктуры заказчика - аномалия по геолокации детектируется
- Фиксировать все действия: время, caller identity, target ARN, результат
Нередко облачный пентест сводится к запуску ScoutSuite + Prowler, генерации PDF с 300 findings и передаче заказчику. Формально - пентест проведён. По факту - никто не проверил, можно ли из read-only доступа дойти до production-данных за четыре часа. Проблема не в инструментах - Prowler и ScoutSuite делают ровно то, для чего созданы. Проблема в том, что compliance-аудит продаётся как пентест облачной инфраструктуры. Пентест - это моделирование атаки: цепочки, PassRole, cross-account lateral movement, SSRF до metadata, persistence через «тихие» регионы. Если в отчёте нет ни одной эксплуатированной цепочки, а только список check/fail - заказчик получил аудит, не пентест.
Прогноз на ближайший год: serverless станет основным полем боя. Execution roles Lambda, Cloud Functions, Azure Functions - тот же overprivileged service account, но с ещё меньшей наблюдаемостью. CloudTrail не фиксирует все data events Lambda по умолчанию, а мисконфигураций в serverless уже накоплено с запасом. Инструменты под это направление только формируются - а атакующие уже давно здесь. Если хочешь отработать эти цепочки в легальной среде - на WAPT разбирают облачные вектора с лабами на реальных AWS-аккаунтах.
