На внешнем пентесте для финтех-компании нашли Jenkins без аутентификации на поддомене
ci-old.client.tld. Сервера не было ни в одном реестре активов заказчика. Через pipeline script console за два часа получили reverse shell во внутреннюю сеть. CI-сервер развернули три года назад для тестового пайплайна и забыли выключить. Это не уникальная история - в каждом втором внешнем пентесте первая точка initial access оказывается на хосте, о существовании которого заказчик не подозревает. Shadow IT, забытые dev-среды и legacy-инфраструктура - слепое пятно, которое не закроет ни сканер уязвимостей, ни SIEM. Ниже - конкретные техники и инструменты, которые применяю для обнаружения shadow IT при пентесте, и разбор того, чем разовая проверка отличается от полноценной ASM-программы.Почему неучтённые активы - первая цель атакующего
Атакующий мыслит категорией внешней поверхности атаки, а не списком серверов из CMDB. Каждый хост на периметре - потенциальная точка initial access. Забытый staging-сервер с дефолтными учётными данными (Default Accounts, T1078.001, Initial Access) или необновлённый VPN-концентратор (External Remote Services, T1133, Initial Access / Persistence) - двери, которых нет на плане здания.Kill chain через shadow IT выглядит так:
- Разведка - обнаружение поддомена через Certificate Transparency или DNS-перебор (Active Scanning, T1595; Search Open Technical Databases, T1596)
- Fingerprinting - определение технологии и версии на обнаруженном хосте (Network Service Discovery, T1046)
- Эксплуатация - сервис не обновлялся или имеет дефолтную конфигурацию (Exploit Public-Facing Application, T1190)
- Foothold - получение shell, дальнейший lateral movement и пост-эксплуатация
Пассивная разведка: обнаружение shadow IT без единого пакета к цели
Пассивная разведка инфраструктуры - первый этап, который не генерирует трафик к целевой инфраструктуре. Для OPSEC при red team-операциях это критично, да и для ASM-программ, работающих непрерывно в фоне, тоже. Все техники ниже соответствуют тактике Reconnaissance по MITRE ATT&CK.
Certificate Transparency и DNS-история
Certificate Transparency (CT) логи - публичные репозитории всех SSL/TLS-сертификатов, выданных удостоверяющими центрами. Каждый сертификат для*.client.tld попадает в CT-лог и остаётся там навсегда. Даже если поддомен staging.client.tld уже не резолвится - факт выпуска сертификата сохранён, и для атакующего это лакомый кусок.Рабочие инструменты: crt.sh (бесплатный веб-интерфейс и API), Certspotter от SSLMate, модуль CT в Amass. На практике запрос
%.client.tld к crt.sh часто выдаёт десятки поддоменов, о которых заказчик не помнит: dev-api.client.tld, old-admin.client.tld, test-2021.client.tld. Прямое использование Search Open Technical Databases (T1596, Reconnaissance).Passive DNS-базы (SecurityTrails, VirusTotal, RiskIQ / Microsoft Defender TI) хранят историю DNS-резолвинга. Через них находятся поддомены, которые когда-то указывали на IP-адреса компании. Если IP до сих пор принадлежит заказчику, а DNS-запись удалена - сервис, вероятно, работает, просто стал "невидимкой" для инвентаризации IT-активов.
Когда техника НЕ работает: CT-логи показывают только домены, для которых выпускались сертификаты через публичные CA. Self-signed сертификаты и сервисы без TLS в CT не попадут. Passive DNS базы могут отставать от реальности на часы или дни.
Shodan, Censys и FOFA: разведка по баннерам без активного сканирования
Поисковые движки по баннерам - второй слой пассивной разведки инфраструктуры OSINT. Shodan, Censys и FOFA непрерывно сканируют весь IPv4 и индексируют ответы сервисов: HTTP-заголовки, SSH-баннеры, SSL-сертификаты, SNMP community strings.[Применимо: внешний пентест, black box / grey box]
Для обнаружения неучтённых активов в инфраструктуре использую несколько подходов:
Поиск по SSL-сертификату организации. В Shodan -
ssl.cert.subject.CN:"client.tld" или ssl:"Organization Name". Находит все IP, где установлен сертификат с именем компании, включая хосты на нестандартных портах и в чужих облаках. Gather Victim Network Information (T1590) в чистом виде.Поиск по favicon-хешу. Если у компании уникальная иконка,
http.favicon.hash в Shodan покажет все серверы с тем же favicon - включая забытые инстансы приложения на dev-окружениях. Удивительно, как часто этот трюк срабатывает.Поиск по ASN. Запрос
asn:ASXXXXX покажет все проиндексированные сервисы в сетевом блоке организации. Часто выявляются порты, которые заказчик считает закрытыми файрволлом. Считает - но нет.Когда техника НЕ работает: данные Shodan и Censys обновляются не в реальном времени - задержка от часов до нескольких недель в зависимости от IP-блока. Сервисы за CDN (Cloudflare, Akamai) не показывают реальный IP. FOFA даёт лучшее покрытие по азиатскому региону, но слабее по российским сетям.
Активное обнаружение неизвестных поддоменов и сервисов
Пассивная разведка даёт базу, но не полную картину. Активные методы - DNS-перебор и HTTP-probing - дополняют её. Тут начинается Active Scanning (T1595, Reconnaissance) с уже ощутимым "шумом" в сторону цели.
Требования к окружению:
- ОС: GNU/Linux (Kali, Ubuntu 22.04+), macOS. Windows - через WSL2
- RAM: минимум 4 ГБ, рекомендуется 8 ГБ (amass на большом скоупе жрёт память)
- Зависимости: Go 1.21+ (для сборки через
go install) или готовые бинарники - Сеть: прямой доступ к DNS-резолверам (не корпоративный прокси, не split-DNS)
- API-ключи: subfinder и amass работают без ключей, но для полного покрытия нужны бесплатные токены SecurityTrails, Shodan, Censys, VirusTotal
Bash:
subfinder -d client.tld -all -silent | \
anew subdomains.txt && \
amass enum -passive -d client.tld >> subdomains.txt && \
sort -u subdomains.txt | \
httpx -silent -status-code -title -tech-detect -o alive.txtsubfinder (ProjectDiscovery, активно поддерживается) собирает поддомены из пассивных источников - CT-логи, DNS-базы, API поисковиков. amass (OWASP, активно развивается) дополняет из собственного набора источников. Результат дедуплицируется, затем httpx (ProjectDiscovery) проверяет каждый хост на живой HTTP/HTTPS-ответ и определяет title страницы, статус-код, стек технологий. Для управления всем стеком ProjectDiscovery удобен pdtm - обновляет subfinder, httpx и nuclei одной командой.Характерный вывод при обнаружении shadow-активов:
Код:
https://staging-api.client.tld [200] [Swagger UI] [Nginx,Express]
https://old-grafana.client.tld [302] [Grafana] [Go]
https://ci.client.tld:8080 [200] [Dashboard [Jenkins]] [Java]admin:admin, Jenkins без аутентификации - не теория, а типичные находки при сканировании dev-поддоменов. После обнаружения живых хостов прогоняю nuclei (ProjectDiscovery) с шаблонами из категорий exposed-panels, default-logins, misconfigurations - валидация уязвимостей на найденных shadow-активах занимает 10-15 минут.Когда техника НЕ работает: DNS-перебор бесполезен, если организация использует wildcard DNS (все поддомены резолвятся на один IP). httpx не поможет для сервисов по не-HTTP протоколам (RDP, SSH, VNC на нестандартных портах - тут нужен
nmap или masscan). При внутреннем пентесте вся эта цепочка менее релевантна - работаете с IP-диапазонами, а не доменами.Облачный shadow IT: несанкционированные облачные сервисы и забытые бакеты
Облачная инфраструктура - основной источник теневых IT-ресурсов. Разработчик поднимает S3-бакет для тестирования, выставляет public read и забывает. DevOps создаёт EC2-инстанс для отладки, открывает security group0.0.0.0/0:22 и не удаляет его. Классика.[Применимо: внешний пентест, black box; для authenticated cloud audit - grey box / white box]
AWS S3 бакеты с предсказуемыми именами. Проверка формата
clientname-dev, clientname-backup, clientname-staging через aws s3 ls s3://clientname-dev --no-sign-request. Открытый для анонимного чтения бакет - прямая утечка данных. По данным AWS security best practices, shared key authentication без переключения на Entra ID / IAM-роли остаётся распространённой проблемой.Azure Blob Storage. По данным Wiz, Microsoft в октябре 2025 года фиксировал рост атак на Azure Blob Storage через некорректно настроенные контейнеры и слабые access controls. Google для GCS рекомендует enforcing uniform bucket-level access и Public Access Prevention на уровне организации.
VM-инстансы с публичными IP. Через Shodan ищу по ASN облачного провайдера и HTTP-заголовкам, характерным для сервисов заказчика. Часто нахожу dev-серверы с SSH на 22 порту, Jupyter Notebook на 8888 или docker registry на 5000 без авторизации. Последний случай - вообще подарок: pull любого образа, включая те, где в ENV-переменных лежат пароли от production-базы.
Когда техника НЕ работает: перебор имён бакетов - brute force, облачные провайдеры рейт-лимитят запросы. AWS GovCloud и private endpoint-бакеты так не обнаруживаются. Для полноценного облачного ASM нужен аутентифицированный доступ к API провайдера - это задача CSPM/CAASM-решений, а не внешнего пентестера.
Dev-среды и legacy на периметре: от staging до foothold
Dev-среды и legacy-системы различаются по причинам появления, но одинаково опасны как забытые сервисы, безопасность которых никто не контролирует.Dev-среды и их уязвимости
Dev-среда попадает на внешний периметр, когда разработчику нужен доступ из дома, CI/CD-пайплайн требует внешний webhook или QA-команда тестирует мобильное приложение с реальным API. Проблема не в существовании среды, а в том, что на ней работают с копиями production-данных, аутентификация ослаблена "для удобства", обновления не применяются, и среда не входит в скоуп SOC.Характерные маркеры обнаружения: поддомены с префиксами
dev-, staging-, test-, qa-, uat-, sandbox-. В HTTP-ответах - Swagger UI, phpinfo(), debug-панели (Django Debug Toolbar, Laravel Telescope), заголовки X-Debug-Token. Увидел X-Debug-Token в ответе - считай, тебе выдали карту внутренностей приложения.Legacy-инфраструктура при пентесте
Legacy - хосты, которые были production до миграции, но остались включёнными. Типичные примеры из практики:- VPN-концентраторы со старой прошивкой (Fortinet, Pulse Secure) на нестандартных портах - External Remote Services (T1133). Fortinet CVE-2024-21762 до сих пор встречается в дикой природе.
- Внутренние wiki (Confluence, MediaWiki), проиндексированные поисковиками - обнаруживаются через Google dork
site:*.client.tld inurl:wiki(Search Open Websites/Domains, T1593) - Старые CMS (WordPress 4.x, Joomla 3.x) с известными RCE - Exploit Public-Facing Application (T1190)
- Почтовые серверы (Exchange 2013, Zimbra) после миграции на O365 - остаются на старом IP и тихо ждут ProxyShell
masscan или данные Shodan по ASN. Но если IP-блок передан другому владельцу - сканирование выходит за рамки скоупа.Инструменты обнаружения shadow IT: trade-off таблица
| Инструмент | Место в kill chain | Преимущества | Ограничения | Когда применять |
|---|---|---|---|---|
| subfinder | Recon (пассивный) | Быстрый, работает из коробки | Только пассивные источники, пропускает нестандартные имена | Первый проход при внешнем пентесте |
| Amass | Recon (пассив + актив) | Глубокий анализ, граф связей между доменами | Медленный на больших скоупах, полная мощность - с API-ключами | Полная инвентаризация при ASM-программе |
| httpx | Fingerprinting | Быстрый probing, определение технологий | Не обнаруживает новые домены, только проверяет существующие | После discovery - фильтрация живых хостов |
| Shodan / Censys | Recon (пассивный) | Без трафика к цели, исторические данные | Данные отстают на дни-недели, CDN скрывает IP | Обнаружение по сертификатам и баннерам |
| nuclei | Валидация (pre-exploitation) | Огромная база шаблонов, автоматизация | Не средство обнаружения, работает по готовому списку | Проверка найденных shadow-активов на уязвимости |
| cloud_enum | Recon (облачный brute force) | Покрывает AWS / Azure / GCP | Brute force, рейт-лимиты провайдеров | Поиск забытых S3-бакетов и Blob-контейнеров |
Рабочая последовательность: subfinder + amass для сбора поддоменов, httpx для фильтрации живых, nuclei с шаблонами
exposed-panels и default-logins для валидации. На одну корневую зону уходит 30-60 минут.Управление поверхностью атаки ASM vs разовый пентест
Бизнес-контекст. ASM-платформа не знает, что
hr-portal.client.tld содержит персональные данные сотрудников. Пентестер задаёт этот контекст вручную.По данным Sprocket Security, "rogue assets often communicate over non-standard ports or protocols and can be flagged through anomaly detection in network traffic""Несанкционнированые ресурсы часто коммуницируют на нестандартных портах или протоколах и могут быть обнаружены через детектирование аномального трафика в сети" - network flow analysis дополняет DNS-based обнаружение shadow IT, но требует доступа к netflow-данным, что возможно только при внутреннем пентесте или ASM с агентом.
Ограничения обоих подходов: ни один инструмент не гарантирует 100% покрытия. Если разработчик использовал личный домен для staging-сервера - CT-логи и DNS-перебор по
client.tld его не обнаружат. Тут помогают только OSINT по сотрудникам и threat intelligence.Три года назад я считал, что хороший пентестер заменяет ASM-платформу. Сейчас думаю иначе. ASM - непрерывный дозор, фиксирующий появление каждого нового поддомена или открытого порта через пять минут после создания. Пентестер - тот, кто приходит и показывает, что найденный Jenkins не просто "информационная" находка, а полноценный вектор до domain admin. Одно без другого работает вполсилы.
Проблема российского рынка в том, что инвентаризация IT-активов - то, что NIST CSF v2.0 фиксирует как ID.AM-01 - почти нигде не работает в реальном времени. Раз в год заказывают пентест, получают отчёт с десятком забытых поддоменов, исправляют найденное - и через месяц DevOps поднимает новый staging с тем же дефолтным паролем. Внешняя поверхность атаки организации - это то, что думает SOC, плюс то, что не думает никто. И второе всегда оказывается больше. Если хочешь прогнать recon-цепочку от обнаружения поддомена до shell на живом стенде - задачи по web-разведке на HackerLab.pro (https://hackerlab.pro) дают именно этот опыт.
Последнее редактирование модератором:
