AWS - S3 Post Exploitation

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

S3

Para más información consulta:

AWS - S3, Athena & Glacier Enum

Información sensible

A veces podrás encontrar información sensible legible en los buckets. Por ejemplo, terraform state secrets.

Pivoting

Diferentes plataformas podrían estar usando S3 para almacenar activos sensibles.\ For example, airflow could be storing DAGs code in there, or web pages could be directly served from S3. Un atacante con permisos de escritura podría modify the code desde el bucket para pivot hacia otras plataformas, o takeover accounts modificando archivos JS.

S3 Ransomware

En este escenario, el attacker creates a KMS (Key Management Service) key in their own AWS account o en otra cuenta comprometida. Luego hacen que esta key accessible to anyone in the world, permitiendo que cualquier AWS user, role, o account cifre objetos usando esta key. Sin embargo, los objetos no pueden ser descifrados.

El atacante identifica un bucket S3 objetivo y obtiene acceso a nivel de escritura en él usando varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el atacante obtuvo acceso al propio entorno AWS. El atacante típicamente apunta a buckets que contienen información sensible como personally identifiable information (PII), protected health information (PHI), logs, backups, y más.

Para determinar si el bucket puede ser objetivo de ransomware, el atacante verifica su configuración. Esto incluye comprobar si S3 Object Versioning está habilitado y si multi-factor authentication delete (MFA delete) está habilitado. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el atacante puede disable Object Versioning. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el atacante cifrar con ransomware ese bucket específico.

Usando la AWS API, el atacante replaces each object in the bucket with an encrypted copy using their KMS key. Esto cifra efectivamente los datos en el bucket, haciéndolos inaccesibles sin la key.

Para aumentar la presión, el atacante programa la eliminación de la KMS key usada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la key sea eliminada y los datos se pierdan de forma permanente.

Finalmente, el atacante podría subir un archivo final, usualmente llamado “ransom-note.txt”, que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin cifrado, probablemente para llamar la atención del objetivo y hacerle saber del ataque de ransomware.

SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)

Otra variante es abusar de SSE-C (S3 server-side encryption with customer-provided keys). Con SSE-C, el client provides the encryption key on every request y AWS no almacena la key. Esto significa que si un atacante reescribe objetos usando their own SSE-C key, los datos de la víctima se vuelven ininteligibles a menos que la víctima pueda proporcionar esa key controlada por el atacante.

  • Preconditions: Compromised AWS credentials (or any principal with the right permissions) y la capacidad de rewrite objects (por ejemplo, s3:PutObject en las keys/prefijos objetivo). Esto suele ir acompañado de la capacidad de establecer políticas de lifecycle destructivas (ver más abajo), p. ej. s3:PutLifecycleConfiguration.
  • Attack chain:
  1. Attacker genera una key aleatoria de 256 bits (AES-256) y la guarda.
  2. Attacker rewrites objetos existentes (mismas object keys) usando headers SSE-C de modo que el objeto almacenado ahora está cifrado con la key del atacante.
  3. Victim no puede descargar/descifrar sin proporcionar la SSE-C key (incluso si los permisos IAM son correctos).
  4. Attacker puede eliminar la key (o simplemente nunca proporcionarla) para hacer los datos irrecuperables.

Example (conceptual) CLI usage:

# Upload/overwrite an object encrypted with attacker-provided SSE-C key
aws s3 cp ./file s3://<BUCKET>/<KEY> \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>

# Download requires providing the same key again
aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
Añadiendo Presión: Abuso del “Temporizador” del ciclo de vida

Para eliminar opciones de recuperación (como versiones antiguas), los atacantes pueden combinar reescrituras SSE-C con reglas de ciclo de vida que expiran objetos y/o eliminan versiones no actuales tras un corto período:

  • s3:PutLifecycleConfiguration en el bucket permite a un atacante programar eliminaciones sin emitir operaciones de delete explícitas para cada objeto/versión.
  • Esto tiene especial impacto cuando versionado está habilitado, porque puede eliminar la “versión anterior buena” que, de otro modo, permitiría la recuperación.
Detección y mitigaciones
  • Prefiera SSE-KMS (o SSE-S3) sobre SSE-C a menos que tenga una razón operacional sólida para permitir SSE-C.
  • Monitoree/alerte las solicitudes PutObject que usen cabeceras SSE-C (eventos de datos de CloudTrail para S3).
  • Monitoree/alerte sobre PutBucketLifecycleConfiguration inesperados (cambios de ciclo de vida).
  • Monitoree/alerte sobre picos repentinos en actividad de sobrescritura (mismas keys actualizadas rápidamente) y eliminaciones de delete-marker/version.
  • Restringa permisos de alto riesgo: limite s3:PutObject a los prefijos necesarios; restrinja fuertemente s3:PutLifecycleConfiguration y s3:PutBucketVersioning; considere requerir MFA para acciones administrativas sensibles (cuando aplique) y use roles administrativos separados con aprobaciones.
  • Postura de recuperación: use versioning, backups, y copias inmutables/offline (S3 replication a una cuenta protegida, backup vaults, etc.); proteja las versiones no actuales contra eliminaciones agresivas y respalde cambios de ciclo de vida con SCPs / guardrails.

s3:RestoreObject

Un atacante con el permiso s3:RestoreObject puede reactivar objetos archivados en Glacier o Deep Archive, haciéndolos accesibles temporalmente. Esto permite la recuperación y exfiltración de datos archivados históricamente (backups, snapshots, logs, certificaciones, secretos antiguos) que normalmente estarían fuera de alcance. Si el atacante combina este permiso con permisos de lectura (p. ej., s3:GetObject), puede obtener copias completas de datos sensibles.

aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'

s3:Delete*

Un atacante con el permiso s3:Delete* puede eliminar objetos, versiones y buckets completos, interrumpir copias de seguridad y causar pérdida de datos inmediata e irreversible, destrucción de evidencia y comprometer artefactos de copia de seguridad o recuperación.

# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>

Para más información check the original research.

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks