A new class of phishing: Verification phishing and cross-IdP impersonation

Many organizations make use of a centralized managed identity provider (IdP) that they use as an SSO gateway, such as Microsoft Entra, Okta, Google Workspace etc. 

In a perfect world, every account, on every business application, would be:

• Accessed via SSO from an IdP account via SAML or OIDC protocols.

• Protected by strong authentication controls such as phishing-resistant factors such as passkeys or Okta Fastpass.

• Configured to provide strong centralized audit logging. 

This would in theory provide broad protection against identity attacks — there are no credentials to steal or be phished (even using modern AiTM phish kits) and the logging would provide threat hunting and incident response teams with a great data source for detection and response. 

But what if it were possible to compromise downstream SaaS applications directly and circumvent every single control we just outlined? No password needed, no MFA needed, no SSO audit logs — and all it took was the ability to phish a verification code from a target user. This is what is often possible using verification phishing when combined with cross-IdP impersonation. 

What is cross-IdP impersonation?

Cross-IdP impersonation is when you authenticate to an application as a user but using a different IdP from the one used ordinarily by the target organization. Depending on the configuration of the target application, this can potentially allow very strict authentication controls to be either partially or completely circumvented. 

Let’s look at an example. Say an organization uses Microsoft Entra as their primary IdP. Their users have email addresses of user@example.com, they authenticate using strong MFA to Microsoft and then either SAML or OIDC login to their downstream applications. 

However, some of their downstream applications support many different login methods to support different customers, as is extremely common for SaaS vendors. Let’s say they are using the Atlassian suite of products, which support many different login methods as shown below:

The legitimate user normally clicks the Microsoft button to perform an OIDC social login. However, what happens if an attacker somehow gains access to an account with a different IdP using the target user’s email address? So they somehow gain access to user@example.com as an account for Apple or Google. Then, in the default configuration of Atlassian, they can click the Apple or Google buttons and login directly to the downstream application without ever touching the organization’s secure Microsoft Entra tenant.

But how would an attacker gain access to an Apple or Google account anyway? Wouldn’t they have to authenticate using Microsoft to login to those services and so it becomes a circular problem? Well actually, no. In many cases, an organization won’t have accounts with other major IdPs and so those accounts don’t actually exist. 

So rather than take over existing accounts, what if an attacker could somehow create a new one?

What is verification phishing?

The primary concern for most organizations is preventing attackers from gaining access to core business applications and data and, consequently, the identities that allow access to those applications and data — therefore, protecting IdP accounts used for SSO is a Tier-1 priority. 

However, preventing accounts being created on other applications they do not use, and therefore do not contain company data, is not a direct concern — unless legitimate users start using those applications and entering company data. This is normally only considered in the context of a shadow SaaS problem — an important, but very different, security issue.

For SaaS vendors though, unwanted and unverified signups can be a painful issue as they are often associated with spam or general misuse of their platforms. Therefore, it’s very common (but not universal) for SaaS vendors to require some basic verification steps for new accounts to raise the bar and prevent common abuse patterns — most commonly, this involves sending an email to the given email address to require either a link to be clicked or to supply a verification code to be used to verify the address. 

For example, here’s what Google sends when creating a new Google account attached to an existing email address:

So let’s say an attacker wants to register a new account as user@example.com with an application that is not used by the target user (or even the target organization). What would they need to do? Well in many cases, they can create the account, set the password and any other details like MFA or phone number directly — all they need to do is convince the user to click the link in the verification email or supply the verification code included.

So that’s what verification phishing is: Using phishing, or some other form of social engineering, to convince a target user to verify an account. But how difficult is that? Well, actually, not very!

Verification phishing scenarios

No matter how hard we try to stop phishing with user awareness training and phishing simulations, phishing still succeeds to some extent.

Typically, we train users to be suspicious of clicking links in emails, to check the domains of any links carefully and to be especially careful when prompted for entering a password for an account they use.

But what are we asking our target users to do with verification phishing? Simply asking them to click a link, or supply a verification code, in an email from a legitimate address for an account they know does not exist — so from their perspective, what are they giving away? What’s the risk, really?

With a bit of clever thought behind the social engineering effort, we should see much higher success rates with verification phishing than with conventional password phishing. Let’s consider a few strategies that could be used, with differing sophistication levels:

• Pretext emails – a classic and simple email approach

• IM phishing – hands-on-keyboard social engineering effort but using IM

• AiTM verification phishing – a technically sophisticated approach requiring new tooling

Pretext emails

We could create a false pretext by emailing users ahead of time to be expecting the verification email and take advantage of the fact the incoming verification email will be from a legitimate address to create an additional sense of trust. We’ll use Google as an example in this case.

IM phishing

IM phishing is a great way to conduct modern phishing attacks as users generally have more trust in IM platforms than email. Since the advent of Slack Connect and Teams external access, this has been possible as an external initial access vector too. If you’re interested in this technique in general, check out our previous posts on Slack phishing and Teams phishing.

It also has the advantage that the instant nature of it makes it great for building a social engineering pretext. This is more of a classic interactive social engineering effort over a new delivery vector (IM), than a single message or link-based phishing attack, and so is a more targeted attack strategy. It’s not too dissimilar from strategies used by Scattered Spider to social engineer their way past MFA controls, except they generally used phone and SMS delivery vectors. 

Consider the following exchange, and ask yourself how many users could fall for this strategy. I’ll play the victim myself this time and we’ll use Apple as an example.

AiTM verification phishing 

AiTM phishing to bypass common SSO and MFA protections is now a commonly used technique by attackers, with a range of open-source and criminal tools implementing this in the wild. However, there is nothing stopping a similar approach being used to make verification phishing much more effective and scalable than it is currently. 

If current AiTM tooling, such as the popular AiTM tool Evilginx, evolves to integrate this capability then it is likely to be by far the most effective verification phishing technique.

Consider the IM phishing example with Slack given above turned into an interactive website.  We would probably see the following steps occur:

• Phishing email sent with a link asking the user to register if they would like to take part in the Apple device trial

• User clicks link and is taken to a custom phishing website that informs them they will need to verify their email for an Apple account to be provisioned for their new device

• User clicks a verification button and the AiTM tool automatically registers a new Apple account and prompts for the verification code

• The target user sees the verification email from Apple arrive in their inbox and copies the code into the phishing website

• The AiTM tool verifies the Apple account using the supplied code and the attack is complete

Putting it all together (with demo)

Now that we’re familiar with cross-IdP impersonation and verification phishing, let’s consider what a full attack chain looks like and what the impact is. 

In doing so, we’ll consider an organization that uses Microsoft Entra as their SSO with strong phishing-resistant MFA and logging and an example downstream SaaS app being Atlassian, which is accessed using a Microsoft social login for SSO. 

• Attacker registers for an IdP account, such as an Apple account with user@example.com and sets a password

• Attacker begins the verification phishing process and convinces a user to supply the verification code

• Attacker verifies their newly created Apple account using the verification code

• Attacker logs in to Atlassian using “Login with Apple” as user@example.com, without having to know the user’s password or MFA factors

• There are no logs generated in Microsoft to show an SSO login to Atlassian was made as it happened via the attacker’s Apple account – the only logs would be within Atlassian itself

Cross-IdP impersonation attack demo

At this point, there’s no better way to demonstrate the attack than to show it. The following narrated video shows cross-idp impersonation in action to compromise an Atlassian account that is normally accessed using a Microsoft Entra account for SSO that is strongly protected with passkeys. 

For the purposes of this demo, we assume some form of successful verification phishing is performed and focus on demonstrating the cross-IdP impersonation aspect.

It doesn't stop there: cross-IdP impersonation for persistence

The problems with cross-IdP impersonation don’t stop at the initial access layer. Consider an attacker who has gained temporary control of an SSO user account, or email inbox, through some other means and is looking to maintain access. Perhaps they have used an AiTM phishing attack to compromise the user’s core SSO identity. 

A common method for achieving this is to create ghost logins on downstream SaaS applications. This depends on what each application supports but it can involve connecting secondary email addresses, connecting separate social accounts, creating API keys or any method that allows a different way to authenticate to the application. These allow the attacker to maintain their access to those applications even if their access to the core SSO identity for the user is revoked. The downside is that it has to be performed on a per-application basis.

However, cross-IdP impersonation is arguably the most powerful ghost login method available. If you already have access to a user’s email inbox through another attack then there is no need to perform verification phishing. Simply register an account with Google/Apple/LinkedIn/X/GitHub or any other major IdP using the email address you have control over, verifying the accounts, and then deleting the email evidence.

An attacker who does this will then maintain the ability to login to any downstream SaaS applications that support any of those login methods without additional verification steps — even if original SSO/email compromise efforts are discovered and contained. In effect, a single persistence technique could potentially maintain access to a range of different downstream applications. 

Why (and when) is this attack possible?

Most SaaS applications support a range of different authentication methods to provide flexibility for the wide range of customers they have and generally make it as simple to sign up as possible — a consequence of product-led growth marketing strategies.

Using more secure, locked-down authentication methods is often left as a task for the administrators of a given customer’s tenant. However, when hundreds of SaaS apps are in use, this doesn’t always happen — maybe the app was self-adopted by a specific team and the security team doesn’t know about it, or they simply haven’t gotten around to it. 

There are far too many applications out there to provide an exhaustive list of what configurations and behaviors are available. Instead, I’ll provide some examples of the different types of controls/configuration you may encounter that can help or hinder this attack technique.

1) Default allow

This is the primary vulnerable case like we have seen with the Atlassian example in this article. Once you have created an account on an application then all other sign-in methods are available by default, making it a prime target for cross-IdP impersonation. 

An important caveat here is this is not a case of Atlassian being uniquely vulnerable. This is a widespread issue with many SaaS apps behaving this way by default. We just used Atlassian as an example because it’s a particularly popular app. 

This also doesn’t mean you have to accept this limitation. It’s often possible to disable other methods, but it requires that app administrators proactively take that step. For example, Atlassian allows third-party logins to be disabled entirely, and more advanced control of authentication options is possible using the Atlassian Guard product too. (See the section on configurable controls, below.)

2) Email verification

Some applications will require their own email verification when a new login method is used. This does not completely prevent the issue, as it’s possible to perform verification phishing of this too, but it’s definitely a mitigating factor that makes an attacker’s life more difficult.

The following screenshots show how this works for Adobe as an example. When logging in with a Google account in this case, it prompts for a verification code from email in order to connect the Google account to the pre-existing Adobe account.

3) Device Verification

Some applications will treat any login from a new device (typically a new browser without a specific cookie set) as requiring a verification code from the linked email account. Again, this isn’t full protection as it still allows a second verification phishing attack, but it is a significant mitigating factor.

An example of this with HubSpot is shown below:

4) Pinned authentication

This is probably the most effective default control that some SaaS apps implement. Once an account has been created, the original authentication method is pinned as being the only acceptable authentication method. Authenticating using a different method will produce an error that cannot be circumvented without using the original authentication method first.

We can see an example of this with Mailchimp below, where we can see after a successful authentication with our malicious Google account we receive an error to indicate that the account is not connected to Google and the original credentials must be used instead.

5) Configurable controls

Many SaaS applications, even if they have no controls in place by default, allow administrators to lock the configuration down if they want to. For example, all supported authentication methods may work by default but it may be possible to disable these individually to ensure only the intended authentication method is possible.

For example, in the case of the Atlassian example we used earlier, it’s possible to disable third-party logins entirely in a basic subscription. More advanced controls over authentication are available using a separate Atlassian Guard subscription:

To give another example, a default Datadog instance may allow Google logins and so be vulnerable to cross-IdP impersonation if password logins or SAML-based SSO logins are normally used. However, an administrator can disable Google logins across the entire organization or on a per-user basis if they wish. 

Alternatively, if an administrator disables both Google and password-based logins then only SAML-based logins will be allowed. Datadog refers to this as ‘SAML strict’. 

This functionality is available without any separate subscriptions:

To give credit where it’s due, it’s worth noting that the examples we’ve used in this blog post offer ways of mitigating this attack – but this isn’t always the case. Many more apps don’t offer this kind of in-app control, leaving customers exposed.  

What steps can SaaS customers take to protect against this threat?

In an ideal world, all SaaS vendors would only support the strongest authentication methods available, default to pinning authentication to the first method used for an account, and allow administrators to flexibly configure authentication rules where required. 

But we don’t live in an ideal world. Many SaaS apps don’t even support SSO and the overwhelming majority of them default to single-factor authentication when users sign up. So how can the average organizations stop their strong SSO controls from being bypassed using cross-IdP impersonation and verification phishing?

Luckily, there are some pragmatic options to significantly increase resilience to these attacks.

Lock your domain with other IdPs

Some IdPs allow you to register and lock your domain with them in order to prevent the creation of personal accounts with them. Apple is one example where you can lock your domain using Apple Business Manager. Maybe you aren’t an Apple user as an organization overall but you want to make sure nobody can create Apple accounts on your domain. Well, you can use this feature to entirely prevent this threat! (For Apple, at least.)

Create detection rules for verification emails from IdP vendors

There are a relatively small number of IdPs that account for the overwhelming majority of social login methods that can be used across a larger number of SaaS apps and the verification emails they send come from predictable addresses with predictable subjects and body formats.  

Your threat hunting teams can create detection rules for this so you are alerted any time a verification request is made on a different IdP vendor. Whether this is from verification phishing, persistence mechanisms or just legitimate users creating shadow SaaS identities, it’s very easy for you to find out about it and then take actions accordingly.

Our friends at Sublime Security don't miss a beat, and have already released a detection rule for this, allowing you to alert on new account creation emails for Apple, GitHub, Microsoft, Google, and Slack.

Audit your SaaS applications for susceptibility to cross-IdP impersonation

Ok, this one is more work, as you might have hundreds of SaaS applications in use overall. It’s better to start with a shortlist of the most widely used and sensitive applications (you’re probably looking at 10 to 20 apps). 

Discovering all the applications in use across your organization and the login methods they use to them is the first part of the problem. It’s also common for multiple login methods to be in use for the same application, a problem known as ghost logins. When you factor in how tricky it is to collect information on application accounts and login methods, and the mixed controls available to enforce the desired configuration in-app, This step is actually much harder than it sounds.

Once you have a list of applications, have your security teams create accounts with other IdPs and then see which of your SaaS applications allow them to login with cross-IdP impersonation, or otherwise which of the controls listed previously apply (e.g. email verification, device verification, pinned authentication etc).

Depending on the results of this, you can reduce vulnerability on an app-by-app basis. Where apps allow it through configuration, have the application owners configure your tenant to restrict authentication options. 

And if you find an application that does not support this feature then pressure the vendor with a feature request, the same as you might for a vendor that doesn’t support SSO.

Ask your red teams to add this technique to their attack simulations

Whether using internal or external red teams, proper adversarial simulation is key to understanding the realistic vulnerability of your organization to a range of attack scenarios. Next time you have a red team operation planned, ask them if they can attempt cross-IdP impersonation and verification phishing as part of an end-to-end attack chain to assess your vulnerability and detection and response controls appropriately. 

In fact, you should probably be asking them to be putting a huge focus on identity attacks in general. Ask them if they can use the open-source SaaS attacks matrix as a basis for an identity attack focused red team operation.

Conclusion

We’ve seen how cross-IdP impersonation enables SaaS applications to be accessed using accounts outside the control of an organization and thus bypassing all controls enforced by SSO, such as:

• Strong password requirements

• MFA

• Phishing-resistant authentication e.g. passkeys or Okta Fastpass

• IP/Location restrictions

• Authentication logs

During the initial access phase of an attack, combining cross-IdP impersonation with verification phishing can allow external attackers to gain permanent access to a range of downstream SaaS applications through the compromise of a single verification code, even if they are normally protected by a rock-solid SSO implementation.

During the persistence phase of a compromise, an attacker can utilize cross-IdP impersonation as an extremely powerful ghost login method in order to maintain access to a range of SaaS applications through a single mechanism, even if containment exercises later remove their access to the original SSO account or email inbox they compromised.

It is extremely important that organizations understand the threat these attacks pose, evaluate their vulnerability to these attacks and implement the prevention and detection controls provided above accordingly.