Los atacantes usan GSocket, una herramienta legítima de acceso remoto de código abierto, para mantener el control de servidores Linux comprometidos después de que los administradores parcheen las vulnerabilidades que usaron para entrar. En un informe de Microsoft del 11 de noviembre se describían varias intrusiones en las que la herramienta sobrevivió a la corrección de la aplicación, lo que obligó a los defensores a investigar el equipo y eliminar la persistencia, además de corregir el fallo original.
La actividad afecta especialmente a las aplicaciones web y a los entornos de alojamiento. La telemetría de Microsoft Defender for Endpoint mostró un aumento del 356,2 % en los dispositivos con detecciones relacionadas con GSocket entre marzo y agosto de 2026, aunque el crecimiento varió según el mes. Esta cifra mide dispositivos con detecciones, no el número de intrusiones confirmadas con éxito.
BleepingComputer informó el 12 de noviembre, citando a Microsoft, que el 87,1 % de los incidentes detectados estaba relacionado con aplicaciones web y alojamiento. Indicó cuotas del 63,9 % para aplicaciones web PHP y alojamiento cPanel, y del 24,3 % para Apache. La educación y la investigación fueron los sectores más atacados, seguidos por tecnología y comunicaciones, fabricación y gobierno.
Cómo sobrevive el acceso tras un parche
Microsoft observó que los atacantes explotaban aplicaciones expuestas a internet para ejecutar comandos con la cuenta del servicio web y, después, desplegaban GSocket. Como el cliente de relé se ejecuta de forma independiente de la aplicación vulnerable, parchear esa aplicación no elimina el cliente ni los mecanismos que lo reinician.
GSocket enruta el tráfico a través de Global Socket Relay Network, un servicio público compartido. El servidor comprometido y el atacante inician cada uno una conexión saliente a un relé, que los empareja mediante un canal cifrado de extremo a extremo. El servidor no necesita ni un servicio de escucha entrante ni una dirección IP pública. La traducción de direcciones de red (NAT), que permite a los sistemas compartir una dirección externa, no impide la conexión.
Así, los atacantes obtienen acceso remoto sin operar un servidor dedicado de mando y control, es decir, la infraestructura que normalmente se usa para dirigir los sistemas comprometidos. Pueden volver a conectarse sin conocer la dirección IP ni el nombre de host del servidor comprometido. Por tanto, no existe una dirección o un dominio de propiedad del atacante que los defensores puedan bloquear, aunque las organizaciones sí pueden restringir el acceso a la propia red de relés.
Las reglas de cortafuegos de entrada no detectan este tráfico saliente. Sí pueden hacerlo el filtrado y la monitorización de salida.
Microsoft afirma que varios actores de amenazas sin relación entre sí han adoptado GSocket. Su script de despliegue puede renombrar procesos, colocar archivos en directorios respaldados por memoria e instalar mecanismos diseñados para sobrevivir a un reinicio. Los investigadores observaron que los atacantes disfrazaban procesos como hilos del núcleo de Linux y usaban trabajos programados de cron, servicios de systemd y archivos de inicio de la shell para mantener el acceso. No se confirmó la persistencia tras reinicios ni las sesiones de relé exitosas en todas las intrusiones analizadas.
En algunos casos, los atacantes también intentaron explotar la vulnerabilidad del núcleo de Linux CVE-2026-43284, que BleepingComputer describe como «Dirty Frag», para pasar de la cuenta del servicio web a root, la cuenta con más privilegios de Linux. Microsoft describió estos casos como intentos de explotación.
Qué pueden buscar los defensores
Las alertas observadas por Microsoft incluían shells sospechosas lanzadas por servidores web y entornos de ejecución de aplicaciones, ejecución de GSocket, descargas de cargas útiles, trabajos de cron y servicios de Linux recién creados. Otras señales eran la ejecución de archivos ocultos, la ofuscación, marcas de tiempo alteradas, la eliminación de binarios en ejecución, intentos de borrar el historial de comandos, reconocimiento del sistema y comportamiento de shell inversa. Una alerta aislada no establece por dónde entró el atacante ni demuestra que cada fase de la intrusión tuviera éxito.
Por ejemplo, Microsoft observó un comando bash que invocaba la carga útil renombrada /usr/bin/defunct, junto con referencias a defunct.service y un enlace multi-user.target.wants usado para habilitar un servicio de systemd. Esto ilustra por qué los administradores deben revisar tanto los nombres de servicio que parecen legítimos como los nombres de archivo reconocibles de GSocket.
Microsoft publicó consultas de búsqueda (hunting) de Defender XDR que abarcan los siete días anteriores. Buscan en los nombres de proceso y en las líneas de comandos gs-netcat, gsocket, gsnetcat y gsocket.io, y después muestran la cuenta, la ruta y el proceso padre para su investigación. Otras consultas revisan la actividad de descarga y las conexiones de red que involucran a gsocket.io y gsgg.b-cdn.net.
Esos dominios, junto con cdn.gsocket.io, distribuyen la herramienta legítima; no son infraestructura de mando y control de los atacantes. Entre los destinos de descarga observados figuraban hxxps://gsocket[.]io/y y hxxps://gsocket[.]io/install.sh, aunque no se confirmó que la descarga desde este último tuviera éxito.
Las búsquedas de archivos cubren rutas que comienzan por /dev/shm/.gs- y nombres que incluyen systemd-remount-d, .gsn_ora, defunct y defunct.service. Microsoft también publicó estas observaciones concretas de archivos y las huellas SHA-256:
/dev/shm/.gs-0/gs-netcat_mini-linux-x86_64:d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa/dev/shm/.gs-0/gs-netcat_mini-linux-aarch64:f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5/tmp/systemd-remount-dy/usr/bin/systemd-remount-d:55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f/tmp/.gsn_ora:12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c
Los binarios específicos de cada arquitectura se asociaron con descargas desde hxxps://gsgg[.]b-cdn[.]net/bin/gs-netcat_mini-linux-x86_64 y hxxps://cdn[.]gsocket[.]io/bin/gs-netcat_mini-linux-aarch64. Estos indicadores representan observaciones concretas, no un inventario completo. Microsoft aconseja investigar las coincidencias junto con la ascendencia de los procesos, el contexto de ejecución, los cambios de persistencia y la actividad de red.
Eliminar el punto de apoyo, además de la vulnerabilidad
Los administradores que investiguen servidores Linux afectados deben eliminar el cliente GSocket no autorizado, los archivos preparados y la persistencia asociada, y después verificar que se hayan detenido las conexiones salientes a la infraestructura de relés, recomienda Microsoft. Detener solo el proceso en ejecución puede dejar intactos otros mecanismos de reinicio.
La empresa recomienda también revisar las entradas de cron, las unidades de systemd y los archivos de inicio de la shell; aplicar reglas de salida con denegación por defecto que solo permitan los destinos necesarios; y monitorizar las conexiones de relé. Cuando sea viable, los directorios temporales y respaldados por memoria deberían montarse como no ejecutables, con alertas por ejecución desde rutas ocultas o escribibles por cualquiera.
Las aplicaciones expuestas a internet, los sistemas de gestión de contenidos, los plugins y los servidores de aplicaciones deben mantenerse actualizados. Microsoft aconseja eliminar los componentes que no se usen y restringir las rutas de carga y de administración. Los administradores también deben priorizar los parches de escalada local de privilegios, incluido CVE-2026-43284. Como contexto aparte de esta recomendación, Microsoft citó el trabajo de FORGE Lab sobre 59 informes de errores del núcleo de Linux, entre ellos ocho vulnerabilidades con exploits locales de root demostrados en entornos controlados.
Las organizaciones que usan Defender for Endpoint en Linux deben, según Microsoft, mantener activadas la protección en tiempo real, la protección entregada desde la nube y la monitorización del comportamiento, incluida la vigilancia de procesos hijo inusuales de servicios web e identidades de proceso disfrazadas. Tras parchear las aplicaciones, debe hacerse una limpieza del host y verificar que las conexiones de relé hayan terminado.
