Wprowadzenie do problemu / definicja
CISA opublikowała analizę dwóch równoległych ćwiczeń red team przeprowadzonych w organizacjach należących do sektorów infrastruktury krytycznej. W obu przypadkach zespół testowy osiągnął pełną kompromitację domeny, uzyskał dostęp do kluczowych systemów biznesowych oraz zasobów chmurowych. Najważniejszy wniosek nie dotyczy jednak wyłącznie zastosowanych technik ofensywnych, lecz różnic w skuteczności detekcji, koordynacji operacyjnej i zdolności do szybkiego reagowania.
Raport pokazuje, że nawet organizacje dysponujące nowoczesnymi narzędziami ochrony mogą przegrać z dobrze przygotowanym przeciwnikiem, jeśli zawiodą procesy, konfiguracja i współpraca pomiędzy zespołami bezpieczeństwa, IT oraz OT.
W skrócie
- W obu organizacjach red team doprowadził do pełnej kompromitacji środowiska.
- W pierwszym podmiocie aktywność ofensywna pozostała praktycznie niewykryta do końca ćwiczeń.
- W drugim organizacja szybciej wykryła incydent i ograniczyła swobodę działania atakujących, ale nie zdołała zatrzymać ich przed osiągnięciem krytycznych celów.
- Kluczowe problemy dotyczyły m.in. ADCS, SCCM, poświadczeń, tożsamości chmurowych oraz ścieżek prowadzących do środowisk OT.
Kontekst / historia
Opisane przypadki dotyczą dwóch organizacji z różnych sektorów infrastruktury krytycznej. Pierwsza działała w obszarze usług i obiektów rządowych, druga w sektorze wodno-kanalizacyjnym. CISA podkreśliła, że w obu ćwiczeniach zastosowano porównywalne techniki i procedury ofensywne, co pozwoliło ocenić przede wszystkim dojrzałość procesów bezpieczeństwa, a nie tylko obecność pojedynczych luk technicznych.
Sprawa wpisuje się w szerszy trend obserwowany w środowiskach enterprise i ICS. Nawet przy wdrożonych rozwiązaniach EDR, segmentacji sieci i monitoringu organizacje nadal przegrywają z przeciwnikiem, jeśli nie mają uporządkowanych procedur eskalacji, nie redukują fałszywych alarmów i nie zapewniają pełnej widoczności między różnymi domenami operacyjnymi. Raport CISA podkreśla, że prawdziwe ryzyko wynika często z łańcucha zależności między błędną konfiguracją, słabym zarządzaniem poświadczeniami i nieskutecznym incident response.
Analiza techniczna
W organizacji A punktem wejścia była aplikacja webowa pozostawiona z domyślnymi danymi uwierzytelniającymi. Po uzyskaniu dostępu red team mógł wysyłać wiadomości phishingowe z zaufanego wewnętrznego adresu, co doprowadziło do przejęcia czterech stacji roboczych. Następnie wykorzystano błędnie skonfigurowany szablon Active Directory Certificate Services podatny na scenariusz ESC1. Taka konfiguracja umożliwia użytkownikowi o niskich uprawnieniach uzyskanie certyfikatów dla innych kont, w tym uprzywilejowanych, co otwiera drogę do szybkiej eskalacji uprawnień i przejęcia domeny.
Po osiągnięciu dominacji w środowisku lokalnym zespół przeszedł do zasobów chmurowych i systemów wrażliwych. Szczególnie alarmujące było to, że atakujący mogli czytać korespondencję personelu SOC, aby sprawdzić, czy ich działania zostały wykryte. Organizacja była jednocześnie przeciążona dużą liczbą fałszywych alarmów, a część zdarzeń związanych z rzeczywistą aktywnością red teamu została uznana za nieistotną. Problem pogłębiała fragmentacja operacyjna, obejmująca wiele odrębnych SOC-ów, różne rozwiązania EDR i brak wspólnej widoczności między zespołami.
W organizacji B jedną z kluczowych słabości było hasło zapisane jawnie w pliku XML na punkcie dystrybucyjnym SCCM. Poświadczenia powiązanego konta usługowego pozwoliły uzyskać wysokie uprawnienia względem kontrolera domeny, a następnie przeprowadzić atak DCSync i pozyskać hash konta krbtgt. To z kolei umożliwiło tworzenie Golden Ticketów i podszywanie się pod użytkowników w całej domenie.
Kolejny wektor dotyczył ścieżki dostępu do środowiska OT. Red team odnalazł pliki RDP wskazujące na bastion host, a następnie wykorzystał poświadczenia FTP znalezione na jump serwerze do połączenia SSH z hostem pośredniczącym. Choć brak dostępu wychodzącego do internetu ograniczył możliwość pełnego rozwinięcia działań, a host został objęty kwarantanną, sama możliwość dojścia do segmentu operacyjnego stanowiła istotne ryzyko.
Obie organizacje miały również wspólny problem w obszarze cloud security: brak Conditional Access dla workload identities. W praktyce oznacza to, że aplikacje i konta usługowe z szerokimi uprawnieniami do Microsoft Graph mogą omijać część mechanizmów ochronnych stosowanych wobec użytkowników interaktywnych. CISA wskazała, że dzięki temu red team uzyskał dostęp do poczty elektronicznej w obu środowiskach.
W organizacji A dodatkowo znaleziono poświadczenia AWS IAM zapisane w katalogach domowych użytkowników, bez terminu wygaśnięcia. Był to przykład trwałego ryzyka wynikającego z niekontrolowanego składowania sekretów. W organizacji B wykorzystano natomiast Seamless SSO. Dzięki biletom Kerberos pozyskanym przez DCSync możliwe było uwierzytelnienie do Azure bez znajomości jawnego hasła użytkownika. Zespół odnalazł wyłączone konto synchronizowane z AD, które było właścicielem aplikacji posiadającej szerokie uprawnienia do skrzynek pocztowych w całym tenancie. Po ponownym włączeniu konta i dodaniu client secret uzyskano zewnętrzny dostęp do poczty całej organizacji.
Konsekwencje / ryzyko
Opisane scenariusze pokazują, że pełna kompromitacja domeny pozostaje jednym z najgroźniejszych skutków błędów konfiguracyjnych i słabego zarządzania tożsamością. Atakujący, którzy uzyskają dostęp do ADCS, SCCM, kont uprzywilejowanych lub konta krbtgt, mogą przejść od incydentu punktowego do trwałej, trudnej do wykrycia obecności w środowisku.
Ryzyko rośnie szczególnie w organizacjach łączących klasyczne IT z systemami OT. Nawet jeśli segment operacyjny nie zostanie bezpośrednio zakłócony, sama możliwość dotarcia do bastionów, jump hostów czy kanałów administracyjnych może stworzyć podstawę do przyszłych działań destrukcyjnych, sabotażowych lub ransomware. W sektorach infrastruktury krytycznej oznacza to potencjalne skutki biznesowe, regulacyjne i operacyjne, włącznie z ryzykiem przerw w świadczeniu usług.
Przypadek organizacji A pokazuje również, że nadmiar alertów może być równie groźny jak ich brak. Gdy SOC działa w warunkach chronicznego szumu, realne sygnały ataku giną w masie zdarzeń, a personel traci zdolność do prawidłowej priorytetyzacji incydentów. To problem nie tylko technologiczny, ale również procesowy i architektoniczny.
Rekomendacje
Organizacje powinny rozpocząć od przeglądu konfiguracji Active Directory Certificate Services, zwłaszcza szablonów certyfikatów umożliwiających nadużycia typu ESC1. Należy ograniczyć możliwość samodzielnego określania podmiotu certyfikatu, zweryfikować listy uprawnień enrollment oraz monitorować nietypowe żądania certyfikatów dla kont uprzywilejowanych.
Równie ważne jest traktowanie SCCM i podobnych platform do zarządzania końcówkami jako zasobów Tier 0. W praktyce oznacza to ścisłą kontrolę dostępu, separację administracji, monitoring artefaktów konfiguracyjnych oraz zakaz przechowywania jawnych poświadczeń na udziałach sieciowych i serwerach dystrybucyjnych.
W obszarze tożsamości chmurowej należy włączyć Conditional Access dla workload identities, przeprowadzić audyt uprawnień aplikacyjnych do Microsoft Graph, usunąć zbędne sekrety i certyfikaty oraz wdrożyć procedury szybkiego unieważniania tokenów i rotacji poświadczeń. Istotne jest także wykrywanie anomalii w użyciu API, zwłaszcza nietypowych wolumenów odczytu poczty i działań wykonywanych przez aplikacje zamiast użytkowników.
- Redukcja fałszywych alarmów i strojenie reguł detekcyjnych.
- Wspólna widoczność między różnymi zespołami bezpieczeństwa.
- Jednoznaczne procedury eskalacji i izolacji hostów.
- Mapowanie krytycznych systemów do właścicieli biznesowych i technicznych.
- Regularne ćwiczenia red team i purple team w środowiskach hybrydowych IT/OT.
W środowiskach wykorzystujących AWS i Azure warto dodatkowo skanować repozytoria, katalogi użytkowników i serwery administracyjne pod kątem pozostawionych kluczy dostępowych, sekretów aplikacyjnych oraz plików konfiguracyjnych zawierających dane uwierzytelniające. Klucze bez daty wygaśnięcia powinny być traktowane jako istotny dług bezpieczeństwa i usuwane priorytetowo.
Podsumowanie
Analiza CISA stanowi ważne ostrzeżenie dla operatorów infrastruktury krytycznej i dużych organizacji hybrydowych. Oba badane podmioty zostały technicznie przełamane, ale skala skutków operacyjnych zależała od dojrzałości detekcji i response. Raport jasno pokazuje, że pojedyncze luki, takie jak domyślne hasła, błędne szablony ADCS, jawne poświadczenia w SCCM czy brak kontroli nad tożsamościami aplikacyjnymi, mogą zostać połączone w pełny łańcuch kompromitacji obejmujący AD, chmurę i potencjalnie OT.
Najważniejszy wniosek jest praktyczny: skuteczna obrona nie zależy wyłącznie od narzędzi, lecz od jakości konfiguracji, widoczności między zespołami oraz zdolności do szybkiego podejmowania decyzji. W realiach współczesnych ataków na infrastrukturę krytyczną właśnie te elementy decydują, czy incydent zostanie zatrzymany na wczesnym etapie, czy przerodzi się w pełną kompromitację środowiska.
Źródła
- CISA Red Team Fully Compromised Two Critical Infrastructure Orgs — https://securityaffairs.com/197901/hacking/cisa-red-team-fully-compromised-two-critical-infrastructure-orgs.html
- CISA Advisory AA26-237A — https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-237a