El patrón se repite: el tráfico “raro” ya no parece raro. Un canal de Command & Control (C2) que pasa por servicios cloud legítimos hereda su reputación, su cifrado y su apariencia de actividad corporativa estándar. Lo que antes era “una IP en un VPS” hoy puede ser una llamada a una API de almacenamiento, una consulta a un repositorio o un pull a un endpoint de CDN.
En entornos corporativos esto impacta doble: por un lado, los controles perimetrales tienden a permitir esos dominios (porque el negocio los necesita); por otro, los equipos de IT suelen tener excepciones acumuladas (proxy, CASB, firewalls, egress) que facilitan el camuflaje. El resultado es que detectar y cortar C2 sin romper operaciones requiere disciplina y telemetría bien escogida.
Qué salió mal: por qué un C2 “legítimo” atraviesa controles que sí funcionan contra C2 tradicional
Cuando el C2 se apoya en servicios cloud, el atacante se beneficia de tres cosas que en empresa solemos considerar “buenas”: TLS por defecto, endpoints compartidos de alto prestigio y patrones de acceso que se confunden con automatización interna. A nivel de proxy o firewall, bloquear “todo el dominio” rara vez es viable si hablamos de proveedores usados por desarrolladores o por el propio negocio.
La consecuencia real es operativa: el SOC ve un flujo saliente hacia un proveedor reconocido y no lo eleva; o lo eleva, pero IT lo rebaja porque hay un pipeline que “siempre habló con eso”. En incidentes reales, el tiempo perdido suele venir de discusiones internas sobre excepciones, no de falta de indicadores técnicos.
También hay un ángulo de coste: muchos canales C2 “legítimos” usan APIs baratas y con cuotas altas. Si además el malware implementa backoff y jitter, el tráfico parece todavía más humano y menos “beaconing”. Eso desplaza el foco desde la detección por volumen a la detección por identidad (quién) y contexto (desde dónde y para qué).
Cómo se materializa: patrones de abuso sobre almacenamiento, mensajería, repositorios y funciones
La idea base es simple: el atacante necesita un buzón para instrucciones y un buzón para resultados. Los servicios cloud lo ofrecen en múltiples formatos (objetos, mensajes, issues, releases, secrets, blobs, colas). En lugar de un socket persistente, usa “polling” a una API con autenticación y respuestas JSON/HTTP normales.
En empresa, esto se mezcla con integraciones legítimas: agentes de CI/CD que descargan artefactos, scripts que consumen webhooks, funciones serverless que llaman a APIs externas. Si no se ancla la autorización a identidades y redes esperadas, el canal C2 queda protegido por nuestra propia permisividad.
- Almacenamiento de objetos como buzón: objetos que se actualizan con comandos y se leen periódicamente. En operación, se ve como GET/HEAD repetidos a un bucket/contenedor con nombres aparentemente aleatorios.
Esto duele especialmente cuando el entorno usa ese mismo proveedor para data lakes o backups. Un equipo de seguridad puede bloquear por “ruta” o “bucket” solo si tiene control de identidad (qué credencial accede) y de contexto (desde qué subred/egress), no solo por dominio.
- Repositorios y “paste” como canal de texto: issues, gists, snippets o comentarios donde el atacante publica instrucciones y el agente exfiltra resultados como commits o comentarios.
A nivel corporativo, la señal no es “accede a un repo”, sino “accede a un repo que no pertenece a la organización” o “accede con un token que no proviene del flujo de SSO corporativo”. Sin esa distinción, el ruido de desarrollo tapa el incidente.
- Mensajería/colas: colas o topics como control-plane (comandos) y data-plane (resultados). En redes, parece telemetría o integración asíncrona.
El riesgo aquí es el bypass de DLP clásico: el contenido viaja encapsulado como mensajes pequeños, muchas veces comprimidos o cifrados a nivel aplicación. Si el egress está abierto para “integraciones”, el atacante solo necesita credenciales o un token embebido.
Señales tempranas que sí funcionan: identidad, periodicidad y “contexto de uso” por encima de dominios
La detección efectiva en C2 sobre cloud legítimo no se gana con una lista de dominios (porque son los mismos que usa la empresa), sino con correlaciones de identidad y comportamiento. En incidentes, lo que marca la diferencia es responder a “¿qué workload/usuario inició esto?” y “¿es coherente con su propósito?” más que a “¿a dónde fue?”.
En la práctica, suele haber tres señales útiles: periodicidad (beaconing con jitter), uso de credenciales fuera de su entorno esperado (token en un endpoint no corporativo, desde una IP de salida que no corresponde), y creación/lectura de recursos con nomenclaturas o patrones ajenos a los estándares internos. Cuando el atacante usa servicios cloud, muchas veces deja huella en logs de API: llamadas repetitivas, errores de autorización, o “enumeración” previa.
- Accesos a APIs con identidad débil o inesperada: claves estáticas en endpoints que deberían usar SSO/OIDC, o tokens usados desde estaciones de usuario cuando deberían usarse desde runners/servicios.
Un caso típico: un token personal que aparece en telemetría del proxy desde un portátil, accediendo a un recurso “de integración”. Si tu organización espera que esas integraciones salgan desde un VPC/egress fijo, ese desvío es una alerta de alto valor.
- Patrón de “polling” constante: solicitudes pequeñas cada N segundos/minutos a un mismo recurso, con variación leve.
Esto suele pasar desapercibido si solo miras volumen. Funciona mejor si agregas por proceso/host (EDR), por user-agent y por destino lógico (ruta/API). En empresas maduras, se materializa en reglas de detección por periodicidad y por “rareza” de destino respecto al rol del activo.
Cómo hacerlo en la práctica: guardrails verificables en AWS (ejemplo) para reducir C2 sobre servicios legítimos
La forma más consistente de reducir C2 “legítimo” es limitar quién puede hablar con qué y desde dónde, y dejar trazabilidad en cada llamada. En AWS, esto se traduce en: (1) egress controlado (NAT/egress proxy), (2) acceso a servicios vía endpoints privados cuando aplique, y (3) políticas IAM que restrinjan por organización, red y rol.
Un patrón concreto: si tu estándar es que los workloads acceden a S3 solo a buckets de tu organización, fuerza ese contrato por policy. Así, aunque un malware obtenga credenciales de un rol, le costará usar S3 como buzón en un bucket externo. Lo mismo aplica a otros servicios cuando existe condición equivalente.
Ejemplo de policy IAM (ilustrativa) para limitar acceso a S3 a buckets bajo tu control y endurecer acciones sensibles. Ajusta a tus necesidades y valida con pruebas en entorno no productivo:
- Restringir por organización (S3 Access Points/condiciones de cuenta): usar condiciones como
aws:ResourceAccountpara impedir acceso a recursos de otras cuentas cuando el rol solo debería operar en cuentas propias.
En operación, esto evita el caso clásico de C2 que escribe/lee de un bucket del atacante. Si una aplicación legítima necesita acceso cross-account, se gestiona explícitamente (con roles dedicados), en vez de dejarlo abierto “por si acaso”.
- Forzar endpoints esperados: cuando uses VPC endpoints para servicios AWS, combina rutas y control de salida para que el tráfico a APIs vaya por el camino previsto, no por Internet abierta.
La ganancia aquí es doble: reduces superficie para exfiltración y aumentas visibilidad. Cuando el endpoint es privado, puedes correlacionar a nivel VPC Flow Logs/CloudTrail con más precisión y detectar desvíos (p.ej., llamadas a APIs desde subredes no autorizadas).
- Bloquear acciones “improbables” para el rol: negar explícitamente operaciones de listado o de administración si el rol solo debería leer/escribir prefijos concretos.
En incidentes reales, el atacante suele explorar (List/Enumerate) antes de usar el canal. Quitarle esa capacidad reduce el tiempo de implantación y aumenta el número de errores, lo que genera señales en CloudTrail y en el propio runtime.
Validación: verifica que CloudTrail está habilitado a nivel organización/cuenta y que capturas eventos de datos donde aporta valor (por ejemplo, en buckets críticos). Comprueba que los roles de workloads no tienen permisos comodín y que los accesos cross-account están justificados. En red, valida que el egress a Internet desde subredes de servidor pasa por los puntos de control definidos y que no existen rutas alternativas (NAT “paralelos”, SG/NACL permisivos) que permitan saltarse inspección.
Recomendaciones para entornos corporativos
Un canal C2 basado en servicios cloud legítimos funciona porque se apalanca en lo que la empresa ya permite: dominios reputados, TLS, APIs comunes y excepciones históricas. La defensa que mejor escala no es bloquear proveedores, sino poner fricción donde el negocio no la nota: identidad fuerte, permisos mínimos y rutas de salida controladas.
Operativamente, prioriza detecciones por contexto: periodicidad de llamadas, destinos no habituales para el rol del activo, y uso de credenciales fuera del flujo esperado (SSO/OIDC vs tokens estáticos). Cuando encuentres un patrón sospechoso, el objetivo no es “cerrar Internet”, sino cortar el camino concreto: revocar credenciales, restringir políticas, y obligar a que el acceso pase por endpoints/egress corporativos trazables.
Si tus guardrails son verificables (CloudTrail y data events donde toca, políticas IAM con condiciones, egress sin rutas paralelas), el C2 “legítimo” deja de ser invisible: se vuelve costoso para el atacante y más rápido de aislar sin interrumpir a los equipos que realmente necesitan esos servicios.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.