Pentest infrastruktury: zewnętrzna powierzchnia ataku, sieć wewnętrzna, Active Directory i realna eskalacja

Pentest infrastruktury odpowiada na pytanie, co realnie może zrobić atakujący mając dostęp do internetu, VPN, sieci biurowej albo pojedynczego konta. Sama lista otwartych portów i CVE nie wystarcza. Trzeba ustalić, które usługi są osiągalne, które błędy są wykorzystywalne, gdzie brakuje segmentacji i czy pojedyncza słabość może doprowadzić do eskalacji.

W wielu organizacjach infrastruktura rośnie latami. Zostają stare panele administracyjne, tymczasowe subdomeny, usługi wystawione „na chwilę”, wyjątki firewall, konta serwisowe, przestarzałe systemy i konfiguracje, których nikt nie dotyka, bo „działa”. Pentest porządkuje ten obraz z perspektywy atakującego.

Zewnętrzna powierzchnia ataku

Test zewnętrzny zaczyna się od mapowania tego, co firma pokazuje światu: domeny, subdomeny, adresacje IP, usługi, certyfikaty, panele logowania, VPN, poczta, DNS, systemy helpdesk, aplikacje testowe, środowiska staging, storage i integracje. To etap, w którym często znajdują się rzeczy zapomniane.

Największą wartość ma nie sama lista hostów, ale decyzja, co z nimi zrobić. Czy panel powinien być publiczny? Czy dostęp do VPN ma MFA? Czy stary host nadal jest potrzebny? Czy subdomena wskazuje na przejęty zasób? Czy TLS i konfiguracja poczty nie obniżają bezpieczeństwa organizacji?

Walidacja podatności, nie kopiowanie wyniku skanera

Automatyczny skaner może wskazać setki alertów. Część będzie prawdziwa, część nieistotna, część fałszywie pozytywna. Rola pentestera polega na walidacji wpływu. Czy podatność jest dostępna z internetu? Czy wymaga uwierzytelnienia? Czy konfiguracja ogranicza wykorzystanie? Czy exploit prowadzi do odczytu danych, przejęcia konta, wykonania kodu, czy tylko do informacji o wersji?

Sieć wewnętrzna: co dzieje się po wejściu do środka

Wewnętrzny pentest zakłada, że atakujący ma pewien punkt zaczepienia: dostęp do gniazdka sieciowego, Wi-Fi, VPN, stacji roboczej, konta użytkownika albo segmentu aplikacyjnego. Celem nie jest „narobienie szkód”, tylko sprawdzenie, czy mechanizmy obronne ograniczają ruch i eskalację.

Typowe obszary to enumeracja usług, konfiguracja SMB, dostępne udziały, hasła w plikach, podatne usługi wewnętrzne, brak segmentacji, niepotrzebne uprawnienia administracyjne, podatności w panelach intranetowych, słabe polityki haseł, brak hardeningu i ścieżki eskalacji w Active Directory.

Active Directory: centrum ciężkości wielu firm

Active Directory jest często najważniejszym elementem infrastruktury. Jeżeli atakujący uzyska kontrolę nad AD, może uzyskać dostęp do stacji, serwerów, danych, aplikacji i procesów administracyjnych. Dlatego test AD powinien obejmować nie tylko hasła, ale również delegacje, ścieżki uprawnień, konta serwisowe, Kerberos, grupy uprzywilejowane, GPO, stare obiekty, lokalnych administratorów i relacje z systemami zewnętrznymi.

W raporcie szczególnie ważne jest pokazanie ścieżki ataku. Przykład: użytkownik domenowy ma dostęp do udziału z plikiem konfiguracyjnym, plik zawiera hasło konta serwisowego, konto ma zbyt szerokie uprawnienia na serwerze aplikacyjnym, a serwer pozwala na eskalację do administratora lokalnego. Pojedynczy element może wyglądać średnio groźnie, ale łańcuch jest poważny.

Segmentacja i ograniczenie skutków incydentu

Dużo organizacji inwestuje w narzędzia ochronne, ale zapomina o prostej zasadzie: po kompromitacji jednego hosta atakujący nie powinien swobodnie chodzić po całej sieci. Segmentacja, ACL, zasady firewall, ograniczenie RDP/SMB/WinRM/SSH, oddzielenie środowisk administracyjnych i monitoring ruchu lateralnego często mają większy wpływ na bezpieczeństwo niż kolejny panel z alertami.

Pentest infrastruktury pozwala sprawdzić, czy segmentacja istnieje tylko na diagramie, czy działa w praktyce. Tester próbuje wykonać konkretne przejścia między segmentami i opisuje, co należałoby zablokować albo monitorować.

Przykładowy fragment techniczny

# Przykład opisu w raporcie, bez danych klienta:
Host: 10.20.14.32
Usługa: SMB
Problem: udział "deploy" dostępny dla zwykłych użytkowników domenowych
Wpływ: odczyt pliku konfiguracyjnego z hasłem konta serwisowego
Rekomendacja: ograniczyć ACL, rotować sekret, przenieść sekret do vaulta, monitorować dostęp

Dobry raport nie zatrzymuje się na „znaleziono hasło w pliku”. Pokazuje, gdzie hasło działało, jakie miało uprawnienia, czy było współdzielone, jak mogło zostać wykorzystane i jak zapobiec powtórzeniu problemu.

Jak priorytetyzować poprawki

Nie wszystko da się naprawić jednego dnia. Dlatego raport powinien grupować zalecenia: szybkie zamknięcia ekspozycji publicznej, krytyczne aktualizacje, ograniczenie dostępu administracyjnego, rotacja sekretów, twarde zmiany architektoniczne i tematy monitoringu. Priorytet powinien wynikać z realnej ścieżki ataku, nie tylko z wyniku CVSS.

Co odróżnia dobry pentest infrastruktury od skanu podatności

Skan podatności odpowiada na pytanie, co narzędzie potrafi wykryć. Pentest infrastruktury odpowiada na pytanie, co atakujący może zrobić z wykrytym błędem. Dlatego weryfikujemy nie tylko porty i wersje usług, ale też ekspozycję paneli, błędne konfiguracje, możliwość eskalacji, segmentację, dostęp do udziałów, ryzyko przejęcia kont i wpływ na ciągłość działania.

Typowe obszary wysokiego ryzyka

• usługi administracyjne dostępne z internetu lub zbyt szeroko w sieci wewnętrznej,
• SMB, RDP, VPN, poczta, DNS, panele administracyjne i systemy legacy,
• słabe hasła, brak MFA, błędy konfiguracji Active Directory,
• nadmiarowe uprawnienia kont serwisowych i współdzielone poświadczenia,
• brak segmentacji między stacjami roboczymi, serwerami i systemami krytycznymi,
• podatności znane, ale bez potwierdzenia realnego wpływu w środowisku klienta.

Efektem testu powinna być nie tylko lista CVE, ale mapa priorytetów: co wystawia organizację na największe ryzyko, które poprawki są szybkie, które wymagają projektu infrastrukturalnego i które ryzyka trzeba monitorować do czasu pełnej naprawy.