Puerta trasera GSocket en servidores web Linux: compruebe si hay PHP, cPanel y Apache comprometidos

Qué ocurrió

El 11 de noviembre de 2026, Microsoft publicó una investigación sobre varios grupos de atacantes independientes que instalan GSocket en servidores Linux comprometidos. BleepingComputer informó sobre ello el 12 de noviembre de 2026. GSocket es una herramienta legítima de código abierto para acceso remoto. Una vez que se ejecuta en un servidor, tanto el servidor como el atacante realizan conexiones salientes a un servicio de retransmisión público, la red Global Socket Relay Network. Ese servicio une ambas conexiones en una sesión cifrada. El servidor no necesita ningún puerto abierto ni una dirección IP pública. Los atacantes no operan infraestructura propia, por lo que no existe una dirección IP ni un dominio del atacante que bloquear.

No se trata de una vulnerabilidad en GSocket. Los atacantes primero logran entrar en una aplicación web accesible desde internet y, después, instalan GSocket para mantener su acceso. Como GSocket se ejecuta de forma independiente de la aplicación, aplicar el parche a la aplicación no lo elimina. Microsoft indica que las detecciones relacionadas con GSocket en su telemetría aumentaron un 356,2 % entre marzo y agosto de 2026.

Microsoft describe los ataques de la siguiente manera:

• Los atacantes explotan una aplicación web y usan curl para descargar y ejecutar un script de instalación.
• El script coloca el cliente GSocket en rutas con permiso de escritura o respaldadas por memoria, como /dev/shm.
• El proceso se disfraza con nombres que parecen hilos del kernel, por ejemplo [kaluad], o con nombres similares a los del sistema, como systemd-remount-d y /usr/bin/defunct.
• La persistencia se configura mediante tareas cron, servicios de systemd, archivos de inicio de la shell, watchdogs y copias adicionales. Después se eliminan los archivos temporales y se modifican las fechas de los archivos.
• En algunos casos, los atacantes intentaron obtener privilegios de root mediante la vulnerabilidad del kernel de Linux CVE-2026-43284, conocida como "Dirty Frag".

Quién está afectado

Los servidores Linux que ejecutan aplicaciones web accesibles desde internet y que en algún momento fueron comprometidos. Según los datos de Microsoft, el 87,1 % de los incidentes afectó a aplicaciones web y alojamientos. Dentro de ese grupo, las aplicaciones web PHP y los alojamientos cPanel representaron el 63,9 % y Apache el 24,3 %. Microsoft también registra alertas de shells iniciadas desde aplicaciones web Java y Node.js. Conviene revisar especialmente los servidores en los que se detectó y corrigió recientemente un fallo en una aplicación web, ya que los atacantes pudieron entrar antes de la corrección.

Los servidores cuyas aplicaciones web nunca fueron comprometidas no están afectados. Un GSocket instalado deliberadamente por su propio equipo no constituye por sí mismo un indicio de compromiso.

Qué hacer ahora

1. Revise todos los servidores web Linux accesibles desde internet siguiendo los pasos de la siguiente sección. Empiece por los servidores en los que se haya corregido recientemente un fallo en una aplicación web, un CMS, un plugin o un panel de alojamiento.
2. Si encuentra GSocket, considere el servidor como comprometido. Detenga el proceso. Después elimine el binario, todas sus copias y todas las entradas de inicio automático: cron, unidades de systemd, archivos de inicio de la shell y scripts de watchdog. Microsoft señala que la persistencia suele estar en varias capas, por lo que detener solo el proceso no elimina el acceso. Si los atacantes pudieron obtener root, por ejemplo mediante CVE-2026-43284, lo más seguro es reconstruir el servidor a partir de una imagen limpia o de una copia de seguridad anterior al compromiso.
3. Cambie las credenciales del servidor afectado: contraseñas de bases de datos, secretos de aplicaciones, claves de API y claves SSH. Revise también authorized_keys por si hay entradas desconocidas.
4. Localice y cierre la vía de entrada. Actualice aplicaciones web, plataformas CMS, plugins y servidores de aplicaciones. Elimine los componentes que no utilice y restrinja las rutas de carga de archivos y de administración.
5. Aplique el parche del kernel contra CVE-2026-43284 ("Dirty Frag") con la actualización de kernel de su distribución y reinicie para cargar el nuevo kernel.
6. Restrinja el tráfico saliente. Cuando sea posible, bloquee las conexiones salientes por defecto y permita solo los destinos que necesite cada servidor. El tráfico de GSocket es solo saliente, por lo que las reglas de cortafuegos de entrada no lo detectan.
7. Refuerce los directorios temporales. Cuando sea práctico, monte /tmp y /dev/shm con la opción noexec.
8. Verifique después que el servidor ya no se conecta al relay de GSocket ni a los dominios indicados más abajo.

Cómo comprobar si está afectado

Ejecute estas comprobaciones como root. Un resultado positivo no es una prueba concluyente por sí mismo, pero debe investigarse.

Archivos y rutas indicados por 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

Procesos en ejecución:

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

Los hilos reales del kernel no tienen un archivo ejecutable. Si un proceso con un nombre entre corchetes, como [kaluad], apunta a un archivo, es sospechoso:

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

Persistencia:

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

Revise con atención las unidades de systemd cuyos nombres parezcan plausibles pero que usted no creó. Compruebe los directorios personales de cuentas de servicios web como www-data, apache y nobody, y de los usuarios de cPanel.

Hashes SHA-256 de archivos conocidos, según Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Red y registros: Busque en los registros de DNS, proxy y cortafuegos los dominios gsocket.io, cdn.gsocket.io y gsgg.b-cdn.net. Estos dominios se usan para descargar la herramienta. Busque también en el historial de la shell y en los registros del servidor web comandos que descarguen gsocket.io/y o gsocket.io/install.sh con curl. Revise las shells iniciadas por el servidor web o por procesos PHP. Use ss -tnp para ver qué procesos mantienen conexiones salientes e investigue aquellos que no pueda justificar. Tenga en cuenta que los atacantes eliminan los archivos temporales y el historial de comandos, por lo que la ausencia de rastros en un solo lugar no demuestra que el servidor esté limpio.

Fuentes

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