
Wprowadzenie do problemu / definicja
Trwa aktywna kampania cyberataków wymierzona w środowiska ScreenConnect wykorzystywane przez dostawców usług zarządzanych (MSP). Sednem zagrożenia jest przejęcie instancji narzędzia zdalnego dostępu, a następnie użycie go do instalowania nieautoryzowanych klientów zdalnego wsparcia na urządzeniach należących do klientów. Taki scenariusz stanowi poważne ryzyko dla łańcucha dostaw IT, ponieważ pojedyncze naruszenie po stronie MSP może przełożyć się na incydenty w wielu organizacjach jednocześnie.
W skrócie
Kampania została wykryta 11 listopada 2026 roku i objęła co najmniej kilka skompromitowanych MSP oraz setki endpointów w dziesiątkach organizacji. Atakujący nadużywają funkcji wykonywania poleceń w ScreenConnect, aby wdrażać własnych klientów zdalnego dostępu i uzyskiwać trwałą kontrolę nad urządzeniami poza legalnym środowiskiem operatora.
Dodatkowo pojawiły się sygnały wskazujące na możliwy bardziej niebezpieczny scenariusz, w którym sesja z już zainfekowanym urządzeniem może prowadzić do kompromitacji stacji roboczej technika. Na obecnym etapie najbardziej prawdopodobne są przejęte poświadczenia oraz uprowadzone sesje wsparcia, choć pełny wektor początkowego dostępu nie został jeszcze jednoznacznie potwierdzony.
Kontekst / historia
ScreenConnect jest szeroko stosowany przez MSP i zespoły IT do zdalnej administracji, pomocy technicznej oraz zarządzania infrastrukturą klientów. Z perspektywy obrońców oznacza to wygodę operacyjną i centralizację działań administracyjnych, ale jednocześnie wysoką koncentrację uprawnień. Dla napastników takie platformy są szczególnie atrakcyjne, ponieważ przejęcie jednego narzędzia może umożliwić szeroki ruch boczny, trwałość oraz aktywność przypominającą legalne działania administratora.
W analizowanym przypadku istotne są również ślady sugerujące, iż część infrastruktury oraz identyfikatorów używanych przez atakujących mogła pojawiać się już wcześniej, na wiele miesięcy przed publicznym ujawnieniem kampanii. Może to wskazywać na wcześniejsze przygotowanie zaplecza operacyjnego, testowanie mechanizmów wdrożeniowych lub prowadzenie równoległych kampanii z użyciem plików podszywających się pod dokumenty administracyjne.
Analiza techniczna
Mechanizm ataku opiera się na nadużyciu legalnych funkcji ScreenConnect po uzyskaniu dostępu do środowiska MSP. Napastnicy wykorzystują funkcję Run Command do zdalnego uruchamiania instalatorów klienta ScreenConnect na zarządzanych endpointach. najważniejsze jest to, iż wdrażany klient może być powiązany nie z legalną instancją operatora, ale z infrastrukturą kontrolowaną przez atakującego.
W praktyce oznacza to przejęcie kanału zdalnego dostępu do urządzeń końcowych bez użycia klasycznego malware RAT, który bywa łatwiej wykrywany przez narzędzia bezpieczeństwa. Sam przebieg ataku może wyglądać jak standardowa czynność administracyjna: uruchomienie polecenia, pobranie instalatora MSI, instalacja agenta i zestawienie połączenia z zewnętrzną infrastrukturą.
Taki model znacząco utrudnia detekcję, zwłaszcza gdy organizacja dopuszcza ruch związany ze zdalnym wsparciem i nie monitoruje szczegółowo historii poleceń administracyjnych, zmian w agentach czy nowych instancji narzędzi zdalnego dostępu. Opisano również oznaki możliwego scenariusza reverse pivot, w którym technik MSP łączący się z naruszonym urządzeniem może sam paść ofiarą dalszej kompromitacji.
Dodatkowe artefakty techniczne sugerują wieloetapowy charakter działań. Wcześniej obserwowane skrypty wsadowe miały dodawać wykluczenia w Microsoft Defender, tworzyć trwałość poprzez folder autostartu i klucze rejestru Run, a następnie pobierać dalsze komponenty. Taki łańcuch wskazuje na połączenie socjotechniki, osłabiania ochrony endpointu, instalacji klienta zdalnego dostępu oraz weryfikacji powodzenia infekcji.
Konsekwencje / ryzyko
Największym zagrożeniem jest skala potencjalnego wpływu. Kompromitacja pojedynczego MSP może doprowadzić do naruszenia bezpieczeństwa wielu niezależnych organizacji, co czyni ten incydent szczególnie groźnym dla sektora usług IT, outsourcingu administracji oraz firm opierających się na zewnętrznym wsparciu technicznym.
Atakujący mogą uzyskać trwały i interaktywny dostęp do stacji roboczych oraz serwerów klientów, prowadzić rekonesans, wykonywać ruch boczny, kraść dane, wdrażać ransomware albo przygotowywać dalsze operacje sabotażowe. Ryzyko rośnie również dlatego, iż aktywność napastników może zostać błędnie uznana za legalne wsparcie zdalne.
Dla MSP oznacza to nie tylko problem techniczny, ale także ryzyko odpowiedzialności kontraktowej, naruszenia zobowiązań bezpieczeństwa oraz konieczność równoległego reagowania u wielu klientów. o ile potwierdzi się kompromitacja stacji techników, zagrożenie może objąć także konta uprzywilejowane, narzędzia RMM, repozytoria skryptów, sejfy z poświadczeniami i infrastrukturę tożsamości.
Rekomendacje
Organizacje korzystające ze ScreenConnect powinny niezwłocznie przeprowadzić przegląd historii Run Command, aktywnych i niedawnych sesji, zmian konfiguracyjnych oraz listy wdrożonych klientów na endpointach. Należy sprawdzić, czy na urządzeniach nie pojawiły się nieautoryzowane instancje klienta zdalnego dostępu, nowe usługi, zadania harmonogramu, wpisy autostartu lub nietypowe instalatory MSI.
MSP powinny czasowo ograniczyć lub wstrzymać interaktywne sesje do urządzeń podejrzanych o kompromitację i prowadzić analizę z użyciem odrębnych narzędzi bezpieczeństwa. Konieczne jest także unieważnienie aktywnych sesji, reset poświadczeń z zaufanych urządzeń administracyjnych oraz wymuszenie i potwierdzenie MFA dla wszystkich kont uprzywilejowanych i operatorskich.
- Monitorować uruchomienia instalatorów klienta ScreenConnect poza standardowym procesem wdrożeniowym.
- Analizować nietypowe polecenia wykonywane przez funkcje administracyjne.
- Weryfikować nowe połączenia wychodzące do nieznanej infrastruktury zdalnego dostępu.
- Sprawdzać modyfikacje wykluczeń w rozwiązaniach EDR i AV.
- Wykrywać trwałość budowaną przez Run keys, Startup folder oraz skrypty PowerShell lub BAT.
- Poszukiwać oznak uprowadzenia sesji wsparcia i wykorzystania przejętych danych logowania.
W planie reagowania należy założyć możliwość incydentu wielopodmiotowego. Oznacza to potrzebę szybkiej segmentacji tenantów, izolacji zagrożonych stanowisk operatorów, komunikacji z klientami, rotacji sekretów oraz przygotowania zbiorczej analizy wpływu na wszystkie obsługiwane organizacje.
Podsumowanie
Aktywne ataki na środowiska ScreenConnect pokazują, jak niebezpieczne może być przejęcie platform zdalnego wsparcia używanych przez MSP. W tym modelu legalne funkcje administracyjne stają się narzędziem do wdrażania nieautoryzowanego dostępu na dużą skalę. Najważniejsze działania obronne obejmują szybką weryfikację historii poleceń i sesji, identyfikację obcych klientów ScreenConnect, reset poświadczeń, potwierdzenie skuteczności MFA oraz szczególną ostrożność przy inicjowaniu sesji z urządzeniami potencjalnie już naruszonymi.




