El tráfico de comando y control de SHEETCREEP va para sheets.googleapis.com sobre HTTPS en IPs de Google. A nivel de red, es indistinguible de un empleado editando una planilla. En Tech86, analizamos esa campaña porque representa el límite actual de la evasión de C2, y por qué la detección necesita ocurrir en el endpoint.
La campaña Sheet Attack y el descubrimiento
Según Zscaler, SHEETCREEP fue observado a partir de septiembre de 2025, con divulgación pública en enero de 2026 durante la campaña "Sheet Attack" contra el gobierno indio. En junio de 2026, Securonix publicó análisis de una variante evolucionada y accedió a la planilla de C2 activa, con 91 pestañas. Ese número circuló como "91 víctimas", pero el breakdown real, según el análisis de Securonix de la planilla de C2, cuenta otra historia: 28 pestañas eran sandboxes automatizadas, 17 eran labs de investigadores de seguridad, 17 eran blancos reales potenciales (apenas 1 de alta confianza), 16 estaban vacías (probablemente bloqueadas por AV), 3 de categorías diversas, 1 pestaña default, 1 VM de análisis y 8 con actividad indeterminada. Decir "91 víctimas" sin ese breakdown es engañoso.
La atribución es de confianza moderada. Zscaler evalúa que puede ser un nuevo grupo APT vinculado a Pakistán o un subgrupo del APT36 (Transparent Tribe). Los indicadores apuntan en esa dirección, victimología enfocada en el gobierno indio, operación desde Pakistán, abuso de nube consistente con ElizaRAT y campañas anteriores como la Operation FlightNight, pero hay diferencias: nuevas técnicas de evasión (Geo-IP, User-Agent), tooling diferente y metadatos PDF distintos.
El mecanismo: una planilla como panel de C2
SHEETCREEP es un RAT liviano en C# con aproximadamente 20 KB. Cada víctima recibe una pestaña dedicada en la planilla con formato username-hostname-4charhash. La Columna A recibe comandos del operador en Base64. La Columna B almacena la salida de los comandos en Base64. La Columna C registra timestamps. El RAT consulta la planilla cada 3 segundos vía Sheets API v4 sobre HTTPS. La autenticación usa una cuenta de servicio (service account) del GCP con llave RSA-2048 embutida en el binario para generar JWTs OAuth2.
Es elegante en la simplicidad. El operador escribe comandos en una celda, el RAT lee, ejecuta y escribe el resultado en la celda adjacente. Todo trafica por la API de Google, sobre HTTPS, para IPs de Google. Ningún servidor dedicado. Ningún dominio sospechoso. Ninguna infraestructura propia.
Dos variantes, dos generaciones operacionales
La variante original, documentada por Zscaler, usaba criptografía TripleDES ECB, ejecutaba comandos vía cmd.exe oculto y mantenía la configuración en texto plano. La variante evolucionada, identificada por Securonix, introdujo ofuscación XOR con llave "discrete", PowerShell runspace in-process (sin proceso powershell.exe hijo) y autenticación vía service account del GCP.
La evolución es significativa. TripleDES ECB para XOR con llave embutida en el código no es mejoría criptográfica, es pragmatismo operacional: XOR es más difícil de detectar por análisis de firma estática, mientras TripleDES exige referencias a System.Security.Cryptography que son indicadores obvios. PowerShell in-process elimina el artefacto más obvio: un proceso powershell.exe hijo. La service account del GCP sustituye credenciales de usuario, reduciendo el riesgo de revocación. Cada cambio cierra una ventana de detección.
Zscaler también encontró indicadores de código generado por IA en SHEETCREEP. Si confirmado, eso representa un marco: un APT sur-asiático usando IA para generar código de malware operacional.
El desafío de detección que cambia el paradigma
Todo tráfico C2 de SHEETCREEP va para sheets.googleapis.com sobre HTTPS en IPs de Google (AS15169). A nivel de red, es indistinguible de tráfico legítimo de Google Workspace. Tu empresa probablemente permite ese tráfico. Tu firewall no bloquea. Tu IDS no detecta. Tu SIEM no alerta.
La detección necesita enfocarse en el endpoint. Procesos no-browser haciendo conexiones sostenidas a APIs de Google son la primera señal. Tareas agendadas anómalas, como WindowsVaultSyncService con descripción "Windows Edge Core Update Task Machine Discord Update", son la segunda. Caminos de archivo sospechosos como %LOCALAPPDATA%\Microsoft\Vault\vaultsvc.exe con atributos Hidden+System son la tercera. Autenticación OAuth2 de service account originada de binarios fuera de contexto corporativo es la cuarta.
El anti-forense agrava el problema. Si el RAT detecta herramientas de análisis como dnSpy, Wireshark o Network Monitor, fuerza un reinicio vía Restart-Computer -Force. El cargador de carga (dropper) se auto-elimina y sustituye por un PDF decoy. El binario recibe atributos Hidden+System. Eso significa que la ventana de análisis es corta y el investigador necesita protección antes de iniciar el análisis.
Contexto histórico: evolución, no novedad
Google Sheets como C2 no es nuevo. El GC2-sheet apareció en 2021. El google_RAT también en 2021. APT41 usó GC2 en 2022, conforme documentado por Google TAG en 2023. Lo que es nuevo en SHEETCREEP es la adopción por un APT sur-asiático con mejorías operacionales: autenticación vía service account, pestañas dedicadas por víctima, ofuscación XOR, PowerShell in-process y anti-forense agresivo.
La tendencia es clara. Amenazas avanzadas están migrando para infraestructura de SaaS legítima como canal C2. El tráfico es permitido por defecto. La infraestructura es gratuita o barata. La detección a nivel de red es casi imposible. El foco necesita estar en el endpoint.
Por qué EDR es la respuesta
En Tech86, la campaña SHEETCREEP refuerza lo que defendemos hace tiempo: la detección de C2 basada en infraestructura de SaaS legítima necesita ocurrir en el endpoint. Nuestro EDR monitorea procesos no-browser haciendo conexiones sostenidas a APIs de SaaS, detecta tareas agendadas con descripciones anómalas, identifica binarios en caminos sospechosos con atributos de ocultación y correlaciona autenticación OAuth2 fuera de contexto.
Cuando el C2 se esconde en el tráfico legítimo de Google Workspace, la red no ve. El endpoint ve. Y el EDR es la herramienta que transforma lo que el endpoint ve en acción de respuesta.
El atacante evolucionó. Tu detección necesita estar donde el atacante no puede esconderse: en el proceso, en el binario, en el comportamiento del endpoint.