Archiwa: Security News - Strona 206 z 346

Masowe skanowanie Salesforce Experience Cloud zwiększa ryzyko ujawnienia danych

Wprowadzenie do problemu

Salesforce ostrzegł przed nasilonymi działaniami cyberprzestępców wymierzonymi w publicznie dostępne wdrożenia Experience Cloud. Problem nie wynika z nowej luki w samej platformie, lecz z błędów konfiguracyjnych dotyczących profilu użytkownika gościnnego, które mogą prowadzić do nieautoryzowanego dostępu do danych udostępnionych zbyt szeroko.

W praktyce oznacza to, że źródłem ryzyka staje się niewłaściwie skonfigurowany model uprawnień. Jeśli anonimowy użytkownik otrzyma dostęp do obiektów, rekordów lub pól, które nie powinny być publiczne, napastnik może wykorzystać tę ekspozycję do pozyskiwania danych bez logowania.

W skrócie

Obecna kampania opiera się na masowym skanowaniu publicznych witryn Salesforce Experience Cloud z użyciem zmodyfikowanego narzędzia AuraInspector. Atakujący sondują publiczne endpointy Aura i sprawdzają, czy konfiguracja konta gościnnego umożliwia odczyt danych z obiektów CRM.

Atak nie wymaga wykorzystania klasycznej podatności platformowej.
Kluczowym problemem są nadmierne uprawnienia profilu guest user.
Zmodyfikowane narzędzie służy nie tylko do wykrywania ekspozycji, ale również do pobierania danych.
Ryzyko obejmuje wyciek informacji, rekonesans i wsparcie dla dalszych ataków socjotechnicznych.

Kontekst i historia

Experience Cloud jest szeroko wykorzystywany do budowy portali dla klientów, partnerów i użytkowników zewnętrznych. W wielu scenariuszach biznesowych część treści musi być dostępna anonimowo, dlatego organizacje korzystają z profilu guest user. To rozwiązanie jest uzasadnione operacyjnie, ale od lat pozostaje obszarem podwyższonego ryzyka, jeśli nie jest objęte restrykcyjną polityką uprawnień.

Producent już wcześniej podkreślał znaczenie modelu współdzielonej odpowiedzialności i konieczność ograniczania dostępu użytkowników niezalogowanych. Obecna fala aktywności pokazuje, że znane błędy konfiguracyjne są dziś wykorzystywane na większą skalę i automatyzowane przez grupy przestępcze, które szukają źle zabezpieczonych środowisk w sposób przemysłowy.

Analiza techniczna

Z technicznego punktu widzenia atak koncentruje się na publicznie dostępnych witrynach Experience Cloud oraz endpointach związanych z frameworkiem Aura, w szczególności ścieżce wykorzystywanej do komunikacji aplikacyjnej. Oryginalny AuraInspector służył do audytu i identyfikowania problemów z kontrolą dostępu, jednak jego zmodyfikowana wersja została przystosowana do masowego rozpoznania oraz ekstrakcji informacji.

Mechanizm nadużycia jest prosty: użytkownik anonimowy dziedziczy dokładnie takie uprawnienia, jakie nada mu administrator. Jeżeli środowisko umożliwia gościowi odczyt określonych obiektów, pól lub rekordów, napastnik może zadawać zapytania i pobierać dane bez procesu uwierzytelnienia. Nie dochodzi więc do przełamania zabezpieczeń platformy, lecz do wykorzystania błędnie ustawionych reguł autoryzacji.

Powodzenie ataku zależy przede wszystkim od dwóch warunków. Po pierwsze, organizacja musi faktycznie korzystać z profilu gościnnego w publicznym serwisie. Po drugie, konfiguracja musi dopuszczać szerszy dostęp niż wymagany przez funkcję portalu. Jeśli oba warunki są spełnione, skanowanie może szybko przejść w zautomatyzowane pobieranie danych.

Szczególnie niebezpieczne są ustawienia pozwalające na zbyt szeroki dostęp do obiektów i pól, liberalne zasady współdzielenia rekordów, aktywne publiczne API, widoczność użytkowników portalu oraz nieodpowiednio zabezpieczona samorejestracja. Tego typu błędy zwiększają nie tylko ryzyko wycieku, ale także ułatwiają enumerację użytkowników i przygotowanie kolejnych etapów ataku.

Konsekwencje i ryzyko

Najbardziej bezpośrednim skutkiem jest ujawnienie danych, które organizacja uznawała za niepubliczne. Mogą to być dane kontaktowe, informacje biznesowe, metadane środowiska lub inne zasoby CRM, które z perspektywy napastnika mają wysoką wartość operacyjną.

Nawet ograniczony wyciek może stać się paliwem dla kolejnych działań. Pozyskane nazwiska, numery telefonów, role użytkowników i powiązania organizacyjne mogą zostać użyte w kampaniach phishingowych lub vishingowych, a także do budowy wiarygodnych scenariuszy podszywania się pod wsparcie techniczne, administratorów lub partnerów biznesowych.

Ryzyko ma również wymiar regulacyjny i reputacyjny. Ujawnienie danych z systemów CRM może prowadzić do obowiązków notyfikacyjnych, kosztownych analiz incydentu, pilnych przeglądów konfiguracji wielu serwisów oraz utraty zaufania klientów i partnerów. Dodatkowo masowa automatyzacja skanowania skraca czas między pojawieniem się błędu a jego wykryciem przez przeciwnika.

Rekomendacje

Organizacje korzystające z Salesforce Experience Cloud powinny potraktować to ostrzeżenie jako sygnał do natychmiastowego przeglądu konfiguracji. Najważniejszym krokiem jest audyt uprawnień profilu guest user i ograniczenie ich do absolutnego minimum wymaganego przez funkcje serwisu.

Usunąć zbędne uprawnienia do obiektów, rekordów i pól.
Zweryfikować, czy użytkownik anonimowy rzeczywiście musi mieć dostęp do danych biznesowych.
Ustawić Default External Access na poziomie prywatnym tam, gdzie to możliwe.
Wyłączyć publiczne API dla gości i sprawdzić, czy nie pozostawiono aktywnego uprawnienia API Enabled.
Ograniczyć widoczność użytkowników portalu i serwisu.
Wyłączyć samorejestrację, jeśli nie jest niezbędna biznesowo, lub wdrożyć dodatkowe mechanizmy walidacji.

Równie ważny jest monitoring. Zespoły bezpieczeństwa powinny analizować logi pod kątem nietypowych zapytań Aura, wzrostu liczby odwołań do publicznych endpointów, prób odczytu zasobów, które nie powinny być publiczne, oraz aktywności z nietypowych adresów IP. Warto także włączyć regularne przeglądy konfiguracji Experience Cloud do standardowego procesu zarządzania zmianą.

Podsumowanie

Masowe skanowanie Salesforce Experience Cloud z użyciem zmodyfikowanego AuraInspector pokazuje, że błędy konfiguracji pozostają jednym z najpoważniejszych zagrożeń w środowiskach SaaS. Atakujący nie muszą wykorzystywać nowej podatności, jeśli organizacja sama dopuści zbyt szeroki dostęp dla użytkownika anonimowego.

Dla administratorów i zespołów bezpieczeństwa to wyraźny sygnał, że ochrona danych w chmurze zależy nie tylko od bezpieczeństwa dostawcy, ale również od jakości lokalnej konfiguracji. Zasada najmniejszych uprawnień, regularne audyty oraz monitoring anomalii powinny być podstawą obrony przed podobnymi kampaniami.

Źródła

LeakyLooker w Google Looker Studio: dziewięć luk mogło umożliwić międzytenantowe zapytania SQL

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili zestaw dziewięciu podatności określonych zbiorczo jako „LeakyLooker”, które dotyczyły Google Looker Studio. Problem dotyczył naruszenia granic izolacji pomiędzy tenantami oraz podważał podstawowy model zaufania platformy analitycznej, w którym użytkownik z uprawnieniami podglądu nie powinien wpływać na wykonywane zapytania ani korzystać z poświadczeń właściciela źródła danych.

W praktyce opisane błędy mogły prowadzić do wykonywania dowolnych zapytań SQL, eksfiltracji danych, a w wybranych scenariuszach również do modyfikacji zasobów w środowiskach Google Cloud. To stawia incydent w gronie najpoważniejszych klas ryzyka dla nowoczesnych platform BI działających jako pośrednik między użytkownikiem a systemami danych.

W skrócie

Zidentyfikowano dziewięć podatności cross-tenant w Google Looker Studio.
Najgroźniejsze scenariusze obejmowały zero-click SQL injection oraz nadużycie zapisanych poświadczeń.
Ryzyko dotyczyło m.in. BigQuery, Spanner, PostgreSQL, MySQL, Google Sheets i Cloud Storage.
Nie ma publicznych dowodów na aktywne wykorzystanie luk w środowisku produkcyjnym.
Problemy zostały usunięte po odpowiedzialnym zgłoszeniu.

Kontekst / historia

Looker Studio pełni rolę warstwy wizualizacyjnej i raportowej, która łączy użytkowników z wieloma źródłami danych. Tego typu platformy są szczególnie wrażliwe na błędy logiczne, ponieważ operują jednocześnie na uprawnieniach użytkownika końcowego, właściciela raportu, konektorów danych i usług backendowych.

W opublikowanych materiałach wskazano, że podatności zostały zgłoszone w czerwcu 2025 roku, a następnie naprawione przez Google. Istotne jest jednak to, że nie chodziło o pojedynczy błąd implementacyjny, lecz o całą klasę problemów architektonicznych związanych z kopiowaniem raportów, zaufaniem do danych wejściowych i pośredniczeniem w dostępie do danych „na żywo”.

Analiza techniczna

Najpoważniejsze scenariusze dotyczyły podatności typu zero-click. W jednym z nich manipulacja kontrolowanym przez użytkownika aliasem kolumny prowadziła do zbudowania niebezpiecznego zapytania SQL po stronie backendu. Mechanizm generowania zapytań dla źródeł takich jak BigQuery okazywał się podatny na wstrzyknięcie, gdy odpowiednio spreparowane dane wejściowe były łączone z instrukcją SQL.

Badacze opisali również obejścia filtrów znaków, w tym wykorzystanie komentarzy SQL zamiast spacji oraz funkcji skryptowych do odtwarzania znaków specjalnych w trakcie wykonywania zapytania. To pokazuje, że nawet częściowa walidacja danych wejściowych nie była wystarczająca, jeśli logika budowania zapytań pozostawała podatna na manipulację.

Druga ważna ścieżka ataku wiązała się z funkcją kopiowania raportu. W przypadku niektórych źródeł JDBC, takich jak PostgreSQL czy MySQL, sklonowany raport mógł zachowywać zapisane poświadczenia oryginalnego właściciela. Oznaczało to, że użytkownik z samym prawem podglądu, po utworzeniu kopii, stawał się właścicielem nowego raportu, ale nadal korzystał z cudzego kontekstu uwierzytelnienia do źródła danych.

Opisano także scenariusze jednoklikowe, w których odpowiednio przygotowany raport mógł skłonić przeglądarkę ofiary do wykonania działań w jej własnym kontekście dostępowym. W połączeniu z natywnymi funkcjami platformy otwierało to drogę do eksfiltracji danych, wycieków przez hiperłącza i renderowanie obrazów, a także do technik XS-Leak opartych na obserwacji zachowania interfejsu.

Technicznie przypadek ten jest szczególnie interesujący, ponieważ źródłem ryzyka nie był wyłącznie klasyczny błąd walidacji wejścia. Problem wynikał z tego, że platforma BI działała jako zaufany broker pomiędzy różnymi granicami bezpieczeństwa: przeglądarką użytkownika, raportem, backendem usługi i docelową bazą danych. Gdy ta warstwa błędnie łączyła uprawnienia właściciela, widza i mechanizmy kopiowania obiektów, izolacja między tenantami przestawała działać zgodnie z założeniami.

Konsekwencje / ryzyko

Wpływ biznesowy takich podatności jest bardzo wysoki. W scenariuszu skutecznego ataku możliwe było odczytywanie danych z baz i zbiorów analitycznych, wykonywanie arbitralnych zapytań SQL, a w części przypadków również modyfikowanie lub usuwanie danych. To oznacza realne zagrożenie dla poufności, integralności i dostępności informacji.

Dla organizacji korzystających z Looker Studio jako wspólnej warstwy raportowej problem był szczególnie groźny. Raporty bywają bowiem udostępniane szeroko wewnątrz firm, partnerom biznesowym, a czasem nawet publicznie. Jeżeli jednocześnie konektory do systemów produkcyjnych działają na uprzywilejowanych kontach lub zapisanych poświadczeniach właściciela, kompromitacja jednego raportu może otworzyć drogę do znacznie większego obszaru środowiska.

Na uwagę zasługuje również ryzyko finansowe określane jako „denial of wallet”. W usługach rozliczanych za wykonane zapytania, takich jak BigQuery, wymuszenie kosztownych operacji analitycznych może prowadzić do wymiernych strat finansowych nawet wtedy, gdy atakujący nie doprowadzi do klasycznej kradzieży danych.

Rekomendacje

Organizacje korzystające z platform BI i konektorów do danych chmurowych powinny traktować warstwę raportową jako element podwyższonego ryzyka, a nie wyłącznie neutralny interfejs wizualizacyjny. Kluczowe działania obronne obejmują zarówno kontrolę dostępu, jak i monitorowanie aktywności na poziomie usług danych.

Przeprowadzić przegląd wszystkich raportów publicznych i współdzielonych oraz ograniczyć ich ekspozycję do minimum.
Zweryfikować, które źródła danych działają na poświadczeniach właściciela, a gdzie można przejść na model uprawnień użytkownika.
Rotować zapisane poświadczenia dla krytycznych źródeł danych i stosować konta o najmniejszych możliwych uprawnieniach.
Ograniczyć możliwość wykonywania niestandardowych zapytań SQL i funkcji natywnych tam, gdzie nie są niezbędne.
Segmentować projekty analityczne i oddzielać je od systemów produkcyjnych.
Monitorować nietypowe zapytania, wzrost kosztów przetwarzania i anomalie w logach usług danych.
Regularnie przeglądać uprawnienia współdzielenia raportów, źródeł danych i kopiowanych obiektów.
Uwzględniać w testach bezpieczeństwa błędy logiczne i architektoniczne, a nie tylko klasyczne podatności wejścia/wyjścia.

Z perspektywy zespołów SOC i cloud security szczególnie ważne jest korelowanie zdarzeń z kilku warstw jednocześnie: działań użytkownika w raporcie, operacji backendowych usługi BI oraz wykonania zapytań po stronie docelowych baz danych. Tylko taka telemetria pozwala zauważyć nadużycia, które formalnie mogą wyglądać jak legalne działania zaufanego komponentu.

Podsumowanie

LeakyLooker pokazuje, że nowoczesne platformy analityczne mogą stać się wektorem ataku o szerokim zasięgu, jeśli łączą dane wielu tenantów, dynamiczne zapytania i złożony model współdzielenia. W tym przypadku szczególnie niebezpieczne okazało się połączenie błędów logicznych, niewłaściwego zarządzania poświadczeniami oraz niewystarczającej izolacji pomiędzy rolą widza i właściciela.

Choć opisane luki zostały już naprawione, sprawa stanowi ważne ostrzeżenie dla organizacji budujących analitykę w chmurze. Bezpieczna architektura BI wymaga nie tylko szybkiego łatania podatności, ale również ścisłej kontroli modeli zaufania, poświadczeń, współdzielenia raportów oraz zakresu uprawnień przypisanych konektorom danych.

Źródła

FortiGate jako punkt wejścia do sieci: kradzież kont usługowych i kompromitacja Active Directory

Wprowadzenie do problemu / definicja

Urządzenia FortiGate od lat stanowią kluczowy element ochrony styku sieci wewnętrznej z internetem. Problem pojawia się jednak wtedy, gdy sama zapora staje się celem skutecznego ataku, ponieważ jej przejęcie może otworzyć napastnikom drogę nie tylko do zarządzania ruchem sieciowym, ale również do konfiguracji, danych uwierzytelniających oraz informacji o architekturze środowiska.

W analizowanych incydentach FortiGate nie było jedynie pojedynczym punktem naruszenia. Po uzyskaniu dostępu do urządzenia atakujący wykorzystywali je jako przyczółek do dalszej penetracji infrastruktury Windows, przejmowania kont usługowych oraz operacji wymierzonych w Active Directory.

W skrócie

Badacze opisali scenariusze, w których FortiGate był wykorzystywany jako wektor wejścia do sieci. Napastnicy uzyskiwali dostęp administracyjny przez podatności lub słabe dane logowania, a następnie eksportowali konfigurację urządzenia, odzyskiwali poświadczenia kont usługowych i pozyskiwali informacje o topologii środowiska.

tworzenie nowych kont administratora na FortiGate,
modyfikacja reguł firewall w celu ułatwienia ruchu bocznego,
dołączanie nieautoryzowanych stacji roboczych do domeny,
wdrażanie narzędzi zdalnego zarządzania,
próby pozyskania pliku NTDS.dit z kontrolerów domeny.

Kontekst / historia

Kampania została zaobserwowana na przełomie końca 2025 i początku 2026 roku. W tym okresie szczególne znaczenie miały luki CVE-2025-59718, CVE-2025-59719 oraz CVE-2026-24858, powiązane z mechanizmami FortiCloud SSO i błędami w procesie uwierzytelniania.

W praktyce problem nie ograniczał się do samego urządzenia brzegowego. FortiGate w wielu organizacjach współpracuje z LDAP i Active Directory, używając kont usługowych do mapowania użytkowników, grup i polityk dostępu. To sprawia, że kompromitacja zapory może stać się bezpośrednim pomostem do naruszenia tożsamości domenowych.

Analiza techniczna

W opisywanych przypadkach atakujący uzyskiwali dostęp administracyjny do FortiGate na dwa główne sposoby: poprzez aktywnie wykorzystywane podatności albo w wyniku błędnej konfiguracji i słabych haseł. Następnie eksportowali konfigurację FortiOS, która mogła zawierać zaszyfrowane poświadczenia kont usługowych wykorzystywanych do integracji z LDAP lub Active Directory.

Po wyeksportowaniu konfiguracji napastnicy odzyskiwali hasła i wykorzystywali je do logowania w środowisku domenowym. W jednym z incydentów zdobyte konto usługowe posłużyło do uwierzytelnienia w Active Directory i dołączenia dwóch nieautoryzowanych stacji roboczych do domeny. Taki ruch umożliwia obejście części mechanizmów kontroli dostępu i stanowi skuteczną bazę do dalszych działań.

Atak obejmował również utrwalenie dostępu na samym urządzeniu brzegowym. Tworzono lokalne konta administracyjne oraz dodawano nowe reguły firewall, które ułatwiały komunikację między segmentami sieci. W drugim przypadku napastnicy bardzo szybko przeszli do logowania na serwery z użyciem przejętych poświadczeń uprzywilejowanych, wdrożyli legalne narzędzia zdalnego zarządzania oraz uruchomili złośliwy ładunek z wykorzystaniem techniki DLL side-loading.

Końcowym celem była próba pozyskania pliku NTDS.dit i gałęzi SYSTEM z kontrolera domeny. Taki zestaw danych pozwala na dalsze łamanie skrótów haseł, eskalację uprawnień i rozszerzenie kompromitacji na całą organizację.

Istotnym problemem okazał się również ograniczony poziom widoczności. Krótka retencja logów na urządzeniach brzegowych utrudniała ustalenie dokładnego momentu wejścia, przebiegu ataku oraz rzeczywistej skali naruszenia.

Konsekwencje / ryzyko

Kompromitacja FortiGate wiąże się z wysokim ryzykiem operacyjnym. Urządzenie znajduje się na styku internetu i sieci wewnętrznej, a jednocześnie często posiada relacje z systemami tożsamości, co czyni je szczególnie wartościowym celem.

utrata poufności danych uwierzytelniających,
manipulacja politykami bezpieczeństwa i ruchem sieciowym,
możliwość nieautoryzowanego dołączania hostów do domeny,
szybki ruch boczny do serwerów i kontrolerów domeny,
utrwalenie dostępu przez konta lokalne i narzędzia RMM,
kradzież danych z Active Directory i pełna eskalacja uprawnień.

Dodatkowym zagrożeniem jest fakt, że urządzenia brzegowe nie zawsze są objęte równie rozbudowanym monitoringiem jak stacje końcowe i serwery. Ograniczona telemetria, brak EDR oraz niewystarczająca retencja logów wydłużają czas niewykrytej obecności napastnika.

Rekomendacje

Organizacje powinny traktować FortiGate jako system krytyczny nie tylko z perspektywy sieci, ale także bezpieczeństwa tożsamości i domeny. Samo aktualizowanie urządzenia nie wystarczy, jeśli równolegle nie zostaną zabezpieczone konta usługowe, interfejsy administracyjne i procesy monitorowania.

zweryfikować wersję FortiOS i niezwłocznie wdrożyć poprawki dla wskazanych podatności,
wyłączyć FortiCloud SSO tam, gdzie nie jest niezbędne,
ograniczyć dostęp administracyjny wyłącznie do zaufanych segmentów i zabezpieczyć go MFA,
przeprowadzić rotację haseł wszystkich kont usługowych powiązanych z LDAP i AD,
przejrzeć lokalne konta administratorów oraz historię zmian polityk firewall,
monitorować eksport konfiguracji i nietypowe logowania administracyjne,
zwiększyć retencję logów urządzeń NGFW do co najmniej kilkunastu dni, a najlepiej do 60–90 dni,
centralizować logi w systemie SIEM,
analizować zdarzenia domenowe związane z nowymi komputerami, nietypowymi logowaniami i zmianami w katalogu,
zweryfikować ustawienia umożliwiające dołączanie maszyn do domeny bez ścisłej kontroli.

W środowiskach, gdzie istnieje podejrzenie naruszenia, warto dodatkowo sprawdzić, czy nie doszło do eksportu konfiguracji z FortiGate, utworzenia nowych kont lokalnych, logowań z adresów powiązanych z VPN zapory do serwerów domenowych oraz instalacji narzędzi zdalnego zarządzania.

Podsumowanie

Opisane incydenty pokazują, że nowoczesna zapora sieciowa może stać się nie tylko narzędziem ochrony, ale również wyjątkowo skutecznym punktem wejścia do środowiska firmowego. Kompromitacja FortiGate może prowadzić do przejęcia kont usługowych, obejścia segmentacji, ruchu bocznego i pełnego naruszenia Active Directory.

Dla obrony kluczowe znaczenie mają szybkie łatanie podatności, ścisła kontrola dostępu administracyjnego, regularna rotacja poświadczeń oraz pełna widoczność telemetryczna z urządzeń brzegowych. Bez tych działań firewall może przestać pełnić funkcję bariery i sam stać się najgroźniejszym elementem łańcucha ataku.

Źródła

Krytyczna luka w HPE Aruba AOS-CX pozwala na reset hasła administratora

Wprowadzenie do problemu / definicja

Hewlett Packard Enterprise usunęło wiele podatności bezpieczeństwa w systemie Aruba Networking AOS-CX, wykorzystywanym w przełącznikach serii CX dla środowisk kampusowych i centrów danych. Najpoważniejsza z nich, oznaczona jako CVE-2026-23813, dotyczy webowego interfejsu zarządzania i może umożliwić nieuwierzytelnionemu atakującemu obejście mechanizmów kontroli dostępu oraz zdalny reset hasła konta administracyjnego.

To szczególnie groźny scenariusz, ponieważ płaszczyzna zarządzania urządzeniami sieciowymi stanowi jeden z najbardziej wrażliwych elementów infrastruktury enterprise. Przejęcie dostępu administracyjnego do przełącznika może otworzyć drogę do dalszej kompromitacji sieci, zmian konfiguracji i zakłócenia pracy usług.

W skrócie

Najważniejsza luka została oznaczona jako CVE-2026-23813.
Podatność dotyczy webowego interfejsu zarządzania HPE Aruba AOS-CX.
Atak może umożliwić obejście uwierzytelnienia i reset hasła administratora.
Producent udostępnił poprawki oraz zalecenia ograniczające ekspozycję.
W chwili publikacji nie wskazano publicznego exploitu ani potwierdzonego aktywnego wykorzystania.

Kontekst / historia

AOS-CX to system operacyjny odpowiedzialny za funkcje administracyjne, konfigurację, telemetrię i integrację operacyjną przełączników Aruba CX. Z perspektywy bezpieczeństwa oznacza to, że każda luka w interfejsie zarządzającym może mieć bezpośredni wpływ na integralność i dostępność całego środowiska sieciowego.

Informacja o CVE-2026-23813 wpisuje się w szerszy trend rosnącej liczby zagrożeń wymierzonych w urządzenia infrastrukturalne i ich płaszczyzny zarządzania. Dla zespołów bezpieczeństwa to kolejny sygnał, że przełączniki, routery i kontrolery powinny być objęte takim samym poziomem nadzoru jak serwery, stacje robocze i aplikacje.

Analiza techniczna

Z opisu producenta wynika, że problem dotyczy klasy authentication bypass w webowym interfejsie administracyjnym AOS-CX. Tego rodzaju błąd oznacza możliwość ominięcia standardowego procesu autoryzacji bez użycia prawidłowych poświadczeń. W praktyce przyczyną mogą być błędy w logice sesji, walidacji żądań, egzekwowaniu kontroli dostępu lub obsłudze mechanizmów resetu danych administracyjnych.

Najbardziej niebezpieczny aspekt tej luki polega na możliwości zresetowania hasła administratora. W efekcie atakujący może uzyskać kontrolę nad urządzeniem na poziomie zarządczym i wykonywać działania o wysokim wpływie operacyjnym.

modyfikować konfigurację urządzenia,
zmieniać polityki dostępu i segmentacji,
manipulować trasami i interfejsami,
osłabiać mechanizmy bezpieczeństwa,
przygotowywać środowisko do dalszego ruchu bocznego.

Producent wskazał, że atak nie wymaga uprzywilejowanego konta i może cechować się niską złożonością. Nawet jeśli w momencie publikacji nie było informacji o publicznym kodzie exploit ani aktywnej eksploatacji, samo opublikowanie biuletynu i aktualizacji zwiększa ryzyko szybkiego opracowania skutecznych metod ataku na podstawie analizy różnic między wersjami oprogramowania.

Konsekwencje / ryzyko

Ryzyko biznesowe i operacyjne związane z CVE-2026-23813 jest wysokie, ponieważ podatność dotyczy krytycznego elementu infrastruktury. Przejęcie konta administratora na przełączniku może przełożyć się na szeroki zakres negatywnych skutków dla organizacji.

utrata integralności konfiguracji sieci,
nieautoryzowane zmiany polityk i tras ruchu,
zakłócenie dostępności usług,
osłabienie widoczności i zdolności detekcyjnych,
umożliwienie dalszych ataków wewnętrznych,
potencjalne przekierowywanie lub przechwytywanie ruchu.

Największe zagrożenie występuje tam, gdzie interfejsy administracyjne są dostępne z rozległych segmentów sieci, stref użytkowników, niedostatecznie chronionych sieci zarządzających lub nawet z zewnątrz. W takich warunkach podatność może stać się punktem wejścia do kompromitacji newralgicznej warstwy infrastrukturalnej.

Rekomendacje

Organizacje korzystające z HPE Aruba AOS-CX powinny potraktować tę lukę priorytetowo i wdrożyć działania ograniczające ryzyko bez zbędnej zwłoki.

Zidentyfikować wszystkie urządzenia działające na podatnych wersjach AOS-CX.
Niezwłocznie zastosować oficjalne poprawki producenta.
Ograniczyć dostęp do interfejsów zarządzania wyłącznie do wydzielonej sieci administracyjnej.
Wyłączyć HTTP i HTTPS tam, gdzie zarządzanie webowe nie jest niezbędne.
Wdrożyć ścisłe filtrowanie ruchu do interfejsów REST i HTTPS z użyciem ACL oraz segmentacji.
Zwiększyć poziom logowania i monitorowania operacji administracyjnych.
Analizować logi pod kątem prób nieautoryzowanego dostępu, zmian haseł i modyfikacji konfiguracji.
Zweryfikować gotowość do rotacji poświadczeń administracyjnych i odtworzenia zaufanej konfiguracji.
Przeprowadzić szerszy przegląd ekspozycji interfejsów zarządzania w całej infrastrukturze.

Z perspektywy defensywnej warto również rozważyć korzystanie z bastionów administracyjnych, pełne rejestrowanie działań uprzywilejowanych oraz dodatkową kontrolę zmian konfiguracyjnych w ramach procesów operacyjnych.

Podsumowanie

Podatność CVE-2026-23813 w HPE Aruba AOS-CX pokazuje, jak poważne konsekwencje mogą mieć błędy w interfejsach zarządzania urządzeń sieciowych. Możliwość obejścia uwierzytelnienia i resetu hasła administratora stwarza realne ryzyko przejęcia kontroli nad kluczowymi elementami infrastruktury.

Nawet przy braku publicznie dostępnego exploitu organizacje nie powinny odkładać działań naprawczych. Priorytetem pozostaje szybkie wdrożenie poprawek, ograniczenie dostępu do płaszczyzny zarządzania oraz wzmożone monitorowanie aktywności administracyjnej.

Źródła

BleepingComputer – HPE warns of critical AOS-CX flaw allowing admin password resets — https://www.bleepingcomputer.com/news/security/hpe-warns-of-critical-aos-cx-flaw-allowing-admin-password-resets/
HPE Support Center – Security bulletin for Aruba Networking AOS-CX vulnerabilities — https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04823en_us&docLocale=en_US

Phishing przez Microsoft Teams i Quick Assist prowadzi do wdrożenia A0Backdoor

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej odchodzą od klasycznych kampanii e-mailowych i wykorzystują narzędzia, które w środowisku firmowym uchodzą za całkowicie normalne. Jednym z takich kanałów jest Microsoft Teams, używany na co dzień do komunikacji wewnętrznej, współpracy projektowej i kontaktu z działem wsparcia IT.

W opisywanej kampanii napastnicy podszywali się pod pracowników pomocy technicznej, a następnie przekonywali ofiary do uruchomienia Quick Assist, legalnego narzędzia zdalnego wsparcia dostępnego w systemie Windows. Celem było wdrożenie malware A0Backdoor i uzyskanie trwałego dostępu do zainfekowanego systemu.

W skrócie

Kampania była wymierzona między innymi w organizacje z sektora finansowego i ochrony zdrowia. Atak rozpoczynał się od działań socjotechnicznych, w tym zasypywania ofiary spamem, po czym następował kontakt przez Teams pod pretekstem pomocy technicznej.

napastnicy wykorzystywali Microsoft Teams do budowania wiarygodności,
ofiary były nakłaniane do uruchomienia Quick Assist,
po uzyskaniu dostępu instalowano podpisane pakiety MSI podszywające się pod legalne komponenty,
malware stosował DLL sideloading i odszyfrowywał ładunek w pamięci,
komunikacja z serwerem sterującym była ukrywana w zapytaniach DNS MX.

Kontekst / historia

Ten przypadek wpisuje się w szerszy trend nadużywania legalnych narzędzi administracyjnych i komunikacyjnych. Współczesne środowiska pracy opierają się na komunikatorach biznesowych, platformach współpracy i zdalnym wsparciu, dlatego użytkownicy są bardziej skłonni ufać wiadomościom otrzymanym przez znane aplikacje niż tradycyjnym e-mailom phishingowym.

Atak odzwierciedla także podejście living-off-the-land, czyli wykorzystywanie zaufanych aplikacji i natywnych mechanizmów systemowych do ukrycia złośliwej aktywności. Dzięki temu operatorzy mogą ograniczyć liczbę oczywistych artefaktów i utrudnić wykrycie incydentu przez klasyczne narzędzia bezpieczeństwa.

Badacze zwracają uwagę, że część zastosowanych metod przypomina techniki obserwowane wcześniej w operacjach powiązanych z grupami ransomware, zwłaszcza w obszarze socjotechniki i nadużywania legalnych narzędzi dostępowych. Jednocześnie połączenie podpisanych instalatorów MSI, A0Backdoor oraz komunikacji C2 przez rekordy DNS MX pokazuje rozwój bardziej wyspecjalizowanych technik operacyjnych.

Analiza techniczna

Łańcuch ataku zaczynał się od przygotowania psychologicznego ofiary. Napastnicy generowali presję i dezorientację poprzez zalew niechcianymi wiadomościami, a następnie kontaktowali się przez Teams jako rzekomy dział IT. Taki scenariusz zwiększał szansę, że pracownik uzna rozmowę za uzasadnioną interwencję techniczną.

Następnie ofiara była nakłaniana do uruchomienia Quick Assist. Po zestawieniu sesji zdalnej operator wdrażał zestaw złośliwych komponentów hostowanych w infrastrukturze chmurowej Microsoft. Wśród nich znajdowały się podpisane cyfrowo pakiety MSI, które podszywały się pod elementy Microsoft Teams oraz legalne usługi systemowe Windows.

Kluczową rolę odgrywała technika DLL sideloading. Napastnicy używali zaufanych binariów Microsoft do załadowania złośliwej biblioteki hostfxr.dll. Biblioteka zawierała zaszyfrowane lub skompresowane dane, które były odszyfrowywane bezpośrednio w pamięci i uruchamiane jako shellcode, co ograniczało liczbę łatwo wykrywalnych śladów na dysku.

Analiza wskazuje również na wykorzystanie funkcji CreateThread w sposób, który mógł utrudniać analizę malware. Nadmierne tworzenie wątków mogło destabilizować środowiska debugowania i spowalniać pracę analityków, jednocześnie nie zakłócając istotnie działania samego złośliwego kodu podczas normalnej infekcji.

Po uruchomieniu shellcode wykonywał kontrole środowiska, w tym mechanizmy wykrywania sandboxów. Jeśli system nie wyglądał na środowisko analityczne, generowany był klucz oparty na SHA-256, służący do odszyfrowania właściwego ładunku A0Backdoor zaszyfrowanego przy użyciu AES.

Sam backdoor relokował się do nowego obszaru pamięci, odszyfrowywał własne procedury i rozpoczynał rozpoznanie hosta. W tym celu korzystał z wywołań API systemu Windows, aby zebrać informacje o komputerze i użytkowniku. Taki fingerprint mógł służyć do oceny wartości ofiary, selekcji dalszych działań oraz przygotowania kolejnych poleceń operatorskich.

Szczególnie interesująca była komunikacja z infrastrukturą sterującą. A0Backdoor ukrywał dane sterujące w zapytaniach DNS MX, osadzając zakodowane metadane w subdomenach o wysokiej entropii kierowanych do publicznych resolverów rekurencyjnych. Odpowiedzi przyjmowały postać rekordów MX zawierających zakodowane polecenia, co mogło utrudniać detekcję w organizacjach monitorujących głównie rekordy TXT.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią jest wysokie, ponieważ opiera się ona na legalnych kanałach komunikacji i narzędziach natywnie obecnych w systemie operacyjnym. To sprawia, że użytkownicy rzadziej rozpoznają zagrożenie, a część zabezpieczeń może uznać aktywność za zgodną z normalnym wsparciem technicznym.

Wykorzystanie Quick Assist zmniejsza potrzebę dostarczania klasycznych załączników lub linków phishingowych. Z kolei podpisane pakiety MSI i DLL sideloading zwiększają szanse na obejście mechanizmów opartych wyłącznie na reputacji plików, prostych allowlistach i powierzchownych kontrolach aplikacyjnych.

Dodatkowym problemem jest kanał C2 oparty na DNS MX, który może pozostać niezauważony, jeśli organizacja nie analizuje pełnego kontekstu ruchu DNS. W praktyce skutki mogą obejmować trwały dostęp do stacji roboczej, eskalację uprawnień, ruch boczny w sieci, kradzież danych oraz przygotowanie gruntu pod kolejne etapy ataku, w tym wdrożenie ransomware.

Rekomendacje

Organizacje powinny formalnie uregulować sposób korzystania z Quick Assist i innych narzędzi zdalnego wsparcia. Każda sesja pomocy technicznej powinna być powiązana z autoryzowanym zgłoszeniem i poprzedzona jednoznaczną weryfikacją tożsamości pracownika IT.

W praktyce warto wdrożyć następujące działania:

monitorowanie uruchomień Quick Assist i korelowanie ich z aktywnością w Microsoft Teams,
analizę instalacji MSI wykonywanych bezpośrednio po sesjach zdalnych,
detekcję nietypowego ładowania bibliotek DLL przez zaufane binaria,
reguły wykrywające anomalie DNS, zwłaszcza zapytania MX o wysokiej entropii,
ograniczenie uruchamiania nieautoryzowanych instalatorów z lokalizacji chmurowych,
stosowanie EDR zapewniającego widoczność zdarzeń pamięciowych, wątków i wywołań API,
szkolenia użytkowników z phishingu prowadzonego przez komunikatory i fałszywy helpdesk.

Z perspektywy zespołów SOC kluczowe znaczenie ma korelacja telemetrii z wielu źródeł. Pojedynczy alert może nie wzbudzić podejrzeń, jednak ciąg zdarzeń obejmujący spam, kontakt przez Teams, start Quick Assist, uruchomienie MSI i nietypowy ruch DNS powinien być traktowany jako silny sygnał możliwej kompromitacji.

Podsumowanie

Kampania wykorzystująca Microsoft Teams i Quick Assist pokazuje, jak cienka stała się granica między legalną administracją a nadużyciem tych samych mechanizmów przez napastników. A0Backdoor łączy klasyczną socjotechnikę z nowoczesnymi technikami ukrywania ładunku, utrudniania analizy i nieoczywistej komunikacji C2.

Dla organizacji oznacza to konieczność rozszerzenia strategii obronnej poza pocztę elektroniczną. Skuteczna detekcja i reakcja wymagają objęcia monitoringiem komunikatorów firmowych, narzędzi zdalnego wsparcia, pamięci procesów oraz nietypowych wzorców w ruchu DNS.

Źródła

BleepingComputer — Microsoft Teams phishing targets employees with A0Backdoor malware — https://www.bleepingcomputer.com/news/security/microsoft-teams-phishing-targets-employees-with-backdoors/
BlueVoyant — Threat Intelligence and technical analysis referenced in the campaign report — https://www.bluevoyant.com/

Ataki na chmurę coraz częściej wykorzystują luki zamiast słabych haseł

Wprowadzenie do problemu / definicja

Bezpieczeństwo środowisk chmurowych wchodzi w nową fazę. Przez lata za główne przyczyny incydentów uznawano słabe hasła, brak wieloskładnikowego uwierzytelniania, błędne konfiguracje oraz nadmiernie szerokie uprawnienia. Choć te problemy nadal pozostają istotne, rosnąca liczba incydentów pokazuje, że napastnicy coraz częściej wybierają szybszą i skuteczniejszą drogę: wykorzystanie świeżo ujawnionych podatności.

To przesunięcie ma duże znaczenie operacyjne. Ochrona chmury nie może już opierać się wyłącznie na tożsamości i kontroli dostępu, ale musi obejmować także błyskawiczne łatanie systemów, monitoring aktywności w środowiskach developerskich, zabezpieczenie łańcucha dostaw oprogramowania oraz automatyczną reakcję na incydenty.

W skrócie

Najnowsze ustalenia wskazują, że w drugiej połowie 2025 roku najczęstszą metodą uzyskania początkowego dostępu do środowisk chmurowych było wykorzystanie podatności, odpowiadające za 44,5% analizowanych incydentów. Przejęte poświadczenia stanowiły 27% przypadków, co oznacza wyraźną zmianę w preferowanych technikach atakujących.

Równocześnie skrócił się czas między ujawnieniem luki a jej praktycznym wykorzystaniem. W wielu sytuacjach organizacje mają już nie tygodnie, ale zaledwie kilka dni na reakcję, a czasem mniej niż 48 godzin. Celem ataków pozostaje przede wszystkim cicha eksfiltracja danych, utrzymanie dostępu przez długi czas oraz przemieszczanie się do bardziej uprzywilejowanych zasobów.

Podatności wyprzedziły skradzione dane logowania jako główny wektor initial access.
Atakujący coraz częściej wykorzystują narzędzia deweloperskie i łańcuch dostaw.
Rosnące znaczenie mają federacja tożsamości, tokeny i konta serwisowe.
Czas reakcji staje się krytycznym elementem obrony.

Kontekst / historia

Dotychczas dominująca narracja wokół bezpieczeństwa chmury koncentrowała się na błędach konfiguracyjnych, publicznie dostępnych zasobach, niskiej higienie haseł oraz braku MFA. W wielu organizacjach te podstawowe mechanizmy zostały jednak stopniowo poprawione, co utrudniło atakującym stosowanie najprostszych metod przejęcia dostępu.

W efekcie cyberprzestępcy, grupy sponsorowane przez państwa oraz aktorzy nastawieni na zysk zaczęli szybciej operacjonalizować nowo ujawnione luki. Coraz częściej ataki nie zaczynają się od klasycznego phishingu, lecz od kompromitacji podatnego komponentu, narzędzia developerskiego albo zaufanej integracji między systemami. Dodatkowo wiele kampanii wskazuje na długotrwałe utrzymywanie obecności w środowisku ofiary, co zwiększa skalę ryzyka biznesowego i utrudnia pełne odzyskanie kontroli nad infrastrukturą.

Analiza techniczna

Najważniejszą zmianą jest przesunięcie punktu wejścia z tożsamości na podatność. Atakujący chętnie wykorzystują błędy typu zdalne wykonanie kodu, które pozwalają szybko osadzić pierwszy ładunek w podatnym systemie. Po uzyskaniu przyczółka rozpoczynają rozpoznanie środowiska, wyszukując klastry Kubernetes, kontenery, systemy zarządzania infrastrukturą, repozytoria sekretów oraz tokeny dostępu.

Istotny jest także pivot pomiędzy zasobami. Kompromitacja stacji roboczej dewelopera albo przejęcie tokena może prowadzić do nadużycia kont serwisowych CI/CD, a następnie do przejęcia komponentów o wyższych uprawnieniach. W praktyce oznacza to, że pojedynczy incydent na pozornie mniej krytycznym elemencie może szybko przerodzić się w kompromitację środowiska produkcyjnego lub systemów przechowujących dane klientów.

Szczególnie niebezpieczne są relacje zaufania oparte na OpenID Connect i podobnych mechanizmach federacji. Jeżeli środowisko chmurowe ufa zewnętrznej platformie kodu źródłowego lub pipeline’owi, przejęcie odpowiedniego tokena może umożliwić uzyskanie tymczasowych poświadczeń bez znajomości hasła. Tego typu aktywność bywa trudniejsza do wykrycia, ponieważ z perspektywy logów przypomina legalne działania automatyzacji.

Drugim wyraźnym trendem pozostaje nadużywanie łańcucha dostaw oprogramowania. Złośliwa zależność, podmieniona paczka lub skompromitowane archiwum mogą uruchomić szkodliwy kod na stacji roboczej programisty, a następnie otworzyć drogę do środowiska firmowego. Jeżeli w takim otoczeniu znajdują się źle chronione sekrety, klucze API lub nadmiernie uprzywilejowane konta techniczne, eskalacja następuje bardzo szybko.

W analizowanych incydentach pojawia się również zacieranie śladów. Napastnicy usuwają logi, artefakty śledcze, a czasem także kopie zapasowe, aby utrudnić analizę powłamaniową i spowolnić proces odzyskiwania. To jeden z powodów, dla których ręczne reagowanie coraz częściej okazuje się niewystarczające.

Konsekwencje / ryzyko

Dla organizacji największe zagrożenie wynika dziś z połączenia trzech czynników: krótkiego czasu wykorzystania nowych luk, szerokich relacji zaufania między narzędziami oraz nadmiernych uprawnień kont technicznych. Taki zestaw sprawia, że nawet pojedynczy punkt kompromitacji może doprowadzić do naruszenia wielu usług i środowisk jednocześnie.

Skutki obejmują wyciek danych, kradzież własności intelektualnej, utratę integralności systemów produkcyjnych oraz bezpośrednie straty finansowe. W sektorach związanych z finansami lub aktywami cyfrowymi przejęcie sekretów i kont serwisowych może otworzyć drogę do kradzieży środków. Dodatkowo długotrwała obecność napastnika zwiększa ryzyko ponownej kompromitacji nawet po częściowym opanowaniu incydentu.

Nie można też ignorować ryzyka wewnętrznego. Chmurowe platformy współpracy i udostępniania plików mogą zostać wykorzystane do cichej eksfiltracji danych. Z punktu widzenia monitoringu takie działania są trudniejsze do odróżnienia od zwykłego ruchu biznesowego niż tradycyjne kanały wynoszenia informacji.

Rekomendacje

Organizacje powinny przyjąć model obrony, który jednocześnie obejmuje podatności, tożsamość, pipeline’y oraz dane. Kluczowe znaczenie ma skrócenie czasu wdrażania poprawek, zwłaszcza dla publicznie dostępnych usług i krytycznych komponentów. Tam, gdzie szybkie łatanie nie jest możliwe, należy wdrażać zabezpieczenia kompensacyjne, takie jak segmentacja, WAF, ograniczenie ekspozycji interfejsów czy czasowa izolacja podatnych zasobów.

Równie ważne jest ograniczenie zaufania między systemami. Integracje OIDC, role IAM, tokeny CI/CD oraz konta serwisowe powinny być regularnie przeglądane pod kątem najmniejszych niezbędnych uprawnień. Warto analizować czas życia tokenów, zakres przyznanych praw oraz możliwość tworzenia nowych uprzywilejowanych kont przez automatyzację.

Silniejszej ochrony wymagają również stacje robocze deweloperów i cały łańcuch dostaw oprogramowania. Dobre praktyki obejmują podpisywanie artefaktów, kontrolę zależności, skanowanie sekretów, ochronę tokenów używanych w narzędziach developerskich oraz separację środowisk prywatnych i firmowych.

Detekcja powinna koncentrować się nie tylko na wskaźnikach kompromitacji, ale również na zachowaniu. Szczególnie istotne są alerty dotyczące tworzenia nowych ról uprzywilejowanych, anomalii w federacji tożsamości, nietypowego użycia tokenów, dostępu do dużych wolumenów danych oraz prób usuwania logów i kopii zapasowych.

Wdrożyć awaryjny proces patchowania dla krytycznych luk.
Ograniczyć uprawnienia kont serwisowych i pipeline’ów.
Zabezpieczyć tokeny, sekrety i zależności używane przez deweloperów.
Monitorować anomalie w federacji tożsamości i dostępie do danych.
Automatyzować izolację workloadów, rotację sekretów i blokowanie podejrzanych działań.

Podsumowanie

Obraz zagrożeń w chmurze wyraźnie się zmienia. Największym problemem nie są już wyłącznie słabe hasła, lecz szybko wykorzystywane podatności, nadużycia zaufanych integracji oraz kompromitacja łańcucha dostaw. Oznacza to, że skuteczna obrona wymaga szerszego podejścia obejmującego nie tylko ochronę kont, ale także błyskawiczne łatanie, monitoring zachowań, kontrolę pipeline’ów i automatyczne reagowanie.

Firmy, które nie skrócą czasu reakcji i nie ograniczą uprawnień technicznych, będą coraz bardziej narażone na szybkie, trudne do wykrycia i kosztowne incydenty chmurowe.

Źródła

CISA ostrzega przed aktywnie wykorzystywanymi lukami w SolarWinds, Ivanti i Workspace ONE

Wprowadzenie do problemu / definicja

Amerykańska agencja CISA rozszerzyła katalog Known Exploited Vulnerabilities o trzy podatności dotyczące popularnych rozwiązań enterprise: SolarWinds Web Help Desk, Ivanti Endpoint Manager oraz Omnissa Workspace ONE UEM. Umieszczenie luk w tym katalogu oznacza, że istnieją dowody ich aktywnego wykorzystywania w rzeczywistych atakach, co podnosi priorytet działań po stronie administratorów i zespołów SOC.

W skrócie

CISA wskazała trzy podatności jako aktywnie eksploatowane: CVE-2025-26399 w SolarWinds Web Help Desk, CVE-2026-1603 w Ivanti Endpoint Manager oraz CVE-2021-22054 w Workspace ONE UEM. Najpoważniejsza z nich, dotycząca SolarWinds, umożliwia wykonanie poleceń na hoście poprzez deserializację niezaufanych danych w komponencie AjaxProxy.

Luka w Ivanti pozwala na obejście uwierzytelniania i ujawnienie określonych poświadczeń, natomiast błąd w Workspace ONE UEM ma charakter SSRF i może prowadzić do nieautoryzowanego dostępu do wrażliwych informacji. Dla środowisk federalnych wyznaczono krótkie terminy wdrożenia poprawek, co dodatkowo podkreśla wagę zagrożenia.

CVE-2025-26399: SolarWinds Web Help Desk, ryzyko wykonania poleceń na hoście
CVE-2026-1603: Ivanti Endpoint Manager, obejście uwierzytelniania i ujawnienie poświadczeń
CVE-2021-22054: Workspace ONE UEM, SSRF i możliwość pozyskania wrażliwych danych

Kontekst / historia

Katalog KEV jest wykorzystywany przez CISA jako operacyjna lista podatności, które powinny być traktowane priorytetowo ze względu na ich wykorzystanie przez realnych przeciwników. W praktyce wpis do KEV często oznacza, że luka przeszła już z fazy teoretycznej do etapu skutecznej weaponizacji.

W przypadku SolarWinds Web Help Desk podatność CVE-2025-26399 pojawia się w szerszym kontekście problemów bezpieczeństwa tego produktu. W ostatnich miesiącach badacze i dostawcy usług MDR raportowali aktywność operatorów wykorzystujących błędy Web Help Desk do uzyskania dostępu początkowego do środowisk ofiar. Opisywana kampania była łączona z działalnością grupy ransomware Warlock.

Luka CVE-2021-22054 nie jest nowa, ale jej ponowne pojawienie się w katalogu aktywnie wykorzystywanych błędów pokazuje istotny problem operacyjny: starsze podatności wciąż pozostają obecne w środowiskach produkcyjnych. Z kolei CVE-2026-1603 w Ivanti Endpoint Manager wpisuje się w utrzymujący się trend wysokiego zainteresowania aktorów zagrożeń produktami do zarządzania infrastrukturą i punktami końcowymi.

Analiza techniczna

CVE-2025-26399 w SolarWinds Web Help Desk to podatność typu deserialization of untrusted data w komponencie AjaxProxy. Tego rodzaju błędy są szczególnie niebezpieczne, ponieważ pozwalają aplikacji przetwarzać dane wejściowe jako obiekty o zaufanym charakterze. Jeżeli mechanizm deserializacji nie został odpowiednio zabezpieczony, atakujący może doprowadzić do wykonania kontrolowanego łańcucha operacji, a finalnie do zdalnego wykonania kodu lub poleceń systemowych.

W praktyce oznacza to możliwość przejęcia serwera aplikacyjnego bez konieczności wcześniejszego uwierzytelnienia, jeśli podatny komponent jest osiągalny z sieci. To właśnie dlatego systemy help desk, które często są dostępne dla wielu użytkowników i zintegrowane z innymi usługami, stają się atrakcyjnym celem.

CVE-2026-1603 w Ivanti Endpoint Manager została opisana jako obejście uwierzytelniania z wykorzystaniem alternatywnej ścieżki lub kanału. Ten typ błędu zwykle wynika z niespójności między mechanizmami autoryzacji a logiką routingu, obsługi endpointów lub komunikacji między komponentami aplikacji. W konsekwencji nieautoryzowany atakujący zdalny może uzyskać dostęp do określonych przechowywanych danych uwierzytelniających.

Nawet jeśli luka nie daje natychmiastowego zdalnego wykonania kodu, wyciek poświadczeń może stać się punktem wyjścia do dalszej eskalacji uprawnień, ruchu bocznego lub kompromitacji innych systemów zarządzanych przez platformę.

CVE-2021-22054 w Workspace ONE UEM jest podatnością SSRF. Ataki tego typu polegają na wymuszeniu na serwerze wykonania żądań do zasobów wskazanych przez napastnika. Jeżeli aplikacja działa w uprzywilejowanym segmencie sieci, SSRF może zostać użyte do enumeracji usług wewnętrznych, pobierania metadanych, obchodzenia segmentacji logicznej, a czasem także do uzyskania dostępu do danych niedostępnych z Internetu.

W tym przypadku wskazywano, że osoba z dostępem sieciowym do UEM może wysyłać żądania bez uwierzytelnienia i pozyskiwać informacje wrażliwe. Istotne jest również to, że aktywna eksploatacja nie zawsze oznacza publicznie dostępny exploit o szerokiej dystrybucji. Często pierwsze nadużycia są obserwowane przez dostawców telemetrii, zespoły threat intelligence lub firmy prowadzące obsługę incydentów.

Konsekwencje / ryzyko

Ryzyko biznesowe i operacyjne jest wysokie, ponieważ wszystkie trzy produkty należą do kategorii oprogramowania uprzywilejowanego administracyjnie. Systemy help desk, UEM i endpoint management mają zwykle rozległy dostęp do danych, stacji roboczych, konfiguracji oraz poświadczeń technicznych.

W scenariuszu kompromitacji SolarWinds Web Help Desk organizacja może mieć do czynienia z pełnym przejęciem serwera aplikacyjnego, instalacją narzędzi post-exploitation, wdrożeniem zdalnego dostępu, kradzieżą danych lub przygotowaniem środowiska pod wdrożenie ransomware. Jeżeli serwer jest zintegrowany z pocztą, katalogiem użytkowników lub systemami zgłoszeniowymi, skala skutków rośnie.

W przypadku Ivanti Endpoint Manager kluczowym zagrożeniem jest ujawnienie przechowywanych poświadczeń. Tego typu dane mogą umożliwić przeciwnikowi przejęcie kont serwisowych, kont administracyjnych albo mechanizmów dystrybucji oprogramowania. To z kolei otwiera drogę do masowej kompromitacji punktów końcowych.

Workspace ONE UEM z podatnością SSRF stwarza ryzyko wykorzystania serwera zarządzającego jako przekaźnika do zasobów wewnętrznych. W środowiskach hybrydowych i chmurowych może to prowadzić do ujawnienia danych konfiguracyjnych, informacji o infrastrukturze lub innych elementów wspierających późniejszą eskalację ataku.

Największym problemem z perspektywy blue teamu jest fakt, że mowa o lukach już aktywnie wykorzystywanych. Oznacza to, że odkładanie aktualizacji na później przestaje być decyzją akceptowalną operacyjnie.

Rekomendacje

Priorytetem powinno być natychmiastowe ustalenie, czy w organizacji działają podatne instancje SolarWinds Web Help Desk, Ivanti Endpoint Manager lub Workspace ONE UEM. Następnie należy zweryfikować wersje, dostępność z sieci zewnętrznych oraz status wdrożenia poprawek producenta.

Zalecane działania operacyjne:

wdrożyć aktualizacje bezpieczeństwa i hotfixy dla wszystkich wskazanych produktów w trybie pilnym,
ograniczyć ekspozycję interfejsów administracyjnych do zaufanych segmentów sieci i połączeń przez VPN,
przeanalizować logi aplikacyjne, serwerowe i sieciowe pod kątem nietypowych żądań do AjaxProxy, podejrzanych prób dostępu bez uwierzytelnienia oraz ruchu wskazującego na SSRF,
sprawdzić, czy na serwerach zarządzających nie pojawiły się nieautoryzowane narzędzia zdalnej administracji, tunele, web shelle lub nowe zadania harmonogramu,
wymusić rotację poświadczeń, jeżeli istnieje choćby podejrzenie kompromitacji systemu Ivanti Endpoint Manager,
zastosować dodatkowe reguły detekcyjne w SIEM/XDR dla procesów potomnych uruchamianych przez usługi aplikacyjne oraz dla połączeń wychodzących z serwerów zarządzających do nietypowych adresów,
przeprowadzić hunting historyczny obejmujący przynajmniej okres od publikacji poprawek i pierwszych doniesień o exploitacji.

Warto również potraktować systemy klasy UEM i help desk jako zasoby Tier 0 lub zbliżone do tej kategorii. Ich monitoring powinien być bardziej restrykcyjny niż w przypadku zwykłych aplikacji biznesowych, ponieważ kompromitacja takich platform bardzo często prowadzi do rozlania incydentu na całą organizację.

Podsumowanie

Dodanie CVE-2025-26399, CVE-2026-1603 i CVE-2021-22054 do katalogu KEV potwierdza, że przeciwnicy nadal skutecznie wykorzystują zarówno nowe, jak i starsze błędy w systemach o wysokich uprawnieniach. Szczególnie niebezpieczna jest luka w SolarWinds Web Help Desk, ponieważ może prowadzić do zdalnego wykonania poleceń i przejęcia hosta.

Podatność w Ivanti zwiększa ryzyko wycieku poświadczeń, a SSRF w Workspace ONE UEM może zostać wykorzystane do dalszej penetracji środowiska wewnętrznego. Dla organizacji oznacza to konieczność natychmiastowego patchowania, przeglądu ekspozycji usług oraz aktywnego poszukiwania śladów nadużyć.

Źródła

The Hacker News — CISA Flags SolarWinds, Ivanti, and Workspace One Vulnerabilities as Actively Exploited — https://thehackernews.com/2026/03/cisa-flags-solarwinds-ivanti-and.html
Ivanti — March 2026 Security Update — https://www.ivanti.com/blog/march-2026-security-update
Huntress — Active Exploitation of SolarWinds Web Help Desk (CVE-2025-26399) — https://www.huntress.com/blog/active-exploitation-solarwinds-web-help-desk-cve-2025-26399
VMware Security Blog — Workspace ONE UEM SSRF CVE-2021-22054 Patch Alert — https://blogs.vmware.com/security/2022/04/workspace-one-uem-ssrf-cve-2021-22054-patch-alert.html
Horizon3.ai — Ivanti Endpoint Manager (EPM) | CVE-2026-1603 — https://horizon3.ai/attack-research/vulnerabilities/cve-2026-1603/