Entre el 18 y el 25 de febrero de 2026, Google Threat Intelligence Group (GTIG), Mandiant y varios socios ejecutaron una operación coordinada para frenar una campaña de ciberespionaje a escala global. El actor, identificado como UNC2814 y vinculado por los investigadores a un posible nexo con la República Popular China (PRC), llevaba años operando con un perfil discreto y un objetivo constante: operadores de telecomunicaciones y organismos gubernamentales en múltiples regiones.
Según los datos publicados por GTIG, cuando se llevó a cabo la disrupción había intrusiones confirmadas en 42 países y un total de 53 víctimas verificadas, con señales de actividad sospechosa en al menos una veintena de países adicionales. Un matiz relevante para no mezclar titulares: GTIG indica que esta actividad no se solapa con lo reportado públicamente como “Salt Typhoon”, ni en víctimas ni en el modo de operar.
La razón por la que este caso merece atención no es solo el volumen. Es el enfoque. En lugar de apoyarse en una vulnerabilidad concreta del proveedor, los atacantes explotaron funciones legítimas de servicios en la nube para camuflar su tráfico como si fuera normal. Es como entrar a un edificio sin forzar la puerta porque alguien dejó una tarjeta de visita “válida” encima del mostrador.
El actor: UNC2814 y el patrón de telecos como objetivo
UNC2814 aparece descrito como un grupo persistente y difícil de rastrear, activo al menos desde 2017. Su historial encaja con campañas de espionaje en telecomunicaciones, un sector especialmente valioso porque concentra metadatos, identidades y rutas de comunicación. En una teleco, el atacante no necesita “leer cada conversación” para sacar valor: basta con saber quién habla con quién, cuándo, desde dónde y con qué frecuencia. Ese tipo de información, combinada con otras fuentes, permite perfilar relaciones y prioridades con una precisión que recuerda a mirar un mapa del metro: no ves la vida de cada pasajero, pero entiendes los flujos.
GTIG y Mandiant señalan que, aunque durante esta campaña no observaron directamente la exfiltración de datos sensibles en todos los casos, el tipo de acceso conseguido podría facilitar técnicas históricas atribuidas a intrusiones de nexo PRC en telecos: obtención de registros de llamadas, SMS no cifrados o incluso abuso de capacidades de interceptación legal cuando existen y se comprometen.
Detección inicial: una pista pequeña en un servidor CentOS
La investigación que aceleró el entendimiento del caso partió de una alerta en un servidor CentOS dentro de un entorno monitorizado con Google Security Operations (SecOps). Mandiant describe una cadena de procesos sospechosa: un binario situado en una ruta típica de “tierra de nadie” del sistema, ejecutando una shell con privilegios elevados para confirmar que había alcanzado root. Es el gesto clásico del intruso que se mira al espejo para comprobar si ya lleva uniforme: “¿tengo permisos máximos?”.
El nombre del binario también tenía intención: “xapt”, probablemente elegido para parecer una herramienta legítima y despistar revisiones rápidas. Este tipo de detalle es importante porque muestra un patrón cada vez más frecuente: el atacante no siempre inventa, a veces imita. Y cuando imita bien, el defensor necesita contexto, no solo firmas.
Después del acceso: movimiento lateral y persistencia con systemd
Una vez dentro, el actor empleó técnicas de living-off-the-land (LotL), es decir, herramientas y comandos habituales del sistema para reducir huella y evitar que un antivirus “salte” por algo exótico. Mandiant reporta movimiento lateral con SSH usando una cuenta de servicio y varias actividades de reconocimiento, escalada de privilegios y preparación de persistencia.
El punto clave fue cómo se aseguró de volver: la persistencia se montó mediante systemd, creando un servicio que arrancaba el malware desde ubicaciones que, de nuevo, suenan más “normales” de lo que deberían. También se observa el uso de nohup para que el backdoor siguiera vivo incluso si la sesión se cerraba. En términos cotidianos, es como dejar una cafetera programada: aunque te vayas de la cocina, el café se seguirá preparando a la hora prevista.
GRIDTIDE: el backdoor que convierte Google Sheets en canal de mando y control
El corazón técnico del caso es GRIDTIDE, descrito como un backdoor en C capaz de ejecutar comandos de shell, subir y descargar archivos. Lo llamativo no es la lista de capacidades, sino su “línea de comunicación”: Google Sheets usado como infraestructura de command-and-control (C2) mediante llamadas a la Google Sheets API.
La metáfora aquí es bastante clara: en lugar de hablar por un walkie-talkie (un C2 clásico), el atacante deja notas en una pizarra compartida dentro de una oficina que todo el mundo usa. El tráfico de red que produce esa actividad puede parecer el de cualquier integración corporativa legítima. GTIG insiste en un punto que conviene subrayar: no se trata de un fallo de seguridad explotado en el producto, sino de un abuso de funcionalidad legítima para disfrazar comunicaciones maliciosas.
GRIDTIDE requiere una clave criptográfica de 16 bytes presente en el host para descifrar su configuración con AES-128 en modo CBC. Dentro de esa configuración están los datos que permiten autenticarse frente a la API, incluyendo credenciales de cuenta de servicio y el identificador de la hoja de cálculo. Con eso, el malware “habla” con la hoja como si fuera una app interna más.
C2 por celdas: cuando A1 se convierte en buzón de órdenes
La operativa de GRIDTIDE se basa en una mecánica de sondeo por celdas. El malware consulta una celda específica buscando órdenes y, si no encuentra nada, espera; si encuentra una orden, la ejecuta y publica el resultado o el estado en el propio documento. GTIG detalla incluso cómo el backdoor limpia la hoja al arrancar, borrando un rango amplio de filas y columnas para evitar interferencias de sesiones anteriores. Es un comportamiento muy de “mesa limpia” antes de empezar a trabajar, solo que aquí el trabajo es malicioso.
El formato de comandos también está estructurado para operar como un protocolo: hay instrucciones para ejecutar comandos, para subir datos al equipo comprometido y para descargar información desde el equipo hacia la hoja, fragmentando el contenido en trozos manejables. Todo ello viaja codificado con una variante URL-safe de Base64, sustituyendo caracteres típicos para reducir problemas con filtros y parsers.
Antes de obedecer, GRIDTIDE recopila información del sistema, como usuario, nombre del equipo, detalles del sistema operativo, IP local, ruta de trabajo, idioma y zona horaria. Esa “tarjeta de visita” del equipo comprometido se guarda en una celda destinada a inventario del atacante. Es la versión digital de entrar en una casa y, antes de hacer nada, mirar el buzón, las llaves y el cuadro eléctrico.
PII y espionaje: el valor real del acceso
Mandiant describe un caso en el que el actor depositó GRIDTIDE en un endpoint con información personal identificable (PII): nombre completo, teléfono, fecha y lugar de nacimiento, y distintos identificadores nacionales o electorales. En telecos, este tipo de datos puede servir para identificar personas de interés y vincular identidades a números y patrones de comunicación. No hace falta imaginar ciencia ficción: con PII y metadatos, el atacante puede seguir a alguien como quien sigue el rastro de un recibo de compra, sumando pequeñas pistas hasta formar un perfil.
La disrupción: cortar proyectos, cuentas y la infraestructura asociada
La respuesta de GTIG se centró en quitarle al actor el “suelo” bajo los pies. Entre las medidas, se incluyen la terminación de Google Cloud Projects controlados por el atacante, la desactivación de cuentas implicadas y la revocación de acceso a llamadas de la Google Sheets API utilizadas como canal C2. Paralelamente, en coordinación con socios, se deshabilitó infraestructura conocida y se aplicaron acciones como el sinkholing de dominios actuales e históricos para degradar la capacidad de mando y control.
Otro elemento práctico fue la publicación de indicadores de compromiso (IOCs) vinculados a infraestructura activa desde al menos 2023, junto con reglas y señales de detección para clientes de Google SecOps a través de paquetes de caza de Mandiant. En la práctica, esto ayuda a que defensores que no estaban en la lista de víctimas confirmadas puedan buscar huellas compatibles con este modo de operar.
Qué deberían aprender los equipos defensivos
Este incidente pone el foco en una realidad incómoda: los servicios cloud que hacen que el trabajo diario sea ágil también pueden convertirse en rutas de comunicación sigilosas para un atacante. No significa que haya que desconfiar de todo, sino que hay que vigilar lo que normalmente se da por sentado. Si un proceso no relacionado con un navegador empieza a hablar con endpoints de Google Sheets API, merece una segunda mirada. Si aparecen binarios en rutas inusuales con nombres “demasiado normales”, también.
La idea clave es ajustar el radar: no solo buscar “lo prohibido”, sino detectar “lo legítimo fuera de lugar”. Como ver un carrito de supermercado dentro de una biblioteca: el objeto es normal, el contexto no.
☞ El artículo completo original de Natalia Polo lo puedes ver aquí