Jeden aktor odpowiada za 83% aktywnych ataków RCE na Ivanti EPMM (CVE-2026-1281, CVE-2026-1340)

Wprowadzenie do problemu / definicja luki

Na przełomie końca stycznia i pierwszej połowy lutego 2026 r. obserwujemy szybkie „uzbrojenie” (weaponization) dwóch krytycznych podatności pre-auth w Ivanti Endpoint Manager Mobile (EPMM) — CVE-2026-1281 i CVE-2026-1340. Obie umożliwiają nieautoryzowane zdalne wykonanie kodu (RCE), czyli przejęcie serwera MDM/UEM bez loginu i hasła.

Najbardziej niepokojący jest jednak wątek operacyjny: telemetria GreyNoise wskazuje, iż dominująca część prób eksploatacji (83%) pochodzi z jednego adresu IP ulokowanego na infrastrukturze określanej jako bulletproof hosting.

W skrócie

• Podatności: CVE-2026-1281 oraz CVE-2026-1340 (obie oceniane jako krytyczne; CVSS 9.8).
• Skala i koncentracja źródła ataków: 417 sesji eksploatacyjnych w dniach 1–9 lutego 2026, z czego 83% z jednego IP 193.24.123[.]42 (PROSPERO OOO / AS200593).
• Sygnał „brokerów dostępu” (IAB): 85% sesji używało OAST/DNS callback do weryfikacji RCE bez natychmiastowego wdrażania malware — typowe „sprawdzam i kataloguję cele”.
• Ryzyko biznesowe: kompromitacja EPMM = dostęp do danych administracyjnych, informacji o urządzeniach mobilnych oraz potencjalna możliwość zmian konfiguracyjnych, co przekłada się na ryzyko przejęcia floty urządzeń.

Kontekst / historia / powiązania

Ivanti EPMM to centralny komponent zarządzania urządzeniami mobilnymi (MDM/UEM). jeżeli stoi publicznie w Internecie, jest to cel „wysokiej dźwigni”: jeden udany pre-auth RCE może otworzyć drogę do dalszych działań w organizacji.

W analizowanym przypadku istotne są dwie obserwacje:

1. Tempo eskalacji po ujawnieniu: GreyNoise wskazuje, iż pierwsze próby eksploatacji widziało już 1 lutego 2026, czyli kilka dni po publikacji informacji o luce, a 8 lutego nastąpił wyraźny pik aktywności (269 sesji jednego dnia).
2. Konsolidacja infrastruktury ofensywnej: pojedynczy host nie tylko atakował Ivanti, ale równolegle „mielił” wiele CVE w różnych produktach, co jest charakterystyczne dla automatyzacji (skan + exploit + walidacja).

Analiza techniczna / szczegóły luki

Co wiemy o CVE-2026-1281 (i relacji do CVE-2026-1340)

• NVD opisuje CVE-2026-1281 jako code injection prowadzące do nieautoryzowanego RCE.
• CERT-EU potwierdza, iż obie podatności dotyczą Ivanti EPMM i pozwalają na pre-auth RCE, a trwała poprawka ma trafić do EPMM 12.8.0.0 (Q1 2026).

Mechanika exploita i „dlaczego Bash ma tu znaczenie”

watchTowr (analiza techniczna) wskazuje na interesujący trop: dostarczone przez Ivanti tymczasowe hotfixy (RPM) podmieniają logikę mapowania URL-i w Apache RewriteMap — z powłokowych skryptów Bash na klasy Java. To silnie sugeruje, iż krytyczny błąd siedział w ścieżce, gdzie atakujący mógł przekazać kontrolowane dane do Basha przez HTTP.

W praktyce exploitowalne żądania dotyczą specyficznych endpointów pod /mifs/… (np. związanych z dystrybucją aplikacji „in-house”), gdzie parametry z URL/Host trafiają do mechanizmu mapowania. watchTowr opisuje, iż finalny wektor wykorzystuje Bash arithmetic expansion (wstrzyknięcie prowadzące do wykonania poleceń).

Telemetria ataków: jeden adres dominuje, a „poc” to nie koniec historii

GreyNoise policzył w dniach 1–9 lutego 2026 417 sesji eksploatacyjnych z 8 IP, ale 346 sesji (83%) pochodziło z 193.24.123[.]42 (PROSPERO OOO / AS200593).
Co ważne, 85% sesji kończyło się DNS callback (OAST) — potwierdzeniem, iż payload wykonał się po stronie ofiary, bez natychmiastowej instalacji malware. To często oznacza etap „selekcji i przygotowania dostępu”.

BleepingComputer podkreśla dodatkowo, iż część obrony oparta wyłącznie o „opublikowane IOC” może nie wystarczyć, bo dominujący adres nie musiał znaleźć się na popularnych listach.

Praktyczne konsekwencje / ryzyko

Skuteczna kompromitacja EPMM może mieć konsekwencje wykraczające poza sam serwer:

• Dostęp do danych: konta administratorów/użytkowników, e-maile, atrybuty urządzeń (numery, IP, zainstalowane aplikacje, identyfikatory typu IMEI/MAC).
• Ryzyko nadużyć operacyjnych: możliwość zmian w konfiguracji zarządzanych urządzeń (w tym ustawień uwierzytelniania), co sprzyja trwałemu przejęciu środowiska mobilnego.
• Cichy etap „stagingu”: OAST/DNS callback i wzmianki o „sleeper shell” w ścieżce /mifs/403.jsp sugerują scenariusz, w którym system wygląda na „spokojny”, a jednak jest już przygotowany do kolejnego kroku.

Rekomendacje operacyjne / co zrobić teraz

1. Natychmiast zastosuj hotfix (RPM) zgodnie z wytycznymi producenta / CERT-EU
   CERT-EU wprost rekomenduje wdrożenie hotfixów RPM 12.x.0 lub 12.x.1 dla podatnych wersji oraz pamiętanie, iż hotfix nie przetrwa upgrade’u i trzeba go ponownie zastosować.
2. Potraktuj każde publicznie wystawione EPMM jako potencjalnie naruszone (jeśli było niezałatane po 29 stycznia 2026)
   GreyNoise pokazał, iż exploity „ruszyły” błyskawicznie po ujawnieniu, z istotnym pikiem 8 lutego.
3. Polowanie na ślady eksploatacji w logach HTTP i endpointach /mifs/…
   Ivanti (cytowane przez BleepingComputer) wskazywało, iż próby mogą pojawiać się w Apache access log (m.in. /var/log/httpd/https-access_log) i dotyczyć ścieżek związanych z dystrybucją aplikacji.
4. Przegląd DNS pod kątem OAST (wysoko-entropijne subdomeny / nietypowe callbacki)
   Skoro 85% obserwacji to DNS callback w celu weryfikacji RCE, logi DNS/proxy mogą być jednym z najlepszych „czujników” potwierdzających wykonanie payloadu.
5. Zablokuj/ogranicz infrastrukturę źródłową tam, gdzie ma to sens (AS-level)
   GreyNoise rekomenduje blokowanie AS200593 (PROSPERO OOO) na brzegu sieci, bo to tam koncentrowała się dominująca aktyność.
6. Przygotuj plan trwałej aktualizacji do EPMM 12.8.0.0 oraz ewentualnej odbudowy instancji
   Zarówno CERT-EU, jak i BleepingComputer podkreślają, iż trwała naprawa ma być dopiero w 12.8.0.0 (Q1 2026), a podejście „najbardziej konserwatywne” może oznaczać rebuild i migrację.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

To zdarzenie wyróżniają trzy elementy, które nie zawsze występują jednocześnie:

• Silna koncentracja źródła (83% z jednego IP) zamiast „rozproszonego botnetu”.
• Weryfikacja exploita przez OAST/DNS (często „IAB-style”), czyli najpierw potwierdzenie podatności i możliwość powrotu później.
• Hotfix jako zmiana architektury ścieżki wykonania (Bash → Java w RewriteMap), co sugeruje, iż luka była „głęboko” w przepływie requestów HTP.

Podsumowanie / najważniejsze wnioski

• CVE-2026-1281 i CVE-2026-1340 to krytyczne, pre-auth podatności RCE w Ivanti EPMM, a exploitacja w realu była potwierdzana jako co najmniej „limitowana” u ofiar.
• W telemetrii GreyNoise 83% aktywności przypisano do jednego IP na infrastrukturze bulletproof (PROSPERO/AS200593), a dominującą taktyką była walidacja przez DNS callback (OAST).
• Operacyjnie: łatka + dochodzenie (logi HTTP/DNS, ślady /mifs/…, poszukiwanie „sleeper shell”) powinny iść równolegle — szczególnie jeżeli EPMM był wystawiony do Internetu.

Źródła / bibliografia

1. BleepingComputer — „One threat actor responsible for 83% of recent Ivanti RCE attacks” (14.02.2026). (BleepingComputer)
2. GreyNoise — „Active Ivanti Exploitation Traced to Single Bulletproof IP…” (luty 2026). (GreyNoise)
3. watchTowr Labs — analiza techniczna CVE-2026-1281/CVE-2026-1340 (30.01.2026). (watchTowr Labs)
4. CERT-EU — „Security Advisory 2026-001: Critical vulnerabilities in Ivanti EPMM” (30.01.2026). (cow-prod-www-v3.azurewebsites.net)
5. NVD (NIST) — karta CVE-2026-1281 (publikacja 29.01.2026, KEV/due date 01.02.2026 widoczne w wpisie). (nvd.nist.gov)