ScreenConnect: atakujący wdrażają nieautoryzowane klienty i malware SCKit na 288 zarządzanych punktach końcowych

Co się wydarzyło

12 listopada 2026 roku ConnectWise wyłączyło pięć rozszerzeń ScreenConnect firm trzecich w środowiskach partnerów. Była to środek ostrożności po zgłoszeniach dotyczących nieautoryzowanego dostępu. ConnectWise twierdzi, że nie stwierdziło żadnej podatności w oprogramowaniu ScreenConnect ani naruszenia własnej infrastruktury. Wstępna ocena firmy wskazuje, że podmiot zagrożenia może wykorzystywać niezależne rozszerzenia firm trzecich zainstalowane w środowiskach partnerów. Sposób, w jaki atakujący uzyskali dostęp, oraz pełny zakres incydentu nadal są badane.

Huntress również śledzi tę aktywność, którą po raz pierwszy wykryło 11 listopada 2026 roku około godziny 17:47 UTC. Według Huntress atakujący wykorzystali dostęp do chmurowych paneli ScreenConnect, aby wysyłać polecenia Run. Polecenia te zainstalowały nieautoryzowane klienty ScreenConnect na co najmniej 288 zarządzanych punktach końcowych w 48 organizacjach. Huntress nie zaobserwowało dowodów na nową podatność. Obecne dane wskazują na skradzione poświadczenia lub przejęte sesje operatorów jako drogę dostępu.

Nieautoryzowane klienty dostarczają SCKit, autorski złośliwy zestaw narzędzi. Utrzymuje on zdalny dostęp nawet bez oryginalnego panelu. Dodaje także wyłączenia Microsoft Defender, instaluje drugiego klienta ScreenConnect kontrolowanego przez atakującego, tworzy zaplanowane zadanie o nazwie "TrapWatch" i może zastąpić legalną instalację ScreenConnect kopią kontrolowaną przez atakującego.

Huntress przeanalizowało ładunki i znalazło kod przeznaczony do dalszego rozprzestrzeniania. Gdy technik łączy się z zainfekowanym punktem końcowym, kod kradnie ciasteczko sesji .aspxauth ze stacji roboczej technika. Następnie używa go w innych panelach i wysyła ładunek do każdej osiągalnej sesji przez Shared Toolbox. Huntress przyznaje, że nie zaobserwowało jeszcze skutecznego rozprzestrzenienia. Firma Sophos niezależnie zgłosiła nieautoryzowane wdrożenia klientów ScreenConnect o tym samym schemacie.

Kogo to dotyczy

Dotyczy to organizacji korzystających z ConnectWise ScreenConnect do zarządzania punktami końcowymi i serwerami, przede wszystkim dostawców MSP i usług IT. Dotychczasowe ataki dotyczyły chmurowych paneli ScreenConnect. ConnectWise wykryło około 400 środowisk partnerów z co najmniej jednym z tych rozszerzeń:

• Labtech Plus
• RMM Plus
• RMM+
• RMM Plus Password Link
• RMM+ Password Link

Rozszerzenia te udostępniają interfejs API, który może uruchamiać zdalne polecenia. Dostęp do niego chroni hasło (passphrase), które partner ustawia podczas konfiguracji. ConnectWise podkreśla, że obecność jednego z tych rozszerzeń nie oznacza, że system został przejęty. Nie zidentyfikowano podatności w ScreenConnect, więc nie ma poprawki do zainstalowania. Huntress zauważyło, że atakujący numerują kolejne przejęte firmy MSP, a zaobserwowane numery zaczynają się od pewnego punktu. Inne firmy MSP mogły więc zostać zaatakowane wcześniej. Dlatego Huntress zaleca wszystkim użytkownikom ScreenConnect sprawdzenie historii poleceń Run Command, nawet jeśli nie otrzymali żadnych alertów.

Co zrobić teraz

1. Jeśli korzystasz z ScreenConnect lokalnie, wyłącz pięć wymienionych rozszerzeń, zgodnie z zaleceniem ConnectWise. Nie włączaj ich ponownie, dopóki ConnectWise nie potwierdzi ich bezpieczeństwa.
2. Sprawdź, czy mechanizmy bezpieczeństwa (EDR, antywirus) działają na stacjach roboczych techników i zarządzanych punktach końcowych. Sprawdź wyłączenia Microsoft Defender, których nikt z zespołu nie dodał.
3. Zabezpiecz logi audytu i sesji ScreenConnect oraz inne logi wskazujące na podejrzaną aktywność, zanim cokolwiek zmienisz.
4. Zresetuj hasła wszystkich operatorów ScreenConnect, zakończ aktywne sesje operatorów i upewnij się, że uwierzytelnianie wieloskładnikowe (MFA) jest włączone dla każdego konta. Zmień hasła (passphrase) interfejsów API rozszerzeń.
5. Przejrzyj konta administratorów i uprawnienia we wszystkich panelach. Usuń konta i uprawnienia, których nie potrafisz wyjaśnić.
6. Traktuj każdy punkt końcowy z nieautoryzowanym klientem ScreenConnect lub artefaktami SCKit jako przejęty. Odizoluj go i przeprowadź analizę. Oczyść go lub odbuduj, zanim ponownie mu zaufasz. Sprawdź także stacje robocze techników, którzy łączyli się z tym punktem.

Jak sprawdzić, czy doszło do ataku

• Przejrzyj historię poleceń Run Command w panelach ScreenConnect pod kątem poleceń, których nikt z zespołu nie uruchamiał, szczególnie od 11 listopada 2026 roku. Szukaj także nieoczekiwanych instalacji rozszerzeń, aktywności Toolbox i elementów Shared Toolbox.
• Szukaj logowań z nietypowych lokalizacji, powtarzających się nieudanych prób logowania, nieoczekiwanych próśb MFA, nowych kont administratorów i zmian uprawnień.
• Na punktach końcowych szukaj klientów ScreenConnect, które nie należą do Twojej instancji, oraz innego oprogramowania do zdalnego dostępu, którego nie zatwierdzono. Sophos powiązało aktywność z identyfikatorami instancji ScreenConnect d905b2b1b165d0a9, 4b8f4089ddaac6a9 i df1f7ef0cfacd0d8 oraz dodatkowymi identyfikatorami 2588ef5c15954b10 i ed630cc2c873b091.
• Przeszukaj punkty końcowe pod kątem zaplanowanego zadania o nazwie "TrapWatch" oraz plików: sckit-run.bat, sckit-decoder.ps1, TrapWatch.ps1, Panel-Lateral.ps1, Run-Lateral-Full.bat, runnew.cmd, ToolboxRelayUploader.exe i Sqlite3.exe. Sophos zaobserwowało także, że curl.exe pobierał ScreenConnect.ClientSetup.msi do C:\Windows\TEMP\sc.msi, który następnie msiexec.exe instalował w tle.
• Przeszukaj logi zapory, proxy i DNS pod kątem adresów IP 185.99.255[.]28 i 155.94.150[.]39. Szukaj także domen: ns[.]mo7sen[.]dev (w tym ścieżki /EadF.php?p=4), sc[.]payproofkit[.]com, cdn007-digitaldownloads[.]com, newnewnew[.]gotdns[.]org oraz Soxnewwork[.]homedns[.]org.
• Zwracaj uwagę na nieoczekiwane prośby o wsparcie, komunikaty o resetowaniu hasła i pobieranie oprogramowania przez kanały, którym zwykle ufasz.

Jeśli znajdziesz którykolwiek z tych wskaźników, zgłoś je do ConnectWise i traktuj dotknięte panele, stacje robocze techników oraz punkty końcowe jako przejęte.

Aktualizacja 14 listopada 2026

Badacze mają obecnie prawdopodobne wyjaśnienie tego, jak atakujący się dostali. Według Huntress rozszerzenie RMM+ omija konta użytkowników, role i MFA w ScreenConnect. Zamiast tego sprawdza żądania względem jednego wspólnego klucza dostępu przechowywanego w ustawieniach rozszerzenia. BleepingComputer i The Register informują, że RMM+ w wersjach 1.0.31 i 1.0.32 zawiera błąd: jeśli nie skonfigurowano klucza dostępu, akceptują pusty klucz. Dzięki temu atakujący mogli uruchamiać polecenia bez logowania się do ScreenConnect i bez przechodzenia uwierzytelniania MFA. Zmiana haseł operatorów i włączenie MFA zatem nie chroni instancji, na której RMM+ jest nadal włączone. Nie ogłoszono jeszcze żadnej poprawionej wersji rozszerzenia.

• Należy upewnić się, że RMM+ oraz powiązane rozszerzenia są wyłączone na każdej instancji, także na serwerach lokalnych. ConnectWise nie może wyłączyć ich tam za Państwa.

• Warto przejrzeć historię poleceń Run Command pod kątem poleceń pochodzących z RMM+, nawet jeśli dzienniki logowania nie pokazują podejrzanych logowań.

• https://www.huntress.com/blog/sckit-worm-rogue-screenconnect

• https://www.bleepingcomputer.com/news/security/new-worm-like-sckit-malware-targets-msps-in-screenconnect-attacks/

• https://www.theregister.com/security/2026/11/12/hackers-exploiting-screenconnect-plugin-flaw-to-spread-malware-across-hundreds-of-pcs/5309361

• https://www.cybersecuritydive.com/news/connectwise-disables-third-party-extensions-cyberattack-ScreenConnect/874490/

Źródła

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://thehackernews.com/2026/11/screenconnect-attacks-target-at-least.html