Поиск открытых S3 корзин через OSINT: Google dorking и Amass на практике

На одном из bug bounty проектов обычный Google-дорк site:s3.amazonaws.com "company-name" вернул ссылку на CSV-файл: 12 000 строк с именами сотрудников, корпоративными email, телефонами и должностями. Корзина висела в открытом доступе больше года. Никакой магии — два дорка, один запуск Amass, три команды AWS CLI, 40 минут от первого запроса до готового отчёта. Ниже — разбор каждого шага с командами, ожидаемым выводом и объяснением, где проходит граница между легальным OSINT и статьёй УК.

Место в цепочке атаки: от разведки до утечки данных сотрудников

S3 (Simple Storage Service) — облачное хранилище Amazon Web Services. Данные хранятся в контейнерах — бакетах (buckets, иногда «корзины»). Компании складывают туда всё подряд: публичные картинки для сайта, бэкапы баз данных, внутренние документы и отчёты. Одна ошибка в политике доступа — и бакет с конфиденциальными данными доступен любому, кто знает или подберёт его имя.

По классификации OWASP (организация, которая ведёт рейтинги веб-уязвимостей), открытое облачное хранилище — прямое попадание в категорию A05:2021 Security Misconfiguration. В описании категории OWASP явно упоминает «open cloud storage» как типовой пример.

В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1593 — уникальные идентификаторы, каждый привязан к конкретному этапу атаки) поиск открытых S3 корзин ложится на этап Reconnaissance (разведка):

• T1593 Search Open Websites/Domains — поиск информации о цели через открытые ресурсы
• T1593.002 Search Engines — использование поисковиков, включая Google dorking
• T1596 Search Open Technical Databases — поиск по техническим базам (Shodan, Censys)

Когда бакет найден и содержит данные, техника переходит в тактику Collection: T1530 Data from Cloud Storage — извлечение данных из облачного хранилища.

Полная цепочка: разведка поддоменов → обнаружение ссылок на S3 → проверка прав доступа → фиксация утечки для отчёта. В пентесте или bug bounty финальный шаг — responsible disclosure, не эксфильтрация.

Зачем атакующему ваш бакет. Утечка данных сотрудников (T1589.002 Email Addresses, T1589.003 Employee Names) — готовый фундамент для целевого фишинга. По данным Verizon DBIR 2025, 68% утечек связаны с человеческим фактором, а 36% инцидентов начинаются именно с фишинга. Список сотрудников с email и должностями — не «низкая критичность», а стартовая точка для полноценной атаки на организацию.

Google dorking для поиска открытых S3-корзин

Google dorking (он же Google hacking) — техника поиска с использованием специальных операторов, которые сужают выдачу до конкретных типов контента. Для OSINT-разведки это первый и самый быстрый шаг: ноль установок, ноль настроек, результат за секунды.

Основные дорки для S3

Бакеты AWS доступны по двум форматам URL. Виртуальный хост: bucketname.s3.amazonaws.com. Path-style: s3.amazonaws.com/bucketname. Оператор site: ограничивает поиск конкретным доменом, кавычки ищут точное совпадение.

Базовый набор дорков для поиска утечек:

• site:s3.amazonaws.com "название-компании" — ищет бакеты, содержащие имя цели
• site:s3.amazonaws.com filetype:csv OR filetype:xls — табличные файлы (списки пользователей, выгрузки, логи)
• site:s3.amazonaws.com filetype:sql "password" — SQL-дампы с упоминанием паролей
• inurl:s3.amazonaws.com "index of" — бакеты с включённым листингом (заголовок «Index of» — маркер того, что сервер отдаёт список файлов)

По данным Intigriti, помимо прямого Google dorking полезно проверять HTTP-ответы целевого приложения. Если приложение загружает файлы из S3, в заголовках ответов появятся маркеры: x-amz-bucket-region, x-amz-request-id, x-amz-id-2. Обнаружить их можно через перехватывающий прокси или простой curl -I https://target.com.

Аналогичные дорки для GCS и Azure

Принцип работает для любого облачного хранилища с публичным доступом:

• site:storage.googleapis.com "название-компании" — Google Cloud Storage
• site:blob.core.windows.net "название-компании" — Azure Blob Storage

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

Ограничения dorking

Google индексирует далеко не все бакеты. Если бакет создан, но на него нет публичных ссылок — дорк его не обнаружит. Dorking работает как первый фильтр, но не заменяет инструменты перебора имён. Для полной картины нужен следующий шаг — разведка поддоменов.

[Применимо: внешний пентест, bug bounty, black box]

Amass: разведка поддоменов для обнаружения корзин

Amass — инструмент OWASP для subdomain enumeration (перечисления поддоменов). Он собирает поддомены из десятков источников: DNS-записи, Certificate Transparency Logs (публичные журналы выданных TLS-сертификатов), поисковые системы, API Shodan и Censys.

Зачем это для поиска открытых amazon S3 bucket? Компании часто создают бакеты с именами, повторяющими структуру поддоменов: assets.company.com → бакет assets-company-com или company-assets. CNAME-записи (DNS-алиасы) поддоменов нередко указывают напрямую на *.s3.amazonaws.com. Amass находит такие записи автоматически.

Разведка поддоменов через Amass — пассивная. Инструмент не отправляет запросов к целевой инфраструктуре напрямую, а собирает данные из открытых источников. Цель не узнает о сканировании.

Альтернативы и смежные инструменты

Subfinder (от ProjectDiscovery) — более быстрая альтернатива для subdomain enumeration. Работает тише, зато Amass глубже за счёт интеграций с большим числом источников. На практике имеет смысл запустить оба и объединить результаты — пересечение обычно 60-70%, остальное уникальное. Если используете стек ProjectDiscovery, pdtm (Package Discovery Tool Manager) поможет установить и обновлять весь набор одной командой.

Для перебора имён бакетов напрямую (brute force) есть специализированные утилиты:

• cloud_enum — перебирает имена для AWS, Azure и GCP по словарю одновременно
• S3Scanner — проверяет список потенциальных имён бакетов на существование и доступность
• Grayhat Warfare — онлайн-база уже найденных открытых бакетов с поиском по ключевым словам

Эти инструменты дополняют Google dorks для поиска утечек: дорки находят проиндексированное, а brute force — то, что существует, но не попало в Google.

[Применимо: внешний пентест, bug bounty, black/grey box. Не работает в полностью изолированных средах без интернета]

Делай раз, делай два, делай три: полный цикл OSINT-разведки S3

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

• ОС: Kali Linux 2023.1+ или любой Linux/macOS с терминалом (Windows — через WSL2)
• RAM: 4 ГБ минимум; для агрессивного сканирования Amass — 8 ГБ
• Amass v4+: установка через Go 1.20+ (go install github.com/owasp-amass/amass/v4/...@master)
• AWS CLI v2: установка по docs.aws.amazon.com/cli
• Интернет: обязателен, все операции — онлайн
• AWS-аккаунт: бесплатный, для настройки AWS CLI (aws configure). Часть команд работает без аутентификации с флагом --no-sign-request

Делай раз: Google dorking. Открываем Google и вводим дорки по очереди:

site:s3.amazonaws.com "target-company"
site:s3.amazonaws.com filetype:csv OR filetype:xls "target-company"
inurl:s3.amazonaws.com "index of" "target-company"

Что ожидать: Google вернёт список URL вида target-company-backup.s3.amazonaws.com/data.csv или s3.amazonaws.com/target-company-assets/. Пустая выдача — бакеты не проиндексированы, переходим ко второму шагу. Любой URL с s3.amazonaws.com в результатах — потенциальная находка. Фиксируем имена бакетов.

Делай два: Amass для разведки поддоменов. Запускаем пассивный сбор и фильтруем результаты:

amass enum -passive -d target-company.com -o subs.txt
grep -iE "s3|amazonaws|aws|bucket|storage" subs.txt

Что ожидать: файл subs.txt заполнится списком поддоменов — от десятков до тысяч. Grep отфильтрует связанные с AWS. Если в выводе grep есть строки с CNAME на *.s3.amazonaws.com — бакет найден. Для проверки вручную: dig CNAME assets.target-company.com. Если ответ содержит s3.amazonaws.com — подтверждение.

Делай три: проверяем права доступа через AWS CLI. Допустим, имя бакета — target-company-assets. Флаг --no-sign-request означает анонимный запрос — именно так обращается к бакету любой человек из интернета.

Проверка листинга (можно ли увидеть список файлов): aws s3 ls s3://target-company-assets --no-sign-request. Если команда вернёт список файлов с датами и размерами — листинг открыт. Ответ AccessDenied — листинг закрыт, но отдельные файлы могут быть доступны.

Проверка скачивания: aws s3 cp s3://target-company-assets/employees.csv ./ --no-sign-request. Файл скачался — доступ на чтение подтверждён. Это уже фактическая утечка.

Проверка ACL (Access Control List — список управления доступом; определяет, кто и какие действия может выполнять с бакетом):

aws s3api get-bucket-acl \
  --bucket target-company-assets \
  --no-sign-request

Если в JSON-ответе есть "Grantee": {"URI": "http://acs.amazonaws.com/groups/global/AllUsers"} — бакет доступен всем. Поле "Permission" покажет разрешённые действия: READ, WRITE, FULL_CONTROL.

Что делать с результатом. При обнаружении утечки: зафиксировать находку (скриншоты, timestamps, минимальный сэмпл данных — не скачивать весь дамп), проверить наличие security contact у компании (security.txt, HackerOne-профиль), оформить responsible disclosure. Не публиковать данные и не передавать третьим лицам.

Ограничения и юридические границы

Когда поиск открытых S3 корзин не работает

Современные дефолты AWS. С апреля 2023 года AWS включает Block Public Access по умолчанию для новых бакетов. Свежесозданные бакеты уже не будут случайно открыты. Проблема — в старых бакетах, созданных до этой даты, и в ситуациях, когда администратор явно отключает защиту (да, такое бывает — «чтобы приложение заработало»).

CloudFront и CDN. Если файлы раздаются через CloudFront, прямые ссылки на s3.amazonaws.com не появятся в HTTP-ответах. Вместо них — домен d1234567.cloudfront.net. Связать CloudFront с конкретным бакетом без доступа к AWS-консоли — задача нетривиальная.

Кастомные домены. Бакет, привязанный к кастомному домену через Route 53, не обнаруживается Google dorking по s3.amazonaws.com. Здесь помогает Amass — он находит CNAME-записи.

Pre-signed URLs. Если доступ требует подписанных ссылок или IAM-авторизации, анонимные запросы вернут AccessDenied. Это штатная конфигурация.

Детекция при brute force. AWS логирует обращения через CloudTrail и S3 Server Access Logging. По данным LevelBlue, мониторинг логов S3 — стандартная практика, и массовый перебор имён может быть замечен. Отсутствие такого мониторинга — отдельная проблема, которую OWASP классифицирует как A09:2021 Security Logging and Monitoring Failures.

OSINT или статья УК

Google dorking и пассивная разведка через Amass — это сбор данных из открытых источников. Данные доступны публично, системы защиты не обходятся.

Проверка листинга командой aws s3 ls --no-sign-request — спорная территория. Формально это обращение к публичному API без обхода защиты. Но если бакет содержит данные, подпадающие под ФЗ-152 (ст. 7 — конфиденциальность персональных данных), скачивание и хранение этих данных без согласия субъекта нарушает закон.

Практические правила:

1. Не скачивать весь дамп — достаточно убедиться, что бакет открыт и содержит конфиденциальные данные
2. Не записывать в чужие бакеты — aws s3 cp local.txt s3://чужой-бакет/ без разрешения — несанкционированный доступ, даже если бакет позволяет запись
3. Работать в рамках scope — в bug bounty программах scope явно определяет допустимые ресурсы
4. Документировать всё — timestamps, скриншоты, команды

Сравнение инструментов OSINT для разведки S3

Разведка перед пентестом — комбинация инструментов. Один покрывает 30-40% поверхности, связка из трёх-четырёх — 80%+.

Корзина на 12 000 записей сотрудников из моего кейса была обнаружена одним Google-дорком. Не Amass, не cloud_enum, не Shodan. Это говорит не о мощи инструмента, а о слабости процесса: компания ни разу за год не проверила собственные бакеты тем же запросом.

По данным IBM X-Force Threat Intelligence Index 2025, около 6000 свежих учётных данных попадает в dark web ежедневно. Открытая S3-корзина с email-адресами — один из каналов, питающих этот поток. Проблема не в технической сложности защиты (включить Block Public Access — одна кнопка), а в том, что облачные ресурсы выпадают из привычного периметра. Компании сканируют серверы, проверяют эндпойнты, обновляют WAF — и при этом ни разу не заглядывают в Google с дорком site:s3.amazonaws.com "своё-имя". По NIST CSF 2.0, инвентаризация активов (ID.AM-01) — фундамент кибербезопасности, но S3-бакеты в этих инвентаризациях оказываются последними. Пока в чеклисте аудита нет строки «прогнать собственные дорки», misconfigured cloud storage будет регулярно попадать в отчёты пентестеров и bug bounty. Индустрия фокусируется на сетевом периметре, на EDR, на zero-day — а данные утекают через бакет, который забыли закрыть в 2021 году. Если хочется не просто запомнить три дорка, а системно разобраться в разведке и других базовых дисциплинах ИБ — на IB Basics берут с любого старта, без входного порога «вы должны знать Linux на уровне X».