AWS - S3 Post Exploitation

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

S3

For more information check:

AWS - S3, Athena & Glacier Enum

Sensitive Information

Às vezes você poderá encontrar informação sensível legível nos buckets. Por exemplo, terraform state secrets.

Pivoting

Diferentes plataformas podem usar o S3 para armazenar ativos sensíveis.
Por exemplo, airflow poderia estar armazenando DAGs code lá, ou web pages poderiam ser servidas diretamente do S3. Um atacante com permissões de escrita poderia modify the code do bucket para pivot para outras plataformas, ou takeover accounts modificando arquivos JS.

S3 Ransomware

Neste cenário, o attacker creates a KMS (Key Management Service) key in their own AWS account ou em outra conta comprometida. Em seguida, eles tornam essa key accessible to anyone in the world, permitindo que qualquer usuário, role, ou conta AWS criptografe objetos usando essa chave. Porém, os objetos não podem ser descriptografados.

O atacante identifica um alvo, S3 bucket and gains write-level access a ele usando vários métodos. Isso pode ser devido a uma má configuração do bucket que o expõe publicamente ou ao atacante obtendo acesso ao próprio ambiente AWS. O atacante normalmente mira buckets que contêm informação sensível, como personally identifiable information (PII), protected health information (PHI), logs, backups, e mais.

Para determinar se o bucket pode ser alvo de ransomware, o atacante verifica sua configuração. Isso inclui verificar se o S3 Object Versioning está habilitado e se o multi-factor authentication delete (MFA delete) is enabled. Se o Object Versioning não estiver habilitado, o atacante pode prosseguir. Se o Object Versioning estiver habilitado mas o MFA delete estiver desabilitado, o atacante pode disable Object Versioning. Se tanto o Object Versioning quanto o MFA delete estiverem habilitados, torna-se mais difícil para o atacante realizar ransomware nesse bucket específico.

Usando a AWS API, o atacante replaces each object in the bucket with an encrypted copy using their KMS key. Isso efetivamente criptografa os dados no bucket, tornando-os inacessíveis sem a chave.

Para aumentar ainda mais a pressão, o atacante agenda a exclusão da chave KMS usada no ataque. Isso dá ao alvo uma janela de 7 dias para recuperar seus dados antes que a chave seja deletada e os dados se tornem permanentemente perdidos.

Finalmente, o atacante pode enviar um arquivo final, normalmente chamado “ransom-note.txt”, que contém instruções para o alvo sobre como recuperar seus arquivos. Este arquivo é enviado sem criptografia, provavelmente para chamar a atenção do alvo e avisá-lo do ataque de ransomware.

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

Outra variante é o abuso do SSE-C (S3 server-side encryption with customer-provided keys). Com SSE-C, o client provides the encryption key on every request e AWS does not store the key. Isso significa que se um atacante reescrever objetos usando their own SSE-C key, os dados da vítima se tornam ilegíveis a menos que a vítima consiga fornecer essa chave controlada pelo atacante.

  • Pré-requisitos: Credenciais AWS comprometidas (ou qualquer principal com as permissões adequadas) e a capacidade de rewrite objects (por exemplo, s3:PutObject nas chaves/prefixos alvo). Isso costuma ser combinado com a capacidade de definir políticas de lifecycle destrutivas (veja abaixo), por exemplo, s3:PutLifecycleConfiguration.
  • Attack chain:
  1. O atacante gera uma chave aleatória de 256 bits (AES-256) e a mantém.
  2. O atacante rewrites objetos existentes (mesmas chaves de objeto) usando cabeçalhos SSE-C de forma que o objeto armazenado agora está criptografado com a chave do atacante.
  3. A vítima não consegue fazer download/descriptografar sem fornecer a chave SSE-C (mesmo que as permissões IAM estejam corretas).
  4. O atacante pode deletar a chave (ou simplesmente nunca fornecê-la) para tornar os dados irrecuperáveis.

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>
Aumentando a pressão: abuso do “temporizador” de ciclo de vida

Para remover opções de recuperação (como versões antigas), atacantes podem combinar regravações SSE-C com regras de ciclo de vida que expiram objetos e/ou excluem versões não atuais após um curto período:

  • s3:PutLifecycleConfiguration no bucket permite que um atacante agende exclusões sem emitir operações de delete explícitas para cada objeto/versão.
  • Isso é especialmente impactante quando versioning está habilitado, porque pode remover a “versão anterior boa” que, de outra forma, permitiria a recuperação.
Detecção e Mitigações
  • Prefira SSE-KMS (ou SSE-S3) em vez de SSE-C, a menos que você tenha uma forte razão operacional para permitir SSE-C.
  • Monitore/alerte sobre requisições PutObject usando cabeçalhos SSE-C (CloudTrail data events para S3).
  • Monitore/alerte sobre PutBucketLifecycleConfiguration inesperados (mudanças de ciclo de vida).
  • Monitore/alerte sobre picos súbitos em atividade de sobrescrita (mesmas chaves atualizadas rapidamente) e exclusões de delete-marker/versões.
  • Restrinja permissões de alto risco: limite s3:PutObject aos prefixos necessários; restrinja fortemente s3:PutLifecycleConfiguration e s3:PutBucketVersioning; considere exigir MFA para ações administrativas sensíveis (quando aplicável) e use funções administrativas separadas com aprovações.
  • Postura de recuperação: use versioning, backups e cópias imutáveis/offline (S3 replication para conta protegida, backup vaults, etc.); proteja versões não atuais contra exclusão agressiva e proteja mudanças de ciclo de vida com SCPs / guardrails.

s3:RestoreObject

Um atacante com a permissão s3:RestoreObject pode reativar objetos arquivados no Glacier ou Deep Archive, tornando-os temporariamente acessíveis. Isso permite recuperação e exfiltração de dados historicamente arquivados (backups, snapshots, logs, certificações, segredos antigos) que normalmente estariam fora de alcance. Se o atacante combinar essa permissão com permissões de leitura (por exemplo, s3:GetObject), ele pode obter cópias completas de dados sensíveis.

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

s3:Delete*

Um atacante com a permissão s3:Delete* pode excluir objetos, versões e buckets inteiros, interromper backups e causar perda de dados imediata e irreversível, destruição de evidências e comprometimento de artefatos de backup ou recuperação.

# 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 mais informações check the original research.

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks