AN0526: Analytic 0526
Use of AWS STS or GCP IAM APIs to request temporary tokens or federation sessions inconsistent with normal account activity, including from unexpected principals or regions.
Analyst context for executives and security teams
This analytic highlights a cloud identity risk pattern: temporary AWS STS or GCP IAM federation/session tokens being requested in ways that do not match normal account behavior, such as by unexpected principals or from unusual regions. For leaders, the significance is that temporary credentials can become a fast path to cloud access that may bypass traditional endpoint-centric visibility if cloud identity telemetry is not collected and reviewed.
Executive priority
Prioritize this as a cloud identity and SOC readiness validation item. Executives and risk owners should ask whether the organization can prove who requested temporary cloud credentials, from where, for which principal, and whether that behavior was expected. This supports incident decision-making, cloud access governance, compliance evidence, and resilience planning for IaaS environments.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring around AWS STS and GCP IAM API activity that creates temporary tokens or federation sessions. Since the ATT&CK object provides no formal detection logic, teams should baseline normal account, principal, and region patterns, then tune for requests from unexpected principals or regions. Investigation should focus on whether the requesting identity, source geography/region, and session context align with normal cloud operations.
Likely telemetry
- AWS STS API activity logs
- GCP IAM API activity logs
- Cloud audit logs for token or federation session requests
- Principal and service account identity context
- Source region or location metadata associated with API calls
Detection direction
- Confirm that AWS STS and GCP IAM token/federation events are logged and retained for IaaS environments.
- Baseline normal principals, accounts, services, and regions that request temporary credentials.
- Alert or hunt for temporary token or federation session requests from unexpected principals or regions.
- Tune detections to account for legitimate automation, CI/CD systems, administrative activity, and scheduled cloud operations to reduce false positives.
- Validate that cloud identity telemetry is available to the SOC and incident responders quickly enough to support investigation.
Mitigation priorities
- Enforce least-privilege access for principals that can request temporary credentials or federation sessions.
- Review and govern federation and temporary credential usage across AWS and GCP environments.
- Restrict or monitor access patterns that are inconsistent with approved regions, principals, or operational workflows where feasible.
- Maintain cloud audit logging and retention sufficient for incident response and compliance evidence.
- Periodically review normal cloud identity behavior so detection baselines remain current.
Analyst notes and limits
This object is a detection analytic for IaaS platforms focused on AWS STS and GCP IAM API use. No tactics, relationships, aliases, labels, or official detection logic were supplied, so the take emphasizes validation questions, telemetry readiness, and conservative detection engineering direction rather than specific rule syntax.
The supplied ATT&CK fields do not include associated techniques, procedures, threat actors, campaigns, or a concrete detection query. Local cloud architecture, identity design, logging configuration, and business-approved regions are required to determine what is abnormal.
Analytic 0526
Use of AWS STS or GCP IAM APIs to request temporary tokens or federation sessions inconsistent with normal account activity, including from unexpected principals or regions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a06a95c5b365… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0526Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.