На внешнем пентесте финтех-компании первая критическая находка заняла 11 минут. Не Nmap, не Burp - запрос
site:target.com filetype:env "DB_PASSWORD" вернул файл с credentials от продакшн-базы. Хост dev-payments.target.com не фигурировал в скоупе, потому что заказчик о нём забыл. По данным IBM X-Force Threat Intelligence Index 2025, каждый день в даркнете всплывает порядка 6000 свежих учёток - и значительная часть из них не результат сложных атак, а банальная индексация конфигов поисковиками. Google Dorking - первый инструмент в руках пентестера и одновременно самый недооценённый: google dorks для разведки позволяют собрать карту внешней поверхности атаки до того, как один пакет коснётся инфраструктуры цели.Место Google Dorking в kill chain: MITRE ATT&CK и операционный контекст
[Применимо: внешний пентест, black box / grey box] Подробнее - в нашем руководстве по asset management пентест.
В терминологии MITRE ATT&CK Google Dorking - техника T1593.002 (Search Engines, Reconnaissance). Каждый запрос уходит на серверы Google, а не на целевой хост: в access-логах жертвы ноль записей. Это и делает дорки безопасным стартом для пассивной разведки внешней поверхности атаки перед переходом к активному сканированию.
В цепочке внешнего пентеста google dorking занимает конкретную позицию:
- Google Dorks + OSINT (passive recon) - определение границ атакуемой поверхности, обнаружение забытых активов
- Shodan / Censys / crt.sh - подтверждение live-хостов, открытых портов, Certificate Transparency
- Active scanning (Nmap, httpx) - fingerprinting сервисов на подтверждённых хостах
- Vulnerability validation (nuclei, manual testing) - pre-exploitation
- Exploitation - initial access
phpinfo() и version strings; Scan Databases (T1596.005) - когда ищем готовые дорки в Google Hacking Database. Отдельная категория - находки credential exposure, которые маппятся на тактику Credential Access (T1552.001, Credentials In Files).Когда пишешь отчёт, каждая находка привязывается к ATT&CK-технике. Дорки - не "погуглил и нашёл", а задокументированный reconnaissance с конкретным TTP-маппингом.
Пять семейств операторов для external attack surface mapping
Русскоязычные гайды перечисляют GHDB-операторы поиска списком:
site:, filetype:, inurl:. Это справочник, а не методология. На практике google dorks OSINT-аналитики группируют операторы по задачам - каждое семейство отвечает на конкретный вопрос при external attack surface mapping.Scoping - определение границ разведки
Первый шаг - понять, что вообще проиндексировано у цели. Запросsite:target.com возвращает общий объём страниц в индексе. Запрос site:target.com -www убирает основной сайт и показывает поддомены: dev, staging, api, legacy-порталы. Оператор related:target.com выдаёт аффилированные домены - дочерние компании, партнёрские порталы, приобретённые бренды. По данным CybelAngel, это фундамент любого organization-specific расследования: без scoping-фазы дальнейшая разведка будет неполной.Нюанс:
related: работает не для всех доменов - Google возвращает результаты только для сайтов, которые сам считает достаточно "крупными". Для малого бизнеса оператор бесполезен.File & content - information disclosure
filetype:env site:target.com ищет .env-файлы с переменными окружения (DB_PASSWORD, API_KEY, SECRET_KEY). Расширяйте на sql, bak, log, conf, yml, json. Дорк intitle:"index of" site:target.com обнаруживает открытые directory listings - от них один шаг до скачивания любого файла из директории. Google Hacking Database (GHDB, поддерживается Offensive Security) - каталог готовых дорков, сортированных по категориям: файлы с паролями, error messages, open directories. GHDB применяется как чеклист при footprinting с помощью Google Dorks, а не как готовый рецепт.Но:
filetype: работает только с расширениями, которые Google умеет индексировать. Бинарные форматы (.sqlite, .kdbx) не ищутся - тут придётся копать иначе.Authentication surface - картирование логинов
Операторыinurl:login site:target.com, inurl:admin site:target.com, intitle:"VPN" OR intitle:"remote access" site:target.com выявляют точки входа для проверки на дефолтные credentials, brute-force protection и известные CVE. Для WordPress - inurl:"/wp-admin" site:target.com. Для 1С-Битрикс (свыше 30% корпоративного сегмента в России) - inurl:/bitrix/admin/ site:target.ru.Technology fingerprinting через OSINT
intitle:"phpinfo()" site:target.com выдаёт PHP-конфигурацию целиком: версия, модули, пути. intext:"Powered by" intext:"version" site:target.com - строки версий для сверки с NVD. intitle:"Grafana" OR intitle:"Kibana" site:target.com - мониторинговые платформы, часто выставленные без аутентификации (и это классика - торчат наружу в каждом втором проекте). Technology fingerprinting OSINT через дорки - не активное сканирование: данные уже в индексе, нужно только правильно спросить.Threat intelligence - мониторинг утечек на сторонних платформах
site:github.com "target.com" password OR secret OR key - код, в котором разработчики оставили credentials. site:pastebin.com "target.com" - paste-сайты с дампами. "@target.com" site:linkedin.com - перечисление email-адресов для целевого фишинга или credential stuffing. Эти запросы выходят за рамки инфраструктуры цели, но остаются полностью пассивными: open source intelligence footprinting не генерирует трафик на целевые серверы.Пошаговый workflow: footprinting с помощью Google Dorks
Отдельный класс - поиск уязвимостей через google dorks на сторонних платформах:
site:github.com "target.com" password, site:trello.com "target.com". Разработчики регулярно коммитят .env-файлы в публичные репозитории. По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году использовали валидные учётные данные - и часть этих credentials были доступны через простой поисковый запрос.Фаза 3 - валидация и переход от passive reconnaissance к pre-exploitation
Находка в индексе Google - ещё не уязвимость. Индекс может быть устаревшим: страница удалена, credentials сменены, файл закрыт через.htaccess. Каждую находку нужно валидировать. Здесь passive reconnaissance инструменты уступают место активной проверке.Пайплайн: из Google SERP извлекаем URL, проверяем доступность через
httpx -status-code -title -tech-detect, затем прогоняем через nuclei с шаблонами из каталога http/exposures/. Для расширения покрытия - gau (Get All URLs): инструмент вытягивает известные URL из Wayback Machine и других архивов, дополняя результаты за пределами текущего индекса Google.
Bash:
# Массовая валидация exposure-находок:
echo target.com | gau --threads 5 \
| grep -iE "\.(env|sql|bak|log|conf)$" \
| httpx -silent -sc -title \
| nuclei -t http/exposures/ -severity medium,high,criticalintitle:"FortiGate" site:target.com на внешнем пентесте обнаружил панель FortiGate. Проверка через nuclei-шаблон [URL='https://www.cve.org/CVERecord?id=CVE-2022-40684']CVE-2022-40684[/URL].yaml подтвердила authentication bypass (CVE-2022-40684, CVSS 9.8 CRITICAL, вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Уязвимость затрагивает FortiOS 7.2.0–7.2.1 и 7.0.0–7.0.6, FortiProxy и FortiSwitchManager (CWE-287, CWE-288 - authentication bypass using alternate path). CVE-2022-40684 внесена в CISA KEV и связана с ransomware-кампаниями. Публичные PoC доступны на ExploitDB (EDB-51092).Аналогичная цепочка: обнаружение Pulse Secure VPN через
intitle:"Pulse Secure" site:target.com -> проверка на CVE-2019-11510 (CVSS 10.0 CRITICAL, arbitrary file reading в Pulse Connect Secure 8.2/8.3/9.0, CWE-22 path traversal). Для CVE-2019-11510 существует Metasploit-модуль (EDB-47297), а сама уязвимость также числится в CISA KEV с пометкой ransomware-связи.Цепочка "дорк -> обнаружение панели -> nuclei -> CVE confirmation" - и есть pre-exploitation recon техники в чистом виде: переход от пассивного обнаружения к подтверждённому вектору атаки.
Ограничения Google Dorking и когда инструмент бесполезен
[Применимо: внешний пентест, все типы инфраструктуры]Понимание границ инструмента отличает результативного пентестера от скрипт-кидди. Дорки - не серебряная пуля, и вот где они ломаются.
CAPTCHA и rate limiting. Google начинает показывать CAPTCHA после 20-50 запросов подряд без пауз. Решения: паузы 10-30 секунд между запросами, ротация IP, Google Custom Search JSON API (100 бесплатных запросов в день - для серьёзного скоупа мало). Автоматизация через утилиты вроде
pagodo требует прокси-пул.Робот видит не всё. Корректно настроенный
robots.txt + мета-тег noindex + серверная аутентификация - тройная защита, которую google hacking не пробивает. Дорки находят только то, что было проиндексировано по ошибке.Устаревший индекс. Google может показывать результаты, которых уже не существует. Оператор
cache: deprecated в 2024 году - ближайшая замена Wayback Machine, но покрытие непостоянно. Каждая находка из SERP требует валидации через httpx.Cloud-native инфраструктура. Компании на AWS/GCP/Azure с инфраструктурой-как-код и автоматическим деплоем оставляют меньше следов в индексе, чем legacy-хозяйство с ручным управлением. Поддомен dev.target.com на bare-metal сервере с Apache 2.4 - лёгкая добыча. Kubernetes-кластер за CDN с корректными security headers - совсем другая история.
Юридические границы. Пассивная разведка через Google - серая зона: запросы уходят на серверы Google, а не на цель. Но скачивание найденного файла с credentials - прямое взаимодействие с инфраструктурой цели. Без scope document валидация находок может создать правовые риски.
| Ограничение | Что делать |
|---|---|
| CAPTCHA при массовых запросах | Паузы 10-30 сек, ротация IP, Google CSE API (100 req/day) |
| Корректный noindex + robots.txt + auth | Дорки бесполезны - переходи на active recon (subfinder, amass) |
| Устаревший индекс, нет cache: | Валидация каждой находки через httpx перед включением в отчёт |
| Cloud-native с CDN | Дополняй Certificate Transparency (crt.sh) и Shodan |
| Нет scope document | Фиксируй URL из SERP, не валидируй |
Для российского сегмента работают Yandex-дорки: оператор
mime: вместо filetype:, host: вместо site:. Яндекс индексирует .ru/.su-зоны глубже Google в ряде случаев, особенно для Битрикс-инфраструктуры. Запрос host:target.ru mime:env может вернуть результаты, которых нет в Google.По моей статистике, в 60-70% внешних пентестов Google Dorks дают хотя бы одну находку уровня medium и выше. Но в оставшихся 30-40% - компании с грамотной конфигурацией, где дорки не возвращают ничего полезного. Тогда переключаемся на Certificate Transparency, ASN enumeration (T1596.001, T1596.002 по ATT&CK) и active scanning.
Полгода назад я начал фиксировать, сколько времени уходит на dorking-фазу и сколько критических находок она приносит. В среднем - 25-40 минут на скоуп из 3-5 доменов, и в каждом втором проекте хотя бы один
.env или незакрытая admin-панель. Но есть момент, о котором мало кто говорит: большинство пентестеров останавливаются на этапе "нашёл в Google" и не доводят находку до валидации. Дорк показал phpinfo() - записали в отчёт как information disclosure уровня Low. А дальше? Версия PHP -> CVE -> exploit chain -> initial access -> foothold. Этот переход от пассивного recon к pre-exploitation и отличает формальный аудит от результативного пентеста.В ближайшие пару лет Google продолжит ужимать возможности dorking: CAPTCHA станет агрессивнее, deprecated-операторов станет больше (после
cache: в 2024 следующим под угрозой link:). Те, кто строит workflow исключительно на Google, окажутся в тупике. Рабочая связка: Google Dorks для первичного обнаружения, crt.sh для полноты покрытия, gau/Wayback для исторической глубины, nuclei для автоматической валидации. Кто владеет всей цепочкой - закрывает external attack surface mapping за один рабочий день, а не за неделю ручного ковыряния. Проверьте свой скоуп запросом site:your-domain.com filetype:env - если что-то вернулось, у вас та же проблема, что и у того финтеха из первого абзаца.
Последнее редактирование модератором:
