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.exei PowerShell z katalogów tymczasowych oraz nietypowych ścieżek wAppDataiPublic. - Monitorować tworzenie plików takich jak
1.vbs,2.vbs,3.vbs,4.vbs,value.txt,map.txt,out.enc,runner.ps1iPyTorchFix.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/