GSocket arka kapısı Linux web sunucularında: PHP, cPanel ve Apache sunucularını ele geçirilme açısından kontrol edin

Ne oldu

11 Kasım 2026'da Microsoft, ele geçirilmiş Linux sunucularına GSocket kuran birkaç ayrı saldırgan grubu hakkında bir araştırma yayımladı. BleepingComputer bu konuyu 12 Kasım 2026'da haberleştirdi. GSocket, meşru bir açık kaynaklı uzaktan erişim aracıdır. Sunucuda çalışmaya başladığında hem sunucu hem de saldırgan, herkese açık bir aktarma hizmeti olan Global Socket Relay Network'e giden bağlantılar kurar. Aktarma hizmeti ikisini şifreli bir oturumda birleştirir. Sunucunun açık bir bağlantı noktasına veya herkese açık bir IP adresine ihtiyacı yoktur. Saldırganların kendilerine ait bir altyapısı bulunmadığından engellenecek bir saldırgan IP adresi ya da alan adı yoktur.

Bu, GSocket'teki bir güvenlik açığı değildir. Saldırganlar önce dışarıya açık bir web uygulamasına girer, ardından erişimi sürdürmek için GSocket'i kurar. GSocket uygulamadan ayrı çalıştığı için uygulamayı yamalamak onu kaldırmaz. Microsoft, telemetrisindeki GSocket ile ilgili tespitlerin Mart ile Ağustos 2026 arasında %356,2 arttığını bildiriyor.

Microsoft saldırıları şöyle tanımlıyor:

• Saldırganlar bir web uygulamasındaki açığı kullanır ve bir kurulum betiğini indirip çalıştırmak için curl kullanır.
• Betik GSocket istemcisini /dev/shm gibi yazılabilir veya bellek üzerindeki yollara yerleştirir.
• Süreç, örneğin [kaluad] gibi çekirdek iş parçacıklarına benzeyen adlar altında veya systemd-remount-d ve /usr/bin/defunct gibi sistem benzeri adlar altında gizlenir.
• Kalıcılık cron işleri, systemd servisleri, kabuk başlangıç dosyaları, bekçi betikleri ve ek kopyalar üzerinden sağlanır. Ardından geçici dosyalar silinir ve dosya zaman damgaları geriye çekilir.
• Bazı durumlarda saldırganlar Linux çekirdeğindeki CVE-2026-43284 açığıyla ("Dirty Frag" olarak bilinir) root yetkisi elde etmeye çalıştı.

Kimler etkileniyor

Geçmişte bir noktada ele geçirilmiş, dışarıya açık web uygulamaları çalıştıran Linux sunucuları. Microsoft verilerinde olayların %87,1'i web uygulamaları ve barındırma hizmetleriyle ilgiliydi. Bu grubun içinde PHP web uygulamaları ve cPanel barındırma %63,9, Apache ise %24,3 paya sahipti. Microsoft ayrıca Java ve Node.js web uygulamalarından başlatılan kabuklara ilişkin uyarıları da listeliyor. Yakın zamanda bir web uygulaması açığı tespit edilip yamalanan sunucular özellikle kontrol edilmeye değer, çünkü saldırganlar yamadan önce içeri girmiş olabilir.

Web uygulamaları hiç ele geçirilmemiş sunucular etkilenmiş değildir. Kendi ekibiniz tarafından bilerek kurulmuş GSocket, tek başına bir ele geçirilme belirtisi değildir.

Şimdi ne yapmalısınız

1. Dışarıya açık her Linux web sunucusunu bir sonraki bölümdeki adımlarla kontrol edin. Son aylarda bir web uygulaması, CMS, eklenti ya da barındırma paneli açığının yamalandığı sunuculardan başlayın.
2. GSocket bulursanız sunucuyu ele geçirilmiş kabul edin. Süreci durdurun. Ardından ikili dosyayı, tüm kopyalarını ve tüm otomatik başlatma kayıtlarını kaldırın: cron, systemd birimleri, kabuk başlangıç dosyaları ve bekçi betikleri. Microsoft, kalıcılığın çoğu zaman katmanlı olduğunu belirtiyor; bu nedenle yalnızca süreci sonlandırmak erişimi kaldırmaz. Saldırganların root yetkisi elde etmiş olabileceği durumda, örneğin CVE-2026-43284 üzerinden, en güvenli seçenek sunucuyu temiz bir imajdan ya da ele geçirilmeden önce alınmış bir yedekten yeniden kurmaktır.
3. Etkilenen sunucudaki kimlik bilgilerini değiştirin: veritabanı parolaları, uygulama gizli anahtarları, API anahtarları ve SSH anahtarları. Ayrıca authorized_keys dosyasında tanınmayan girişler olup olmadığını kontrol edin.
4. Giriş yolunu bulun ve kapatın. Web uygulamalarını, CMS platformlarını, eklentileri ve uygulama sunucularını güncelleyin. Kullanmadığınız bileşenleri kaldırın ve dosya yükleme ile yönetici yollarını kısıtlayın.
5. Çekirdeği CVE-2026-43284 ("Dirty Frag") için yamalayın. Dağıtımınızın çekirdek güncellemesini uygulayın ve yeni çekirdekle yeniden başlatın.
6. Giden trafiği kısıtlayın. Mümkün olduğunda giden bağlantıları varsayılan olarak engelleyin ve yalnızca sunucunun ihtiyaç duyduğu hedeflere izin verin. GSocket trafiği yalnızca dışarı yöndedir, bu nedenle gelen trafik kuralları bunu yakalamaz.
7. Geçici dizinleri sertleştirin. Uygulanabilir olduğunda /tmp ve /dev/shm dizinlerini noexec seçeneğiyle bağlayın.
8. Sonrasında doğrulayın ki sunucu artık GSocket aktarma hizmetine veya aşağıda listelenen alan adlarına bağlanmıyor.

Etkilenip etkilenmediğinizi nasıl kontrol edersiniz

Bu kontrolleri root olarak çalıştırın. Bir eşleşme tek başına kanıt değildir, ancak incelenmelidir.

Microsoft'un adlandırdığı dosya ve yollar:

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

Çalışan süreçler:

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

Gerçek çekirdek iş parçacıklarının çalıştırılabilir dosyası yoktur. [kaluad] gibi köşeli parantez içinde bir adı olan ve bir dosyaya işaret eden süreç şüphelidir:

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

Kalıcılık:

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

Kendiniz oluşturmadığınız, ama makul görünen isimlere sahip systemd birimlerini dikkatle inceleyin. www-data, apache ve nobody gibi web servisi hesaplarının ve cPanel kullanıcılarının ev dizinlerini kontrol edin.

Microsoft'un bildirdiği bilinen dosya özetleri (SHA-256):

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Ağ ve günlükler: DNS, proxy ve güvenlik duvarı günlüklerinde gsocket.io, cdn.gsocket.io ve gsgg.b-cdn.net alan adlarını arayın. Bu alan adları aracı indirmek için kullanılır. Ayrıca kabuk geçmişinde ve web sunucusu günlüklerinde curl ile gsocket.io/y veya gsocket.io/install.sh adreslerini getiren komutları arayın. Web sunucusu veya PHP süreçlerinin başlattığı kabuklara bakın. Hangi süreçlerin giden bağlantı tuttuğunu görmek için ss -tnp komutunu kullanın ve açıklayamadığınız süreçleri inceleyin. Saldırganların geçici dosyaları ve komut geçmişini sildiğini unutmayın; bir yerde izlerin bulunmaması sunucunun temiz olduğunu kanıtlamaz.

Kaynaklar

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