Exfiltración de datos en S3: lo que pueden probar los logs

En resumen. A la pregunta "¿se llevaron los datos?" solo se puede responder para objetos de S3 si los eventos de datos de S3 en CloudTrail o los registros de acceso al servidor de S3 estaban activados antes del incidente. Con ellos: cuente los GetObject por principal, bucket y hora, sume bytesTransferredOut / Bytes Sent y enumere las claves de los objetos. Sin ellos: puede demostrar que el atacante podía leer (permisos, ListBuckets; ListObjects también es un evento de datos) y si un bucket se hizo público o una instantánea se compartió (eventos de administración), pero no qué objetos salieron. Revise también los canales que no requieren ninguna descarga: políticas públicas, ACL, instantáneas de EBS/RDS y AMI compartidas.

El robo de datos es lo primero que preguntan abogados, clientes y reguladores, y es donde la cobertura de los registros más pesa. Este artículo explica lo que cada fuente de registros de AWS puede demostrar sobre la exfiltración desde S3 y mediante instantáneas, y cómo redactar un informe honesto cuando no puede demostrarlo.

Dos fuentes para las lecturas de objetos

Lo ideal es disponer de ambos: CloudTrail aporta una identidad fiable y los registros de acceso, un segundo registro independiente. Con cualquiera de los dos basta para responder a la pregunta.

Cómo leer los eventos de datos de CloudTrail

Un evento de datos correspondiente a la lectura de un objeto tiene este aspecto (recortado):

{
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "eventCategory": "Data",
  "userIdentity": {"arn": "arn:aws:iam::111122223333:user/backup-admin", "accessKeyId": "AKIA..."},
  "sourceIPAddress": "203.0.113.77",
  "requestParameters": {"bucketName": "acme-customer-exports", "key": "exports/customers-0001.csv.gz"},
  "additionalEventData": {"bytesTransferredOut": 12345678}
}

Preguntas y cómo responderlas:

• ¿Cuántos objetos? Cuente los valores distintos de requestParameters.key por principal y bucket.
• ¿Cuántos datos? Sume bytesTransferredOut. Las lecturas parciales (solicitudes por rango) cuentan sus bytes reales.
• ¿Qué objetos? La lista de claves es su inventario de divulgación. Expórtela.
• ¿Desde dónde? sourceIPAddress y userAgent: un cliente boto3 en un VPS que descarga 300 objetos en 20 minutos no es su tarea de copia de seguridad.
• Antes de las lecturas: ListObjects / ListObjectsV2 (también eventos de datos) y los eventos de administración ListBuckets, GetBucketPolicy, GetBucketAcl y GetBucketLocation del mismo principal.

La técnica correspondiente es MITRE ATT&CK T1530 Data from Cloud Storage.

Cómo leer los registros de acceso al servidor de S3

Los registros de acceso al servidor contienen una línea por solicitud; los campos que importan aquí son el bucket, la hora, la IP remota, el solicitante, la operación, la clave, el código de estado HTTP y los bytes enviados (formato del registro).

79a59df9... acme-customer-exports [14/Sep/2026:09:15:04 +0000] 203.0.113.77
arn:aws:iam::111122223333:user/backup-admin 3E57427F3EXAMPLE REST.GET.OBJECT
exports/2026/customers/customers-0001.csv.gz "GET /exports/... HTTP/1.1" 200 - 12345678 ...

(Aquí se ha partido en varias líneas para facilitar la lectura; cada registro ocupa una sola línea.)

Filtre por REST.GET.OBJECT con estado 200 o 206 y agrupe por solicitante y bucket. Un solicitante - indica una solicitud anónima: es lo esperado en un bucket de sitio web público y una fuga en cualquier otro caso.

Exfiltración sin descargas

Algunos de los robos de datos más eficaces en AWS nunca producen un GetObject en su cuenta, porque el atacante hace que los datos sean accesibles y los copia desde otro lugar. Todos ellos son eventos de administración, así que son visibles incluso sin eventos de datos:

Una instantánea compartida significa que los datos pueden copiarse a la cuenta del atacante sin dejar ningún rastro adicional en la suya. Trate su contenido como divulgado.

Cuando no dispone de ninguna de las dos fuentes

Sea preciso en el informe. Puede afirmar:

• qué principales tenían permiso para leer qué buckets (políticas de IAM, políticas de bucket);
• si el atacante enumeró buckets o leyó políticas de bucket (eventos de administración);
• si algún bucket se hizo público o se compartió alguna instantánea;
• si los flujos de red de sus instancias muestran transferencias salientes voluminosas (análisis de VPC Flow Logs), algo útil para datos preparados en EC2, pero no para descargas directas desde S3, que no atraviesan su VPC.

No puede afirmar que los objetos no se leyeron. "No hay evidencias de acceso" solo tiene sentido cuando esas evidencias podrían haber existido. El artículo sobre las limitaciones explica cómo redactarlo.

El reloj de la notificación

Si puede haber datos personales implicados, los plazos legales empiezan a correr desde que se tiene conocimiento del incidente, no desde el final de la investigación: según el RGPD, 72 horas para notificar a la autoridad de control (artículo 33). Implique pronto a su delegado de protección de datos y entréguele la lista de objetos en cuanto la tenga.

En el analizador

AWS Forensics señala las descargas masivas desde cualquiera de las dos fuentes (100 o más objetos de un mismo bucket por un mismo principal en una hora), las descargas anónimas desde direcciones públicas, las políticas de bucket y ACL públicas, la eliminación de S3 Block Public Access, las instantáneas o AMI compartidas con otras cuentas y la lectura masiva de secretos. Las notas de Cobertura indican explícitamente cuándo no se han aportado ni eventos de datos ni registros de acceso. Pivote sobre el bucket en la pestaña Entidades para ver todas las solicitudes que lo afectan, de ambas fuentes. Para el contexto completo, empiece por la visión general de la respuesta a incidentes.