SCKit i ScreenConnect: malware typu worm atakuje MSP przez sesje zdalnego wsparcia - Security Bez Tabu

SCKit i ScreenConnect: malware typu worm atakuje MSP przez sesje zdalnego wsparcia

Cybersecurity news

Wprowadzenie do problemu / definicja

SCKit to zestaw złośliwych komponentów wykorzystywanych w kampanii wymierzonej w dostawców usług zarządzanych (MSP) korzystających ze ScreenConnect. Istota zagrożenia polega na odwróceniu klasycznego modelu zdalnego wsparcia: zamiast ograniczać się do utrzymania dostępu do endpointu klienta, atakujący próbują wykorzystać aktywną sesję pomocy technicznej do przejęcia stacji roboczej technika.

Taki scenariusz znacząco zwiększa ryzyko ataku łańcuchowego. Jeśli kompromitacji ulegnie stanowisko operatora MSP, zagrożenie może objąć wiele środowisk klientów zarządzanych z jednego panelu administracyjnego.

W skrócie

W listopadzie 2026 roku ujawniono kampanię nadużywającą środowisk ScreenConnect hostowanych w chmurze do wdrażania nieautoryzowanych klientów zdalnego dostępu. Według ustaleń badaczy atakujący wykorzystywali podatny komponent RMM+ oraz mechanizmy zdalnego wykonywania poleceń bez standardowej ścieżki logowania operatora.

W dalszym etapie użyto zestawu SCKit, którego zadaniem było utrwalenie dostępu, kradzież ciasteczek uwierzytelniających i próba infekcji stanowisk techników MSP poprzez sesje ScreenConnect. Chociaż kod i logika działania wskazują na model przypominający worm, badacze nie potwierdzili skutecznego domknięcia pełnego łańcucha infekcji na poprawnie zaktualizowanych klientach.

Kontekst / historia

Incydent wpisuje się w rosnący trend nadużywania legalnych narzędzi RMM i platform zdalnego wsparcia jako nośników ataku. W omawianej kampanii wstępny wektor miał być związany z rozszerzeniem RMM+ dla ScreenConnect.

Wersje 1.0.31 i 1.0.32 miały zawierać błąd uwierzytelniania umożliwiający akceptację pustego klucza dostępowego, jeśli administrator wcześniej go nie skonfigurował. W praktyce mogło to pozwolić na zdalne wydawanie poleceń bez pełnego uwierzytelnienia do konsoli i bez przechodzenia przez MFA.

Z ustaleń badaczy wynika, że kampania objęła co najmniej dziesiątki organizacji i setki endpointów, a aktywność rozwijała się bardzo szybko. Dodatkowo wcześniejsza podatność po stronie klienta ScreenConnect, oznaczona jako CVE-2026-84869, została wcześniej załatana w wersji 26.6.5, co miało istotne znaczenie dla ograniczenia skuteczności późniejszej fazy ataku.

Analiza techniczna

SCKit nie jest pojedynczym plikiem malware, lecz zestawem skryptów i komponentów realizujących różne etapy operacji. Pierwszym celem jest ustanowienie trwałego dostępu przez instalację dodatkowych klientów ScreenConnect Access skonfigurowanych do łączenia się z infrastrukturą kontrolowaną przez napastników.

Jednym z najciekawszych elementów technicznych jest komponent określany jako RelayTrap. Jego zadaniem jest podmiana legalnego procesu ScreenConnect Guest na zainfekowanym urządzeniu i oczekiwanie na połączenie przychodzące od technika MSP. Zamiast standardowego scenariusza przesyłania plików do klienta, komponent próbuje odwrócić kierunek transferu i doprowadzić do uruchomienia ładunku na stacji operatora.

Mechanizm ten miał wykorzystywać CVE-2026-84869, czyli krytyczną lukę klienta związaną z transferem plików w aktywnej sesji. Drugim ważnym modułem jest TrapWatch, który monitoruje usługi ScreenConnect i przygotowuje środowisko do przechwycenia sesji wsparcia dokładnie w momencie zestawienia połączenia przez technika.

Badacze zwrócili również uwagę, że część kodu była dostarczana jako źródła C# i kompilowana lokalnie z użyciem PowerShell. Taki model utrudnia detekcję opartą wyłącznie o hashe binariów i pozwala atakującym dynamicznie zmieniać ładunek. Po potencjalnym uruchomieniu na stacji technika kolejne moduły próbują wykradać ciasteczka sesyjne ScreenConnect z przeglądarek, co może umożliwić przejęcie już uwierzytelnionej sesji operatora bez ponownego pozyskiwania hasła.

Następnie malware może enumerować dostępne endpointy i wykorzystywać natywne funkcje platformy, takie jak Shared Toolbox czy zdalne wykonywanie poleceń, do dalszej propagacji. Kluczowe jest jednak to, że analizy produkcyjne i laboratoryjne nie potwierdziły skutecznego wykorzystania pełnego łańcucha worm na poprawnie zaktualizowanych klientach.

Konsekwencje / ryzyko

Z punktu widzenia bezpieczeństwa MSP kampania jest wyjątkowo groźna, ponieważ uderza w model zaufania między dostawcą usług a wieloma klientami. Kompromitacja jednego endpointu klienta może stać się punktem wejścia do stacji roboczej technika, a następnie do kolejnych organizacji.

Praktyczne skutki takiego incydentu mogą obejmować:

  • nieautoryzowaną instalację dodatkowych agentów zdalnego dostępu,
  • przejęcie sesji operatorów MSP,
  • rozprzestrzenianie poleceń przez legalne funkcje administracyjne,
  • utratę poufności danych na wielu zarządzanych hostach,
  • zakłócenie działania usług IT u klientów końcowych,
  • utrudnioną detekcję ze względu na nadużywanie prawidłowych narzędzi administracyjnych.

Dodatkowym problemem jest to, że aktywność atakujących może przypominać zwykłą obsługę zdalną. Organizacje, które koncentrują monitoring wyłącznie na klasycznych wskaźnikach malware, mogą nie zauważyć incydentu przez dłuższy czas.

Rekomendacje

Organizacje korzystające ze ScreenConnect, a w szczególności MSP, powinny potraktować ten przypadek jako sygnał do pilnej weryfikacji bezpieczeństwa całego łańcucha zdalnego wsparcia.

  • zaktualizować klientów i komponenty ScreenConnect do wersji zawierających poprawki bezpieczeństwa, w tym co najmniej 26.6.5 tam, gdzie dotyczy to CVE-2026-84869,
  • wyłączyć i zweryfikować wszystkie podatne lub zbędne rozszerzenia firm trzecich, zwłaszcza RMM+ w wersjach 1.0.31 i 1.0.32,
  • przeanalizować historię Run Command, Shared Toolbox i zdarzenia związane z niestandardowym wykonywaniem skryptów,
  • szukać śladów nieautoryzowanych instalacji klientów ScreenConnect Access na endpointach,
  • sprawdzić, czy na hostach nie pojawiły się nietypowe skrypty VBS, PowerShell i zadania harmonogramu związane z utrwaleniem dostępu,
  • unikać interaktywnych sesji ScreenConnect z podejrzanymi hostami do czasu ich odseparowania i zweryfikowania innymi narzędziami,
  • objąć monitoringiem stacje robocze techników MSP jako zasoby o podwyższonym znaczeniu krytycznym,
  • wymusić rotację sesji, wylogowanie operatorów i przegląd artefaktów przeglądarkowych w razie podejrzenia kradzieży cookies,
  • wdrożyć segmentację operacyjną między środowiskami klientów i ograniczać uprawnienia zgodnie z zasadą least privilege,
  • przygotować dedykowane playbooki reagowania na incydenty związane z nadużyciem legalnych narzędzi RMM.

Podsumowanie

SCKit pokazuje wyraźną ewolucję zagrożeń wymierzonych w ekosystem MSP. Celem atakujących nie jest już wyłącznie pojedynczy host klienta, ale cały mechanizm zdalnego wsparcia oraz relacja zaufania między technikiem a zarządzanymi środowiskami.

Kampania wykorzystująca ScreenConnect łączyła nadużycie rozszerzenia RMM+, instalację nieautoryzowanych klientów zdalnego dostępu oraz próbę przejęcia sesji techników przez mechanikę przypominającą worm. Nawet jeśli pełny łańcuch nie został potwierdzony na poprawnie załatanych klientach, sam model ataku stanowi ważne ostrzeżenie dla branży i pokazuje, że platformy zdalnego wsparcia należy traktować jak systemy krytyczne.

Źródła