83% организаций за последний год словили минимум один cloud account takeover - это данные Abnormal Security за 2024 год. Почти каждая пятая - десять и более инцидентов. Red Canary в ежегодном Threat Detection Report поставил T1078.004 Cloud Accounts на первое место по частоте обнаружения - выше ransomware и spear phishing. А в рунете атаки на облачные аккаунты до сих пор разбираются на уровне «включите двухфакторку». Без единого CloudTrail-запроса, без Sigma-правила, без правила корреляции. Ниже - конкретные attack chain в AWS и Azure и то, что SOC обязан видеть на каждом этапе.
T1078.004 Cloud Accounts - место в kill chain и почему SOC буксует
T1078.004 (Cloud Accounts) в MITRE ATT&CK покрывает сразу четыре тактики: Initial Access, Persistence, Privilege Escalation и Defense Evasion. Нетипичная ситуация - одна техника закрывает атакующему несколько этапов одновременно. Получил валидные облачные credentials - вошёл в среду, закрепился, поднял привилегии. И всё это выглядит как легитимная активность.Вот в чём главная боль SOC: API-вызовы с валидными credentials неотличимы от действий реального пользователя без поведенческого baseline. Red Canary фиксирует, что основная масса детектов T1078.004 приходится на этап логина - аномальный источник, нетипичный user agent, несоответствие геолокации. После успешной аутентификации детектирование резко усложняется, потому что атакующий работает через штатные API и консоли. По сути - становится «легитимным пользователем».
Типичная цепочка при компрометации облачного аккаунта:
- Initial Access - фишинг, утечка ключей, SSRF к IMDS, social engineering helpdesk
- Discovery - перебор доступных API, чтение IAM-политик, enumeration хранилищ
- Privilege Escalation - PassRole, AssumeRole, создание новых credentials
- Persistence - backdoor-аккаунты, изменение federation settings, вредоносные OAuth-приложения
- Impact - exfiltration через нативные storage-сервисы, шифрование бэкапов через API, запуск cryptomining
Decision tree: какой вектор initial access ждать
| Условие в инфраструктуре | Вероятный вектор | Что мониторить первым |
|---|---|---|
| AWS Amplify CLI до версии 12.10.1 | CVE-2024-28056, AssumeRoleWithWebIdentity без условий | CloudTrail: sts:AssumeRoleWithWebIdentity с нетипичным sourceIdentity |
| Код в public-репозиториях | Утечка IAM access keys | GuardDuty: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration |
| EC2 с IMDSv1 (без hop limit) | SSRF → кража IAM-токенов через IMDS | VPC Flow Logs + CloudTrail: обращения к 169.254.169.254 |
| Azure AD с федерацией (ADFS/PingFederate) | Манипуляция federation settings, golden SAML | Azure AD Audit Logs: изменения в trustedDomain |
| OAuth-интеграции с SaaS | Компрометация токенов, вредоносные app registrations | Azure AD: новые ServicePrincipal с широкими permissions |
| Helpdesk без верификации по второму каналу | Social engineering для сброса пароля/MFA | IdP: MFA reset + логин с нового устройства < 1 часа |
AWS: attack chain и detection в CloudTrail
Кража IAM-credentials: три основных вектора
Утечка ключей из репозиториев.Azure: компрометация identity plane и detection
Service Principals, federation и OAuth-токены
По данным Recorded Future (2025), атаки на облачные аккаунты в Azure-средах бьют по трём направлениям:Компрометация Service Principals. Service Principal - identity для приложений и автоматизации. Если приложение с permissions
Directory.ReadWrite.All скомпрометировано, атакующий получает контроль над tenant'ом. В отличие от пользовательских аккаунтов, Service Principals часто не покрыты MFA и Conditional Access. Это слепая зона, которую SOC-команды регулярно пропускают - просто потому что Service Principals не отображаются в стандартных дашбордах рядом с «живыми» пользователями.Манипуляция federation. Recorded Future фиксирует: атакующие изменяют настройки федерации, злоупотребляют sync-аккаунтами, подделывают токены или создают backdoor-identity для имперсонации пользователей с полным обходом MFA. Прямой аналог golden SAML / golden ticket из on-prem AD, только в облаке.
OAuth app registration. Создание вредоносного приложения с permissions на чтение почты, файлов или управление директорией - persistence, который переживает смену пароля скомпрометированного пользователя. Атакующий добивается consent grant от пользователя с достаточными привилегиями - и дальше приложение работает автономно. Пароль сменили, MFA перевыпустили, а вредоносное приложение продолжает тянуть данные.
Применимость: внешний пентест (через фишинг consent grant), внутренний (через компрометацию Global Admin или Application Admin).
Detection через Azure AD Logs и Sigma-правила
Sigma-правила из SigmaHQ для Azure-среды:azure_tap_added.yml- детектирует добавление Temporary Access Pass (TAP). TAP - альтернативный метод аутентификации, который атакующий добавляет для обхода MFA после компрометации admin-аккаунтаazure_mfa_interrupted.yml- прерванные MFA-запросы; массовые прерывания указывают на MFA fatigue атакуazure_mfa_denies.yml- множественные отказы MFA с последующим успешным логином = подозрение на SIM swap или компрометацию authentication methodokta_new_behaviours_admin_console.yml- если Okta используется как IdP, правило ловит новые поведенческие паттерны при доступе к admin-консоли
Detection-чеклист для SOC: покрытие T1078.004
Минимальный набор детектов, обязательный для покрытия атак на облачные аккаунты:| Категория | Что детектировать | Источник данных | Sigma-правило |
|---|---|---|---|
| Аномальный логин | Новая геолокация, нетипичный ASN, impossible travel | CloudTrail / Azure AD Sign-In Logs | - |
| AiTM-маркер | OfficeHome + user agent Axios | Azure AD Sign-In Logs | - |
| Credential persistence | Создание access key или login profile для другого пользователя | CloudTrail | aws_iam_s3browser_loginprofile_creation.yml |
| MFA manipulation | Добавление TAP, смена MFA-фактора | Azure AD Audit Logs | azure_tap_added.yml |
| MFA fatigue | Множественные deny/interrupt + успешный логин | Azure AD Sign-In Logs | azure_mfa_interrupted.yml, azure_mfa_denies.yml |
| IAM escalation | PassRole + CreateFunction, AttachRolePolicy с wildcard | CloudTrail | - |
| Anti-forensics | StopLogging, DeleteTrail, DeleteFlowLogs | CloudTrail | - |
| Admin anomaly | Новое поведение в admin-консоли IdP | Okta System Log | okta_new_behaviours_admin_console.yml |
По D3FEND (MITRE), ключевые контрмеры для T1078.004: D3-AM (Access Modeling) - построение модели нормального доступа, D3-AA (Agent Authentication) - усиление аутентификации, D3-AL (Account Locking) - автоматическая блокировка при аномалиях. Фундамент - baseline нормального поведения (NIST CSF 2.0, DE.AE-01), без которого детекты генерируют шум вместо actionable alerts.
Для организаций-субъектов КИИ компрометация облачного аккаунта с доступом к значимым объектам запускает обязанности по уведомлению ФСТЭК по ФЗ-187 (ст. 14) - надзор через плановые и внеплановые проверки.
Trade-off защитных мер: что покрывает и где слепые зоны
| Мера | Покрывает | НЕ покрывает | Когда обязательна |
|---|---|---|---|
| MFA (FIDO2/WebAuthn) | Фишинг паролей, credential stuffing, password spray | AiTM с Evilginx-прокси, session hijacking, Service Principals | Все пользовательские аккаунты |
| IMDSv2 (hop limit) | SSRF к Instance Metadata Service | Утечку long-lived access keys из репозиториев | Все EC2-инстансы без исключений |
| Least privilege IAM | Снижение blast radius | Не предотвращает initial access; сложно поддерживать в dynamic environments | Постоянный процесс + IAM Access Analyzer |
| Conditional Access (Azure) | Ограничение по геолокации, устройству, risk level | Insider на compliant device из trusted location | Дополнение к MFA |
| CloudTrail + SIEM | Visibility, audit trail, forensics | Без правил корреляции и baseline - бесполезен | С первого дня, все регионы |
| GuardDuty (AWS) | Anomaly detection, crypto mining, credential exfiltration | Кастомные attack chain; high false positive на старте | Включить + настроить suppression |
| Credential rotation | Сокращение окна эксплуатации | Не помогает при token theft (STS temporary credentials) | Автоматизировать через Config rules |
По данным Abnormal Security, 63% security-лидеров скептически оценивают MFA как защиту от account takeover, а 65% - SSO. Скепсис обоснован: MFA закрывает категорию атак (credential stuffing, password spray), но не AiTM, session hijacking или злоупотребление OAuth-токенами. При этом 87% организаций ожидают нативную защиту от ATO со стороны облачного провайдера. Но провайдеры - не security-компании, и их встроенные механизмы заточены под защиту от misconfiguration, а не под real-time detection компрометации облачного аккаунта.
На нескольких red team проектах в 2024 году я видел одну и ту же картину: организация включила MFA для всех пользователей, настроила Conditional Access, подключила GuardDuty - и при этом не имела ни одного правила корреляции, которое связывало бы облачные события в цепочку. Отдельные alertы на
ConsoleLogin из необычной геолокации были. Корреляция ConsoleLogin → CreateAccessKey → RunInstances с GPU-типом за 60 минут - отсутствовала. Результат: cryptomining-кампания работала трое суток, пока не пришёл счёт от AWS.Корень проблемы не в инструментах. CloudTrail, Azure AD Logs, GuardDuty, Defender for Cloud - все генерируют события. Проблема - в отсутствии облачно-специфичных SOC-playbooks, которые описывают не «что мониторить», а «что делать, когда видишь последовательность A → B → C за N минут».
В on-prem мире playbooks для lateral movement через Pass-the-Hash стандартизированы уже десять лет. Облачный эквивалент - цепочка
AssumeRole → CreateLoginProfile → ConsoleLogin → PutBucketPolicy - в большинстве SOC-команд остаётся за рамками runbook'ов. Пока подход строится на механическом переносе on-prem детектов в облако, атакующие будут на шаг впереди - они-то используют нативные облачные API. Если интересно, как другие SOC-команды строят облачно-специфичные playbook'ы под разные SIEM-стеки - на codeby.net обсуждают подобные кейсы с примерами корреляций.
Последнее редактирование:
