BBOT OSINT автоматизация разведки до облака

На последнем внешнем пентесте я потратил полтора часа на склейку цепочки Subfinder → httpx → naabu → nuclei bash-скриптами. Четыре утилиты, четыре формата вывода, отладка pipe-конвейеров между ними - и всё равно потерял часть данных на стыках. BBOT закрыл ту же задачу одной командой. И вытащил облачные бакеты, которые ручной конвейер пропустил: модули cloud-enum автоматически получают найденные поддомены и генерируют из них имена-кандидаты для проверки. Ниже - разбор конвейера BBOT от домена до облачных активов с корректным маппингом на MITRE ATT&CK и рабочими командами.

Почему BBOT, а не связка Subfinder + httpx + naabu​

Amass, Subfinder, httpx, naabu, nuclei - каждый решает одну задачу. Для полного рекона нужно минимум пять утилит с промежуточными файлами между ними. Каждый инструмент - свой формат вывода, своя дедупликация, свои грабли: Shodan выдаёт rate limit на бесплатном плане, Censys требует другой API-ключ, а скрипт для бакетов на Go собирается отдельным бинарником. Весь этот зоопарк надо кормить и выгуливать. Подробнее - в нашем материале про asset management пентест.

BBOT - рекурсивный оркестратор с event-driven архитектурой, объединяющий 80+ модулей. Каждый модуль генерирует события (DNS_NAME, IP_ADDRESS, OPEN_TCP_PORT, STORAGE_BUCKET), которые автоматически попадают в подписанные модули. Нашёл поддомен через crt.sh - событие DNS_NAME летит в massdns для резолва, оттуда IP_ADDRESS уходит в naabu для сканирования портов, а DNS_NAME параллельно уходит в bucket_aws для проверки бакетов. Без промежуточных файлов и bash-клея.

В цепочке атаки BBOT покрывает этап Reconnaissance по MITRE ATT&CK - всё до Initial Access. Поддомены, IP-адреса, порты, облачные активы, email-адреса сотрудников. Каждый найденный актив - потенциальная точка входа.

Перед началом работы проверяйте версию: bbot --version. Набор модулей и поведение флагов меняются между релизами - всё описанное ниже проверяйте на своей установке.

Установка BBOT и первый запуск​

BBOT официально поддерживается на Linux и macOS с Python 3.9+. На Windows - через Docker или WSL.

Через pip (лучше pipx или virtualenv): pip install bbot для стабильной версии, pip install --pre bbot для dev-ветки с последними модулями.

Docker: docker run -it blacklanternsecurity/bbot:stable --help. Для persistence данных между запусками монтируйте volume: docker run -v $(pwd)/data:/root/.bbot -it blacklanternsecurity/bbot:stable --help.

После установки: bbot -l - список доступных модулей с флагами. bbot --help-all - полный help с конфигурационными опциями. Флаги subdomain-enum, cloud-enum, email-enum, portscan, web-basic, web-thorough - основные точки входа для построения конвейера.

Маппинг флагов BBOT на техники MITRE ATT&CK​

Частая ошибка при документировании инструментов автоматизации OSINT recon - путаница между пассивными и активными техниками. Пассивный сбор IP-адресов из WHOIS и активное сканирование портов - разные техники, разные тактики, разная юридическая рамка. Ниже - корректный маппинг основных флагов и модулей BBOT.


Три принципиальных замечания к маппингу:

naabu - строго T1595.001. Модуль naabu шлёт SYN-пакеты на целевые хосты - это активное сканирование. Техника T1590.005 (IP Addresses) описывает пассивный сбор IP из OSINT-источников и к naabu не относится. T1590.005 корректна для модулей ipneighbor, passivetotal, viewdns - они получают IP из WHOIS и passive DNS без отправки трафика на цели.

cloud-enum - T1596, не T1526. Техника T1526 (Cloud Service Discovery) - это тактика Discovery, постэксплуатация. Она применима, когда у атакующего уже есть доступ к облачному аккаунту. Модули bucket_aws, bucket_gcp перебирают имена бакетов снаружи, без аутентификации - это Reconnaissance через поиск в открытых технических базах (T1596). Путать эти две техники - как путать разведку с улицы и осмотр квартиры после того, как дверь уже открыли.

email-enum - T1589.002, не T1593.003. Флаг email-enum запускает модули сбора email через публичные источники - это T1589.002 (Email Addresses). Техника T1593.003 (Code Repositories) - про сканирование git-репозиториев на предмет секретов. Если используете модуль github в BBOT, он ближе к T1593.003, но к флагу email-enum эта техника не клеится.

Конвейер разведки от поддоменов до облачных бакетов​

Пассивная DNS enumeration автоматизация​

Минимальная команда для пассивного перечисления поддоменов: bbot -t example.com -f subdomain-enum -rf passive. Флаг -rf passive ограничивает выполнение модулями с тегом passive - никаких DNS-брутфорсов и зонных трансферов, только запросы к публичным базам.

Для работы с платными API ключи прописываются через -c: bbot -t example.com -f subdomain-enum -c modules.shodan_dns.api_key=YOUR_KEY modules.securitytrails.api_key=YOUR_KEY. При регулярном использовании удобнее YAML-конфиг ~/.config/bbot/bbot.yml - ключи задаются один раз.

Грабля, на которую наступают все: rate-limiting API. Shodan на бесплатном плане даёт 1 запрос в секунду, SecurityTrails - жёсткие лимиты на бесплатном плане (актуальные значения проверяйте в кабинете). BBOT лимиты не обходит - если API возвращает 429, модуль просто не вернёт данных. Проверяйте лимиты ваших API-ключей до запуска скана, иначе получите красивый отчёт с дырами.

Активное сканирование портов​

Для добавления portscan: bbot -t example.com -f subdomain-enum -m naabu. Модуль naabu (T1595.001, Scanning IP Blocks) принимает IP-адреса из событий subdomain-enum и сканирует порты - по умолчанию top-100.

Критично: naabu - активный модуль. Он генерирует сетевой трафик к целевым хостам. Убедитесь, что scope пентеста явно разрешает активное сканирование. Для чисто пассивной разведки используйте -rf passive - naabu будет автоматически исключён.

Cloud asset discovery и CWE-200​

Флаг cloud-enum запускает модули bucket_aws, bucket_gcp, bucket_azure, bucket_digitalocean, bucket_firebase. Каждый модуль получает события DNS_NAME от subdomain-enum и генерирует имена-кандидаты: для поддомена dev.example.com проверяются бакеты вроде dev-example, dev.example, example-dev.

Команда: bbot -t example.com -f subdomain-enum cloud-enum. Комбинация пассивного перечисления поддоменов и внешней проверки бакетов - без аутентификации в облаке, чисто Reconnaissance (T1596).

На практике cloud-enum регулярно находит забытые S3-бакеты с публичным доступом - классика CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). DevOps создал бакет для стейджинга, забыл ограничить доступ - BBOT обнаруживает его по имени, сгенерированному из поддомена. На одном проекте именно так нашли бакет с бэкапами БД, до которого ручной конвейер просто не добрался. Такие находки - одни из самых ценных на внешнем пентесте.

Scope-контроль: whitelist, blacklist, strict-scope​

По умолчанию BBOT считает в scope всё, что относится к указанному домену и его поддоменам. На реальном пентесте scope сложнее: клиент даёт два домена, но разрешает сканировать только определённую подсеть.
Whitelist переопределяет автоматический scope - модули обработают только находки внутри whitelist. Blacklist исключает конкретные хосты и подсети. Флаг --strict-scope отключает автоматическое включение поддоменов - полезно, когда клиент разрешил тестировать один конкретный хост.

Целями могут быть DNS_NAME (example.com), IP_ADDRESS (1.2.3.4), IP_RANGE (1.2.3.0/24), URL (https://www.example.com) и EMAIL_ADDRESS (user@example.com). Комбинируйте: bbot -t example.com 10.0.0.0/24 urls.txt - входные данные из аргументов и файлов одновременно.

Вывод результатов: JSON, Neo4j, asset inventory​

BBOT сохраняет результаты в TXT, JSON и CSV в ~/.bbot/scans/<scan_name>/. Имя скана генерируется автоматически или задаётся через -n my_scan. Последние 20 сканов хранятся на диске, старые удаляются.

Для pipe-конвейера с jq: bbot -t example.com -f subdomain-enum --output-module json | jq. Для генерации asset inventory: bbot -t example.com -f subdomain-enum -o . --output-modules asset_inventory. Здесь -o задаёт директорию для результатов, а --output-modules (-om) - формат вывода (json, csv, asset_inventory, neo4j и т.д.); это независимые флаги. Имя флага менялось между релизами - проверяйте через bbot --help-all.

Для визуализации графа attack surface - Neo4j:
Граф доступен на http://localhost:7474. Каждое событие - узел, связи - рёбра. На крупном скопе это удобнее таблиц: видно кластеры связанных активов, общие IP для нескольких поддоменов, бакеты, привязанные к конкретным сервисам.

BBOT также даёт Python API для интеграции в CI/CD-пайплайны continuous recon: async for event in Scanner("example.com", modules=["httpx", "sslcert"]).async_start(): print(event) - запускает скан программно и итерирует по событиям (нужен async event loop).

При повторных сканах BBOT использует сохранённый word cloud - словарь частых слов, собранных в предыдущих прогонах. DNS-брутфорс от этого становится точнее: словарь адаптируется под конкретную цель.

Безопасность самого BBOT: три advisory​

BBOT - инструмент для разведки чужих систем, но его собственная поверхность атаки тоже заслуживает внимания. Ирония: инструмент для поиска чужих CWE-200 сам засветился с CWE-200. Три зафиксированных advisory:

GHSA-63wh-p5fx-h4vc - модуль git_clone.py может слить ваши GitHub API-ключи на сервер, контролируемый атакующим. Если вы сканируете враждебную инфраструктуру с включённым модулем github и прописанным API-ключом - ключ может утечь. Это CWE-200 (Exposure of Sensitive Information). Рекомендация: создавайте отдельный API-токен с минимальными правами специально для BBOT, не суйте туда основной токен разработчика.

GHSA-3mp7-vp6j-2mxx - SSRF в модуле docker_pull через парсинг WWW-Authenticate realm. Попадает под OWASP A10:2021 (Server-Side Request Forgery). При обращении к враждебному Docker-реестру атакующий может заставить BBOT выполнить запрос к произвольному внутреннему URL.

GHSA-3vgw-585j-4m45 - Path Traversal (Zip-Slip) в модуле unarchive. Позволяет записать файлы за пределы целевой директории при распаковке вредоносного архива.

Практический вывод: запускайте BBOT в изолированном окружении - Docker-контейнер или отдельная VM. Не прописывайте в конфиг production-токены с широкими правами. Обновляйте регулярно: pip install --upgrade bbot. Перед обновлением проверяйте changelog - advisory выше фиксировались в разных версиях, не все имеют присвоенные CVE-номера.

Полная команда разведки от домена до облака​

Рекон - единственный этап пентеста, который нормально автоматизируется. Exploitation требует понимания контекста, post-exploitation - нестандартного мышления. Но я регулярно вижу обратную картину: рекон собирают руками, а exploitation пытаются автоматизировать nuclei-шаблонами. Это инверсия приоритетов. Автоматизируем то, что требует мозга, и вручную делаем то, что идеально ложится на конвейер.

BBOT - не панацея. Свои проблемы есть: false positive на крупных скопах, rate-limiting API, три собственных advisory в модулях. Но event-driven архитектура решает главную боль ручного рекона - потерю данных на стыках между инструментами. Когда каждое событие автоматически попадает во все релевантные модули, пропустить бакет или забыть просканировать порты для половины поддоменов - физически сложнее.

Чего BBOT не заменит - определение scope и анализ «слепых зон». Инструмент ищет то, что умеют его модули. Кастомные облачные сервисы, не покрытые bucket-модулями, приватные DNS-резолверы, нестандартные схемы именования - всё это за рамками автоматизации. После каждого прогона BBOT стоит потратить 30-40 минут на ручную проверку: поддомены из archived-версий сайта, бакеты с именами, не привязанными к домену, облачные ресурсы, доступные только через API вендора. Кто этого не делает - получает красивый граф в Neo4j с дырой посередине. Попробуйте прогнать BBOT на своём домене и сравнить результат с тем, что знаете о своей инфраструктуре. Разница может удивить.