Статья Мисконфигурация облака как вектор атаки: S3-бакеты, снапшоты и storage AWS/Azure/GCP

На пентесте финтех-компании я нашёл S3-бакет с продакшн-бэкапами БД за три минуты - aws s3 ls s3://company-prod-backups --no-sign-request. Внутри лежали SQL-дампы с PII на сотни тысяч клиентов, ключи API к платёжному шлюзу и .env-файл с credentials от RDS-инстанса. Бакет висел больше года. CSPM у клиента не стояло. Никакого.

Это не уникальный случай - это норма. По данным CrowdStrike Global Threat Report 2025, количество облачных вторжений выросло на 26% год к году, а IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с использованием валидных credentials на 71%. Мисконфигурация облака - самый дешёвый для атакующего вектор: не нужны zero-day, не нужна социальная инженерия. Хватит curl и понимания, где искать.

Kill chain облачной атаки через мисконфигурацию хранилищ​

Атака на незащищённое облачное хранилище укладывается в конкретные тактики MITRE ATT&CK. Вот маппинг цепочки, которую я прохожу на облачных пентестах:

Этап	Техника MITRE ATT&CK	Что происходит
Разведка	Cloud Storage Object Discovery (T1619, Discovery)	Перечисление бакетов, контейнеров, объектов
Разведка	Cloud Infrastructure Discovery (T1580, Discovery)	Обнаружение публичных снапшотов, инстансов
Initial Access / Persistence	Cloud Accounts (T1078.004, Initial Access / Persistence / Privilege Escalation / Defense Evasion)	Вход с утекшими облачными credentials
Credential Access	Cloud Instance Metadata API (T1552.005, Credential Access)	Извлечение токенов через SSRF к metadata service
Сбор данных	Data from Cloud Storage (T1530, Collection)	Массовое скачивание из открытых хранилищ
Сбор / Defense Evasion	Create Snapshot (T1578.001, Defense Evasion)	Создание снапшотов чужих дисков для офлайн-анализа
Exfiltration	Transfer Data to Cloud Account (T1537, Exfiltration)	Копирование данных в подконтрольный аккаунт
Заметание следов	Disable or Modify Cloud Logs (T1562.008, Defense Evasion)	Отключение CloudTrail

Цепочка не линейная - она ветвится в зависимости от находок. Открытый бакет даёт прямой путь к T1530. Утёкший ключ в .env-файле - это T1078.004 и дальше lateral movement внутри облачного аккаунта. SSRF в веб-приложении на EC2 - классический T1552.005 с извлечением временных credentials из metadata service (Atomic Red Team тесты доступны для Azure, на AWS воспроизводится вручную через curl к 169.254.169.254). OWASP относит открытые облачные хранилища к категории A05:2021 - Security Misconfiguration: insecure default configurations, open cloud storage.

Recon: как атакующие находят открытые S3-бакеты и облачные хранилища​

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

• ОС: Linux (Kali/Ubuntu 22.04+) или macOS
• Минимальные ресурсы: 2 ГБ RAM, 10 ГБ свободного места (для хранения результатов сканирования)
• Инструменты: AWS CLI v2, Azure CLI (az), Google Cloud SDK (gsutil), trufflehog v3 (>15k звёзд GitHub, активно поддерживается), s3scanner (последний релиз: 2023, Python)
• Сеть: интернет-доступ обязателен (облачные API недоступны offline)
• Привилегии: начальная разведка выполняется анонимно (--no-sign-request); для глубокого перечисления нужны любые валидные IAM credentials

AWS S3: три подхода к обнаружению​

Пассивная разведка. Google dorks типа site:s3.amazonaws.com "companyname" и inurl:s3.amazonaws.com filetype:sql - первое, с чего начинаю. GrayhatWarfare (grayhatwarfare.com) агрегирует индекс публичных бакетов с поиском по ключевым словам и именам файлов. Сертификаты SSL через crt.sh покажут поддомены, часть которых указывает на S3-hosted ресурсы. GrayhatWarfare и CloudFox (BishopFox) перечисляют публичные облачные ресурсы AWS через комбинацию методов.

Перебор имён бакетов. S3-бакеты живут в глобальном пространстве имён - если company-prod-backups существует, он кому-то принадлежит. Генерирую варианты из имени компании, продуктов, окружений: company-backup, company-staging, company-logs, company-assets-prod. Инструмент s3scanner автоматизирует перебор и проверяет ACL каждого найденного бакета. Применимость: внешний пентест без credentials.

Через утечку credentials. На практике - самый результативный путь. trufflehog сканирует git-историю и вытаскивает AWS-ключи, токены, пароли. По данным CrowdStrike Global Threat Report 2025, количество облачных вторжений выросло на 26% год к году. IBM X-Force Threat Intelligence Index 2025 фиксирует увеличение на 71% атак с использованием валидных credentials - облачные ключи входят в этот вектор наряду с корпоративными учётными данными.

# Анонимная проверка S3-бакета (внешний пентест)
aws s3 ls s3://target-bucket --no-sign-request
# Рекурсивный листинг объектов
aws s3 ls s3://target-bucket --no-sign-request --recursive --human-readable
# ACL бакета - требует s3:GetBucketAcl (обычно недоступно анонимно, используйте при наличии IAM credentials)
aws s3api get-bucket-acl --bucket target-bucket
# Bucket policy - требует s3:GetBucketPolicy (аналогично, анонимно вернёт AccessDenied)
aws s3api get-bucket-policy --bucket target-bucket
# Анонимная проверка публичности - листинг объектов
aws s3api list-objects-v2 --bucket target-bucket --no-sign-request --max-keys 10

Если get-bucket-acl (требует IAM credentials с правом s3:GetBucketAcl) возвращает grant для AllUsers или AuthenticatedUsers - публичный S3 бакет, дальше объяснять не надо. Если get-bucket-policy содержит "Principal": "*" - тот же результат. Для анонимной проверки достаточно aws s3 ls или list-objects-v2 с --no-sign-request: успешный ответ = публичный доступ.

Azure Blob Storage и GCP: аналогичные паттерны​

Azure. Контейнеры внутри storage accounts. Анонимный доступ возможен, если storage account разрешает allowBlobPublicAccess и контейнер настроен как container (листинг и чтение) или blob (чтение по прямой ссылке). Проверка: curl -s -H 'x-ms-version: 2021-12-02' "https://<account>.blob.core.windows.net/<container>?restype=container&comp=list" - XML со списком блобов означает открытый контейнер. Microsoft изменил дефолт для новых storage accounts в ноябре 2023, отключив anonymous public access на уровне account by default, но существующие аккаунты с мисконфигурацией Azure Blob Storage обновление не затронуло. Инструмент BlobHunter (Python, последнее обновление: 2022) перечисляет storage accounts по подпискам Azure и проверяет публичный доступ.

GCP. Команда gsutil ls gs://bucket-name для анонимной проверки. GCP bucket misconfiguration часто связана с тем, что uniform bucket-level access не включён - тогда каждый объект может иметь собственный ACL, и контроль превращается в хаос. Организационная политика constraints/storage.publicAccessPrevention на уровне организации и VPC Service Controls для предотвращения data exfiltration - два основных защитных рубежа.

Эксплуатация: от листинга до полного доступа​

Открытые S3-бакеты - чтение, запись, ransomware​

Три сценария эксплуатации открытых S3-бакетов в зависимости от ACL:

Только чтение. Атакующий перечисляет объекты (T1619, Cloud Storage Object Discovery), находит SQL-дампы, конфиг-файлы, бэкапы - и тянет всё (T1530, Data from Cloud Storage). Утечка данных через S3 в этом сценарии происходит за часы: по данным IBM Cost of a Data Breach Report, среднее время обнаружения утечки исторически составляет порядка 200+ дней - за это время терабайты уже украдены. А автоматизированные сканеры работают 24/7, индексируя миллионы потенциальных целей.

По данным Verizon DBIR, мисконфигурация остаётся одним из ведущих факторов утечек - до 38% веб-инцидентов связаны с ошибками конфигурации. Значительная доля - напрямую с cloud storage misconfiguration.

Запись доступна. Если ACL или policy разрешает s3:PutObject - это уже не утечка, это захват инфраструктуры. Атакующий подменяет файлы (supply chain через статические ассеты), загружает веб-шелл, размещает фишинговую страницу на доверенном домене. По данным Sprocket Security, на пентестах выявляли S3 bucket takeover: домен указывал на бакет, который больше не существовал. Атакующий регистрировал бакет с тем же именем и раздавал вредоносный контент с корпоративного домена. DNS-запись оставалась после миграции - и никто её не чистил. Классическая история: уехали, а ключи оставили в двери.

S3-ransomware. Ransomware-группы активно целятся в S3. Согласно исследованию Halcyon Research (январь 2025, кампания Codefinger), описан сценарий перезаписи объектов с использованием SSE-C (Server-Side Encryption with Customer-Provided Keys - ключ знает только атакующий) и удаления оригиналов с загрузкой ransom note. Отдельно описывается злоупотребление SSE-KMS с ротацией ключа шифрования на подконтрольный атакующему. По данным исследователей, атакующий в первую очередь проверяет три настройки: отсутствие versioning (нельзя откатить), отключённый Object Lock (объекты можно перезаписать), отсутствие MFA Delete (удаление без подтверждения). Все три выполнены - бакет идеальная мишень для ransomware.

Trend Micro и другие исследователи описывают более широкий спектр облачных целей: EBS-снапшоты, RDS-базы, ECR-образы контейнеров и системы бэкапирования (S3, Glacier, AWS Backup). Логика атакующих: уничтожить бэкапы, зашифровать основные данные, оставить жертву без пути восстановления.

Кейс 2025 года. Исследователи Casmer Labs (Cloud Storage Security) обнаружили публично доступный S3-бакет с сотнями тысяч PDF-файлов банковских платёжных поручений в финансовой системе Индии. Имена, адреса, телефоны, номера банковских счётов и коды маршрутизации IFSC. Бакет был живой - новые файлы продолжали загружаться во время анализа. Для доступа не требовалось ничего - бакет просто имел public read access. Это не взлом. Это мисконфигурация.

Публичные снапшоты AWS: credentials на блюдечке​

Техника Create Snapshot (T1578.001, Defense Impairment) в MITRE ATT&CK описывает создание или обнаружение снапшотов облачных дисков для офлайн-доступа к данным. На пентестах публичные снапшоты AWS дают результаты чаще, чем открытые бакеты - и находки, как правило, критичнее.

AWS позволяет делать EBS-снапшоты публичными - предполагается для переноса данных между аккаунтами. Разработчик создаёт снапшот, забывает убрать public access, и содержимое диска доступно любому AWS-аккаунту. Для эксплуатации достаточно знать Account ID цели.

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

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

Cloud Storage Security выделяет четыре фактора, замедляющих реагирование: отсутствие полного инвентаря cloud storage, отсутствие классификации данных (бакет с маркетинговыми скриншотами - не то же, что бакет с банковскими формами), ограниченная видимость object-level активности и неясное владение ресурсами.

Для пентестера эти пробелы - подсказка, где копать. Prowler (активно поддерживается, >10k звёзд GitHub) и ScoutSuite (последнее обновление: 2024) запускаю на первом этапе внутреннего облачного пентеста. За минуты они находят публичные бакеты, избыточные IAM policies, отключённый CloudTrail, отсутствие шифрования.

Decision tree: выбор вектора при облачном пентесте​

Условие	Техника	Инструмент	Контекст
Имя компании, нет credentials	Брутфорс имён бакетов + OSINT	s3scanner, GrayhatWarfare	Внешний пентест
AWS Access Key (low-priv)	Перечисление S3, EBS snapshots, IAM	Pacu, ScoutSuite, Prowler	Внутренний пентест
SSRF в приложении на EC2	Cloud Instance Metadata API (T1552.005)	curl к 169.254.169.254	Внешний пентест, если IMDSv1
Доступ к CI/CD	Поиск секретов в variables и artifacts	trufflehog, gitleaks	Внешний/внутренний
Reader role в Azure	Перечисление storage accounts с public access	az cli, BlobHunter	Внутренний пентест
Любой доступ к AWS account	Публичные снапшоты по Account ID (T1578.001)	aws ec2 describe-snapshots	Внутренний пентест

Два года аудитов облачных сред - от стартапов до enterprise - и один стабильный паттерн. Команда безопасности покупает CSPM, настраивает правила, считает задачу закрытой. Через полгода в тикет-системе висят сотни непроработанных findings, а DevOps продолжает создавать бакеты через консоль, минуя IaC-пайплайн. По данным CrowdStrike Global Threat Report 2025, количество облачных вторжений выросло на 26% за год - при том что инструментов защиты стало больше.

Проблема не в технологиях детекции. Ownership облачных ресурсов размыт между DevOps, SRE и Security - и ни одна команда не считает безопасность облачных хранилищ своей головной болью. CSPM находит проблему, но её никто не фиксит, потому что конкретный бакет не привязан к конкретному человеку. Пока ownership не закреплён за инженером с алертами в его PagerDuty (а не за абстрактной «командой инфраструктуры»), все инструменты мониторинга генерируют шум, а не защиту.

Облачные атаки через неправильную конфигурацию исчезнут не когда появится очередной CNAPP, а когда каждый storage-ресурс получит владельца, которому больно за его мисконфигурацию. Если хочешь отработать эту цепочку от разведки бакетов до эксфильтрации - на WAPT в Codeby Academy облачный вектор разбирают на лабах с реальной AWS-инфраструктурой.