CVE-2025-10035 w GoAnywhere MFT: krytyczne RCE i Medusa

CVE-2025-10035 to krytyczna podatność deserializacji w GoAnywhere MFT oceniona na CVSS 10.0. Atak prowadzi do command injection przez License Servlet panelu administracyjnego. Fortra opublikowała poprawkę we wrześniu 2025 r., ale późniejsze dochodzenie i analiza Microsoftu potwierdziły wcześniejsze wykorzystanie przeciwko wielu organizacjom, w tym aktywność powiązaną z grupą Storm-1175 oraz wdrożeniem ransomware Medusa.

Rekomendacja: zaktualizuj do GoAnywhere MFT 7.6.3 lub 7.8.4 albo nowszego wspieranego wydania, natychmiast usuń Admin Console z publicznego Internetu i przeszukaj logi pod kątem śladu SignedObject.getObject. System osiągalny przed poprawką wymaga analizy incydentu i rotacji dostępnych poświadczeń.

CVE-2025-10035 — potwierdzone fakty

Parametr	Wartość
Produkt	Fortra GoAnywhere MFT
Komponent	License Servlet w Admin Console
CVSS	10.0 — krytyczna
Podatne wersje	wydania przed 7.8.4; poprawiona linia sustain 7.6.3
Wersje z poprawką	7.6.3 i 7.8.4
Klasa błędu	deserializacja niezaufanych danych / command injection
Ekspozycja kluczowa	panel administratora dostępny z Internetu
Wykorzystanie	potwierdzone co najmniej od 11 września 2025 r. przez Fortra i Microsoft
Publiczna analiza PoC	tak — watchTowr Labs

Fortra podała, że 11 września rozpoczęła dochodzenie po zgłoszeniu podejrzanej aktywności, 12 września stworzyła hotfix, a 15 września udostępniła pełne wydania 7.6.3 oraz 7.8.4. Publiczne advisory pojawiło się 18 września.

Techniczna przyczyna: zaufanie do SignedObject

Podatność znajduje się w obsłudze odpowiedzi licencyjnej. GoAnywhere przyjmowało zaszyfrowany pakiet zawierający zserializowany obiekt Javy. Zewnętrzna warstwa ograniczała typ do java.security.SignedObject, co na pierwszy rzut oka wyglądało jak bezpieczna kontrola. Problem pojawiał się przy odczycie obiektu wewnętrznego.

Metoda SignedObject.getObject() deserializuje przechowywaną zawartość. Jeżeli aplikacja wykonuje tę operację zanim skutecznie potwierdzi zaufanie do podpisu i dopuszczalnych klas wewnętrznych, kontrolowany obiekt może uruchomić gadget chain. Publiczna analiza watchTowr pokazała, jak dostęp do ścieżki licencyjnej i słabości przepływu uwierzytelnienia prowadzą do tego sinka.

To dobry przykład, dlaczego podpisany wrapper nie gwarantuje bezpieczeństwa, gdy:

token lub identyfikator wymagany przez endpoint można uzyskać bez logowania;
klucze lub format ochronny można odtworzyć z produktu;
weryfikacja nie poprzedza niebezpiecznej deserializacji;
classpath zawiera klasy możliwe do użycia jako gadżety;
panel administracyjny jest wystawiony do Internetu.

Publiczny PoC i bezpieczna walidacja

watchTowr opublikował analizę „Is This Bad? This Feels Bad” opisującą techniczne odtworzenie luki i dowód koncepcji. Materiał zawiera szczegóły, których nie należy testować na produkcji. Deserializacja może od razu wykonać polecenie z uprawnieniami aplikacji.

Bezpieczna walidacja:

sprawdź numer aktywnej wersji i poziom hotfixa w portalu oraz plikach instalacji;
ustal historyczną ekspozycję Admin Console, także przez load balancer i tymczasowe reguły;
zabezpiecz goanywhere.log, Admin Audit Log, logi reverse proxy i EDR;
wyszukaj SignedObject.getObject w exception stack traces;
odtwórz test wyłącznie na izolowanej kopii bez kluczy i danych klientów;
po aktualizacji potwierdź zewnętrznie, że panel nie jest osiągalny.

PoC nie powinien być potrzebny do decyzji o patchu. Podatna wersja plus publicznie dostępna konsola stanowią wystarczający dowód wysokiego ryzyka.

Aktywne wykorzystanie i ransomware

Microsoft Defender zaobserwował 11 września 2025 r. wykorzystanie w wielu organizacjach, powiązane taktykami z aktorem Storm-1175. Po uzyskaniu dostępu napastnicy wdrażali narzędzia zdalnego sterowania, przemieszczali się w środowisku, a w jednym z opisanych przypadków skutecznie uruchomili ransomware Medusa.

Nie oznacza to, że każdy atak kończył się Medusą ani że tylko jedna grupa znała exploit. Publiczne szczegóły i maksymalna ocena ułatwiają kopiowanie techniki. Dla obrony najważniejszy jest fakt, że luka była używana przed pełnym publicznym ostrzeżeniem.

Naprawa i ograniczenie powierzchni ataku

Fortra wskazuje wydania 7.6.3 i 7.8.4 jako zawierające poprawkę. Zainstaluj najnowszą wspieraną wersję z portalu klienta i potwierdź poprawny restart wszystkich węzłów klastra. MFTaaS utrzymywane przez Fortra było aktualizowane przez dostawcę, ale klient nadal powinien przeanalizować konta, integracje i transfery dotyczące swojego tenantu.

Panel Admin Console nie powinien być wystawiony do Internetu. Dostęp powinien prowadzić przez prywatną sieć lub VPN z MFA, dedykowane stacje administracyjne i allowlistę adresów. Publiczne endpointy transferowe należy oddzielić od panelu zarządzającego na poziomie routingu i polityk zapory.

Ponadto:

użyj osobnych kont serwisowych do każdego partnera i workflow;
ogranicz dostęp systemu MFT do udziałów, baz i sekretów;
wyłącz nieużywane protokoły oraz konektory;
kontroluj egress i uruchamianie procesów potomnych;
przechowuj audyt poza serwerem, aby napastnik nie mógł go łatwo usunąć;
testuj odtworzenie konfiguracji z zaufanej kopii.

Hunting i IOCs

Najbardziej charakterystycznym śladem opisanym przez Fortrę jest wyjątek zawierający SignedObject.getObject w stosie wywołań License Servlet. Nie jest to jednak kompletny wskaźnik — udany atak może pozostawić inne lub ograniczone logi.

Sprawdź również:

żądania do ścieżek licencyjnych i LicenseResponseServlet z nietypowych adresów;
nowe konta administratorów, klucze i zmiany konfiguracji partnerów;
procesy potomne Javy, interpretery poleceń i narzędzia zdalnego dostępu;
archiwa i pliki staging tworzone poza harmonogramem transferów;
logowania RDP/SSH oraz ruch SMB z serwera MFT do nowych hostów;
nowe usługi, scheduled tasks i mechanizmy persistence;
masowy odczyt danych lub transfery poza normalnym oknem;
próby usunięcia logów i wyłączenia ochrony endpoint.

Jeśli istnieje ślad deserializacji lub nieautoryzowanego procesu, odizoluj system, zachowaj dowody i rozważ pełną odbudowę. Obróć poświadczenia partnerów, klucze SSH, certyfikaty, hasła do baz i konta domenowe dostępne z workflow.

Powierzchnia ataku: oddziel konsolę od transferu

Fortra wiąże ryzyko z instancjami, w których Admin Console była dostępna przez publiczny Internet. To ważne rozróżnienie architektoniczne: publiczne endpointy obsługujące SFTP, FTPS, AS2 albo inne transfery biznesowe nie muszą publikować tego samego listenera i routingu co panel administracyjny. W wielu wdrożeniach load balancer lub reverse proxy przypadkowo udostępnia oba.

Inwentaryzacja powinna obejmować wszystkie węzły, adresy wirtualne, porty, ścieżki proxy, reguły WAF, tunele partnerskie, węzły DR i obrazy testowe. Sprawdź konfigurację historyczną od co najmniej początku okna wskazanego przez dostawcę, nie tylko stan po wrześniowej zmianie. Log zmian zapory, infrastruktura jako kod, historia DNS/certyfikatów oraz archiwalne skany mogą potwierdzić, kiedy konsola była osiągalna.

Numer wersji zbierz z panelu, plików wydania i aktywnego procesu na każdym węźle. Klaster może wyglądać na zaktualizowany, mimo że jeden backend nie został zrestartowany. Podobnie obraz DR lub automatyzacja odtworzeniowa może zawierać podatną linię. Dla usługi zarządzanej potwierdź zakres odpowiedzialności dostawcy, ale nadal oceniaj konta, workflow i dane własnego tenanta.

Bezpieczna walidacja ekspozycji nie wysyła zaszyfrowanego pakietu ani obiektu Javy. Wystarczy potwierdzić, czy niezaufane źródło może osiągnąć endpoint administracyjny na warstwie TCP/TLS/HTTP, zarejestrować odpowiedź i porównać ją z zatwierdzoną architekturą. Nie próbuj obchodzić logowania. Jeżeli publiczna ścieżka istnieje, usuń ją przed dalszym badaniem.

Triage: podatność, możliwa ekspozycja czy kompromitacja?

Podziel instancje na cztery grupy:

Poprawiona wersja i konsola nigdy niepubliczna. Potwierdź wszystkie węzły oraz routing, a następnie wykonaj retest kontroli zarządczych.
Podatna wersja, konsola wiarygodnie prywatna. Aktualizuj pilnie i zweryfikuj, czy dostęp z sieci partnerskich, VPN oraz mniej zaufanych segmentów był rzeczywiście zablokowany.
Podatna wersja z historycznie publiczną konsolą, bez znanych IoC. Zachowaj logi, rozpocznij hunting, ogranicz ruch, zaktualizuj i przygotuj rotację sekretów.
Stack trace, nieautoryzowany proces, konto, narzędzie zdalne albo ruch boczny. Izoluj system i traktuj jako pełny incydent, nie zadanie patch management.

Ślad SignedObject.getObject zwiększa pewność, ale jego brak nie dowodzi braku ataku. Log mógł zostać zrotowany, wyłączony lub zmieniony, a pomyślne wykonanie może nie zostawić identycznego wyjątku. Oceń kompletność goanywhere.log, Admin Audit Log, proxy/WAF, EDR i logów sieciowych. Przerwa w telemetrii podczas ekspozycji powinna zwiększyć, a nie zmniejszyć ostrożność.

W grupie czwartej zatrzymaj automatyczne transfery w kontrolowany sposób, aby nie nadpisywać dowodów i nie rozsyłać dalej zmodyfikowanych plików. W razie potrzeby przełącz partnerów na czysty, ograniczony kanał awaryjny. Procedura powinna być częścią planu reakcji na wyciek danych, ponieważ MFT posiada dostęp do danych i organizacji zewnętrznych.

Jak budować oś czasu i użyteczne IoC

Zacznij od żądań do Admin Console i ścieżek licencyjnych. Połącz adres źródłowy, X-Forwarded-For, czas, identyfikator sesji, status HTTP oraz backend obsługujący żądanie. Następnie sprawdź zdarzenia aplikacyjne i wyjątki w tym samym oknie. Różnice stref czasowych oraz zegary load balancera, aplikacji i EDR trzeba znormalizować przed korelacją.

Na hoście najważniejsza jest relacja procesu Java z procesami potomnymi, nowymi plikami i egress. Nie ograniczaj reguł do jednej nazwy powłoki. Monitoruj nietypowe drzewo parent–child, wykonywanie z katalogów tymczasowych, tworzenie archiwów, nowe narzędzia administracyjne, zmiany usług i zadań. Dla systemu MFT warto mieć baseline legalnych procesów uruchamianych przez integracje.

Warstwa danych odpowiada na inne pytanie: co mogło zostać odczytane lub zmienione. Koreluj logi workflow, kolejki transferów, rozmiary, partnera, konto techniczne, ścieżkę źródłową/docelową oraz porę. Szukaj masowych odczytów bez odpowiadającego zatwierdzonego joba, ponownego transferu starych plików, zmienionych destination i tworzenia nowych kluczy partnerskich.

Ruch boczny z serwera MFT może pojawić się w AD, RDP, SSH, SMB, bazach i hypervisorach. Przejrzyj logowania źródłowe z adresu instancji, nawet gdy konto nie jest lokalnym administratorem GoAnywhere. Jeżeli host miał szerokie uprawnienia domenowe, połącz dochodzenie z analizą bezpieczeństwa Active Directory.

Hardening MFT po wdrożeniu poprawki

Panel administracyjny powinien mieć osobną prywatną ścieżkę: segment zarządzający, allowlistę, VPN/ZTNA z phishing-resistant MFA oraz dedykowane urządzenie. Nie publikuj go przez ten sam virtual host co transfer. Zasady Zero Trust wymagają kontroli podmiotu, urządzenia, kontekstu i działania, a nie tylko źródłowego adresu IP.

Role administratorów rozdziel według funkcji. Osoba zarządzająca partnerem nie musi kontrolować globalnej konfiguracji, credentiali i audytu. Uprawnienia wysokiego wpływu aktywuj czasowo z uzasadnieniem i approval zgodnie z PAM. Konta awaryjne przechowuj poza normalnym SSO i monitoruj każde użycie.

Każdy workflow powinien mieć osobną tożsamość i minimalne prawa do udziału, bucketu lub bazy. Nie używaj jednego konta domenowego do wielu partnerów. Ogranicz egress do znanych endpointów, repozytoriów aktualizacji i usług wewnętrznych. Zabroń bezpośredniego zarządzania domeną, backupem i hypervisorem z serwera transferowego.

Eksportuj Admin Audit Log, logi workflow i systemowe poza host z ochroną przed modyfikacją. File Integrity Monitoring powinien obejmować pliki aplikacji, biblioteki, konfigurację, klucze i skrypty zadań. Backup konfiguracji musi być szyfrowany, testowany i dostępny bez użycia potencjalnie skompromitowanego tenanta tożsamości.

Weryfikacja remediacji i retest bez eksploatacji

Po instalacji sprawdź wersję na każdym węźle, datę startu procesu Java i zgodność plików z pakietem dostawcy. Zapisz stan jako dowód. Zweryfikuj, czy load balancer nie kieruje części ruchu do starego backendu oraz czy DR i staging również otrzymały poprawkę.

Z zewnętrznej sieci potwierdź, że Admin Console nie jest osiągalna. Z sieci administracyjnej przetestuj logowanie kontem testowym, MFA, role, zmianę konfiguracji niskiego ryzyka i pełny ślad audytowy. Uzgodniony alert powinien połączyć nietypową próbę dostępu do panelu z logiem proxy i SIEM.

Nie odtwarzaj publicznego mechanizmu deserializacji na produkcji. Jeżeli organizacja potrzebuje potwierdzenia technicznego, zbuduj izolowane laboratorium z wersją podatną i poprawioną, bez kluczy, partnerów i danych. Kryterium retestu to odrzucenie dawnej klasy wejścia lub brak dotarcia do sinka przy nieszkodliwym markerze — bez uruchamiania polecenia.

Po podejrzeniu naruszenia aktualizacja nie jest wystarczającym kryterium zamknięcia. Potrzebne są: czysty rebuild albo uzasadniona analiza integralności, rotacja wszystkich osiągalnych credentiali, przegląd transferów i partnerów, weryfikacja persistence, odtworzenie z zaufanej kopii i działające detekcje. Zależności chmurowe i ekspozycję brzegową warto ponownie objąć pentestem AWS, Azure i GCP.

Drzewo decyzji dla CVE-2025-10035

Czy każdy węzeł ma 7.6.3, 7.8.4 lub nowszy wspierany fix? Jeśli nie lub brak pewności, zachowaj logi i aktualizuj. Jeśli tak, potwierdź aktywny proces oraz DR.
Czy Admin Console była kiedykolwiek publiczna? Jeśli tak lub historia jest niepełna, rozpocznij hunting. Jeśli nie, udokumentuj dowody z routingu i logów.
Czy istnieje SignedObject.getObject albo żądanie licencyjne z nietypowego źródła? Jeśli tak, eskaluj triage. Jeśli nie, nadal sprawdź procesy, konta i transfery.
Czy Java uruchomiła nietypowy proces lub host rozpoczął lateral movement? Jeśli tak, izolacja i pełny IR. Jeśli nie, oceń ciągłość EDR i logów.
Czy workflow udostępniały sekrety, bazy lub udziały? Jeśli tak, rotuj i przeglądaj ich użycie w kolejności ryzyka.
Czy wykryto szyfrowanie, narzędzia zdalne albo staging danych? Uruchom procedurę reakcji na ransomware i powiadom właścicieli danych/partnerów zgodnie z planem.

Dlaczego MFT wymaga odrębnego modelu zagrożeń

GoAnywhere automatyzuje wymianę plików między organizacjami i wewnętrznymi systemami. Jeden serwer ma często zaufanie do wielu stref, dlatego jego przejęcie może prowadzić zarówno do kradzieży danych, jak i do dalszego ruchu w sieci. Segmentacja powinna uniemożliwiać bezpośrednie administrowanie domeną, a konto usługi nie może mieć praw wykraczających poza konkretny transfer.

Regularny pentest infrastruktury powinien sprawdzać, czy publiczna usługa MFT nie otwiera drogi do panelu zarządzającego i zasobów wewnętrznych. Plan reagowania na incydent ransomware musi uwzględniać zatrzymanie automatycznych transferów bez utraty materiału dowodowego.