Виправлення вразливого сайту не вигнало зловмисника із сервера. Microsoft описала атаки, у яких на скомпрометовані Linux-сервери встановлювали GSocket, щоб повертатися після усунення початкової вразливості вебзастосунку. Окремий клієнт віддаленого доступу використовував спільну мережу ретрансляторів, а завдання cron, служби й інші зміни автозапуску могли відновлювати його роботу.
Дослідження від 11 листопада охоплює кілька вторгнень, а не одну нову вразливість чи одну встановлену групу. Для власника сайту або хостингового облікового запису висновок конкретний: закрити початковий шлях проникнення й прибрати закріплення зловмисника — різні завдання.
Від вебзапиту до окремого каналу доступу
У спостережених ланцюжках відкритий вебзастосунок давав змогу виконувати команди від імені облікового запису вебслужби. Далі зловмисник завантажував скрипт розгортання. Той перевіряв систему, добирав клієнт під її архітектуру й розміщував файли в доступних для запису каталогах, зокрема в /dev/shm, що використовує оперативну пам’ять.
На цьому етапі інцидент переставав бути лише проблемою застосунку. Клієнт gs-netcat міг працювати незалежно від вразливого сайту. Оновлення PHP, плагіна чи іншого ураженого компонента залишалося необхідним, але не видаляло другу програму. Таке саме розмежування важливе під час оновлення PHP2Shell і перевірки можливого вторгнення: виправлене середовище закриває шлях проникнення, але не пояснює все, що виконали до встановлення виправлення.
Сам GSocket — легітимний інструмент віддаленого доступу з відкритим кодом. Його наявність потрібно оцінювати в контексті: погоджений засіб адміністрування відрізняється від клієнта, який запустив вебпроцес, сховав у тимчасовому каталозі й пов’язав із невідомою службою.
Обидві сторони з’єднуються назовні
Звичайна зворотна оболонка часто містить адресу сервера зловмисника. GSocket натомість використовує спільний секрет для ідентифікації з’єднання. Уражений сервер і оператор окремо встановлюють вихідні з’єднання з Global Socket Relay Network. Мережа поєднує їх у сеанс із наскрізним шифруванням. Оператору не потрібні публічна IP-адреса жертви чи відкритий вхідний порт.
Скрипт встановлення може створити секрет і вивести його в консоль, звідки оператор його забере; підтримувані канали сповіщень також дають змогу передати секрет. Маючи його, користувач сумісного клієнта може приєднатися пізніше. Тому зміна адреси сайту або пошук лише окремого домену зловмисника не охоплюють цей механізм.
Це не робить трафік некерованим. Адміністратори можуть обмежити вихідний доступ до інфраструктури ретрансляторів і з’ясувати, який процес його ініціював. Важливо розрізняти власну адресу зловмисника, якої може не бути, та спільний сторонній сервіс, яким він зловживає.
Знайоме ім’я процесу може приховувати іншу програму
Microsoft спостерігала файли /tmp/systemd-remount-d, /usr/bin/systemd-remount-d та /tmp/.gsn_ora. В іншому випадку /usr/bin/defunct запускався з іменем процесу, схожим на потік ядра. Частина активності змінювала часові мітки або видаляла проміжні файли, тому швидка перевірка лише нещодавніх завантажень могла пропустити сліди.
Закріплення з’являлося в cron, systemd, файлах запуску оболонки та механізмах нагляду за процесом. Це пояснює, чому зупинити один процес недостатньо: інша точка запуску або резервна копія може відновити роботу клієнта. Такі назви й шляхи — приводи для розслідування, а не вказівка видаляти кожну схожу легітимну службу.
У кількох інцидентах дослідники також бачили спроби отримати права root через вразливість ядра Linux CVE-2026-43284, відому як Dirty Frag. Це наступний крок після проникнення, а не початковий вхід через вебзастосунок. Microsoft застерігає: не кожен ланцюжок містив усі етапи; успішне з’єднання з ретранслятором чи збереження доступу після перезавантаження підтвердили не в усіх випадках.
Що саме показує телеметрія
Кількість пристроїв із виявленнями, пов’язаними з GSocket, зросла на 356,2% від березня до серпня 2026 року в телеметрії Microsoft. Це зміна кількості виявлених пристроїв у межах видимості компанії, а не підрахунок усіх зламаних Linux-систем. Вебзастосунки й хостинг становили 87,1% інцидентів, які вдалося віднести до категорії; усередині цієї групи помітну частку мали PHP-застосунки та cPanel-хостинг.
Звіт опублікували в листопаді, але ці вимірювання стосуються березня–серпня. Вони не доводять такого самого стрибка заражень цього тижня й не означають, що кожне використання інструмента зловмисне.
Після виправлення завершіть перевірку сервера
Для ураженого сервера збережіть докази й поєднайте вебзапит, дочірній процес, завантажений клієнт, зміну автозапуску та вихідний сеанс в одну хронологію. Перевіряйте несанкціоновані завдання cron, служби systemd і профілі оболонки разом. Приберіть сторонній клієнт та механізми його запуску, після чого підтвердьте припинення з’єднань із ретрансляторами. Оновіть відкриті вебзастосунки й усуньте локальні вразливості підвищення привілеїв; обмежте непотрібний вихідний трафік.
Користувачеві керованого хостингу варто запитати провайдера, чи охоплювало відновлення сам сервер і механізми закріплення поряд з оновленням застосунку. Звіт про патч відповідає на запитання про версію. Щоб закрити інцидент, потрібна також відповідь про окремий канал доступу, який залишився після вторгнення.
Джерела
- Gund, Y., Maniath, S. та Microsoft Security Research. Як зловмисники використовують GSocket для прихованого керування. Microsoft Security Blog, 11 листопада 2026 року; переглянуто 12 листопада 2026 року. Дослідження розгортання, закріплення та ретрансляції GSocket.
