По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году начинались с действительных учётных данных. IBM X-Force добавляет масштаба: в dark web ежедневно всплывает порядка 6000 свежих credential-пар, а рост атак с valid credentials - 71% год к году. Но украденный пароль без адреса - мёртвый груз. Атакующему нужна карта инфраструктуры жертвы: конкретный IP, конкретный сервис, куда подставить логин. Metabigor решает это в одну команду:
metabigor net --org "Target" вытаскивает все IP-блоки организации из публичных реестров. Без API-ключей. Без лимитов на запросы. Для blue team это способ увидеть собственный периметр глазами атакующего и раскопать активы, которых нет ни в одной CMDB. Но сразу оговорка - не все модули Metabigor работают без ключей, и путаница в этом вопросе ломает пайплайны. Разберёмся, где проходит граница.Как атакующий видит вашу инфраструктуру снаружи
Пассивная разведка инфраструктуры - первый этап kill chain по MITRE ATT&CK, тактика Reconnaissance. Атакующий собирает IP-диапазоны, домены, данные о сертификатах и сервисах цели до того, как отправит первый пакет в её сеть. Результат разведки определяет вектор: забытый Jenkins на legacy-подсети - кандидат для эксплуатации дефолтных credentials, staging-домен без WAF - точка входа для веб-атак, IP-блок, не покрытый EDR - зона для закрепления.По Verizon DBIR 2025, 38% утечек связаны с кражей учётных данных. Атакующий не взламывает периметр - он входит через дверь, о которой security-команда забыла. Metabigor OSINT разведка показывает именно такие двери: IP-блоки, зарегистрированные на организацию, но не попавшие в инвентаризацию.
Для blue team запуск OSINT recon по собственной инфраструктуре - не факультатив, а гигиенический минимум. CMDB отстаёт от реальности на месяцы: облачные ресурсы создаются без тикетов, тестовые серверы живут годами после закрытия проекта, приобретённые компании приносят с собой целые подсети, о которых никто не знает. Пассивная разведка инфраструктуры закрывает разрыв между тем, что вы думаете у вас есть, и тем, что видит атакующий.
Честная карта модулей Metabigor: безключевой OSINT и его границы
В README на GitHub Metabigor позиционируется как «OSINT without API key hassle». Звучит красиво, но это маркетинговое упрощение. Инструмент состоит из нескольких модулей, и их зависимость от API принципиально различается.Модуль
net обращается к публичным базам интернет-регистраторов - RIPE NCC, ARIN, APNIC - и парсит данные Whois и BGP без аутентификации. Это действительно безключевой OSINT.Модуль
cert работает через Censys Search API и требует API-ключ Censys. Без ключа модуль не вернёт ничего. Бесплатный тариф Censys ограничен по числу запросов в месяц - актуальные лимиты на censys.io/pricing. Никакого «автоматического распределения нагрузки» Metabigor не делает: вы работаете в рамках квоты вашего аккаунта.Ниже - карта покрытия с привязкой к MITRE ATT&CK. В таблице явно разграничено, что покрывает Metabigor сам, а что требует сопутствующих утилит.
| Компонент | API-ключ | Источник данных | MITRE ATT&CK (Reconnaissance) |
|---|---|---|---|
metabigor net --org | Нет | RIPE, ARIN, APNIC | T1590.005 (IP Addresses) |
metabigor net --asn | Нет | BGP, RIPE Stat | T1590.005 (IP Addresses) |
metabigor net (whois-данные) | Нет | Whois-серверы регистраторов | T1596.002 (WHOIS), частично |
metabigor cert | Да (Censys API) | Censys (индекс CT-логов) | Прямого покрытия ATT&CK нет |
| dig / dnsx (сопутствующие) | Нет | DNS-резолверы | T1596.001 (DNS/Passive DNS) |
| whois (сопутствующий) | Нет | Whois-серверы | T1596.002 (WHOIS) |
| crt.sh (сопутствующий) | Нет | Certificate Transparency | T1590.001 (Domain Properties), частично |
| nmap / masscan (сопутствующие) | Нет | Активное сканирование | T1595.001 (Scanning IP Blocks) |
T1590.005 (IP Addresses) и частично T1596.002 (WHOIS) покрываются непосредственно Metabigor через модуль
net. Техники T1596.001 (DNS/Passive DNS) и T1590.001 (Domain Properties) закрываются сопутствующими утилитами - dig, dnsx, host. Metabigor сам DNS-резолвинг не делает, поддомены не ищет, порты не сканирует. Путать покрытие одного инструмента с покрытием всего пайплайна - типичная ошибка, которая создаёт ложное ощущение полноты разведки.Metabigor: установка и использование
Требования к окружению:- Go 1.17+ (Metabigor написан на Go)
- Linux или macOS (на Windows нужен WSL или ручная установка whois/dig - нативная поддержка Windows официально не подтверждена)
- Сетевой доступ к RIPE, ARIN, APNIC - не заблокирован корпоративным прокси или файрволом
- Для модуля
cert: аккаунт Censys с API-ключом, переменныеCENSYS_API_IDиCENSYS_API_SECRET
Bash:
# Установка через go install (рекомендуемый способ)
go install github.com/j3ssie/metabigor@latest
# Альтернатива - сборка из исходников (сверяйтесь с README, структура проекта может меняться)
git clone https://github.com/j3ssie/metabigor.git
cd metabigor
go build -o metabigor main.go # если main.go не в корне или сборка падает: go build ./...
sudo mv metabigor /usr/local/bin/metabigor --help для списка модулей, metabigor net --help для справки по конкретному модулю. Базовый синтаксис: metabigor <модуль> <флаги>. Вывод - plain text, по одной записи на строку, что удобно для пайплайнов с |, tee, sort -u.Модуль net - безключевая разведка сетевой инфраструктуры
[Применимо: внешний аудит периметра, asset discovery, threat intelligence]Модуль
net - ядро безключевого OSINT в Metabigor. Он парсит данные из публичных баз интернет-регистраторов и возвращает IP-диапазоны (CIDR-блоки), зарегистрированные на указанную организацию или ASN. Сбор данных об инфраструктуре без отправки единого пакета к целевым системам - чистая пассивка.Предусловия:
- Работает если: целевая организация имеет собственные IP-блоки, зарегистрированные в RIPE/ARIN/APNIC (фигурирует как org-name в Whois-записях); сетевой доступ к реестрам не заблокирован.
- Не работает если: организация размещает инфраструктуру полностью в облаке (AWS, Azure, GCP) без собственных IP-блоков и ASN; организация арендует IP у провайдера и не указана в Whois как отдельная org.
Поиск по названию организации
Командаmetabigor net --org "Sberbank" шлёт запросы к RIPE, ARIN и APNIC, ищет записи, где org-name содержит указанную строку, и возвращает список CIDR-блоков:
Код:
194.186.207.0/24
194.54.14.0/24
212.44.152.0/22/24 - 256 адресов, /22 - 1024. Вывод можно сразу передать в nmap -sn -iL ip_ranges.txt для проверки живых хостов или в masscan для быстрого обнаружения открытых портов.Поиск по ASN
Если известен Autonomous System Number организации,metabigor net --asn AS47541 вернёт полный список IP-блоков, анонсируемых этой AS. ASN можно узнать через BGP.he.net или BGPView - оба ресурса бесплатны и не требуют регистрации.Поиск по ASN точнее, чем по org-name: он опирается на BGP-таблицы, а не на текстовое совпадение в Whois. Для организаций с распространёнными названиями (Delta, Global, National) поиск по ASN - единственный адекватный вариант. Иначе результат засорится блоками десятков компаний с похожими именами.
Типичные false positive
IP-блоки из вывода Metabigor нельзя принимать за истину без проверки. Три источника ошибок:- Устаревшие записи. IP-блоки, проданные или переданные другой организации, но ещё не обновлённые в реестре. Whois-данные обновляются с задержкой от дней до месяцев.
- Совпадение по подстроке. Запрос
--org "Delta"вернёт блоки Delta Air Lines, Delta Electronics и десятка других компаний. Решение - использовать точное юридическое название или переходить на поиск по ASN. - Арендованные блоки. Блоки, которые организация временно арендовала и уже вернула провайдеру. Реестр может показывать старую запись.
whois <первый_IP_из_блока> - проверяем поля org-name, descr, country. Если организация в Whois не совпадает с целевой - блок выкидываем.Модуль cert - атрибуция инфраструктуры через Censys API
Повторю для тех, кто пролистал:metabigor cert - не безключевой OSINT. Модуль обращается к Censys Search API, а не напрямую парсит публичные CT-логи. Без установленных переменных окружения для Censys API (исторически CENSYS_API_ID и CENSYS_API_SECRET, но имена могли измениться после миграции Censys на API v2) модуль не вернёт ничего.Бесплатный тариф Censys ограничен по числу запросов в месяц (конкретные лимиты меняются - проверяйте на censys.io/pricing). Metabigor не обходит эти лимиты и не распределяет нагрузку - каждый вызов
metabigor cert тратит запрос из вашей квоты.Механика работы
Модуль запрашивает Censys по доменному имени и возвращает IP-адреса серверов, на которых обнаружены TLS-сертификаты с этим доменом в полях Subject Alternative Name (SAN) или Common Name (CN). Это позволяет найти серверы за CDN или балансировщиком нагрузки: если сертификат выдан на конкретный домен и установлен на сервере, Censys его проиндексирует.Использование:
metabigor cert -q target.com (точный синтаксис флагов проверяйте через metabigor cert --help - он менялся между версиями, а интеграция с Censys может быть неработоспособна после миграции Censys API v1→v2, изменившей схему аутентификации и эндпоинты). Результат - список IP-адресов, по одному на строку.Предусловия:
- Работает если: есть валидный Censys API-ключ; целевой домен использует публично выпущенные TLS-сертификаты; серверы с этими сертификатами доступны для сканирования Censys.
- Не работает если: API-ключ отсутствует или превышена квота; домен использует self-signed сертификаты, не попавшие в CT-логи; серверы за строгим файрволом, блокирующим сканирование Censys.
Безключевая альтернатива для CT-разведки
Если ключ Censys не нужен или недоступен - для поиска по Certificate Transparency логам есть crt.sh. Публичный интерфейс, регистрация не нужна. Запросcurl -s "https://crt.sh/?q=%25.target.com&output=json" | jq -r '.[].name_value' | sort -u вернёт все домены, упомянутые в сертификатах для target.com. Это не полный эквивалент metabigor cert - crt.sh не показывает IP-адреса серверов, только доменные имена из сертификатов - но задачу обнаружения поддоменов без API-ключа закрывает.Безключевой пайплайн OSINT: от организации до карты активов
Metabigor OSINT разведка раскрывается в пайплайне - цепочке утилит, где выход одного инструмента становится входом для следующего. Ниже - рабочий пайплайн для blue team на безключевых источниках.[Применимо: внешний аудит периметра, continuous asset discovery, SOC monitoring]
Требования к окружению:
- Metabigor (модуль
net) - dnsx (DNS-резолвер от ProjectDiscovery, github.com/projectdiscovery/dnsx) или стандартный
dig - curl + jq (для работы с crt.sh API)
- Bash-совместимая оболочка
Bash:
# Шаг 1: IP-блоки организации из реестров (без API)
metabigor net --org "Example Corp" | tee ip_ranges.txt
# Шаг 2: поддомены из CT-логов (без API, через crt.sh)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
| jq -r '.[].name_value' | sort -u | tee ct_domains.txt
# Шаг 3: DNS-резолвинг найденных доменов (без API)
cat ct_domains.txt | dnsx -silent -a -resp | tee resolved.txt
# Шаг 4: кросс-проверка - какие IP попадают в наши блоки
# NB: grep -F не понимает CIDR-нотацию, используем mapcidr для корректного матчинга
cat resolved.txt | awk '{print $NF}' > resolved_ips.txt
mapcidr -l resolved_ips.txt -fl ip_ranges.txt -o matched.txt
# NB: флаги mapcidr менялись между версиями - проверьте `mapcidr -h` для актуального синтаксисаip_ranges.txt- CIDR-блоки, зарегистрированные на организациюct_domains.txt- все домены из Certificate Transparency логовresolved.txt- домены с их текущими A-записямиmatched.txt- домены, хостящиеся на инфраструктуре организации
resolved.txt с ip_ranges.txt через CIDR-aware инструмент (например, mapcidr от ProjectDiscovery) показывает, какие из найденных доменов реально сидят на IP-блоках организации, а какие ведут на CDN или облачный хостинг. Домен на CDN - одна модель защиты, домен на собственном IP без CDN - другая; для blue team это разный уровень контроля.Пайплайн покрывает четыре техники MITRE ATT&CK из тактики Reconnaissance:
- T1590.005 (IP Addresses) - шаг 1,
metabigor net - T1596.002 (WHOIS) - частично через
metabigor net(парсинг Whois-данных реестров), полноценно - через отдельную утилитуwhoisна этапе верификации - T1596.001 (DNS/Passive DNS) - шаг 3,
dnsx - T1590.001 (Domain Properties) - шаги 2-3, crt.sh + dnsx
diff между текущим и предыдущим запуском - ваш alert: новый CIDR или домен в diff означает, что кто-то поднял сервер или зарегистрировал домен без ведома security-команды.Если хочется отработать такой пайплайн руками - на HackerLab.pro в категории OSINT можно собрать его самостоятельно. Платформа Codeby с 12 категориями заданий, нужна регистрация.
Разведка сетевой инфраструктуры: кросс-проверка и верификация
Metabigor - не оракул. Результаты модуляnet содержат false positive, и передавать их напрямую в активный сканер без верификации - путь к сканированию чужой инфраструктуры. Для blue team это юридический риск; для пентестера - выход за рамки scope.Три правила верификации
Whois-подтверждение. Каждый CIDR из вывода Metabigor проверяется черезwhois <первый_IP_из_блока>. Сверяйте поля org-name, descr, country, netname. Организация в Whois не совпадает с целевой - блок выкидываем.BGP-валидация. Проверьте ASN через BGP.he.net: принадлежит ли он целевой организации, какие prefix-блоки анонсируются. CIDR, не анонсируемый ни одним ASN организации - либо устаревшая запись, либо блок уже у другого оператора.
Reverse DNS. Для IP из подтверждённых блоков запустите
dig -x <IP> или батчевый dnsx -ptr -l verified_ips.txt. PTR-записи часто содержат hostname вида staging-01.internal.example.com - это подтверждает принадлежность хоста и подсказывает его назначение. Отсутствие PTR-записи тоже информативно: может быть неуправляемый хост, о котором все забыли.Типичные ошибки при разведке без API ключей
Большинство SOC-команд, с которыми я работал за последние два года, знают свою инфраструктуру хуже, чем средний атакующий с Metabigor и десятью минутами свободного времени. CMDB ведётся вручную, обновляется при заведении тикета, а тикет заводится «потом». Shadow IT - не исключение, а норма: тестовые серверы разработчиков, dev-окружения на забытых подсетях, домены от закрытых проектов, IP-блоки приобретённых компаний. Бессмысленно тратить бюджет на EDR и SIEM, если вы не знаете полный список активов, которые эти инструменты должны защищать.
Continuous asset discovery - не маркетинговый buzz, а тот самый гигиенический минимум. Мой прогноз: через год-два пайплайны вроде описанного выше станут стандартной частью SOC-процесса наравне с мониторингом CT-логов и Shodan-алертами. Команды, которые до сих пор считают пассивную разведку «делом пентестеров», будут проигрывать уже на этапе инвентаризации - атакующий не ждёт, пока вы обновите CMDB. Попробуйте прогнать пайплайн из этой статьи по собственной организации. Если в
diff появится хоть один CIDR, о котором вы не знали - значит, атакующий знал о нём раньше вас. Если интересно, как другие SOC-команды строят continuous recon, - на codeby.net есть тред по asset discovery, где разбираем конкретные пайплайны.
