Steal Application Specific Passwords and MFA Bypass (T1697)

Some older mail clients and devices cannot do multifactor authentication, so providers offer Application Specific Passwords (ASPs) instead. MITRE ATT&CK T1697, Steal Application Specific Passwords, covers adversaries who obtain an ASP to access valid accounts and get around MFA. It is in the Credential Access tactic and applies to Office Suite, Identity Provider and SaaS platforms.

How attackers use it

MITRE describes three routes. An adversary may socially engineer a user into handing over an ASP, for instance through Phishing for Information (T1598). They may generate an ASP for an account they already compromised. Or they may take an ASP stored on a system. With it, they can use Valid Accounts (T1078) and sometimes maintain persistence, with no MFA in the way.

The page lists one procedure example, in which a group stole ASPs to bypass MFA in environments using the Microsoft App Password feature.

How to detect it

MITRE's analytics focus on three things:

• Creation of an ASP for a user, followed shortly by sign-ins from a source, device, client or location outside that account's baseline, or by a legacy or non-MFA authentication path that does not match approved ASP use.
• Successful Office Suite access using an authentication method that skips the account's expected MFA flow, especially from a first-seen client or an unusual device.
• Successful SaaS sign-in through an app password or legacy mechanism from a client not previously tied to that account, followed by new sessions or access that does not fit normal use.

In practice, build an inventory of which accounts legitimately use ASPs, and alert on ASP creation outside that list.

How to reduce the risk

• User training. Teach users not to generate or share an ASP in response to unsolicited instructions.
• Disable or remove the feature. Where modern authentication is available, turn ASPs off. The page notes Microsoft supports disabling users' ability to create app passwords and recommends disabling legacy authentication so existing app passwords stop working.
• Account use policies. Restrict the clients, paths and locations from which legacy or app password accounts can authenticate, so a stolen ASP does not have unlimited reach.
• User account management. Limit who can create ASPs, disable creation where it is not needed and remove existing ones. Microsoft allows admins to disable creation and delete existing ASPs, and Google administrators can view and revoke users' application specific passwords.

Check your own environment

• Which users have app passwords today, and does each one map to a real device or app?
• Is legacy authentication blocked, or limited to named locations?
• Do alerts exist for ASP creation and for sign-ins that skip MFA?
• Is there a revoke step in your leaver and device retirement process?

Quick check

Sources

• MITRE ATT&CK T1697, Steal Application Specific Passwords