Archiwa: VPN - Strona 25 z 156

Setki fałszywych rozszerzeń VPN dla Chrome przechwytywały ruch przez serwer proxy

Wprowadzenie do problemu / definicja

Ekosystem rozszerzeń przeglądarkowych od lat pozostaje atrakcyjnym celem nadużyć, ponieważ dodatki działają blisko danych użytkownika i często otrzymują szerokie uprawnienia. Najnowsza wykryta kampania pokazała, że nawet rozszerzenia reklamowane jako narzędzia prywatności, takie jak VPN-y i proxy, mogą w praktyce obniżać poziom bezpieczeństwa. W analizowanym przypadku setki dodatków podszywały się pod znane marki i przekierowywały ruch przeglądarki przez infrastrukturę kontrolowaną przez jednego operatora.

W skrócie

Badacze bezpieczeństwa zidentyfikowali ponad 737 rozszerzeń dla Google Chrome, które imitowały popularne usługi VPN i proxy. Część z nich konfigurowała przeglądarkę tak, aby ruch był przekazywany przez serwery SOCKS5 kontrolowane przez operatora kampanii. Łączna liczba instalacji sięgała około 75 tysięcy, a analiza wskazała na wykorzystanie 40 kont wydawców oraz wspólnego zaplecza analitycznego. Choć część dodatków została usunięta, wiele z nich pozostawało dostępnych w sklepie w chwili publikacji ustaleń.

Kontekst / historia

Fałszywe lub wprowadzające w błąd rozszerzenia nie są nowym zjawiskiem, jednak kampanie podszywające się pod usługi bezpieczeństwa mają wyjątkowo wysoki potencjał nadużyć. Użytkownicy poszukujący VPN-u zwykle chcą zwiększyć prywatność, ominąć ograniczenia regionalne lub zabezpieczyć połączenie, dlatego częściej akceptują szerokie uprawnienia i mniej krytycznie podchodzą do deklaracji producenta.

W tej kampanii operatorzy wykorzystywali nazwy, opisy i elementy identyfikacji wizualnej kojarzone z rozpoznawalnymi markami VPN oraz usługami proxy. Według ustaleń badaczy część rozszerzeń reklamowała również nieistniejące lokalizacje serwerów premium, co może wskazywać na próbę monetyzacji poprzez fałszywe plany subskrypcyjne. Tego typu praktyki naruszają zasady Chrome Web Store dotyczące podszywania się, treści spamowych oraz wprowadzania użytkowników w błąd.

Analiza techniczna

Kluczowym elementem technicznym kampanii było wymuszanie trasowania ruchu przeglądarki przez zewnętrzny serwer proxy SOCKS5, najczęściej na porcie 1082. W praktyce oznaczało to możliwość zmiany ustawień sieciowych Chrome tak, aby żądania HTTP i HTTPS przechodziły przez infrastrukturę kontrolowaną przez operatora. Sam mechanizm proxy nie jest automatycznie złośliwy, ponieważ podobnie działają legalne usługi VPN i proxy. O niebezpieczeństwie przesądzała jednak warstwa oszustwa: podszywanie się pod znane marki, ukrywanie faktycznego operatora oraz deklarowanie funkcji, których dodatek nie realizował.

Badacze opisali kilka dominujących wzorców działania:

masowe przekierowywanie ruchu do wspólnego zaplecza proxy,
wykorzystanie DNS-over-HTTPS do rozwiązywania nazw hostów proxy,
prezentowanie fikcyjnych serwerów premium w różnych krajach,
rozproszenie kampanii na wiele kont wydawców, co utrudniało szybką korelację i reakcję.

Taki model dawał operatorowi znaczną widoczność w ruch użytkownika. Nawet jeśli treść komunikacji była szyfrowana, pośrednik mógł obserwować metadane połączeń, adresy docelowe, źródłowy adres IP użytkownika oraz cały ruch przesyłany nieszyfrowanym HTTP. Dodatkowym problemem mogła być zdalna konfiguracja po zatwierdzeniu rozszerzenia w sklepie, co utrudnia wykrycie rzeczywistego zachowania na etapie weryfikacji.

Konsekwencje / ryzyko

Najbardziej oczywistym zagrożeniem jest utrata prywatności. Użytkownik instalujący fałszywy VPN może nieświadomie przekazać dane o swojej aktywności podmiotowi, którego tożsamość pozostaje ukryta. Dotyczy to historii odwiedzanych domen, wzorców połączeń, przybliżonej geolokalizacji na podstawie adresu IP oraz potencjalnie treści komunikacji nieszyfrowanej.

Drugim poziomem ryzyka jest możliwość manipulacji ruchem. Operator proxy znajdujący się na ścieżce transmisji może wpływać na odpowiedzi dla ruchu HTTP, prowadzić przekierowania, podstawiać treści lub wspierać kampanie phishingowe. W środowisku firmowym takie rozszerzenie może stać się punktem wyjścia do dalszego rozpoznania infrastruktury i obejścia części polityk bezpieczeństwa.

Trzecim obszarem zagrożeń są oszustwa finansowe i reputacyjne. Reklamowanie nieistniejących usług premium może prowadzić do wyłudzeń płatności, a podszywanie się pod legalne marki podważa zaufanie do całego segmentu narzędzi prywatności. Dla organizacji oznacza to także wzrost ryzyka shadow IT, gdy pracownicy samodzielnie instalują niezweryfikowane dodatki.

Rekomendacje

Użytkownicy indywidualni powinni w pierwszej kolejności przejrzeć listę zainstalowanych rozszerzeń i usunąć wszystkie dodatki VPN lub proxy, których pochodzenia nie potrafią jednoznacznie potwierdzić. Po odinstalowaniu warto sprawdzić, czy ustawienia proxy w Chrome i w systemie operacyjnym wróciły do stanu domyślnego oraz czy nie pozostała niestandardowa konfiguracja DNS.

Organizacje powinny wdrożyć ścisłą kontrolę rozszerzeń przeglądarkowych na poziomie polityk zarządzania punktami końcowymi. Najbezpieczniejszym podejściem pozostaje model allowlist, w którym dozwolone są wyłącznie zatwierdzone dodatki.

Monitorować obecność nieautoryzowanych rozszerzeń Chrome.
Weryfikować zmiany w ustawieniach proxy użytkownika i przeglądarki.
Analizować połączenia do nieznanych serwerów pośredniczących, zwłaszcza SOCKS5.
Sprawdzać anomalie w ruchu DNS-over-HTTPS i ruchu wychodzącym przez pojedyncze węzły pośrednie.
Edukować użytkowników, że obecność dodatku w oficjalnym sklepie nie gwarantuje bezpieczeństwa.

Podsumowanie

Opisana kampania pokazuje, że rozszerzenia reklamowane jako narzędzia ochrony prywatności mogą stać się mechanizmem przechwytywania i pośredniczenia w ruchu użytkownika. Nie chodziło wyłącznie o złośliwy kod, ale o połączenie funkcji sieciowych, ukrytej infrastruktury, podszywania się pod znane marki i potencjalnego oszustwa subskrypcyjnego. Dla użytkowników i firm to wyraźny sygnał, że bezpieczeństwo przeglądarki wymaga takiej samej kontroli jak bezpieczeństwo stacji roboczej.

Źródła

Hundreds of fake Chrome VPN extensions route traffic through a proxy — https://www.bleepingcomputer.com/news/security/hundreds-of-fake-chrome-vpn-extensions-route-traffic-through-a-proxy/
Chrome Web Store – Program Policies — https://developer.chrome.com/docs/webstore/program-policies
Impersonation & Intellectual Property — https://developer.chrome.com/docs/webstore/program-policies/impersonation-and-intellectual-property
Spam policy FAQ — https://developer.chrome.com/docs/webstore/spam-faq/
Deceptive Installation Tactics FAQ — https://developer.chrome.com/docs/webstore/program-policies/deceptive-installation-tactics-faq?authuser=0000

Nowe inicjatywy wzmacniają cyberbezpieczeństwo systemów wodnych w USA

Wprowadzenie do problemu / definicja

Cyberbezpieczeństwo sektora wodno-kanalizacyjnego należy dziś do kluczowych wyzwań związanych z ochroną infrastruktury krytycznej. Systemy uzdatniania i dystrybucji wody coraz szerzej wykorzystują rozwiązania OT, SCADA, zdalny dostęp oraz komponenty IT połączone z sieciami organizacji. Taki model zwiększa sprawność operacyjną, ale jednocześnie rozszerza powierzchnię ataku i podnosi ryzyko incydentów mogących przełożyć się na realne skutki fizyczne.

W odpowiedzi na rosnącą presję zagrożeń w Stanach Zjednoczonych rozwijane są nowe inicjatywy legislacyjne i organizacyjne, których celem jest poprawa odporności operatorów wodociągów i kanalizacji. Szczególny nacisk położono na małe i wiejskie systemy wodne, które zwykle dysponują ograniczonym budżetem, niewielkim personelem i niską dojrzałością bezpieczeństwa.

W skrócie

Nowe działania na rzecz ochrony systemów wodnych w USA opierają się na dwóch uzupełniających się filarach. Pierwszy obejmuje finansowanie szkoleń, wymiany informacji o zagrożeniach oraz wsparcia technicznego dla operatorów. Drugi koncentruje się na partnerstwach branżowych i modelach współpracy, które mają zapewnić praktyczne zdolności monitorowania, wykrywania zagrożeń i reagowania na incydenty.

większe wsparcie dla małych i średnich operatorów wodnych,
rozwój programów szkoleniowych i doradczych,
wzmocnienie wymiany informacji o zagrożeniach,
budowa zdolności operacyjnych w zakresie detekcji i reakcji,
lepsze powiązanie finansowania z realnymi potrzebami sektora OT.

Kontekst / historia

Sektor wodny od lat uchodzi za jeden z trudniejszych do zabezpieczenia segmentów infrastruktury krytycznej. Wynika to z dużego rozproszenia organizacyjnego, zróżnicowanego poziomu dojrzałości technologicznej oraz ograniczonych zasobów po stronie lokalnych operatorów. W praktyce wiele systemów nadal działa w oparciu o starsze środowiska sterowania, niewystarczająco odseparowane sieci i ograniczony nadzór nad bezpieczeństwem.

W ostatnich latach problem zyskał większą widoczność za sprawą incydentów, ostrzeżeń i analiz dotyczących podatności infrastruktury wodnej. Do wywołania istotnego zakłócenia nie jest potrzebny wysoce zaawansowany atak destrukcyjny. Często wystarczy przejęcie zdalnego dostępu, wykorzystanie nieaktualnych kont, błąd konfiguracji urządzeń brzegowych albo naruszenie interfejsu operatorskiego. To zwiększyło presję na ustawodawców i regulatorów, aby zapewnić operatorom konkretne narzędzia podnoszące poziom ochrony.

Na tym tle pojawiły się inicjatywy ustawowe wspierające finansowanie cyberbezpieczeństwa systemów wodnych, w tym członkostwa w wyspecjalizowanych centrach wymiany informacji, programów szkoleniowych oraz pomocy technicznej dla mniejszych podmiotów. Równolegle rozwijane są partnerstwa branżowe, które mają przełożyć politykę i środki finansowe na codzienne działania operacyjne.

Analiza techniczna

Z technicznego punktu widzenia największym wyzwaniem pozostaje zderzenie środowisk OT z wymaganiami nowoczesnego bezpieczeństwa teleinformatycznego. Wiele instalacji wykorzystuje urządzenia PLC, RTU, panele HMI, systemy telemetryczne i serwery historyczne projektowane przede wszystkim pod kątem ciągłości procesu, a nie odporności na współczesne zagrożenia cybernetyczne.

Typowy profil ryzyka w systemach wodnych obejmuje zarówno luki technologiczne, jak i problemy organizacyjne.

nadmierny lub słabo kontrolowany zdalny dostęp do sieci OT,
brak pełnej segmentacji pomiędzy IT i OT,
słabe zarządzanie tożsamością oraz kontami uprzywilejowanymi,
opóźnienia w aktualizacjach systemów i oprogramowania przemysłowego,
ograniczoną widoczność ruchu sieciowego i brak detekcji anomalii,
zależność od integratorów i dostawców utrzymania.

Nowe inicjatywy próbują odpowiadać właśnie na te problemy. Wsparcie dla szkoleń, wymiany danych o zagrożeniach i pomocy technicznej może pomóc operatorom szybciej identyfikować słabe punkty oraz wdrażać podstawowe mechanizmy obrony. Równie istotny jest model koordynacji sektorowej, który można traktować jako próbę stworzenia wspólnej warstwy usług: agregacji telemetryki, dystrybucji ostrzeżeń, opracowywania procedur reagowania i dostarczania ekspertyzy podmiotom nieposiadającym własnych zespołów bezpieczeństwa.

W praktyce skuteczna obrona środowiska wodociągowego nie sprowadza się do wdrożenia klasycznych narzędzi endpoint security. Kluczowe znaczenie mają także działania typowe dla ochrony OT.

inwentaryzacja aktywów i zależności technologicznych,
kontrola połączeń zdalnych do stacji operatorskich i urządzeń sterujących,
monitoring zmian konfiguracji,
kopie zapasowe konfiguracji i systemów inżynierskich,
testowane scenariusze pracy awaryjnej,
plany reagowania na incydenty uwzględniające skutki operacyjne i sanitarne.

Konsekwencje / ryzyko

Cyberbezpieczeństwo systemów wodnych ma znaczenie wykraczające daleko poza obszar IT. Udany atak może skutkować zakłóceniem dostaw wody, utratą widoczności procesowej, błędnym dozowaniem chemikaliów, przestojami oczyszczalni ścieków oraz kosztami regulacyjnymi, operacyjnymi i reputacyjnymi. Dla małych społeczności nawet krótkotrwały incydent może oznaczać poważne zaburzenie ciągłości usług publicznych.

Poziom ryzyka rośnie szczególnie tam, gdzie odpowiedzialność za IT i OT spoczywa na jednej osobie, monitoring nie działa całodobowo, urządzenia przemysłowe są dostępne z internetu albo organizacja korzysta ze współdzielonych kont i nie ćwiczy procedur odtworzeniowych. Z perspektywy strategicznej sektor wodny pozostaje również atrakcyjnym celem działań demonstracyjnych, sabotażowych i presji politycznej, ponieważ nawet niewielki operator może mieć wysoką wartość symboliczną przy relatywnie niskim poziomie zabezpieczeń.

Rekomendacje

Operatorzy systemów wodnych powinni wykorzystać nowe programy wsparcia jako impuls do wdrożenia podstawowych, ale konsekwentnie realizowanych praktyk bezpieczeństwa. Największy efekt przynoszą zwykle działania ograniczające dostęp, poprawiające widoczność środowiska i zwiększające gotowość operacyjną.

przeprowadzić pełną inwentaryzację zasobów IT i OT oraz mapowanie połączeń,
ograniczyć zdalny dostęp do autoryzowanych kanałów z MFA i rejestrowaniem sesji,
wdrożyć segmentację sieci i separację systemów sterowania od sieci biurowej,
usunąć nieaktywne konta byłych pracowników i dostawców,
wprowadzić zasadę najmniejszych uprawnień,
monitorować logi z firewalli, VPN, stacji operatorskich i kluczowych serwerów,
utrzymywać kopie zapasowe konfiguracji PLC, HMI i serwerów inżynierskich,
regularnie testować procedury przejścia na tryb manualny lub awaryjny,
korzystać z branżowych kanałów wymiany informacji o zagrożeniach,
szkolić personel z bezpiecznej obsługi środowisk OT, a nie wyłącznie z phishingu.

Dla regulatorów i decydentów kluczowe będzie utrzymanie modelu, w którym finansowanie idzie w parze z praktycznym wsparciem technicznym. Same wymagania formalne nie wystarczą, jeśli małe podmioty nie otrzymają dostępu do kompetencji, usług i narzędzi możliwych do wdrożenia przy ograniczonych zasobach.

Podsumowanie

Nowe inicjatywy wzmacniające cyberbezpieczeństwo amerykańskich systemów wodnych pokazują, że ochrona infrastruktury krytycznej jest coraz częściej traktowana jako problem operacyjny, a nie wyłącznie regulacyjny. Połączenie działań ustawodawczych, finansowania, wymiany informacji o zagrożeniach i wsparcia środowiskowego może realnie zwiększyć odporność sektora, zwłaszcza wśród małych i wiejskich operatorów.

Największym wyzwaniem pozostaje jednak przełożenie tych założeń na codzienną praktykę. To właśnie kontrola dostępu, segmentacja, monitoring, gotowość do reagowania i rozwój kompetencji OT zdecydują o tym, czy nowe programy przyniosą trwałą poprawę bezpieczeństwa.

Źródła

US Lawmakers Reintroduce Bill to Boost Rural Water Cybersecurity — https://www.securityweek.com/us-lawmakers-reintroduce-bill-to-boost-rural-water-cybersecurity/
Water Intelligence, Security, and Cyber Threat Protection Act of 2025 — https://www.congress.gov/bill/119th-congress/senate-bill/1118/text
Cybersecurity of the Municipal Water Sector: Background and Issues for Congress — https://www.congress.gov/crs-product/R48556
Cybersecurity Funding | US EPA — https://www.epa.gov/cyberwater/cybersecurity-funding
Cybersecurity | National Rural Water Association — https://nrwa.org/issues/cybersecurity/

Fałszywy startup kryptowalutowy ujawnił schemat zatrudniania podejrzanych północnokoreańskich pracowników IT

Wprowadzenie do problemu / definicja

Zagrożenia typu insider threat coraz częściej zaczynają się nie od exploita, phishingu czy podatności w oprogramowaniu, lecz od pozornie legalnego procesu rekrutacyjnego. Najnowszy opisany przypadek pokazuje, że zorganizowane grupy mogą uzyskiwać dostęp do środowisk firmowych poprzez zatrudnienie pod fałszywą tożsamością jako zdalni programiści.

W praktyce oznacza to, że wektor wejścia do organizacji może być w pełni autoryzowany, a jednocześnie stanowić element działalności wywiadowczej, finansowej lub sabotażowej. To szczególnie niebezpieczne dla firm technologicznych, które powierzają nowym pracownikom dostęp do kodu, systemów chmurowych i komunikacji wewnętrznej już na wczesnym etapie onboardingu.

W skrócie

Badacze bezpieczeństwa stworzyli fikcyjny startup z obszaru DeFi i opublikowali oferty pracy dla programistów. W rezultacie zatrudnili trzy osoby, które według ich oceny były powiązane z północnokoreańską operacją pracowników IT działających pod fałszywymi tożsamościami.

Każdy z zatrudnionych otrzymał monitorowaną maszynę wirtualną, co pozwoliło śledzić ich aktywność od pierwszego dnia pracy. W toku obserwacji wykryto niespójności w dokumentach, ślady użycia narzędzi AI do edycji obrazów, korzystanie z infrastruktury maskującej pochodzenie połączeń oraz szybkie działania rozpoznawcze po uzyskaniu dostępu do środowiska roboczego.

fikcyjna firma posłużyła jako kontrolowane środowisko badawcze,
trzy osoby przeszły proces rekrutacji i onboarding,
zaobserwowano oznaki fałszywej tożsamości i ukrywania lokalizacji,
po uzyskaniu dostępu rozpoczęto rekonesans systemowy.

Kontekst / historia

Model działania polegający na lokowaniu podstawionych pracowników IT w zagranicznych firmach jest znany od kilku lat i był wielokrotnie opisywany przez administrację USA oraz branżę bezpieczeństwa. Celem takich operacji bywa generowanie przychodów, omijanie sankcji, uzyskiwanie dostępu do systemów przedsiębiorstw oraz budowanie trwałej obecności w środowiskach ofiar.

Opisywany eksperyment rozwija wcześniejsze badania nad pośrednikami udostępniającymi tożsamości i wspierającymi fikcyjne profile kandydatów. Tym razem badacze przyjęli odwrotną rolę i wystąpili jako pracodawca. Stworzyli pozornie legalny projekt kryptowalutowy, aby prześledzić cały łańcuch dostępu — od aplikacji kandydata, przez onboarding, aż po aktywność w przydzielonym środowisku pracy.

Znaczenie tej sprawy wykracza poza sektor krypto. Podobne kampanie były wcześniej łączone z wykorzystaniem skradzionych lub pożyczonych tożsamości obywateli USA oraz z zatrudnieniem w wielu firmach technologicznych. To oznacza, że zagrożenie dotyczy także software house’ów, dostawców SaaS, fintechów oraz organizacji opierających się na pracy zdalnej.

Analiza techniczna

Najważniejszym elementem tej operacji nie był exploit, lecz przejęcie zaufania organizacyjnego. Kandydaci przeszli proces rekrutacyjny, podpisali dokumenty i uzyskali legalny dostęp do służbowych zasobów. Taki scenariusz jest szczególnie trudny do wykrycia, ponieważ aktywność użytkownika początkowo nie wygląda jak klasyczne włamanie.

Badacze wskazali na liczne anomalie w materiałach identyfikacyjnych. W jednym przypadku kandydat deklarował miejsce zamieszkania w Teksasie, lecz dane wskazywały na niespójne powiązania z różnymi stanami i informacjami finansowymi. W innym przypadku metadane miały sugerować przetwarzanie obrazu z użyciem narzędzi Google Gemini oraz obecność znacznika SynthID, kojarzonego z treściami generowanymi lub modyfikowanymi przez modele AI. U kolejnej osoby stwierdzono użycie dokumentu należącego do innej osoby oraz modyfikację zdjęć utrudniającą geolokalizację.

Po uzyskaniu dostępu do maszyn roboczych zatrudnione osoby niemal natychmiast rozpoczęły rekonesans systemowy. Zaobserwowano użycie poleceń i narzędzi takich jak dxdiag, systeminfo oraz wmic w celu identyfikacji konfiguracji hosta i środowiska. Sprawdzano również, z jakiego kraju widoczne jest połączenie, co może sugerować chęć potwierdzenia skuteczności stosowanych metod maskowania lokalizacji.

W jednym z przypadków operator zainstalował Chrome Remote Desktop i zsynchronizował prywatne konto Google z udostępnioną maszyną. Taki krok może służyć przejmowaniu sesji przez innych operatorów, zapewnieniu trwałego dostępu do środowiska oraz współdzieleniu danych uwierzytelniających i artefaktów przeglądarki. Z perspektywy obronnej jest to wyraźny sygnał naruszenia zasad separacji tożsamości prywatnej i służbowej.

Badacze odnotowali także zmianę zestawu narzędzi względem wcześniejszych obserwacji. Wśród widocznych elementów znalazły się usługi przekazywania kodów 2FA, konta Outlook wykorzystywane obok innych platform pocztowych oraz rozszerzenia przeglądarkowe wspierające automatyzację aplikowania o pracę i przygotowania do rozmów kwalifikacyjnych, również z użyciem AI. Infrastruktura sieciowa miała obejmować serwery VPS oraz wyjścia VPN używane do ukrywania pochodzenia ruchu.

Technicznie była to więc operacja mieszana, łącząca socjotechnikę, nadużycie lub kradzież tożsamości, obchodzenie kontroli HR i KYC, anonimizację sieciową, rekonesans na endpointach oraz potencjalne przygotowanie do dalszych działań wewnątrz organizacji.

Konsekwencje / ryzyko

Dla organizacji skutki takiego incydentu mogą być bardzo poważne nawet bez użycia malware. Podstawiony pracownik może uzyskać dostęp do repozytoriów kodu, pipeline’ów CI/CD, menedżerów sekretów, paneli administracyjnych, środowisk chmurowych oraz komunikacji wewnętrznej.

W konsekwencji możliwe są:

kradzież własności intelektualnej,
sabotaż procesu wytwórczego,
wstrzyknięcie backdoora do kodu,
eksfiltracja danych klientów,
przygotowanie późniejszego ataku na łańcuch dostaw.

Dodatkowym problemem jest trudność w odróżnieniu wrogiej aktywności od legalnej pracy administracyjnej lub deweloperskiej. Nowy pracownik ma uzasadniony powód do uruchamiania narzędzi systemowych, logowania do repozytoriów, konfiguracji środowiska programistycznego czy łączenia się z systemami testowymi. To znacząco obniża skuteczność tradycyjnych mechanizmów detekcji opartych wyłącznie na anomaliach technicznych.

W szerszym ujęciu problem obejmuje też zgodność regulacyjną i ryzyko finansowe. Organizacja może nieświadomie wypłacać wynagrodzenie podmiotom objętym sankcjami, naruszać obowiązki due diligence lub narażać się na konsekwencje prawne związane z ochroną danych i eksportem technologii.

Rekomendacje

Firmy zatrudniające zdalnych specjalistów IT powinny traktować proces rekrutacyjny jako część architektury bezpieczeństwa. Oznacza to konieczność wdrożenia wieloetapowej weryfikacji tożsamości, a nie tylko jednorazowego sprawdzenia podczas onboardingu.

porównywanie deklarowanego miejsca pobytu z dokumentami, rachunkami, numerami telefonu i strefą czasową aktywności,
okresowe ponowne potwierdzanie tożsamości pracowników zdalnych,
rozmowy wideo i weryfikacja dokumentów na żywo,
analiza spójności behawioralnej i językowej kandydata,
szczególna ostrożność wobec kandydatów unikających kamery lub przesyłających dokumenty z oznakami edycji.

Od strony technicznej zalecane jest dostarczanie ściśle kontrolowanych środowisk roboczych, najlepiej w modelu VDI lub odseparowanych maszyn wirtualnych, z pełnym rejestrowaniem aktywności administracyjnej, ograniczeniami kopiowania danych oraz blokadą nieautoryzowanych narzędzi zdalnego dostępu. Warto wdrożyć alerty dotyczące instalacji aplikacji do zdalnego pulpitu, synchronizacji prywatnych kont oraz nietypowych rozszerzeń przeglądarkowych.

Dostęp powinien być nadawany zgodnie z zasadą najmniejszych uprawnień i etapowany. Nowy pracownik nie powinien od razu otrzymywać pełnego dostępu do produkcji, sekretów, kluczy podpisujących czy krytycznych repozytoriów. Konieczne jest również monitorowanie użycia systemów kodowych, tokenów OAuth, menedżerów haseł i zasobów chmurowych pod kątem nietypowych wzorców.

Równie ważne jest przeszkolenie działów HR, rekruterów i menedżerów technicznych. To oni najczęściej jako pierwsi dostrzegają sygnały ostrzegawcze, takie jak niespójne CV, pośpiech w zatrudnieniu, nacisk na pracę wyłącznie zdalną, problemy z potwierdzeniem lokalizacji czy nietypowe zachowanie podczas rozmowy rekrutacyjnej.

Podsumowanie

Przypadek fałszywego startupu kryptowalutowego pokazuje, że współczesne zagrożenia dla firm technologicznych coraz częściej omijają klasyczne granice bezpieczeństwa i wykorzystują zaufanie organizacyjne. Zatrudnienie podstawionego pracownika może być równie skutecznym wektorem kompromitacji jak spear phishing czy luka zdalnego wykonania kodu.

Najważniejszy wniosek jest prosty: bezpieczeństwo rekrutacji zdalnej stało się integralną częścią cyberbezpieczeństwa przedsiębiorstwa. Organizacje powinny łączyć kontrolę tożsamości, monitorowanie endpointów, segmentację dostępu oraz ścisłą współpracę między HR a zespołami bezpieczeństwa.

Źródła

Atak na polską elektrociepłownię przez prywatny APN doprowadził do wyłączenia turbiny

Wprowadzenie do problemu

Incydent dotyczący polskiej elektrociepłowni pokazuje, że pozorna izolacja systemów OT i ICS nie gwarantuje realnego bezpieczeństwa. W tym przypadku prywatny APN, często uznawany za bezpieczny kanał komunikacji z urządzeniami zdalnymi, stał się wektorem ruchu bocznego, który umożliwił napastnikom ingerencję w proces technologiczny.

Skutkiem ataku było zatrzymanie turbiny oraz zakłócenie działania systemu uzdatniania wody procesowej. To szczególnie istotny sygnał ostrzegawczy dla operatorów infrastruktury krytycznej, którzy wykorzystują prywatne sieci komórkowe jako element architektury komunikacyjnej.

W skrócie

Atak dotknął elektrociepłownię obsługującą około 50 tys. mieszkańców. Z ujawnionych informacji wynika, że intruzi przeszli z kompromitowanej infrastruktury farmy wiatrowej do środowiska sterowania zakładu przez prywatny APN operatora sieci dystrybucyjnej.

Następnie, korzystając z legalnych funkcji urządzeń oraz standardowych protokołów przemysłowych, przełączyli sterowniki PLC w tryb STOP. Dodatkowo zresetowali i przeparametryzowali wybrane urządzenia sieciowe, aby utrudnić odzyskanie środowiska i analizę powłamaniową.

wektor wejścia prowadził przez prywatny APN, a nie bezpośrednio z internetu do OT,
napastnicy wykorzystali słabe zabezpieczenia dostępu zdalnego,
atak nie wymagał klasycznego malware,
użyto natywnych funkcji administracyjnych i przemysłowych.

Kontekst i historia incydentu

Do incydentu doszło w grudniu 2025 roku, ale jego szczegóły zostały ujawnione dopiero po dłuższym dochodzeniu. Sprawa wpisuje się w szerszy kontekst zagrożeń dla polskiej infrastruktury krytycznej i pokazuje, że zagrożenie może wynikać nie tylko z ekspozycji usług publicznych, lecz także z błędnych założeń architektonicznych dotyczących sieci pośrednich.

Prywatny APN jest często traktowany jako warstwa separacji między środowiskiem przemysłowym a sieciami otwartymi. Problem pojawia się wtedy, gdy konfiguracja dopuszcza komunikację między klientami, a podłączone urządzenia posiadają słabe lub domyślne mechanizmy uwierzytelniania. W takiej sytuacji APN przestaje pełnić rolę bariery i staje się wspólną płaszczyzną ruchu dla atakującego.

Analiza techniczna

Łańcuch ataku rozpoczął się od farmy wiatrowej, gdzie urządzenie FortiGate pełniło funkcję zapory i koncentratora VPN. Dostęp zdalny był wystawiony do internetu, a konta nie były chronione przez uwierzytelnianie wieloskładnikowe. Po przejęciu uprawnień administracyjnych napastnik uzyskał możliwość dalszego poruszania się po środowisku.

Kolejnym elementem był router komórkowy Teltonika RUTX50 połączony z prywatnym APN. Analiza wskazała na skuteczne logowania przez SSH, co sugeruje wykorzystanie tunelowania przez router do wejścia do sieci prywatnej operatora.

Po przeskanowaniu APN napastnicy odnaleźli sterownik WAGO PFC200 z publicznie dostępnym interfejsem administracyjnym oraz domyślnymi poświadczeniami. Ten element stał się punktem krytycznym całego scenariusza, ponieważ umożliwił dalsze tunelowanie do sieci OT elektrociepłowni.

W dalszej fazie odnotowano połączenia do trzech sterowników Siemens przez protokół S7. Najpewniej był to etap rekonesansu, po którym przystąpiono do działań destrukcyjnych. Sterowniki Siemens z rodzin S7-300, S7-1200 i S7-1500 zostały przełączone w tryb STOP oraz zabezpieczone hasłami, co doprowadziło do zatrzymania turbiny i zakłócenia pracy systemów pomocniczych.

Równolegle zresetowano do ustawień fabrycznych kilka urządzeń infrastrukturalnych, w tym serwery portów szeregowych Moxa i przełączniki. Zmieniono im hasła oraz przypisano nieosiągalne adresy IP, co utrudniło odzyskanie środowiska. Po zakończeniu działań uszkodzono także ścieżkę wejścia i część artefaktów, między innymi przez reset urządzeń oraz utratę logów.

To klasyczny przykład ataku typu living off the land w środowisku OT. Napastnicy nie musieli wdrażać złośliwego oprogramowania, ponieważ wykorzystali dozwolone funkcje administracyjne i wspierane protokoły przemysłowe.

Konsekwencje i ryzyko

Najważniejszy wniosek z incydentu jest prosty: prywatny APN sam w sobie nie zapewnia skutecznej separacji bezpieczeństwa. Jeśli jeden z podłączonych węzłów zostanie przejęty, napastnik może próbować przemieszczać się poziomo do innych zasobów działających w tej samej przestrzeni komunikacyjnej.

Ryzyko ma kilka wymiarów. Po pierwsze, dostęp do interfejsów zarządczych OT umożliwia zmianę stanu procesu technologicznego, a nie tylko obserwację. Po drugie, domyślne poświadczenia znacząco skracają drogę do przejęcia kolejnych urządzeń. Po trzecie, resetowanie sprzętu i niszczenie logów utrudnia analizę śledczą oraz odtwarzanie środowiska. Po czwarte, brak malware nie oznacza niższego poziomu zagrożenia, bo działania oparte na legalnych funkcjach są często trudniejsze do wykrycia.

Dla operatorów infrastruktury krytycznej taki scenariusz oznacza ryzyko przestojów, wzrost kosztów odtworzenia, potencjalne konsekwencje regulacyjne oraz szkody reputacyjne. Nawet jeśli nie doszło do długotrwałych przerw w dostawach, samo zdalne zatrzymanie elementów procesu technologicznego należy traktować jako incydent wysokiej wagi.

Rekomendacje

Organizacje korzystające z prywatnych APN w środowiskach przemysłowych powinny zweryfikować, czy włączono izolację klientów oraz czy komunikacja między urządzeniami odbywa się wyłącznie wtedy, gdy jest to rzeczywiście uzasadnione operacyjnie. APN nie powinien być uznawany za strefę zaufaną, lecz za medium transportowe wymagające pełnej kontroli bezpieczeństwa.

usunąć domyślne poświadczenia ze sterowników, routerów i urządzeń sieciowych,
włączyć MFA dla wszystkich kont z dostępem zdalnym,
ograniczyć interfejsy WWW, SSH i inne usługi zarządcze tylko do wybranych segmentów,
wdrożyć ścisłą segmentację między IT, sieciami pośrednimi i OT,
monitorować logowania administracyjne, zmiany konfiguracji PLC i przełączenia w tryb STOP,
utrzymywać kopie zapasowe konfiguracji oraz procedury szybkiego odtworzenia,
przeprowadzać ćwiczenia reagowania na incydenty obejmujące scenariusze bez malware,
zapewnić retencję logów odporną na reset urządzeń i utratę lokalnych artefaktów.

Podsumowanie

Atak na polską elektrociepłownię pokazuje, że bezpieczeństwo infrastruktury krytycznej nie może opierać się na pojedynczym założeniu architektonicznym. Prywatna sieć komórkowa nie zastąpi segmentacji, silnego uwierzytelniania, kontroli dostępu i monitorowania działań administracyjnych.

Napastnicy wykorzystali kombinację słabych zabezpieczeń, braku MFA, nadmiernie otwartej komunikacji w APN i domyślnych poświadczeń, aby przejść od kompromitacji jednego obiektu do zakłócenia pracy innego. Dla zespołów OT i bezpieczeństwa to wyraźny sygnał, że model zagrożeń musi obejmować również sieci komórkowe, zarządzanie zdalne oraz zależności między rozproszonymi obiektami infrastrukturalnymi.

Źródła

The Hacker News — Hackers Breach Polish Power Plant Controls via Private Cellular Network and Shut Turbine — https://thehackernews.com/2026/08/hackers-breach-polish-power-plant.html
CERT Polska — komunikaty i analiza incydentu — https://cert.pl/
Teltonika Networks Wiki — RutOS versions earlier than 7.07 — https://wiki.teltonika-networks.com/
CISA — Teltonika advisory dotyczący urządzeń RUT — https://www.cisa.gov/
Rząd RP — informacje dotyczące kampanii wymierzonej w infrastrukturę krytyczną — https://www.gov.pl/

Gunra ransomware wykorzystuje luki Fortinet i Schneider Electric do ataków na sieci firm

Wprowadzenie do problemu / definicja

Gunra to aktywna rodzina ransomware działająca w modelu podwójnego wymuszenia, w którym atakujący nie tylko szyfrują zasoby ofiary, ale wcześniej wykradają dane, aby zwiększyć presję na zapłatę okupu. Najnowsze obserwacje pokazują, że grupa wykorzystuje podatności w urządzeniach brzegowych oraz komponentach środowisk przemysłowych, aby uzyskać początkowy dostęp do infrastruktury organizacji.

Taki sposób działania wpisuje się w rosnący trend nadużywania systemów wystawionych do internetu jako punktu wejścia do sieci przedsiębiorstw. Szczególnie niebezpieczne są tu urządzenia VPN, zapory, proxy bezpieczeństwa oraz elementy OT i ICS, które po kompromitacji mogą stać się furtką do dalszej eskalacji ataku.

W skrócie

Gunra atakuje organizacje z wielu sektorów, w tym infrastrukturę krytyczną, ochronę zdrowia, usługi publiczne i finanse.
W analizowanych incydentach wykorzystywano luki CVE-2025-24472 w FortiOS i FortiProxy oraz CVE-2024-5559 w Schneider Electric PowerLogic P5.
Po uzyskaniu dostępu napastnicy prowadzili eskalację uprawnień, kradzież poświadczeń, ruch boczny przez SMB oraz eksfiltrację danych.
Końcowa faza obejmowała usuwanie logów, niszczenie kopii zapasowych i szyfrowanie kluczowych systemów.

Kontekst / historia

Gunra pojawiła się w krajobrazie zagrożeń w 2025 roku i z czasem rozwinęła działalność w kierunku modelu RaaS, umożliwiającego współpracę z afiliantami. Według dostępnych informacji grupa koncentrowała się na podmiotach z Azji Wschodniej, Europy i Australii, jednak jej kampanie miały charakter globalny.

Znaczenie zagrożenia wzrosło wraz z ostrzeżeniami dotyczącymi ataków na podmioty o wysokim znaczeniu operacyjnym, w tym organizacje związane z infrastrukturą krytyczną. To pokazuje, że współczesne kampanie ransomware coraz częściej wykraczają poza klasyczne środowiska biurowe i obejmują także systemy przemysłowe oraz energetyczne.

Analiza techniczna

W opisywanych incydentach początkowy dostęp był uzyskiwany przez wykorzystanie podatności w rozwiązaniach Fortinet oraz Schneider Electric. W przypadku CVE-2025-24472 chodzi o obejście uwierzytelnienia w FortiOS i FortiProxy, które w określonych warunkach może pozwolić zdalnemu, nieuwierzytelnionemu napastnikowi na uzyskanie wysokich uprawnień administracyjnych. To szczególnie groźny scenariusz dla urządzeń perymetrycznych, ponieważ umożliwia wejście do środowiska bez użycia legalnych kont.

Druga z luk, CVE-2024-5559, dotyczy Schneider Electric PowerLogic P5. Problem ma charakter kryptograficzny i może prowadzić do odmowy usługi, restartu urządzenia lub nawet pełnego przejęcia kontroli nad przekaźnikiem po wykorzystaniu specjalnie przygotowanego tokenu resetu. Obecność tej podatności w łańcuchu ataku pokazuje, że operatorzy ransomware coraz śmielej sięgają po komponenty środowisk OT.

Po wejściu do infrastruktury Gunra stosowała klasyczny zestaw technik post-exploitation. Obserwowano użycie narzędzi z pakietu Impacket do zdalnego wykonywania poleceń przez SMB oraz pozyskiwania danych uwierzytelniających z kontrolerów domeny. Atakujący przejmowali hashe z bazy NTDS, uzyskiwali dostęp do kont uprzywilejowanych i poruszali się lateralnie pomiędzy kolejnymi systemami.

W części przypadków wykorzystywano także dostęp do środowisk VDI personelu IT, co umożliwiało kradzież dokumentacji konfiguracyjnej oraz informacji o topologii sieci. Dodatkowo opisywano manipulowanie ruchem na urządzeniach SSL-VPN w celu przechwycenia poświadczeń i informacji o sesjach użytkowników. Skradzione ciasteczka sesyjne mogły następnie posłużyć do przejęcia aktywnych sesji i podszycia się pod legalnych użytkowników.

W bardziej zaawansowanych scenariuszach atakujący obchodzili MFA przez modyfikację komponentów odpowiedzialnych za uwierzytelnianie w portalu VDI. Na końcowym etapie prowadzono czyszczenie logów systemowych i sieciowych, usuwanie historii poleceń, eksfiltrację danych z zasobów lokalnych i usług chmurowych, a następnie niszczenie kopii zapasowych przed wdrożeniem modułu szyfrującego.

Konsekwencje / ryzyko

Ryzyko związane z aktywnością Gunra jest wysokie, ponieważ kampanie tej grupy łączą kilka silnie destrukcyjnych elementów: wykorzystanie publicznie dostępnych luk, kradzież danych, przejmowanie tożsamości, niszczenie backupów i szyfrowanie systemów. Nawet jeśli organizacja jest w stanie odtworzyć środowisko z kopii zapasowych, pozostaje problem wycieku informacji i możliwych skutków regulacyjnych, finansowych oraz reputacyjnych.

Skutki incydentu mogą obejmować niedostępność systemów biznesowych, zatrzymanie procesów operacyjnych, utratę dostępu do baz danych, zakłócenie pracy środowisk VDI, kompromitację kont uprzywilejowanych oraz ujawnienie dokumentacji technicznej. W sektorach przemysłowych i energetycznych dodatkowo pojawia się ryzyko wpływu na systemy o znaczeniu fizycznym i operacyjnym.

Rekomendacje

Organizacje powinny priorytetowo zweryfikować, czy używane instancje FortiOS, FortiProxy oraz urządzenia Schneider Electric są podatne na wskazane błędy, a następnie niezwłocznie wdrożyć poprawki i zalecenia producentów. Szczególną uwagę należy poświęcić systemom wystawionym bezpośrednio do internetu.

Włączyć ścisły monitoring urządzeń perymetrycznych, w tym VPN, firewalli i proxy.
Przeprowadzić przegląd konfiguracji Security Fabric oraz kont administracyjnych i serwisowych.
Zweryfikować integralność komponentów odpowiedzialnych za MFA i uwierzytelnianie.
Ograniczyć ruch lateralny przez segmentację sieci i separację środowisk administracyjnych.
Monitorować użycie narzędzi takich jak Impacket, PsExec, SMB admin shares i mechanizmy dumpingu poświadczeń.
Wdrożyć kopie zapasowe niemutowalne, offline i regularnie testowane.
Objąć OneDrive, SharePoint i środowiska VDI dodatkowymi regułami detekcji anomalii.
Centralizować logi i zabezpieczyć je przed usunięciem przez napastnika.
Rotować poświadczenia uprzywilejowane po każdym podejrzeniu kompromitacji urządzeń brzegowych.
Przeprowadzić threat hunting pod kątem przejętych sesji, nocnych logowań i dużych transferów danych.

W środowiskach OT warto dodatkowo odseparować sieci przemysłowe od IT, ograniczyć zdalny dostęp do kontrolowanych punktów pośredniczących i prowadzić dokładną inwentaryzację firmware’u oraz komponentów zarządzających.

Podsumowanie

Aktywność Gunra potwierdza, że nowoczesne operacje ransomware coraz częściej rozpoczynają się od kompromitacji urządzeń brzegowych i systemów o wysokiej wartości operacyjnej. Wykorzystanie luk w rozwiązaniach Fortinet i Schneider Electric pokazuje, że granica między cyberatakami na klasyczne środowiska IT a systemami przemysłowymi staje się coraz mniej wyraźna.

Dla zespołów bezpieczeństwa oznacza to konieczność równoległego wzmacniania kilku obszarów: zarządzania podatnościami, monitoringu urządzeń perymetrycznych, ochrony tożsamości, segmentacji sieci oraz odporności kopii zapasowych. Im szybciej organizacje ograniczą ekspozycję publicznych usług i poprawią widoczność aktywności w sieci, tym większa szansa na zatrzymanie podobnych kampanii przed etapem szyfrowania danych.

Źródła

The Hacker News — https://thehackernews.com/2026/08/gunra-ransomware-exploits-fortinet-and.html
NVD: CVE-2025-24472 — https://nvd.nist.gov/vuln/detail/CVE-2025-24472
NVD: CVE-2024-5559 — https://nvd.nist.gov/vuln/detail/CVE-2024-5559

Fałszywe rozmowy rekrutacyjne jako wektor ataku: UAC-0145 wykorzystuje trojanizowany VPN

Wprowadzenie do problemu / definicja

Socjotechnika od lat pozostaje jednym z najskuteczniejszych sposobów uzyskania dostępu do środowisk firmowych. Najnowsza kampania przypisywana klastrowi UAC-0145 pokazuje, że nawet proces rekrutacyjny może zostać wykorzystany jako wiarygodny kanał dostarczenia złośliwego oprogramowania. W tym scenariuszu ofiara otrzymuje pozornie legalne narzędzie VPN, które w rzeczywistości umożliwia uruchamianie poleceń na przejętym systemie.

Ataki tego typu są szczególnie groźne, ponieważ wykorzystują naturalne zaufanie kandydatów do działań prowadzonych przez rzekomych rekruterów. Gdy celem stają się administratorzy i specjaliści IT, skutki udanej kompromitacji mogą wykraczać daleko poza pojedynczą stację roboczą.

W skrócie

Operatorzy kampanii kontaktowali się z kandydatami za pośrednictwem portali pracy i komunikatorów, podszywając się pod rekruterów. Po wstępnej selekcji ofiara była zapraszana na rozmowę techniczną i otrzymywała pliki konfiguracyjne do połączenia z rzekomą firmową siecią VPN.

Gdy standardowa konfiguracja nie działała, napastnicy proponowali pobranie alternatywnego klienta o nazwie SopraVPN. Program, przygotowany na bazie kodu WireGuard, zawierał jednak modyfikacje pozwalające odszyfrować ukryty kod PowerShell i uruchomić go na systemie ofiary, a następnie pobrać kolejny etap infekcji.

Kontekst / historia

Według ustaleń ukraińskiego CERT kampania trwa co najmniej od maja 2026 roku i została powiązana z UAC-0145, opisywanym jako podgrupa szerszego ekosystemu Sandworm. Ten przeciwnik jest od lat kojarzony z zaawansowanymi operacjami wymierzonymi w Ukrainę, sektor publiczny i infrastrukturę krytyczną.

Na uwagę zasługuje wieloetapowy charakter operacji. Atak nie ogranicza się do pojedynczej wiadomości phishingowej, lecz obejmuje analizę CV, kontakt przez czat, przeniesienie rozmowy do Telegrama, udział w rozmowie wideo oraz przesłanie materiałów rzekomo niezbędnych do wykonania zadania technicznego. Taki przebieg znacząco zwiększa wiarygodność całej historii i obniża czujność ofiary.

Analiza techniczna

Techniczny rdzeń kampanii opiera się na dostarczeniu zmanipulowanego klienta VPN. Z perspektywy użytkownika wygląda on jak standardowe narzędzie do bezpiecznego dostępu zdalnego, jednak w praktyce jego binaria zostały zmodyfikowane w taki sposób, aby przetwarzać niestandardowe dane ukryte w pliku konfiguracyjnym.

Kluczową rolę odgrywa opcja konfiguracyjna SymmetricKey. Parametr ten zawiera dane zakodowane w Base64, wykorzystywane następnie do odszyfrowania ukrytego ładunku przy użyciu AES-256-GCM. Jako materiał kluczowy służy 32-bajtowa wartość uzyskana po dekodowaniu pola PrivateKey. Po odszyfrowaniu skrypt PowerShell jest uruchamiany przez mechanizm przypominający funkcje wykonywania poleceń po zestawieniu interfejsu sieciowego.

W praktyce oznacza to, że klient VPN staje się nośnikiem ukrytej funkcji zdalnego wykonywania poleceń. Użytkownik uruchamia aplikację sieciową, ale w tle dochodzi do realizacji kodu kontrolowanego przez atakującego. To szczególnie niebezpieczne w środowiskach technicznych, gdzie praca z konfiguracjami VPN i podwyższonymi uprawnieniami jest czymś normalnym.

W systemach Windows obserwowano dodatkowo wykorzystanie PowerShell do utworzenia zaplanowanego zadania odpowiedzialnego za pobranie kolejnego ładunku. W środowiskach Linux wykorzystywano polecenie curl do pobrania pliku wykonywalnego z infrastruktury przeciwnika przez tunel VPN. Publicznie nie ujawniono pełnej funkcji drugiego etapu, jednak sposób wdrożenia wskazuje na próbę utrwalenia dostępu i dalszej eksploatacji przejętego hosta.

Zmodyfikowany klient bazował na WireGuard.
Złośliwa logika była ukryta w niestandardowej konfiguracji.
Do uruchomienia ładunku wykorzystywano PowerShell lub narzędzia systemowe Linux.
Atak zakładał pobranie kolejnego etapu malware z zewnętrznej infrastruktury.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią jest wysokie, ponieważ jej cele stanowią osoby posiadające zaawansowane uprawnienia, wiedzę administracyjną oraz dostęp do wrażliwych zasobów. Uruchomienie trojanizowanego klienta VPN może prowadzić do wykonania dowolnych poleceń, pobrania dodatkowego malware i uzyskania trwałego dostępu do systemu.

Dla organizacji oznacza to potencjalną eskalację uprawnień wewnątrz domeny, środowiska chmurowego lub infrastruktury produkcyjnej. Dodatkowym problemem jest fakt, że komunikacja związana z rekrutacją często odbywa się poza standardowymi kanałami firmowymi, co utrudnia wykrycie incydentu. Obecność wariantów dla Windows i Linux pokazuje również, że operatorzy są przygotowani do działania w zróżnicowanych środowiskach roboczych.

Co istotne, atak nie wymaga wykorzystania klasycznej luki bezpieczeństwa. Wystarczy przekonanie użytkownika do uruchomienia programu, który wygląda jak element legalnej procedury rekrutacyjnej. Nawet dobrze załatane systemy mogą więc zostać naruszone, jeśli zabraknie kontroli nad źródłami oprogramowania i zasadami korzystania z urządzeń uprzywilejowanych.

Rekomendacje

Organizacje powinny wyraźnie rozdzielić środowiska administracyjne od codziennych aktywności użytkowników i zabronić instalowania niezweryfikowanego oprogramowania na stacjach używanych do pracy uprzywilejowanej. Szczególną uwagę należy zwrócić na procesy rekrutacyjne, zadania techniczne oraz wszelkie prośby o korzystanie z zewnętrznych narzędzi dostępowych.

Wdrożyć kontrolę aplikacji i blokować nieautoryzowane klienty VPN oraz narzędzia sieciowe.
Monitorować tworzenie zaplanowanych zadań, uruchomienia PowerShell i nietypowe procesy potomne klientów VPN.
Wykrywać anomalie w plikach konfiguracyjnych WireGuard, w tym obecność niestandardowych parametrów.
Ograniczyć pobieranie binariów z niezatwierdzonych repozytoriów i usług hostingu plików.
Egzekwować zasadę korzystania z zasobów firmowych wyłącznie z urządzeń zarządzanych.
Szkolić personel techniczny z rozpoznawania wieloetapowej socjotechniki podszywającej się pod rekrutację.
Segmentować środowiska administracyjne i oddzielać je od aktywności codziennej.

Zespoły SOC i DFIR powinny analizować korelacje między kontaktem rekrutacyjnym, uruchomieniem klienta VPN, aktywnością PowerShell oraz połączeniami do zewnętrznych serwerów pobierających payload. W środowiskach Linux analogicznej uwagi wymagają procesy curl, nowe pliki wykonywalne w katalogach tymczasowych oraz nietypowe połączenia inicjowane po ustanowieniu tunelu.

Podsumowanie

Kampania UAC-0145 pokazuje, jak skutecznie przeciwnicy potrafią połączyć socjotechnikę z nadużyciem zaufania do legalnych narzędzi. Wykorzystanie rozmowy kwalifikacyjnej jako pretekstu do instalacji trojanizowanego klienta VPN to przykład operacji dopasowanej do profilu zawodowego ofiary i jej codziennych nawyków.

Najważniejszy wniosek dla organizacji jest prosty: nawet doświadczeni specjaliści IT mogą paść ofiarą starannie przygotowanego scenariusza. Skuteczna obrona wymaga jednocześnie kontroli technicznej, separacji środowisk uprzywilejowanych oraz większej ostrożności wobec procesów biznesowych, które dotąd rzadko były postrzegane jako istotny wektor ataku.

Źródła

The Hacker News — Sandworm-Linked UAC-0145 Uses Fake Job Interviews to Push VPN That Can Run Commands

Cisco ostrzega przed aktywnie wykorzystywaną luką DoS w ASA i FTD VPN

Wprowadzenie do problemu / definicja

Cisco opublikowało ostrzeżenie dotyczące podatności CVE-2026-20349, która wpływa na Cisco Secure Firewall ASA oraz Cisco Secure Firewall Threat Defense. Luka umożliwia zdalnemu, nieuwierzytelnionemu atakującemu doprowadzenie do nieoczekiwanego restartu urządzenia, a w efekcie do odmowy usługi.

Problem dotyczy komponentów odpowiedzialnych za zdalny dostęp przez SSL VPN, dlatego szczególnie istotny jest dla organizacji, które wystawiają usługi VPN do Internetu i opierają na nich pracę zdalną lub dostęp administracyjny.

W skrócie

Podatność: CVE-2026-20349
Typ zagrożenia: denial of service
Wpływ: zdalny restart urządzenia i utrata dostępności usług
Wektor ataku: specjalnie przygotowane żądania HTTP do usługi Remote Access SSL VPN
Wymagania: brak uwierzytelnienia i brak interakcji użytkownika
Status: aktywnie wykorzystywana w atakach
Mitigacja: aktualizacja, bez skutecznych obejść producenta

Kontekst / historia

Ostrzeżenie zostało opublikowane 11 sierpnia 2026 roku po tym, jak zespół PSIRT firmy Cisco potwierdził aktywne próby wykorzystania podatności. Błąd został wykryty podczas wewnętrznych testów bezpieczeństwa, a niezależnie zgłosił go również badacz Valerio Brussani.

Znaczenie tej luki wynika z roli, jaką urządzenia ASA i FTD pełnią w infrastrukturze przedsiębiorstw. Często zabezpieczają one ruch brzegowy, segmentację sieci oraz zdalny dostęp użytkowników, administratorów i partnerów. Każde zakłócenie ich działania może więc bezpośrednio przełożyć się na ciągłość operacyjną organizacji.

Analiza techniczna

Mechanizm podatności opiera się na niewystarczającej walidacji podczas przetwarzania żądań HTTP kierowanych do usługi Remote Access SSL VPN. Napastnik może wysłać odpowiednio spreparowane żądanie do podatnego urządzenia, powodując przeładowanie systemu i stan odmowy usługi.

Kluczowe jest to, że atak nie wymaga wcześniejszego logowania ani posiadania poświadczeń. W praktyce oznacza to, że publicznie dostępne usługi VPN stają się bezpośrednią powierzchnią ataku, jeśli na urządzeniu aktywne są odpowiednie mechanizmy nasłuchu SSL.

Według informacji producenta zagrożone mogą być konfiguracje wykorzystujące:

IKEv2 Remote Access VPN z usługami klienckimi,
SSL VPN,
Zero Trust Network Access w środowiskach FTD.

Cisco wskazało jednocześnie, że Secure Firewall Management Center nie jest podatne. Poprawki udostępniono dla wybranych wersji ASA 9.16, 9.18, 9.20, 9.22, 9.23 i 9.24 oraz dla FTD 7.0, 7.2, 7.4, 7.6, 7.7 i 10.0. Sama obecność urządzenia tej klasy w sieci nie oznacza jeszcze ekspozycji, dlatego konieczna jest weryfikacja zarówno wersji systemu, jak i aktywnych funkcji VPN.

Choć skutkiem wykorzystania luki nie jest bezpośrednie przejęcie kontroli nad urządzeniem, wpływ operacyjny może być poważny. Restart zapory lub platformy dostępu zdalnego może odciąć użytkowników od usług, przerwać sesje administracyjne i utrudnić utrzymanie stabilności środowiska.

Konsekwencje / ryzyko

Najbardziej oczywistą konsekwencją jest utrata dostępności. W środowiskach korzystających z VPN oznacza to możliwość odcięcia pracowników zdalnych, administratorów albo połączeń między oddziałami i systemami.

Ryzyko jest szczególnie wysokie w organizacjach, które publikują usługi SSL VPN bezpośrednio do Internetu, nie posiadają wysokiej dostępności dla urządzeń brzegowych, utrzymują starsze wersje oprogramowania lub opierają krytyczne procesy na nieprzerwanym dostępie zdalnym.

Fakt aktywnej eksploatacji oznacza, że zagrożenie nie ma wyłącznie charakteru teoretycznego. Nawet jeśli luka nie prowadzi do wykonania kodu, możliwość wymuszania restartów może zostać użyta do destabilizacji środowiska, zakłócania operacji SOC i NOC oraz wywoływania powtarzalnych przerw w łączności.

Rekomendacje

Najważniejszym działaniem jest możliwie szybkie wdrożenie poprawek udostępnionych przez Cisco. Producent nie wskazał skutecznych obejść, które eliminowałyby problem bez aktualizacji, dlatego odkładanie działań zwiększa ryzyko utrzymania podatnej powierzchni ataku.

Przeprowadzić inwentaryzację wszystkich instancji Cisco ASA i FTD udostępniających zdalny dostęp.
Potwierdzić, czy aktywne są funkcje IKEv2 Remote Access VPN, SSL VPN lub ZTNA.
Porównać używane wersje z listą wydań naprawionych przez producenta.
Zaplanować wdrożenie aktualizacji w kontrolowanym oknie serwisowym.
Sprawdzić logi i telemetrię pod kątem nagłych restartów oraz nietypowych żądań HTTP do usług VPN.
Zweryfikować konfiguracje wysokiej dostępności i mechanizmy failover.
Ograniczyć ekspozycję usług zdalnych do niezbędnych interfejsów i adresów, jeśli architektura na to pozwala.

Zespoły SOC i NOC powinny dodatkowo przygotować reguły detekcyjne dla anomalii związanych z usługami Remote Access SSL VPN oraz korelować incydenty dostępności z ruchem przychodzącym do urządzeń brzegowych. Warto również przetestować procedury awaryjnego przełączenia i odtworzenia dostępu zdalnego.

Podsumowanie

CVE-2026-20349 to istotna podatność DoS w rozwiązaniach Cisco ASA i FTD, uderzająca w warstwę zdalnego dostępu i już wykorzystywana w rzeczywistych atakach. Ponieważ exploitacja nie wymaga uwierzytelnienia, a skutkiem może być restart urządzenia obsługującego VPN, organizacje powinny potraktować sprawę priorytetowo.

Dla firm korzystających z podatnych wersji ASA lub FTD kluczowe jest szybkie potwierdzenie ekspozycji i wdrożenie poprawek. W tym przypadku aktualizacja nie jest jedynie działaniem prewencyjnym, lecz bezpośrednią odpowiedzią na aktywne zagrożenie.

Źródła

Cisco warns of ASA and FTD VPN flaw exploited to crash devices — https://www.bleepingcomputer.com/news/security/cisco-warns-of-asa-and-ftd-vpn-flaw-exploited-to-crash-devices/
Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Denial of Service Vulnerability — https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-dzv4mQFF
CVE-2026-20349 — https://www.cve.org/CVERecord?id=CVE-2026-20349