Cyberbezpieczeństwo • Open Source Intelligence • Reconnaissance • Analiza powierzchni ataku

Rekonesans jest jednym z pierwszych etapów testów penetracyjnych. Jego zadaniem jest ustalenie, jakie informacje o badanej organizacji, jej domenach, infrastrukturze, aplikacjach i technologiach można pozyskać przed rozpoczęciem właściwych testów bezpieczeństwa.

OSINT (Open Source Intelligence) to proces pozyskiwania, weryfikowania, korelowania i analizowania informacji dostępnych publicznie lub komercyjnie, w celu odpowiedzi na konkretne pytanie analityczne. Nie jest jedynie wyszukiwaniem informacji w Google. Jego wartość wynika z łączenia pozornie niezależnych danych w spójny obraz sytuacji.

W cyberbezpieczeństwie OSINT pozwala między innymi ustalić, jakie zasoby organizacja udostępnia publicznie, jakie technologie wykorzystuje, czy ujawnia informacje o swojej infrastrukturze oraz które elementy jej cyfrowego śladu wymagają dodatkowej ochrony.

Z perspektywy pentestera rekonesans pomaga odpowiedzieć na podstawowe pytanie: co potencjalny napastnik może dowiedzieć się o systemie, zanim spróbuje naruszyć jego zabezpieczenia?

1. OSINT, reconnaissance i rozpoznanie techniczne — podstawowe pojęcia

1.1. Czym różni się OSINT od rekonesansu?

Pojęcia te są powiązane, ale nie są tożsame.

• OSINT — pozyskiwanie i analiza informacji ze źródeł otwartych.
• Reconnaissance — szerszy etap rozpoznawania celu, obejmujący zarówno analizę źródeł otwartych, jak i inne dopuszczone metody zbierania informacji.
• Passive reconnaissance — rozpoznanie bez bezpośredniego sondowania badanego systemu.
• Active reconnaissance — rozpoznanie przez bezpośrednią interakcję z celem, np. kontrolowane sprawdzanie dostępnych usług sieciowych.

W klasyfikacji MITRE ATT&CK rekonesans stanowi odrębną taktykę, obejmującą techniki zbierania informacji o organizacji, jej pracownikach i infrastrukturze.

MITRE ATT&CK®

+1

Istotne jest to, że publicznie dostępna informacja nie musi być informacją nieszkodliwą. Nazwa używanej platformy, adres panelu administracyjnego czy schemat adresów e-mail mogą nie stanowić podatności samodzielnie, lecz mogą ułatwiać kolejne etapy ataku.

1.2. Pasywny i aktywny rekonesans

Pasywny rekonesans

Analiza publicznych stron, rekordów DNS dostępnych przez publiczne źródła, certyfikatów TLS, archiwów internetowych, dokumentacji i danych z publicznych baz technicznych. Nie wymaga wysyłania sond do badanego serwera.

Aktywny rekonesans

Bezpośrednie sprawdzanie usług, portów, endpointów i zachowania systemu. Może generować logi, alerty i obciążenie, dlatego wymaga odpowiedniego zakresu oraz upoważnienia.

Przykład różnicy: sprawdzenie historycznych rekordów DNS w publicznej bazie jest działaniem pasywnym. Wysłanie pakietów do portów badanego hosta w celu ustalenia, które usługi nasłuchują, jest rozpoznaniem aktywnym.

Pasywny rekonesans również wymaga ostrożności. Publiczne źródła mogą zawierać dane nieaktualne, błędnie przypisane lub dotyczące infrastruktury dostawcy, a nie organizacji, którą analizujemy.

1.3. Cele rekonesansu w pentestingu

Prawidłowo przeprowadzony rekonesans powinien pozwolić na:

1. Ustalenie zakresu cyfrowej obecności organizacji.
2. Identyfikację publicznie dostępnych zasobów.
3. Rozpoznanie technologii i zależności.
4. Wykrycie niezamierzonego ujawniania informacji.
5. Wstępną ocenę powierzchni ataku.
6. Opracowanie hipotez do późniejszej weryfikacji.
7. Ustalenie priorytetów dalszych testów.

Nie należy utożsamiać rekonesansu z potwierdzaniem podatności. Informacja, że serwer używa konkretnej technologii, nie oznacza jeszcze, że jest podatny na atak.

2. Cykl OSINT — od pytania analitycznego do wniosków

Skuteczny OSINT powinien być procesem powtarzalnym. Gromadzenie setek domen, adresów IP i nazw technologii bez określonego celu generuje szum informacyjny, ale niekoniecznie poprawia bezpieczeństwo.

Metodyka powinna obejmować następujące etapy:

01

Planowanie

Określenie celu, zakresu, ograniczeń i pytań badawczych.

02

Pozyskiwanie danych

Źródła publiczne, DNS, certyfikaty, archiwa i dokumentacja.

03

Normalizacja

Usuwanie duplikatów, standaryzacja domen i dat.

04

Korelacja

Łączenie danych o zasobach, technologiach i zależnościach.

05

Weryfikacja

Sprawdzenie aktualności, wiarygodności i alternatywnych wyjaśnień.

06

Ocena ryzyka

Ustalenie, które obserwacje wymagają działań obronnych.

07

Raportowanie

Wnioski, dowody, poziom pewności i zalecenia.

2.1. Planowanie — sformułowanie pytania badawczego

Zanim rozpoczniesz zbieranie informacji, określ, co dokładnie chcesz ustalić.

Przykładowe pytania dla właściciela witryny:

• Jakie domeny i subdomeny należą do naszej organizacji?
• Czy publiczne źródła ujawniają środowiska testowe?
• Jakie informacje o technologiach można uzyskać bez logowania?
• Czy certyfikaty wskazują na nieznane lub zapomniane nazwy hostów?
• Czy publicznie dostępne dokumenty ujawniają dane, które powinny pozostać niejawne?
• Czy istnieją historyczne adresy URL, które warto sprawdzić w ramach zatwierdzonego audytu?

Dobrze postawione pytanie determinuje dobór źródeł i pozwala zdefiniować kryterium zakończenia analizy.

2.2. Pozyskiwanie informacji

Źródła należy dobierać do rodzaju badanego zasobu. Inne źródła będą odpowiednie dla domeny, inne dla aplikacji internetowej, a jeszcze inne dla informacji o publicznie ujawnionym oprogramowaniu.

Dla domen i infrastruktury przydatne są m.in. publiczne rekordy DNS, bazy certyfikatów TLS i wyszukiwarki usług internetowych. Dla aplikacji — dokumentacja, publiczne repozytoria kodu, archiwa URL oraz dokumenty udostępniane przez właściciela.

OWASP Web Security Testing Guide

+1

2.3. Normalizacja danych

Wyniki z różnych źródeł często opisują ten sam zasób w odmienny sposób. Przed analizą warto ujednolicić:

• zapis nazw domen i hostów;
• format adresów IP;
• znaczniki czasu i strefy czasowe;
• identyfikatory certyfikatów;
• nazwy technologii i wersji;
• statusy zasobów;
• adresy źródłowe oraz daty pozyskania.

Należy przy tym zachować oryginalną wartość. Normalizacja powinna tworzyć ujednolicony rekord, a nie niszczyć informację potrzebną do późniejszej weryfikacji.

2.4. Korelacja i ocena wiarygodności

Załóżmy, że trzy źródła wskazują na host staging.example.test:

• certyfikat TLS zawiera tę nazwę;
• archiwum internetowe zawiera historyczną stronę;
• publiczna dokumentacja projektu wymienia środowisko testowe.

To silniejsza przesłanka niż pojedynczy wynik z jednej bazy. Nadal jednak nie dowodzi, że host jest obecnie aktywny ani że należy do aktualnej infrastruktury organizacji.

Dla każdego istotnego ustalenia warto przechowywać:

Pole	Znaczenie
Obserwacja	Co konkretnie znaleziono
Źródło	Skąd pochodzi informacja
Data pozyskania	Kiedy ją sprawdzono
Data źródłowa	Kiedy informacja została opublikowana lub zarejestrowana, jeśli wiadomo
Potwierdzenie	Jakie inne źródło wspiera ustalenie
Pewność	Wysoka, średnia lub niska
Znaczenie	Dlaczego obserwacja jest istotna dla bezpieczeństwa
Dalsze działanie	Co należy zweryfikować lub poprawić

Zasada analityczna jest prosta: fakt, hipoteza i wniosek muszą być od siebie oddzielone.

3. Rozpoznanie domen i infrastruktury DNS

Domena jest często punktem wyjścia do budowania mapy cyfrowej infrastruktury. Publiczne rekordy DNS mogą ujawniać adresy serwerów, systemy pocztowe, dostawców usług oraz część zależności technicznych.

3.1. Podstawowe typy rekordów DNS

Rekord	Zastosowanie	Znaczenie dla analizy
A	Mapowanie nazwy na IPv4	Identyfikacja adresu docelowego
AAAA	Mapowanie nazwy na IPv6	Wykrycie ekspozycji IPv6
MX	Serwery pocztowe	Rozpoznanie infrastruktury poczty
NS	Serwery autorytatywne DNS	Identyfikacja operatora DNS
TXT	Tekstowe dane domeny	SPF, weryfikacja usług i inne deklaracje
CNAME	Alias nazwy DNS	Identyfikacja zależności od innych nazw
PTR	Mapowanie adresu IP na nazwę	Pomocnicza identyfikacja hosta
CAA	Polityka wystawiania certyfikatów	Ograniczenia dotyczące urzędów certyfikacji

3.2. Praktyczna analiza DNS

Dla własnej domeny lub domeny objętej autoryzacją można użyć narzędzia dig do sprawdzenia podstawowych rekordów:

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com CAA

W tym przykładzie example.com jest domeną zastępczą. Przedstawione zapytania służą do odczytu publicznych danych DNS; nie skanują portów ani nie sprawdzają podatności aplikacji.

Podczas interpretacji należy zwrócić uwagę na:

• sekcję odpowiedzi;
• serwery, które udzielają odpowiedzi;
• wartości TTL;
• kody odpowiedzi DNS;
• zgodność rekordów A i AAAA;
• zgodność konfiguracji pocztowej z wymaganiami organizacji.

Wartość TTL określa czas, przez jaki odpowiedź może być przechowywana w pamięci podręcznej. Nie jest bezpośrednim wskaźnikiem bezpieczeństwa.

3.3. SPF, DKIM i DMARC — OSINT poczty elektronicznej

Publiczne rekordy DNS mogą ujawniać politykę pocztową domeny.

• SPF określa, które serwery są upoważnione do wysyłania poczty w imieniu domeny.
• DKIM wykorzystuje podpisy kryptograficzne do weryfikacji integralności wiadomości i powiązania podpisu z domeną.
• DMARC określa politykę obsługi wiadomości, których wyniki uwierzytelnienia nie spełniają wymaganych warunków, oraz umożliwia raportowanie.

Z punktu widzenia obrony warto sprawdzić, czy domena ma prawidłowo skonfigurowane rekordy, czy polityka DMARC odpowiada dojrzałości organizacji i czy nie istnieją niezamierzone wyjątki.

Sam fakt istnienia rekordu SPF lub DMARC nie dowodzi prawidłowej konfiguracji. Znaczenie ma jego treść, zgodność z rzeczywistymi nadawcami oraz zachowanie całego systemu pocztowego.

3.4. Subdomeny i zapomniane zasoby

Subdomeny mogą wskazywać na różne komponenty organizacji:

• www — główna witryna;
• api — interfejs programistyczny;
• mail — usługi pocztowe;
• dev lub staging — środowiska nieprodukcyjne;
• vpn — punkt dostępu zdalnego;
• admin — potencjalny panel administracyjny.

Są to jedynie przykłady konwencji nazewniczych, a nie dowód istnienia konkretnych usług.

Szczególnie ważne jest wykrywanie zasobów osieroconych: nazw, które nadal wskazują na zewnętrzną usługę, mimo że organizacja przestała jej używać. W określonych konfiguracjach może to prowadzić do ryzyka przejęcia subdomeny (subdomain takeover).

Właściwa procedura obronna polega na potwierdzeniu własności zasobu, sprawdzeniu aktualnego rekordu DNS, ustaleniu, czy usługa docelowa nadal jest przypisana do organizacji, oraz usunięciu lub naprawieniu nieaktualnego powiązania.

Nie należy próbować rejestrować obcych zasobów ani przejmować usług w celu potwierdzenia hipotezy bez jednoznacznego upoważnienia.

4. Wyszukiwarki, archiwa i publiczne repozytoria

4.1. Rekonesans w wyszukiwarkach

Wyszukiwarki mogą ujawniać informacje, które zostały opublikowane przypadkowo, pozostały po migracji serwisu albo nie zostały usunięte z indeksu po zmianie konfiguracji.

OWASP WSTG zaleca analizowanie zarówno treści indeksowanych bezpośrednio z witryny, jak i informacji publikowanych w zewnętrznych źródłach.

OWASP Web Security Testing Guide

+1

Przy audycie własnej domeny można stosować operatory wyszukiwania:

site:example.com
site:example.com filetype:pdf
site:example.com inurl:api
site:example.com intitle:documentation

Operatory pozwalają zawęzić wyniki, ale nie zapewniają kompletnego spisu zasobów. Wyniki zależą od indeksowania, czasu ostatniego odświeżenia i mechanizmów wyszukiwarki.

Co analizować?

• dokumentację techniczną i pliki PDF;
• publiczne kopie instrukcji administracyjnych;
• komunikaty błędów;
• historyczne adresy paneli;
• dane kontaktowe i informacje o stosie technologicznym;
• pliki, które miały być dostępne wyłącznie wewnętrznie.

Nie należy pobierać ani wykorzystywać znalezionych haseł, tokenów lub kluczy. W przypadku ujawnienia sekretu właściwym działaniem jest ograniczenie dostępu do dowodu, zgłoszenie problemu właścicielowi i unieważnienie sekretu.

4.2. robots.txt i sitemap.xml

Plik robots.txt może wskazywać ścieżki, których właściciel nie chce udostępniać robotom wyszukiwarek. Nie jest jednak mechanizmem kontroli dostępu. Google wyraźnie wskazuje, że sam robots.txt nie gwarantuje ukrycia strony w wynikach wyszukiwania.

Google for Developers

Podczas audytu warto sprawdzić:

• czy robots.txt nie ujawnia zbędnych informacji o strukturze serwisu;
• czy sitemap.xml zawiera tylko zamierzone publiczne adresy;
• czy prywatne zasoby są chronione uwierzytelnianiem;
• czy stare adresy nie pozostają publicznie dostępne;
• czy treści przeznaczone do wyłączenia z indeksowania zostały odpowiednio zabezpieczone.

Ważne rozróżnienie: usunięcie adresu z mapy strony nie zabezpiecza zasobu, jeśli nadal można go pobrać bez autoryzacji.

4.3. Archiwa internetowe i historyczne adresy URL

Internet Archive oraz inne archiwa mogą przechowywać historyczne wersje publicznych stron. Z punktu widzenia rekonesansu są przydatne do ustalania, jakie funkcje, ścieżki i informacje były wcześniej ujawniane.

Przykładowe pytania analityczne:

• Czy dawniej istniał panel administracyjny pod innym adresem?
• Czy aplikacja używała innego endpointu API?
• Czy strona ujawniała nazwę wersji oprogramowania?
• Czy dokumentacja wskazywała na usuniętą funkcję?
• Czy publiczna dokumentacja nadal opisuje nieaktualną architekturę?

Historyczny adres URL nie jest dowodem, że endpoint nadal istnieje. Zanim zostanie wykorzystany w testach dynamicznych, trzeba potwierdzić, że zasób jest aktualny i mieści się w zakresie autoryzacji.

4.4. Publiczne repozytoria kodu

Publiczne repozytoria mogą ujawniać szczegóły implementacji, zależności, nazwy usług i konfiguracje. OWASP zwraca uwagę, że komentarze HTML i kod JavaScript mogą zawierać niezamierzone informacje o architekturze, endpointach lub sekretach.

OWASP Web Security Testing Guide

W audycie własnej organizacji warto kontrolować:

• pliki konfiguracyjne;
• manifesty zależności;
• skrypty wdrożeniowe;
• dokumentację infrastruktury;
• przykładowe pliki .env;
• historię zmian i usunięte pliki;
• odwołania do wewnętrznych usług;
• przypadkowo opublikowane dane dostępowe.

Jeżeli sekret trafił do historii repozytorium, samo usunięcie go z najnowszego commita nie wystarcza. Należy unieważnić sekret, sprawdzić jego użycie w logach oraz ocenić potrzebę oczyszczenia historii i ograniczenia dostępu do repozytorium.

5. Narzędzia OSINT — zastosowanie techniczne

5.1. Najważniejsze narzędzia

OWASP Amass

Mapowanie powierzchni ataku, odkrywanie zasobów i korelowanie informacji o domenach. Projekt łączy dane OSINT z metodami rozpoznania infrastruktury.

OWASP Foundation

+1

Zastosowanie: inwentaryzacja domen i kontrola ekspozycji.

Oficjalny projekt

Shodan

Wyszukiwarka informacji o usługach widocznych w Internecie. Analizuje m.in. banery usług, metadane i informacje o urządzeniach.

Shodan Help Center

+1

Zastosowanie: sprawdzanie publicznej ekspozycji własnej infrastruktury.

Otwórz Shodan

Censys

Wyszukiwanie hostów, certyfikatów, usług i właściwości internetowych. Pozwala łączyć dane infrastrukturalne z informacjami o certyfikatach i obserwowanych usługach.

Censys Documentation

Zastosowanie: weryfikacja zewnętrznego obrazu infrastruktury.

Otwórz Censys

crt.sh

Wyszukiwanie publicznych zapisów certyfikatów TLS, w tym nazw wymienionych w certyfikatach.

Zastosowanie: odkrywanie nazw hostów i analiza historii certyfikatów.

Otwórz crt.sh

Maltego

Analiza relacji między domenami, organizacjami, adresami e-mail i innymi encjami. Przydatne do wizualizacji zależności, których nie widać w pojedynczych wynikach wyszukiwania.

OWASP Web Security Testing Guide

Zastosowanie: korelacja danych i budowa grafu powiązań.

Strona projektu

5.2. OWASP Amass — rozpoznanie domen

Amass może zbierać informacje o domenach i mapować zasoby organizacji. Dostępne metody zależą od konfiguracji, źródeł danych i wybranego trybu pracy.

Dla domeny, którą kontrolujesz, przykładowe polecenie w trybie pasywnym wygląda następująco:

amass enum --passive -d example.com -o osint-results.txt

Znaczenie parametrów:

• enum — uruchamia enumerację zasobów.
• --passive — ogranicza pracę do trybu pasywnego.
• -d example.com — określa analizowaną domenę.
• -o osint-results.txt — zapisuje wyniki do pliku.

Amass może korzystać z wielu źródeł danych, a część integracji wymaga konfiguracji kluczy API. Brak wyniku nie oznacza, że zasób nie istnieje. Podobnie znalezienie nazwy nie potwierdza, że host jest obecnie aktywny.

GitHub

+1

5.3. Certyfikaty TLS i Certificate Transparency

Certificate Transparency (CT) jest mechanizmem publicznego rejestrowania informacji o wystawionych certyfikatach TLS. Pozwala kontrolować proces wystawiania certyfikatów i analizować nazwy hostów, które pojawiły się w certyfikatach.

MDN

+1

W kontekście OSINT istotne pola certyfikatu obejmują:

• Subject — podmiot wskazany w certyfikacie;
• Issuer — wystawca certyfikatu;
• Not Before i Not After — okres ważności;
• Subject Alternative Name (SAN) — dodatkowe nazwy, dla których certyfikat został wystawiony;
• algorytm podpisu i klucz publiczny.

Przykładowa procedura:

1. Wyszukaj certyfikaty dla własnej domeny.
2. Zbierz nazwy DNS z pola SAN.
3. Usuń duplikaty i zapisz daty wystawienia.
4. Porównaj wyniki z aktualnym inwentarzem zasobów.
5. Oznacz historyczne lub nieznane nazwy do weryfikacji.
6. Sprawdź, czy nieaktualne rekordy DNS zostały usunięte.

Certyfikat potwierdza określone fakty dotyczące jego wystawienia, ale sam nie dowodzi aktualnej własności ani dostępności hosta.

5.4. Shodan i Censys — obserwacja infrastruktury zewnętrznej

Obie platformy agregują informacje o publicznie osiągalnych usługach, ale ich wyniki należy traktować jako migawkę określonego momentu.

Przy audycie własnej organizacji analizuj przede wszystkim:

• czy publicznie widoczne są usługi, które powinny być prywatne;
• czy banery ujawniają nadmierne informacje o oprogramowaniu;
• czy znane adresy IP są przypisane do właściwych systemów;
• czy obserwowane usługi odpowiadają aktualnemu inwentarzowi;
• czy certyfikaty i nazwy hostów są zgodne z konfiguracją organizacji.

Ograniczenie: adres IP może należeć do CDN, hostingu współdzielonego lub dostawcy chmurowego. Nie należy przypisywać organizacji każdego hosta, który znajduje się pod tym samym adresem. Rekordy mogą też być nieaktualne.

Shodan Help Center

+1

6. Analiza informacji o aplikacji WWW

Po zidentyfikowaniu domen i hostów kolejnym krokiem jest zbadanie, jakie informacje udostępnia sama aplikacja. Celem nie jest automatyczne wyszukiwanie podatności, lecz sporządzenie technicznego obrazu serwisu.

6.1. Fingerprinting technologii

Fingerprinting polega na ustalaniu, jakie technologie mogą obsługiwać daną aplikację. Źródłami są między innymi nagłówki HTTP, struktura HTML, nazwy plików statycznych, publiczna dokumentacja i charakterystyczne wzorce odpowiedzi.

Przykładowe nagłówki:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: nginx
X-Powered-By: PHP

To przykład hipotetyczny. Nagłówki mogą być usuwane, zmieniane lub generowane przez proxy, dlatego nie zawsze identyfikują rzeczywisty backend.

Podczas analizy należy rozróżniać:

• technologię potwierdzoną bezpośrednio;
• technologię prawdopodobną;
• technologię wskazaną wyłącznie przez pośredni sygnał;
• wersję, której nie da się wiarygodnie ustalić.

Jeśli aplikacja wygląda na opartą na WordPressie, nie oznacza to automatycznie, że wszystkie widoczne komponenty należą do tej platformy. Frontend może być oddzielony od backendu, a ruch może przechodzić przez CDN lub reverse proxy.

6.2. Nagłówki HTTP i ujawnianie informacji

W ramach audytu własnej witryny warto sprawdzić, czy odpowiedzi nie ujawniają zbędnych danych:

• dokładnych wersji serwera;
• szczegółów środowiska wykonawczego;
• ścieżek systemowych;
• wewnętrznych identyfikatorów;
• danych diagnostycznych;
• stosów wywołań i szczegółów wyjątków.

Należy jednak zachować proporcje. Sam nagłówek Server nie jest zwykle wystarczającym dowodem poważnej podatności. Jego znaczenie rośnie, jeśli ujawnia informacje pomagające potwierdzić nieaktualny komponent lub wskazuje na inne problemy z konfiguracją.

6.3. Analiza kodu HTML i JavaScript

Kod dostarczany przeglądarce jest dostępny użytkownikowi i może ujawniać elementy architektury aplikacji.

Podczas przeglądu własnego serwisu zwróć uwagę na:

• komentarze HTML;
• mapy źródłowe JavaScript;
• adresy API;
• nazwy środowisk;
• identyfikatory usług;
• niepotrzebne dane diagnostyczne;
• klucze dostępowe i tokeny.

Nie każdy klucz widoczny we frontendzie jest sekretem. Przykładowo identyfikator publicznej aplikacji może być przeznaczony do ujawnienia, a klucz API może być ograniczony do konkretnych domen i operacji. Klucze dające nieograniczony dostęp do prywatnych zasobów nie powinny być umieszczane w kodzie klienta.

Jeśli znajdziesz potencjalny sekret, nie używaj go do testowania uprawnień bez odpowiedniego upoważnienia. Zapisz minimalny dowód i uruchom procedurę unieważnienia lub rotacji.

6.4. Mapowanie endpointów

Endpointy to punkty, przez które aplikacja udostępnia funkcje i dane. Można je identyfikować na podstawie dokumentacji, linków, plików JavaScript, map witryny i archiwów historycznych.

Wyniki warto podzielić na:

• endpointy publiczne;
• endpointy wymagające uwierzytelnienia;
• endpointy administracyjne;
• endpointy integracyjne;
• endpointy historyczne;
• endpointy o niepotwierdzonym statusie.

W fazie pasywnej samo znalezienie adresu nie powinno automatycznie prowadzić do wywoływania go. Najpierw trzeba ustalić, czy znajduje się w zakresie i czy jego testowanie zostało zatwierdzone.

7. Analiza osób, organizacji i cyfrowego śladu

OSINT nie dotyczy wyłącznie infrastruktury. Publiczne informacje o organizacji, strukturze zespołów i procesach biznesowych mogą mieć znaczenie dla modelowania zagrożeń.

W zastosowaniach obronnych analizuje się przede wszystkim informacje związane z bezpieczeństwem organizacji, a nie prywatne życie jej pracowników.

7.1. Publiczne informacje o organizacji

Przydatne źródła obejmują:

• oficjalną stronę i dokumentację;
• publiczne ogłoszenia o pracę;
• raporty roczne i dokumenty przetargowe;
• publiczne repozytoria projektów;
• komunikaty o incydentach;
• dokumentację integracji;
• informacje o dostawcach technologii.

Ogłoszenia o pracę mogą wskazywać, że organizacja używa określonego środowiska chmurowego, systemu ERP albo platformy CMS. Jest to jednak przesłanka, a nie pewność, że technologia jest obecnie używana w produkcji.

7.2. Adresy e-mail i struktura tożsamości

Domena pocztowa i publiczne dane kontaktowe mogą pomóc ustalić, jak organizacja zarządza komunikacją. W audycie defensywnym warto analizować:

• czy adresy służbowe są publikowane tylko tam, gdzie jest to potrzebne;
• czy organizacja stosuje SPF, DKIM i DMARC;
• czy istnieją jasne kanały zgłaszania phishingu;
• czy konta uprzywilejowane są odseparowane od zwykłych kont użytkowników;
• czy publiczna dokumentacja nie ujawnia procedur odzyskiwania dostępu.

Nie należy wykorzystywać takich informacji do nękania osób, podszywania się pod pracowników ani pozyskiwania dostępu poprzez manipulację. Testy socjotechniczne wymagają osobnego zakresu i wyraźnego upoważnienia.

7.3. Weryfikacja źródeł

Każda informacja o osobie lub organizacji powinna mieć określone pochodzenie i poziom pewności.

W praktyce:

• źródło pierwotne jest zwykle lepsze od anonimowego powtórzenia;
• data publikacji nie zawsze jest datą aktualności informacji;
• zgodność kilku źródeł zwiększa wiarygodność, ale nie gwarantuje prawdziwości;
• brak informacji nie jest dowodem, że dane zdarzenie nie wystąpiło.

W raporcie OSINT należy unikać kategorycznych stwierdzeń, jeżeli dostępne dane wspierają jedynie hipotezę.

8. Praktyczne ćwiczenie — pasywny rekonesans własnej domeny

Poniższe ćwiczenie pozwala przeprowadzić podstawową analizę OSINT bez skanowania portów, prób logowania ani testowania podatności. Używaj własnej domeny lub zasobów, do których masz upoważnienie.

8.1. Procedura krok po kroku

01

Ustal domenę bazową

Zapisz domenę organizacji, potwierdź jej własność i określ zakres analizy.

02

Sprawdź publiczne rekordy DNS

Zbierz rekordy A, AAAA, MX, NS, TXT i CAA.

03

Przejrzyj Certificate Transparency

Zidentyfikuj nazwy hostów z certyfikatów i porównaj je z inwentarzem.

04

Przeszukaj indeksy i archiwa

Sprawdź publiczne dokumenty, stare adresy URL i historyczne wersje strony.

05

Przejrzyj technologie

Zapisz widoczne technologie i odróżnij potwierdzone fakty od przypuszczeń.

06

Skoreluj wyniki

Usuń duplikaty, zanotuj daty i oznacz niepotwierdzone zasoby.

07

Opracuj zalecenia

Przypisz właściciela działania, priorytet i sposób weryfikacji poprawki.

8.2. Szablon rejestru OSINT

Każdy znaleziony zasób zapisuj w ustrukturyzowanej formie:

Pole	Przykład
Identyfikator	OSINT-001
Zasób	staging.example.com
Typ	Subdomena
Źródło	Publiczny zapis certyfikatu
Data obserwacji	Data przeprowadzenia analizy
Aktualność	Niepotwierdzona
Pewność przypisania	Średnia
Potencjalne ryzyko	Możliwe zapomniane środowisko
Działanie	Weryfikacja w inwentarzu organizacji

Przykład jest fikcyjny. Sam wpis w rejestrze nie oznacza wykrycia podatności — wskazuje obszar wymagający weryfikacji.

8.3. Jak ocenić jakość rekonesansu?

Dobra analiza OSINT powinna spełniać następujące warunki:

• posiada jasno określony cel;
• dokumentuje źródła i daty pozyskania danych;
• rozróżnia dane aktualne od historycznych;
• usuwa duplikaty i weryfikuje najważniejsze ustalenia;
• uwzględnia granice własności i autoryzacji;
• nie gromadzi nadmiarowych danych osobowych;
• kończy się konkretnymi zaleceniami obronnymi.

9. Jak wykorzystać OSINT do poprawy bezpieczeństwa?

Rekonesans ma największą wartość wtedy, gdy jego wyniki przekładają się na konkretne działania.

Ustalenie	Zalecane działanie obronne
Nieznana subdomena	Zweryfikować właściciela i status w inwentarzu
Nieaktualny rekord DNS	Usunąć lub poprawić, po sprawdzeniu zależności
Certyfikat dla nieznanego hosta	Potwierdzić przeznaczenie i uprawnienia do zasobu
Publiczna dokumentacja techniczna zawiera nadmiarowe informacje	Ograniczyć publikację i sprawdzić kopie historyczne
Sekret w repozytorium	Unieważnić, przeanalizować użycie i poprawić zarządzanie sekretami
Ujawniona wersja komponentu	Potwierdzić wersję, podatności i status poprawek
Publicznie dostępny panel administracyjny	Ocenić wymagania dostępu i ograniczyć ekspozycję
Niespójna konfiguracja poczty	Zweryfikować SPF, DKIM, DMARC i przepływy pocztowe

Warto ustanowić okresowy przegląd powierzchni ataku. Dla organizacji o zmiennej infrastrukturze przydatne jest porównywanie kolejnych pomiarów i generowanie alertów o nowych hostach, certyfikatach oraz usługach.

OSINT nie zastępuje monitoringu infrastruktury ani systemu zarządzania podatnościami. Uzupełnia je o perspektywę zewnętrzną — pokazuje, co można ustalić na podstawie informacji dostępnych poza organizacją.

10. Bezpieczeństwo, etyka i ograniczenia prawne

Publiczna dostępność danych nie oznacza nieograniczonego prawa do ich wykorzystywania. W Polsce należy uwzględniać m.in. ochronę danych osobowych, prawa do prywatności, przepisy dotyczące nieuprawnionego dostępu do systemów oraz warunki korzystania z usług i baz danych.

Przed rozpoczęciem rekonesansu technicznego:

1. Zdefiniuj zakres i cel.
2. Potwierdź upoważnienie do działań aktywnych.
3. Ogranicz zbieranie danych do niezbędnego minimum.
4. Nie próbuj wykorzystywać znalezionych poświadczeń.
5. Nie wykonuj destrukcyjnych testów w ramach samego OSINT.
6. Zabezpiecz materiały dowodowe.
7. Zgłaszaj ujawnione sekrety i błędne konfiguracje właściwemu właścicielowi.

Szczególną ostrożność należy zachować wobec danych osobowych i informacji dotyczących prywatnych osób. Audyt bezpieczeństwa organizacji nie powinien przekształcać się w nieuzasadnione profilowanie pracowników.

11. Źródła techniczne i dokumentacja

Poniższe materiały stanowią dobre punkty odniesienia do dalszej nauki i opracowywania procedur:

OWASP Web Security Testing Guide

Metodyka zbierania informacji, identyfikacji powierzchni ataku i testowania aplikacji WWW.

OWASP Amass

Mapowanie infrastruktury i odkrywanie zasobów organizacji.

MITRE ATT&CK — Reconnaissance

Taktyki i techniki rozpoznania stosowane przez przeciwników.

Shodan Help Center

Dokumentacja wyszukiwania i interpretacji danych o usługach internetowych.

Censys Platform — Quick Start

Praca z danymi hostów, certyfikatów i publicznych usług.

Google Search Central — robots.txt

PODSUMOWANIE

Rekonesans OSINT to jeden z najważniejszych etapów analizy cyberbezpieczeństwa, ponieważ pozwala zidentyfikować publicznie dostępne informacje o organizacji, jej infrastrukturze IT oraz potencjalnych punktach ekspozycji. Prawidłowo przeprowadzony umożliwia wykrycie błędów konfiguracyjnych, ujawnionych zasobów, nieaktualnych usług i informacji, które mogą ułatwić atakującemu przygotowanie kolejnych etapów operacji.

Największą wartością OSINT nie jest ilość zebranych danych, lecz umiejętność ich weryfikacji, korelacji i przełożenia na konkretne wnioski dotyczące ryzyka. Informacja znaleziona w jednym źródle nie zawsze oznacza podatność, dlatego każdy wynik wymaga oceny kontekstu i potwierdzenia.

Z perspektywy specjalisty cyberbezpieczeństwa OSINT powinien być stałym elementem zarządzania powierzchnią ataku (Attack Surface Management), audytów bezpieczeństwa oraz testów penetracyjnych prowadzonych w ramach określonego zakresu i upoważnienia.

Warto pamiętać, że skuteczna obrona zaczyna się od wiedzy o tym, co można znaleźć na temat naszej organizacji w publicznej przestrzeni cyfrowej. Regularna analiza DNS, certyfikatów, publicznych repozytoriów, usług internetowych i ujawnionych informacji pozwala ograniczyć ekspozycję oraz szybciej reagować na potencjalne zagrożenia.

Na HackerStop.pl będziemy rozwijać temat OSINT również od strony praktycznej — od analizy rekordów DNS i certyfikatów TLS, przez narzędzia takie jak Shodan i Amass, aż po wykrywanie niezamierzonego ujawnienia informacji w aplikacjach internetowych.

Poznaj swoją powierzchnię ataku, zanim wykorzysta ją ktoś inny.