03.05.2023
1 хв
4953
Мережева розвідка (OSINT) — ключовий інструмент для багхантерів, які полюють на вразливості у вебсервісах та інфраструктурі компаній. Використання Google Dorks, Shodan, GitHub search та моніторингу витоків дозволяє знайти піддомени, відкриті API, тестові інстанси та конфіденційні дані ще до проведення активного тестування. Завдяки OSINT фахівець формує карту інфраструктури, виявляє старі паролі, токени та вразливі сервіси, що можуть стати входом до системи. Правильний підхід до збору інформації збільшує шанси на успішний багхантинг та підвищує ефективність пошуку критичних помилок.
Багхантер – це фахівець із пошуку вразливостей у цифрових системах. Його завдання — знаходити технічні дірки, які можна експлуатувати, та повідомляти про них власникам систем до того, як це зробить хтось інший. За це платять у рамках bug bounty програм або приватних договорів. Чим краще багхантер збирає інформацію про мету, тим швидше він знаходить точку входу. Не знаєш, які послуги у компанії є — не знайдеш ні помилку, ні баг. А от якщо у вас в арсеналі OSINT? розвідка з відкритих джерел? ти отримуєш перевагу.
OSINT – це пошук та аналіз інформації з публічних джерел: сайтів, форумів, соцмереж, локальних реєстрів, навіть кешів пошукових систем. Просунута розвідка з відкритих джерел — не просто збір адрес сайтів. Це системна робота: спочатку аналіз інфраструктури, потім пошук уразливих точок, далі випливає уточнення, що з цього реально можна використовувати в атаці.
Інструменти OSINT дозволяють багхантеру:
скласти карту доменів та піддоменів компанії;
знайти відкриті API, адмінки, панелі моніторингу та тестові інстанси;
отримати інформацію про внутрішні системи – слідами розробників у GitHub, Jira, DockerHub;
побачити витоку конфігурацій, паролів, ключів
зрозуміти, які технології використовує ціль і які вони відомі вразливості.
Простий приклад: багхантер запускає скан піддоменів, знаходить dev.oldcorp.com, на ньому Jenkins без авторизації. Далі через консоль виконує команду, отримує реверс-шелл. Все це почалося з OSINT.
Давайте розберемо кожен із методів OSINT частинами та на реальних кейсах: від Google Dorks до аналізу витоків.
Перший крок — зрозуміти, що ціль має в інтернеті, тобто які домени вона контролює, які технології використовує, які сервіси працюють в онлайні. Все це можна зібрати, не чіпаючи жодного сервера безпосередньо. Наприклад, багхантер використовує Amass, щоб зібрати всі піддомени компанії, серед них знаходить домен третього рівня vpn.oldcorp.com. Через Shodan він дізнається, що сервер використовує застарілий OpenVPN. Через nmap він бачить, що порт 943 відкрито. Це означає, що можна стукати до веб-інтерфейсу адмінки з версією. За CVE у такий спосіб у нас знайдено RCE-експлойт, а отже, OSINT дав не просто карту інфраструктури, а конкретну мету, що експлуатується без зайвого шуму.
Розробники часто самі викладають ключі, конфіги та паролі у відкритих репозиторіях. Зазвичай це відбувається випадково чи через незнання. Все це стає частиною відкритого інтернету, якщо потрапляє до індексу пошуковика, репозиторій або хмарного сховища без доступу. Наприклад, багхантер може використовувати Google Dork site:github.com “aws_access_key_id” “oldcorp” – і знайти коміт, в якому інженер завантажив .env з AWS-ключами. Перевірка показала, що ключ активний. Через AWS CLI багхантер отримує список бакетів, один з них може бути відкритим і містити дампи внутрішніх баз. Що можна було зробити за допомогою цієї інформації? Якби доступ був реальний, це критична вразливість із серйозними наслідками.
Інструменти та підходи:
Google Dorks: intitle:index.of, filetype:env, intext:”password”
GitHub search + GitLeaks: шукаємо API-ключі, токени, конфіги
hunter.io, theHarvester: збір email-адрес та профілів
waybackurls, gau: індексація старих URL-адрес та ресурсів
Злитий пароль – це не просто рядок з бази, це потенційний вхід у внутрішні системи. У багатьох компаній корпоративні емейли, які вже спливали у старих витоках і досі працюють. Якщо не впроваджено двофактор, а паролі не змінювалися роками, то атака стає тривіальною.
Наприклад, багхантер перевіряє домен компанії через Have I Been Pwned і бачить кілька збігів по емейл. Один із них — [email protected]. Через DeHashed та Scylla.sh він знаходить старий пароль. Потім заходить за цими даними до Jenkins-інстанс, доступний за адресою ci.target.com. Jenkins цілком може бути налаштований без SSO і авторизація пройде успішно. Таким чином можна отримати доступ до пайплайнів, змінних оточення, токенів.
Інший реальний кейс – витік токенів Slack. У 2023 році один розробник випадково закоммітив .env із SLACK_API_TOKEN у публічний GitHub-репозиторій. Репозиторій було видалено через добу, але токен залишився активним. Багхантер використовував архів GitHub через wayback machine, витягнув .env, отримав токен, розшифрував workspace, а потім знайшов список учасників та повідомлення внутрішніх каналів. Серед них було обговорення production-інциденту та ключ до staging-оточення.
Також у 2024 році стався витік бази даних з форуму Exploit.in, який знову актуалізував уразливість через старі корпоративні емейли. Один із багхантерів знайшов логін та пароль співробітника IT-відділу в цій базі. Спробувавши авторизацію на GitLab компанії, він отримав доступ. Вивантаження проектів показало, що в одному з репозиторіїв є deploy.sh із приватним приватним SSH-ключом. Ключ був активний і за допомогою нього вдалося підключитися до staging-сервера.
Це важливий урок про те, що не можна ігнорувати старі витоки. Те, що злилося у 2016, може працювати у 2025, якщо процеси контролю та ротації відсутні. Багхантер, який стежить за витоками, має фору за кілька кроків до будь-якої перевірки сканерами.
На жаль, корпоративні помилки повторюються, особливо у межах однієї галузі — fintech, edtech, SaaS тощо. Аналізуючи вразливості конкурентів, багхантер може отримати карту типових багів, архітектурних прорахунків та поганих практик.
Наприклад, багхантер вивчає публічні звіти на HackerOne по компаніях з тієї ж сфери, що і ціль. Бачить серію багів, пов’язаних із поганою валідацією JWT-токенів: відсутність перевірки alg, заміна токена на none, або відсутність ротації refresh-токенів. Перевіряє реалізацію на стороні своєї мети і знаходить схожу конструкцію, потім генерує токен з alg: none, підписує і таким чином отримує доступ до чужого облікового запису.
Інший випадок: вивчення піддоменів конкурентів через Shodan. Багхантер зауважує, що в одного з конкурентів вендор розгорнув систему моніторингу на публічному IP без авторизації. Він перевіряє ту ж схему біля мети та знаходить grafana.oldcorp.com, доступний без логіну. Далі він отримує візуалізацію запитів до backend’у, схеми баз даних та API-ключі.
Треба розуміти, що інструмент сам собою — це просто програма, яка має лише теоретичну корисність. Ефект дає лише правильний ланцюжок: ціль → припущення → інструмент → результат → атака.
Це інструмент візуального аналізу, який запускається для збагачення та уточнення зв’язків між доменами, IP, email, компаніями та будь-якими іншими сутностями. Наприклад, вводимо example.com, будуємо граф і знаходимо пов’язані email-адреси, одна з яких засвічена в Have I Been Pwned. Далі логічно провести перевірку пароля для спроб входу у внутрішні панелі.
Maltego корисний при розслідуванні та картуванні пов’язаних структур. Особливо якщо мета дробиться на багато юросіб або інфраструктура розмазана підрядниками.
Це пошукова система з інфраструктури. У практичній реалізації він може виглядати так: запитуємо org: “OldCorp” port:9200, бачимо, що у компанії відкрито Elasticsearch без авторизації. Далі здійснюємо перехід по IP, curl-запит і бачимо дані. Можна репортувати критичну вразливість.
Також Shodan може використовуватися для пошуку Open Jenkins, GitLab, Prometheus, Zabbix та інших сервісів з відомими вразливістю. Окрім цього можна здійснити пошук за сигнатурами: product:Jenkins, http.title:”GitLab”.
Це елементарний інструмент для уточнення пошукових запитів. Скажімо. запит site:corp.com filetype:env може видати .env із продовими ключами. А intitle:”index of” admin може підсвітити папку з дампами. Несморя на простоту це досить ефективний інструмент: такі файли адміністратори все ще завантажують у корінь сайту або забувають закрити індексацію.
Однак ця схема не працює за свіжими файлами. Вам варто розраховувати лише на те, що вже потрапило до індексу. При цьому Google Dorks краще комбінувати з waybackurls і filesystem search.
Пошук у репозиторіях може бути дуже корисним. Коли ми запитуємо org:corp “api_key”, можемо знайти закоммічений config.js із ключем до Stripe. Через git clone та gitleaks detect можна автоматизувати пошук на рівні всього GitHub або конкретних реп. Це корисно як у фазі розвідки, так і для моніторингу власних витоків, якщо ви на боці компанії.
OSINT – не хакінг, але його наслідки можуть бути порівнянними. Все залежить від того, куди ви полізли і з якою метою. Лінія проходить там, де закінчується публічність та починається несанкціонований доступ.
Що допустимо:
аналіз доменів, ІР, публічних метаданих;
вивчення відкритих репозиторіїв, форумів, соціальних мереж;
перевірка витоків із використанням публічних баз даних;
сканування через пасивні джерела (Shodan, Censys, Archives);
пошук по Google Dorks та кешу.
Що вимагає дозволу:
фішинг (навіть якщо це просто лист із посиланням);
спроба авторизації за знайденими даними;
робота з вразливими сервісами, навіть якщо доступ відкритий;
сканування чи перебір на бойових інстансах.
Зразок: ви знайшли відкритий Jenkins. Якщо ви просто зайшли в інтерфейс – це OSINT. Якщо запустили білд – це вже активна дія. Без дозволу – кримінальна стаття.
Таким чином, OSINT — це не просто етап розвідки, а фундамент успішного багхантінгу. Кожен знайдений піддомен, пароль, що втік, або забутий API – це потенційні двері в систему. Багхантер без OSINT як шукач скарбів без картки. Він може копати навмання, але справжні знахідки чекають на тих, хто вміє аналізувати, зіставляти і знаходити слабкі місця ще до першої атаки.
