Archiwa: VPN - Strona 9 z 102 - Security Bez Tabu

BTMOB RAT: malware-as-a-service przyspiesza przejęcia urządzeń z Androidem

Wprowadzenie do problemu / definicja

BTMOB to złośliwe oprogramowanie typu RAT (Remote Access Trojan) przeznaczone dla systemu Android, którego celem jest zdalne przejęcie kontroli nad urządzeniem ofiary. Zagrożenie wyróżnia się nie tylko rozbudowanym zestawem funkcji szpiegowskich i operacyjnych, ale także modelem dystrybucji przypominającym legalne usługi SaaS. Dzięki temu z narzędzia mogą korzystać również mniej zaawansowani cyberprzestępcy.

W praktyce BTMOB nie jest pojedynczą próbką malware, lecz całym zestawem umożliwiającym budowanie fałszywych aplikacji, przygotowywanie kampanii phishingowych i szybkie tworzenie nowych wariantów złośliwych pakietów APK. To istotnie zwiększa skalę zagrożenia i utrudnia jego wykrywanie.

W skrócie

BTMOB to zaawansowany trojan zdalnego dostępu dla Androida rozwijany co najmniej od początku 2025 roku.
Zagrożenie wywodzi się z wcześniejszej rodziny SpySolr i rozszerza jej możliwości o pełniejsze przejęcie urządzenia.
Infekcja zwykle zaczyna się od phishingu i instalacji fałszywej aplikacji spoza oficjalnego sklepu.
Kluczowym elementem ataku jest nadużycie usług dostępności Androida.
Malware oferowane jest w modelu malware-as-a-service wraz z builderem APK i zapleczem do lokalizacji kampanii.

Kontekst / historia

BTMOB został nagłośniony przez badaczy bezpieczeństwa analizujących kampanie wymierzone przede wszystkim w użytkowników z Brazylii i szerzej Ameryki Łacińskiej. Choć pierwsze obserwacje dotyczyły tego regionu, konstrukcja malware i sposób jego sprzedaży wskazują, że zagrożenie może być łatwo adaptowane do innych rynków.

Rodowód BTMOB prowadzi do rodziny SpySolr, jednak nowa odsłona zagrożenia została wyraźnie rozbudowana. Z prostszego narzędzia do inwigilacji ewoluowała w kierunku platformy do kompleksowego przejmowania urządzeń mobilnych, wspieranej przez mechanizmy komercjalizacji, marketingu i obsługi klientów przestępczych.

Na uwagę zasługuje również profesjonalizacja kampanii. Operatorzy wykorzystują lokalne motywy socjotechniczne, podszywają się pod usługi streamingowe, platformy kryptowalutowe czy instytucje publiczne, a także dopasowują przynęty do konkretnego kraju. Taki poziom personalizacji zwiększa skuteczność oszustw i skraca czas potrzebny do uruchomienia nowych operacji.

Analiza techniczna

Łańcuch infekcji BTMOB jest stosunkowo prosty, ale skuteczny. Ofiara otrzymuje wiadomość phishingową lub trafia na stronę podszywającą się pod zaufany serwis. Następnie zostaje przekierowana do fałszywego sklepu z aplikacjami, skąd pobiera złośliwy plik APK.

Po instalacji aplikacja nakłania użytkownika do przyznania uprawnień dostępności. To kluczowy moment całego ataku, ponieważ właśnie te uprawnienia umożliwiają malware szeroką interakcję z interfejsem systemu, automatyzację działań i obchodzenie części zabezpieczeń. W efekcie atakujący może wykonywać operacje, które normalnie wymagałyby aktywności użytkownika.

Funkcjonalnie BTMOB wykracza poza klasyczny mobilny trojan bankowy. Oprogramowanie może wspierać wykradanie danych uwierzytelniających, przechwytywanie informacji z urządzenia, wykonywanie zrzutów ekranu, monitorowanie aktywności oraz zdalne sterowanie smartfonem. Taki zestaw możliwości oznacza ryzyko zarówno kradzieży środków finansowych, jak i długotrwałej inwigilacji ofiary.

Szczególnie groźnym elementem jest wbudowany builder APK. Pozwala on generować nowe warianty złośliwych aplikacji, zmieniać elementy socjotechniczne i dopasowywać kampanię do regionu, marki lub scenariusza ataku. To utrudnia detekcję opartą wyłącznie na sygnaturach, ponieważ liczba mutacji może rosnąć bardzo szybko.

Niepokojący jest także model sprzedaży. BTMOB promowany jest jako gotowy produkt cyberprzestępczy, oferowany wraz z narzędziami ułatwiającymi obsługę kampanii. Tego typu podejście obniża próg wejścia dla przestępców i przyspiesza uprzemysłowienie ataków na urządzenia mobilne.

Konsekwencje / ryzyko

Dla użytkownika końcowego infekcja BTMOB może oznaczać pełną kompromitację smartfona. Zagrożone są dane osobowe, wiadomości, informacje finansowe, tokeny sesyjne, hasła oraz inne poufne treści przetwarzane na urządzeniu. Jeśli telefon służy do logowania do banku, poczty lub komunikatorów, skutki incydentu mogą być wielowymiarowe.

Dla organizacji szczególnie niebezpieczne są scenariusze BYOD oraz wykorzystywanie urządzeń mobilnych do dostępu do poczty firmowej, VPN, aplikacji biznesowych i mechanizmów MFA. Przejęty telefon pracownika może zostać użyty do odczytywania kodów jednorazowych, przechwytywania powiadomień push i podszywania się pod użytkownika w procesach autoryzacji.

Dodatkowym ryzykiem jest łatwa skalowalność tego modelu. Jeżeli uruchomienie kampanii wymaga jedynie zakupu zestawu i podstawowej obsługi panelu, liczba aktorów zdolnych do prowadzenia ataków będzie rosła. To zwiększa presję na zespoły bezpieczeństwa i skraca cykl życia wskaźników kompromitacji.

Rekomendacje

Najważniejszym krokiem obronnym pozostaje ograniczenie instalacji aplikacji wyłącznie do oficjalnych sklepów i zaufanych kanałów dystrybucji. Organizacje powinny dodatkowo wdrażać polityki MDM lub EMM blokujące instalowanie pakietów spoza autoryzowanych źródeł oraz monitorujące nadużycia uprawnień dostępności.

Równie istotna jest edukacja użytkowników. Kampanie tego typu nadal bazują głównie na socjotechnice, dlatego pracownicy i użytkownicy prywatni powinni zachować szczególną ostrożność wobec linków przesyłanych przez SMS, komunikatory i e-mail, zwłaszcza jeśli prowadzą one do pobrania aplikacji.

korzystanie wyłącznie z oficjalnych sklepów z aplikacjami,
regularne przeglądanie uprawnień dostępności i usuwanie podejrzanych aplikacji,
stosowanie mobilnych rozwiązań bezpieczeństwa skanujących aplikacje i adresy URL,
monitorowanie anomalii na urządzeniach służbowych oraz integracja danych mobilnych z SOC,
przygotowanie procedur izolacji urządzenia, resetu haseł i ponownej rejestracji MFA po incydencie.

Podsumowanie

BTMOB pokazuje, że mobilne zagrożenia dojrzewają w kierunku pełnoprawnych usług cyberprzestępczych. Połączenie phishingu, nadużycia usług dostępności Androida, zdalnego sterowania urządzeniem i łatwego w użyciu buildera sprawia, że malware może być skutecznie wykorzystywane zarówno przeciw użytkownikom indywidualnym, jak i organizacjom.

Najważniejszy wniosek jest jednoznaczny: bezpieczeństwo smartfonów nie może być traktowane jako obszar drugorzędny. Współczesny telefon to pełnoprawny punkt dostępu do danych, usług i procesów biznesowych, a jego przejęcie może mieć skutki porównywalne z kompromitacją stacji roboczej.

Źródła

Holenderskie służby zakłóciły botnet z 17 milionami zainfekowanych urządzeń

Wprowadzenie do problemu / definicja

Holenderskie władze przeprowadziły operację wymierzoną w rozległą infrastrukturę botnetową, która według ustaleń obejmowała co najmniej 17 milionów zainfekowanych urządzeń. Sprawa pokazuje skalę współczesnych sieci przejętych hostów, wykorzystywanych nie tylko do ataków DDoS, ale również do pośredniczenia w złośliwym ruchu sieciowym oraz ukrywania aktywności cyberprzestępczej.

Botnet to sieć urządzeń kontrolowanych zdalnie przez operatora za pośrednictwem infrastruktury command-and-control. W praktyce oznacza to, że komputery, smartfony, tablety lub inne systemy podłączone do internetu mogą zostać wykorzystane bez wiedzy właścicieli jako narzędzia do dalszych operacji przestępczych.

W skrócie

Holenderska policja i krajowe centrum cyberbezpieczeństwa zakłóciły działanie botnetu obejmującego około 17 milionów urządzeń.
Operacja objęła ponad 200 serwerów zlokalizowanych w Niderlandach, które wspierały działanie całej infrastruktury.
Botnet miał być powiązany z usługą proxy monetyzującą dostęp do przejętych adresów IP.
Działania uderzyły nie tylko w techniczne zaplecze operacji, ale również w model biznesowy oparty na wykorzystaniu zainfekowanych urządzeń.

Kontekst / historia

Botnety od lat pozostają jednym z podstawowych narzędzi cyberprzestępczości. W przeszłości kojarzono je głównie z wysyłką spamu, atakami DDoS oraz dystrybucją malware. Obecnie coraz częściej pełnią one funkcję rozproszonej warstwy proxy, umożliwiającej przekierowywanie ruchu przez realne sieci domowe i mobilne.

Taki model działania utrudnia wykrywanie i blokowanie złośliwej aktywności, ponieważ ruch wychodzi z legalnych adresów IP należących do niczego nieświadomych użytkowników. W analizowanym przypadku istotne jest również to, że infrastruktura sterująca była utrzymywana na serwerach hostowanych lokalnie, co umożliwiło organom ścigania jej namierzenie i wyłączenie.

Analiza techniczna

Z technicznego punktu widzenia przejęte urządzenia mogły działać jako węzły pośredniczące dla ruchu sieciowego. Oznacza to, że operatorzy botnetu mogli wykorzystywać je do maskowania źródła połączeń, obchodzenia mechanizmów reputacyjnych i budowania komercyjnej usługi proxy opartej na cudzych zasobach.

Kluczową rolę w takim ekosystemie odgrywają serwery zarządzające. Mogą one odpowiadać za rejestrację nowych botów, dystrybucję konfiguracji, routing ruchu, autoryzację klientów oraz monitorowanie dostępności aktywnych węzłów. Przejęcie ponad 200 serwerów znacząco ogranicza zdolność operatora do centralnego sterowania siecią, choć nie oznacza automatycznego usunięcia infekcji ze wszystkich urządzeń końcowych.

Warto także odróżnić legalne usługi proxy od infrastruktury zbudowanej na bazie malware. W legalnym modelu użytkownik świadomie instaluje oprogramowanie i wyraża zgodę na wykorzystanie części swoich zasobów. W tym przypadku działania władz wskazują, że właściciele urządzeń nie uczestniczyli świadomie w całym mechanizmie, co klasyfikuje operację jako działalność przestępczą.

Konsekwencje / ryzyko

Ryzyko związane z takim botnetem jest wielowymiarowe. Zainfekowane urządzenie może zostać użyte do ataków na inne cele, co prowadzi do spadku wydajności, zużycia zasobów i potencjalnego naruszenia prywatności. Dodatkowo adres IP ofiary może posłużyć jako punkt wyjścia do działań przestępczych, utrudniając analizę incydentów oraz prawidłową atrybucję.

Dla organizacji szczególnie groźne jest przeniknięcie takiego malware do środowisk brzegowych, urządzeń sieciowych i stacji roboczych użytkowników zdalnych. Jeśli host staje się częścią sieci proxy, może posłużyć do omijania filtrów bezpieczeństwa, maskowania kampanii phishingowych, oszustw reklamowych oraz ataków aplikacyjnych prowadzonych z legalnie wyglądających lokalizacji.

Skala infekcji pokazuje również, że problem ma charakter systemowy. Najbardziej narażone pozostają urządzenia z domyślnymi hasłami, nieaktualnym firmware’em i włączonym zdalnym interfejsem administracyjnym dostępnym z internetu.

Rekomendacje

Zmienić domyślne dane logowania na unikalne i silne hasła, szczególnie w routerach, kamerach IP i urządzeniach IoT.
Regularnie aktualizować firmware oraz oprogramowanie urządzeń wystawionych do internetu.
Wyłączyć zdalny dostęp administracyjny, jeśli nie jest niezbędny.
Ograniczyć ekspozycję usług zarządzających poprzez segmentację sieci, ACL oraz dostęp wyłącznie przez VPN.
Monitorować nietypowy ruch wychodzący, w tym długotrwałe połączenia do nieznanych hostów i wzorce charakterystyczne dla usług proxy.
Wdrożyć detekcję opartą na telemetrii endpointów, logach sieciowych i analizie DNS.
Regularnie prowadzić skanowanie podatności oraz inwentaryzację urządzeń.
Przygotować procedury reagowania obejmujące izolację hostów, analizę artefaktów infekcji i rotację poświadczeń.

Dla zespołów SOC ważne jest również właściwe odróżnienie legalnego użycia usług proxy od aktywności wskazującej na przestępcze pośrednictwo. Sama obecność ruchu proxy nie jest jeszcze dowodem incydentu, ale korelacja z anomaliami systemowymi i śladami malware powinna uruchomić pogłębioną analizę.

Podsumowanie

Zakłócenie działania botnetu liczącego 17 milionów urządzeń to znaczący cios w infrastrukturę wspierającą współczesną cyberprzestępczość. Operacja potwierdza, że nowoczesne botnety coraz częściej pełnią rolę komercyjnej warstwy anonimizacji ruchu, a nie wyłącznie narzędzia do przeprowadzania ataków DDoS.

Z perspektywy obrony najważniejsze pozostają podstawy: higiena bezpieczeństwa, aktualizacje, eliminacja domyślnych konfiguracji oraz aktywne monitorowanie ruchu wychodzącego. To właśnie te działania najskuteczniej ograniczają ryzyko włączenia urządzeń firmowych i domowych do podobnych operacji.

Źródła

Ataki na FortiClient EMS: luka CVE-2026-35616 posłużyła do dystrybucji infostealera EKZ

Wprowadzenie do problemu / definicja

Aktywnie wykorzystywana podatność CVE-2026-35616 w FortiClient Enterprise Management Server (EMS) pokazuje, jak niebezpieczne może być przejęcie centralnej infrastruktury zarządzania punktami końcowymi. W tym przypadku napastnicy nie ograniczyli się do uzyskania dostępu do serwera zarządzającego, lecz wykorzystali go jako zaufany kanał do rozsyłania złośliwego oprogramowania do zarządzanych stacji roboczych. Kampania doprowadziła do wdrożenia nowego infostealera oznaczonego jako EKZ, podszywającego się pod legalną poprawkę dla oprogramowania Fortinet.

W skrócie

CVE-2026-35616 to krytyczna luka typu authentication bypass w FortiClient EMS.
Podatność umożliwia nieuwierzytelnionemu atakującemu wykonywanie działań administracyjnych, w tym zdalne uruchamianie poleceń lub kodu.
Napastnicy wykorzystywali przejęty serwer EMS do modyfikowania profili zdalnego dostępu i polityk endpointów.
Końcowym ładunkiem był infostealer EKZ kradnący dane z przeglądarek Chromium oraz Firefox.
Atak wyróżnia się użyciem legalnego, zaufanego kanału administracyjnego do dystrybucji malware.

Kontekst / historia

FortiClient EMS pełni rolę centralnego systemu zarządzania agentami FortiClient, politykami bezpieczeństwa oraz konfiguracją połączeń VPN. Tego typu platformy są wyjątkowo atrakcyjnym celem dla cyberprzestępców, ponieważ kompromitacja pojedynczego serwera może przełożyć się na szeroki wpływ na całe środowisko organizacji.

Podatność CVE-2026-35616 została publicznie powiązana z aktywnymi atakami na początku kwietnia 2026 roku. Producent potwierdził wykorzystanie luki w rzeczywistych kampaniach i opublikował awaryjne poprawki dla podatnych wersji 7.4.5 oraz 7.4.6. Jednocześnie wskazano, że linia 7.2 nie została objęta tym problemem. Sprawa zyskała dodatkową wagę po pilnych ostrzeżeniach dla administracji federalnej USA oraz doniesieniach o dużej liczbie publicznie dostępnych instancji EMS wystawionych do Internetu.

Z czasem analizy incydentów pokazały, że luka nie była używana wyłącznie do uzyskania dostępu administracyjnego. Atakujący zaczęli wykorzystywać centralne mechanizmy zarządzania FortiClient do masowego dostarczania złośliwego kodu na zarządzane endpointy, znacząco zwiększając skalę oddziaływania pojedynczej kompromitacji.

Analiza techniczna

Źródłem problemu jest nieprawidłowa kontrola dostępu w interfejsach API FortiClient EMS. W praktyce oznacza to możliwość wykonywania operacji administracyjnych bez poprawnego uwierzytelnienia. Po skutecznym obejściu mechanizmów dostępowych napastnik może ingerować w konfigurację systemu oraz polityki stosowane wobec agentów końcowych.

W obserwowanej kampanii łańcuch ataku przebiegał według powtarzalnego schematu. Najpierw napastnik wykorzystywał CVE-2026-35616 do uzyskania nieautoryzowanego dostępu do funkcji administracyjnych EMS. Następnie modyfikował profil Remote Access Profile i polityki endpointów, dodając skrypt uruchamiany po zestawieniu połączenia VPN. Po ustanowieniu tunelu IPsec komponent FortiClient uruchamiał skrypt wsadowy przy użyciu procesów systemowych, a ten wywoływał zakodowany w Base64 payload PowerShell. Kolejnym etapem było pobranie pliku wykonywalnego podszywającego się pod legalną poprawkę endpointową, który finalnie uruchamiał infostealera EKZ.

Istotne jest to, że złośliwy kod nie był dostarczany przez phishing ani przez odrębne włamanie na każdą stację. Dystrybucja odbywała się za pośrednictwem zaufanego kanału administracyjnego. W efekcie każdy zarządzany endpoint mógł stać się celem wykonania malware bez wzbudzania natychmiastowych podejrzeń użytkownika.

Sam EKZ Infostealer koncentruje się na kradzieży danych z przeglądarek. Obejmuje to zapisane hasła, ciasteczka sesyjne, dane autouzupełniania, informacje adresowe oraz dane kart płatniczych. Obsługiwane są zarówno przeglądarki oparte na Chromium, jak i Firefox. Szczególnie niebezpieczna jest zdolność do pozyskiwania ciasteczek i innych danych wspierających przejęcie aktywnych sesji, co może ograniczać skuteczność części mechanizmów MFA.

W analizach incydentów zwracano uwagę na sygnały ostrzegawcze w logach EMS. Jednym z ważniejszych wskaźników był komunikat o braku certyfikatu w nagłówku żądania, po którym mogły następować nietypowe operacje związane z certyfikatami i zmianami konfiguracji. Dodatkowo obserwowano logowania z infrastruktury VPS, z węzłów Tor oraz nieoczekiwane modyfikacje profili zdalnego dostępu.

Konsekwencje / ryzyko

Skutki kompromitacji FortiClient EMS są znacznie poważniejsze niż przejęcie pojedynczego hosta. W tym scenariuszu naruszona zostaje zaufana płaszczyzna zarządzania, która może posłużyć do równoczesnego wdrożenia złośliwych skryptów na wielu stacjach roboczych i systemach klienckich.

masowa dystrybucja malware do zarządzanych endpointów,
kradzież poświadczeń z przeglądarek i aplikacji webowych,
przejęcie sesji przy użyciu ciasteczek uwierzytelniających,
wtórny dostęp do usług chmurowych, paneli administracyjnych i aplikacji wewnętrznych,
ryzyko dalszego ruchu bocznego lub eskalacji do ransomware,
utrata integralności konfiguracji bezpieczeństwa dystrybuowanej centralnie.

Z perspektywy operacyjnej szczególnie niebezpieczne jest to, że część aktywności może przypominać legalne działania administracyjne. Jeśli organizacja nie monitoruje zmian w profilach VPN, uruchomień PowerShell inicjowanych przez komponenty FortiClient oraz nietypowych logowań do konsoli EMS, naruszenie może pozostać niewykryte przez dłuższy czas.

Rekomendacje

Organizacje korzystające z FortiClient EMS powinny potraktować ten typ incydentu jako zagrożenie dla całej floty zarządzanych urządzeń, a nie wyłącznie dla jednego serwera aplikacyjnego. Reakcja powinna obejmować zarówno działania naprawcze po stronie EMS, jak i szeroką weryfikację endpointów.

niezwłocznie zainstalować poprawki bezpieczeństwa lub przeprowadzić aktualizację do wersji wolnej od problemu,
sprawdzić, czy instancja EMS była wystawiona bezpośrednio do Internetu,
przeanalizować logi EMS pod kątem anomalii związanych z certyfikatami i próbami obejścia uwierzytelnienia,
zweryfikować ostatnie zmiany w profilach Remote Access Profile, politykach endpointów i skryptach uruchamianych po zestawieniu tunelu VPN,
monitorować uruchomienia cmd.exe i powershell.exe inicjowane przez procesy FortiClient,
poszukiwać artefaktów w katalogach związanych z logowaniem i skryptami klienta oraz podejrzanych plików w katalogach systemowych,
wykrywać połączenia HTTP do surowych adresów IP oraz sekwencje obejmujące pobranie, uruchomienie i eksfiltrację danych,
sprawdzić, czy nie pojawiły się nowe konta administracyjne lub logowania z nietypowych lokalizacji i ASN,
wymusić reset poświadczeń użytkowników przy podejrzeniu kradzieży danych z przeglądarek,
unieważnić aktywne sesje w systemach SaaS i aplikacjach wewnętrznych, aby ograniczyć skutki przejęcia ciasteczek.

W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto dodatkowo odseparować płaszczyznę zarządzania EMS od sieci publicznej, ograniczyć dostęp administracyjny za pomocą segmentacji i list dozwolonych adresów oraz wdrożyć reguły detekcji skupione na nietypowych modyfikacjach centralnie dystrybuowanej konfiguracji VPN.

Podsumowanie

Kampania wykorzystująca CVE-2026-35616 przeciwko FortiClient EMS pokazuje, że atak na system zarządzający może mieć skutki porównywalne z naruszeniem o charakterze domenowym. Po obejściu uwierzytelnienia napastnicy użyli legalnych funkcji platformy do wypchnięcia infostealera EKZ na zarządzane endpointy, znacząco zwiększając skalę i skuteczność operacji.

Dla zespołów bezpieczeństwa kluczowy wniosek jest jasny: kompromitacja systemu EDR, UEM, MDM czy platformy zarządzania klientami VPN nie powinna być traktowana jak zwykły incydent serwerowy. Wymaga szybkiego łatania, monitorowania zmian konfiguracyjnych, analizy procesów potomnych uruchamianych przez agentów końcowych oraz założenia, że wszystkie zarządzane hosty mogły zostać narażone.

Źródła

19,6 miliarda plików publicznie dostępnych w chmurze bez uwierzytelnienia. Skala błędnych konfiguracji rośnie

Wprowadzenie do problemu / definicja

Błędna konfiguracja zasobów chmurowych pozostaje jednym z najpoważniejszych i jednocześnie najczęściej bagatelizowanych problemów bezpieczeństwa. Nie chodzi tu o nową podatność typu zero-day ani wyrafinowany atak, lecz o sytuację, w której zasoby przechowywane w chmurze — takie jak buckety obiektowe, backupy czy eksporty baz danych — są udostępnione publicznie bez wymaganego uwierzytelnienia.

Najnowsze ustalenia badaczy pokazują, że skala zjawiska jest ogromna. Miliardy plików przechowywanych w publicznie listowalnych bucketach mogą być przeglądane bez hasła, bez obchodzenia zabezpieczeń i bez konieczności przełamywania jakichkolwiek mechanizmów ochronnych.

W skrócie

Analiza objęła ponad 535 tysięcy publicznie listowalnych bucketów w głównych środowiskach chmurowych. Łącznie oszacowano, że zawierają one około 19,6 miliarda plików dostępnych bez uwierzytelnienia. Wśród nich znalazły się setki tysięcy plików z poświadczeniami, niemal milion eksportów SQL oraz setki tysięcy kopii zapasowych.

ponad 535 tys. publicznie listowalnych bucketów,
około 19,6 mld plików dostępnych bez logowania,
685 047 plików z poświadczeniami i kluczami,
985 645 plików .sql,
733 040 plików .bak.

Problem nie wynika z luki w samych platformach chmurowych, lecz z niewłaściwej konfiguracji dostępu, błędów operacyjnych oraz nieprawidłowego przechowywania sekretów.

Kontekst / historia

Publiczne ekspozycje bucketów nie są nowym zjawiskiem. Od lat organizacje przypadkowo ujawniają repozytoria obiektowe zawierające dane klientów, pliki aplikacyjne, logi, backupy i dokumentację wewnętrzną. Jednak wraz z rozwojem środowisk cloud-native problem urósł do niespotykanej wcześniej skali.

Nowoczesne środowiska wytwarzają ogromne ilości artefaktów: obrazy, logi, eksporty baz, pliki tymczasowe, archiwa czy konfiguracje. Każdy z tych elementów może zostać zapisany w pamięci obiektowej, a pojedynczy błąd w polityce dostępu wystarczy, by zasób stał się publicznie osiągalny.

Szczególnie niebezpieczne jest to, że wiele organizacji traktuje storage obiektowy jako zaplecze techniczne, które nie podlega tak ścisłej kontroli jak systemy produkcyjne. W efekcie do bucketów trafiają pliki .env, snapshoty środowisk testowych, archiwa baz danych i automatycznie generowane kopie bezpieczeństwa.

Analiza techniczna

Według opublikowanych ustaleń badacze przeanalizowali w marcu 2026 roku metadane bucketów w usługach Amazon S3, Google Cloud, Microsoft Azure, DigitalOcean i Alibaba Cloud. Co istotne, analiza nie wymagała pobierania zawartości plików. Już same nazwy i typy plików pozwoliły zidentyfikować materiały o bardzo wysokiej wrażliwości.

Na szczególną uwagę zasługują pliki z sekretami. Wśród ujawnionych danych znalazły się pliki .env, klucze prywatne oraz bazy haseł. Z perspektywy napastnika są to zasoby o najwyższej wartości, ponieważ umożliwiają przejście od biernej obserwacji do aktywnej kompromitacji środowiska.

Drugą krytyczną kategorią są eksporty i kopie baz danych. Pliki .sql i .bak mogą zawierać pełne zbiory rekordów, pozbawione zabezpieczeń obecnych w aplikacji, takich jak uwierzytelnianie, autoryzacja czy kontrola logiki biznesowej. Oznacza to, że po ich pobraniu możliwa jest szczegółowa analiza danych offline.

Badacze zwrócili również uwagę na nazewnictwo plików. Wiele z nich zawierało frazy takie jak „secret”, „salary”, „kyc” czy „credentials”, a nazwy związane z hasłami, paszportami, fakturami i backupami występowały na masową skalę. To wskazuje, że problem obejmuje nie tylko zasoby techniczne, ale również dane osobowe, dokumenty finansowe i materiały związane z compliance.

Najgroźniejszy jest efekt łańcuchowy. Otwarty bucket może jednocześnie zawierać plik .env z poświadczeniami oraz eksport SQL tej samej aplikacji. To daje napastnikowi możliwość zarówno szybkiego dostępu do środowiska, jak i długoterminowego wykorzystania wykradzionych danych do phishingu, przejęć kont czy oszustw biznesowych.

Konsekwencje / ryzyko

Ryzyko związane z publicznie dostępnymi bucketami jest wielowymiarowe. Organizacja może utracić poufność danych klientów, pracowników i partnerów, a ujawnienie sekretów aplikacyjnych może doprowadzić do wtórnej kompromitacji infrastruktury chmurowej i kont uprzywilejowanych.

przejęcie kont i usług dzięki ujawnionym kluczom oraz tokenom,
eskalacja uprawnień w środowisku chmurowym,
wycieki danych osobowych i regulacyjnych,
ataki ransomware poprzedzone rozpoznaniem z użyciem publicznych backupów,
oszustwa finansowe i phishing ukierunkowany,
sankcje regulacyjne oraz wysokie koszty obsługi incydentu.

Wysoki poziom zagrożenia wynika z faktu, że mamy do czynienia z ekspozycją pasywną. Napastnik nie musi stosować exploita ani złośliwego oprogramowania. Jeśli zasób jest publicznie listowalny, może zostać odnaleziony, zautomatyzowanie przeskanowany i masowo wykorzystany.

Rekomendacje

Organizacje powinny traktować błędną konfigurację storage’u jako problem architektoniczny, a nie pojedynczą pomyłkę administratora. Skuteczna obrona wymaga połączenia polityk organizacyjnych, automatyzacji i ciągłego monitoringu.

wymuszenie domyślnej prywatności wszystkich bucketów i blokady publicznego listowania,
zakaz przechowywania sekretów w pamięci obiektowej bez odpowiedniego szyfrowania i ścisłej kontroli dostępu,
automatyczne skanowanie bucketów pod kątem plików .env, kluczy prywatnych, dumpów SQL i backupów,
regularny audyt uprawnień IAM, ACL i polityk bucketów,
szyfrowanie kopii zapasowych oraz ich separacja od zasobów publicznie osiągalnych,
wdrożenie mechanizmów CSPM do ciągłego wykrywania błędnych konfiguracji,
przegląd pipeline’ów CI/CD i skryptów automatyzacji pod kątem niekontrolowanego zapisu artefaktów,
rotacja wszystkich poświadczeń, które mogły zostać ujawnione, nawet przy braku potwierdzonego nadużycia,
ograniczenie retencji danych i minimalizacja zbieranych informacji,
wymuszenie MFA dla kont administracyjnych i usług krytycznych.

Z perspektywy użytkownika końcowego podstawą pozostaje stosowanie unikalnych haseł dla każdej usługi oraz aktywacja uwierzytelniania wieloskładnikowego. Nawet jeśli dane zostaną ujawnione przez dostawcę lub partnera, ogranicza to ryzyko dalszego nadużycia poświadczeń.

Podsumowanie

Ekspozycja 19,6 miliarda plików w publicznie dostępnych bucketach pokazuje, że jednym z największych zagrożeń dla bezpieczeństwa chmury nadal nie są wyłącznie nowe podatności, lecz dobrze znane błędy konfiguracyjne. Problem obejmuje nie tylko dane archiwalne, ale również aktywne sekrety, backupy i eksporty baz danych, które mogą prowadzić do pełnej kompromitacji organizacji.

W środowiskach wielochmurowych i silnie zautomatyzowanych kontrola nad storage’em musi być ciągła, centralnie egzekwowana i wspierana politykami bezpieczeństwa. W przeciwnym razie pojedyncza błędna flaga dostępu może zamienić zwykły bucket w gotowy zestaw narzędzi dla atakującego.

Źródła

Security Affairs – 19.6 Billion Files Are Sitting Open on the Internet. No Password Required — https://securityaffairs.com/192787/security/19-6-billion-files-are-sitting-open-on-the-internet-no-password-required.html
Mysterium VPN Report – 19.6 billion files exposed across publicly listable cloud buckets — https://www.mysteriumvpn.com/blog/19-6-billion-files-open-on-the-internet
Amazon Web Services – Blocking public access to Amazon S3 storage — https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
Google Cloud – IAM and access control for Cloud Storage — https://cloud.google.com/storage/docs/access-control
Microsoft Learn – Secure access to Azure Storage — https://learn.microsoft.com/azure/storage/common/security-recommendations

Krytyczna luka RCE w Gogs pozwala uwierzytelnionym użytkownikom przejąć serwer

Wprowadzenie do problemu / definicja

W platformie Gogs, czyli lekkiej i samohostowanej usłudze Git typu open source, ujawniono krytyczną podatność z kategorii zdalnego wykonania kodu. Luka umożliwia uwierzytelnionemu użytkownikowi uruchomienie dowolnych poleceń na serwerze w określonym scenariuszu związanym z obsługą pull requestów oraz funkcją rebase przed scaleniem zmian.

Z punktu widzenia bezpieczeństwa oznacza to, że nawet konto bez uprawnień administracyjnych może stać się punktem wyjścia do pełnej kompromitacji instancji. Problem jest szczególnie istotny dla organizacji wykorzystujących Gogs do hostowania prywatnych repozytoriów, wewnętrznych projektów programistycznych i procesów DevOps.

W skrócie

Podatność została oceniona na 9,4 w skali CVSS i w momencie ujawnienia nie miała jeszcze przypisanego identyfikatora CVE. Mechanizm ataku polega na przygotowaniu złośliwej nazwy gałęzi, która podczas operacji „Rebase before merging” prowadzi do wstrzyknięcia parametru --exec do polecenia git rebase.

atak może zostać przeprowadzony przez każdego uwierzytelnionego użytkownika,
nie są wymagane uprawnienia administratora,
nie jest potrzebna interakcja innych użytkowników,
w środowiskach z domyślną konfiguracją wystarczyć może samo utworzenie konta i repozytorium,
dostępne są już narzędzia automatyzujące eksploatację.

Kontekst / historia

Gogs jest popularny przede wszystkim tam, gdzie liczy się prostota wdrożenia, niskie wymagania infrastrukturalne oraz pełna kontrola nad środowiskiem. Z tego powodu bywa wykorzystywany przez mniejsze organizacje, zespoły deweloperskie, laboratoria oraz firmy utrzymujące własne wewnętrzne platformy do zarządzania kodem.

Opisywana luka została zgłoszona opiekunowi projektu 17 marca 2026 roku. Według dostępnych informacji problem dotyczy wszystkich wspieranych platform, w tym systemów Linux, Windows i macOS. Szacowano również, że publicznie dostępnych może być ponad tysiąc instancji Gogs, a rzeczywista skala wdrożeń prawdopodobnie jest większa ze względu na środowiska ukryte za sieciami prywatnymi, VPN lub działające wyłącznie wewnątrz organizacji.

Analiza techniczna

Źródłem podatności jest sposób obsługi procesu scalania zmian z użyciem mechanizmu rebase. Samo polecenie git rebase służy do odtwarzania sekwencji commitów na nowej bazie, jednak wspiera także parametr --exec, który pozwala uruchamiać polecenia powłoki podczas wykonywania operacji.

W podatnym scenariuszu atakujący tworzy pull request z odpowiednio spreparowaną nazwą gałęzi. Jeśli w repozytorium włączona jest opcja „Rebase before merging”, złośliwa nazwa może zostać potraktowana w sposób umożliwiający dołączenie dodatkowego argumentu do wywołania git rebase. W rezultacie serwer wykonuje polecenie wskazane przez napastnika.

Kluczowe znaczenie ma niski próg wejścia. W wielu wdrożeniach użytkownik po założeniu konta może utworzyć własne repozytorium, a jako jego właściciel samodzielnie konfigurować dostępne metody scalania. To sprawia, że eksploatacja nie musi zależeć od błędów administracyjnych wyższego poziomu ani od przejęcia uprzywilejowanego konta.

Dodatkowym czynnikiem zwiększającym ryzyko jest dostępność gotowego modułu Metasploit, który upraszcza wykorzystanie luki zarówno w środowiskach linuksowych, jak i windowsowych. Oznacza to, że atak może być powtarzalny, szybki i osiągalny także dla mniej zaawansowanych operatorów.

Konsekwencje / ryzyko

Skuteczne wykorzystanie podatności może doprowadzić do pełnej kompromitacji serwera Gogs. Napastnik może uzyskać dostęp do hostowanych repozytoriów, odczytać lub zmodyfikować kod źródłowy, przejąć przechowywane poświadczenia, a następnie wykorzystać zainfekowany host do dalszego poruszania się po infrastrukturze.

W środowiskach współdzielonych ryzyko rośnie jeszcze bardziej. Jedna podatna instancja może stać się punktem dostępu do danych wielu zespołów lub klientów, co oznacza możliwość naruszenia poufności, integralności i separacji projektów. Dla organizacji rozwijających oprogramowanie oznacza to również realne zagrożenie dla łańcucha dostaw, zwłaszcza jeśli Gogs jest powiązany z procesami budowania, automatyzacją wdrożeń lub przechowywaniem kluczy dostępowych.

kradzież własności intelektualnej,
modyfikacja kodu źródłowego i skryptów buildów,
przejęcie tokenów, haseł i innych sekretów,
ruch lateralny do innych systemów organizacji,
naruszenie prywatności repozytoriów współdzielonych na jednej instancji.

Rekomendacje

Do czasu opublikowania oficjalnej poprawki organizacje powinny skupić się na ograniczeniu powierzchni ataku. Najważniejsze jest zablokowanie publicznej rejestracji lub dopuszczanie wyłącznie zaufanych użytkowników. Równie istotne jest ograniczenie możliwości samodzielnego tworzenia repozytoriów oraz przegląd konfiguracji metod scalania we wszystkich istniejących projektach.

Jeśli to możliwe, warto wyłączyć opcję „Rebase before merging” do czasu usunięcia luki. Administratorzy powinni również przeprowadzić audyt uprawnień, zweryfikować, które konta mają możliwość tworzenia pull requestów i merge’owania zmian, a także sprawdzić, czy na serwerze nie występują oznaki wcześniejszego nadużycia.

wyłączyć publiczną rejestrację kont,
ograniczyć lub zablokować tworzenie nowych repozytoriów przez użytkowników końcowych,
wyłączyć tryb rebase merge tam, gdzie to możliwe,
przeanalizować logi błędów oraz nietypowe operacje związane z pull requestami,
sprawdzić integralność repozytoriów i historię zmian,
przeprowadzić rotację poświadczeń dostępnych z poziomu serwera Gogs,
wdrożyć segmentację sieciową i ograniczyć widoczność instancji,
monitorować procesy uruchamiane przez usługę pod kątem nietypowych poleceń systemowych.

W środowiskach o wysokim profilu ryzyka uzasadnione może być także tymczasowe odizolowanie instancji od Internetu i ograniczenie dostępu wyłącznie do sieci wewnętrznej, VPN lub ściśle kontrolowanych list dostępu.

Podsumowanie

Krytyczna luka RCE w Gogs pokazuje, że nawet pozornie techniczny detal związany z obsługą operacji Git może przełożyć się na pełne przejęcie platformy wspierającej rozwój oprogramowania. Połączenie wysokiej oceny CVSS, braku potrzeby posiadania uprawnień administracyjnych oraz możliwości łatwej automatyzacji ataku sprawia, że jest to problem o dużym znaczeniu operacyjnym.

Dla administratorów i zespołów bezpieczeństwa najważniejsze są obecnie działania tymczasowe: ograniczenie rejestracji, zmniejszenie swobody użytkowników w zakresie tworzenia repozytoriów, wyłączenie podatnego scenariusza scalania oraz aktywne monitorowanie środowiska. Platformy zarządzania kodem powinny być traktowane jako zasoby krytyczne, ponieważ ich kompromitacja może bezpośrednio przełożyć się na bezpieczeństwo całego procesu wytwarzania oprogramowania.

Źródła

BTMOB RAT na Androida: mobilny trojan MaaS atakuje Brazylię i Amerykę Łacińską

Wprowadzenie do problemu / definicja

BTMOB to złośliwe oprogramowanie typu Remote Access Trojan (RAT) dla systemu Android, które umożliwia zdalne przejęcie urządzenia, kradzież danych oraz prowadzenie działań wykraczających poza klasyczne scenariusze mobilnych infekcji. Najnowsze analizy wskazują, że zagrożenie rozwija się w modelu Malware-as-a-Service, co oznacza jego komercjalizację i udostępnianie szerszemu gronu cyberprzestępców.

Taki model obniża próg wejścia dla operatorów kampanii, ponieważ nie muszą oni samodzielnie tworzyć malware ani rozbudowanej infrastruktury. W efekcie mobilne zagrożenia stają się bardziej skalowalne, szybsze we wdrożeniu i łatwiejsze do dostosowania do konkretnego regionu lub scenariusza oszustwa.

W skrócie

BTMOB jest rozwijany jako mobilny RAT o możliwościach szerszych niż typowy trojan bankowy. Oprócz zbierania danych i monitorowania aktywności użytkownika pozwala także na głębszą kontrolę nad urządzeniem, co zwiększa potencjalne skutki infekcji.

zagrożenie celuje głównie w Brazylię i kraje Ameryki Łacińskiej,
jest dystrybuowane w modelu MaaS,
operatorzy mają korzystać z kreatora APK typu no-code,
kampanie wykorzystują phishing i fałszywe strony instalacyjne,
malware nadużywa mechanizmów systemowych Androida, w tym usług dostępności.

Kontekst / historia

Rodzina BTMOB była wcześniej opisywana jako rozwinięcie malware SpySolr. W starszych kampaniach wykorzystywano strony phishingowe podszywające się pod znane usługi, w tym platformy streamingowe czy serwisy związane z kryptowalutami. Obecna ewolucja wskazuje jednak na znacznie dojrzalszy model operacyjny.

Z perspektywy rynku cyberprzestępczego jest to kolejny przykład uprzemysłowienia zagrożeń mobilnych. Zamiast pojedynczego narzędzia używanego przez jedną grupę, BTMOB staje się produktem usługowym, który można konfigurować, lokalizować i wdrażać w różnych kampaniach. Tego typu podejście zwiększa skalę ryzyka i skraca czas potrzebny do uruchomienia nowej fali ataków.

Analiza techniczna

Infekcja zwykle rozpoczyna się od socjotechniki. Użytkownik trafia na spreparowaną stronę podszywającą się pod wiarygodną usługę, a następnie jest nakłaniany do pobrania złośliwego pliku APK poza oficjalnym sklepem. To klasyczny schemat sideloadingu, który pozostaje jednym z najskuteczniejszych wektorów dostarczania mobilnego malware.

Kluczowym elementem działania BTMOB jest nadużycie usług dostępności Androida. Mechanizm Accessibility Service został zaprojektowany jako wsparcie dla osób z niepełnosprawnościami, ale malware może wykorzystywać go do obserwacji interfejsu, automatyzacji kliknięć, uzyskiwania kolejnych uprawnień i wykonywania operacji bez pełnej świadomości użytkownika. W praktyce umożliwia to przejście od pozornie niegroźnej aplikacji do pełnego przejęcia urządzenia.

Z dostępnych analiz wynika, że BTMOB może realizować następujące działania:

zbieranie wrażliwych danych z urządzenia,
wykonywanie zrzutów ekranu,
rejestrowanie aktywności użytkownika,
rozszerzanie własnych uprawnień operacyjnych,
zapewnienie operatorowi zdalnej kontroli nad smartfonem.

Szczególnie istotna jest warstwa operacyjna zagrożenia. Malware ma być oferowane wraz z narzędziami pozwalającymi generować nowe warianty APK i dostosowywać przynęty phishingowe do konkretnego kraju, języka oraz scenariusza ataku. To utrudnia wykrywanie oparte wyłącznie na sygnaturach, ponieważ kolejne próbki mogą różnić się nazwą aplikacji, ikoną, pakietem i konfiguracją.

Konsekwencje / ryzyko

Ryzyko związane z BTMOB wykracza poza same oszustwa finansowe. Smartfon jest dziś centralnym elementem tożsamości cyfrowej użytkownika i zawiera dane logowania, wiadomości, historię aktywności, aplikacje finansowe, komunikatory oraz komponenty wykorzystywane do uwierzytelniania wieloskładnikowego.

Skutki infekcji mogą obejmować zarówno straty po stronie użytkownika indywidualnego, jak i poważne konsekwencje dla organizacji. Przejęcie urządzenia mobilnego może umożliwić dalszy ruch w środowisku firmowym, jeśli telefon jest wykorzystywany do dostępu do poczty, VPN, aplikacji SaaS lub komunikatorów korporacyjnych.

przejęcie kont finansowych i usług cyfrowych,
obejście mechanizmów MFA poprzez kontrolę nad urządzeniem,
kradzież danych osobowych i firmowych,
wykorzystanie telefonu jako punktu wejścia do środowiska przedsiębiorstwa,
prowadzenie dalszych oszustw z użyciem zaufanej tożsamości ofiary.

Model MaaS dodatkowo zwiększa ryzyko, ponieważ umożliwia szybkie uruchamianie kolejnych kampanii i łatwą adaptację technik do lokalnych realiów. To sprawia, że zagrożenie może rozszerzać się poza obecne regiony aktywności.

Rekomendacje

Podstawową linią obrony pozostaje ograniczenie instalacji aplikacji do oficjalnych źródeł oraz maksymalne blokowanie sideloadingu. W środowiskach firmowych powinno to być egzekwowane politykami MDM lub UEM, a urządzenia mobilne należy traktować jak pełnoprawne endpointy.

blokować lub ściśle kontrolować instalację aplikacji spoza oficjalnego sklepu,
audytować użycie uprawnień dostępności na urządzeniach Android,
wdrażać mobilne rozwiązania bezpieczeństwa i telemetrykę,
szkolić użytkowników z rozpoznawania phishingu kierującego do fałszywych sklepów i stron instalacyjnych,
segmentować dostęp do zasobów firmowych z urządzeń mobilnych,
wymuszać polityki zgodności urządzeń i minimalne wymagania bezpieczeństwa,
śledzić wskaźniki kompromitacji publikowane przez dostawców threat intelligence.

Dla zespołów SOC i IR istotne jest rozszerzenie procesów detekcji o mobile threat detection. Samo monitorowanie stacji roboczych nie zapewni odpowiedniej widoczności, gdy atak rozpoczyna się od mobilnego phishingu i złośliwego APK.

Podsumowanie

BTMOB pokazuje, że mobilna cyberprzestępczość wchodzi na coraz wyższy poziom dojrzałości. Połączenie funkcji zdalnego przejęcia urządzenia, nadużywania usług dostępności, regionalnie dopasowanej socjotechniki i modelu MaaS tworzy zagrożenie o dużym potencjale skalowania.

Choć obecne kampanie koncentrują się na Brazylii i Ameryce Łacińskiej, charakter tego narzędzia sugeruje, że jego znaczenie może szybko wyjść poza jeden region. Dla organizacji i użytkowników to wyraźny sygnał, że bezpieczeństwo urządzeń mobilnych musi stać się integralną częścią strategii cyberbezpieczeństwa.

Źródła

CVE-2026-35616 w FortiClient EMS aktywnie wykorzystywana do wdrażania malware

Wprowadzenie do problemu / definicja

CVE-2026-35616 to krytyczna podatność typu improper access control w FortiClient Endpoint Management Server (EMS), umożliwiająca zdalne wykonanie nieautoryzowanego kodu lub poleceń bez uwierzytelnienia. Ze względu na centralną rolę EMS w zarządzaniu stacjami końcowymi, skutki skutecznego ataku mogą wykraczać daleko poza kompromitację pojedynczego serwera.

W praktyce oznacza to, że atakujący może przejąć zaufany kanał administracyjny i wykorzystać go do działań obejmujących wiele zarządzanych urządzeń jednocześnie. To właśnie ten aspekt sprawia, że omawiana luka stanowi zagrożenie o wysokim priorytecie operacyjnym.

W skrócie

Podatność dotyczy FortiClient EMS w wersjach 7.4.5 i 7.4.6.
Luka została sklasyfikowana jako krytyczna i była aktywnie wykorzystywana w rzeczywistych atakach.
Napastnicy mieli używać serwera EMS do dystrybucji fałszywej poprawki podszywającej się pod aktualizację Fortinet.
Ładunkiem końcowym był EKZ Infostealer, malware ukierunkowany na kradzież danych uwierzytelniających.
Ryzyko obejmuje zarówno przejęcie kontroli nad środowiskiem endpointów, jak i późniejszą eskalację incydentu z użyciem skradzionych poświadczeń.

Kontekst / historia

Fortinet udostępnił poprawki poza standardowym cyklem aktualizacji na początku kwietnia 2026 roku, jednocześnie potwierdzając aktywne wykorzystanie luki w środowiskach produkcyjnych. To ważny sygnał, ponieważ publikacja awaryjnych poprawek zwykle wskazuje na wysokie prawdopodobieństwo dalszych kampanii ataków.

Sprawa szybko zyskała dodatkową wagę po uwzględnieniu CVE-2026-35616 w katalogu Known Exploited Vulnerabilities prowadzonym przez CISA. W praktyce wpis do KEV oznacza, że organizacje powinny potraktować podatność jako pilny problem bezpieczeństwa wymagający natychmiastowych działań naprawczych.

W kolejnych analizach badacze wskazali, że atakujący nie poprzestawali na samym dostępie do serwera EMS. Zamiast tego wykorzystywali mechanizmy platformy do dalszego rozsyłania złośliwych poleceń i komponentów na zarządzane stacje końcowe, co znacząco zwiększało skalę potencjalnych szkód.

Analiza techniczna

Źródłem problemu jest niewłaściwa kontrola dostępu w interfejsach FortiClient EMS. Specjalnie przygotowane żądania HTTP kierowane do określonych endpointów aplikacji mogą zostać obsłużone tak, jakby pochodziły od legalnie uwierzytelnionego administratora.

Skutkiem jest możliwość pominięcia mechanizmów uwierzytelniania i wykonywania operacji administracyjnych bez posiadania prawidłowych poświadczeń. W zależności od scenariusza atakujący może uruchamiać polecenia lub kod na poziomie serwera EMS, a następnie wykorzystywać natywne funkcje zarządzania do dalszej aktywności w środowisku.

W opisywanej kampanii serwer EMS miał służyć do dystrybucji fałszywej poprawki Fortinet uruchamianej przez PowerShell. Finalnym ładunkiem był EKZ Infostealer, którego zadaniem była kradzież danych uwierzytelniających zapisanych w przeglądarkach, między innymi w Chrome i Firefox, a następnie ich zapis lokalny i eksfiltracja przez HTTP.

Technicznie jest to szczególnie groźne połączenie dwóch elementów: kompromitacji centralnego systemu zarządzania oraz użycia zaufanej infrastruktury do wdrażania malware na wielu hostach jednocześnie. Atak nie wymaga więc osobnej kompromitacji każdej stacji roboczej, ponieważ przejęte funkcje EMS mogą stać się narzędziem masowej dystrybucji złośliwego oprogramowania.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest centralizacja ryzyka. Jedna luka w systemie zarządzania endpointami może przełożyć się na jednoczesne narażenie całej populacji urządzeń podłączonych do EMS, co otwiera drogę do wdrożenia infostealera, backdoora, a nawet ransomware na dużą skalę.

Istotnym zagrożeniem pozostaje także kradzież poświadczeń użytkowników i administratorów. Dane uwierzytelniające przejęte z przeglądarek mogą zostać później wykorzystane do dalszych ataków na pocztę, sieci VPN, usługi SaaS, środowiska chmurowe oraz panele administracyjne.

Dla organizacji regulowanych oznacza to również ryzyko naruszenia poufności danych, przestojów operacyjnych, kosztów reagowania incydentowego i potencjalnych obowiązków notyfikacyjnych. Jeśli EMS działa w segmencie o szerokiej łączności i wysokich uprawnieniach, wpływ incydentu może być szczególnie dotkliwy.

Rekomendacje

Najważniejszym krokiem jest natychmiastowe wdrożenie poprawek lub hotfixów dostarczonych przez producenta dla podatnych wersji FortiClient EMS. Organizacje korzystające z wersji 7.4.5 i 7.4.6 powinny traktować aktualizację jako działanie awaryjne.

Równolegle należy przeprowadzić aktywne polowanie na oznaki kompromitacji. Warto przeanalizować logi HTTP i logi aplikacyjne EMS pod kątem nietypowych żądań do endpointów administracyjnych, nieautoryzowanych zmian konfiguracji, niestandardowych zadań PowerShell oraz nagłych akcji dystrybucji aktualizacji do wielu hostów.

Po stronie endpointów zalecane jest sprawdzenie artefaktów mogących wskazywać na obecność infostealera, w tym podejrzanych uruchomień PowerShell, plików wykonywalnych podszywających się pod poprawki, nowych logów zawierających dane uwierzytelniające oraz nietypowego ruchu HTTP po wdrożeniu aktualizacji. W środowiskach podwyższonego ryzyka zasadne może być również wymuszenie resetu haseł użytkowników, których urządzenia mogły zostać objęte kampanią.

Dodatkowo warto ograniczyć powierzchnię ataku poprzez segmentację serwera EMS, zawężenie dostępu administracyjnego do zaufanych sieci, monitorowanie zmian konfiguracji oraz wdrożenie reguł detekcyjnych dla nietypowego użycia mechanizmów zdalnego zarządzania. W przypadku podejrzenia naruszenia bezpieczeństwa należy potraktować wszystkie urządzenia zarządzane przez EMS jako potencjalnie narażone.

Podsumowanie

CVE-2026-35616 pokazuje, jak groźne mogą być podatności w platformach centralnego zarządzania bezpieczeństwem endpointów. W tym przypadku problem nie ogranicza się do zdalnego wykonania kodu na pojedynczym serwerze, lecz obejmuje możliwość przejęcia zaufanego kanału administracyjnego i użycia go do szerokiej dystrybucji malware w organizacji.

Z uwagi na potwierdzone wykorzystanie w atakach, obecność w katalogu KEV oraz powiązanie z kampanią wykorzystującą EKZ Infostealer, luka powinna być traktowana jako zagrożenie najwyższego priorytetu. Szybkie patchowanie, walidacja integralności środowiska i przegląd oznak kompromitacji są w tym przypadku kluczowe.

Źródła

Security Affairs — https://securityaffairs.com/192817/malware/cve-2026-35616-forticlient-ems-flaw-actively-exploited-in-malware-attacks.html
FortiGuard PSIRT: FG-IR-26-099 — https://fortiguard.fortinet.com/psirt/FG-IR-26-099
Arctic Wolf — FortiClient EMS Exploited via CVE-2026-35616 to Deliver EKZ Infostealer Disguised as a Fortinet Patch — https://arcticwolf.com/resources/blog/forticlient-ems-exploited-via-cve-2026-35616-to-deliver-ekz-infostealer-disguised-as-a-fortinet-patch/
NVD — CVE-2026-35616 — https://nvd.nist.gov/vuln/detail/CVE-2026-35616
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-35616