La exfiltración vía snapshot sharing es uno de esos vectores que sorprenden a equipos maduros: no requiere volcar millones de filas por la red, ni disparar patrones típicos de DLP basados en consultas o transferencia de datos. Basta con que alguien tenga permisos aparentemente “inofensivos” de lectura/operación sobre snapshots para convertir una copia consistente de una base de datos o volumen en un activo exportable a otra cuenta.
En la práctica, el impacto es que un atacante puede llevarse bases de datos enteras (o discos completos) con un rastro operativo que se confunde con tareas legítimas de backup, DR o migración. Y lo más delicado: muchas organizaciones monitorizan el acceso a datos (queries, buckets, egress), pero no tratan el cambio de permisos de snapshots como un evento crítico.
Qué salió mal: permisos “de lectura” que permiten compartir snapshots
El escenario típico no empieza con un “admin comprometido”, sino con un rol con alcance operativo: alguien que puede listar y describir recursos, crear snapshots por motivos de soporte, o gestionar backups. En AWS, ese rol puede operar sobre RDS snapshots o EBS snapshots; en Azure, sobre Managed Disk snapshots o copias de Azure SQL según el modelo de backup/restore usado por la organización.
El giro está en que la exfiltración no necesita un SELECT * ni un export a CSV. Si el atacante puede crear un snapshot y después modificar sus permisos, puede compartirlo con una cuenta externa (suya) o, en el peor caso, marcarlo como público de forma temporal. En empresa esto suele pasar por dos motivos: políticas IAM demasiado amplias (“para no bloquear operaciones”) o ausencia de guardrails a nivel organización que impidan compartir fuera del perímetro corporativo.
Cómo se materializa la exfiltración sin disparar DLP
En vez de extraer datos por la capa lógica (consultas), el atacante se mueve a la capa de plataforma: genera un snapshot consistente y cambia su visibilidad. La DLP que inspecciona queries, logs de aplicación o patrones de exfiltración por endpoints suele quedarse ciega porque el “dato” viaja encapsulado como un artefacto de infraestructura.
En AWS, el patrón más común es: snapshot (RDS o EBS) y luego compartición (agregar permisos a otra cuenta) o publicación (hacerlo público). En un entorno con varias cuentas, esto puede camuflarse como intercambio entre cuentas para DR o analítica; la diferencia es el destino: una cuenta ajena a la organización. En incidentes reales, el atacante suele elegir ventanas de mantenimiento o picos de actividad para que el evento se diluya en el ruido operativo.
- Compartir con cuenta externa: se añade un principal (otra cuenta) como autorizado a restaurar/copiar el snapshot. En la cuenta del atacante, se restaura a un recurso bajo su control, fuera de tu visibilidad.
- Hacerlo público temporalmente: se cambia el atributo de visibilidad, se copia/restaura desde fuera y luego se revierte. Si no hay alertas en tiempo real, el “público” puede durar minutos y aun así ser suficiente.
Consecuencia práctica: incluso con egress controlado, el atacante no necesita “sacar” datos por tu red; traslada un artefacto de cloud a otra cuenta y lo consume allí. El coste para el atacante es bajo y el riesgo de detección, si no miras cambios de atributos, también.
Señales tempranas en logs: lo que sí deja rastro (y cómo correlacionarlo)
La buena noticia es que el snapshot sharing es auditable: el cambio de permisos no es “mágico”, deja eventos en logs de control. La mala noticia es operativa: muchas organizaciones no han definido reglas específicas y esos eventos no están priorizados. El resultado es que el SIEM los ingiere, pero nadie los investiga.
En AWS, una señal crítica es el evento de CloudTrail asociado al cambio de atributos/permisos del snapshot. En incidentes con RDS, el evento relevante suele ser ModifyDBSnapshotAttribute (comúnmente citado como “ModifySnapshotAttribute” en detecciones genéricas). Para EBS snapshots existen operaciones equivalentes para modificar permisos de creación/volcado. A nivel de investigación, lo importante es responder: quién lo ejecutó, desde dónde (IP/user agent), qué snapshot afectó y a qué cuenta se concedió acceso.
- Evento de cambio de permisos: crea una alerta de alta severidad cuando el payload incluya atributos de compartición o visibilidad pública. En empresa, esto reduce falsos positivos si exiges que el cambio sea “hacia fuera” (cuentas no permitidas) o que el atributo pase a “public”.
- Correlación con creación reciente de snapshots: si ves un snapshot creado y, en un margen corto, se modifican permisos, el patrón es sospechoso salvo que esté justificado por un pipeline conocido. Este “encadenamiento” suele delatar el abuso.
En Azure/GCP la lógica es la misma: vigilar cambios de permisos en snapshots/discos manejados y correlacionar con identidades y proyectos/suscripciones destino. El aprendizaje operativo aquí es no quedarse en “hubo un snapshot”: lo determinante es el cambio de ACL/Sharing y el destino fuera del perímetro.
Cómo hacerlo en la práctica: detección y alertas en tiempo real
Si tuviera que priorizar una sola acción, sería montar una alerta near-real-time cuando un snapshot pase a estado “shared” o “public”, o cuando se añada un principal externo. Esto convierte un vector silencioso en uno detectable antes de que el atacante complete la copia/restauración en su cuenta.
En AWS, implementa detección sobre CloudTrail (idealmente Organization Trail) y enruta a EventBridge/SIEM. Como mínimo, filtra eventos de modificación de atributos de snapshots y dispara alarma si el cambio implica:
- Adición de cuentas no permitidas: valida contra una allowlist de cuentas de la organización (o de un conjunto de cuentas de DR/analytics). En empresas con múltiples OUs, esta allowlist se gestiona como configuración central, no “en el código” de cada equipo.
- Visibilidad pública: trata cualquier intento de “public” como incidente, incluso si se revierte rápido. En escenarios reales, el atacante no necesita horas; minutos bastan.
Para bajar ruido, añade contexto automático al ticket/alerta: tags del recurso, dueño (Owner/CostCenter), región, ARN del snapshot, identidad (principalId), y si el rol proviene de un pipeline conocido. Esa “enriquecimiento” es la diferencia entre una alerta accionable y una que se ignora.
Validación: ejecuta un test controlado en un entorno no productivo creando un snapshot y simulando un intento de compartición. Verifica que CloudTrail registra el evento, que tu regla lo detecta, que el alertado incluye el principal destino y que el runbook indica cómo revertir permisos y congelar credenciales.
Recomendaciones para entornos corporativos
Este vector funciona porque desplaza la exfiltración desde el plano de datos (consultas) al plano de control (permisos de snapshots). En operación real, eso significa que un rol “de lectura” o “de backup” puede convertirse en un canal de salida si no existe un guardrail explícito que impida compartir fuera de la organización.
La defensa efectiva combina dos capas: bloqueo y detección rápida. Bloquea la compartición externa con SCPs en AWS Organizations o Azure Policy (según plataforma) para negar cambios de permisos hacia cuentas/suscripciones no corporativas, y acompáñalo con alertas en tiempo real ante cualquier transición a “shared/public”. Cuando estas dos piezas están bien afinadas, el snapshot deja de ser un método silencioso y pasa a ser un evento de seguridad claramente visible y accionable.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.