Google Dorks для OSINT: практичний гайд для due diligence

Звичайний пошук у Google і Google-дорк-запит ставлять пошуковику два різні питання. Перший шукає, про що сторінка. Другий — який це тип файлу, де він розміщений і що саме там не мало з'являтися у видачі. Для розслідувача друге питання часто важливіше: саме так публічно проіндексована таблиця, відкрита адмін-панель чи витік внутрішнього документа знаходяться без потреби вручну перевіряти кожен закуток інтернету. Нижче — як працюють ці оператори, яке місце вони займають у повноцінному OSINT-процесі та де їхні можливості закінчуються.

Ключові тези

• Google-дорки — це стандартні оператори пошуку Google: site:, filetype:, intitle:, inurl:, intext: та кілька інших, скомбіновані так, щоб звузити пошук до конкретного типу файлу, домену чи шаблону сторінки. Для цього не потрібен особливий доступ чи хакерські інструменти.
• Для due diligence та перевірки репутації це важливо тому, що такі запити знаходять документи, відкриті директорії та проіндексовані сторінки, які не з'являться у відповідь на просто ім'я людини чи назву компанії.
• Одного оператора рідко достатньо. Цінність мають саме комбінації — і вміння підібрати правильну комбінацію під конкретне запитання є справжньою навичкою.
• Усе, що повертає дорк-запит, — це зачіпка, а не висновок. Перевірка того, чим цей результат є насправді, чи він актуальний і чи його можна законно використати, — окрема робота, яка йде вже після пошуку.
• Запуск таких запитів проти систем чи даних, доступу до яких у вас немає, — на відміну від пошуку в тому, що вже публічно проіндексовано й доступне будь-якому користувачу, — це вже зовсім інша дія, і в практиці Molfar ця межа проведена чітко.

Що таке Google-дорк насправді

Слово "дорк" (dork) звучить як назва хакерської техніки, і його справді часто так і використовують — тому варто одразу уточнити: Google-дорк — це пошуковий запит, побудований з операторів, які сам Google документує й підтримує. Жодного експлойту, жодного обходу систем захисту, нічого, крім рядка пошуку. Дорк-запит просто каже Google фільтрувати за критеріями, які звичайний пошук за ключовими словами ігнорує: тип файлу, структура URL, заголовок сторінки, домен, діапазон дат — так, що у видачі опиняються не просто сторінки про тему, а сторінки, які відповідають дуже конкретній формі.

Причина, чому це взагалі є темою безпеки й розслідувань, — у тому, чим ця форма часто виявляється на практиці. Краулер Google індексує все, що публічно доступне, зокрема файли й директорії, які адміністратор ніколи не планував робити доступними для пошуку: таблицю, залишену у незахищеній папці, сторінку входу без заборони в robots.txt, конфігураційний файл, що опинився в корені вебсайту. Для цього не потрібне жодне правопорушення — потрібно лише знати, які оператори скомбінувати.

Яке місце це займає в OSINT-процесі

Використання розширених пошукових операторів — один із шарів у ширшій OSINT-методології, а не заміна їй. OSINT як дисципліна спирається на набагато більше, ніж запити до пошуковика, а оператори нижче — один зі способів виконати кроки "пошук офіційних і публічних записів" та "картографування публічної цифрової інфраструктури", описані в нашому огляді OSINT-методів. Це також один із пунктів у значно ширшому каталозі інструментів і методів, структурованому в OSINT Framework, де дорк-запити згруповані поряд із пошуком у соцмережах, аналізом метаданих та десятками інших категорій.

Оператори, які дійсно важливі для due diligence

Кілька операторів покривають переважну більшість практичних випадків. Кожен працює й окремо, але справжня цінність — у комбінаціях.

site: обмежує результати одним доменом. site:sec.gov поверне лише сторінки цього домену, проіндексовані Google, — зручно для пошуку по сайту регулятора чи компанії без зайвого шуму з усього інтернету.

filetype: обмежує результати конкретним форматом файлу. filetype:xlsx чи filetype:pdf — спосіб знайти таблиці, PDF-файли й презентації, а не вебсторінки. Це важливо, бо внутрішні документи (фінанси, оргструктура, списки постачальників) часто опиняються проіндексованими саме як файли, а не як сторінки.

intitle: обмежує результати сторінками, де термін є в заголовку. intitle:"index of" — класичний шаблон для пошуку відкритих лістингів директорій: папок, які вебсервер показує без жодної сторінки-"обгортки", демонструючи всі файли всередині.

inurl: обмежує результати сторінками, де термін є в самій адресі. inurl:login чи inurl:admin показує сторінки входу й адмін-панелі, які технічно доступні, але не мали рекламуватися публічно.

intext: обмежує результати сторінками, де термін є будь-де в тексті. intext:"confidential" чи intext:"internal use only" — спосіб знайти документи з власними позначками конфіденційності; це працює саме тому, що така позначка ніколи не мала стати об'єктом пошуку.

OR, оператор виключення (-) і символ підстановки (*) не обмежують, а уточнюють запит: OR шукає за двома термінами одночасно, - виключає термін із результатів, а * замінює невідоме слово. "Іван * Петренко" підхопить по-батькові чи middle name, якого у вас ще немає; site:example.com -www виключає основний сайт, коли потрібні саме субдомени.

Справжню роботу виконують комбіновані запити: site:example.com filetype:xlsx intext:"бюджет" — це принципово інший, значно точніший запит, ніж будь-яка з трьох його частин окремо. І саме комбінація, а не окремий оператор, будується розслідувачем під конкретне запитання.

Чекліст Google-дорків для due diligence

Оператори вище — узагальнені. Цінність на практиці дає саме знання, яка комбінація відповідає на яке розслідувальне запитання, — а цю відповідність рідко де прописують, бо більшість гайдів з дорк-запитів пишуться для пентестерів, а не для корпоративного due diligence чи перевірки репутації. Ось версія, якою користуємося ми, структурована за типом запитання, а не за оператором:

Перевірка публічного сліду компанії та її розкриттів

• site:[домен компанії] filetype:pdf — річні звіти, політики й розкриття, які компанія сама публікувала, і які часто легше знайти так, ніж через її власну навігацію.
• site:[домен компанії] intitle:"index of" — швидка перевірка на відкритий лістинг директорії на корпоративному домені, що трапляється частіше, ніж мало би.
• "[назва компанії]" filetype:xlsx OR filetype:csv — таблиці, що згадують компанію, але розміщені поза її доменом; це можуть бути витоки списків постачальників чи дані, якими необережно розпорядився партнер.

Перевірка відкритості інформації про конкретну людину (background check, перевірка перед працевлаштуванням)

• "[повне ім'я]" filetype:pdf — ім'я всередині PDF-файлів: резюме, судові документи, програми конференцій, наукові публікації.
• intext:"[повне ім'я]" intext:"резюме" OR intext:"CV" — публічно проіндексовані копії резюме, які можуть показати трудову історію інакше, ніж її описує сама людина.
• "[повне ім'я]" site:linkedin.com OR site:facebook.com — звужує результати до конкретного імені на конкретній платформі, що не завжди робить внутрішній пошук самої платформи.

Перевірка активів і власності

• "[назва юрособи]" filetype:pdf intext:"витяг з ЄДР" — витяги з Єдиного державного реєстру, які хтось завантажив як PDF на сторонній сайт (для тендеру, пакету due diligence тощо); будь-який знайдений так витяг перевіряється проти офіційного пошуку в ЄДР на порталі online.minjust.gov.ua, а не сприймається як достатнє підтвердження сам по собі.
• site:[домен реєстру юрисдикції] "[назва юрособи]" — цільовий пошук саме в проіндексованому вмісті конкретного публічного реєстру, коли його власний внутрішній пошук слабкий або платний.

Перевірка випадкового витоку даних, пов'язаного з організацією

• site:pastebin.com "[домен компанії]" — домен чи шаблон email компанії у дампах на пейстбін-сайтах — часто найшвидший сигнал, що облікові дані, пов'язані з організацією, десь уже злили.
• intext:"password" filetype:log site:[домен компанії] — відкриті лог-файли, які ніколи не мали індексуватися і які інколи залишаються доступними ще місяцями після того, як першопричину нібито усунули.

Жоден з цих запитів не є екзотичним. У процес це перетворює саме запуск правильного набору запитів під конкретне питання, а не один загальний пошук навмання — і подальше ставлення до кожного результату як до зачіпки для перевірки, а не як до готового висновку.

Для повнішого, постійно оновлюваного каталогу конкретних шаблонів дорк-запитів за типом того, що вони розкривають, корисним публічним довідником лишається Google Hacking Database (GHDB) — категоризований індекс, який підтримує компанія OffSec відтоді, як у листопаді 2010 року перейняла проєкт від його творця. Каталог охоплює все: від відкритих сторінок входу до неправильно сконфігурованих директорій файлів. Утім, це каталог шаблонів, а не заміна вміння підібрати шаблон під власне запитання.

Що насправді розкривають ці запити — і чому перевірка все одно потрібна

Причина, з якої варто серйозно ставитися до дослідження випадкових витоків даних, — не одна гучна статистика про злом, а те, наскільки рутинним є саме це викриття. Академічне дослідження атак, що поєднують Google-дорки з інструментами на кшталт Shodan і Censys, зазначає: серед усіх задокументованих типів кібератак загалом у 2022 році найбільшу частку становив ransomware (68,42%), далі мережеві злами (18,42%) і ексфільтрація даних (3,95%), решта розподілена між іншими категоріями.(1) Це цифри про загальну картину кіберзлочинності, до якої веде розвідка на основі дорк-запитів, а не статистика конкретно про атаки з використанням дорків — і саме так їх і варто читати. Суть не в точному відсотку, а в тому, що етап розвідки — пошук уже відкритого, будь-яким способом, — передує значній частці того, що зрештою стає інцидентом, про який звітують.

Саме тому результат будь-якого із запитів вище — це зачіпка, а не висновок. Пошуковик може підтвердити, що файл існує й проіндексований. Він не може підтвердити, чи файл актуальний, чи його вже замінили новішою версією, чи позначка "confidential" — реальний сигнал конфіденційності, а не стандартний текст шаблону, чи документ дійсно належить тій юрособі, на яку натякає назва файлу. Усі чотири випадки траплялися достатньо часто, щоб жоден знайдений через дорк-запит документ не потрапляв у результат роботи Molfar без окремого підтвердження через першоджерело — реєстр, прямий запит або підтвердження з інших незалежних джерел.

Правові та етичні межі

Усе описане вище працює з контентом, який уже публічно проіндексований Google, — сторінками й файлами, які пошуковик, а отже й будь-хто інший, і так може дістати без обходу жодного логіна, платного доступу чи системи захисту. Це принципово інша дія, ніж спроба отримати доступ до системи, на яку немає дозволу, — і межа між ними не зсувається залежно від того, наскільки цікавим виглядає знахідка.

В українському праві ця межа проведена прямо: стаття 361 Кримінального кодексу України встановлює відповідальність за несанкціоноване втручання в роботу інформаційних (автоматизованих), електронних комунікаційних, інформаційно-комунікаційних систем та електронних комунікаційних мереж — за базовим складом (частина 1) це штраф від 1 000 до 3 000 неоподатковуваних мінімумів доходів громадян, пробаційний нагляд або обмеження волі на строк до трьох років. Пошук відкритого ресурсу, який Google уже проіндексував, під цю статтю не підпадає. Спроба використати знайдену вразливість чи дані для подальшого проникнення в систему — підпадає, незалежно від заявленої мети. Коли в межах легітимного дослідження трапляються чутливі відкриті дані, правильний шлях — задокументувати знахідку і, де доречно, повідомити про потребу усунути вразливість, а не завантажувати, поширювати чи використовувати ці дані понад те, що потрібно для конкретного завдання.

Поширені запитання

Чи незаконні Google-дорки?

‍Ні — самі оператори є стандартним, задокументованим Google синтаксисом пошуку, і пошук публічно проіндексованого контенту з їх допомогою не є несанкціонованим доступом. Незаконним може стати те, що хтось робить із результатом: доступ до системи понад те, що вже відкрито будь-якому користувачу, або використання знайдених облікових даних чи інформації — це вже інша дія, яка в Україні підпадає під статтю 361 ККУ.

Чи потрібне для Google-дорків спеціальне програмне забезпечення?

‍Ні. Кожен оператор, описаний тут, працює у звичайному рядку пошуку Google. Спеціалізовані інструменти для розвідки (Shodan, Censys, Recon-ng) розширюють ту саму ідею на інфраструктуру, яку пошуковики не індексують, але це окремий шар, а не обов'язкова умова для самих дорк-запитів.

Чому внутрішній пошук на сайті компанії не знаходить того, що знаходять Google-дорки?

‍Внутрішній пошук сайту зазвичай індексує лише те, що налаштовано в системі керування контентом, і найчастіше тільки сторінки, а не будь-який тип файлу. Краулер Google індексує все публічно доступне незалежно від того, чи веде туди посилання з навігації сайту, — саме тому файл без жодного посилання на нього все одно може з'явитися в дорк-запиті.

Чим це відрізняється від OSINT Framework чи загальних OSINT-методів?

‍Google-дорк-запити — один конкретний метод усередині OSINT: спосіб виконати кроки з пошуку та записів, які ширший OSINT-процес виконує й іншими способами — через соцмережі, аналіз метаданих, пошук у публічних реєстрах. OSINT Framework каталогізує його поряд із цими методами; ця стаття детально розбирає саме оператори.

Чи може пошук через Google-дорки замінити професійну перевірку due diligence чи background check?

‍Ні. Це техніка пошуку потенційних зачіпок. Підтвердження того, що ці зачіпки насправді означають, — перевірка автентичності документа, звірка твердження з першоджерелом, оцінка юридичних ризиків — окремий, значно складніший процес, і саме цю частину автоматизований пошук виконати не може.