◆ Case study · Pentest infrastruktury wewnętrznej

Dali nam jedno wejście do sieci.
Wyszliśmy z całą domeną.

Duża organizacja z rozległą siecią wewnętrzną: ponad 200 hostów, kilkanaście technologii serwerowych, systemy wdrażane przez 12 lat. Zaczęliśmy od jednego przyczółka w LAN-ie — bez kont domenowych, bez dokumentacji. Pokazujemy, jak legacy, domyślne hasła i jeden serwer aplikacyjny zamieniają się w przejęcie kontrolera domeny.

TRYB Internal / grey-box POWIERZCHNIA 200+ hostów STANDARD PTES · OWASP · MITRE ATT&CK CZAS DO 1. TRAFIENIA < 2h

200+

Hostów w zasięgu
z jednego przyczółka

Niezależne ścieżki
do uprawnień admina

12 lat

Najstarszy system
wciąż w produkcji

Domain Admin
w jednym engagemencie

„Mamy firewall na brzegu i antywirusa na stacjach. Sieć wewnętrzna jest bezpieczna, bo jest wewnętrzna." To zdanie słyszymy na co drugim spotkaniu otwierającym. I to zdanie jest dokładnie tym, co czyni pentest infrastruktury wewnętrznej tak owocnym.

Obrona większości organizacji jest zbudowana jak skorupka jajka — twarda na zewnątrz, płynna w środku. Gdy tylko napastnik znajdzie się w LAN-ie (phishing, złośliwy załącznik, podrzucony pendrive, niezabezpieczone gniazdko w sali konferencyjnej, dostęp dostawcy), wszystkie założenia o „wewnętrznym = zaufanym" stają się jego sprzymierzeńcem.

Ten engagement był w pełni autoryzowany, z pisemnym zakresem. Dostaliśmy to, co miałby realny napastnik po pierwszym kroku: jeden adres IP w sieci wewnętrznej, bez konta domenowego. Wszystko poniżej jest zanonimizowane — nazwy hostów, domeny i adresy zostały zmienione lub usunięte. Pokazujemy mechanizm i sposób myślenia, nie gotowy przepis na konkretną firmę.

Akt I · Rekonesans

Mapa sieci, której nie miał nawet dział IT

Pierwsze godziny to nie eksploitacja — to inwentaryzacja. Skan całej puli adresowej pokazał skalę, której sam zespół klienta nie był w pełni świadomy: dziesiątki serwerów aplikacyjnych, bazy danych, kontrolery domeny, urządzenia sieciowe i — co najciekawsze — całe pokłady systemów, o których „wszyscy myśleli, że dawno je wyłączono".

recon — mapowanie powierzchni ataku

# Skan puli wewnętrznej (zanonimizowany widok wyników)
$ nmap -sS -sV --open -iL targets.txt
 
[+] 445/tcp   SMB        ~160 hostów (Windows Server + Samba)
[+] 8080/tcp  Apache Tomcat   dziesiątki instancji
[+] 7001/tcp  Oracle WebLogic  kilka hostów
[+] 9200/tcp  Elasticsearch   klaster bez auth?
[+] 4848/tcp  Payara / GlassFish  konsola admina
[+] 9999/tcp  JBoss Remoting  interfejs zarządzania
 
[!] Windows Server 2008 R2 / 2012 — wciąż w produkcji
[!] Samba 3.x na kilku hostach — wiek > dekada
# Wniosek: powierzchnia ataku ≫ to, co firma sądziła, że ma.

Dlaczego to ważne

Najgroźniejszy host to ten, o którym nikt nie pamięta. Systemy „tymczasowo zostawione" sprzed lat nie mają właściciela, nie są patchowane i nie trafiają na listę do aktualizacji — a wciąż mają pełną łączność z resztą sieci. To one najczęściej są pierwszym stopniem.

Akt II · Pierwszy przyczółek

Konsola administracyjna z hasłem „admin"

Mając mapę, priorytetyzujemy. Serwery aplikacyjne Java (Tomcat, WebLogic, Payara, JBoss) to klasyczne „złoto pentestera" — wystawiają konsole administracyjne, które zbyt często stoją na domyślnych albo trywialnych poświadczeniach. Pierwszy przyczółek nie wymagał żadnego exploita. Wymagał zgadnięcia tego, czego nikt nie zmienił.

foothold — default credentials

# Konsola zarządzania serwerem aplikacyjnym
$ login → admin : [puste / domyślne]
[panel] ▸ Witaj w konsoli administracyjnej
 
# Panel pozwala wgrać aplikację (deploy).
# Wgranie aplikacji = wykonanie kodu na serwerze.
$ deploy app.war  →  /shell
[!] wykonanie poleceń w kontekście usługi serwera
[!] usługa działała z wysokimi uprawnieniami systemowymi

Możliwość wgrania własnej aplikacji do serwera aplikacyjnego to w praktyce zdalne wykonanie kodu (RCE). A ponieważ usługi serwerowe nagminnie działają na nadmiarowych uprawnieniach, pierwszy host padł w całości — z dostępem do plików konfiguracyjnych, w których czekała kolejna nagroda.

Akt III · Eskalacja i ruch boczny

Hasła w plaintext, deserializacja i stary, dobry SMB

Z pierwszego serwera nie wynosi się „jednej flagi". Wynosi się materiał do następnego kroku. Pliki konfiguracyjne aplikacji niemal zawsze zawierają poświadczenia do baz danych, kont serwisowych i integracji — zapisane czystym tekstem. A te konta bardzo często mają uprawnienia daleko wykraczające poza jedną aplikację.

lateral movement — łańcuch wektorów

# 1. Sekrety z plików konfiguracyjnych aplikacji
[+] db_user / db_pass w plaintext → dostęp do bazy
[+] konto serwisowe użyte też na innych hostach
 
# 2. Stare serwery aplikacyjne — deserializacja
[+] WebLogic / podatne biblioteki → RCE
 
# 3. Legacy SMB / przestarzałe Windows Server
[+] brak podpisywania SMB → relay poświadczeń
[+] reużycie haseł lokalnego administratora
 
[!] 3 niezależne ścieżki zbiegają się w tym samym celu:
    konta o uprawnieniach w całej domenie.

⚠ Reużycie haseł = mnożnik zasięgu

Pojedyncza podatność rzadko kończy engagement. Kończy go kombinacja: jedno hasło lokalnego administratora powtórzone na 80 stacjach, jedno konto serwisowe z nadmiarowymi uprawnieniami, jeden niepodpisany protokół. Każdy element z osobna wygląda na „średni". Razem dają pełną kontrolę.

Firewall na brzegu sieci nie ma znaczenia,
gdy napastnik już jest w środku.

Akt IV · Trafienie krytyczne

Od konta serwisowego do kontrolera domeny

Active Directory jest sercem większości firmowych sieci — i jednocześnie jej najczulszym punktem. Gdy dysponujemy już poświadczeniami kont serwisowych i kontrolą nad kilkoma hostami, klasyczne techniki nadużycia AD (przejęcie kont uprzywilejowanych, wykorzystanie błędów konfiguracji uprawnień, ścieżki eskalacji w katalogu) prowadzą do najwyższej nagrody.

privilege escalation → Domain Admin

# Łańcuch: serwis → eskalacja → uprawnienia w domenie
operator ▸ wykorzystanie błędnej konfiguracji uprawnień AD
domena   ▸ dostęp do obiektów uprzywilejowanych
 
[CRIT] uzyskano uprawnienia klasy Domain Admin
       ▸ kontrola nad kontrolerem domeny
       ▸ dostęp do bazy haseł całej organizacji
       ▸ możliwość dostępu do dowolnego hosta i danych
 
# Stop. Cel osiągnięty. Dalej już tylko dokumentujemy.

⚠ Severity: Critical — pełna kompromitacja domeny

Uprawnienia Domain Admin oznaczają w praktyce koniec gry: dostęp do każdej stacji, każdego serwera i każdego pliku w organizacji, możliwość wyłączenia mechanizmów obronnych i utrzymania trwałego dostępu. Z perspektywy ryzyka biznesowego to scenariusz, w którym napastnik kontroluje całą infrastrukturę IT firmy.

Co istotne — w żadnym momencie nie potrzebowaliśmy „magicznego" exploita 0-day. Cała ścieżka składała się ze znanych, dawno opisanych słabości: domyślnych haseł, niezałatanego legacy, sekretów w plaintext i błędów konfiguracji AD. To nie jest historia o genialnym napastniku. To historia o normalnej firmowej sieci.

Oś czasu