OSINT w codziennej pracy IT

OSINT, czyli Open Source Intelligence, kojarzy się głównie z wywiadem i red teamingiem. W praktyce codziennej pracy IT to zestaw technik pozwalających szybko zrozumieć kontekst: co jest wystawione na zewnątrz, z czym to się komunikuje i co może pójść nie tak.

Do czego OSINT przydaje się na co dzień

Kilka scenariuszy z rzeczywistej pracy:

Przejęcie utrzymania infrastruktury. Zanim zaczniesz cokolwiek zmieniać, chcesz wiedzieć, co jest widoczne z zewnątrz. Shodan i Censys dają zupełnie inną perspektywę niż patrzenie od środka, a nmap uzupełnia ten obraz aktywną weryfikacją tego, co znalazłeś pasywnie. To dobre uzupełnienie pierwszego audytu po przejęciu serwera, zanim jeszcze zalogujesz się po SSH.
Analiza incydentu. Ktoś atakuje z konkretnego IP, chcesz szybko ustalić kontekst: ASN, geolokalizację, historię zgłoszeń. Warto pamiętać, że geolokalizacja adresu IP to przybliżona lokalizacja samego adresu albo infrastruktury operatora, a nie lokalizacja atakującego, który mógł działać przez VPN, proxy albo przejęty serwer.
Weryfikacja wycieków. Sprawdzenie, czy adresy e-mail organizacji pojawiają się w znanych wyciekach (HaveIBeenPwned API, Dehashed).
Due diligence dostawcy. Zanim podpiszesz umowę, warto wiedzieć, jak wygląda jego własna infrastruktura od zewnątrz.

Narzędzia, które faktycznie się przydają

Shodan

Wyszukiwarka urządzeń podłączonych do internetu. Podstawowe zastosowanie to sprawdzenie, co organizacja wystawia na zewnątrz, często bez pełnej świadomości tego faktu.

org:"Nazwa firmy"
ssl.cert.subject.cn:"*.domena.pl"
http.favicon.hash:XXXX

Shodan CLI umożliwia automatyzację:

shodan search --fields ip_str,port,org 'org:"Nazwa"' | sort -t',' -k2 -n

Darmowy plan ma limity zapytań i ograniczoną liczbę wyników, więc do regularnego monitoringu większej liczby domen warto rozważyć płatny dostęp albo API Censys jako uzupełnienie.

Censys

Podobny do Shodana, z osobną metodologią i częstotliwością skanowania, więc bywa, że pokazuje coś, czego Shodan jeszcze nie widział, i odwrotnie. Przydatny do mapowania infrastruktury przez certyfikaty, zwłaszcza gdy organizacja korzysta z współdzielonych IP albo CDN, gdzie sam adres niewiele mówi.

Certificate transparency: crt.sh

Publicznie zaufany certyfikat TLS, czyli taki, który spełnia wymagania ekosystemu przeglądarek i podlegających mu urzędów certyfikacji, trafia do publicznych logów Certificate Transparency. Certyfikat z prywatnego CA albo self-signed nie musi się tam pojawić, ale zdecydowana większość certyfikatów używanych na publicznie dostępnych stronach spełnia te wymagania. crt.sh pozwala te logi przeszukać i jest jednym z najszybszych sposobów na znalezienie subdomen, o których organizacja mogła zapomnieć:

curl -s "https://crt.sh/?q=%.domena.pl&output=json" | jq -r '.[].name_value' | sort -u

Ta metoda jest w pełni pasywna, nie generuje żadnego ruchu w stronę badanej infrastruktury, więc dobrze nadaje się jako pierwszy krok przed czymkolwiek bardziej aktywnym.

theHarvester

Zbieranie adresów e-mail, subdomen i nazw z publicznych źródeł:

theHarvester -d domena.pl -b google,bing,linkedin

Wyniki bywają hałaśliwe i zawierają fałszywe trafienia, warto je zawsze weryfikować ręcznie, zanim trafią do raportu czy dalszej analizy.

Amass i subfinder

Do enumeracji subdomen dają znacznie więcej wyników niż ręczne przeszukiwanie DNS:

amass enum -passive -d domena.pl
subfinder -d domena.pl -silent

Amass w trybie pasywnym korzysta wyłącznie z zewnętrznych źródeł danych, bez bezpośrednich zapytań do infrastruktury celu. Tryb aktywny (-active) już dotyka badanej domeny i wymaga tej samej ostrożności co skanowanie portów.

WHOIS i pasywny DNS

Dane rejestracyjne domeny (WHOIS) i historia rekordów DNS potrafią pokazać zmiany właściciela, przeniesienia infrastruktury albo powiązane domeny rejestrowane w tym samym czasie. Lokalne, bieżące sprawdzenie warto robić po konkretnym typie rekordu, a nie zapytaniem ANY, którego wiele serwerów DNS dziś ogranicza albo ignoruje i które i tak nie pokaże historii, tylko aktualny stan:

whois domena.pl
dig +short domena.pl A
dig +short domena.pl MX
dig +short domena.pl NS
dig +short domena.pl TXT

Historyczne rekordy, czyli to, co domena wskazywała wcześniej, zanim ktoś to zmienił, to już domena serwisów z pasywnym DNS, na przykład SecurityTrails: przechowują zapisy nawet po ich zmianie, co bywa jedynym śladem po serwerze, który dawno przestał istnieć.

Podobną rolę, ale dla treści stron, pełni Wayback Machine (archive.org). Archiwalne migawki potrafią pokazać starą strukturę API, zapomniany panel administracyjny albo wersję strony sprzed migracji, których już nie ma w żywej infrastrukturze, ale które mogą wciąż odpowiadać na starych subdomenach.

Threat intelligence i reputacja

Zanim zaczniesz ręcznie analizować podejrzany adres IP albo domenę, sprawdź, czy ktoś już to zrobił. VirusTotal agreguje wykrycia z wielu silników antywirusowych i sandboxów, AbuseIPDB zbiera zgłoszenia o nadużyciach powiązane z konkretnymi adresami IP:

curl -s -H "x-apikey: TWOJ_KLUCZ" \
  "https://www.virustotal.com/api/v3/ip_addresses/1.2.3.4"

To dobry pierwszy krok przy analizie incydentu, zanim zaangażujesz czas w głębszą analizę.

Wycieki kodu i sekretów

Publiczne repozytoria bywają źródłem informacji, których nikt świadomie nie chciał ujawnić: kluczy API, danych dostępowych, wewnętrznych adresów. GitHub code search i narzędzia takie jak gitleaks czy trufflehog można uruchomić nie tylko na własnych repozytoriach, ale też przeszukać publiczne repozytoria pracowników pod kątem przypadkowo opublikowanych sekretów firmowych. To naturalne rozszerzenie tematu zarządzania sekretami, tylko z perspektywy sprawdzania, co już wyciekło, zamiast zapobiegania. Do automatycznego, cyklicznego skanowania repozytoriów pod kątem takich wycieków zbudowałem git-scanner.

Frameworki agregujące

SpiderFoot i Recon-ng automatyzują część tej pracy, odpytując dziesiątki źródeł jednocześnie i budując mapę powiązań między domenami, adresami IP, adresami e-mail i kontami w mediach społecznościowych. Przydają się, gdy trzeba szybko zbudować ogólny obraz, ale wynik zawsze wymaga ręcznej weryfikacji, bo agregacja mnoży też liczbę fałszywych trafień.

Kilka praktycznych zasad

Działaj w granicach uprawnień. Korzystanie z publicznie dostępnych indeksów, takich jak Shodan czy crt.sh, to co innego niż bezpośrednie, aktywne skanowanie cudzej infrastruktury. To drugie może naruszać prawo, regulaminy usług albo zawarte umowy, zależnie od jurysdykcji, sposobu działania i celu, i powinno być wykonywane wyłącznie w ramach jasno określonych uprawnień, na przykład własnej infrastruktury, pisemnej zgody właściciela albo umowy pentestowej. Nie jest to kwestia, którą da się rozstrzygnąć jednym uniwersalnym zdaniem, w razie wątpliwości warto to skonsultować z działem prawnym.

Pilnuj OPSEC własnych działań. Aktywne zapytania, na przykład bezpośrednie żądania HTTP do badanej infrastruktury, zostawiają ślad w logach po drugiej stronie. Przy analizie incydentu z udziałem realnego przeciwnika warto rozważyć, czy Twoje własne zapytania nie zdradzą, że sprawa została zauważona.

Automatyzuj rutynowe sprawdzenia. Cykliczny monitoring własnych domen pod kątem nowych subdomen lub wystawionych portów to dobre uzupełnienie standardowego monitoringu infrastruktury.

Dokumentuj, co znalazłeś. OSINT bez zapisu jest jednorazowy. Notatnik (Obsidian, Logseq, zwykły markdown) z datowanymi obserwacjami ma wartość historyczną przy analizie incydentów, zwłaszcza gdy trzeba porównać stan infrastruktury sprzed miesięcy z obecnym.

Koreluj źródła. Jedno źródło to dane, dwa to korelacja, trzy to wiedza operacyjna. Adres IP pojawiający się jednocześnie w Shodanie, w feedach threat intelligence i we własnych logach to inny priorytet niż adres IP widoczny tylko w jednym miejscu.

OSINT to nie magia, tylko systematyczne zbieranie i łączenie publicznych informacji, żeby zobaczyć obraz, który inni przeoczają. Sposób, w jaki takie zbieranie i korelację danych rekonesansu układam w jedno narzędzie, pokazuję przy projekcie CyberSec Recon Console.