50 godzin black-box.
Tyle widzi napastnik z Internetu.
Techniczne case study external attack surface: OSINT, fingerprinting, publiczne API, legacy, priorytetyzacja, request/response i plan 30/60/90 dla organizacji.
przykładowo
do triage
logowania
ryzyka
Zanim atakujący dostanie konto, widzi zaskakująco dużo
Black-box bez kont i dokumentacji nie jest „skanem portów”. Dobrze wykonany pokazuje, jak organizacja wygląda z zewnątrz: domeny, stare środowiska, panele logowania, chmura, VPN, SSO, technologie, błędy konfiguracji, wycieki w assetach i miejsca, w których automatyczny scanner krzyczy albo milczy.
Ten case jest zanonimizowany. Nie podajemy domen, adresów IP, fingerprintów klienta ani wyników umożliwiających identyfikację. Pokazujemy strukturę pracy, przykładowe artefakty i to, jak z external attack surface zrobić raport zrozumiały dla zarządu i użyteczny dla IT.
Zasady i higiena testu
Najpierw ustalamy tempo, zakres, domeny, wyjątki, okna czasowe i ścieżkę eskalacji. Black-box bez zasad łatwo zmienić w hałas. Dobry black-box ma być realistyczny, ale kontrolowany.
Nie możesz chronić czegoś, czego nie masz w inwentarzu
Największa wartość często pojawia się przy polu „unknown owners”. IT zna główne systemy, ale nie zawsze zna preview deploymenty, stare panele partnerów, zapomniane subdomeny po migracji albo środowiska testowe, które miały zniknąć po projekcie.
Technologie i wersje bez agresywnego skanowania
Fingerprint nie służy do chwalenia się listą technologii. Służy do priorytetyzacji: co jest stare, co jest publiczne, gdzie jest panel logowania, gdzie może być API, gdzie widać środowisko preview, a gdzie brakuje podstawowych nagłówków bezpieczeństwa.
Najciekawsze rzeczy nie zawsze są CVE
Black-box pokazuje nie tylko podatności techniczne, ale też problem zarządzania powierzchnią ataku: kto jest właścicielem assetu, czy jest monitorowany, czy ma MFA, czy trafia do patch managementu i SIEM.
Publiczny schemat API jako akcelerator ataku
Dla zespołu technicznego to konkret: publiczny OpenAPI nie musi od razu oznaczać wycieku danych, ale jeżeli pokazuje endpointy administracyjne, modele obiektów i środowisko preview, znacząco przyspiesza dalsze testy. Dla biznesu to dowód, że powierzchnia ataku żyje poza główną aplikacją.
Jak z 200 obserwacji zrobić plan działania
To odróżnia pentest od listy z narzędzia. Zarząd nie potrzebuje 80 stron „missing header”. Zarząd potrzebuje wiedzieć, które 5 rzeczy realnie zmniejszy ryzyko przejęcia kont, wycieku danych albo wejścia do sieci.
To lista decyzji, których nikt już nie pamięta.
Artefakty przydatne dla IT i zarządu
Mapa powierzchni
Domeny, subdomeny, usługi HTTP, panele, API, chmura, legacy i właściciele.
Top ryzyka
Krótka lista rzeczy, które realnie zwiększają prawdopodobieństwo incydentu.
Dowody bez szkody
Request/response, screenshoty, nagłówki, fingerprinty i ścieżki reprodukcji bez dotykania danych klientów.
Plan 30/60/90
Co zamknąć natychmiast, co w miesiąc, co w kwartale: MFA, asset ownership, monitoring, patching, exposure reduction.
Co zwykle najbardziej zmniejsza ryzyko
1. Właściciel każdego publicznego assetu. Jeżeli nie wiadomo, kto odpowiada za system, system powinien zostać odcięty albo przejęty przez właściciela.
2. MFA i polityki dla paneli. Każdy panel logowania z Internetu: MFA, rate limiting, monitoring, brak defaultowych komunikatów zdradzających technologię.
3. Oddziel preview/stage od Internetu. Środowiska testowe nie powinny być publiczne bez kontroli dostępu.
4. Stały EASM, nie jednorazowa akcja. Powierzchnia zmienia się po każdym wdrożeniu, migracji i projekcie marketingowym.
Nie wiesz, jak Twoja firma wygląda z Internetu?
Zrobimy kontrolowany black-box i EASM: mapa assetów, walidacja ryzyk, dowody techniczne, priorytety napraw i executive summary dla zarządu.
Zamów test bezpieczeństwa →