MITRE ATT&CK T1697 Steal Application Specific Passwords: Detecting and Preventing Credential Theft

An application specific password (ASP) is a second, static password for the same account that signs in without the MFA prompt, so an attacker who obtains one has a quiet, durable way in. MITRE ATT&CK v20 tracks this as T1697 Steal Application Specific Passwords, a Credential Access technique on the Office Suite, Identity Provider and SaaS platforms. This guide covers how ASPs are obtained and abused, the identity provider settings that decide your exposure, the DET0926 detection analytics, and a response sequence that actually removes the access. It is written for identity engineers, detection engineers and Microsoft 365 or Google Workspace administrators. For the wider tactic, start with the ATT&CK Credential Access Tactic Guide; for retiring the protocols that ASPs exist to serve, see the Legacy Authentication and ROPC Retirement Guide.

Key takeaways

• An ASP is an MFA exception you issued yourself. ATT&CK describes ASPs as passwords that give third-party apps or legacy devices account access, and notes that using one bypasses any MFA set on the account.
• Three ways to get one. Social engineering the user into generating and sharing it, generating a new one from an already compromised session, or reading one stored on a system where an older mail client saved it.
• A password reset may not end it. Microsoft Learn states that Entra ID app passwords are not revoked when the user's password is reset, while Google and Apple revoke ASPs automatically on a password change. Know which rule applies to each of your identity providers.
• Creation is the best early signal. An ASP created shortly after an unusual sign-in, followed by a legacy or non-interactive sign-in from a new client or location, is the core DET0926 pattern.
• The durable fix is to need none. Turn off ASP creation, block legacy authentication with Conditional Access or the equivalent, and move the remaining clients to modern authentication. As of November 2026 all three major providers document how to do this.

How the technique works

ATT&CK defines T1697 as adversaries stealing ASPs to gain access to T1078 Valid Accounts while bypassing MFA. The technique has no sub-techniques. Its value to an attacker comes from what an ASP is: a provider-generated secret that stands in for the user's password in a client that cannot complete an interactive MFA challenge, such as an older mail client using IMAP, POP or Exchange ActiveSync. Once issued, the ASP authenticates on its own. No push, code or security key is asked for.

Acquisition routes

1. Social engineering: the user is talked into generating an ASP and reading it out or pasting it into a form, often under a pretext such as fixing a mail sync problem. ATT&CK links this route to T1598 Phishing for Information; the house guide is the MITRE ATT&CK T1598 Phishing for Information page.
2. Generation from a compromised session: an attacker who already holds a session (for example after an adversary-in-the-middle phish or an approved push) opens the user's security settings and creates a new ASP. This turns a short-lived session into a credential that survives session revocation.
3. Theft from storage: clients that use ASPs store them, so an infostealer or an attacker with file access on the endpoint may recover one. This overlaps with T1555 Credentials from Password Stores.

In the wild

ATT&CK v20 lists one group against T1697: APT42, which it records stealing ASPs to bypass MFA requirements, including in victim environments that used Microsoft's App Password feature. The Charming Kitten (APT35) Threat Actor Profile covers the related Iranian cluster.

Know your exposure: ASP behaviour by provider

ASP rules differ by provider, and the differences decide both the attack surface and the response steps. The table records what each provider's own documentation states as of November 2026. Providers are listed alphabetically. Confirm current values in each vendor's documentation before relying on them. Platform hardening beyond ASPs is covered in the Google Workspace Security Guide and the Entra ID Security Guide.

Two Microsoft details matter for response. First, when an admin clears the app password setting, Microsoft Learn states that existing app passwords keep working, but users can no longer manage or delete them; the documented way to stop them is a Conditional Access policy that blocks legacy authentication. Second, for federated domains, app passwords are verified by Entra ID and bypass federation, so on-premises access policies and on-premises authentication logs do not see them. Your evidence for these sign-ins is in Entra ID, not your federation server.

Prevention and hardening

ATT&CK maps four mitigations to T1697. The table turns each into concrete settings.

Hardening steps that matter most

• Block legacy authentication first, in report-only mode: Microsoft's documented policy targets All users and All resources, sets Client apps to Exchange ActiveSync clients and Other clients, grants Block access, and starts as Report-only. Exclude at least one emergency access account; see the Break-Glass Account Guide.
• Retire the per-user MFA dependency: app passwords belong to the per-user MFA model. Moving to Conditional Access based MFA removes the reason to keep them. See Entra Per-User MFA to Conditional Access.
• Prefer delegated sign-in: Google and Apple both document signing in with the account itself ("Sign in with Google", or authorising with an Apple Account for supported mail, calendar and contacts apps) as the alternative to an ASP.
• Use phishing-resistant MFA for the session that could create an ASP: generation from a compromised session is the stealthiest route, so protect the security settings page with strong authentication. Google notes that accounts using only security keys may not see the app password option at all. See the Phishing-Resistant MFA Guide.
• Do not use ASPs for automation: Microsoft Learn describes app passwords as a sign-in method for non-browser apps, not for administrative actions in tools such as PowerShell. Apple documents a limit of 25 active app-specific passwords and Microsoft a limit of 40 per user, so a user near either number is worth a look. Scripts and integrations belong on workload identities, not on a person's account with an MFA exception.

Detection: the DET0926 analytics

ATT&CK v20 detection strategy DET0926, Suspicious Acquisition and Use of Application-Specific Passwords, has three analytics. Each is a correlation, not a single event, and each uses a tunable time window (ATT&CK calls it ASPActivityWindow) and a list of approved ASP uses (ApprovedASPUsage).

Turning the analytics into rules

• Rule 1, creation after risk: ASP or app password created within 24 hours of a risky or first-seen-location sign-in for the same user. The 24-hour window is our starting point; tune it to your volume.
• Rule 2, legacy sign-in from a new client: in Entra ID sign-in logs, add the Client App column and filter for legacy protocols on both interactive and non-interactive tabs. Alert when a user's first legacy sign-in in 90 days appears, or when it comes from a hosting provider or anonymising network.
• Rule 3, any ASP where policy says none: if ASP creation is supposed to be off, any creation event or any last-used date that moves in the Google Admin console is an incident, not an anomaly.
• Rule 4, mailbox access after ASP use: correlate legacy sign-ins with mailbox access events such as MailItemsAccessed in the unified audit log, which shows what the session read.

Hunting questions

• Which users have any ASP today, and which of those still have a business reason?
• Which ASPs show a last-used date but belong to users who report no legacy client?
• Which successful sign-ins carry a legacy client value while the user's normal sign-ins satisfy MFA?

Response: removing ASP-based access

Treat a confirmed malicious ASP as an account compromise. The Account Takeover Response Playbook covers the full process; the ASP-specific steps are these.

1. Preserve evidence first: export the sign-in and audit events for the user covering the window before and after ASP creation, including non-interactive sign-ins and the mailbox audit log.
2. Revoke the ASPs explicitly: in Google, revoke from the user's Security page in the Admin console; in Apple, use Revoke All; in Entra ID, have the user delete app passwords and apply the legacy authentication block to the account. Do not rely on a password reset in Entra ID: app passwords survive it.
3. Reset the password and revoke sessions: this ends the original session the attacker used to generate the ASP.
4. Re-register MFA methods: check for methods added during the compromise window and remove any the user does not recognise.
5. Check for other persistence: mailbox forwarding rules, delegated access and OAuth grants made by the same account. See the Business Email Compromise Response Playbook.
6. Close the door: if the user needed the ASP for a real client, move that client to modern authentication before removing the exception.

Decision guidance

• Small organisation on one provider: turn ASP creation off and block legacy authentication outright. The number of genuine legacy clients is usually small enough to fix by hand.
• Large or hybrid estate: run the legacy block in report-only mode for at least two weeks (our suggestion), build an exception group with a named owner and expiry date for each member, and monitor that group with the rules above.
• Devices that cannot be upgraded: multifunction printers and line-of-business systems that send mail are better served by a dedicated relay or a workload identity than by a person's ASP. See the Exchange Online SMTP AUTH Basic Auth Retirement guide.
• Federated tenants: because app passwords bypass federation, do not assume on-premises policy protects you; decide in Entra ID.

Where identity fits

An ASP is a long-lived, non-interactive credential attached to a human account. In practice it behaves like a non-human credential that nobody inventories: it has no owner field, no expiry and, in Entra ID, survives a password reset. Treat ASPs as part of the credential inventory, with the same questions you ask of an API key: who issued it, what uses it, when was it last used and how is it revoked. Our MFA Fatigue and Bypass Guide covers the other routes attackers use to get past MFA.

Framework mapping

Measuring progress

• Number of accounts holding at least one ASP, trending to zero or to a documented exception list.
• Percentage of successful sign-ins using legacy client types, from the sign-in log Client App field.
• Exception group size and the share of members with an owner and expiry date.
• Time from an ASP creation event to analyst review.
• Number of help desk requests for ASPs, which shows whether modern client migration is keeping up.

Common failure patterns

• Resetting the password and closing the ticket: in Entra ID the app password keeps working after the reset.
• Turning off creation and assuming the job is done: Microsoft documents that existing app passwords keep working until legacy authentication is blocked.
• Looking only at interactive sign-ins: much ASP use appears in non-interactive sign-in logs.
• Trusting federation logs: app passwords for federated users are validated in the cloud, so on-premises logs are silent.
• Permanent exceptions: exclusion groups for the legacy block grow quietly and are never reviewed.

Practitioner checklist

• Record the ASP setting and default for every identity provider you run, using the table above.
• Turn off ASP creation in Entra ID unless a documented exception needs it.
• Deploy a legacy authentication block in report-only mode, review, then enforce.
• Export every user with an ASP in Google Workspace and confirm each with the user.
• Build alerts for ASP creation after a risky sign-in and for first-seen legacy sign-ins.
• Add "revoke ASPs explicitly" to account takeover runbooks for each provider.
• Give every legacy exception an owner and expiry date and review it monthly.
• Brief the help desk and users: nobody legitimate asks for an app password over the phone or chat.

Standards and references

• MITRE ATT&CK: Steal Application Specific Passwords (T1697)
• MITRE ATT&CK: Valid Accounts (T1078)
• Microsoft Learn: Enforce Microsoft Entra multifactor authentication with legacy applications using app passwords
• Microsoft Learn: Block legacy authentication with Conditional Access
• Google Account Help: Sign in with app passwords
• Google Workspace Admin Help: Manage a user's security settings
• Apple Support: Sign in to apps with your Apple Account using app-specific passwords

Related NHI Mgmt Group resources: ATT&CK Credential Access Tactic Guide · Legacy Authentication and ROPC Retirement Guide · MFA Fatigue and Bypass Guide · Conditional Access Guide · Account Takeover Response Playbook