Attackers in the wild have been observed using advanced social engineering tactics to convince victims to create and share App-Specific Passwords, representing the latest in phishing tactics capable of sidestepping otherwise phishing-resistant login methods, and bypassing MFA checks.
Attackers in the wild have been observed using advanced social engineering tactics to convince victims to create and share App-Specific Passwords, representing the latest in phishing tactics capable of sidestepping otherwise phishing-resistant login methods, and bypassing MFA checks.
App-Specific Passwords (ASPs) are a way for users to access applications that do not support MFA or are otherwise incompatible with a platform’s standard login workflows. They are intended to enable a user to login to “legacy” (typically desktop) applications that do not support modern authentication (e.g. OAuth 2.0). For example, you might use this feature to allow a third-party mail client access to an email account by logging in with your Microsoft, Google, or Apple account.
The logic behind this is that it is comparatively more secure than giving your critical IdP password to less secure apps — likely due to the volume of accounts compromised as a result of third-party breaches. It also means that if someone phishes your primary account password that normally has a second factor, that specific password can’t be used without the second factor.
However, if an ASP is acquired by an attacker, it can be used to login to the target app — circumventing phishing-resistant authentication methods such as passkeys, and bypassing MFA checks. It effectively provides a method of sidestepping your preferred login method. So for example, if you're an organization that uses a passwordless login to access your Google Workspace account and has disabled secondary login methods (the gold standard in terms of secure authentication), an ASP gives attackers a way around this.
With recent evidence of exploitation in the wild in the form of app-specific password phishing, our latest addition to the SaaS attacks matrix, it’s important that security teams are aware of this technique, what the risks are, and how to defend against it.
Let’s take a quick look at how this actually works before we dive into the malicious use cases.
ASPs 101
ASPs are pretty straightforward. You log into your chosen account (e.g. Microsoft, Google, or Apple) and navigate to the ASP creation page — in Google’s case myaccount.google.com/apppasswords. Then, it’s as simple as typing in a name and hitting the “create” button.
This isn’t actually app-specific in the sense that it’s tied to a specific app at the point of creation, but the idea is that you’d create a unique password for each app you want to log into.
From this point, you can use the password along with your email address to log into apps normally. It’s important to note that this isn’t available for every app, but is specifically intended for things like third-party email clients. By logging in with an ASP, you are also granting specific permissions to the app. So in the case of Google, you can view, send and delete emails, access contacts, and access the calendar, but you can’t add mail rules, or access other G-Suite apps like Google Drive.
It’s important to note that you can’t use this as a substitute for SSO — e.g. you can’t authenticate to a third-party app like Slack using your Google account with an ASP, so the risk is somewhat limited to basic email functionality. That said, email access gives an attacker plenty to work with, and it’s enough to move laterally to other accounts through password and MFA resets — so there’s plenty of scope to expand the blast radius with a little extra legwork.
How ASP phishing works
While logging in with an ASP doesn’t grant an attacker full access to the account, there’s still a lot that an attacker can do with access to email, contact, and calendar information. It’s certainly enough to be used in social engineering attacks impersonating the compromised user, as well as generally monitoring email activity.
An example of this was recently disclosed where an expert on Russian information operations was targeted with a sophisticated and personalized social engineering attack, where the attacker was able to establish persistent access to the victim’s mailbox using ASPs by logging into a mail client.
This involved a sophisticated lure impersonating the US Department of State instructing the victim on how to create and share an ASP with the attacker, granting access to their Google mailbox.
Benefits and limitations of ASP phishing
This approach has a few advantages over conventional credential phishing:
It completely sidesteps otherwise phishing-resistant login methods such as passkeys, and by design does not require MFA.
This kind of attack also naturally doesn’t trigger many typical phishing or malware-based detections. As it’s pure social engineering, there is no malicious link, page, or file to analyse.
For less technically aware victims, this might present a more effective alternative to traditional credential phishing — awareness training won’t extend to this kind of use case.
While generic security alert emails are generated when an app password is created, visibility of actual login events is limited. For example, Google provides no logs for ASP creation and usage, while Microsoft provides no on-premises logging or auditing capability.
However, there are also limitations that will probably see this technique remain a niche choice for attackers. Namely, the complexity of the attack doesn’t necessarily map to the payoff, where it doesn’t result in full account compromise and the permissions/scopes of an ASP login are limited. This means that it lends itself to multi-step attacks, most likely as part of more targeted and stealthy attacks against specific individuals (as seen in the example above). For this reason, attackers are likely to prioritize other methods when they are available.
Comparing ASPs with other auth bypasses
ASP phishing is part of a growing trend of phishing techniques focused on bypassing conventional authentication. With more organizations investing in phishing-resistant authentication methods like passkeys/WebAuthn and using SSO as standard, attackers are increasingly looking to circumvent the standard login process entirely.
Similar phishing approaches designed to circumvent an account’s authentication controls include:
Phishing for API keys, which has the advantage of granting full access to the account, and persisting even if the account password is changed (in contrast, Google resets all ASPs if the account password is changed).
Consent phishing, which sees the victim accept OAuth scopes for an attacker-controlled app integration granting access to the account without needing to directly compromise it. (You can read more about recent examples here.)
Device code phishing, functionally very similar to consent phishing but involving the victim entering a code for authorization.
Cross-IdP impersonation, which sees the attacker register a new IdP connected to the victim’s email account that can be used to access connected apps via SSO without directly compromising the primary IdP. (You can read more about this here.)
Clearly, ASP phishing is part of a much bigger trend in which attackers are moving away from conventional phishing tactics in order to sidestep the authentication process.
Conclusion
There is a common misconception that adopting SSO-based logins, with a locked-down IdP account is an identity security silver bullet. The reality is that identity, authentication, and authorization is a complex and little-understood space. Even with SSO, there are ghost logins, backup login and MFA methods susceptible to downgrade attacks, and as we’ve seen with ASP phishing and similar techniques, many, many more ways to compromise an identity.
Security teams need to approach the complexity of identity security with their eyes open to reality. Without a full picture of how your various workforce identities can be accessed by your users, exploitable gaps will inevitably be left for attackers to take advantage of.
Recommendations
Given the logging challenges relating to ASP creation and use, the best option is to prevent ASPs from being created in the first place.
By default, users can't create app passwords in Microsoft. The app passwords feature must be enabled before users can use them. To check if this option is turned on, you can see and toggle the setting in Entra by browsing to Conditional Access > Named locations > Configure MFA trusted IPs > Multifactor authentication page > Allow users to create app passwords to sign in to non-browser apps option.
Apple and Google ASPs can’t be disabled in the same way… but don’t worry. That’s where Push comes in.
How Push can help
We’re working on adding visibility for ASPs being created, but users of our browser-based security platform can use existing features to prevent ASP phishing. Realistically, there’s no good reason for the average user to be configuring ASPs. So, you can use our URL blocking feature to prevent employees from accessing the pages for ASP creation on relevant apps.
When a user tries to access the page, they’ll see this message instead and a security alert will be generated.
It is recommended that you block the following URLs for Google and Apple:
Unfortunately, there is no specific link to the Microsoft creation page — but as established above, this should not be enabled by default in Microsoft.
If you encounter any more apps which allow ASPs, you can similarly add the specific ASP creation page to the list of blocked URLs.
Want to learn more about Push?
And that’s not all — Push provides comprehensive identity attack detection and response capabilities against techniques like AiTM phishing, credential stuffing, password spraying and session hijacking using stolen session tokens. You can also use Push to find and fix identity vulnerabilities across every app that your employees use, like: ghost logins; SSO coverage gaps; MFA gaps; weak, breached and reused passwords; risky OAuth integrations; and more.
If you want to learn more about how Push helps you to detect and defeat common identity attack techniques, book some time with one of our team for a live demo.
