Backdoor GSocket na serwerach Linux: sprawdź PHP, cPanel i Apache pod kątem kompromitacji

Co się wydarzyło

11 listopada 2026 roku Microsoft opublikował wyniki badań dotyczących kilku odrębnych grup atakujących, które instalują GSocket na przejętych serwerach Linux. BleepingComputer napisał o tym 12 listopada 2026 roku. GSocket to legalne, otwartoźródłowe narzędzie do zdalnego dostępu. Gdy działa na serwerze, zarówno serwer, jak i atakujący nawiązują połączenia wychodzące do publicznej usługi przekaźnika, Global Socket Relay Network. Przekaźnik łączy oba końce w zaszyfrowaną sesję. Serwer nie potrzebuje otwartego portu ani publicznego adresu IP. Atakujący nie utrzymują własnej infrastruktury, więc nie ma adresu IP ani domeny atakującego, które można by zablokować.

To nie jest podatność w GSocket. Atakujący najpierw włamują się do internetowej aplikacji webowej, a następnie instalują GSocket, aby zachować dostęp. Ponieważ GSocket działa niezależnie od aplikacji, załatanie aplikacji nie usuwa go. Microsoft podaje, że wykrycia związane z GSocket w jego telemetrii wzrosły o 356,2% między marcem a sierpniem 2026 roku.

Microsoft opisuje ataki w następujący sposób:

• Atakujący wykorzystują podatność aplikacji webowej i używają curl, aby pobrać i uruchomić skrypt instalacyjny.
• Skrypt umieszcza klienta GSocket w ścieżkach z możliwością zapisu lub w pamięci, takich jak /dev/shm.
• Proces jest maskowany nazwami przypominającymi wątki jądra, na przykład [kaluad], lub nazwami systemowymi, takimi jak systemd-remount-d i /usr/bin/defunct.
• Trwałość jest zapewniana przez zadania cron, usługi systemd, pliki startowe powłoki, skrypty watchdog i dodatkowe kopie. Pliki pomocnicze są następnie usuwane, a znaczniki czasu plików cofane.
• W kilku przypadkach atakujący próbowali uzyskać uprawnienia roota, wykorzystując błąd jądra Linux CVE-2026-43284, znany jako „Dirty Frag”.

Kogo to dotyczy

Serwery Linux z internetowymi aplikacjami webowymi, które w pewnym momencie zostały przejęte. W danych Microsoftu 87,1% incydentów dotyczyło aplikacji webowych i hostingu. W tej grupie aplikacje webowe PHP i hosting cPanel stanowiły 63,9%, a Apache 24,3%. Microsoft wymienia też alerty dotyczące powłok uruchamianych z aplikacji webowych w Javie i Node.js. Szczególnie warto sprawdzić serwery, na których niedawno wykryto i załatano błąd w aplikacji webowej, ponieważ atakujący mogli wejść przed załataniem.

Serwery, na których aplikacje webowe nigdy nie zostały przejęte, nie są dotknięte problemem. GSocket zainstalowany celowo przez własny zespół sam w sobie nie jest oznaką kompromitacji.

Co zrobić teraz

1. Sprawdź każdy internetowy serwer webowy Linux według kroków z kolejnej sekcji. Zacznij od serwerów, na których w ostatnich miesiącach załatano błąd aplikacji webowej, CMS-a, wtyczki lub panelu hostingowego.
2. Jeśli znajdziesz GSocket, traktuj serwer jako skompromitowany. Zatrzymaj proces. Następnie usuń plik binarny, wszystkie jego kopie oraz wszystkie wpisy autostartu: cron, jednostki systemd, pliki startowe powłoki i skrypty watchdog. Microsoft zauważa, że trwałość jest często warstwowa, więc samo zabicie procesu nie usuwa dostępu. Jeśli atakujący mogli uzyskać uprawnienia roota, na przykład przez CVE-2026-43284, najbezpieczniejszym rozwiązaniem jest odtworzenie serwera z czystego obrazu lub kopii zapasowej wykonanej przed kompromitacją.
3. Zmień dane uwierzytelniające na dotkniętym serwerze: hasła do baz danych, sekrety aplikacji, klucze API i klucze SSH. Sprawdź też authorized_keys pod kątem nieznanych wpisów.
4. Znajdź i zamknij drogę wejścia. Zaktualizuj aplikacje webowe, platformy CMS, wtyczki i serwery aplikacji. Usuń nieużywane komponenty i ogranicz ścieżki przesyłania plików oraz panelu administracyjnego.
5. Załataj jądro przeciwko CVE-2026-43284 („Dirty Frag”) aktualizacją dostarczoną przez dystrybucję i uruchom ponownie system z nowym jądrem.
6. Ogranicz ruch wychodzący. Tam, gdzie to możliwe, blokuj połączenia wychodzące domyślnie i zezwalaj tylko na cele, których serwer rzeczywiście potrzebuje. Ruch GSocket jest wyłącznie wychodzący, więc reguły zapory dla ruchu przychodzącego go nie wykryją.
7. Wzmocnij katalogi tymczasowe. Jeśli jest to praktyczne, zamontuj /tmp i /dev/shm z opcją noexec.
8. Zweryfikuj po fakcie, że serwer nie łączy się już z przekaźnikiem GSocket ani z domenami wymienionymi poniżej.

Jak sprawdzić, czy jesteś dotknięty

Uruchom te sprawdzenia jako root. Trafienie samo w sobie nie jest dowodem, ale należy je zbadać.

Pliki i ścieżki wskazane przez 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

Działające procesy:

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

Prawdziwe wątki jądra nie mają pliku wykonywalnego. Jeśli proces o nazwie w nawiasach, na przykład [kaluad], wskazuje na plik, jest podejrzany:

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

Trwałość:

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

Uważnie przyjrzyj się jednostkom systemd, których nazwy wyglądają wiarygodnie, ale których nie tworzyłeś. Sprawdź katalogi domowe kont usług webowych, takich jak www-data, apache i nobody, oraz użytkowników cPanel.

Znane skróty plików (SHA-256) podane przez Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Sieć i logi: Przeszukaj logi DNS, proxy i zapory pod kątem gsocket.io, cdn.gsocket.io i gsgg.b-cdn.net. Te domeny służą do pobierania narzędzia. Przeszukaj też historię powłoki i logi serwera webowego pod kątem poleceń pobierających gsocket.io/y lub gsocket.io/install.sh za pomocą curl. Szukaj powłok uruchomionych przez procesy serwera webowego lub PHP. Użyj ss -tnp, aby sprawdzić, które procesy utrzymują połączenia wychodzące, i zbadaj te, których nie potrafisz wyjaśnić. Pamiętaj, że atakujący usuwają pliki pomocnicze i historię poleceń, więc brak śladów w jednym miejscu nie dowodzi, że serwer jest czysty.

Źródła

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