{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/aws-iam/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","aws-iam","identity-and-access-audit","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon Web Services"],"content_html":"\u003cp\u003eAdversaries who have successfully compromised an AWS account with administrative privileges may create new Security Assertion Markup Language (SAML) Identity Providers (IdPs) within AWS Identity and Access Management (IAM) to establish a persistent backdoor. This technique allows attackers to maintain unauthorized federated access to AWS resources, even if their initial access credentials are rotated or revoked. By controlling an external IdP, attackers can forge SAML assertions, enabling them to assume roles within the compromised AWS account and access resources without requiring traditional AWS credentials. The creation of SAML providers is an infrequent administrative action, typically reserved for initial Single Sign-On (SSO) integration or major infrastructure changes, making its unauthorized occurrence a high-fidelity indicator of potential adversarial activity. Monitoring successful \u003ccode\u003eCreateSAMLProvider\u003c/code\u003e API calls is crucial for detecting this form of persistence and preventing long-term unauthorized access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAdversary obtains administrative access to an AWS account, typically through compromised credentials or misconfiguration exploitation.\u003c/li\u003e\n\u003cli\u003eThe adversary executes the \u003ccode\u003eCreateSAMLProvider\u003c/code\u003e API call via the AWS CLI, SDK, or console to register a new SAML Identity Provider in IAM.\u003c/li\u003e\n\u003cli\u003eDuring this registration, the adversary specifies SAML metadata that points to an external IdP under their control.\u003c/li\u003e\n\u003cli\u003eThe adversary then creates or modifies an existing IAM role, establishing a trust policy that allows the newly registered rogue SAML IdP to assume the role.\u003c/li\u003e\n\u003cli\u003eUsing their controlled external IdP, the adversary generates and signs malicious SAML assertions.\u003c/li\u003e\n\u003cli\u003eThe adversary presents these forged SAML assertions to AWS via the \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e API call, which grants temporary credentials for the trusted IAM role.\u003c/li\u003e\n\u003cli\u003eWith these temporary credentials, the adversary gains persistent access to AWS resources, bypassing multi-factor authentication and credential rotation mechanisms.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to establish a covert and persistent method of access to an AWS environment. This backdoor enables them to assume various IAM roles, granting them ongoing control over cloud resources, data exfiltration capabilities, and the ability to launch further attacks. The persistence mechanism is particularly dangerous as it can survive credential rotation, making it difficult to fully evict the attacker. While specific victim counts are not available, any organization utilizing AWS IAM for identity federation is susceptible if administrative access is compromised. The financial, reputational, and operational damage can be severe, including unauthorized data modification or deletion, service disruptions, and compliance violations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Detect AWS IAM SAML Provider Creation\u0026quot; to your SIEM and tune for your environment to detect \u003ccode\u003eCreateSAMLProvider\u003c/code\u003e API calls.\u003c/li\u003e\n\u003cli\u003eRestrict \u003ccode\u003eiam:CreateSAMLProvider\u003c/code\u003e permissions to a highly limited set of administrative roles using AWS IAM policies.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging for all management events to capture \u003ccode\u003eCreateSAMLProvider\u003c/code\u003e and \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e API calls.\u003c/li\u003e\n\u003cli\u003eImplement Service Control Policies (SCPs) to control SAML provider creation in member accounts within AWS Organizations.\u003c/li\u003e\n\u003cli\u003eUse AWS Config rules to monitor identity provider configurations for unauthorized changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-15T14:21:02Z","date_published":"2026-07-15T14:21:02Z","id":"https://feed.craftedsignal.io/briefs/2026-07-aws-iam-saml-provider-created/","summary":"Adversaries with administrative access to an AWS account can create rogue SAML Identity Providers (IdPs) to establish persistent, federated access to AWS resources that survives credential rotation, enabling them to assume roles and access resources by forging SAML assertions from an IdP they control.","title":"AWS IAM SAML Provider Creation for Persistence","url":"https://feed.craftedsignal.io/briefs/2026-07-aws-iam-saml-provider-created/"}],"language":"en","title":"CraftedSignal Threat Feed - Aws-Iam","version":"https://jsonfeed.org/version/1.1"}