Mandiant i GTIG obserwowali kampanię szantażu UNC6240 (ShinyHunters) przeciw Oracle PeopleSoft od 27 maja do 9 czerwca 2026 r., przed komunikatem producenta o powiązanej z nią podatności. Dla właścicieli systemów kadrowych i finansowych oraz uczelni ograniczenie dostępu do interfejsów zarządzania powinno iść w parze z planem ich szybkiego odłączenia.

Kto może zdecydować o odłączeniu interfejsów zarządzania PeopleSoft, jeśli trzeba zareagować przed kolejnym komunikatem producenta? Odpowiedź „ustalimy to, kiedy pojawi się problem” potraktujmy jako sygnał do przejrzenia własnej procedury. Publikacja Mandiant i GTIG z 11 czerwca uzasadnia taką rozmowę: opisuje aktywność wcześniejszą niż komunikat Oracle z 10 czerwca. Przy przeglądzie własnej instalacji ustalmy zatem, które interfejsy zarządzania można odłączyć, kto zatwierdza zmianę i kto sprawdzi jej wykonanie. Ocenę, czy atak dotknął naszą instalację, zapiszmy jako osobne zadanie. Dopóki zespół jej nie przeprowadzi, stan środowiska pozostaje nieznany.

CVE-2026-35273 wykorzystywano przed komunikatem Oracle

W analizie Mandiant i GTIG badacze powiązali obserwowaną aktywność z CVE-2026-35273. Podatność wykorzystywano przed komunikatem Oracle z 10 czerwca. Przypisanie aktywności UNC6240 (ShinyHunters) pozostaje ustaleniem autorów analizy.

Właściciel PeopleSoft powinien przełożyć tę chronologię na pytanie o moment uruchomienia reakcji. Czy wewnętrzna procedura pozwala ocenić ograniczenie dostępu do interfejsów zarządzania, gdy są informacje o atakach, a zespół dopiero ustala stan własnej instalacji? Podczas przeglądu zapiszmy, jakie informacje są potrzebne do takiej decyzji i kto ma je zebrać.

W notatce dotyczącej własnej instalacji oddzielmy ustalenie badaczy od wyniku lokalnego sprawdzenia. Przy pierwszym wskażmy analizę, przy drugim zapiszmy, co rzeczywiście zweryfikowano. Jeśli ocena instalacji jeszcze się nie odbyła, nazwijmy jej stan nieznanym. Samo przeczytanie informacji o CVE-2026-35273 nie powinno zamykać zadania oceny środowiska.

Plan ograniczenia dostępu do interfejsów zarządzania powinien wskazywać warunki decyzji także przy niepełnej wiedzy o incydencie.

Procedurę odłączenia PeopleSoft sprawdźmy na konkretnych rolach

Dokument zderzmy z praktyką we własnym środowisku. Poprośmy osobę wskazaną w procedurze o pokazanie, które interfejsy zarządzania może odłączyć i czy wie, kto zatwierdzi takie działanie. Odpowiedź zapiszmy przy odpowiednim kroku procedury.

W przeglądzie uwzględnijmy osobno decyzję, wykonanie i potwierdzenie rezultatu. Jeśli dokument przypisuje wszystko ogólnie „zespołowi”, doprecyzujmy role oraz zastępstwo. Jeśli wymaga zgody, wskażmy sposób jej uzyskania w trybie awaryjnym.

Próbę rozmowy o odłączeniu interfejsów zarządzania zakończmy zapisem tego, czego nie rozstrzygnięto. Gdy administrator i właściciel usługi inaczej rozumieją zakres planowanego ograniczenia, zlećmy uzgodnienie go przed zatwierdzeniem procedury. W dokumencie użyjmy nazw składników potwierdzonych we własnym środowisku. Nie zastępujmy takiego sprawdzenia założeniem, że ogólne polecenie „odłączyć system” będzie dla wszystkich jednoznaczne.

Właściciel PeopleSoft powinien określić zakres decyzji

W rozmowie zarządczej ustalmy granice planowanego działania: które interfejsy zarządzania obejmie odłączenie, kto będzie oceniał skutki i na jakiej podstawie zapadnie decyzja o przywróceniu dostępu. Ocenę skutków odłączenia powierzmy właścicielowi konkretnej instalacji.

Dla systemu kadrowego lub finansowego poprośmy właściciela PeopleSoft o wskazanie czynności wymagających uzgodnienia przed odłączeniem. Nie zakładajmy z góry ich listy ani pilności. W planie zapiszmy wynik lokalnej oceny wraz z odpowiedzialnością za decyzję. Jeżeli właściciel nie umie jeszcze określić konsekwencji, wyznaczmy zadanie ich rozpoznania, zamiast wpisywać niepotwierdzoną deklarację o braku wpływu na pracę.

Plan odłączenia interfejsów zarządzania powinien łączyć zakres ograniczenia, osobę decyzyjną i warunki przywrócenia dostępu.

W ocenie gotowości do odłączenia uwzględnijmy potwierdzenie wykonania zmiany. Wskażmy, kto sprawdzi, czy osiągnięto uzgodniony zakres ograniczenia, i gdzie zapisze wynik. Nie traktujmy samej zgody na odłączenie jako zakończenia całego zadania. Warunki przywrócenia również omówmy z właścicielem usługi, aby plan obejmował decyzję o dalszym działaniu.

Polska uczelnia potrzebuje oceny własnego PeopleSoft

Dla polskiej uczelni lub właściciela systemów kadrowych i finansowych korzystającego z PeopleSoft punktem wyjścia jest ustalenie dostępu do interfejsów zarządzania i odpowiedzialności za jego ograniczenie.

Jeśli PeopleSoft jest używany w organizacji czytelnika, poprośmy o wspólny przegląd właściciela usługi i administratora. Przy każdym ustaleniu odnotujmy, czy wynika z aktualnej konfiguracji, dokumentacji czy wymaga dopiero potwierdzenia. Jako rezultat spotkania przyjmijmy listę decyzji o dostępie oraz braków do uzupełnienia.

Co z tym zrobić w poniedziałek

Każdy krok dotyczący PeopleSoft ogranicz do 30 minut; pytania bez odpowiedzi zapisz z właścicielem zadania. Przygotowania do reakcji podejmij od razu, bez czekania na poniedziałek.

  1. Spisz dostęp do interfejsów zarządzania. Przejrzyj dostępny opis konfiguracji i zanotuj, kto oraz skąd powinien mieć dostęp. Przy niepotwierdzonych pozycjach wpisz pytanie do administratora i termin weryfikacji.
  2. Wskaż role przy odłączeniu interfejsów zarządzania. Odszukaj w procedurze osobę zatwierdzającą ograniczenie oraz wykonawcę. Zapisz brakujące przypisania i zleć ich uzupełnienie właścicielowi usługi razem z zastępstwem.
  3. Sprawdź plan odłączenia interfejsów zarządzania. Na podstawie dokumentacji zapisz planowany zakres ograniczenia, sposób potwierdzenia jego wykonania i warunki przywrócenia. Rozbieżności skieruj do wyjaśnienia przed zatwierdzeniem planu.

Oceniajmy gotowość do odłączenia interfejsów zarządzania przez możliwość wskazania konkretnego zakresu działania i osoby odpowiedzialnej. Chronologia CVE-2026-35273 uzasadnia przygotowanie takiej decyzji przed kolejnym alarmem. Plan szybkiego odłączenia powinien być sprawdzalnym ustaleniem właściciela usługi i administratora.

Źródła

Redakcja cyberinsight.pl.