Cl0p publikuje listę ~30 ofiar kampanii na Oracle E-Business Suite. Co wiemy o atakach i jak się bronić

securitybeztabu.pl 1 dzień temu

Wprowadzenie do problemu / definicja luki

Grupa powiązana z Cl0p opublikowała na swoim portalu około 30 rzekomych ofiar kampanii wymierzonej w klientów Oracle E-Business Suite (EBS) — popularnego systemu ERP. Na liście wymieniono m.in. Logitech, The Washington Post, Cox Enterprises, Pan American Silver, LKQ Corporation i Copeland. Część podmiotów (np. The Washington Post) potwierdziła naruszenie, większość jednak milczy lub prowadzi dochodzenia wewnętrzne. Źródła branżowe łączą tę falę incydentów z krytyczną podatnością CVE-2025-61882 (CVSS 9.8) w komponencie BI Publisher Integration pakietu EBS, która umożliwia zdalne, nieautoryzowane ataki przez HTTP. Oracle załatał błąd w trybie alarmowym na początku października 2025 r.

W skrócie

  • Atakujący: klaster przestępczy kojarzony z FIN11 i marką Cl0p (ekstorsja + wycieki).
  • Wektor: wykorzystanie luk w Oracle EBS; najbardziej prawdopodobna — CVE-2025-61882 (RCE bez uwierzytelniania) w zakresach wersji 12.2.3–12.2.14.
  • Skala: dziesiątki organizacji; ok. 29 pozycji na stronie Cl0p, wycieki danych u co najmniej 18 z nich (częściowo wieluset-GB/TB).
  • Linia czasu: masowe maile z szantażem od 29 września; łatki Oracle — 4–5 października 2025 r.; kolejne potwierdzenia ofiar w październiku-listopadzie.
  • Status: część firm potwierdziła incydent (np. The Washington Post), inne nie komentują publicznie.

Kontekst / historia / powiązania

Specjaliści Google Threat Intelligence i Mandiant opisali na początku października zmasowaną kampanię ekstorsyjną: do menedżerów spływały e-maile z twierdzeniami o kradzieży danych z ich środowisk EBS. Równolegle Reuters i inne media informowały o kolejnych ofiarach (np. Envoy Air/AA, Harvard), a Oracle potwierdził problem i wydał Security Alert z łatą. SecurityWeek zebrał listę ~30 nazw wskazanych przez Cl0p, podkreślając, iż część danych rzeczywiście wygląda na pochodzące z instancji Oracle. Tę kampanię osadzono w modus operandi znanym z wcześniejszych akcji Cl0p (MOVEit, Fortra, Cleo) — presja medialna + publikacja wykradzionych pakietów.

Analiza techniczna / szczegóły luki

CVE-2025-61882 (Oracle E-Business Suite – Concurrent Processing / BI Publisher Integration)

  • Zakres wersji: 12.2.3–12.2.14.
  • Skutki: zdalne przejęcie komponentu (CIA: C/I/A=H, CVSS 9.8), bez uwierzytelniania przez HTTP.
  • Charakter: „easily exploitable”; sprzyja RCE i dostępowi do wrażliwych danych przetwarzanych w EBS.
  • Eksploatacja: raporty wskazują na aktywny exploit przed publikacją poprawki (zero-day).

Uwaga: w doniesieniach pojawia się także druga luka z tej samej „rodziny”, jednak na dziś to CVE-2025-61882 jest jednoznacznie potwierdzone przez Oracle/NVD jako krytyczny wektor RCE.

Prawdopodobny łańcuch ataku (uogólniony)

  1. Skany internetowo dostępnych instancji EBS (typowe ścieżki /OA_HTML/…).
  2. Wykorzystanie CVE-2025-61882 do wykonania kodu w komponentach związanych z BI Publisher/Concurrent Processing.
  3. Utrwalenie (np. web-shell, konto aplikacyjne) i zbieranie danych (eksporty, raporty, zrzuty tabel).
  4. Ekstorsja: kontakt do kadry zarządzającej z żądaniem okupu + groźbą publikacji plików.
  5. Publikacja paczek na stronie Cl0p w razie braku płatności.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja danych ERP: finanse, łańcuch dostaw, HR, logistyka — wysokie ryzyko wtórnych oszustw i fraudów.
  • Zakłócenia operacji: ryzyko zatrzymania procesów (AP/AR, zamówienia, produkcja).
  • Ryzyko prawno-regulacyjne: RODO/PCI/sox — kary administracyjne, obowiązki notyfikacyjne.
  • Efekt łańcuchowy: EBS z reguły integruje się z innymi systemami (ESB, hurtownie danych) — możliwość lateral movement.
  • Ryzyko reputacyjne: Cl0p publikuje duże wolumeny danych (setki GB do TB), co zwiększa presję na zapłatę.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i konfiguracja

  • Natychmiast zastosuj Security Alert dla CVE-2025-61882 (EBS 12.2.3–12.2.14). Zweryfikuj, iż poprawka została wdrożona na wszystkich węzłach (apps tier/db tier).
  • Ogranicz ekspozycję EBS do internetu: jeżeli to możliwe, dostęp wyłącznie przez VPN/ZTNA; przeglądarkowy interfejs użytkownika (OA_HTML) nie powinien być publiczny.
  • WAF/Reverse proxy: tymczasowe reguły blokujące nietypowe żądania do endpointów raportowania/BI, rozmiary odpowiedzi i długotrwałe transfery.

2) Detekcja i monitoring (przykładowe reguły)

  • Netflow/Proxy/Firewall – wykrywanie dużych POST/GET do zewnętrznych adresów z hostów EBS:
    • Splunk (prosty szkic): index=proxy OR index=nginx sourcetype=http (uri_path="/OA_HTML/*" OR cs_uri_stem="/OA_HTML/*") | stats sum(bytes_out) as out, values(cs_uri_query) as q by src_ip, uri_path, http_method | where out > 500000000 /* >500MB dziennie */
  • System – nietypowe procesy JVM/Java z parametrami uruchamianymi przez użytkowników aplikacyjnych:
    • Linux (ad-hoc): ps -ef | egrep 'java|weblogic' | egrep -i 'curl|wget|nc|bash -i|sh -i'
  • Pliki aplikacyjne – poszukiwanie web-shelli w katalogach serwisujących EBS: find $INST_TOP/ora/10.1.3/j2ee -type f -mtime -30 -size +50k \ -iname "*.jsp" -exec grep -H -E "(Runtime|getRuntime|ProcessBuilder)" {} \;
  • Logi HTTP – anomalie w BI Publisher/Concurrent Processing (duże odpowiedzi, 5xx po dużych POST, nagły skok 2xx): awk '{print $7, $9, $10}' access_log | grep -E "BIPublisher|Concurrent|OA_HTML" | sort | uniq -c | sort -nr | head

(Powyższe to wzorce poszukiwań – dostosuj do swojej topologii i ścieżek w danym wydaniu EBS.)

3) Łagodzenie skutków i IR

  • Załóż kompromitację dla instancji nienaprawionych przed 4–5 października 2025 r.; przeprowadź triage pamięci (Volatility/AVML) i przegląd harmonogramów (Concurrent Requests), kont oraz pakietów raportowych.
  • Rotacja haseł/kd. integracyjnych i przegląd SSO jeżeli EBS zintegrowany jest z IdP.
  • Segmentacja: izoluj serwery apps/db do czasu zakończenia dochodzenia, wstrzymaj zadania eksportów masowych.
  • Zgłoszenia regulacyjne: oceń zakres danych wg jurysdykcji (np. RODO) i czasów detekcji.

4) Twardnienie (hardening) „na jutro”

  • Minimalizacja powierzchni: odłącz zbędne moduły/servlety, wymuś TLS 1.2+, nagłówki bezpieczeństwa.
  • Kontrola egress: EBS zwykle nie potrzebuje otwartego ruchu wychodzącego do internetu — egres pod ścisłą allowlistą.
  • Kopia zapasowa planu odtworzeniowego: test odtworzenia offline; backupy szyfrowane i odseparowane (immutability).

Różnice / porównania z innymi przypadkami

  • MOVEit/Fortra/Cleo vs Oracle EBS: podobny model ekstorsji (nacisk medialny, tablica wstydu, hurtowe wycieki). Różnica: zamiast podatności w menedżerach transferu plików, celem jest system ERP — więc jakość i kontekst danych (finanse, logistyka) mają zwykle wyższą wartość operacyjną dla przestępców i większy impakt biznesowy. SecurityWeek wskazuje, iż wcześniejsze skojarzenia Cl0p-FIN11 tłumaczą użycie brandu Cl0p jako „frontu” kampanii.

Podsumowanie / najważniejsze wnioski

  • CVE-2025-61882 w Oracle EBS to krytyczna luka RCE, realnie wykorzystywana w kampanii ekstorsyjnej. Łatka od Oracle jest dostępna — patchuj natychmiast.
  • Lista Cl0p obejmuje ~29 organizacji, a część z nich potwierdziła incydenty (np. The Washington Post). Nie zakładaj, iż „to tylko straszak”.
  • Traktuj EBS jak system krytyczny: zamknięcie ekspozycji internetowej, kontrola egresu, ciągły monitoring i „assume breach” dla okien bez łatek z końca września/początku października 2025 r.

Źródła / bibliografia

  1. SecurityWeek – lista ~30 ofiar i kontekst kampanii Cl0p (10 listopada 2025). (SecurityWeek)
  2. Reuters – The Washington Post potwierdza naruszenie związane z Oracle EBS (6 listopada 2025). (Reuters)
  3. Oracle Security Alert – CVE-2025-61882 (EBS) – opis i łatki. (Oracle)
  4. NVD – karta podatności CVE-2025-61882 (CVSS 9.8, RCE bez uwierzytelniania). (NVD)
  5. Google Threat Intelligence – wpis o zero-day w Oracle EBS i kampanii ekstorsyjnej (9 października 2025). (Google Cloud)
Idź do oryginalnego materiału