Wprowadzenie do problemu / definicja
Red teaming to kontrolowana symulacja działań przeciwnika, której celem jest sprawdzenie, czy organizacja potrafi wykryć, zatrzymać i skutecznie obsłużyć realistyczny incydent bezpieczeństwa. Najnowszy przypadek opisany przez CISA pokazuje, że dwie organizacje z sektora infrastruktury krytycznej mogą posiadać bardzo podobne słabości techniczne, a mimo to osiągnąć zupełnie odmienne wyniki z perspektywy obrony.
Kluczowe znaczenie miały nie tylko same narzędzia bezpieczeństwa, ale przede wszystkim jakość pracy SOC, sposób obsługi alertów, poziom widoczności operacyjnej oraz zdolność do szybkiej izolacji zagrożonych systemów. To ważna lekcja dla podmiotów, które inwestują w technologie ochronne, ale nie zawsze rozwijają procesy i kompetencje zespołów na tym samym poziomie.
W skrócie
- CISA opisała dwa równoległe ćwiczenia red team przeciwko organizacjom infrastruktury krytycznej.
- W obu środowiskach testerzy osiągnęli kompromitację domeny i uzyskali dostęp do wrażliwych zasobów.
- Jedna organizacja nie wykryła praktycznie całego łańcucha ataku.
- Druga zidentyfikowała phishing na wczesnym etapie i szybko odizolowała stacje robocze.
- O skuteczności obrony przesądziły ludzie, procedury i spójność operacyjna, a nie sam zestaw narzędzi.
Kontekst / historia
Przypadek opisany przez CISA jako „A Tale of Two SOCs” dotyczy dwóch organizacji reprezentujących różne sektory infrastruktury krytycznej. Jedna działała w obszarze usług i obiektów rządowych, a druga w sektorze wodno-kanalizacyjnym. Ćwiczenia prowadzono równolegle, stosując zbliżone techniki ofensywne, aby ocenić realną skuteczność zespołów bezpieczeństwa i porównać ich reakcję.
W obu organizacjach red team wykrył zbliżone klasy problemów. Obejmowały one błędne konfiguracje usług katalogowych, nadmierne uprawnienia, poświadczenia przechowywane w jawnej postaci oraz niewystarczającą kontrolę nad tożsamościami i kluczami dostępowymi w środowiskach chmurowych. Taki obraz potwierdza, że nawet dojrzałe organizacje nadal zmagają się z dobrze znanymi, lecz nadal skutecznymi wektorami ataku.
Analiza techniczna
W pierwszej organizacji punkt wejścia stanowiła aplikacja webowa pozostawiona z domyślnymi poświadczeniami dla wbudowanych kont. Dzięki temu red team zdobył możliwość wysyłania wiadomości phishingowych z wewnętrznego adresu, co znacząco zwiększyło wiarygodność kampanii i umożliwiło uruchomienie ładunków na kilku stacjach roboczych.
Następnie wykorzystano domyślną konfigurację Machine Account Quota w Active Directory oraz błędnie skonfigurowany szablon AD CS. Taki zestaw otwiera drogę do eskalacji uprawnień przez nadużycie usług certyfikatów, w tym do uzyskania certyfikatów w imieniu uprzywilejowanych użytkowników. W praktyce pozwala to przejść od zwykłego konta domenowego do pełnej kompromitacji domeny bez używania bardziej widocznych technik.
Po przejęciu kontroli nad tożsamością domenową testerzy uzyskali dostęp do wrażliwych systemów biznesowych. Ułatwiły to jawnie zapisane poświadczenia, w tym dane serwisowe oraz informacje umieszczone w plikach konfiguracyjnych baz danych. Dodatkowym zagrożeniem były statyczne klucze dostępu do AWS skonfigurowane bez terminu wygaśnięcia, co zwiększa ryzyko utrzymywania długotrwałej obecności w środowisku.
W warstwie chmurowej red team przejął również token odświeżania oraz nadużył aplikacji Entra ID z nadmiernymi uprawnieniami. Pozwoliło to uzyskać wgląd w skrzynki pocztowe zespołu bezpieczeństwa i sprawdzić, czy obrońcy zauważyli podejrzaną aktywność. To szczególnie groźny etap operacji, ponieważ daje atakującemu zarówno trwałość dostępu, jak i przewagę informacyjną nad zespołem reagowania.
Najbardziej niepokojącym elementem pierwszego ćwiczenia był niemal całkowity brak wykrycia działań przeciwnika. Alerty generowane przez aktywność red teamu zginęły wśród licznych false positives powstających podczas normalnej pracy biznesowej. Dodatkowo organizacja korzystała z wielu narzędzi endpointowych i kilku SOC-ów bez wspólnej, skonsolidowanej widoczności. Jeden z prawdziwych alertów powiązanych z aktywnością na serwerze SCCM został błędnie odrzucony jako fałszywy alarm.
Druga organizacja posiadała podobne słabości techniczne, ale znacznie lepiej działała w warstwie operacyjnej. SOC wykrył phishing na etapie uruchamiania ładunków i odizolował zainfekowane stacje robocze w ciągu od kilku do kilkunastu minut. To skutecznie przerwało komunikację C2 i ograniczyło możliwość rozwinięcia ataku z pierwotnego punktu wejścia.
Ponieważ początkowy foothold został odcięty, dalsza część ćwiczenia była prowadzona w modelu assume-breach. W tym środowisku również odnaleziono jawne poświadczenia, w tym konto usługowe domeny zapisane w konfiguracji SCCM. Uprawnienia tego konta umożliwiły przeprowadzenie ataku DCSync i pozyskanie sekretu krbtgt, co w realnym incydencie mogłoby otworzyć drogę do pełnej kontroli nad uwierzytelnianiem Kerberos.
Red team dotarł również do bastion hosta w strefie DMZ środowiska OT, jednak brak dostępu wychodzącego do Internetu uniemożliwił zestawienie kanału C2. To ograniczenie znacząco utrudniło dalszą penetrację segmentu operacyjnego i pokazało, że właściwa segmentacja oraz kontrola ruchu sieciowego nadal pozostają jednymi z najskuteczniejszych mechanizmów ograniczania skutków incydentu.
Konsekwencje / ryzyko
Najważniejszy wniosek z opisanego przypadku jest prosty: pełna kompromitacja domeny bardzo często nie wynika z jednego spektakularnego błędu, lecz z połączenia kilku pozornie zwykłych zaniedbań. Domyślne hasła, błędne szablony AD CS, niekontrolowane Machine Account Quota, sekrety w plikach konfiguracyjnych i nadmierne uprawnienia w chmurze tworzą razem bardzo skuteczny łańcuch ataku.
Dla operatorów infrastruktury krytycznej ryzyko jest szczególnie wysokie. Nawet jeśli atak początkowo obejmuje wyłącznie warstwę IT, późniejsze przejście do systemów wspierających operacje może zakłócić procesy biznesowe, wpłynąć na ciągłość świadczenia usług publicznych i zwiększyć ryzyko oddziaływania na środowiska OT. W analizowanym przypadku bariery sieciowe pomogły ograniczyć skalę zagrożenia, ale nie zmienia to faktu, że atakujący osiągnął bardzo wysoki poziom uprzywilejowania.
Drugim kluczowym ryzykiem jest ślepota operacyjna SOC. Nadmiar fałszywych pozytywów, brak wspólnego obrazu telemetrii, rozproszona odpowiedzialność za systemy oraz niewystarczające uprawnienia analityków sprawiają, że nawet poprawnie działające narzędzia nie przekładają się na skuteczną obronę. Z perspektywy przeciwnika to idealne warunki do cichego i długotrwałego działania.
Rekomendacje
Organizacje powinny zacząć od eliminacji domyślnych poświadczeń w aplikacjach i urządzeniach oraz wdrożenia regularnych przeglądów ekspozycji zewnętrznej. Każdy system dostępny publicznie powinien być objęty inwentaryzacją, skanowaniem bezpieczeństwa i procedurą hardeningu jeszcze przed wdrożeniem produkcyjnym.
W środowiskach Active Directory warto ograniczyć lub wyłączyć Machine Account Quota tam, gdzie nie jest to niezbędne. Niezbędny jest także pełny przegląd usług AD CS i szablonów certyfikatów pod kątem scenariuszy nadużyć klasy ESC. Równolegle należy monitorować zdarzenia związane z żądaniami certyfikatów, zmianami w szablonach oraz nietypowymi operacjami katalogowymi.
Krytyczne znaczenie ma również usunięcie poświadczeń zapisanych w jawnej postaci. Hasła serwisowe, sekrety aplikacyjne i klucze chmurowe powinny zostać przeniesione do dedykowanych systemów zarządzania sekretami z rotacją, audytem użycia oraz możliwie krótkim okresem ważności. Statyczne klucze bez daty wygaśnięcia należy traktować jako dług techniczny wysokiego ryzyka.
W obszarze tożsamości i chmury konieczny jest przegląd uprawnień aplikacji Entra ID, ograniczenie zbyt szerokich zgód oraz wdrożenie procedur token hygiene, obejmujących między innymi odwoływanie sesji i reagowanie na przejęcie tokenów. Dodatkowo warto monitorować nietypowy dostęp do poczty zespołów bezpieczeństwa i administratorów.
Z perspektywy SOC priorytetem powinna być redukcja szumu alertowego, korelacja danych z wielu narzędzi oraz centralizacja widoczności. Analitycy muszą posiadać jasne ścieżki eskalacji, jednoznacznie przypisaną odpowiedzialność za zasoby oraz odpowiednie uprawnienia do izolowania hostów i uruchamiania działań containment bez zbędnych opóźnień.
W środowiskach OT należy utrzymywać ścisłą segmentację, ograniczać łączność wychodzącą z hostów pośredniczących i kontrolować kanały administracyjne pomiędzy IT a OT. Nawet częściowe bariery sieciowe mogą znacząco ograniczyć skutki incydentu i utrudnić przeciwnikowi przejście do systemów operacyjnych.
Podsumowanie
Opisane przez CISA dwa równoległe testy red team stanowią ważne ostrzeżenie dla całego sektora cyberbezpieczeństwa. Obie organizacje miały podobne słabości techniczne, ale tylko jedna potrafiła skutecznie zareagować na początkową fazę ataku. To potwierdza, że skuteczność ochrony zależy nie tylko od liczby wdrożonych narzędzi, lecz przede wszystkim od jakości procesów, kompetencji zespołu i zdolności do szybkiego działania.
Dla obrońców najważniejszy wniosek jest jednoznaczny: błędy w zarządzaniu tożsamością, certyfikatami, sekretami i alertami nadal należą do najkrótszych dróg prowadzących do kompromitacji domeny i środowisk chmurowych. Organizacje infrastruktury krytycznej powinny potraktować ten przypadek zarówno jako ostrzeżenie, jak i praktyczną listę priorytetów naprawczych.
Źródła
- The Hacker News — https://thehackernews.com/2026/08/cisa-red-team-compromised-two-critical.html
- CISA Advisory AA26-237A: A Tale of Two SOCs — https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-237a