¿Tecnología Geek te ahorra tiempo? Agréganos como tu fuente preferida en Google y ve más noticias nuestras en tus resultados. Fuente preferida en Google
GSocket está convirtiendo servidores Linux parcheados en puertas que siguen abiertas. Microsoft publicó el 11 de noviembre un informe con varios incidentes en los que grupos distintos instalaron esta herramienta de acceso remoto de código abierto y conservaron la entrada aun después de corregida la falla que les dio paso.
La cifra que resume el problema viene de la telemetría de Microsoft Defender for Endpoint: las detecciones ligadas a GSocket crecieron 356,2 % entre marzo y agosto de 2026. El aumento no fue parejo mes a mes, y aun así marca una adopción repetida entre atacantes sin relación entre ellos.
GSocket nació como una herramienta legítima de administración remota, obra del colectivo The Hacker’s Choice. Su diseño permite llegar a equipos detrás de cortafuegos y de redes con direcciones internas, sin abrir puertos de entrada en la máquina destino.
Un relevo público en lugar de un servidor propio
El truco está en el relevo. El servidor comprometido y el operador conectan hacia afuera, cada uno por su lado, con la Global Socket Relay Network, la red pública de relevo del proyecto; ese punto intermedio empareja las dos sesiones y las une con cifrado de extremo a extremo.
Ninguno de los dos extremos necesita una dirección pública propia ni un puerto abierto esperando conexiones. Las reglas del cortafuegos pensadas para la entrada no ven pasar este tráfico, porque todo sale. Microsoft advierte que el filtrado de salida y la vigilancia del tráfico saliente sí pueden cortarlo.
La sesión tampoco depende de una dirección del atacante. GSocket identifica cada extremo con un secreto compartido que el guion de instalación genera al azar; quien tenga ese secreto puede reconectar desde cualquier cliente compatible, sin saber la dirección ni el nombre del equipo comprometido.
Ese secreto llega al operador por la consola, por un archivo temporal o por canales de aviso como Telegram, Discord o un webhook. Bloquear una dirección IP o un dominio, la receta clásica contra un servidor de mando y control, aquí se queda corta: no hay infraestructura propia del atacante que bloquear.
BleepingComputer informó el 12 de noviembre que varios actores distintos ya abusan de la herramienta, con actividad creciente desde marzo y foco en aplicaciones web y entornos de alojamiento. La coincidencia entre grupos sin vínculo refuerza la lectura de Microsoft: el relevo compartido ahorra montar y mantener servidores propios.
Cerrar el fallo no limpia el equipo
La entrada, en los casos observados, fue una aplicación web expuesta a internet. El atacante ejecutaba comandos con curl para bajar un guion remoto, perfilar el equipo, elegir el cliente GSocket acorde con su arquitectura y dejarlo en rutas escribibles o apoyadas en memoria, como /dev/shm.
Instalado el cliente, venía el disfraz. Microsoft vio procesos renombrados para parecer hilos del núcleo del sistema, copias redundantes y persistencia repartida entre tareas cron, servicios de systemd, archivos de inicio de sesión y programas vigilantes que relanzan el cliente si muere.
Los archivos de instalación se borraban al terminar, para dejar pocas huellas. Y en pocos incidentes apareció un intento extra: explotar CVE-2026-43284, Dirty Frag, una de esas vulnerabilidades en el núcleo de Linux que dan acceso root, para escalar privilegios desde la cuenta del servicio web.
El reparto de víctimas explica a quién le toca revisar primero. Las aplicaciones web y el alojamiento sumaron el 87,1 % de los incidentes que Microsoft pudo atribuir; dentro de ese grupo, las aplicaciones PHP y el alojamiento con cPanel pesaron 63,9 % y Apache, 24,3 %.
Por sectores, educación e investigación concentraron el 30,7 % de las organizaciones afectadas y tecnología y telecomunicaciones, el 22,9 %. Microsoft atribuye ese orden a la exposición: parques web grandes y descentralizados, mantenidos fuera del equipo central, cuestan más de inventariar y de parchear a tiempo.
Para un medio, una tienda o una pyme con su sitio en un servidor Linux compartido, el mensaje práctico es incómodo: actualizar el gestor de contenidos y sus complementos cierra la puerta de entrada, pero no expulsa a quien ya dejó un cliente de relevo corriendo por dentro.
La respuesta que plantea Microsoft separa dos trabajos. Primero, investigar el equipo: retirar el cliente GSocket, sus entradas de persistencia y los archivos dejados en rutas temporales, y comprobar que las conexiones salientes hacia el relevo se detuvieron del todo.
Después, endurecer la salida: reglas de tráfico saliente con denegación por defecto y destinos permitidos contados, directorios temporales y de memoria sin permiso de ejecución donde se pueda, y revisión de tareas cron, unidades de systemd y archivos de inicio con nombres de servicio creíbles.
El dato que queda para quien administra un servidor es simple de comprobar en su propio panel: si el parche se aplicó y aun así aparecen procesos con nombres de hilos del núcleo que nadie instaló, conexiones salientes a destinos que nadie reconoce o tareas cron nuevas, el incidente no terminó con la actualización.
Fuente: Microsoft Security Blog
La conversación sigue en el foro
Comenta esta noticia, pregunta lo que quieras y comparte tu experiencia con otros lectores en el foro de Tecnología Geek. Participar es gratis: solo necesitas tu cuenta del sitio.
Entrar al foro
