SCKit: як хробак перетворює ConnectWise ScreenConnect на платформу атак MSP

Що сталося

11 листопада 2026 року компанія ConnectWise повідомила про активну кампанію, у межах якої зловмисники отримували несанкціонований доступ до хмарних інстанцій ConnectWise ScreenConnect — платформи віддаленого доступу та підтримки, якою масово користуються керовані постачальники послуг (MSP) та ІТ-команди, щоб віддалено адмініструвати і лагодити комп'ютери своїх клієнтів.

Отримавши доступ до консолі управління, атакуючі використовували штатну функцію Run Command, щоб масово розсилати команди на підконтрольні пристрої. Команди тихо встановлювали на клієнтських машинах додатковий «зрадницький» ScreenConnect-клієнт, підключений до інфраструктури зловмисників, а разом із ним — новий інструментарій під назвою SCKit. Це означає, що навіть після завершення легітимного сеансу підтримки атакуючі зберігали окремий, власний канал віддаленого доступу до заражених систем.

Масштаб вражає швидкістю. За даними компанії Huntress, лише 11 листопада оператор встиг уразити щонайменше 288 хостів у 48 організаціях, причому близько третини з них — за перші 10 хвилин. А 13 листопада фахівці Huntress зафіксували новий сплеск активності з іншої інфраструктури, який зачепив ще 205 хостів у 41 організації. ConnectWise у відповідь превентивно вимкнув п'ять сторонніх розширень у понад 400 партнерських середовищах.

Як працює SCKit: набір із 16 файлів

SCKit — це не одна програма, а пакет із 16 файлів: PowerShell-скрипти, batch-скрипти, .cmd-файли та конфігураційні дані, зібрані в багатоступеневий механізм розповсюдження. Завдання набору — закріпитися, зберегти постійний доступ і поширитися далі через саму інфраструктуру, якою MSP керує своїми клієнтами.

Доставка організована хитро. Корисне навантаження зберігається в зашифрованому вигляді, але ключ для розшифрування фактично надає сама заражена машина: коли хробак запитує пакет з інфраструктури атакуючих, він передає GUID Windows-системи у рядку запиту. Сервер у відповідь повертає ключ шифрування, вектор ініціалізації та сіль, за допомогою яких скрипт розпаковує пакет у тимчасову папку конкретної машини. Тобто кожна копія SCKit виявляється прив'язаною до конкретного пристрою — це ускладнює аналіз і повторне використання перехопленого артефакту на іншій машині.

Після розпакування встановлюються пастки та політики блокування, а інсталятор додає винятки для Windows Defender і встановлює другий, уже підконтрольний атакуючим ScreenConnect-клієнт. Легітимний клієнт ScreenConnect зупиняється, переводиться в ручний режим запуску — і його місце займає копія зловмисників. Усе це працює з правами SYSTEM, тому звичайний антивірус та оновлення самі по собі не рятують.

RelayTrap: сеанс підтримки у зворотний бік

Найцікавіша частина SCKit — компонент RelayTrap, який перевертає звичну логіку віддаленої підтримки з ніг на голову. Зазвичай технік за допомогою клієнта Host підключається до віддаленої системи з компонентом Guest, щоб взаємодіяти з нею, передавати файли та виконувати адміністративні дії. SCKit намагається розвернути цей зв'язок навпаки: зробити так, щоб саме заражена машина клієнта атакувала техніка, коли той підключається для підтримки.

RelayTrap реалізовано не як готовий бінарник, а як вихідний код на C# — файл RelayTrap.cs. Він завантажується на заражений пристрій, де PowerShell-скрипт компілює його в локальний виконуваний файл. Окремий компонент TrapWatch стежить за службами ScreenConnect і готує заміну легітимного Guest-процесу. Коли технік відкриває інтерактивний сеанс підтримки, RelayTrap вичікує 2,5 секунди після встановлення з'єднання і намагається передати назад, на робочу станцію техніка, файл Run-Lateral-Full.bat із запуском на виконання.

Дослідники Blackpoint Cyber і Huntress звернули увагу на показову деталь: вихідний код RelayTrap містить надзвичайно детальні коментарі, які пояснюють його функціональність, обхідні шляхи сумісності та навіть попередні помилки кодування. Це типовий почерк коду, згенерованого великою мовною моделлю. Тобто зловмисники, найімовірніше, пришвидшили розробку хробака за допомогою ШІ — ще одне підтвердження, що інструменти генерації коду активно використовуються і в наступальних цілях.

Крадіжка cookie та вихід на інших клієнтів

Якщо RelayTrap успішно доставляє корисне навантаження на робочу станцію техніка, починається другий етап — вихід із зараженої машини на весь парк клієнтів, яким цей технік керує.

Компонент Panel-Lateral.ps1 (за підтримки LabConfig.ps1) викрадає сесійний cookie .aspxauth з браузера техніка і намагається відтворити його проти консолі ScreenConnect. Це дозволяє викрасти вже автентифіковану сесію управління — без знання пароля і без повторного проходження MFA. Далі інструмент ToolboxRelayUploader.exe використовує отриманий доступ, щоб завантажити в Shared Toolbox (спільний набір інструментів панелі) файл WithUninstall.ps1, а команда на панелі змушує кожну досяжну сесію запустити його з правами SYSTEM. Приблизно через 60 секунд після розсилки ToolboxRelayUploader видаляє елемент зі Shared Toolbox, щоб замести сліди.

Так вибудовується хробакоподібний ланцюжок зараження: скомпрометована машина клієнта → робоча станція техніка → інші кінцеві точки в усіх організаціях, до яких цей технік має доступ. У середовищі MSP, де один технік може адмініструвати десятки різних замовників, це означає потенційний шлях до компрометації відразу багатьох не пов'язаних між собою компаній через ту саму інфраструктуру, якою їх обслуговують.

Важлива обмовка: жодна з дослідницьких команд поки не спостерігала успішного стрибка з клієнтської машини на робочу станцію техніка. Тестування Blackpoint Cyber проти актуального клієнта ScreenConnect показало, що Guest ставив передачу в чергу, але Host зі сторони техніка так і не запитував і не запускав файл. Іншими словами, поширення «через техніка» — це проєктна можливість інструментарію, яку завадила реалізувати вже випущена латка, а не підтверджений факт зараження.

Роль CVE-2026-84869 та сторонніх розширень

У центрі механізму Guest-to-Host лежить вразливість CVE-2026-84869 — критична вада клієнтської частини ScreenConnect з оцінкою 9.9 за шкалою CVSS. Вона дозволяла несанкціоновану передачу файлу та його виконання під час активного віддаленого сеансу за певних умов. ConnectWise випустила виправлення ще 8 вересня 2026 року у версії клієнта 26.6.5.

Тут криється перша практична пастка для MSP: оновлення хмарної консолі не оновлює автоматично клієнти техніків. У багатьох партнерів на робочих станціях залишилися старі версії клієнта, вразливі до CVE-2026-84869, — саме тому ConnectWise наголошує, що всі клієнти техніків мають бути перевірені на версію 26.6.5 або новішу.

Друга проблема — сторонні розширення. ConnectWise ідентифікував п'ять незалежних розширень, які можуть бути пов'язані з цією активністю, і превентивно вимкнув їх у сотнях партнерських середовищ:

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

Окремо дослідники повідомили про недолік автентифікації у версіях RMM+ 1.0.31 та 1.0.32, який міг приймати порожній ключ доступу, якщо його не було налаштовано. ConnectWise на момент публікації заявив, що початковий вектор доступу ще не встановлено — тобто шлях, яким зловмисники вперше проникали в консолі партнерів, продовжує з'ясовуватися. Для власників локальних (on-premises) інстанцій рекомендація жорстка: негайно вимкнути перелічені розширення і переконатися, що всі клієнти техніків оновлені.

Чому це небезпечно саме для MSP

Ця атака цінна не стільки технічною складністю, скільки вибором мішені. MSP — це мультиплікатор: одна скомпрометована консоль управління відкриває доступ одразу до десятків і сотень клієнтських організацій. Атакувати постачальника послуг вигідніше, ніж атакувати кожну компанію окремо, — це той самий принцип, що й у supply chain-атак.

Крім того, ScreenConnect — легітимний інструмент, якому довіряють системи захисту та адміністратори. Команди, розіслані через Run Command, і додаткові ScreenConnect-клієнти виглядають як штатна активність, тому їх легко пропустити. Дослідники Huntress прямо попереджають: видалення лише «зайвого» клієнта не прибирає персистентність інструментарію — заражені системи повторно заражалися невдовзі після того, як їх повертали в роботу без повного очищення.

Нарешті, загроза крадіжки сесійних cookie через Panel-Lateral.ps1 — це класична атака на ідентичність, яка обходить паролі та багатофакторну автентифікацію. Якщо технік авторизований, зловмиснику не потрібні його облікові дані — достатньо викраденого токена сесії, щоб діяти від його імені.

Як захиститися: практичні кроки

ConnectWise та дослідницькі команди сформулювали конкретний план дій для MSP та ІТ-команд. Навіть якщо ви не отримували сповіщень про компрометацію, варто перевірити середовище зараз.

1. Вимкніть сторонні розширення та оновіть клієнти. Власники локальних інстанцій мають негайно вимкнути Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link і RMM+ Password Link. Всі клієнти техніків ScreenConnect повинні працювати на версії 26.6.5 або новішій — пам'ятайте, що оновлення хмарної консолі не оновлює клієнти автоматично.

2. Не підключайтеся до підозрілого хоста через ScreenConnect. Інтерактивний сеанс може спровокувати спробу поширення на робочу станцію техніка. Для розслідування використовуйте EDR live response, WinRM або інший позасмуговий інструмент. Якщо технік уже підключався до підозрілого хоста, трактуйте його робочу станцію як потенційно скомпрометовану і досліджуйте з чистого пристрою.

3. Ізолюйте хост до повного очищення. Сама лише ізоляція не прибирає персистентність. Видаліть rogue-клієнт, заплановане завдання TrapWatch, папку C:\ProgramData\RelayTrap\, значення RelayTrapLiteAlert у гілці реєстру HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, а також файли інструментарію в %TEMP% (зокрема sckit-*, Panel-Lateral.ps1, runnew.cmd, ToolboxRelayUploader.exe). Легітимний клієнт перевіряйте окремо, перш ніж щось видаляти.

4. Відкличте скомпрометовані доступи. З чистого пристрою завершіть активні веб-сесії ScreenConnect і змініть облікові дані. Оскільки інструментарій вміє красти токени браузерних сесій, відкличте також потенційно скомпрометовані сесії браузера та провайдера ідентичності. Зайве нагадаємо: якщо є підозра, що облікові записи могли опинитися в руках зловмисників, варто перевірити їх на предмет витоків — зокрема, через наш інструмент перевірки витоків даних.

5. Проведіть аудит активності панелі. Перегляньте журнали Run Command і Toolbox на предмет невідомих виконань та інструментів, а за допомогою журналів аудиту інстансу з'ясуйте, до яких систем і робочих станцій техніків могли отримати доступ. Звертайте увагу на раптову масову активність, яку ніхто з вашої команди не ініціював.

Висновок

SCKit — це показовий приклад того, як зловмисники націлюються не на окремі компанії, а на постачальників послуг, які обслуговують їх усіх. Легітимний інструмент віддаленої підтримки перетворили на платформу атак, а швидкість розгортання — сотні хостів за лічені хвилини — нагадує, що в таких сценаріях рахунок іде на години.

Для MSP головний урок — не довіряти сліпо власному інструментарію. Перевіряйте версії клієнтів, тримайте під контролем сторонні розширення, аудитуйте Run Command і Toolbox, а розслідування підозрілих хостів ведіть лише позасмуговими засобами. І пам'ятайте: видалити «зайвий» клієнт недостатньо — персистентність SCKit живе глибше, і без повного очищення система повернеться під контроль атакуючих.