NAIC i 0-day w PeopleSoft: gdy regulator traci dane

Historia włamania do NAIC — amerykańskiego stowarzyszenia nadzorców ubezpieczeniowych (National Association of Insurance Commissioners) — jest pouczająca z dwóch powodów naraz. Po pierwsze, pokazuje, jak pojedynczy 0-day w systemie klasy ERP zamienia się w kampanię obejmującą ponad sto organizacji. Po drugie, i to jest w niej najciekawsze, jest studium przypadku czytania oświadczeń grup wymuszeniowych — bo napastnicy najpierw ogłosili spektakularne liczby, a potem sami je skorygowali, tłumacząc pierwotny komunikat… błędną interpretacją danych wygenerowaną przez AI.

Dla zespołów bezpieczeństwa to rzadka okazja, by na konkretnym przykładzie przećwiczyć umiejętność, której zwykle się nie ćwiczy: oddzielanie faktów od marketingu przestępców.

Punkt wejścia: CVE-2026-35273 w Oracle PeopleSoft

11 czerwca 2026 roku Oracle opublikował pozaharmonogramowy (out-of-band) biuletyn dotyczący podatności CVE-2026-35273 w PeopleSoft. Sam fakt wydania poprawki poza cyklem kwartalnym jest sygnałem — Oracle robi to wtedy, gdy czekanie do najbliższego Critical Patch Update byłoby zbyt ryzykowne.

Podatność pozwala na nieuwierzytelnione zdalne wykonanie kodu. To najgroźniejsza kombinacja, jaka istnieje: napastnik nie potrzebuje konta ani hasła, wystarczy mu dostęp sieciowy do podatnego systemu.

Żeby zrozumieć skalę skutków, trzeba wiedzieć, czym jest PeopleSoft. To pakiet aplikacji biznesowych używany głównie do obsługi:

kadr i płac (dane osobowe pracowników, wynagrodzenia, oceny, dane bankowe),
finansów (faktury, płatności, budżety, dane dostawców),
obsługi studentów na uczelniach (Campus Solutions — dane rekrutacyjne, oceny, płatności),
zaopatrzenia i zarządzania dostawcami.

Innymi słowy: to system, w którym z definicji znajdują się najwrażliwsze dane organizacji. Uczelnie, agencje rządowe i duże przedsiębiorstwa trzymają w nim komplet informacji o ludziach i pieniądzach. Dlatego 0-day w PeopleSofcie nie jest „kolejnym CVE” — to bezpośredni dostęp do skarbca.

Kampania z wykorzystaniem tej luki, przypisywana grupie ShinyHunters, według doniesień dotknęła ponad 100 organizacji, ze szczególnym udziałem uczelni. To ten sam ekosystem sprawców, o którym pisaliśmy przy atakach na helpdesk i wymuszeniach w SaaS — tyle że tutaj wektorem nie była socjotechnika, lecz techniczna luka w oprogramowaniu.

Chronologia incydentu w NAIC

Ułóżmy fakty w kolejności, bo w tej sprawie chronologia jest istotna dla oceny wiarygodności.

Data (2026)	Zdarzenie
11 czerwca	Oracle publikuje biuletyn poza cyklem dla CVE-2026-35273
ok. 11 czerwca	NAIC wykrywa nieautoryzowany dostęp do swoich systemów
17–18 czerwca	NAIC publikuje komunikaty publiczne
18 czerwca	ShinyHunters dopisuje NAIC do swojej strony wycieków
18 czerwca	Grupa deklaruje: ponad 105 000 plików, 3,1 TB, w tym 2,1 mln dokumentów sprawozdawczych ubezpieczycieli
ok. 24–25 czerwca	Publikacja rzekomych 3,1 TB danych
później	Grupa koryguje własną deklarację: nie 2,1 mln, lecz 260 tys. dokumentów

Zwróć uwagę na zbieżność dat: wykrycie włamania w NAIC nastąpiło mniej więcej wtedy, gdy Oracle wydał poprawkę. To typowe dla 0-dayów — obrońcy dowiadują się o problemie w momencie, w którym atak już trwa, a często trwał od tygodni.

Rozbieżność, która uczy najwięcej

Najbardziej wartościowa część tej historii to konfrontacja deklaracji napastnika z oceną ofiary.

Wersja grupy (pierwotna): 3,1 TB danych, ponad 105 tys. plików, w tym 2,1 miliona dokumentów sprawozdawczych ubezpieczycieli — czyli materiał sugerujący dostęp do wrażliwych danych finansowych całego sektora.

Wersja grupy (po korekcie): liczba dokumentów sprawozdawczych to 260 tysięcy, a pierwotne oświadczenie opierało się na — cytując uzasadnienie grupy — błędnej interpretacji danych wygenerowanej przez AI.

Wersja NAIC: wykradziono dane publicznie dostępne, przestarzałe logi i pliki konfiguracyjne. Organizacja stwierdza, że nie uzyskano dostępu do danych osobowych (PII) ani do danych kart płatniczych i bankowych.

Ten rozjazd — z 2,1 mln do 260 tys. dokumentów, przy jednoczesnym twierdzeniu ofiary, że w praktyce chodzi o materiały publiczne — jest lekcją samą w sobie. Wyciągnijmy z niej konkretne wnioski.

Dlaczego przestępcy zawyżają liczby

Grupy wymuszeniowe działają w modelu, w którym rozgłos jest częścią nacisku. Im większa deklarowana skala, tym:

większa presja na ofiarę, by negocjowała,
większe zainteresowanie mediów, które wzmacniają przekaz,
lepsza „reputacja” grupy wobec przyszłych ofiar i partnerów w modelu ransomware-as-a-service.

Wolumen podawany w terabajtach jest przy tym miarą wyjątkowo mylącą. Kopia zapasowa maszyny wirtualnej, katalog logów albo powielone archiwa potrafią zająć setki gigabajtów, nie zawierając ani jednego wrażliwego rekordu. Terabajty mierzą objętość, nie wartość.

Zaskakujący wątek: AI po stronie napastnika

Uzasadnienie korekty — „błędna interpretacja wygenerowana przez AI” — jest szczegółem, którego nie należy przeoczyć. Wynika z niego, że grupa użyła modelu do przeanalizowania i skatalogowania wykradzionych danych, a następnie oparła publiczny komunikat na jego wnioskach, których nikt nie zweryfikował.

To domyka pewien obraz. Po stronie obrońców mówimy o modelach, które pomagają znajdować podatności — pod warunkiem że człowiek weryfikuje wynik. Tutaj widzimy tę samą technologię po drugiej stronie i ten sam błąd metodologiczny: zaufanie wynikowi modelu bez weryfikacji. Napastnicy popełniają go równie chętnie jak wszyscy inni — z tą różnicą, że ich pomyłka kosztowała wiarygodność, a nie bezpieczeństwo.

Praktyczna konsekwencja dla obrońcy jest bezpośrednia: komunikat grupy wymuszeniowej może być nie tylko celowo zawyżony, ale też po prostu błędny, bo powstał z automatycznej analizy, której nikt nie sprawdził.

Jak czytać oświadczenia grup wymuszeniowych

Ta historia daje gotowy zestaw zasad. Warto go mieć spisany, zanim będzie potrzebny.

1. Deklaracja to hipoteza, nie ustalenie. Ciężar dowodu leży po stronie twierdzącego. Do czasu weryfikacji własną telemetrią traktuj każdą liczbę jako niepotwierdzoną.

2. Weryfikuj przez własne dane, nie przez czytanie strony wycieków. Odpowiedź na pytanie „co wyszło z organizacji” znajduje się w Twoich logach: wolumeny ruchu wychodzącego, dostępy do repozytoriów plików, zapytania do baz, aktywność kont serwisowych. To jedyne źródło, które nie ma motywacji, by kłamać.

3. Rozróżniaj „dostęp do systemu” od „eksfiltracji danych” i od „wrażliwości danych”. To trzy osobne pytania. Napastnik mógł być w systemie, nie wyprowadzając danych; mógł wyprowadzić dane bezwartościowe; mógł też wyprowadzić mało danych o dużej wrażliwości. Skrót myślowy „byli w środku, więc mamy wielki wyciek” bywa równie błędny jak jego zaprzeczenie.

4. Nie buduj komunikacji na cudzych liczbach. Jeśli oprzesz oświadczenie dla klientów na deklaracji przestępców, a ta okaże się zawyżona — sam wyrządzisz sobie szkodę. Jeśli ją zbagatelizujesz, a okaże się prawdziwa — stracisz wiarygodność. Mów wyłącznie o tym, co potwierdziłeś, i wskaż, kiedy podasz więcej. To standard opisany w naszym poradniku o pierwszych godzinach po wycieku.

5. Pamiętaj, że liczby rosną albo maleją w czasie. W przypadku wycieku Conduent liczba poszkodowanych rosła miesiącami, od ok. 10 mln do ponad 62 mln. Tutaj deklaracja została zmniejszona. Oba kierunki są normalne — pierwsze komunikaty prawie nigdy nie są ostateczne.

Regulator jako cel — dlaczego to szczególny przypadek

NAIC to organizacja koordynująca nadzór ubezpieczeniowy w USA. Nawet jeśli — zgodnie z jej oceną — wykradziono głównie materiały publiczne, sam fakt włamania do regulatora ma znaczenie wykraczające poza jedną instytucję.

Instytucje nadzorcze i branżowe agregują dane od wielu podmiotów. To czyni z nich cel o wysokiej dźwigni: jedno włamanie potencjalnie dotyka całego sektora, bez konieczności atakowania każdej firmy z osobna. Ta sama logika stoi za atakami na dostawców usług, izby rozliczeniowe czy centra przetwarzania — opisywaliśmy ją przy zarządzaniu ryzykiem dostawców.

Dodatkowy wymiar to dane pozornie nieszkodliwe. Przestarzałe logi i pliki konfiguracyjne — czyli dokładnie to, co według NAIC wyciekło — nie są sensacją nagłówkową, ale dla napastnika bywają cenne: ujawniają nazwy hostów, wersje oprogramowania, schematy nazewnictwa kont, ścieżki integracji i adresy wewnętrzne. To materiał do przygotowania następnego ataku, tym razem precyzyjnie ukierunkowanego. Dlatego ocena „to były tylko logi” nie powinna kończyć analizy, lecz uruchamiać przegląd tego, co z tych logów wynika.

Co zrobić, jeśli używasz PeopleSoft

Ustal ekspozycję. Sprawdź, które instancje PeopleSoft są osiągalne z internetu. Systemy klasy ERP i HR bardzo często nie mają powodu, by być publicznie dostępne — a bywają, bo „tak było wygodniej przy wdrożeniu” albo dla obsługi pracy zdalnej sprzed lat. Portal samoobsługi pracownika czy rekrutacji to typowy powód wystawienia, ale powinien być odseparowany od pełnej aplikacji.

Zweryfikuj poprawki, w tym te wydane poza cyklem. Oracle wydaje kwartalne Critical Patch Update, ale przy CVE-2026-35273 opublikował biuletyn pozaharmonogramowy. Jeśli Twój proces łatania jest zsynchronizowany wyłącznie z kwartałami, przegapisz dokładnie te poprawki, które są najpilniejsze. Ustaw monitorowanie komunikatów producenta niezależnie od kalendarza — to element dojrzałego procesu zarządzania podatnościami.

Poszukaj śladów wstecz. Przy 0-dayu wykorzystywanym w kampanii pytanie brzmi nie „czy jesteśmy podatni”, ale „czy nie było nas już w tej setce organizacji”. Przejrzyj logi serwera aplikacyjnego pod kątem nietypowych żądań, poszukaj nowych plików w katalogach aplikacji (webshelle), sprawdź nieoczekiwane procesy potomne serwera aplikacyjnego i nietypowe zapytania do bazy — zwłaszcza masowe odczyty tabel z danymi kadrowymi.

Zrotuj sekrety, jeśli byłeś w oknie ekspozycji. Konta integracyjne, klucze API, poświadczenia do bazy. Łatka zamyka wejście, ale nie unieważnia tego, co napastnik zdążył wynieść.

Ogranicz zasięg systemu. ERP nie powinien móc inicjować dowolnych połączeń wychodzących ani rozmawiać z całą siecią wewnętrzną. Segmentacja i kontrola egressu to najtańszy sposób na zamianę „przejęli ERP” w „przejęli ERP i utknęli”.

Wzmocnij monitoring danych, nie tylko systemów. Alarm na masowy odczyt danych kadrowych albo eksport dużej liczby rekordów jest skuteczniejszy niż jakikolwiek pojedynczy wskaźnik kompromitacji. To praktyczne zastosowanie cyklu threat intelligence i detekcji nastawionej na skutek, a nie na narzędzie.

Gdzie konkretnie szukać śladów

Przy 0-dayu w aplikacji webowej ERP zestaw miejsc do sprawdzenia jest dość powtarzalny. Warto przejść je metodycznie, zamiast polegać na jednym wskaźniku kompromitacji.

Logi serwera aplikacyjnego i webowego. Szukaj żądań do nietypowych ścieżek, serii błędów 500 poprzedzających nagłe „uspokojenie” ruchu (typowy ślad dostrajania exploita), a także żądań POST o nietypowych rozmiarach do endpointów, które normalnie przyjmują krótkie formularze.

Nowe pliki w katalogach aplikacji. Klasyczny efekt udanego RCE w aplikacji webowej to webshell — plik umieszczony w katalogu serwowanym przez serwer. Porównaj drzewo katalogów z wzorcem z wdrożenia lub z kopią zapasową; interesują Cię pliki z datą modyfikacji spoza okien wdrożeniowych.

Procesy potomne serwera aplikacyjnego. Serwer aplikacyjny uruchamiający powłokę, interpreter skryptowy albo narzędzia sieciowe to zachowanie, którego w normalnej pracy nie ma. To jedna z najskuteczniejszych i najprostszych reguł detekcyjnych dla tej klasy ataków.

Zapytania do bazy danych. Najcenniejszy sygnał przy ERP: masowe odczyty tabel kadrowych, płacowych lub dostawców, wykonane przez konto aplikacyjne poza godzinami przetwarzania wsadowego. Jeśli logujesz zapytania, szukaj SELECT obejmujących nietypowo szerokie zakresy rekordów.

Konta i uprawnienia. Nowe konta administracyjne, zmiany ról, dodane klucze integracji. Przy ERP szczególnie istotne są konta serwisowe — bywają pomijane w przeglądach, bo „należą do systemu”.

Ruch wychodzący. Eksfiltracja danych kadrowych z ERP to zwykle transfer o zauważalnym wolumenie. Porównaj profil ruchu wychodzącego z serwera aplikacyjnego z okresem sprzed incydentu; interesują Cię nowe kierunki i nietypowe wolumeny w krótkim czasie.

Najczęstsze pytania (FAQ)

Skoro NAIC mówi, że wyciekły dane publiczne, to czy w ogóle był to poważny incydent? Tak. Nieautoryzowany dostęp do systemów organizacji jest poważny niezależnie od klasyfikacji wykradzionych danych. Ocena „dane publiczne, przestarzałe logi i konfiguracja” ogranicza skutki dla osób trzecich, ale nie zmienia faktu, że napastnik był w środku — a konfiguracja i logi ułatwiają kolejne ataki.

Komu wierzyć: grupie czy ofierze? Żadnej ze stron na słowo. Grupa ma motywację, by wyolbrzymiać (presja negocjacyjna), ofiara — by pomniejszać (reputacja, odpowiedzialność prawna). Wiarygodne są ustalenia poparte dowodami: analiza powłamaniowa, dane telemetryczne, zgłoszenia do regulatorów. W tej sprawie sama grupa skorygowała własne liczby, co dobrze pokazuje ich pierwotną wartość dowodową.

Nie używamy PeopleSoft. Czy ta historia nas dotyczy? Wektor — nie. Wzorzec — tak. 0-day w systemie klasy ERP/HR może dotyczyć dowolnego dostawcy. Uniwersalne pytania brzmią: czy nasz ERP jest wystawiony do internetu, jak szybko wgrywamy poprawki poza cyklem, czy wykrylibyśmy masowy eksport danych kadrowych i czy potrafimy odtworzyć, co się działo miesiąc temu.

Co konkretnie zrobić w pierwszej kolejności? Trzy rzeczy: sprawdzić ekspozycję ERP do internetu, potwierdzić wersję i komplet poprawek (łącznie z pozaharmonogramowymi), przejrzeć logi wstecz za okres ekspozycji. Jeśli którekolwiek z tych pytań zostaje bez jednoznacznej odpowiedzi, masz swój priorytet na najbliższy tydzień.

Jak przygotować się do sytuacji, w której nasza nazwa pojawia się na stronie wycieków? Zawczasu: ustal, kto ocenia wiarygodność deklaracji, kto zatwierdza komunikat, jakie dane musisz mieć, by potwierdzić lub zaprzeczyć, i w jakim czasie. To scenariusz do przećwiczenia w ramach planu reagowania na incydenty — w trakcie prawdziwego incydentu nie ma czasu na ustalanie ról.

Podsumowanie

Sprawa NAIC łączy dwie lekcje, które rzadko występują razem. Techniczna jest znajoma: 0-day w systemie klasy ERP daje napastnikowi natychmiastowy dostęp do najwrażliwszych danych organizacji, a poprawki wydawane poza kwartalnym cyklem łatwo przegapić, jeśli proces łatania jest przywiązany do kalendarza dostawcy.

Druga lekcja jest rzadsza i cenniejsza: deklaracje grup wymuszeniowych to materiał do weryfikacji, nie źródło faktów. W tym przypadku napastnicy sami zredukowali własne liczby z 2,1 mln do 260 tys. dokumentów, tłumacząc pierwotny komunikat niezweryfikowaną analizą AI. Organizacja, która oparłaby komunikację na pierwszej wersji, znalazłaby się w kłopotliwej sytuacji.

Jeśli chcesz sprawdzić, czy Twoje systemy ERP są widoczne z internetu, jak szybko domykasz okna po pozaharmonogramowych poprawkach i czy wykryłbyś masowy eksport danych kadrowych — zweryfikujmy to kontrolowanym testem.

Źródła i dalsza lektura: SecurityWeek, BleepingComputer, Oracle Security Alerts, CISA KEV.