Harvard ofiarą kampanii na Oracle E-Business Suite. Cl0p publikuje 1,3 TB danych – co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Harvard University potwierdził, że padł ofiarą kampanii wymierzonej w klientów Oracle E-Business Suite (EBS), którą przypisuje się grupie Cl0p. Po tym, jak uczelnia pojawiła się na stronie wycieków Cl0p, przestępcy udostępnili archiwa o łącznej wielkości ponad 1,3 TB z rzekomo wykradzionymi danymi. Harvard podkreśla, że incydent dotyczy „ograniczonej liczby podmiotów powiązanych z małą jednostką administracyjną” i nie ma dowodów na kompromitację innych systemów uczelni.

W skrócie

• Cl0p opublikował link do ponad 1,3 TB danych związanych z Harvardem; treść nie została niezależnie zweryfikowana przez media.
• Incydent jest częścią szerszej kampanii przeciw klientom Oracle EBS, w której wykorzystywano CVE-2025-61882 (RCE bez uwierzytelnienia).
• Google/Mandiant szacują, że poszkodowanych jest dziesiątki organizacji; aktywność atakujących sięga co najmniej sierpnia, a być może lipca 2025 r.
• Harvard zastosował poprawki i monitoruje środowisko; zasięg szkód ma być ograniczony.
• Ataki są połączone z kampanią wymuszeń (extortion) – e-maile kierowane do decydentów, groźby publikacji danych.

Kontekst / historia / powiązania

Kampania przeciw Oracle EBS została nagłośniona na początku października 2025 r., gdy wiele organizacji zaczęło otrzymywać e-maile o wycieku danych i żądania okupu. Wkrótce potem Oracle wydał Security Alert dla CVE-2025-61882, a analizy Google Threat Intelligence Group i Mandiant wskazały na masowy charakter operacji. W przypadku Harvardu Cl0p najpierw dodał uczelnię do swojej strony, a 12 października opublikował link do rzekomych danych.

Analiza techniczna / szczegóły luki

CVE-2025-61882 dotyczy komponentu Oracle Concurrent Processing – BI Publisher Integration w EBS. Luka umożliwia zdalne wykonanie kodu bez uwierzytelnienia (CVSS 9.8) przez HTTP i dotyczy wersji 12.2.3–12.2.14. Oracle wyraźnie zaleca natychmiastową instalację poprawek; warunkiem ich zastosowania jest wcześniejszy CPU z października 2023 r. Wskazano także wskaźniki kompromitacji (IOCs), m.in. pewne adresy IP i artefakty powiązane z publicznie krążącym POC.

W kolejnych dniach Oracle opublikował również osobny alert dla CVE-2025-61884 (Runtime UI; wysoka waga), który nie jest tożsamy z 61882, ale adresuje dodatkowy wektor w łańcuchach ataku obserwowanych w terenie. Administratorzy EBS powinni traktować oba biuletyny jako krytyczne. (Uwaga: 61884 to osobna podatność i nie oznacza, że Harvard został przez nią naruszony).

Praktyczne konsekwencje / ryzyko

EBS często przetwarza wrażliwe informacje back-office (finanse, HR, łańcuch dostaw). Wyciek 1,3 TB – jeśli się potwierdzi – może obejmować różne typy danych operacyjnych. Nawet przy „ograniczonym” zakresie incydentu ryzyka obejmują: dalsze ataki ukierunkowane, oszustwa finansowe, spear-phishing na podstawie struktur organizacyjnych, a także odpowiedzialność regulacyjną (FERPA/GLBA w sektorze edukacyjnym, RODO dla danych osób w UE). Kampania ma skalę „dziesiątek organizacji”, co zwiększa prawdopodobieństwo wtórnych nadużyć i łańcuchowych kompromitacji dostawców.

Rekomendacje operacyjne / co zrobić teraz

1. Patch now: Niezwłocznie zastosuj poprawki z Oracle Security Alert – CVE-2025-61882 oraz nowszy alert dla CVE-2025-61884. Zweryfikuj zależności (wymóg CPU 10/2023).
2. Hunting & IOCs: Przeskanuj logi HTTP/Apache EBS i serwery aplikacyjne pod kątem IOCs i komend wskazanych przez Oracle; sprawdź nietypowe połączenia wychodzące i artefakty web-shelli.
3. Segmentacja i egress filtering: Ogranicz dostęp sieciowy (szczególnie ruch wychodzący z EBS), zastosuj WAF/IPS z regułami na znane wzorce eksploatacji. (Wnioski spójne z zaleceniami GTIG/Mandiant w kontekście kampanii).
4. IR i komunikacja: Przygotuj plan notyfikacji interesariuszy i osób, których dane mogą być dotknięte. W razie potwierdzenia wycieku – procedury zgodności (np. zgłoszenia regulatorom).
5. Hardening EBS: Weryfikacja kont i ról aplikacyjnych, rotacja haseł i kluczy, wyłączenie nieużywanych modułów/servletów, przegląd integracji BI Publisher i komponentów Concurrent Processing.
6. Kontrola łańcucha dostaw: Zidentyfikuj systemy i integracje zależne od EBS (np. middleware, hurtownie danych); sprawdź, czy nie nastąpiło „przeciągnięcie” danych do innych węzłów.

Różnice / porównania z innymi przypadkami (MOVEit, Accellion itd.)

Cl0p od lat prowadzi kampanie „data theft & extortion” oparte na lukach w oprogramowaniu firm trzecich (Accellion FTA, GoAnywhere, MOVEit). Oracle EBS różni się jednak tym, że to system ERP/back-office, więc kompromitacja może dotykać danych operacyjnych rdzenia organizacji, a nie wyłącznie systemów wymiany plików. Skala kampanii (dziesiątki ofiar, łańcuchy exploitów) jest porównywalna do wcześniejszych operacji Cl0p, ale profil danych i możliwe skutki biznesowe są potencjalnie poważniejsze.

Podsumowanie / kluczowe wnioski

• Harvard potwierdził incydent EBS i ograniczony zasięg wewnątrz uczelni, ale Cl0p twierdzi, że opublikował 1,3 TB danych.
• CVE-2025-61882 to krytyczna luka RCE bez uwierzytelnienia w Oracle EBS; łatki są dostępne i wymagają pilnego wdrożenia.
• Kampania ma charakter masowy (dozens of orgs), a łańcuchy eksploatacji mogły obejmować wiele podatności. Organizacje muszą prowadzić aktywne huntingi i przegląd integracji EBS.

Źródła / bibliografia

• Oracle – Security Alert: CVE-2025-61882 (E-Business Suite, RCE bez uwierzytelnienia). (Oracle)
• The Record (Recorded Future News) – Harvard: „limited number of parties” i potwierdzenie incydentu EBS. (The Record from Recorded Future)
• SecurityWeek – Harvard pierwszą potwierdzoną ofiarą; link do 1,3 TB archiwów. (SecurityWeek)
• BleepingComputer – Timeline i oświadczenie Harvard University IT; powiązanie z kampanią Cl0p. (BleepingComputer)
• CyberScoop – Skala ataków (dziesiątki organizacji), Shadowserver, szczegóły łańcucha exploitów. (CyberScoop)