Archiwa: PowerShell - Security Bez Tabu

Adopcja AI w firmach obciąża SOC: więcej alertów, więcej szumu i nowe ryzyka operacyjne

Wprowadzenie do problemu / definicja

Masowe wdrażanie narzędzi sztucznej inteligencji w przedsiębiorstwach zaczyna wyraźnie wpływać na codzienną pracę centrów operacji bezpieczeństwa. Kluczowym wyzwaniem nie są dziś wyłącznie bezpośrednie ataki na modele czy agentów AI, lecz rosnąca liczba legalnych działań wykonywanych przez asystentów kodowania, aplikacje generatywne i integracje zewnętrzne, które z perspektywy systemów bezpieczeństwa wyglądają jak wczesna faza incydentu.

W praktyce oznacza to, że SOC musi coraz częściej odróżniać realne zagrożenia od normalnej aktywności generowanej przez narzędzia AI. To przesuwa ciężar pracy z klasycznego wykrywania malware na analizę kontekstu operacyjnego i zachowań użytkowników oraz agentów.

W skrócie

Nowa fala adopcji AI powoduje szybki wzrost alertów powiązanych z aktywnością agentów, choć nadal stanowią one niewielką część całego wolumenu zdarzeń. Problem polega na tym, że zdecydowana większość takich alarmów nie wskazuje na rzeczywisty incydent, lecz na legalne, choć nietypowe działania wykonywane przez oprogramowanie wspierane przez AI.

alerty związane z AI rosną szybciej niż wiele tradycyjnych kategorii detekcji,
większość z nich to fałszywe alarmy lub nieszkodliwa aktywność,
realne ryzyka dotyczą głównie uprawnień, dostępu do danych, tuneli wychodzących i zgód OAuth,
największym kosztem staje się triage oraz konieczność przebudowy reguł detekcyjnych.

Kontekst / historia

W ostatnich miesiącach wykorzystanie AI przestało być domeną wyłącznie zespołów technicznych. Z narzędzi generatywnych korzystają dziś deweloperzy, analitycy, działy biznesowe i użytkownicy aplikacji SaaS. Oznacza to, że nowe źródła aktywności pojawiają się jednocześnie na stacjach roboczych, w chmurze, w systemach tożsamości oraz w obiegu danych.

Historycznie większość reguł EDR i SOC była projektowana pod klasyczne techniki ataku, takie jak eskalacja uprawnień, pobieranie narzędzi z internetu, tworzenie tuneli czy odczyt poświadczeń. Tymczasem współczesny agent AI może wykonywać podobne operacje w pełni legalnie, na przykład analizując repozytorium, instalując zależności, uruchamiając skrypty lub uzyskując dostęp do tokenów potrzebnych do integracji. To prowadzi do sytuacji, w której stare wzorce detekcji coraz częściej błędnie opisują nową normalność organizacyjną.

Analiza techniczna

Analizowany materiał wskazuje, że spośród około 16,9 mln alertów SOC około 73 tys. sklasyfikowano jako zdarzenia związane z AI. To mniej niż jeden procent całości, ale jednocześnie segment o bardzo wysokiej dynamice wzrostu. W okresie od lutego do czerwca 2026 r. liczba takich alertów wzrosła o 685%, co pokazuje, że problem dopiero się rozpędza.

Technicznie zdarzenia te można podzielić na trzy główne kategorie. Pierwsza obejmuje rzeczywiste ataki, których udział pozostaje niewielki. Nie chodzi głównie o przejęcie firmowego agenta AI, lecz raczej o kampanie wykorzystujące popularność narzędzi AI jako element socjotechniki, przynęty phishingowej lub kanału dostępu do użytkownika.

Druga kategoria to ryzykowne, ale legalne użycie AI. Dotyczy to sytuacji, w których agent działa z nadmiernymi uprawnieniami, z wyłączonym mechanizmem potwierdzania poleceń albo bez odpowiedniej izolacji środowiska. Taki model pracy zwiększa prawdopodobieństwo niekontrolowanego wykonania kodu, odczytu sekretów, modyfikacji konfiguracji lub otwarcia połączeń na zewnątrz organizacji.

Materiał przywołuje przykłady zachowań, które z punktu widzenia telemetryki bezpieczeństwa wyglądają wyjątkowo groźnie. W jednym przypadku agent uruchomił PowerShell i zestawił tunel zwrotny do internetu z wykorzystaniem ngrok oraz tokena użytkownika. W innym odczytano cały macOS Keychain do pliku tymczasowego tylko po to, by pobrać pojedynczy sekret. Formalnie były to działania wykonane przez legalne narzędzia, lecz ich ślad forensyczny przypominał aktywność ofensywną.

Trzecia kategoria to czysty szum operacyjny, który odpowiada za zdecydowaną większość alertów związanych z AI. W tej grupie mieszczą się detekcje uruchamiane przez instalatory aplikacji, podpisane binaria czy procesy tworzone przez narzędzia CLI i edytory wspierane przez AI. W efekcie reguły kojarzone dotąd z ransomware, reverse shellem, iniekcją DLL lub post-exploitation zaczynają aktywować się podczas całkowicie normalnej pracy użytkownika.

Konsekwencje / ryzyko

Najbardziej odczuwalnym skutkiem jest przeciążenie zespołów SOC. Jeżeli każda nietypowa akcja agenta AI jest traktowana jak potencjalna kompromitacja hosta, rośnie liczba eskalacji, spada jakość analizy i zwiększa się zmęczenie alertami. W takim środowisku prawdziwe incydenty mogą zostać przeoczone lub zbyt późno zakwalifikowane jako istotne.

Drugie ryzyko dotyczy błędnej priorytetyzacji. Wysoki poziom severity nie zawsze będzie oznaczał realny atak, ponieważ część reguł nadal nie uwzględnia kontekstu legalnej pracy agentów AI. To osłabia wartość tradycyjnych mechanizmów scoringu i może prowadzić do niewłaściwego wykorzystania zasobów analitycznych.

Istotnym zagrożeniem pozostaje także ekspozycja danych i tożsamości. Nadmierne zgody OAuth, przekazywanie plików do zewnętrznych modeli, uruchamianie agentów bez ograniczeń oraz brak kontroli nad obiegiem sekretów zwiększają ryzyko wycieku informacji, nadużycia uprawnień i skutecznego wykorzystania prompt injection. Dodatkowo pojawia się komponent łańcucha dostaw, szczególnie gdy agent wykonuje instrukcje bazujące na zewnętrznym kodzie lub niezweryfikowanych źródłach.

Rekomendacje

Organizacje powinny dostosować swoje mechanizmy detekcji do realiów powszechnej adopcji AI. Nie chodzi o wyłączanie alertów, ale o budowanie kontekstu, który pozwoli odróżnić legalne użycie agentów od działań faktycznie złośliwych.

dostroić najbardziej hałaśliwe reguły EDR i SOC związane z reverse shellem, ransomware, credential access i lateral movement,
wprowadzić polityki użycia AI obejmujące zgody OAuth, klasyfikację danych i dozwolone integracje,
zakazać uruchamiania agentów w trybach omijających potwierdzanie działań bez dodatkowych zabezpieczeń,
izolować agentów AI w kontenerach lub maszynach wirtualnych o ograniczonych uprawnieniach,
monitorować tworzenie tuneli wychodzących, masowe odczyty magazynów sekretów i nietypowe transfery do usług generatywnych,
rozdzielić tożsamość użytkownika od tożsamości agenta, aby ustalić, które działania były inicjowane świadomie, a które autonomicznie.

W środowiskach deweloperskich szczególnie ważne jest ograniczenie dostępu agentów do lokalnych poświadczeń, kluczy SSH, pamięci procesów oraz zasobów użytkownika. Taki model nie tylko redukuje ryzyko, ale też poprawia widoczność i korelację zdarzeń w systemach monitoringu.

Podsumowanie

Adopcja AI w przedsiębiorstwach nie doprowadziła jeszcze do masowej fali potwierdzonych włamań realizowanych bezpośrednio przez firmowych agentów. Spowodowała jednak gwałtowny wzrost nowego rodzaju alertów, z których zdecydowana większość stanowi szum operacyjny utrudniający codzienną pracę SOC.

Największe wyzwanie polega dziś na tym, by nauczyć systemy bezpieczeństwa rozumienia normalnej aktywności agentów AI. Bez tej zmiany organizacje będą ponosić coraz wyższy koszt triage’u, a realne zagrożenia związane z uprawnieniami, sekretami, tunelowaniem ruchu i przepływem danych do usług zewnętrznych pozostaną niedoszacowane.

Źródła

When the Whole Company Adopts AI: What It Does to Your SOC

Atak na PaperCut NG/MF z użyciem setek agentów AI doprowadził do przejęcia ponad 440 instancji

Wprowadzenie do problemu / definicja

Kampanie wykorzystujące sztuczną inteligencję w ofensywnych operacjach cybernetycznych wchodzą w nową fazę. Najnowszy przypadek związany z platformą PaperCut NG/MF pokazuje, że AI nie musi tworzyć przełomowego exploita, aby istotnie zwiększyć skuteczność ataku. Wystarczy, że przyspieszy badanie podatności, automatyzację walidacji celów, analizę niepowodzeń i kolejne iteracje narzędzi. W praktyce oznacza to skrócenie czasu od ujawnienia podatności do masowej eksploatacji oraz obniżenie progu wejścia dla zaawansowanych operacji.

W skrócie

Badacze bezpieczeństwa opisali kampanię wymierzoną w PaperCut NG/MF, w której napastnik miał wykorzystywać setki agentów AI do automatyzacji kolejnych etapów ataku. Operacja była oparta na łańcuchu obejmującym obejście uwierzytelnienia i zdalne wykonanie kodu. Według dostępnych ustaleń atakujący uzyskał dostęp do ponad 440 instancji należących do 395 organizacji w 48 krajach. Szczególnie istotny jest nie sam fakt eksploatacji podatności, lecz tempo działania: od prac badawczych nad podatnością do skutecznego użycia przeciw realnym ofiarom miały upłynąć zaledwie godziny.

Kontekst / historia

PaperCut NG i PaperCut MF to szeroko stosowane rozwiązania do zarządzania drukiem, obecne m.in. w środowiskach edukacyjnych, administracyjnych i korporacyjnych. Tego typu systemy bywają wystawiane do internetu lub dostępne z sieci zewnętrznych, co czyni je atrakcyjnym celem dla operatorów poszukujących szybkiego wejścia do infrastruktury ofiary.

W opisywanej kampanii kluczowe znaczenie miały dwie niedawno ujawnione podatności oznaczone jako CVE-2026-81578 oraz CVE-2026-82078. Ich połączenie umożliwiało utworzenie praktycznego łańcucha ataku prowadzącego od obejścia mechanizmów uwierzytelnienia do wykonania kodu na systemie docelowym. Z dostępnych analiz wynika, że aktywność była obserwowana przede wszystkim przeciw organizacjom z sektora edukacyjnego, zwłaszcza w Stanach Zjednoczonych, Wielkiej Brytanii, Francji, Hiszpanii, Kanadzie i innych krajach zachodnich.

Dodatkowy kontekst stanowi obserwacja infrastruktury operatora. Jeden z adresów IP przypisywanych kampanii był wcześniej łączony z rekonesansem, skanowaniem portów oraz próbami brute force wobec różnych technologii wystawionych do internetu. To sugeruje, że atak na PaperCut mógł być częścią szerszej działalności nastawionej na pozyskiwanie dostępu początkowego.

Analiza techniczna

Technicznie kampania wyróżnia się nie tyle oryginalnością samego łańcucha podatności, ile sposobem jego operacyjnego wykorzystania. Zamiast ręcznie prowadzić badanie wersji oprogramowania, budowę exploita, testy i selekcję celów, atakujący miał zautomatyzować cały przepływ pracy z pomocą agentów AI oraz publicznie dostępnych narzędzi ofensywnych.

Według opublikowanych ustaleń proces obejmował kilka etapów. Najpierw operator analizował różnice między poprawionymi i podatnymi wersjami PaperCut, aby szybko zidentyfikować warunki skutecznej eksploatacji. Następnie przygotowano wielowątkowe narzędzie do walidacji celów, które było rozwijane iteracyjnie na podstawie wyników kolejnych prób. Taka pętla sprzężenia zwrotnego miała pozwalać na ciągłe poprawianie skuteczności ataku bez konieczności pełnego, ręcznego nadzoru.

Równolegle budowano listy potencjalnych ofiar przy użyciu źródeł danych o systemach dostępnych z internetu. Kolejne skrypty geolokalizowały cele, filtrowały je według państw oraz identyfikowały instancje PaperCut gotowe do następnego etapu. Po uzyskaniu wykonania kodu operator prowadził działania post-exploitation: rozpoznanie hosta, enumerację użytkowników i procesów, pobieranie wrażliwych danych konfiguracyjnych oraz próby kradzieży poświadczeń.

W analizach wskazano również użycie znanych narzędzi takich jak Mimikatz, SharpHound, Certipy, Rubeus czy Impacket. To zestaw typowy dla operacji ukierunkowanych na eskalację uprawnień, rozpoznanie środowiska Active Directory, nadużycia Kerberos i dalszy ruch boczny. W części przypadków celem było uzyskanie uprawnień administracyjnych w domenie. Szczególnie niepokojące jest to, że automatyzacja obejmowała także klasyfikację błędów, ponawianie nieudanych prób oraz śledzenie stanu poszczególnych zadań, co znacząco podnosi odporność całej kampanii na zakłócenia.

Z perspektywy obrońcy najważniejszy wniosek jest następujący: AI została tu użyta jako warstwa orkiestracji i optymalizacji. Nie zastąpiła klasycznych technik ofensywnych, ale przyspieszyła ich wdrożenie i skalowanie. Dzięki temu czas od identyfikacji podatności do realnych kompromitacji został drastycznie skrócony.

Konsekwencje / ryzyko

Największe ryzyko wynika z ekonomii ataku. Jeżeli operator może zautomatyzować badanie podatności, walidację celów, exploitację i elementy post-exploitation, to ta sama kampania może objąć setki organizacji przy relatywnie mniejszym nakładzie pracy. To oznacza większą liczbę ofiar, krótszy czas reakcji dla zespołów bezpieczeństwa i większą presję na szybkie wdrażanie poprawek.

W środowiskach edukacyjnych, które według analiz były szczególnie często atakowane, kompromitacja PaperCut może prowadzić do przejęcia serwerów, kradzieży poświadczeń, rozpoznania domeny oraz dalszego ruchu bocznego. Jeżeli system jest zintegrowany z usługami katalogowymi lub ma szerokie uprawnienia w sieci, może stać się wygodnym punktem wejścia do głębszej kompromitacji infrastruktury.

Dodatkowym zagrożeniem pozostaje niejasny cel końcowy operatora. Tego typu dostęp może zostać wykorzystany bezpośrednio do kradzieży danych, wdrożenia ransomware albo sprzedany innym grupom jako dostęp początkowy. Nawet jeśli w części przypadków nie doszło do finalnego etapu ataku, samo uzyskanie uprawnień administracyjnych w domenie należy traktować jako incydent o bardzo wysokiej krytyczności.

Rekomendacje

Organizacje korzystające z PaperCut NG/MF powinny w pierwszej kolejności niezwłocznie zweryfikować wersje oprogramowania i wdrożyć poprawki bezpieczeństwa odnoszące się do CVE-2026-81578 oraz CVE-2026-82078. Jeżeli aktualizacja nie może zostać wykonana natychmiast, należy wdrożyć działania ograniczające ekspozycję, w tym usunięcie interfejsów administracyjnych z internetu i ograniczenie dostępu do zaufanych segmentów sieci lub przez VPN.

Warto przeprowadzić aktywne polowanie na oznaki kompromitacji. Szczególną uwagę należy zwrócić na:

nietypowe logowania do PaperCut,
uruchamianie procesów potomnych przez usługę aplikacji,
ślady użycia narzędzi do zrzutu poświadczeń i enumeracji Active Directory,
nietypowy ruch wychodzący z serwera PaperCut,
tworzenie nowych kont, modyfikacje grup uprzywilejowanych i zmiany w politykach domenowych.

W środowiskach Windows należy przeanalizować logi bezpieczeństwa, zdarzenia PowerShell, Sysmon oraz artefakty EDR pod kątem technik credential dumping, Kerberoastingu, LDAP enumeration i lateral movement. Dobrą praktyką jest również rotacja poświadczeń administracyjnych, zwłaszcza jeśli istnieje podejrzenie, że serwer aplikacyjny miał kontakt z domeną lub przechowywał wrażliwe dane uwierzytelniające.

Od strony architektury bezpieczeństwa rekomendowane są:

segmentacja sieci i separacja serwerów zarządzania drukiem od krytycznych zasobów,
zasada najmniejszych uprawnień dla kont serwisowych,
MFA dla dostępu administracyjnego tam, gdzie jest możliwe,
ograniczenie zaufania między systemami aplikacyjnymi a kontrolerami domeny,
monitoring ekspozycji usług internet-facing,
szybki proces patch management dla systemów peryferyjnych, które bywają pomijane w priorytetyzacji.

Na poziomie strategicznym organizacje powinny założyć, że przyszłe kampanie będą jeszcze szybciej adaptować się do błędów konfiguracji, zmian w obronie i publikowanych poprawek. Oznacza to potrzebę skrócenia czasu od publikacji informacji o podatności do oceny ryzyka, testów i wdrożenia remediacji.

Podsumowanie

Incydent związany z PaperCut NG/MF pokazuje, że ofensywne wykorzystanie AI dojrzewa operacyjnie. Przełomem nie jest tu nowa klasa exploita, lecz zdolność do automatyzacji całego cyklu ataku: od analizy podatności, przez selekcję celów, po iteracyjne poprawianie skuteczności działań po kompromitacji. Dla zespołów bezpieczeństwa to wyraźny sygnał, że tradycyjnie wolniejsze etapy pracy napastnika mogą dziś zostać skrócone do godzin lub minut. W praktyce wygrywać będą te organizacje, które potrafią szybko identyfikować ekspozycję, priorytetyzować poprawki i aktywnie wykrywać wczesne oznaki nadużyć.

Źródła

https://thehackernews.com/2026/09/papercut-attacker-uses-hundreds-of-ai.html
https://thehackernews.com/2026/09/attackers-exploit-papercut-flaws-to.html
https://blackpointcyber.com/
https://www.greynoise.io/
https://www.papercut.com/

Kampanie ClickFix nadużywają legalnych usług do utrzymania trwałego dostępu

Wprowadzenie do problemu / definicja

ClickFix to technika socjotechniczna, w której atakujący nakłaniają ofiarę do samodzielnego wykonania złośliwej akcji, najczęściej przez skopiowanie i uruchomienie polecenia lub wklejenie kodu w przeglądarce. Najnowsze kampanie pokazują jednak, że ten model ataku wyraźnie ewoluuje i coraz częściej łączy manipulację użytkownikiem z nadużyciem legalnych usług oraz zaufanych komponentów.

W praktyce oznacza to, że cyberprzestępcy nie muszą już polegać wyłącznie na klasycznych downloaderach czy prostych stealerach. Zamiast tego wykorzystują przeglądarkę, rozszerzenia, usługi chmurowe oraz publicznie dostępne mechanizmy komunikacji do utrzymania trwałości, ukrycia aktywności i dalszego rozwijania kompromitacji w środowisku ofiary.

W skrócie

Dwie niedawno opisane kampanie oparte na ClickFix i ClearFake pokazują rosnącą dojrzałość tego typu operacji.
W jednym scenariuszu atak koncentrował się na przejęciu sesji przeglądarki i kradzieży kryptowalut z użyciem złośliwego kodu oraz rozszerzenia Tampermonkey.
W drugim przypadku ofiary były nakłaniane do uruchomienia polecenia pobierającego złośliwą bibliotekę DLL przez WebDAV.
Łańcuch infekcji prowadził do instalacji infostealera, reverse proxy oraz narzędzia zdalnego dostępu.
Wspólnym mianownikiem obu kampanii jest wykorzystywanie legalnych usług i zaufanej infrastruktury do utrudnienia wykrycia.

Kontekst / historia

ClickFix stał się w ostatnich latach jedną z bardziej skutecznych metod uzyskiwania początkowego dostępu. Zamiast opierać się wyłącznie na exploitach, operatorzy przenoszą część łańcucha infekcji na użytkownika, który sam wykonuje działania omijające standardowe zabezpieczenia. To podejście dobrze wpisuje się w obecny krajobraz zagrożeń, w którym filtrowanie poczty, sandboxing i systemy EDR utrudniają klasyczne dostarczenie malware.

Opisana kampania wymierzona w przeglądarkę miała rozpocząć się już w październiku 2025 roku, a do marca 2026 roku rozwinęła się w kierunku kompromitacji komponentów opartych na usługach Google. Z kolei drugi łańcuch ataku został powiązany z analizą incydentu z kwietnia 2026 roku, gdy badacze wykryli podejrzaną bibliotekę DLL uruchamianą z wykorzystaniem WebDAV. Ustalenia wskazują, że nie był to odosobniony incydent, lecz element szerszej operacji ukierunkowanej na kradzież kryptowalut i poświadczeń.

Analiza techniczna

Pierwsza kampania odchodzi od klasycznego scenariusza ClickFix, w którym użytkownik uruchamia komendę PowerShell lub skrypt systemowy. W tym wariancie ofiara była nakłaniana do wklejenia złośliwego fragmentu kodu bezpośrednio do sesji przeglądarki Chrome. W bardziej rozwiniętej odsłonie operatorzy skupili się na użyciu legalnego rozszerzenia Tampermonkey, które pozwala załadować skrypt i zapewnić trwałość w obrębie odwiedzanej witryny oraz kolejnych sesji przeglądarki.

Kluczowym elementem tej operacji było wykorzystanie zaufanej infrastruktury. Złośliwe skrypty dostarczano z dokumentów i arkuszy hostowanych w usługach Google, między innymi z użyciem Google Visualization API oraz Google Sheets. Dzięki temu ruch związany z kampanią mógł wyglądać jak zwykła komunikacja z legalnymi usługami chmurowymi, co znacząco utrudnia wykrywanie oparte na reputacji domen czy prostych regułach sieciowych.

Druga kampania wykorzystywała wariant ClearFake. Ofiara trafiała na przejętą stronę internetową, gdzie prezentowano fałszywy mechanizm CAPTCHA stylizowany na usługę Google. Interfejs instruował użytkownika, aby wkleił i uruchomił polecenie w oknie Uruchamianie systemu Windows. Efektem było pobranie zamaskowanej biblioteki DLL przez WebDAV, a następnie uruchomienie ładunku Amatera.

Amatera pełnił rolę infostealera zdolnego do pozyskiwania danych związanych z kryptowalutami, poświadczeń, informacji z przeglądarek oraz wrażliwych plików. W zależności od przebiegu infekcji możliwe było także wdrożenie modułu kradzieży kryptowalut, reverse proxy lub instalacja NetSupport Manager, co zapewniało napastnikom nieautoryzowany zdalny dostęp do systemu. Taki zestaw funkcji sugeruje, że celem nie była wyłącznie szybka monetyzacja, ale również utrzymanie pozycji w środowisku i możliwość dalszego wykorzystania kompromitacji.

Technicznie istotne jest to, że obie kampanie przesuwają aktywność do obszarów często słabiej monitorowanych kontekstowo, takich jak sesje przeglądarki, rozszerzenia, legalne usługi SaaS, publiczne endpointy oraz dopuszczone komponenty. W praktyce sprawia to, że tradycyjne mechanizmy bezpieczeństwa skoncentrowane na blokowaniu złośliwych plików i domen mogą nie zareagować wystarczająco wcześnie.

Konsekwencje / ryzyko

Najważniejszym ryzykiem jest obejście klasycznego modelu ochrony endpointów poprzez zaangażowanie użytkownika w łańcuch infekcji. Jeżeli pracownik sam wkleja kod do przeglądarki, uruchamia polecenie w oknie systemowym lub instaluje pozornie nieszkodliwy komponent, część zabezpieczeń może uznać taką aktywność za działanie autoryzowane.

W środowisku korporacyjnym skutki mogą być wielowymiarowe. Na poziomie użytkownika oznacza to utratę poświadczeń, danych przeglądarki, tokenów sesyjnych i informacji finansowych. Na poziomie organizacji może prowadzić do trwałej obecności napastnika, tunelowania ruchu przez reverse proxy, dalszego przemieszczania się po sieci oraz przygotowania gruntu pod kolejne etapy ataku, w tym działania brokerskie lub ransomware. Dodatkowym problemem jest nadużycie legalnych usług chmurowych, przez co ruch generowany przez malware miesza się z normalną aktywnością biznesową.

Rekomendacje

Organizacje powinny traktować przeglądarkę jako zarządzane środowisko wykonawcze, a nie wyłącznie narzędzie do przeglądania stron WWW. W praktyce oznacza to ograniczenie możliwości instalowania rozszerzeń, kontrolę użycia narzędzi developerskich oraz wdrożenie polityk dostępu opartych na rolach użytkowników.

Zablokować lub ściśle nadzorować możliwość instalacji i używania rozszerzeń takich jak menedżery skryptów.
Monitorować nietypowe użycie WebDAV, uruchamianie bibliotek DLL z lokalizacji sieciowych oraz procesy inicjowane przez ręcznie wklejane polecenia.
Rozszerzyć telemetrię o aktywność w przeglądarkach, w tym manipulacje sesją, nietypowe skrypty użytkownika i zmiany w konfiguracji rozszerzeń.
Wdrożyć reguły detekcyjne dla fałszywych CAPTCHA i wzorców ClickFix, zwłaszcza komunikatów nakazujących wklejenie kodu do paska adresu, terminala, PowerShell lub okna Uruchamianie.
Aktualizować listy IoC oraz korelować je z ruchem do zaufanych usług chmurowych, ponieważ sama reputacja domeny nie jest już wystarczającym wskaźnikiem bezpieczeństwa.
Szkolić użytkowników, że legalny proces weryfikacji, wsparcia technicznego czy zgłoszenia błędu nie wymaga ręcznego wklejania kodu do przeglądarki ani uruchamiania poleceń systemowych.

Z perspektywy zespołów SOC i blue team szczególnie ważne staje się budowanie detekcji behawioralnej. W przypadku takich kampanii większą wartość niż pojedynczy wskaźnik kompromitacji mają sekwencje działań, takie jak otwarcie podejrzanej strony, ręczne wykonanie polecenia, uruchomienie biblioteki z udziałem WebDAV, instalacja nietypowego narzędzia zdalnego dostępu oraz komunikacja z usługami chmurowymi w niestandardowym kontekście.

Podsumowanie

Nowe kampanie ClickFix potwierdzają, że socjotechnika pozostaje jednym z najskuteczniejszych wektorów ataku, a jej połączenie z legalnymi usługami znacząco zwiększa skuteczność i utrudnia wykrycie. Atakujący nie tylko kradną dane i kryptowaluty, ale coraz częściej dążą do trwałości, zdalnej kontroli oraz głębszej kompromitacji środowiska.

Dla obrońców oznacza to konieczność przesunięcia uwagi z prostego blokowania znanych artefaktów na kontrolę zachowań użytkownika, zarządzanie przeglądarką i analizę nadużyć zaufanej infrastruktury. To właśnie te obszary będą miały kluczowe znaczenie w wykrywaniu kolejnych generacji kampanii ClickFix.

Źródła

https://www.darkreading.com/endpoint-security/clickfix-campaigns-legitimate-services-persistent-access
https://blog.talosintelligence.com/
https://blog.talosintelligence.com/
https://blog.talosintelligence.com/
https://www.netsupportsoftware.com/product/netsupport-manager/

PEEP zamienia Chrome i Edge w tylne wejście po kompromitacji systemu

Wprowadzenie do problemu / definicja

PEEP to zaawansowany framework post-exploitation zaprojektowany z myślą o przeglądarkach opartych na Chromium, przede wszystkim Google Chrome i Microsoft Edge. Jego zadaniem nie jest uzyskanie początkowego dostępu do systemu, lecz utrwalenie obecności napastnika na już przejętej stacji roboczej poprzez osadzenie złośliwego komponentu w profilu przeglądarki.

W praktyce oznacza to wykorzystanie legalnego procesu przeglądarki jako nośnika trwałości, kanału komunikacji z serwerem dowodzenia oraz narzędzia do kradzieży danych i wykonywania poleceń. To podejście zwiększa skuteczność ukrywania aktywności atakującego, ponieważ część operacji odbywa się w zaufanym środowisku użytkownika.

W skrócie

PEEP podszywa się pod pozornie nieszkodliwe rozszerzenie zakładek i instaluje się poza oficjalnym sklepem dodatków. Malware modyfikuje mechanizmy integralności konfiguracji Chromium, aby automatycznie aktywować złośliwy moduł bez wzbudzania podejrzeń użytkownika.

Po aktywacji narzędzie cyklicznie łączy się z infrastrukturą C2, zbiera historię przeglądania, metadane kart, adresy URL oraz ciasteczka sesyjne. Kluczowym elementem działania jest wykorzystanie mechanizmu Native Messaging Host, który pozwala przekroczyć ograniczenia sandboxa przeglądarki i uruchamiać zadania bezpośrednio na hoście.

Kontekst / historia

Według analizy badaczy PEEP został zbudowany na bazie RedExt, otwartoźródłowego projektu wykorzystywanego do analiz danych przeglądarkowych i ćwiczeń red teamowych. Nowy zestaw rozwija jednak tę koncepcję o kompletne procedury wdrożeniowe, aktualizacje, beaconing, telemetrię oraz most natywny do systemu operacyjnego.

To istotna różnica, ponieważ PEEP nie przypomina prostego stealera przeglądarkowego. Jest to raczej pełnoprawne narzędzie utrzymywania dostępu po kompromitacji, którego wartość dla operatora polega na trwałości, elastyczności i możliwości prowadzenia dalszych działań z poziomu przeglądarki.

Badacze podkreślają również, że framework nie zawiera własnego wektora initial access. Oznacza to, że atakujący musi wcześniej uzyskać możliwość wykonania kodu lub odpowiednie uprawnienia na hoście, a dopiero później wdrożyć PEEP jako kolejny etap operacji.

Analiza techniczna

Rdzeń narzędzia stanowi złośliwe rozszerzenie podszywające się pod komponent typu „Smart Bookmarks”. Dodatek prowadzi cykliczny beaconing do serwera dowodzenia, odbiera zadania i równolegle eksfiltruje dane przeglądarkowe, takie jak historia, otwarte karty, aktywny adres URL, ustawienia lokalizacyjne i cookies sesyjne.

Najgroźniejszym elementem architektury jest użycie binarki Native Messaging Host oznaczonej jako nm_host.exe. Mechanizm Native Messaging jest legalną funkcją Chromium służącą do komunikacji rozszerzeń z lokalną aplikacją, jednak w tym scenariuszu staje się pomostem między kodem przeglądarki a systemem operacyjnym.

Dzięki temu PEEP może wykonywać polecenia powłoki, zarządzać plikami, identyfikować procesy i usługi oraz realizować działania wykraczające poza standardowe możliwości dodatku przeglądarkowego. Taka architektura sprawia, że przeglądarka staje się praktycznym punktem wykonawczym dla dalszej aktywności po kompromitacji.

W warstwie trwałości malware modyfikuje plik Secure Preferences odpowiedzialny w ekosystemie Chromium między innymi za integralność konfiguracji użytkownika. Fałszowanie wartości integralności pozwala obejść kontrolę aktywacji rozszerzeń i automatycznie uruchamiać złośliwy komponent przy starcie przeglądarki.

Dodatkowo wykorzystywane są polityki wymuszające instalację rozszerzeń, techniki sideloadingu oraz mechanizmy ponownej rejestracji dodatku. W kampanii zaobserwowano również skrypty PowerShell wspierające wdrożenie, w tym włączanie trybu deweloperskiego, poprawianie pliku Secure Preferences i odtwarzanie rejestracji rozszerzenia.

Zidentyfikowano także skrypt dla Linuksa służący do analogicznej manipulacji preferencjami, co może wskazywać na rozwój kompatybilności międzyplatformowej. Po uruchomieniu rozszerzenie ładuje konfigurację C2, inicjalizuje automatyczne zbieranie danych i uruchamia skrypt treści osadzany w odwiedzanych stronach.

Taki model umożliwia wykonywanie działań związanych z przeglądarką, takich jak iniekcja JavaScript, dostęp do schowka czy zbieranie informacji o sesji, a jednocześnie delegowanie poleceń systemowych do komponentu natywnego.

Konsekwencje / ryzyko

PEEP znacząco zwiększa poziom ryzyka po skutecznej kompromitacji stacji roboczej. Przejęta przeglądarka staje się trwałym punktem dostępu działającym w zaufanym i powszechnie używanym procesie, co może utrudniać wykrycie wyłącznie na podstawie klasycznych wskaźników kompromitacji.

Szczególnie niebezpieczna jest możliwość kradzieży aktywnych sesji i danych uwierzytelniających zapisanych lub używanych w przeglądarce. W praktyce może to prowadzić do przejmowania kont SaaS, paneli administracyjnych, zasobów chmurowych i aplikacji biznesowych bez konieczności łamania haseł.

Zdolność do wykonywania poleceń systemowych poprzez Native Messaging oznacza również, że przeglądarka może zostać wykorzystana jako punkt pivotu do dalszego rekonesansu, utrzymania dostępu i manipulowania aktywnością użytkownika. To rozszerza zakres zagrożenia z poziomu kradzieży danych do pełniejszej kontroli nad hostem.

Rekomendacje

Organizacje powinny traktować przeglądarki Chromium jako ważny obszar monitorowania w ramach EDR, DFIR i threat huntingu. Szczególną uwagę warto poświęcić zmianom w katalogach profili Chrome i Edge, zwłaszcza plikom Preferences, Secure Preferences, ScriptCache oraz lokalizacjom związanym z rozszerzeniami.

monitorowanie niestandardowych rozszerzeń instalowanych poza oficjalnymi kanałami,
alertowanie na zmiany w kluczach rejestru odpowiedzialnych za zewnętrzne rozszerzenia,
kontrolę użycia polityk wymuszających instalację dodatków poza standardowym procesem administracyjnym,
wykrywanie rejestracji lub uruchamiania Native Messaging Host bez uzasadnionego kontekstu biznesowego,
analizę nietypowej aktywności PowerShell związanej z profilami przeglądarek,
monitorowanie połączeń HTTP wykonywanych przez procesy przeglądarki do nieznanej infrastruktury.

Z perspektywy hardeningu warto ograniczyć lokalny sideloading rozszerzeń, monitorować użycie trybu deweloperskiego i egzekwować polityki dopuszczające wyłącznie zatwierdzone dodatki. Dobrym uzupełnieniem jest okresowy przegląd zainstalowanych rozszerzeń, walidacja manifestów oraz kontrola binariów zarejestrowanych jako hosty Native Messaging.

W środowiskach podwyższonego ryzyka zalecana jest także segmentacja sesji administracyjnych i uprzywilejowanych. Krytyczne logowania nie powinny odbywać się z tych samych profili przeglądarki, które są używane do codziennej pracy, ponieważ ogranicza to skutki przejęcia ciasteczek sesyjnych.

Podsumowanie

PEEP pokazuje, że nowoczesna przeglądarka może zostać przekształcona z narzędzia użytkownika w trwały komponent dostępu po kompromitacji. O sile tego podejścia decyduje nie tylko kradzież danych przeglądarkowych, ale również nadużycie legalnych mechanizmów Chromium do utrzymania trwałości, obejścia ochrony i wykonywania komend na hoście.

Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia detekcji o telemetrykę związaną z rozszerzeniami, plikami preferencji i mostami Native Messaging. Każde odstępstwo od standardowego modelu wdrażania dodatków do Chrome i Edge powinno być analizowane jak potencjalny incydent bezpieczeństwa.

Źródła

Rhysida atakuje administrację Berlina: wyciek danych i presja podwójnego wymuszenia

Wprowadzenie do problemu / definicja

Incydent przypisywany grupie Rhysida przeciwko sieci administracyjnej Berlina to przykład nowoczesnego ataku ransomware połączonego z kradzieżą danych. W modelu podwójnego wymuszenia napastnicy nie ograniczają się do zaszyfrowania systemów, ale wcześniej eksfiltrują informacje i grożą ich publikacją, aby zwiększyć presję na ofiarę.

Taki scenariusz znacząco podnosi skalę ryzyka. Nawet jeśli organizacja ograniczy skutki operacyjne ataku, nadal musi mierzyć się z potencjalnym naruszeniem danych osobowych, odpowiedzialnością regulacyjną oraz długotrwałymi konsekwencjami reputacyjnymi.

W skrócie

Berlin potwierdził incydent w swojej sieci krajowej oraz otrzymanie żądania okupu.
Grupa Rhysida twierdziła, że przejęła około 5,7–5,8 TB danych.
Wykradzione informacje miały zostać wystawione na sprzedaż z ceną wywoławczą 30 bitcoinów.
Władze zadeklarowały, że nie zapłacą okupu.
Potencjalnie zagrożone mogą być dane pracowników administracji, obywateli oraz firm.

Kontekst / historia

Rhysida jest od dłuższego czasu kojarzona z operacjami ransomware wykorzystującymi schemat double extortion. Tego rodzaju grupy wybierają ofiary, dla których ciągłość działania ma kluczowe znaczenie, a sektor publiczny jest pod tym względem szczególnie podatny na presję operacyjną i polityczną.

W przypadku Berlina publicznie poinformowano o odłączeniu wybranych części infrastruktury od głównej sieci po wykryciu incydentu. Równolegle pojawiły się informacje o żądaniu okupu oraz ryzyku ujawnienia przejętych danych. Taki przebieg zdarzeń odpowiada wzorcowi obserwowanemu w kampaniach przypisywanych grupom nastawionym na wymuszenie finansowe poprzez eksfiltrację i groźbę publikacji danych.

Analiza techniczna

Z technicznego punktu widzenia incydent wpisuje się w klasyczny łańcuch ataku ransomware. Po uzyskaniu dostępu napastnicy zwykle prowadzą rekonesans wewnętrzny, eskalację uprawnień, przemieszczanie boczne oraz przygotowanie do transferu danych poza środowisko ofiary.

W operacjach podobnych do tych przypisywanych Rhysida istotne znaczenie ma etap poprzedzający szyfrowanie lub groźbę publikacji. To właśnie eksfiltracja danych staje się głównym narzędziem nacisku. Jeśli informacje rzeczywiście zostały zebrane w wieloterabajtowym wolumenie i zaoferowane w modelu aukcyjnym, oznacza to próbę monetyzacji nie tylko samego ataku, ale również wtórnego obrotu wykradzionymi zasobami.

Dla zespołów bezpieczeństwa szczególnie niepokojące są symptomy takie jak:

nietypowy ruch wychodzący o dużej objętości,
masowe odczyty udziałów sieciowych i repozytoriów plików,
użycie narzędzi do kompresji i archiwizacji,
nienaturalna aktywność kont uprzywilejowanych,
wykorzystanie legalnych narzędzi administracyjnych do działań ofensywnych,
próby utrzymania trwałości w systemach administracyjnych.

Profil zagrożenia związany z Rhysida pokrywa się z taktykami stosowanymi przez współczesne grupy ransomware działające w modelu partnerskim lub usługowym. Obejmuje to nadużywanie środowisk Windows, wykorzystywanie legalnych mechanizmów zdalnej administracji, eksfiltrację przed etapem destrukcyjnym oraz korzystanie z infrastruktury negocjacyjnej ukrytej w sieciach anonimizujących.

Konsekwencje / ryzyko

Największe ryzyko w tego typu incydentach wynika z połączenia zakłócenia działania z utratą poufności. Jeżeli wśród przejętych materiałów znalazły się dane pracowników, mieszkańców lub podmiotów gospodarczych, skutki mogą obejmować kradzież tożsamości, ukierunkowany phishing, oszustwa wykorzystujące dane urzędowe oraz długofalowe nadużycia wobec osób, których informacje zostały naruszone.

Dla administracji publicznej zagrożenie ma dodatkowy wymiar strategiczny. Wycieki mogą obejmować nie tylko dane osobowe, ale również dokumentację operacyjną, wewnętrzną komunikację, informacje o dostawcach czy elementy procedur bezpieczeństwa. To z kolei może ułatwić kolejne kampanie spear phishingowe, podszywanie się pod instytucje publiczne oraz ataki łańcucha dostaw wymierzone w partnerów i wykonawców.

Nie można też pomijać kosztów wtórnych. Obsługa incydentu, analiza śledcza, notyfikacje, wsparcie prawne i działania naprawcze generują znaczące obciążenie organizacyjne i finansowe, a utrata zaufania społecznego może mieć długofalowe skutki wykraczające poza sam aspekt techniczny.

Rekomendacje

Incydent w Berlinie przypomina, że obrona przed ransomware nie może opierać się wyłącznie na kopiach zapasowych. Konieczne są także mechanizmy utrudniające eksfiltrację danych oraz ograniczające możliwość nadużycia kont uprzywilejowanych.

Wdrożenie silnego MFA dla wszystkich zdalnych punktów dostępu.
Segmentacja sieci oraz szybka możliwość izolacji krytycznych segmentów.
Ograniczenie uprawnień administracyjnych zgodnie z zasadą najmniejszych uprawnień.
Monitoring ruchu wychodzącego i centralna detekcja nietypowych transferów danych.
Regularna rotacja poświadczeń uprzywilejowanych oraz przegląd kont serwisowych.
Eliminacja ekspozycji usług administracyjnych do internetu tam, gdzie nie jest to niezbędne.

Po stronie detekcji warto rozwijać reguły obejmujące nietypowe użycie PowerShell, RDP, archiwizatorów oraz narzędzi systemowych wykorzystywanych do rekonesansu i przemieszczania bocznego. Równie ważne są przetestowane procedury reagowania na incydenty, scenariusze komunikacji kryzysowej oraz gotowe ścieżki współpracy z CERT, organami ścigania i inspektorami ochrony danych.

Z perspektywy odporności organizacyjnej kluczowe znaczenie mają także ćwiczenia tabletop dla scenariuszy double extortion, przegląd klasyfikacji informacji, minimalizacja retencji danych oraz szyfrowanie danych w spoczynku tam, gdzie jest to możliwe. Im mniejszy wolumen dostępnych informacji, tym mniejsza siła późniejszego szantażu.

Podsumowanie

Atak przypisywany Rhysida na administrację Berlina pokazuje, że współczesne ransomware to przede wszystkim operacje wymuszenia oparte na kradzieży danych. Nawet szybka reakcja i odmowa zapłaty nie eliminują ryzyka publikacji informacji, naruszenia prywatności i wielomiesięcznych działań naprawczych.

Dla sektora publicznego i prywatnego najważniejszy wniosek jest jasny: skuteczna obrona wymaga jednocześnie prewencji, detekcji, segmentacji, kontroli tożsamości oraz gotowości do obsługi incydentu naruszenia danych na dużą skalę.

Źródła

Złośliwe klienty ScreenConnect rozprzestrzeniają czteroetapowy łańcuch VBScript na nowe hosty

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali kampanie, w których legalne narzędzie zdalnego dostępu ConnectWise ScreenConnect zostało wykorzystane do dystrybucji złośliwego, czteroetapowego łańcucha VBScript. To podejście sprawia, że przejęty klient nie służy wyłącznie do utrzymania dostępu, ale może także przenosić kolejne ładunki na nowe systemy łączące się z zainfekowaną instancją.

Taki model działania upodabnia incydent do zagrożenia o cechach robaka. Z perspektywy zespołów bezpieczeństwa oznacza to konieczność traktowania narzędzi RMM i zdalnego wsparcia nie tylko jako potencjalnie nadużywanych aplikacji administracyjnych, ale również jako kanału wtórnej infekcji.

W skrócie

Ataki wykorzystywały kilka metod początkowego dostępu, w tym oszustwa z użyciem Quick Assist, phishing z instalatorem MSI oraz fałszywe przynęty związane ze zwrotem pieniędzy.
Po instalacji nieautoryzowanego klienta ScreenConnect uruchamiany był łańcuch skryptów 1.vbs, 2.vbs, 3.vbs i 4.vbs.
Skrypty profilowały host, dobierały wariant ładunku, pobierały kolejne komponenty i uruchamiały PowerShell odpowiedzialny za odszyfrowanie oraz wykonanie malware.
Wśród skutków obserwowano backdoor ScreenConnect, narzędzia do eskalacji uprawnień, persistence, tunelowania ruchu oraz koparkę kryptowalut XMRig.
Najgroźniejszym elementem kampanii był mechanizm propagacji na kolejne hosty podłączające się do przejętego klienta.

Kontekst / historia

Opisywane incydenty odnotowano w sierpniu 2026 roku. Chociaż różniły się metodą uzyskania początkowego dostępu, wykazywały wspólne artefakty i niemal identyczny przebieg wykonania, co sugeruje spójną logikę operacyjną lub współdzielone zestawy narzędzi.

W praktyce ofiary były nakłaniane do uruchomienia narzędzi pomocy zdalnej albo otwarcia dostarczonych plików instalacyjnych. Po zakończeniu tej fazy na systemie pojawiał się nieautoryzowany klient ScreenConnect skonfigurowany do komunikacji z infrastrukturą kontrolowaną przez operatorów kampanii.

Znaczenie sprawy zwiększa fakt, że producent ScreenConnect opublikował zalecenia ograniczające ryzyko do czasu wdrożenia poprawki. Problem miał dotyczyć zachowania transferu plików w sesjach Remote Access Support i Access, zarówno w środowiskach chmurowych, jak i wdrożeniach on-premise.

Analiza techniczna

Rdzeniem kampanii był sekwencyjny łańcuch czterech skryptów VBScript uruchamianych przez proces wscript.exe. Każdy etap przygotowywał dane dla kolejnego, dzięki czemu operatorzy mogli elastycznie dobierać ładunki końcowe do stanu i poziomu ochrony zainfekowanego hosta.

Pierwszy etap, 1.vbs, odpowiadał za rekonesans systemu. Skrypt sprawdzał między innymi zasoby hosta, obecność ScreenConnect i rozwiązania bezpieczeństwa, a następnie zapisywał wynik do pliku tymczasowego w uproszczonej postaci stanu. Taka logika pozwalała warunkować dalszy przebieg infekcji.

Drugi skrypt, 2.vbs, odczytywał przygotowany stan i decydował, czy kontynuować wykonanie. Następnie pobierał dane z zewnętrznego źródła i tworzył artefakty pośrednie wykorzystywane do przygotowania mapowania dalszych zasobów lub logiki pobrania właściwego ładunku.

Trzeci etap, 3.vbs, pobierał odpowiedni plik zależnie od wcześniejszego profilu ofiary. Zasób trafiał do zaszyfrowanego pliku tymczasowego, co utrudniało analizę statyczną i umożliwiało selektywne dostarczanie malware tylko do określonych środowisk.

Czwarty skrypt, 4.vbs, uruchamiał PowerShell odpowiedzialny za odszyfrowanie pobranego ładunku, zapisanie go w ukrytej lokalizacji i wykonanie kolejnych poleceń. W zależności od wariantu końcowy efekt mógł obejmować różne funkcje operacyjne.

backdoor ScreenConnect działający w kontekście użytkownika,
komponenty do obejścia UAC i utrzymania trwałości,
narzędzia tunelujące,
koparkę kryptowalut XMRig.

Szczególnie niebezpieczny był mechanizm propagacji. W wybranych ścieżkach wykonania skrypty były kopiowane do lokalizacji publicznej, a zainfekowany klient ScreenConnect stawał się nośnikiem kolejnych dostaw. Gdy nowy host nawiązywał połączenie, ten sam łańcuch mógł zostać ponownie uruchomiony, rozszerzając incydent na następne systemy.

Operatorzy stosowali również techniki utrudniające analizę. Zaobserwowano końcowe skrypty PowerShell zamykające procesy wscript.exe i cscript.exe, a następnie usuwające katalog roboczy. W części przypadków wykryto też wpisy autostartu wskazujące na skrypty w profilu użytkownika, co sugeruje próbę utrzymania dostępu po restarcie systemu.

Konsekwencje / ryzyko

Najpoważniejszym ryzykiem jest połączenie legalnego narzędzia administracyjnego z mechanizmem samorozprzestrzeniania. W praktyce oznacza to możliwość kaskadowego dostarczania malware pomiędzy kolejnymi endpointami korzystającymi z pozornie zaufanego kanału zdalnego dostępu.

Dla organizacji skutki mogą obejmować trwały nieautoryzowany dostęp do stacji roboczych, eskalację uprawnień, osłabienie zabezpieczeń systemu Windows, cryptojacking oraz rozszerzenie incydentu na kolejne hosty. Taki scenariusz znacząco podnosi koszt i złożoność działań IR, ponieważ usunięcie pojedynczego pliku lub procesu może nie rozwiązać całego problemu.

Dodatkowym zagrożeniem jest selektywny dobór ładunków na podstawie obecności rozwiązań EDR lub AV. To wskazuje, że operatorzy aktywnie starają się unikać detekcji i maksymalizować skuteczność infekcji w zależności od poziomu ochrony konkretnego hosta.

Rekomendacje

Organizacje korzystające ze ScreenConnect powinny potraktować taki scenariusz jako incydent wysokiego priorytetu. Konieczne jest jednoczesne wdrożenie działań zapobiegawczych, monitoringu oraz procedur reagowania na hostach, które mogły zostać objęte propagacją.

Zweryfikować wszystkie instancje ScreenConnect pod kątem nieautoryzowanych klientów i nietypowych połączeń.
Tymczasowo ograniczyć lub wyłączyć transfer plików tam, gdzie jest to operacyjnie możliwe.
Analizować uruchomienia wscript.exe, cscript.exe i PowerShell z katalogów tymczasowych oraz nietypowych ścieżek w AppData i Public.
Monitorować tworzenie plików takich jak 1.vbs, 2.vbs, 3.vbs, 4.vbs, value.txt, map.txt, out.enc, runner.ps1 i PyTorchFix.ps1.
Sprawdzić wpisy autostartu użytkownika i inne artefakty persistence związane ze skryptami VBS.
Przeanalizować zgłoszenia phishingowe, historię pobrań i przypadki użycia Quick Assist w zespołach wsparcia.
Izolować hosty, na których wykryto nieautoryzowanego klienta ScreenConnect lub oznaki działania łańcucha VBScript.
Rozważyć pełne odtworzenie systemu z zaufanego obrazu, jeśli wykonane zostały końcowe etapy ładunku.
Ograniczyć wykonywanie VBScript i niepodpisanych skryptów PowerShell tam, gdzie polityki bezpieczeństwa na to pozwalają.

Z perspektywy reagowania warto założyć, że wykryty backdoor może być tylko jednym z elementów incydentu. Warianty obejmujące eskalację uprawnień i osłabienie zabezpieczeń zwiększają ryzyko dalszego ruchu bocznego, kradzieży danych i ponownej kompromitacji po pozornym oczyszczeniu środowiska.

Podsumowanie

Opisana kampania pokazuje, że narzędzia zdalnego dostępu pozostają atrakcyjnym celem dla atakujących i mogą zostać przekształcone w mechanizm wtórnej infekcji. Szczególnie groźne jest połączenie socjotechniki, legalnego oprogramowania administracyjnego, wieloetapowego łańcucha VBScript i selektywnego doboru ładunków końcowych.

Dla zespołów bezpieczeństwa najważniejsze wnioski są trzy: monitorować narzędzia RMM równie uważnie jak klasyczne malware, traktować nietypowe użycie wscript.exe i PowerShell z katalogów tymczasowych jako sygnał wysokiego ryzyka oraz rozważać pełne odtworzenie systemu w przypadku potwierdzonej kompromitacji.

Źródła

The Hacker News — https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
ConnectWise Advisory — https://www.connectwise.com/company/trust/advisories
Huntress — https://www.huntress.com/

PEEP zamienia Chrome i Edge w tylne furtki po przejęciu stacji roboczej

Wprowadzenie do problemu / definicja

PEEP to zaawansowany zestaw narzędzi post-exploitation ukierunkowany na przeglądarki oparte na Chromium, przede wszystkim Google Chrome i Microsoft Edge. Nie służy on do uzyskiwania pierwszego dostępu do środowiska, lecz aktywuje się po wcześniejszej kompromitacji systemu i wykorzystuje przeglądarkę jako trwały kanał komunikacji, eksfiltracji danych oraz wykonywania poleceń.

Kluczowym elementem działania PEEP jest złośliwe rozszerzenie podszywające się pod legalny komponent przeglądarki. Dzięki temu zagrożenie działa w zaufanym procesie użytkownika, co utrudnia jego wykrycie i zwiększa skuteczność przejmowania sesji, danych przeglądarkowych oraz kontroli nad hostem.

W skrócie

PEEP to framework działający po kompromitacji systemu, a nie narzędzie do początkowego włamania.
Złośliwe rozszerzenie „Smart Bookmarks” jest osadzane bezpośrednio w profilach Chrome i Edge.
Malware wykrada historię przeglądania, pliki cookie, dane sesyjne i metadane aktywności użytkownika.
Mechanizm Native Messaging umożliwia wykonywanie poleceń systemowych poza sandboxem przeglądarki.
Zagrożenie wykorzystuje wiele metod utrwalenia, w tym modyfikacje profili, polityk i rejestru.

Kontekst / historia

Analiza wskazuje, że PEEP bazuje na otwartoźródłowym frameworku RedExt, pierwotnie przeznaczonym do analiz danych przeglądarkowych i zastosowań red teamowych. W złośliwej wersji rozwiązanie zostało rozbudowane o gotowy łańcuch instalacyjny, regularną telemetrię, funkcję aktualizacji, komponent natywny oraz zestaw komend operacyjnych typowych dla dojrzałego malware.

To dobry przykład szerszego trendu, w którym legalne mechanizmy administracyjne i funkcje przeglądarki są adaptowane do działań ofensywnych. W praktyce oznacza to odejście od prostych loaderów na rzecz nadużywania wbudowanych funkcji systemu i aplikacji, co utrudnia wykrywanie przez klasyczne rozwiązania ochronne.

Analiza techniczna

Sercem PEEP jest złośliwe rozszerzenie Chromium utrzymujące cykliczną komunikację z serwerem dowodzenia i kontroli. Mechanizm beaconingu działa regularnie, pobiera zadania od operatora, zbiera dane z przeglądarki i zwraca wyniki wykonania. W efekcie przeglądarka staje się interaktywnym agentem działającym w kontekście zalogowanego użytkownika.

Zakres gromadzonych danych obejmuje historię przeglądania, aktywne adresy URL, informacje o kartach, ustawienia regionalne, strefę czasową oraz sesyjne pliki cookie. Taki zestaw informacji pozwala nie tylko profilować ofiarę, ale również wspiera przejmowanie aktywnych sesji webowych, w tym dostępów do usług SaaS, poczty czy paneli administracyjnych.

Szczególnie istotną rolę odgrywa komponent natywny uruchamiany za pomocą mechanizmu Native Messaging. To on umożliwia wyjście poza środowisko przeglądarki i wykonywanie działań na poziomie systemu operacyjnego, takich jak uruchamianie poleceń, operacje na plikach czy rozpoznanie procesów i usług. Właśnie ten element sprawia, że PEEP należy traktować nie jako zwykłe złośliwe rozszerzenie, lecz jako pełnoprawny backdoor.

W zakresie utrwalenia obecności malware korzysta z modyfikacji plików konfiguracyjnych profilu, w tym Secure Preferences, a także z technik sideloadingu, polityk wymuszonej instalacji rozszerzeń, wpisów rejestru użytkownika i zewnętrznych manifestów. Dodatkowo w łańcuchu instalacyjnym pojawiają się skrypty PowerShell odpowiadające za włączanie trybu deweloperskiego, obchodzenie mechanizmów integralności oraz ponowną rejestrację rozszerzenia po jego usunięciu.

Istotne znaczenie ma również architektura komunikacji z infrastrukturą C2. Oddzielne endpointy mogą odpowiadać za rejestrację agenta, heartbeat, odbiór poleceń, eksfiltrację danych i aktualizację komponentów. Z perspektywy operatora daje to możliwość utrzymywania stałej kontroli nad infekcją oraz dynamicznego rozszerzania możliwości narzędzia bez wdrażania nowego ładunku inną ścieżką.

Konsekwencje / ryzyko

Największe ryzyko związane z PEEP wynika z połączenia trzech cech: działania wewnątrz zaufanego procesu przeglądarki, dostępu do aktywnych artefaktów sesyjnych oraz możliwości wykonywania poleceń na hoście. Taka kombinacja umożliwia zarówno kradzież danych, jak i długotrwałą obecność przeciwnika na stacji roboczej.

W praktyce szczególnie narażone są konta dostępowe do systemów biznesowych, aplikacji chmurowych, skrzynek pocztowych i paneli administracyjnych obsługiwanych przez przeglądarkę. Przejęte cookies i dane sesyjne mogą wspierać session hijacking, a możliwość ingerencji w treść stron lub wykonywania skryptów otwiera drogę do dalszej kradzieży poświadczeń i manipulowania interakcjami użytkownika.

Dla zespołów SOC i DFIR wyzwaniem jest fakt, że istotna część aktywności realizowana jest przez podpisany i powszechnie używany proces przeglądarki. Oznacza to, że tradycyjne reguły wykrywania skupione na nowych plikach wykonywalnych lub standardowych loaderach mogą nie zapewniać wystarczającej widoczności.

Rekomendacje

Organizacje powinny traktować przeglądarki Chromium jako pełnoprawny element powierzchni ataku endpointu. Ochrona nie może ograniczać się do binariów i procesów systemowych, ale powinna obejmować również rozszerzenia, polityki instalacyjne oraz integralność plików konfiguracyjnych w profilach użytkowników.

Wdrożyć listy dozwolonych rozszerzeń i blokować dodatki spoza autoryzowanych źródeł.
Regularnie audytować ustawienia polityk instalacyjnych rozszerzeń oraz wpisy rejestru związane z zewnętrznymi dodatkami.
Monitorować zmiany w plikach Preferences i Secure Preferences w profilach Chrome oraz Edge.
Traktować nieoczekiwane włączenie trybu deweloperskiego jako sygnał ostrzegawczy.
Wykrywać uruchamianie natywnych hostów przez przeglądarkę oraz nietypowe skrypty PowerShell ingerujące w profile Chromium.
Korelować zdarzenia przeglądarkowe z aktywnością systemową i komunikacją do nieznanych endpointów.

W przypadku podejrzenia infekcji nie wystarczy samo usunięcie rozszerzenia. Konieczna jest pełna analiza profilu przeglądarki, polityk systemowych, artefaktów Native Messaging, wpisów rejestru oraz aktywnych sesji użytkownika. Równolegle należy unieważnić sesje webowe, wymusić ponowne logowanie i przeprowadzić rotację haseł do krytycznych usług.

Podsumowanie

PEEP pokazuje, że przeglądarka internetowa staje się coraz częściej pomostem między warstwą użytkownika a systemem operacyjnym. Połączenie złośliwego rozszerzenia, obejścia mechanizmów integralności Chromium i natywnego komponentu hosta daje atakującym trwały, trudny do wykrycia kanał dostępu o wysokiej wartości operacyjnej.

Dla obrońców to wyraźny sygnał, że bezpieczeństwo endpointów musi obejmować również telemetrykę i kontrolę bezpieczeństwa przeglądarek. W przeciwnym razie organizacja może przeoczyć zagrożenie działające w jednym z najbardziej zaufanych i najczęściej używanych procesów użytkownika.