Archiwa: Windows - Strona 4 z 154

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/

BigBear 2.0 omija MFA w Microsoft 365. Nowa fala phishing-as-a-service uderza w firmy

Wprowadzenie do problemu / definicja

BigBear 2.0 to platforma phishing-as-a-service (PhaaS) zaprojektowana do przejmowania kont Microsoft 365 z wykorzystaniem techniki adversary-in-the-middle (AiTM). W praktyce atak nie polega na klasycznym łamaniu mechanizmu uwierzytelniania wieloskładnikowego, lecz na pośredniczeniu w prawdziwym procesie logowania, przechwytywaniu poświadczeń oraz ciasteczek sesyjnych użytkownika.

Taki model działania pokazuje, że tradycyjne MFA oparte na kodach SMS, aplikacjach OTP czy prostych powiadomieniach push nie zawsze chroni przed nowoczesnym phishingiem wymierzonym w tożsamość. Jeżeli napastnik przejmie aktywną sesję, może uzyskać dostęp do konta bez ponownego przechodzenia drugiego składnika.

W skrócie

BigBear 2.0 to zestaw PhaaS ukierunkowany na konta Microsoft 365.
Kampania wykorzystywała mechanizm AiTM oparty na frameworku Evilginx2.
Według ustaleń badaczy obejście MFA miało dotknąć 258 organizacji.
Panel operatorski obsługiwał 42 węzły VPS skoncentrowane wyłącznie na Microsoft 365.
Ujawnione dane wskazują na kradzież ponad 5 tys. rekordów poświadczeń, w tym aktywnych sesji po MFA.

Kontekst / historia

Phishing proxy oraz zestawy AiTM nie są nowością, ale w ostatnich latach wyraźnie dojrzały operacyjnie. Narzędzia takie jak Evilginx2 zdobyły popularność, ponieważ pozwalają cyberprzestępcom atakować użytkowników usług chmurowych bez potrzeby wykorzystywania podatności po stronie samego dostawcy.

BigBear 2.0 wpisuje się w ten trend, lecz wyróżnia się skalą i poziomem organizacji. Z dostępnych ustaleń wynika, że operatorzy korzystali z panelu administracyjnego umożliwiającego zarządzanie infrastrukturą phishingową, obsługę wielu węzłów oraz dystrybucję skradzionych danych. To kolejny sygnał, że przestępczość ukierunkowana na tożsamość w chmurze staje się coraz bardziej sprofesjonalizowana.

Dla firm korzystających z Microsoft 365 ma to szczególne znaczenie. Konta pocztowe i dostęp do usług współpracy są dziś jednym z najważniejszych punktów wejścia do dalszych etapów ataku, w tym do oszustw BEC, kradzieży dokumentów czy ruchu bocznego przez mechanizmy single sign-on.

Analiza techniczna

Rdzeniem operacji był atak AiTM, w którym ofiara trafiała na fałszywą stronę logowania pełniącą rolę odwrotnego proxy między użytkownikiem a prawdziwym systemem uwierzytelniania Microsoft. Ofiara wpisywała login i hasło, a następnie realizowała drugi składnik uwierzytelnienia w interfejsie przypominającym legalny portal.

Cały ruch przechodził jednak przez infrastrukturę kontrolowaną przez napastnika. Po poprawnym uwierzytelnieniu serwer tożsamości wystawiał sesję oraz odpowiednie cookies lub tokeny. To właśnie one były przechwytywane przez złośliwy serwer proxy, a następnie wykorzystywane do odtworzenia legalnie uwierzytelnionej sesji po stronie atakującego.

W analizowanej kampanii stosowano konfiguracje phishingowe przygotowane specjalnie pod Microsoft 365. Infrastrukturę wspierały również geograficznie dopasowane proxy rezydencyjne, co mogło utrudniać wykrywanie anomalii opartych wyłącznie na lokalizacji logowania lub późniejszego użycia sesji.

Istotnym elementem był także kod JavaScript ingerujący w obsługę FIDO2 i WebAuthn po stronie przeglądarki. Celem takiej manipulacji nie było złamanie tych technologii, lecz zepchnięcie użytkownika do słabszych metod uwierzytelniania, które łatwiej obsłużyć w modelu phishing proxy.

Z technicznego punktu widzenia problem nie dotyczy kompromitacji samego MFA jako protokołu kryptograficznego. Atak uderza w warstwę sesji i wykorzystuje fakt, że po udanym logowaniu przeglądarka otrzymuje artefakty sesyjne, które mogą zostać skradzione, jeśli użytkownik komunikuje się z usługą przez złośliwego pośrednika.

Konsekwencje / ryzyko

Skuteczne przejęcie sesji Microsoft 365 może otworzyć napastnikowi dostęp do poczty, OneDrive, SharePoint, Teams oraz innych aplikacji powiązanych z tym samym kontekstem tożsamości. W organizacji oznacza to ryzyko wycieku danych, podszywania się pod pracowników, nadużyć finansowych i eskalacji incydentu do kont o wyższych uprawnieniach.

Szczególnie groźne są scenariusze business email compromise. Napastnik mający dostęp do prawdziwej skrzynki może analizować relacje biznesowe, tworzyć reguły ukrywające wiadomości, monitorować obieg faktur i prowadzić bardzo wiarygodne oszustwa wobec kontrahentów lub działów finansowych.

Problem pogłębia fakt, że wiele organizacji nadal traktuje tradycyjne MFA jako wystarczającą ochronę przed phishingiem. Kampanie takie jak BigBear 2.0 pokazują, że sam drugi składnik nie eliminuje ryzyka, jeśli nie jest odporny na pośrednictwo i nie towarzyszą mu dodatkowe zabezpieczenia związane z urządzeniem, kontekstem dostępu i monitoringiem sesji.

Rekomendacje

Najważniejszym kierunkiem obrony jest wdrażanie phishing-resistant MFA. W praktyce oznacza to preferowanie FIDO2, passkeys, Windows Hello for Business oraz innych metod, które są znacznie bardziej odporne na przechwycenie w modelu AiTM. Równocześnie warto ograniczać lub wycofywać słabsze formy uwierzytelniania, takie jak SMS OTP czy proste zatwierdzanie push.

Organizacje powinny też wzmacniać polityki dostępu warunkowego i opierać je nie tylko na lokalizacji, lecz przede wszystkim na stanie urządzenia, poziomie ryzyka logowania, sile uwierzytelnienia i kontekście aplikacji. Sam sygnał geograficzny bywa niewystarczający, zwłaszcza gdy przeciwnik korzysta z proxy rezydencyjnych dopasowanych do regionu ofiary.

W przypadku podejrzenia kompromitacji warto podjąć następujące działania:

zresetować hasło użytkownika,
unieważnić aktywne sesje,
odwołać lub odświeżyć tokeny dostępu,
wymusić ponowne uwierzytelnienie,
sprawdzić reguły skrzynki pocztowej i delegacje,
przeanalizować nietypowe aplikacje OAuth,
zbadać logi pod kątem anomalii w sesjach i użyciu tokenów.

Zespoły SOC powinny monitorować oznaki kradzieży ciasteczek sesyjnych, nietypowe zmiany w aktywnych sesjach webowych, nowe lokalizacje dostępu do poczty oraz działania wykonywane bezpośrednio po poprawnym logowaniu użytkownika. Istotne pozostaje także szkolenie pracowników, choć przy zaawansowanych kampaniach samo podnoszenie świadomości nie zastąpi skutecznych mechanizmów technicznych.

Podsumowanie

BigBear 2.0 potwierdza, że współczesny phishing coraz częściej koncentruje się na przejęciu sesji, a nie tylko na kradzieży hasła. Kampania wymierzona w Microsoft 365 pokazuje, że dobrze przygotowany zestaw AiTM może skutecznie obchodzić tradycyjne MFA i prowadzić do kompromitacji kont na dużą skalę.

Dla organizacji wniosek jest jednoznaczny: MFA nadal pozostaje niezbędne, ale musi być odporne na phishing i wspierane przez dojrzałe polityki dostępu warunkowego, kontrolę urządzeń oraz skuteczne procesy wykrywania i reagowania na incydenty tożsamościowe.

Źródła

BleepingComputer — BigBear Microsoft 365 phishing service bypassed MFA at 258 organizations — https://www.bleepingcomputer.com/news/security/bigbear-microsoft-365-phishing-service-bypassed-mfa-at-258-organizations/
CloudSEK — Tracking BigBear 2.0 Evilginx2 Phishing Campaign — https://www.cloudsek.com/blog/tracking-bigbear-2-0-evilginx2-phishing-campaign
Microsoft Learn — Phishing-resistant MFA — https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa
Microsoft Security Blog — Detecting and mitigating a multi-stage AiTM phishing and BEC campaign — https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/
Microsoft Learn — Alert grading for session cookie theft alert – Microsoft Defender XDR — https://learn.microsoft.com/en-us/defender-xdr/session-cookie-theft-alert

Luki PaperCut wykorzystywane w atakach na szkoły w USA i Europie

Wprowadzenie do problemu

PaperCut to popularna platforma do zarządzania drukiem, szeroko stosowana w szkołach, uczelniach, administracji i firmach. Najnowsze incydenty pokazują jednak, że tego typu systemy mogą stać się wygodnym punktem wejścia do sieci organizacji, zwłaszcza gdy łączą w sobie podatności umożliwiające obejście uwierzytelniania oraz zdalne wykonanie kodu.

W praktyce oznacza to możliwość przejęcia kontroli nad serwerem, uruchamiania poleceń systemowych, kradzieży poświadczeń i dalszego przemieszczania się po infrastrukturze. Dla sektora edukacyjnego, który często działa w środowiskach o ograniczonych zasobach bezpieczeństwa, ryzyko jest szczególnie wysokie.

W skrócie

Atakujący aktywnie wykorzystywali nowe luki w oprogramowaniu PaperCut przeciwko szkołom i innym podmiotom edukacyjnym w Stanach Zjednoczonych oraz Europie. Scenariusz ataku zakładał połączenie podatności typu authentication bypass z mechanizmem zdalnego wykonywania poleceń.

napastnicy uzyskiwali dostęp do serwera PaperCut bez standardowego procesu logowania,
po kompromitacji prowadzili rekonesans środowiska i hosta,
tworzyli uprzywilejowane konta w celu utrwalenia dostępu,
pobierali narzędzia do pozyskiwania poświadczeń i dalszej eksploatacji,
analizowali pliki konfiguracyjne w poszukiwaniu haseł, sekretów i ustawień LDAP.

Kontekst i historia

PaperCut już wcześniej pojawiał się w analizach incydentów jako element wykorzystywany w kampaniach cyberprzestępczych, w tym operacjach prowadzących do wdrożenia ransomware. Z tego powodu każda nowa krytyczna luka w tym produkcie automatycznie zwiększa poziom zagrożenia dla organizacji, które utrzymują publicznie dostępne interfejsy administracyjne lub z opóźnieniem wdrażają poprawki.

W opisywanej kampanii szczególnie istotne było tempo działania atakujących. Między ujawnieniem podatności a pierwszymi przypadkami realnej eksploatacji upłynęło niewiele czasu. To potwierdza, że systemy wspierające, takie jak infrastruktura druku, są stale monitorowane przez przestępców pod kątem nowych możliwości wejścia do środowiska ofiary.

Analiza techniczna

Ataki opierały się na wykorzystaniu podatności oznaczonych jako CVE-2026-81578 oraz CVE-2026-82078. Najgroźniejszy był scenariusz łańcuchowy, w którym najpierw dochodziło do obejścia mechanizmu uwierzytelniania, a następnie do zdalnego wykonania kodu na serwerze PaperCut. Taka kombinacja znacząco skraca czas potrzebny na przejście od wykrycia podatnej usługi do pełnej kompromitacji hosta.

Po uzyskaniu dostępu napastnicy wykonywali polecenia służące do rekonesansu, w tym sprawdzanie użytkownika, procesów, wersji systemu i nazwy hosta. Następnie obserwowano tworzenie uprzywilejowanego konta o nazwie „Administrator17”, co mogło służyć zarówno utrwaleniu dostępu, jak i ułatwieniu dalszych działań w sieci.

W dalszym etapie kampanii wykorzystywano narzędzia systemowe, takie jak certutil, do pobierania dodatkowych komponentów. Analiza wskazywała również na użycie ładunków Java powiązanych z Meterpreterem, co sugeruje próbę ustanowienia interaktywnej sesji zdalnej oraz elastycznego wdrażania kolejnych narzędzi ofensywnych bez konieczności natychmiastowego uruchamiania bardziej rozbudowanego malware.

Atakujący przeszukiwali też pliki konfiguracyjne PaperCut w celu odnalezienia poświadczeń, sekretów, tokenów oraz parametrów integracji z LDAP. To szczególnie niebezpieczne, ponieważ systemy zarządzania drukiem bywają połączone z centralną infrastrukturą katalogową, a wyciek takich danych może prowadzić do eskalacji uprawnień poza samą aplikacją.

W analizowanych śladach aktywności pojawiło się również narzędzie lsa_collect.exe, którego użycie wiązano z próbą pozyskania danych potrzebnych do odzyskania Windows BootKey. Może to stanowić etap przygotowawczy do dostępu do bazy SAM i odzyskiwania lokalnych poświadczeń. Z perspektywy obrońcy jest to sygnał, że incydent wykraczał poza prostą kompromitację aplikacji i zmierzał w kierunku głębszego przejęcia systemu operacyjnego.

Dodatkowe wskaźniki aktywności obejmowały pliki o krótkich, pięcioznakowych nazwach z rozszerzeniami .class, .cmd lub .out, uruchamianie cmd.exe i powershell.exe przez proces pc-app.exe, a także nietypowe żądania do niestandardowych ścieżek oraz większe transfery realizowane przez klienta python-requests.

Konsekwencje i ryzyko

Ryzyko wynikające z takich incydentów jest wielopoziomowe. Na pierwszym etapie dochodzi do przejęcia serwera PaperCut i uzyskania możliwości wykonywania poleceń w systemie operacyjnym. Następnie napastnik może przejść do kradzieży poświadczeń lokalnych i aplikacyjnych, a w dalszej kolejności do kompromitacji usług katalogowych, kont uprzywilejowanych i innych krytycznych zasobów.

Dla placówek edukacyjnych oznacza to realne zagrożenie zakłóceniem pracy infrastruktury IT, niedostępnością usług dla uczniów i pracowników, ryzykiem naruszenia danych osobowych oraz wzrostem kosztów reagowania na incydent. W środowiskach o słabej segmentacji sieci nawet pozornie drugorzędna usługa może stać się początkiem szerokiej kompromitacji.

Rekomendacje

Najważniejszym krokiem powinno być niezwłoczne wdrożenie poprawek bezpieczeństwa udostępnionych przez producenta. Organizacje powinny również sprawdzić, czy interfejsy administracyjne PaperCut nie są wystawione bezpośrednio do Internetu. Jeśli zdalny dostęp jest niezbędny, powinien być realizowany przez kontrolowane kanały z dodatkowymi zabezpieczeniami.

przeanalizować logi server.log pod kątem znanych wskaźników eksploatacji,
zweryfikować, czy proces pc-app.exe nie uruchamiał powłok systemowych,
sprawdzić obecność poleceń rekonesansowych i nietypowych kont administracyjnych,
skontrolować użycie certutil, powershell.exe oraz artefaktów związanych z ładunkami Java,
wymusić rotację poświadczeń, jeśli istnieje ryzyko ujawnienia danych integracyjnych,
ograniczyć uprawnienia usługi PaperCut do absolutnego minimum,
wdrożyć monitoring EDR na serwerach druku i systemach pomocniczych,
blokować nieautoryzowany ruch wychodzący z serwerów aplikacyjnych,
regularnie testować procedury reagowania na incydenty dla systemów wspierających.

Podsumowanie

Wykorzystanie luk w PaperCut przeciwko szkołom w USA i Europie pokazuje, że systemy zarządzania drukiem nadal stanowią atrakcyjny wektor wejścia do sieci organizacji. Połączenie obejścia uwierzytelniania z możliwością zdalnego wykonania kodu daje napastnikom szybki dostęp do hosta, a następnie do poświadczeń, konfiguracji i potencjalnie całej infrastruktury.

Dla organizacji edukacyjnych kluczowe znaczenie mają szybkie aktualizacje, ograniczanie ekspozycji usług, monitoring aktywności post-exploitation i dokładna analiza logów. Bezpieczeństwo systemów pomocniczych nie powinno być traktowane jako priorytet drugiej kategorii, ponieważ to właśnie one coraz częściej stają się początkiem poważnych incydentów.

Źródła

REVSTEALER rozszerza atak: powiązane moduły wyłączają Windows Update i Defender, a następnie uruchamiają koparkę

Wprowadzenie do problemu / definicja

REVSTEALER to zagrożenie typu infostealer atakujące systemy Windows, zaprojektowane do kradzieży haseł, ciasteczek, danych komunikatorów, plików portfeli kryptowalutowych oraz innych wrażliwych informacji. Najnowsze ustalenia pokazują jednak, że jego działanie wykracza poza klasyczną eksfiltrację danych.

Z kampanią powiązano cztery dodatkowe moduły, które mogą pozostać aktywne na urządzeniu nawet po samousunięciu głównego stealer’a. Oznacza to, że ofiara może błędnie uznać incydent za zakończony, podczas gdy system nadal pozostaje osłabiony, monitorowany lub wykorzystywany do dalszych działań przestępczych.

W skrócie

REVSTEALER kradnie dane uwierzytelniające, sesje aplikacji i informacje o portfelach kryptowalutowych.
Z malware powiązano cztery moduły: ProManager, WinUpdate, SoftManager oraz LockAppHost.
Komponenty te odpowiadają za trwałość w systemie, przechwytywanie danych, podmianę adresów portfeli, reverse proxy oraz kryptomining.
Najgroźniejszy moduł wyłącza Windows Update i osłabia Microsoft Defender przed uruchomieniem koparki.
Samousunięcie głównego pliku malware może utrudnić prawidłową ocenę skali incydentu.

Kontekst / historia

REVSTEALER był oferowany jako komercyjny stealer co najmniej od lutego 2026 roku. Kampanie dystrybucyjne opierały się głównie na fałszywym oprogramowaniu, cheat-ach do gier oraz podszywaniu się pod darmowe narzędzia wykorzystujące AI.

Badacze wskazują również na wykorzystanie przejętych kanałów wideo, które publikowały krótkie materiały zachęcające użytkowników do pobrania zainfekowanych plików. Taki model dystrybucji pokazuje, że operatorzy kampanii łączą klasyczne techniki socjotechniczne z nowoczesnymi tematami przyciągającymi uwagę użytkowników.

Istotnym elementem operacji jest sposób działania głównego stealer’a. Po kradzieży danych malware raportuje wykonanie zadania do infrastruktury operatora i usuwa się z systemu, co może tworzyć mylne wrażenie krótkotrwałej infekcji.

Analiza techniczna

Analiza wykazała cztery moduły powiązane z REVSTEALER poprzez podobne techniki budowy, pakowania, dynamiczne rozwiązywanie funkcji systemowych oraz wykorzystanie zapasowej konfiguracji opartej o smart kontrakty w sieci Polygon. To sugeruje dobrze przemyślaną i rozwijaną architekturę kampanii.

ProManager koncentruje się na użytkownikach desktopowych portfeli kryptowalutowych. Moduł potrafi nakładać kontrolowane przez atakującego treści na legalne okna aplikacji portfelowych, tworząc skuteczną nakładkę phishingową. Dodatkowo przechwytuje dane wpisywane lub wklejane do pól haseł i fraz odzyskiwania, a trwałość uzyskuje przez wpis autostartu w rejestrze.

WinUpdate monitoruje schowek systemowy i podmienia skopiowane adresy kryptowalut na adres należący do operatora kampanii. Oprócz tego zbiera ciągi tekstowe przypominające seed phrase portfela. Do utrzymania obecności wykorzystuje zaplanowane zadanie, a w wariancie zapasowym również wpis Run w rejestrze.

SoftManager przekształca zainfekowany system w reverse proxy. W praktyce pozwala to przekierowywać ruch atakującego przez urządzenie ofiary, co może służyć do maskowania aktywności, obchodzenia ograniczeń geograficznych albo prowadzenia dalszych operacji z wykorzystaniem cudzego łącza. Moduł korzysta z kilku mechanizmów trwałości, w tym skryptów logowania, zadań harmonogramu i autostartu w rejestrze.

LockAppHost to najbardziej destrukcyjny komponent. Po uzyskaniu podwyższonych uprawnień wyłącza mechanizmy ochronne Windows, dodaje wykluczenia do Microsoft Defendera i dezaktywuje elementy odpowiedzialne za aktualizacje systemu. Następnie uruchamia koparkę kryptowalut, maskując ją pod legalnie wyglądającymi procesami systemowymi. Według ustaleń badaczy moduł wyłącza pięć usług Windows Update, jedenaście zaplanowanych zadań aktualizacyjnych oraz dwa zadania powiązane z narzędziem usuwania złośliwego oprogramowania.

Sam główny komponent REVSTEALER kradnie bardzo szeroki zestaw danych. Obejmuje to hasła i ciasteczka przeglądarek, pliki ponad 50 portfeli kryptowalutowych, dane komunikatorów, konfiguracje VPN i FTP, poświadczenia z Windows Credential Manager, dokumenty oraz informacje z menedżerów haseł. W niektórych przypadkach malware przechwytuje również sesje platform gamingowych.

Na uwagę zasługują także techniki obchodzenia zabezpieczeń i utrudniania analizy. REVSTEALER wykonuje testy środowiska sandbox, korzysta z pośrednich wywołań systemowych, unika klasycznej tablicy importów i kończy działanie na systemach skonfigurowanych w określonych językach używanych w Rosji i Azji Centralnej. Gdy podstawowy serwer C2 staje się niedostępny, zagrożenie może pobrać zapasową konfigurację z kontraktu smart contract, zwiększając odporność infrastruktury na zakłócenia.

Konsekwencje / ryzyko

Zagrożenie związane z REVSTEALER ma charakter wielowarstwowy. Pierwszą konsekwencją jest utrata tożsamości cyfrowej użytkownika lub pracownika, ponieważ przejęcie haseł, sesji i tokenów może umożliwić dostęp do kont bez znajomości hasła.

Drugą warstwą ryzyka jest kompromitacja finansowa. Kradzież plików portfeli, fraz odzyskiwania oraz podmiana adresów kryptowalut w schowku może prowadzić do bezpośredniej utraty środków. Szczególnie niebezpieczne są scenariusze, w których ofiara nie zauważa manipulacji i samodzielnie autoryzuje transfer do portfela przestępcy.

Trzeci obszar dotyczy nadużycia zasobów i infrastruktury. Urządzenie może zostać wykorzystane jako reverse proxy, a także jako host dla koparki kryptowalut. W środowisku firmowym oznacza to nie tylko spadek wydajności, ale również ryzyko wykorzystania infrastruktury organizacji do ukrywania działań przestępczych.

Najpoważniejsze skutki niesie moduł LockAppHost. Wyłączenie Windows Update oraz osłabienie Microsoft Defendera zwiększa podatność systemu na kolejne infekcje, utrudnia detekcję i opóźnia wdrażanie poprawek bezpieczeństwa. Nawet jeśli sam minera zostanie usunięty, zmiany obniżające poziom ochrony mogą utrzymywać się znacznie dłużej.

Rekomendacje

Infekcję REVSTEALER należy traktować jako incydent obejmujący zarówno kradzież danych, jak i możliwość utrzymania trwałych komponentów w systemie. Samo usunięcie jednego pliku malware nie powinno być uznawane za wystarczające działanie naprawcze.

zweryfikować wpisy autostartu w rejestrze, zadania harmonogramu, usługi i skrypty logowania;
sprawdzić stan usług Windows Update i przywrócić ich prawidłową konfigurację;
przejrzeć wyjątki dodane do Microsoft Defendera i usunąć nieautoryzowane wykluczenia;
poszukiwać oznak działania koparki oraz nietypowych procesów systemowych;
unieważnić aktywne sesje użytkowników i przeprowadzić reset haseł oraz rotację poświadczeń;
monitorować schowek i aktywność związaną z portfelami kryptowalutowymi;
wdrożyć reguły detekcyjne YARA oraz rozszerzyć telemetrię EDR;
ograniczyć pobieranie oprogramowania wyłącznie do oficjalnych źródeł;
podnieść świadomość użytkowników w zakresie fałszywych aplikacji, przejętych kanałów promocyjnych i socjotechniki.

W środowiskach korporacyjnych warto dodatkowo przeprowadzić threat hunting pod kątem eksfiltracji danych z przeglądarek, dostępu do pamięci procesów Chrome, nietypowego użycia narzędzi systemowych oraz nagłych zmian w harmonogramie zadań i ustawieniach Defendera.

Podsumowanie

REVSTEALER ewoluuje z klasycznego stealer’a w bardziej rozbudowany zestaw narzędzi łączący kradzież danych, trwałość, nadużycie infrastruktury i kryptomining. Najgroźniejszym elementem kampanii jest to, że po pozornym zakończeniu infekcji system może nadal pozostawać aktywnie wykorzystywany przez atakujących.

Dla zespołów bezpieczeństwa oznacza to konieczność pełnej rekonstrukcji zmian na zainfekowanym hoście oraz kompleksowego resetu zaufania do urządzenia. W praktyce skuteczna reakcja wymaga nie tylko usunięcia malware, ale również odbudowy mechanizmów ochronnych i ponownej oceny ryzyka dla kont, danych i infrastruktury.

Źródła

The Hacker News — https://thehackernews.com/2026/09/four-revstealer-linked-modules-disable.html
Elastic Security Labs, technical white paper referenced in the report — https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6c3d1c73c7f4f6b5/REVSTEALER_White_Paper.pdf
Morphisec analysis of fake Claude-themed malware delivery — https://www.morphisec.com/blog/fake-claude-opus-5-free-desktop-app-delivers-malware/
GitHub YARA rules referenced by researchers — https://github.com/elastic/protections-artifacts

CISA dodaje aktywnie wykorzystywaną lukę Google Chromium V8 do katalogu KEV

Wprowadzenie do problemu / definicja

Agencja CISA dopisała podatność CVE-2026-85046 do katalogu Known Exploited Vulnerabilities, co oznacza, że luka jest nie tylko publicznie znana, ale również wykorzystywana w rzeczywistych atakach. Problem dotyczy silnika V8 w Google Chromium, który odpowiada za wykonywanie kodu JavaScript i WebAssembly w przeglądarkach opartych na Chromium.

Z punktu widzenia bezpieczeństwa to szczególnie istotna kategoria błędów, ponieważ luki w V8 mogą prowadzić do zdalnego wykonania kodu po otwarciu złośliwie przygotowanej strony internetowej. W praktyce oznacza to, że przeglądarka ponownie pozostaje jednym z najbardziej atrakcyjnych wektorów wejścia dla cyberprzestępców.

W skrócie

CVE-2026-85046 to luka typu type confusion w silniku V8, oceniona na 8,8 w skali CVSS. Google potwierdziło, że exploit dla tej podatności był wykorzystywany w środowisku produkcyjnym, a poprawki trafiły do wersji Chrome 152.0.7977.82/.83 dla Windows i macOS oraz 152.0.7977.82 dla Linuksa.

Następnie CISA dodała podatność do katalogu KEV i wyznaczyła termin usunięcia jej z federalnych środowisk do 18 września 2026 roku. Dla sektora prywatnego to wyraźny sygnał, że aktualizacja przeglądarek powinna zostać potraktowana priorytetowo.

Kontekst / historia

Katalog KEV prowadzony przez CISA obejmuje podatności, dla których istnieją wiarygodne dowody aktywnego wykorzystania. Umieszczenie luki w tym zestawieniu zwykle zwiększa presję na zespoły SOC, administratorów stacji roboczych i dostawców usług bezpieczeństwa, ponieważ oznacza podwyższone ryzyko operacyjne.

W przypadku CVE-2026-85046 mowa o kolejnej luce zero-day w ekosystemie Chrome w 2026 roku. To potwierdza, że przeglądarki internetowe nadal są jednym z najważniejszych celów ataków, zwłaszcza w kampaniach phishingowych, drive-by download oraz operacjach ukierunkowanych na konkretne organizacje.

W wielu scenariuszach użytkownik nie musi nawet pobierać dodatkowego pliku. Samo wejście na odpowiednio spreparowaną stronę może wystarczyć do uruchomienia łańcucha eksploatacji.

Analiza techniczna

Podatność została sklasyfikowana jako type confusion w V8. Taki błąd pojawia się wtedy, gdy silnik nieprawidłowo interpretuje typ lub strukturę obiektu w pamięci, co może prowadzić do naruszenia integralności danych i przygotowania warunków do dalszej eksploatacji.

W środowisku przeglądarkowym type confusion często staje się punktem wyjścia do uzyskania arbitralnych odczytów i zapisów w pamięci procesu. To z kolei może umożliwić wykonanie kodu w kontekście procesu renderera działającego wewnątrz sandboxa.

Z dostępnych informacji wynika, że luka dotyczyła mechanizmów kompilacyjnych V8 i mogła prowadzić do nieprawidłowego mapowania struktur tablic w pamięci. Taki stan może zostać wykorzystany do budowy prymitywów pamięciowych przydatnych podczas tworzenia exploita oraz przejęcia kontroli nad procesem przeglądarki.

Choć samo wykonanie kodu odbywa się zazwyczaj w obrębie sandboxa, w realnych kampaniach atakujący często łączą tego typu błędy z dodatkowymi lukami eskalacji uprawnień lub ucieczki z izolacji. Ograniczenie szczegółów technicznych przez Google należy więc traktować jako standardową praktykę mającą utrudnić szybkie odtworzenie skutecznego exploita.

Konsekwencje / ryzyko

Najważniejszym ryzykiem jest możliwość zdalnej kompromitacji przeglądarki po odwiedzeniu złośliwej strony HTML. Taki scenariusz stanowi zagrożenie dla stacji roboczych użytkowników końcowych, środowisk VDI, systemów administracyjnych i urządzeń, na których wykorzystywane są przeglądarki bazujące na Chromium.

Dla organizacji skutki mogą obejmować kradzież sesji, przejęcie danych uwierzytelniających, uruchomienie złośliwego kodu w kontekście użytkownika, instalację loaderów lub infostealerów, a także wykorzystanie przeglądarki jako punktu wejścia do dalszego ruchu bocznego.

Ryzyko jest szczególnie wysokie tam, gdzie aktualizacje przeglądarek wdrażane są z opóźnieniem, użytkownicy posiadają szerokie uprawnienia lokalne, a monitoring ruchu internetowego i telemetria endpointów pozostają ograniczone. Potwierdzona eksploatacja in the wild zmienia priorytet tej luki z ważnej poprawki bezpieczeństwa na zagrożenie wymagające natychmiastowej reakcji.

Rekomendacje

Organizacje powinny niezwłocznie zaktualizować Chrome oraz wszystkie przeglądarki i komponenty oparte na Chromium do wersji zawierających poprawkę. Warto przy tym zweryfikować nie tylko standardowe instalacje desktopowe, ale również obrazy VDI, golden images, kioski, hosty administracyjne oraz systemy wykorzystujące osadzone komponenty Chromium.

wymusić aktualizację do naprawionych wersji na wszystkich zarządzanych endpointach,
zidentyfikować aplikacje korzystające z osadzonych komponentów Chromium,
monitorować logi EDR/XDR pod kątem nietypowych zachowań procesów przeglądarki,
zwiększyć detekcję prób uruchamiania payloadów z pamięci przez procesy przeglądarkowe,
ograniczyć uprawnienia lokalne użytkowników i utrzymywać segmentację stacji roboczych,
stosować polityki ograniczające uruchamianie nieautoryzowanego kodu po stronie użytkownika,
przeprowadzić szybki przegląd ekspozycji na kampanie phishingowe i złośliwe reklamy.

Dodatkowo zespoły bezpieczeństwa powinny traktować wpis w katalogu KEV jako sygnał do przyspieszonego patch managementu. W środowiskach o podwyższonym profilu ryzyka uzasadnione może być także czasowe zaostrzenie izolacji przeglądarek, monitoringu DNS i HTTP oraz analizy zachowań procesów potomnych uruchamianych przez aplikacje przeglądarkowe.

Podsumowanie

CVE-2026-85046 to poważna luka typu type confusion w silniku V8, która została potwierdzona jako aktywnie wykorzystywana i trafiła do katalogu KEV prowadzonego przez CISA. Jej znaczenie wynika nie tylko z wysokiej oceny CVSS, ale przede wszystkim z realnej eksploatacji w środowisku produkcyjnym.

Dla organizacji oznacza to konieczność natychmiastowej aktualizacji przeglądarek Chromium-based, weryfikacji ekspozycji oraz wzmocnienia monitoringu endpointów. W 2026 roku przeglądarka pozostaje jednym z kluczowych celów ataków, dlatego tempo wdrażania poprawek ma bezpośredni wpływ na poziom ryzyka.

Źródła

Security Affairs — https://securityaffairs.com/198455/security/u-s-cisa-adds-google-chromium-v8-flaw-to-its-known-exploited-vulnerabilities-catalog-2.html
Chrome Releases — Stable Channel Update for Desktop — https://chromereleases.googleblog.com/
CVE Record: CVE-2026-85046 — https://www.cve.org/CVERecord?id=CVE-2026-85046
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Ponad 5,4 tys. zhakowanych stron rozprowadza ClickFix z ładunkami ukrytymi w blockchainie

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili szeroko zakrojoną kampanię, w której przestępcy wykorzystują skompromitowane strony internetowe do dystrybucji złośliwych ładunków metodą ClickFix. Szczególnie niepokojący jest fakt, że kolejne etapy infekcji oraz konfiguracja ataku są przechowywane w smart kontraktach blockchaina, co utrudnia ich szybkie zablokowanie i wyłączenie całej infrastruktury.

Takie podejście, określane jako EtherHiding, pokazuje rosnący trend nadużywania technologii zdecentralizowanych w operacjach cyberprzestępczych. Zamiast tradycyjnych serwerów C2 atakujący korzystają z publicznie dostępnej infrastruktury blockchain, dzięki czemu ich kampanie stają się bardziej elastyczne i odporne na działania obrońców.

W skrócie

W kampanii zidentyfikowano ponad 5400 zhakowanych stron internetowych.
Ofiarami kompromitacji były głównie witryny oparte na WordPressie i PrestaShop.
Atak wykorzystuje fałszywe ekrany CAPTCHA i technikę ClickFix, skłaniając użytkownika do uruchomienia polecenia PowerShell.
Kolejne etapy infekcji są pobierane z infrastruktury opartej o BNB Smart Chain Testnet.
Nowszy wariant kampanii wykorzystuje stager WebRTC, który umożliwia ukryte dostarczanie kodu bez zapisu na dysk.

Kontekst / historia

ClickFix to technika socjotechniczna, w której użytkownik zostaje przekonany do samodzielnego uruchomienia złośliwego polecenia pod pretekstem rozwiązania problemu technicznego, przejścia weryfikacji CAPTCHA lub naprawy błędu przeglądarki. Z punktu widzenia obrony jest to skuteczny model ataku, ponieważ część szkodliwego działania wykonuje sama ofiara.

W analizowanej operacji atakujący połączyli ClickFix z architekturą EtherHiding. Oznacza to, że zainfekowana witryna pełni jedynie rolę pośrednika, natomiast właściwy kod lub konfiguracja są pobierane z blockchaina. Taka konstrukcja pozwala operatorom łatwo aktualizować payloady bez konieczności ponownego modyfikowania każdej przejętej strony, a jednocześnie znacząco utrudnia blokowanie całej kampanii.

Analiza techniczna

Początkowy wektor kompromitacji stron nie został jednoznacznie ustalony. Po przejęciu witryny operatorzy osadzają w niej złośliwy skrypt albo zmodyfikowany komponent, który wykonuje zapytania JSON-RPC do endpointów BSC Testnet i pobiera kolejny etap ataku. W praktyce blockchain staje się odpornym repozytorium dla danych operacyjnych malware.

W klasycznym wariancie użytkownik odwiedzający zainfekowaną stronę widzi fałszywy ekran CAPTCHA lub komunikat sugerujący konieczność wykonania czynności naprawczej. Instrukcja prowadzi ofiarę do otwarcia okna „Uruchamianie” w systemie Windows i wklejenia komendy PowerShell. Po jej wykonaniu następuje pobranie i uruchomienie końcowego ładunku, który może zostać dynamicznie zmieniony po stronie smart kontraktu.

Nowsza odsłona kampanii odchodzi częściowo od klasycznego ClickFix i wykorzystuje stager oparty o WebRTC. Mechanizm zestawia ukryty kanał komunikacji peer-to-peer, a kod JavaScript jest odbierany i wykonywany bezpośrednio w pamięci przeglądarki, z użyciem dynamicznego wstrzykiwania do DOM. Taki model ogranicza artefakty plikowe, przez co utrudnia detekcję rozwiązaniom skupionym głównie na aktywności dyskowej.

Dla zespołów bezpieczeństwa problemem jest również sama natura tej infrastruktury. Zamiast pojedynczego serwera do przejęcia lub zablokowania obrońcy mają do czynienia z publicznymi endpointami RPC oraz logiką osadzoną w smart kontraktach. To wymaga rozszerzenia klasycznych procedur reagowania o monitorowanie połączeń do sieci blockchain i nietypowej aktywności WebRTC.

Konsekwencje / ryzyko

Skala operacji oznacza istotne ryzyko zarówno dla właścicieli stron, jak i dla użytkowników końcowych. Dla administratorów zhakowanych serwisów skutki obejmują utratę reputacji, możliwość dodania domen do list blokad, spadek widoczności w wyszukiwarkach oraz wykorzystanie ich środowisk do dalszej dystrybucji malware.

Dla odwiedzających główne zagrożenie stanowi uruchomienie złośliwego polecenia we własnym systemie. W zależności od dostarczonego ładunku końcowego może to prowadzić do kradzieży danych uwierzytelniających, instalacji infostealerów, uzyskania zdalnego dostępu lub przygotowania gruntu pod kolejne etapy kompromitacji.

Ryzyko operacyjne dodatkowo zwiększa możliwość szybkiej zmiany payloadu. Jeśli obrońcy przygotują sygnatury dla jednego wariantu, operatorzy mogą w krótkim czasie podmienić stager, rodzinę malware albo sposób komunikacji, podnosząc koszty wykrywania i reagowania po stronie SOC.

Rekomendacje

Organizacje powinny traktować tę kampanię jako połączenie kompromitacji aplikacji webowych, socjotechniki i nowoczesnej infrastruktury C2. Skuteczna obrona wymaga działań wielowarstwowych.

Regularnie aktualizować WordPress, PrestaShop oraz wszystkie wtyczki, moduły i motywy.
Monitorować integralność plików i analizować logi pod kątem nieautoryzowanych zmian w skryptach JavaScript.
Ograniczać możliwość uruchamiania PowerShell i interpreterów skryptowych tam, gdzie nie są potrzebne biznesowo.
Wdrożyć application control, rejestrowanie poleceń PowerShell oraz alertowanie na nietypowe relacje parent-child process między przeglądarką a interpreterami.
Filtrować lub blokować endpointy BSC Testnet RPC, jeśli organizacja nie korzysta z nich operacyjnie.
Monitorować nietypowy ruch UDP i użycie WebRTC poza standardowymi scenariuszami komunikacyjnymi.
Szkolić użytkowników, że prawidłowe strony internetowe nie wymagają kopiowania poleceń do okna „Uruchamianie” w celu przejścia CAPTCHA lub naprawy błędu.

Podsumowanie

Opisana kampania pokazuje, że współczesne operacje malware coraz częściej łączą kompromitację popularnych CMS-ów, skuteczną socjotechnikę i odporną na zakłócenia infrastrukturę opartą o blockchain. Ponad 5,4 tys. przejętych stron i aktywność setek z nich każdego dnia wskazują na dobrze zautomatyzowaną oraz elastyczną operację.

Najważniejszy wniosek dla obrońców jest jasny: tradycyjne zabezpieczenia webowe i endpointowe nie wystarczą, jeśli organizacja nie monitoruje także nadużyć związanych z blockchain RPC, wykonywaniem poleceń przez użytkowników oraz pamięciowym uruchamianiem kodu w przeglądarce.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/over-5-400-hacked-sites-serve-clickfix-payloads-stored-on-the-blockchain/
Netskope — Malware on the Blockchain: An Ongoing Campaign’s New WebRTC Twist — https://www.netskope.com/fr/blog/malware-on-the-blockchain-an-ongoing-campaigns-new-webrtc-twist
HHS Sector Alert — ClickFix Attacks Sector Alert — https://www.hhs.gov/sites/default/files/clickfix-attacks-sector-alert-tlpclear.pdf

Ataki na PaperCut uderzają w szkoły i uczelnie. Cyberprzestępcy kradną poświadczenia przez nowe luki

Wprowadzenie do problemu / definicja

PaperCut to popularne oprogramowanie do zarządzania drukiem, wykorzystywane w szkołach, na uczelniach oraz w wielu innych organizacjach. Najnowsze incydenty pokazują jednak, że tego typu systemy mogą stać się atrakcyjnym punktem wejścia do infrastruktury, zwłaszcza gdy są zintegrowane z usługami katalogowymi i wystawione na ataki z zewnątrz.

W opisywanej kampanii napastnicy wykorzystują świeżo ujawnione podatności w PaperCut, aby przejąć kontrolę nad serwerami, a następnie zdobywać poświadczenia i informacje pozwalające na dalszą eskalację uprawnień. Szczególnie zagrożony jest sektor edukacyjny, gdzie liczba użytkowników, rozproszenie środowiska i ograniczone zasoby bezpieczeństwa zwiększają powierzchnię ataku.

W skrócie

Ataki koncentrują się na podatnych serwerach PaperCut działających w szkołach i na uniwersytetach w Stanach Zjednoczonych oraz Europie. Łańcuch ataku obejmuje obejście uwierzytelniania i zdalne wykonanie kodu, co pozwala napastnikom uzyskać dostęp bez znajomości poprawnych danych logowania.

celem kampanii jest przede wszystkim kradzież poświadczeń,
atakujący prowadzą rozpoznanie przejętego systemu,
tworzone są uprzywilejowane konta dla utrzymania dostępu,
napastnicy próbują pozyskać dane z rejestru Windows i plików konfiguracyjnych,
kompromitacja jednego serwera może prowadzić do dalszego ruchu bocznego w sieci.

Kontekst / historia

Systemy zarządzania drukiem od dawna należą do grupy aplikacji, które bywają niedoceniane z perspektywy bezpieczeństwa, mimo że często są silnie powiązane z infrastrukturą tożsamości organizacji. PaperCut jest wdrażany szeroko, a jego integracje z LDAP, Active Directory czy mechanizmami jednokrotnego logowania powodują, że przejęcie takiego serwera może otworzyć drogę do kolejnych zasobów.

W środowiskach edukacyjnych ryzyko jest jeszcze większe. Uczelnie i szkoły obsługują dużą liczbę kont, urządzeń i usług, a jednocześnie nie zawsze dysponują wystarczającymi zasobami do ciągłego monitorowania wszystkich komponentów. To sprawia, że aplikacje brzegowe, takie jak serwery wydruku, są kuszącym celem dla przestępców.

Opisywana aktywność wpisuje się w znany schemat ataków na usługi dostępne z sieci. W tym przypadku wykorzystano podatności oznaczone jako CVE-2026-81578 oraz CVE-2026-82078, które razem umożliwiają uzyskanie nieautoryzowanego dostępu i wykonanie dowolnych poleceń na podatnym systemie.

Analiza techniczna

Z dostępnych informacji wynika, że napastnicy łączą dwie luki w jeden skuteczny łańcuch ataku. Pierwsza pozwala ominąć mechanizmy uwierzytelniania, a druga doprowadza do zdalnego wykonania kodu. W praktyce oznacza to możliwość przejęcia serwera bez konieczności logowania się legalnym kontem.

Po uzyskaniu dostępu atakujący uruchamiają zestaw poleceń rozpoznawczych, aby ocenić wartość przejętego hosta i możliwości dalszych działań. Obejmują one identyfikację użytkownika, wersji systemu, uruchomionych procesów i podstawowych parametrów środowiska. Taki etap post-exploitation jest typowy dla ukierunkowanych włamań i służy przygotowaniu kolejnych kroków.

Następnie obserwowane było tworzenie uprzywilejowanych kont, co sugeruje próbę utrzymania trwałego dostępu. Równolegle napastnicy pobierali narzędzia służące do zbierania danych z rejestru Windows, w tym artefaktów potrzebnych do rekonstrukcji BootKey oraz uzyskania dostępu do bazy SAM. Taki zestaw technik może prowadzić do pozyskania skrótów haseł lub innych informacji przydatnych w eskalacji uprawnień.

Ważnym elementem kampanii było także przeszukiwanie plików konfiguracyjnych PaperCut pod kątem wpisów związanych z hasłami, sekretami, integracją LDAP i tokenami. To szczególnie groźne, ponieważ dane aplikacyjne zapisane lokalnie mogą umożliwić dostęp do kolejnych systemów zaplecza, kont serwisowych lub usług katalogowych.

W analizowanej aktywności odnotowano również wykorzystanie ładunków powiązanych z Meterpreterem oraz komunikację z infrastrukturą kontrolowaną przez napastników. Sugeruje to, że ataki nie miały charakteru jednorazowego, lecz stanowiły część pełnego łańcucha włamania obejmującego dostarczenie narzędzi, utrzymanie dostępu i przygotowanie gruntu pod dalszą kompromitację.

Konsekwencje / ryzyko

Największym zagrożeniem jest utrata poświadczeń, które mogą umożliwić dostęp do kolejnych krytycznych systemów organizacji. W środowisku edukacyjnym może to oznaczać ryzyko przejęcia kont administracyjnych, systemów katalogowych, portali dla studentów i pracowników, danych kadrowych czy zasobów laboratoryjnych.

Ryzyko rośnie z uwagi na fakt, że PaperCut bywa zintegrowany z centralnymi mechanizmami tożsamości. Jeśli atakującym uda się zdobyć hasła, sekrety LDAP, tokeny lub lokalne skróty haseł, mogą oni poruszać się pomiędzy segmentami sieci, eskalować uprawnienia i utrzymywać trwały dostęp nawet po usunięciu pierwotnej podatności.

Dodatkowym problemem jest możliwość długotrwałego, niezauważonego działania. Komendy rozpoznawcze, przeszukiwanie plików konfiguracyjnych czy wykorzystanie narzędzi systemowych do pobierania plików nie zawsze są natychmiast wykrywane, zwłaszcza w słabiej monitorowanych środowiskach. W rezultacie kompromitacja pojedynczego serwera może być jedynie początkiem większego incydentu.

Rekomendacje

Organizacje korzystające z PaperCut powinny jak najszybciej zinwentaryzować wszystkie instancje produktu i ustalić, które z nich są dostępne z internetu. Ograniczenie ekspozycji paneli administracyjnych i usług brzegowych powinno być traktowane jako priorytet.

Niezbędne jest również niezwłoczne wdrożenie poprawek bezpieczeństwa udostępnionych przez producenta. Samo załatanie systemu nie rozwiązuje jednak problemu, jeśli atakujący zdążyli już uzyskać dostęp, utworzyć dodatkowe konta lub wyeksportować dane uwierzytelniające.

monitorować uruchamianie cmd.exe, powershell.exe i innych interpreterów przez procesy powiązane z PaperCut,
analizować komendy rozpoznawcze, takie jak whoami, tasklist, ver czy uname,
wykrywać użycie certutil do pobierania plików,
sprawdzać nietypowe tworzenie nowych kont uprzywilejowanych,
kontrolować dostęp do plików konfiguracyjnych zawierających sekrety i ustawienia LDAP,
szukać oznak zrzutu rejestru, dostępu do SAM i prób pozyskania BootKey.

Po stronie reagowania warto przeprowadzić pełny przegląd integralności serwera, rotację poświadczeń powiązanych z PaperCut, kont serwisowych i danych integracyjnych, a także analizę logów pod kątem komunikacji z podejrzaną infrastrukturą. Jeśli incydent zostanie potwierdzony, należy założyć możliwość naruszenia większej części środowiska.

Długofalowo pomocne będą segmentacja sieci, ograniczenie uprawnień kont serwisowych, wdrożenie MFA tam, gdzie jest to możliwe, oraz przechowywanie sekretów aplikacyjnych poza lokalnymi plikami konfiguracyjnymi, jeśli architektura organizacji na to pozwala.

Podsumowanie

Kampania wymierzona w serwery PaperCut pokazuje, że nawet pozornie pomocnicze systemy mogą stać się krytycznym punktem wejścia do infrastruktury. W tym przypadku celem atakujących nie było wyłącznie przejęcie pojedynczego serwera wydruku, lecz zdobycie poświadczeń, danych konfiguracyjnych i możliwości dalszego ruchu bocznego.

Dla szkół i uczelni to wyraźny sygnał, że bezpieczeństwo systemów zarządzania drukiem powinno być traktowane na równi z innymi ważnymi komponentami środowiska IT. Kluczowe znaczenie mają szybkie łatanie, ograniczanie ekspozycji usług oraz aktywne monitorowanie oznak post-exploitation.

Źródła

https://thehackernews.com/2026/09/attackers-exploit-papercut-flaws-to.html