Ostrzeżenie CISA z 13 października dotyczące Ivanti Connect Secure nie było środkiem ostrożności wobec hipotetycznej luki. Atakujący wykorzystali już łańcuch omijania uwierzytelniania i wykonywania kodu przeciwko urządzeniu, które miało wówczas wszystkie poprawki dla swojej gałęzi. Agencja dodała CVE-2026-104935 do katalogu Known Exploited Vulnerabilities i wyznaczyła federalnym instytucjom cywilnym termin usunięcia zagrożenia na 16 października.
Natychmiastowa aktualizacja i nierozwiązany incydent to odrębne problemy. Volexity opisuje wielokrotne wykorzystanie luki, tymczasowe zmiany pamięci, zbieranie poświadczeń i selektywne usuwanie dzienników bez typowego trwałego web shella. Aktualizacja zamyka udokumentowaną drogę wejścia, ale nie unieważnia skradzionych sekretów ani nie dowodzi, że wcześniej nie było dostępu.
Termin i wersje wymagające uwagi
Luka otrzymała wynik CVSS 8,6. Umożliwia zdalne wykonywanie poleceń przy niskiej złożoności ataku, bez istniejącego konta i bez działania użytkownika. Connect Secure znajduje się między internetem, aplikacjami wewnętrznymi i usługami tożsamości. Błąd uwierzytelniania zapewnia więc napastnikowi cenną, zaufaną pozycję.
Ukończone materiały wymieniają jako zagrożone wersje 25.1.1.1 i wcześniejsze w tej gałęzi, 25.1.2.2 i wcześniejsze oraz 22.8R2.4 i wcześniejsze. Poprawione wydania obejmują 25.1.1.2, 25.1.3.0, 25.1.3.1 i 22.8R2.5. Nie oznacza to dowolnego przechodzenia między gałęziami: administrator powinien dopasować instalację i wspieraną ścieżkę aktualizacji do komunikatu Ivanti.
Wyjątek dotyczący starszego oprogramowania opisano z różną precyzją. Główny tekst podaje 22.7.x i wcześniejsze, a scalony materiał oparty na CVE wskazuje 22.7R2.14 i wcześniejsze. Żaden zapis nie gwarantuje ogólnego bezpieczeństwa ani nie uzasadnia obniżenia wersji. Starsze wydania mogą mieć inne luki lub nie być już wspierane.
Aktualizacja KEV z 13 października dodała też Windows Shell CVE-2026-96951. To osobny problem wymagający interakcji użytkownika, inaczej niż bezpośrednia, nieuwierzytelniona droga Ivanti. Oba wpisy otrzymały termin 16 października dla Federal Civilian Executive Branch według przywołanych wymogów BOD 26-04. Firmy prywatne nie przejmują automatycznie obowiązków tej dyrektywy, ale dzielą techniczne ryzyko. Windows jest tu kontekstem, nie drugą luką Ivanti.
Wpis w KEV potwierdza zaobserwowane wykorzystanie, nie włamanie do każdego wystawionego urządzenia ani masową skalę. Pole dotyczące ransomware miało wartość nieznaną, a nie potwierdzony związek. Stwierdzenie Ivanti o ograniczonej znanej eksploatacji również opisuje widoczność firmy, nie wiarygodny górny limit ofiar.
Aktualna wówczas brama została zaatakowana przed ujawnieniem
Volexity rozpoczęła dochodzenie 5 października i prześledziła wykorzystanie do 3 października. Chodziło o Connect Secure 22.8R2.4, Build 19097, aktualny wtedy dla swojej gałęzi. Inny dostawca informacji o zagrożeniach miał widzieć powiązane oznaki od 1 października. Są to różne obserwacje; wcześniejszej daty nie należy przedstawiać jako potwierdzonej przez Volexity.
Firma śledzi niezidentyfikowaną aktywność jako UTA0576. To nazwa klastra analitycznego, a nie dowiedziona tożsamość organizacji lub sponsora państwowego. Z niską pewnością oceniła motyw jako przestępczy zamiast szpiegowskiego. Operację przerwano, zanim ustalono ostateczny cel.
Ivanti podała, że część problemu znalazła w programie bezpieczeństwa produktu i naprawiła w lipcowym wydaniu 25.1.3.0 z 2026 roku. Do ataków doszło podczas przenoszenia poprawki do innych wspieranych wersji. Powstała realna luka ochrony między gałęziami, ale publiczny opis nie ustala, kiedy firma zrozumiała cały łańcuch lub dowiedziała się o atakach. Prace nad zgodnością i przenoszeniem poprawek nie uzasadniają niepopartego zarzutu celowej zwłoki.
Tło obejmuje wykorzystywane luki Connect Secure: styczniowy przepełniony bufor stosu CVE-2025-0282 oraz CVE-2025-22457, później wiązaną ze szpiegostwem powiązanym z Chinami. Nie identyfikują one UTA0576 ani nie dowodzą zagrożenia każdego urządzenia. Volexity porównała też odzyskiwanie poświadczeń z przechwyconych pakietów do ataków na urządzenia zdalnego dostępu SonicWall. Pokazuje to szerszą atrakcyjność zaufanej infrastruktury brzegowej.
Trzy słabości prowadziły od publicznego żądania do root
Zrekonstruowany łańcuch zaczynał się od rozbieżności autoryzacji i routingu. Żądanie do publicznego elementu logowania welcome.cgi mogło podać inne miejsce docelowe w nagłówku X-DSCGI-PATH. Urządzenie sprawdzało publiczny URL, lecz kierowało ruch do chronionego modułu przesyłania wu.cgi.
Moduł zapisywał plik, zanim sprawdził poprawność archiwum ZIP. Skrypt Perl z takim rozszerzeniem istniał krótko przed odrzuceniem i usunięciem. Równoległe żądania wygrywały wyścig z czyszczeniem, umożliwiając wykonanie jako ograniczone konto cgi-server. To zależny od czasu błąd obsługi pliku, a nie dowód, że zwykłe archiwa ZIP są z natury wykonywalne.
Ivanti połączyła obejście uwierzytelniania i zdalne wykonanie pod CVE-2026-104935. Osobna eskalacja uprawnień wykorzystywała zaufanie uprzywilejowanej usługi do zmodyfikowanej konfiguracji oraz zmianę biblioteki w pamięci. Legalne zadanie konserwacyjne przekierowano do złośliwego skryptu wykonywanego jako root. Operator sprawdził dostęp do chronionych danych haseł, po czym przywrócił konfigurację i instrukcję pamięci.
W chwili ukończonych publikacji Ivanti planowała późniejszą poprawkę osobnej eskalacji. Nie oznacza to, że aktualizacja z 13 października pozostawia udokumentowaną drogę bez uwierzytelnienia otwartą: zablokowanie wejścia i wykonania przerywa ten konkretny łańcuch. Kolejne wydania producenta pozostają jednak ważne.
Zamiast pozostawić pierwszy backdoor, operator wielokrotnie wykorzystywał kanał luki do wysyłania poleceń i odbierania wyników przez HTTPS. Niektóre etapy działały tylko w pamięci, w tym skompresowany i zakodowany ładunek Python. Wybrane wpisy debugowania i audytu Linux usuwano, pliki tymczasowe i wyniki czyszczono, a zmieniony stan przywracano.
Volexity ustaliła, że metoda omijała Integrity Checker Tool Ivanti. Narzędzie szuka nieoczekiwanych zmian plików. Tymczasowe modyfikacje pamięci i przywrócona konfiguracja wykraczają poza to, co może wykluczyć czysty wynik kontroli dysku. Ogranicza to znaczenie wyniku, ale nie czyni sprawdzania integralności bezużytecznym.
Dane tożsamości rozszerzyły wpływ poza urządzenie
Dostęp bramy do katalogu umożliwił zapytania do wewnętrznego kontrolera domeny Active Directory. Śledczy odzyskali własne narzędzie LDAP i skrypty Python celujące w poświadczenia lokalnych administratorów LAPS, dane odzyskiwania BitLocker, atrybuty haseł, metadane użytkowników i ścieżki skryptów logowania. Dzienniki uwierzytelniania dostarczały poprawnych nazw użytkownika.
LAPS może otworzyć dostęp administratora lokalnego, a dane BitLocker odblokować zaszyfrowany dysk. Volexity z wysoką pewnością oceniła, że informacje dostępne przez konkretne zapytania katalogowe zostały wyprowadzone. Nie dowodzi to istnienia każdego poszukiwanego sekretu ani powodzenia wszystkich dalszych włamań.
Operator przeglądał także przechwycone pakiety w poszukiwaniu jawnych poświadczeń LDAP, HTTP Basic i skrótów NTLM challenge-response. Narzędzie ze zmienioną nazwą w ukrytym katalogu obserwowało m.in. LDAP, HTTP, FTP i Telnet, wykorzystując osiem rotowanych plików. Ryzyko nadużycia skrótów i łamania offline zależy od konfiguracji i siły haseł. Zebrany materiał tworzy jednak problem, którego aktualizacja VPN nie cofa.
Dalsze działania obejmowały rozpoznanie DNS i nazw hostów, wyszukiwanie konfiguracji VPN i dzienników oraz password spraying wobec kont katalogowych. Łącznie wspierały ocenę przygotowania do ruchu bocznego i szerszego dostępu. Nie ustalono ostatecznego celu ani sukcesu każdej techniki.
Ostrożności wymaga też twierdzenie o AI ze scalonego materiału. Volexity ze średnią pewnością oceniła użycie dużych modeli językowych podczas tworzenia exploita lub działań po włamaniu, wskazując dopasowane skrypty, wpisane na stałe poświadczenia, powtarzanie kanału poleceń i złożoność łańcucha. To wnioskowanie, nie bezpośredni dowód. Ludzkie iteracje i istniejące prywatne narzędzia mogą dawać podobne wzorce; nie potwierdza to autonomicznego ataku AI.
Jakich dowodów wymaga wiarygodne zamknięcie
Shadowserver naliczył po ujawnieniu ponad 5500 pozornie dostępnych z internetu instancji Connect Secure. To obserwacja ekspozycji, a nie liczba podatnych lub zaatakowanych klientów. Mogą obejmować pułapki, powtórzenia i zaktualizowane systemy. Inwentaryzacja powinna uwzględniać aktywne i zapasowe bramy, węzły odtworzeniowe i zapomniane testy, a następnie sprawdzać faktyczne kompilacje.
Ivanti zalecała natychmiastowe aktualizacje i regularne kontrole integralności; Rapid7 dodatkowo podkreślał poszukiwanie włamania po łataniu. Okres ekspozycji, połączenia wychodzące z bramy, logi tożsamości i katalogu, firewall, DNS i zachowana pamięć odpowiadają na inne pytania niż wersja. Nietypowa liczba żądań welcome.cgi i rozbieżności URL/nagłówka są wskazówkami, ale napastnicy je zmieniają. Brak opublikowanych wskaźników nie daje uniwersalnego oczyszczenia.
Izolacja i ochrona dowodów mogą się ścierać. Restart lub odbudowa niszczy ślady ulotne; opóźnienie izolacji może wydłużyć dostęp napastnika. Kolejność zależy od bieżącego ryzyka, redundancji i możliwości śledczych. Zespół powinien koordynować zbieranie bez niepotrzebnego przedłużania dostępu i dokumentować działania wraz z czasem.
Rotacja poświadczeń powinna wynikać z integracji bramy, dostępnych sekretów i zaobserwowanej aktywności. Poświadczenia usług, hasła lokalnych administratorów, klucze odzyskiwania, tokeny i wielokrotnie używane sekrety użytkowników wymagają osobnego rozważenia. Ślepe resetowanie może zaburzyć zależności i pominąć mniej widoczne dane. Połączenia dalszych systemów pochodzące z zaufanej bramy trzeba badać oddzielnie.
Długofalowo warto ograniczać zbędne wystawienie internetu i administracji, centralizować logi, minimalizować uprawnienia kont katalogowych, segmentować sieć oraz usuwać jawne protokoły uwierzytelniania. Nie eliminuje to zero-day, lecz ogranicza zasięg jednej przejętej maszyny i dowody, które może ona usunąć.
Kolejne sygnały to nowe ataki i ofiary, potwierdzone pokrycie poprawek we wspieranych gałęziach, osobna poprawka eskalacji oraz użycie skradzionych sekretów w dalszych systemach. Volexity nie udostępniła gotowego kodu ofensywnego, lecz analiza techniczna może pomóc naśladowcom. Brak nowych publicznych przypadków nie wyklucza dalszych włamań.
Zamknięcie wymaga osobnych odpowiedzi o podatnej wersji, ekspozycji w oknie ataków, śladach dostępu oraz później osiągalnych systemach i sekretach. Ukończona aktualizacja odpowiada na pierwsze pytanie. Jest niezbędnym etapem, a nie zamiennikiem pozostałych trzech.