Loading story…
AWS published guidance for migrating IAM Identity Center from Microsoft Active Directory to an external SAML 2.0 identity provider, using Okta as an example. Changing the identity source to or from Active Directory permanently deletes IAM Identity Center users, groups, AWS account assignments, and application assignments at cutover, disrupting access until those entitlements are recreated.
Organizations should export principals and assignments before migration, validate SCIM provisioning and identity attributes in the new provider, and restore assignments from backup files after cutover. AWS recommends post-migration access and assignment-drift testing, ongoing monitoring, and cleanup; rollback is manual, requiring Active Directory synchronization to be reconfigured and assignments recreated because no automatic rollback exists.
See affected versions and whether adversaries are exploiting it.
1 event from the most recent confirmed update back to the earliest known activity.
AWS published guidance for migrating IAM Identity Center from Microsoft Active Directory to an external SAML 2.0 identity provider, using Okta as an example. It warns that transitions to or from Active Directory delete Identity Center users, groups, and assignments, and outlines export, validation, restoration, monitoring, and manual rollback procedures.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Threat researchers and U.S. government defenders warned that attackers who steal an identity provider's token-signing private key can forge **SAML 2.0** assertions and authenticate as arbitrary users to cloud services that trust the compromised provider. The technique, known as **Golden SAML**, lets intruders bypass normal controls including MFA in some scenarios and obtain access to environments such as **AWS**, **Azure**, **Microsoft 365**, and **vSphere**. CyberArk showed the method can be used against **AD FS** federations, including exchanging forged assertions through AWS STS `AssumeRoleWithSAML` to obtain temporary AWS credentials, while noting the abuse stems from compromised trust infrastructure rather than a flaw in SAML itself. Mandiant and **CISA** later tied Golden SAML to broader post-compromise cloud intrusion activity, including operations by **UNC2452**, and said attackers often pivot from on-premises compromise into cloud tenants by stealing AD FS signing certificates, altering federated domains, abusing privileged Azure AD roles, or adding rogue credentials to applications and service principals. Defenders were urged to treat on-premises and cloud investigations as linked, rotate signing certificates and other secrets, revoke refresh tokens, remove cloud persistence, and harden monitoring around AD FS, federation settings, privileged accounts, and application permissions. Detection remains challenging because forged assertions can closely resemble legitimate federated logins; Splunk noted one analytic for suspicious AWS `AssumeRoleWithSAML` activity was ultimately removed because it no longer reliably identified the intended abuse.
Aug 15, 2026
AWS announced a gradual rollout of a redesigned sign-in and sign-up experience that changes how some customers access AWS accounts. The update introduces a unified email entry point for **root users** and certain newly created accounts, refreshed session-selection pages, and support for signing in with supported identity providers for eligible accounts. AWS said existing customers will keep using their current credentials and sign-in methods, and the changes are being introduced to a limited set of users first. AWS said organizations using **IAM Identity Center** or federation should continue to use their existing organizational access portals or federation URLs, while customers authenticating with traditional **IAM users** and **root user** credentials should review the updated flow. The company also warned that teams relying on browser automation or scripted sign-in workflows may need to validate compatibility with the new interface as the rollout expands.
Aug 17, 2026
AWS introduced **EC2 Instance Metadata Service Version 2 (IMDSv2)** to reduce theft of instance metadata and IAM role credentials through server-side request forgery (SSRF), open web application firewalls, reverse proxies, and network-device misconfigurations. IMDSv2 requires a session-oriented `HTTP PUT` request to obtain a secret token before metadata access; organizations can enforce IMDSv2-only access or disable IMDS, while AWS provides usage metrics, CloudTrail logging, updated SDKs and CLIs, and the `ec2:RoleDelivery` IAM context key to support migration from IMDSv1. IMDS hardening addresses only one of several credential-access routes available after AWS compute compromise. Attackers may also obtain credentials from hard-coded application secrets, environment variables, local credential files, container credential endpoints, EKS identity mechanisms, and services such as Systems Manager, IoT, IAM Roles Anywhere, Cognito, and DataSync. Security teams should enforce IMDSv2 where applicable and monitor these additional credential stores, endpoints, tokens, and certificates because a single EC2 workload can expose multiple IAM principals.
Sep 3, 2026