Cross-IdP impersonation is a growing trend as a method of hijacking SSO to access downstream apps — without needing to compromise accounts on your company’s main IdP.
Cross-IdP impersonation is a growing trend as a method of hijacking SSO to access downstream apps — without needing to compromise accounts on your company’s main IdP.
Two stories have hit the headlines in recent months involving attackers and researchers, demonstrating ways of taking over a SaaS account by accessing it using an SSO login from an IdP that you’ve never used before.
Yes, you read that right. An attacker created an IdP account on an IdP that you don’t use. And because the account matched your actual company domain, they used it to log into your actual downstream accounts on the apps that you use.
We're calling this technique cross-IdP impersonation. If you’re familiar with our other research, this is basically ghost logins on steroids — you’re effectively making your own!
Let’s take a look at some examples.
Cross-IdP impersonation in the wild
Spoofing Zendesk support emails and infiltrating connected apps (via Apple SSO)
A 15-year-old researcher was able to access Zendesk support ticket history via spoofing a company’s support email, and later use it to access connected apps (Slack, in this case) via SSO, successfully targeting hundreds of companies.
The attack is based around the fact that Zendesk support tickets are easy to enumerate. The typical method of setting up Zendesk is to have your existing support email address (e.g. support@company.com) forward emails to Zendesk.
The researcher was able to abuse this feature to create an account for an existing company domain on an IdP not currently being used by the company, and then use that account to authenticate to a third-party app used by the company.
The researcher found that, although Zendesk had started blocking emails from ‘noreply@’ addresses (probably to prevent this kind of attack), Apple sent its verification emails from an ‘appleid@’ address, making the attack possible when using Apple IdP.
There’s a couple of things to note here:
Apple could be swapped out for any IdP that doesn’t send verification emails from a ‘noreply@’ address.
Slack could be swapped out for just about any downstream SaaS app.
Taking a step back — what if an attacker had discovered this exploit? The researcher states that, after Zendesk refused to acknowledge the issue through its bug bounty program operated by HackerOne, he individually contacted ‘hundreds’ of affected organizations.
So that’s hundreds of vulnerable organizations, and potentially tens to hundreds of business apps per victim organization that could be accessed via Apple SSO. Any app that allows ‘sign in with Apple’ could be targeted where:
An app with an existing account belonging to the specific email & domain combination could be taken over.
A new account could also be created on apps allowing anyone with a company email to join the company tenant.
It’s unclear whether Zendesk will have implemented a global fix for the issue either, as the vulnerability stems from a configuration option that could be remediated by disabling email collaboration, but is on by default.
Google domain verification bug similarities
The Zendesk attack shares some similarities with a recent (now resolved) Google email verification vulnerability which allowed a newly created Google account/domain to be used to authenticate to downstream apps via SSO — this time without verifying ownership of the domain.
Whereas the Zendesk attack took advantage of Apple email configs, this attack was much more direct in that Google enabled SSO to downstream apps prior to domain verification.
The Google attack is definitely a bug rather than abusing a feature, and has since been patched. But, we’re starting to see a concerning pattern emerge.
How big of a problem is this?
First, let’s recap the general attack path:
The attacker signs up for an account on an app that functions as an IdP, linking it to the victim’s existing company email address via the ‘use existing email’ option.
The attacker either bypasses domain verification or verifies the domain via email (typically by clicking a link or entering a one-time password) either through an attack like the ones above, or by social engineering the victim user.
The attacker logs into an account on a downstream app using the ‘sign in with …’ SSO login option.
Let’s look more closely at why this is a cause for concern.
It gets around your most hardened IdP accounts
The notion of IdP impersonation isn’t necessarily new. Take for example cross-tenant impersonation, which focuses on mapping an attacker-controlled Okta tenant to a compromised Okta tenant to give full access to connected user accounts and enable unrestricted lateral movement.
Cross-IdP impersonation, however, doesn’t require that you’ve already compromised an IdP admin account. You pick a user account (or multiple) that you want to take over, you enroll them with a new IdP matching the tenant and address structure, and then authenticate to whichever apps you’re interested in taking over.
So, compromising your target’s main IdP isn’t necessary when the data and functionality that you’re most interested in lives in downstream apps. This means that even if your primary IdP is super locked down with phishing-resistant authentication (e.g. passkeys) this technique enables attackers to get around it.
And a smart attacker who does their OSINT will identify potential app admins whose accounts to mirror, eliminating any noise that would be generated by privilege escalation & lateral movement attempts such as in-app phishing.
App-based prevention measures are inconsistent
It’s worth noting that this attack doesn’t work the same on all apps. At the point of using a new login method to access an app, it is considered best practice to require re-verification — for example by logging in with the original login method, or approving the request via an email code or link.
Requiring re-authentication with the original login method is probably game over for the attacker, but if the attacker has already found a way of verifying a new IdP via email, the latter option is probably less of an obstacle.
But not all apps follow these best practices around adding new login methods. We tested a range of the most popular apps that our customers use by creating an account, adding a password and an SSO method, and subsequently adding another SSO method using a different IdP, and found that 60% (3 in 5) of the apps we tested do not require re-verification by default when adding a new SSO login method.
60% (3 in 5) of the apps we tested do not require re-verification by default when adding a new SSO login method
There are more IdPs than you realize
IdP accounts have always been a valuable target. Earlier this year we saw a dramatic spike in the attacks on Okta accounts, for example. But these accounts are often well protected with strong credentials (or passkeys) and MFA.
In contrast, cross-IdP impersonation gives attackers a way of getting the benefit of an IdP compromise without needing to take over a locked down IdP account.
Apps accept a wide variety of SSO login options. An app might support any combination of, for example:
Log in with Google
Log in with Facebook
Log in with Apple
Log in with X
Log in with Microsoft
Log in with GitHub
Log in with Okta
Log in with SAML
Log in with SSO
And there are many, many IdPs — probably more than you realize — all of which could potentially be hijacked by an attacker to impersonate your organization.
But it’s not just about attackers creating new IdP accounts: What other IdPs might your users have inadvertently created? And are these accounts as securely configured as your primary company IdP (most commonly Okta, Microsoft Entra, or Google Workspace)?
In fact, there are a few different scenarios to be aware of here:
An attacker creates a new account on a previously unused IdP mapping to your company domain and email, and exploits a flaw to bypass domain verification.
An attacker creates a new account on a previously unused IdP mapping to your company domain and email, and social engineers the target user to convince them to complete the domain verification request.
A legitimate user signs up for an account that functions as an IdP with their company email, using a weak password and no MFA. This account is later compromised by an attacker.
In all of these cases, an attacker would be able to authenticate to downstream apps and take over user accounts.
We’re only scratching the surface of what’s possible
The Zendesk attack demonstrates a creative way of abusing an app’s functionality, combined with the way in which the Apple IdP is configured.
It would be naive to suggest that similar issues don’t exist for other IdPs. Or that apps other than Zendesk don’t have features that can be exploited.
For example, we’ve previously documented using Zapier to create malicious automated workflows to compromise integrated apps, or changing the SAML configuration of an app to direct logins to a malicious Okta tenant.
Until now, there hasn’t been much research in this space. It’s not surprising when we consider that this kind of bug bounty isn’t paying out, and I know of only a handful of forward-thinking security consultancies conducting any real offensive security testing with their clients in this space.
All organizations should be taking SaaS and identity attacks seriously — a good starting point would be to normalize SaaS and IdP configuration testing as part of routine security assessments, as well as demonstrating in-app post exploitation activity to raise awareness of how direct and dangerous these attacks can be.
Expect more cross-IdP impersonation in future
With the success of the attacks on Snowflake customers it feels like attackers and researchers are starting to take note, and the research scrutiny is amping up. It would be wise to expect more of these attacks in future.
Cross-IdP impersonation could be largely prevented if all apps required re-verification upon adding a new login method by default (specifically, requiring that you log in with the original method, not approving via email link/code). This is yet another example of the inconsistencies in SaaS authentication introducing vulnerabilities.
As this is unlikely to happen anytime soon, to mitigate the threat of cross-IdP impersonation we recommend that you:
Set email alerts for employees receiving IdP activation emails to their corporate mailbox and forward to your SIEM. This will provide visibility both of unauthorized IdPs being connected to your domain by employees (which can lead to your corporate apps and accounts being compromised via less secure accounts, such as their Apple, LinkedIn, X, etc.), and of attackers attempting to register a new IdP as part of an attack.
Warn users of the risks associated with creating new IdP accounts and connecting them to their primary corporate email (as well as the possibility of phishing scams designed to trick the user into completing the verification process or passing on a verification code).
Where possible, prevent the conversion of personal accounts to corporate accounts within the main IdP providers. For example, Apple Business Manager recently released the ability to lock your domain and prevent new accounts being created, as well as locking the authentication to your preferred IdP (preventing local accounts from being created) — convenient timing!
Where configurable, require downstream applications to enforce re-verification when adding new SSO methods. Requiring login with the original method, rather than email approval, is a more secure approach.
However, your ability to prevent attackers from creating new accounts on IdPs and connecting them to your domain is going to vary from IdP to IdP, so complete remediation may not be possible. And unless handled carefully, joining multiple IdPs to your primary IdP has the potential to increase your attack surface, not reduce it!
