Start by reviewing the IAM Identity Center identity source settings and confirming whether ADFS metadata and SAML certificates are present. Then correlate CloudTrail activity for all ADFS users, including current and historic AWS SSO roles, and manually review actions that could indicate malicious use. Identity driven intrusions often require time based correlation because deleted roles and users may no longer be visible through simple API lookups.
Why ADFS-backed AWS activity is harder to investigate than native console use
When AWS is federated through ADFS, the identity evidence is split across layers: the source directory, the federation service, IAM Identity Center or federated roles, and CloudTrail. That means a suspicious AWS action may not map cleanly to a single user record or a still-present role. Investigators have to reconstruct access from time-bound assertions, role assumptions, and session activity rather than relying on current account state alone. That is especially important when roles, users, or certificates have already changed.
This is a classic trust-chain problem, not just a logging problem. If ADFS metadata, SAML certificates, or role mappings are altered, the same AWS action can come from either a legitimate user path or a compromised federation path. Security teams therefore need to verify who could have assumed what, when, and under which federation state. The relevant control question is whether the trust relationship was still sound at the time of access, not simply whether the final AWS action looks unusual in isolation. In practice, many teams only discover the federation layer matters after a suspicious action has already been attributed to the wrong principal.
For teams managing federated identities, the broader NHI lesson is that weak visibility and delayed revocation are common failure patterns; NHIMG research notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for any investigation that depends on historic identity reconstruction.
How to reconstruct the event chain across ADFS, IAM Identity Center, and CloudTrail
Start with the federation configuration, not the suspicious API call. Confirm which ADFS metadata file, signing certificate, relying party trust, and attribute mappings were active when the activity occurred. Then identify the AWS roles that were available to each federated user at that time, including historic AWS SSO or IAM Identity Center assignments if the current view no longer matches the event window. The objective is to rebuild the access path exactly as it existed during the session.
Next, correlate CloudTrail with the federation timeline. Look for role assumption events, console sign-ins, unusual source IPs, uncommon user agents, and activity that spans multiple roles in a short period. Because federated sessions are time bound, the useful evidence is often the sequence: ADFS authentication, SAML assertion issuance, role assumption, and then downstream API activity. If the investigation stops at the current directory state, deleted or rotated roles can hide the path entirely. Where available, use CloudTrail alongside IdP logs and directory change history to prove whether a particular identity could have reached the observed AWS action.
- Validate whether the suspicious action occurred during a valid federated session window.
- Check whether the SAML assertion or role mapping could have granted broader access than expected.
- Review whether the same ADFS user later assumed additional AWS roles that broadened the blast radius.
- Compare current trust settings with the historical configuration at the time of the event.
NIST guidance on security logging and monitoring is useful here because the investigation depends on preserving and correlating source evidence rather than trusting a single system of record, and the relevant control families are described in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when federation logs, CloudTrail retention, or directory history are incomplete across the incident window.
Where federated AWS investigations usually go wrong
Tighter federation controls often increase operational complexity, because investigators must reason over historic trust state rather than present-day access alone. That creates a trade-off between simpler administration and stronger forensic confidence. The most common mistake is assuming a deleted role or removed user proves the activity could not have happened; in federated environments, the opposite can be true, because the evidence of access may live in logs, not in the current identity inventory.
A second edge case appears when multiple ADFS claims rules or role mappings exist for different business units. In that situation, the same human identity may legitimately reach several AWS roles, which makes anomaly hunting noisier and raises the bar for time-based correlation. Best practice is evolving toward treating federation state as part of the evidence set, not as background configuration. If certificate rollover, metadata updates, or role removals happened near the event window, those changes should be investigated as part of the access path itself, not as separate hygiene tasks.
Practitioners should also distinguish between suspicious AWS usage and suspicious federation usage. Sometimes the cloud action is only the symptom, while the real compromise is at the ADFS trust layer. When that happens, the fast path is to map the session lineage first and decide whether the issue is misuse of an existing trust relationship, stolen federation credentials, or an overly broad role assignment.
Risk and Threat Considerations
Federated AWS access through ADFS creates a trust-abuse risk: if an attacker compromises the identity source, the federation certificate, or the assertion path, they can inherit AWS access without touching AWS user passwords directly. The exposure is amplified when historic role mappings are hard to reconstruct, because defenders may underestimate the blast radius after roles or users are deleted.
Failure mechanism: the attacker uses a valid federated authentication flow to obtain a SAML assertion, assumes an AWS role, and performs actions inside normal CloudTrail-visible activity. If logging, retention, or identity history is incomplete, the malicious path blends into legitimate federation traffic and becomes difficult to attribute.
Impact: investigators may miss lateral movement across AWS roles, misidentify the origin of the session, or fail to scope compromise across older assignments. That can delay containment, leave standing trust relationships in place, and allow the same federation path to be reused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Suspicious AWS activity needs correlated monitoring across IdP and cloud logs. |
| DE.AE — Anomalies and Events | The question centers on identifying unusual AWS actions and access paths. | |
| PR.AA — Identity Management, Authentication, and Access Control | ADFS-fed AWS access depends on correct identity and trust configuration. | |
| Recommendation — Correlate identity, federation, and cloud logs to detect and investigate anomalous access. Investigate unusual session patterns, role use, and API activity as potential incidents. Validate federation trust, claims, and role mappings before trusting access decisions. | ||
| CIS Controls v8 | 8 — Audit Log Management | CloudTrail and IdP logs are the primary evidence for reconstruction. |
| 6 — Access Control Management | Historic role assignments and federation privileges determine blast radius. | |
| Recommendation — Preserve and review authentication and cloud activity logs across the full incident window. Review and remove excessive or stale federated access paths that expand compromise impact. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Federated AWS abuse often uses legitimate identities and sessions. |
| Recommendation — Hunt for legitimate-account abuse patterns that indicate unauthorized access through trusted identities. | ||
Practitioner Guidance
What to prioritise: Rebuild the trust chain before judging the AWS action. If the IdP, certificate, or claim mapping changed near the event, treat that as part of the incident scope rather than as background configuration drift.
What to verify: Confirm the exact federation state during the session window, then test whether the observed AWS role could have been reached by a legitimate ADFS assertion. The key question is not whether the role exists now, but whether it was assumable then.
Decision rule: If the suspicious activity can only be explained by current-state lookups, the investigation is incomplete. Escalate to historical correlation across ADFS, identity center assignments, and CloudTrail until the access path is reproducible or disproven.
Practitioner takeaway: In federated AWS incidents, attribution fails most often when teams inspect the cloud action before they reconstruct the trust relationship that made the action possible.
Related resources from NHI Mgmt Group
- How should security teams reduce CloudTrail noise from AWS console activity during incident response?
- How should security teams evaluate open-source cryptographic libraries used in identity flows?
- How should security teams investigate suspicious cross-account role activity in cloud environments?
- How should security teams monitor Snowflake for suspicious identity activity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
