Skip to content
BreachPathAttack Path LibraryStart
AdvancedAccount takeoverData theft

Identity provider compromise to federated access

An attacker who reaches the single sign-on identity provider abuses its trust to grant themselves access across every federated application at once — turning one identity system into keys to the whole estate.

Technologies
SaaS (generic), Azure
Entry points
Phishing, Stolen credentials
Sectors
SaaS & technology, Financial services, Professional services…
Stages
3
01

Administrative access to the identity provider is gained

Through phishing of an identity administrator or reuse of a privileged credential, the attacker gains administrative access to the identity provider that federates access to the organisation's applications.

Attacker objective

Reach an administrative role in the SSO / identity provider.

MITRE ATT&CK
Controls that should stop this
  • Phishing-resistant MFA and dedicated admin accounts for the IdP
  • Strictly limited, monitored set of IdP administrators
  • Privileged access management for identity administration
What defenders should see
  • Admin sign-ins to the IdP from unusual locations
  • Risky sign-ins on identity-administration accounts
  • Administrative actions outside normal hours
What a pentest validates
  • Assess exposure and protection of IdP administrators
  • Test MFA strength on identity administration
  • Review who holds IdP admin and how it is monitored
Business impact

The attacker controls the system that vouches for identity across the estate.

02

Federation trust is abused to mint access

The attacker manipulates the identity provider — adding an identity, altering claims or federation settings, or issuing tokens — so that federated applications accept them as a legitimate, authorised user.

Attacker objective

Use the IdP's trust to grant access to applications without per-app credentials.

MITRE ATT&CK
Controls that should stop this
  • Alerting on federation, claim and trust-configuration changes
  • Monitoring new identity and credential provisioning in the IdP
  • Conditional access that considers device and risk, not just the token
What defenders should see
  • Changes to federation settings, signing configuration or trusts
  • New identities or credentials provisioned in the IdP
  • Tokens issued with unusual properties
What a pentest validates
  • Test detection of federation and trust-configuration changes
  • Review monitoring of identity/credential provisioning
  • Validate app-side conditional access beyond token trust
Business impact

The attacker can present as an authorised user to any federated application.

03

Federated applications and their data are accessed

Using the trust they now control, the attacker signs into the federated applications that matter — collaboration, finance, code, customer systems — and accesses or exports their data.

Attacker objective

Reach the data and capability in the connected applications.

MITRE ATT&CK
Controls that should stop this
  • Per-application access review and anomaly detection
  • Data-egress controls and DLP on connected apps
  • Ability to break federation and force re-authentication quickly
What defenders should see
  • First-time sign-ins to many applications by one identity
  • Bulk data access or export across connected apps
  • Access patterns inconsistent with the impersonated user
What a pentest validates
  • Test how far IdP control reaches into connected apps
  • Validate per-app anomaly detection and egress controls
  • Confirm the organisation can sever federation quickly
Business impact

Data across many federated systems is exposed from a single identity-provider compromise.

ATT&CK techniques in this chain

T1078.004Valid Accounts: Cloud AccountsT1213Data from Information RepositoriesT1567Exfiltration Over Web ServiceT1556Modify Authentication ProcessT1566PhishingT1484.002Domain or Tenant Policy Modification: Trust Modification

If this chain completes

Because federated apps trust the identity provider, its compromise can silently unlock all of them — the highest-leverage identity attack, enabling access to any connected system without touching each one individually.

Should you test this against your environment?

Turn this chain into a scoped red-team brief — objective, systems and identities in scope, testing assumptions and the questions to answer before commissioning.

Generate my red-team test briefExplore more paths