Бекдор GSocket на Linux уеб сървъри: проверете PHP, cPanel и Apache хостове за компрометиране

Какво се случи

На 11 ноември 2026 г. Microsoft публикува изследване за няколко отделни групи атакуващи, които инсталират GSocket на компрометирани Linux сървъри. BleepingComputer съобщи за него на 12 ноември 2026 г. GSocket е легитимен инструмент с отворен код за отдалечен достъп. След като се стартира на сървър, както сървърът, така и атакуващият установяват изходящи връзки към публичната услуга за пренасочване Global Socket Relay Network. Пренасочвателят свързва двете страни в криптирана сесия. Сървърът не се нуждае нито от отворен порт, нито от публичен IP адрес. Атакуващите не използват собствена инфраструктура, затова няма IP адрес или домейн на нападателя, които да бъдат блокирани.

Това не е уязвимост в GSocket. Атакуващите първо проникват в уеб приложение, достъпно от интернет, а след това инсталират GSocket, за да запазят достъпа си. Тъй като GSocket работи отделно от приложението, поправянето на приложението не го премахва. Microsoft посочва, че откритията, свързани с GSocket, в телеметрията ѝ са се увеличили с 356,2% между март и август 2026 г.

Microsoft описва атаките по следния начин:

• Атакуващите използват уязвимост в уеб приложение и с curl изтеглят и изпълняват скрипт за инсталация.
• Скриптът поставя клиента на GSocket в пътеки с възможност за запис или в паметта, например /dev/shm.
• Процесът се маскира под имена, които приличат на ядрени нишки, например [kaluad], или под системни имена като systemd-remount-d и /usr/bin/defunct.
• Постоянството се осигурява чрез cron задачи, systemd услуги, файлове за стартиране на обвивката, наблюдаващи скриптове и допълнителни копия. Помощните файлове после се изтриват, а времевите марки на файловете се променят назад.
• В някои случаи атакуващите са се опитали да получат root права чрез уязвимостта в Linux ядрото CVE-2026-43284, известна като „Dirty Frag“.

Кой е засегнат

Linux сървъри, които работят с уеб приложения, достъпни от интернет, и които са били компрометирани в даден момент. Според данните на Microsoft 87,1% от инцидентите са засегнали уеб приложения и хостинг. В тази група PHP уеб приложенията и cPanel хостингът представляват 63,9%, а Apache – 24,3%. Microsoft посочва и предупреждения за обвивки, стартирани от Java и Node.js уеб приложения. Сървърите, при които наскоро е открита и поправена уязвимост в уеб приложение, заслужават особено внимание, тъй като атакуващите може да са проникнали преди поправката.

Сървърите, чиито уеб приложения никога не са били компрометирани, не са засегнати. GSocket, инсталиран умишлено от вашия собствен екип, сам по себе си не е признак за компрометиране.

Какво да направите сега

1. Проверете всеки Linux уеб сървър, достъпен от интернет, като следвате стъпките в следващия раздел. Започнете със сървърите, при които през последните месеци е поправена уязвимост в уеб приложение, CMS, плъгин или хостинг панел.
2. Ако откриете GSocket, считайте сървъра за компрометиран. Спрете процеса. След това премахнете двоичния файл, всяко копие и всеки запис за автоматично стартиране: cron, systemd единици, файлове за стартиране на обвивката и скриптове за наблюдение. Microsoft отбелязва, че постоянството често е многослойно, така че само спирането на процеса не премахва достъпа. Ако атакуващите може да са получили root права, например чрез CVE-2026-43284, най-безопасният вариант е сървърът да бъде пресъздаден от чист образ или от резервно копие, направено преди компрометирането.
3. Сменете удостоверителните данни на засегнатия сървър: пароли за бази данни, тайни ключове на приложения, API ключове и SSH ключове. Проверете и authorized_keys за непознати записи.
4. Открийте и затворете пътя за проникване. Актуализирайте уеб приложенията, CMS платформите, плъгините и сървърите за приложения. Премахнете компонентите, които не използвате, и ограничете пътищата за качване на файлове и администраторските пътища.
5. Поправете ядрото срещу CVE-2026-43284 („Dirty Frag“) с актуализацията на ядрото от вашата дистрибуция и рестартирайте към новото ядро.
6. Ограничете изходящия трафик. Където е възможно, блокирайте изходящите връзки по подразбиране и разрешете само местата, нужни на сървъра. Трафикът на GSocket е само изходящ, затова правилата за входящ трафик на защитната стена не го улавят.
7. Укрепете временните директории. Когато е практично, монтирайте /tmp и /dev/shm с noexec.
8. Проверете след това, че сървърът вече не се свързва с пренасочвателя на GSocket или с домейните, посочени по-долу.

Как да проверите дали сте засегнати

Изпълнете тези проверки като root. Съвпадението само по себе си не е доказателство, но трябва да бъде проучено.

Файлове и пътеки, посочени от Microsoft:

ls -la /dev/shm/.gs-* /tmp/.gsn_ora /tmp/systemd-remount-d /usr/bin/systemd-remount-d /usr/bin/defunct 2>/dev/null
find / -xdev \( -name 'gs-netcat*' -o -name 'defunct.service' -o -name 'defunct' -o -name 'systemd-remount-d' \) 2>/dev/null

Работещи процеси:

ps -eo pid,ppid,user,args | grep -Ei 'gs-netcat|gsocket|defunct|remount-d' | grep -v grep

Истинските ядрени нишки нямат изпълним файл. Ако процес с име в квадратни скоби, например [kaluad], сочи към файл, той е подозрителен:

for p in /proc/[0-9]*; do n=$(cat $p/cmdline 2>/dev/null | tr '\0' ' '); case "$n" in \[*) e=$(readlink $p/exe 2>/dev/null); [ -n "$e" ] && echo "${p#/proc/} $n -> $e";; esac; done

Постоянство:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
systemctl list-unit-files --type=service | grep -Ei 'defunct|remount'
grep -sEl 'gs-netcat|gsocket|defunct|GS_' /etc/profile /etc/profile.d/* /etc/bash.bashrc /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile

Внимателно разгледайте systemd единиците, чиито имена изглеждат правдоподобно, но които не сте създали вие. Проверете домашните директории на акаунти за уеб услуги като www-data, apache и nobody, както и на потребителите на cPanel.

Известни хешове на файлове (SHA-256) от Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Мрежа и журнали: Търсете в DNS, прокси и журналите на защитната стена gsocket.io, cdn.gsocket.io и gsgg.b-cdn.net. Тези домейни се използват за изтегляне на инструмента. Търсете също в историята на обвивката и в журналите на уеб сървъра команди, които с curl изтеглят gsocket.io/y или gsocket.io/install.sh. Обърнете внимание на обвивки, стартирани от уеб сървъра или PHP процесите. Използвайте ss -tnp, за да проверите кои процеси поддържат изходящи връзки, и проучете всеки, който не можете да обясните. Имайте предвид, че атакуващите изтриват помощните файлове и историята на командите, така че липсата на следи на едно място не доказва, че сървърът е чист.

Източници

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/