Identity Provider Email Spoofing Takeover
Sign in with a social provider, and the platform decided who you were by your email address. The problem: one supported provider lets an administrator of their own directory set any email they like on a user — verified or not. We stood up our own directory, created a user wearing a victim’s email, and signed in. The platform happily merged us into the victim’s account. No victim interaction, no credential theft.
- Duration
- 2 Weeks
- Team
- 2 Identity & Access Operators
- Scope
- Authentication Security Review
- Methodology
- Authentication & Federation Security Review
Attack narrative
Each phase references the MITRE ATT&CK technique used, with captured evidence.
- 01
Analysis
Identity Confusion — Mutable Email Claim
Account linking keyed on the email claim returned by the identity provider rather than the immutable subject identifier — and treated that email as trustworthy even when the provider had never verified it.
operator@proteqon: linking-logic# How does social login decide which account to attach to?match key : email claim from provider token[!] email claim is administrator-mutable and may be unverified[!] subject (sub) claim ignored for linkingverdict : controlling the email claim = controlling the account$ - 02
Resource Development
T1585 — Establish Accounts
We provisioned our own identity-provider directory and created a user whose contact email was set to the victim’s address — an action available to any directory administrator, with no proof of ownership required.
operator@proteqon: attacker-directory# In an attacker-controlled directory tenant$ idp-admin user create --email victim@[REDACTED].example[+] User created with arbitrary, UNVERIFIED email[*] Note: emitted token will carry the victim email claim$ - 03
Exploitation
T1550 — Use Alternate Authentication Material
We chose "sign in with this provider" on the target and authenticated as our attacker-directory user. The platform read the victim’s email from the token and merged us into their existing account. Demonstrated against an operator-owned target account only.
operator@proteqon: merge-takeover (test target)$ auth-flow login --provider <provider> --as attacker-directory-user[*] Provider token issued (email claim = test victim)[+] Platform matched on email and linked accounts[+] Logged into the test victim account, no password used$ - 04
Impact
T1078 — Valid Accounts
Account linkage by mutable email means any account with social login enabled is reachable by anyone who can name its email address — full takeover with zero victim interaction.
Key vulnerabilities
Account Linking on Mutable / Unverified Email Claim
Social login matched accounts on the provider email claim, which a directory administrator can set arbitrarily and which may be unverified, enabling takeover by impersonating the email.
Immutable Subject Identifier Ignored
The stable subject identifier that uniquely binds a provider identity to an account was not used for linking.
No Verified-Email Enforcement Before Merge
Accounts were merged without confirming the incoming email was provider-verified or owner-confirmed.
Remediation
- 01
Link accounts on the immutable subject identifier, never on the email address alone.
- 02
Require a provider-verified email signal before any automatic account merge, and fall back to an ownership-proof step (e.g. a magic link) otherwise.
- 03
Where the provider offers domain-verified email signals, consume them and redact unverified email claims.
- 04
Audit existing links created via social login and re-bind any established on unverified email.
Outcome
Account linking moved to the immutable subject identifier with verified-email enforcement. Confirmed fixed and unsafe links audited.
- None
- Victim Interaction
- Zero
- Credentials Needed
- Email Claim
- Match Key Abused
- 1
- Critical Findings
All client identities, infrastructure details, and timelines in this report have been anonymized and adapted to protect confidentiality. Technique identifiers reference the MITRE ATT&CK framework. All offensive actions described were performed within a pre-authorized rules-of-engagement window; no production data was destroyed and no live systems were harmed.
Start an engagement
Want this level of rigor on your systems?
Book a 30-minute scoping call with a senior engineer. You'll leave with a clear recommendation on scope, approach, and timeline.