GRIDTIDE y el abuso de Google Sheets como C2: implicancias operativas para telecom, gobierno y equipos de seguridad

La campaña atribuida a UNC2814 muestra cómo un actor avanzado puede ocultar control remoto y movimiento lateral detrás de APIs legítimas. Qué cambia en monitoreo, hardening y respuesta para equipos SysAdmin, DevOps y SecOps.

Bajada. La reciente disrupción de la campaña GRIDTIDE por parte de Google Threat Intelligence Group (GTIG) y Mandiant vuelve a poner sobre la mesa un patrón que ya no puede tratarse como excepción: actores avanzados que operan sobre servicios cloud legítimos para camuflar su comando y control. En este caso, el canal fue Google Sheets API, utilizado para intercambiar instrucciones y datos en entornos de telecomunicaciones y organismos gubernamentales de múltiples regiones.

Más allá del interés técnico, el caso importa por su impacto operativo: obliga a revisar cómo distinguimos tráfico “válido” de comportamiento malicioso, cómo priorizamos detección en servidores Linux expuestos y qué evidencias preservamos cuando el atacante vive dentro de patrones aparentemente normales de SaaS.

Qué se conoce de la campaña y por qué es relevante

Según la publicación técnica de Google Cloud, la operación atribuida a UNC2814 afectó al menos 53 organizaciones en 42 países, con actividad asociada desde 2023 y seguimiento del grupo desde 2017. La intrusión usó un backdoor en C denominado GRIDTIDE, con capacidades de ejecución de comandos, subida y descarga de archivos, y persistencia a través de systemd en hosts Linux.

El dato central no es una vulnerabilidad puntual en Google, sino la utilización de funcionalidades legítimas de Google Sheets como medio de C2. Dicho de otro modo: no se rompe la plataforma, se abusa de ella. Este enfoque reduce fricción para el atacante porque el tráfico puede parecer “normal” para controles de red que privilegian reputación de dominio por encima de contexto de proceso y patrón de uso.

Coberturas de The Record y BleepingComputer coinciden en que el foco estuvo en telecom y sector público, y remarcan que este tipo de acceso puede habilitar operaciones de vigilancia sobre metadatos, sistemas de interceptación legal y datos sensibles de identidad, incluso cuando no se observe exfiltración inmediata durante la ventana de respuesta.

Técnicas observadas: lo importante para defensa

En términos prácticos, el caso combina varias técnicas conocidas con un canal C2 menos evidente:

• Ejecución y privilegios: uso de binarios disfrazados (por ejemplo, xapt) y comandos de reconocimiento para validar contexto y privilegios.
• Persistencia: creación de servicios systemd para sostener ejecución tras reinicios.
• Movimiento lateral: uso de SSH con credenciales/servicios comprometidos.
• Túneles cifrados: despliegue de VPN bridge para salida persistente.
• C2 sobre SaaS: polling y escritura en celdas de Google Sheets API para recibir comandos y transferir fragmentos de datos.

La consecuencia para los equipos de operación es clara: una estrategia basada solo en bloqueo de dominios “maliciosos” pierde eficacia cuando el actor usa servicios ampliamente permitidos por política corporativa.

Qué cambia para SysAdmin y DevOps en entornos reales

Hay tres cambios concretos que conviene priorizar en infraestructura:

1) Observabilidad de proceso + red, no red aislada

El criterio “sale a un dominio confiable, entonces está bien” ya no alcanza. Es necesario correlacionar:

• proceso origen (hash, ruta, usuario, árbol de procesos),
• destino/API invocada y frecuencia,
• comportamiento temporal (polling anómalo, ráfagas de escritura/lectura),
• cambios de persistencia (nuevas unidades systemd, cron, binarios en rutas no estándar).

2) Hardening de servidores de borde y gestión de credenciales de servicio

Dado que el vector inicial no está plenamente confirmado y el actor tiene historial en web servers y edge devices, conviene reforzar:

• inventario y parcheo acelerado en activos expuestos,
• mínimo privilegio en cuentas de servicio,
• rotación de claves y tokens,
• restricciones de egress por rol de servidor (qué APIs necesita realmente cada workload).

3) Respuesta a incidentes orientada a “abuso de confianza”

Cuando el atacante usa APIs legítimas, la pregunta operativa no es solo “qué bloqueamos”, sino “qué permisos revocamos y qué artefactos de confianza regeneramos”. En Linux esto suele incluir:

• revocar llaves SSH y credenciales de cuentas de servicio comprometidas,
• reconstruir host desde baseline confiable cuando hay indicios de root-level compromise,
• validar integridad de unidades systemd, binarios en /usr/sbin, /var/tmp y rutas transitorias,
• conservar evidencias (logs de autenticación, process accounting, netflow, auditd) antes de limpieza.

Lecciones estratégicas para 2026

El caso GRIDTIDE consolida una tendencia: el “living off trusted cloud” como evolución natural del living-off-the-land clásico. Para SOC y equipos de plataforma, esto empuja a madurar detecciones de comportamiento y a trabajar más cerca entre seguridad, operaciones de red y administración de identidades.

También recuerda que la interrupción pública de infraestructura atacante no equivale al fin del riesgo. Los propios investigadores anticipan que el actor intentará recomponer su huella con nuevos recursos y potencialmente otros proveedores SaaS. Por eso, la ventaja defensiva no está en perseguir un único IOC, sino en institucionalizar controles repetibles para patrones de abuso similares.

Acciones recomendadas (próximos 7 días)

1. Buscar persistencia anómala en Linux: unidades systemd nuevas/modificadas, binarios no inventariados en rutas críticas y ejecución desde directorios temporales.
2. Auditar egress de servidores sensibles hacia APIs SaaS: establecer baseline por rol y alertar desvíos de volumen/frecuencia.
3. Revisar cuentas de servicio: llaves activas, permisos sobredimensionados y tokens sin rotación reciente.
4. Aplicar detecciones de comportamiento para cadenas “proceso inesperado + API cloud + polling periódico”.
5. Actualizar playbooks de IR con escenarios de C2 sobre servicios legítimos y criterios de reconstrucción de host.

En síntesis, GRIDTIDE no es solo una historia de espionaje internacional: es una señal operativa para cualquier organización que dependa de SaaS y Linux en producción. La defensa efectiva pasa por contexto, correlación y disciplina de respuesta, no únicamente por listas de bloqueo.

Fuentes consultadas: Google Cloud Threat Intelligence (informe técnico de disrupción), The Record, BleepingComputer y The Register.