How T1697 steal application specific passwords shows up in intrusions
If you run identity and SaaS telemetry, your core question is whether a sign-in came from a person or from a separate secret that someone can reuse. T1697 Steal application specific passwords is a Credential Access technique in which an adversary obtains application specific passwords, the separate secrets that legacy or non-interactive clients use in place of a primary password and interactive multi-factor prompts. Those secrets often sit outside the controls that govern normal sign-in, so the SOC lead and the identity team need to track them together. The technique serves the broader aim that MITRE defines for the Credential Access tactic, TA0006: the adversary is trying to steal account names and passwords. T1697 is one route to that aim, and it deserves its own detection case.
In intrusions, the technique is most relevant on office suite, identity provider and SaaS platforms, where application specific passwords are issued for mail, calendar or file clients that cannot complete modern authentication. Illustrative example: an application password created for a legacy mail client is used from an unfamiliar network, and no one on the security team knows the credential exists. Start with three decisions: which platforms in your estate issue these secrets, who may create them, and whether their use appears in your sign-in logs. Then confirm with each vendor how the secrets are generated and revoked and which authentication or application log events record their use. The data components most often referenced for Credential Access, User Account Authentication and Application Log Content, are the places to look first.
This page targets MITRE ATT&CK Enterprise version 20.0. Confirm the sub-technique and detection strategy mapping against the version your team actually uses, because releases can rename, deprecate or revoke techniques and their detection content. Check the version history on the MITRE ATT&CK updates page before you rely on any mapping in your detection library. For the authoritative technique list and the data component references, read the enterprise-attack 20.0 STIX bundle in the attack-stix-data repository. Record the version in every Sigma rule, Wazuh rule and runbook that cites T1697 so that a later update does not silently change what your detection covers.
Which telemetry reveals application specific password use and misuse
This table maps each data component ATT&CK uses for T1697 to the signal it can reveal, the open-source collector that gathers it, and the coverage limits to confirm. Read it as a starting point for deciding which logs to ingest first, then validate each row against your own identity provider, Office suite and SaaS audit exports.
| Data component | Signal to look for | Collection path and limits |
|---|---|---|
| User Account Authentication (DC0002) | Sign-ins that use an application specific password on a protocol or client that your policy normally blocks, or sign-ins from new client types for the same account | Identity provider and mail or directory logs shipped to Wazuh or Security Onion. Confirm with each vendor which authentication protocols and client types are logged and how they are labeled. |
| Application Log Content (DC0038) | Creation, rotation or first use of an application specific password, followed by unusual mailbox, file or API activity from the same account | Office suite and SaaS audit APIs forwarded through log shipping (for example Filebeat or Fluent Bit into Wazuh or OpenSearch). Confirm audit event names and retention with each vendor, because not every SaaS product records credential creation. |
| Logon Session Creation | A new interactive or service session on an endpoint that runs a client which stores or reuses an application specific password | Windows security logs or Linux authentication logs collected by Wazuh agents. Coverage depends on the endpoint, and logon event detail varies by operating system and audit policy, so confirm the relevant event IDs and fields in your own environment. |
| Process Creation (supporting) | A mail or sync client launched by an unexpected parent process, or a scripted client that authenticates outside managed devices | Endpoint process telemetry from Wazuh or Velociraptor where enabled. Coverage is endpoint-dependent and may be absent on unmanaged or mobile devices. |
| Network Traffic Content (supporting) | Legacy protocol sessions that present application specific passwords to services that should require modern sign-in | Zeek or Suricata sensors on the network path. Encrypted sessions limit visibility, so confirm which protocols your sensors can parse before relying on this row. |
| Account lifecycle events | Application specific passwords created, revoked or left active for accounts that have left the organization | Identity provider admin audit exports. Ask your identity team which admin events are logged and how far back they are retained. |
Detection logic for application specific password abuse
Application specific passwords sit outside the normal sign-in path, so abuse often shows up as a change in how a credential is created or used rather than as a failed login. The cards below pair each idea with the telemetry that reveals it and the baseline you need to tune it. Every threshold should be set from your own environment, not copied from a default.
New credential followed by unfamiliar use
Alert when an application specific password is created for an account and then used within a short window from a new network, country, or client type that the account has not used before. The creation event and the first use event are the two halves of the logic, so correlate them per account. Set the window and the "unfamiliar" definition from 30 to 60 days of your own sign-in history. Expected false positives include users who legitimately add a new mail client after a device refresh, and help desk resets performed from a different site.
Legacy protocol authentication after modern MFA
Flag successful authentications over legacy protocols, such as basic-auth IMAP, POP, or SMTP, for accounts where MFA is enforced for modern sign-in. Application specific passwords are often the only credential these protocols accept, so their use is a strong signal in tenants that have blocked legacy authentication. Review which mail clients, multifunction devices, and line-of-business applications still use these protocols before setting the alert to fire. Expect false positives from older scanners and scheduled report jobs that are documented but not yet migrated.
Burst of sign-ins from one credential
Count distinct source addresses, autonomous systems, or user agents that authenticate with the same application specific password within a rolling window. A single credential appearing from many sources in a short period suggests the secret has been copied out of its intended client. Set the source-count threshold from observed normal behavior for each application, since a mail gateway or sync service can legitimately fan out across many addresses. Service accounts, scheduled jobs, and shared mailbox relays are the usual sources of noise, so tag them and exclude them by named identity.
Credential creation by unusual administrators
Alert when an account that does not normally manage security settings creates or revokes application specific passwords for another user. Compare the actor against a list of accounts that have performed this action in the last 90 days, since that list is the baseline that matters. Legitimate sources of noise include service desk tooling, onboarding automation, and executives who manage their own credentials, so classify those identities up front. Route confirmed unusual creations to the identity team for a same-day check of the target account.
Credential changes outside change windows
Correlate credential creation and revocation events with approved change calendars and ticket references. A spike in application specific password creation during hours when no change or helpdesk activity is planned can indicate an attacker using a stolen session to mint a durable secret. Keep the calendar feed current, because a stale calendar will produce false positives during holidays and staff rotations. Confirm with your identity provider vendor which audit events carry the actor and target fields you need before you build this rule.
How to validate the T1697 detection in a lab before trusting it
This sequence proves that the T1697 detection fires on the telemetry it depends on, under controlled conditions, and documents how quickly and how cleanly it does so before any alert is relied on in production.
Define the expected telemetry first
Before any test is staged, the detection owner writes down which data components the detection depends on for the target platforms, such as User Account Authentication for identity provider and SaaS sign-ins, Application Log Content for office suite and SaaS audit trails, and Logon Session Creation where a host is involved. For each one, list the source system, the log fields expected, and the retention period confirmed with the platform owner. Confirm the ATT&CK version the mapping targets, since releases can rename or deprecate content. The step is done when a reviewer can point from every rule condition to a named log source and field.
Agree test accounts and scope in writing
The security lead, the application owner and the range operator agree in writing which test accounts, applications, tenants and time window are in scope, who approves the exercise, how activity will be tagged so it can be separated from production traffic, and how the test will be stopped. Test accounts should be dedicated, carry no production entitlements, and be reset afterward. Record who holds the approval and where it is stored. The step is done when the signed scope note exists and every test account is listed with its owner.
Run an approved emulation without publishing commands
A qualified tester runs an approved emulation of the behavior described by T1697 inside the private cyber range or a staged tenant, following the agreed scope and the range's operating procedure. Operational details stay in the restricted test record rather than in shared documentation, and the exercise log captures start and end times, accounts used and the systems touched. The team observes live, and the tester can halt activity at any point. The step is done when the test record shows the emulation ran exactly as approved and was closed out.
Confirm the alert fires in Wazuh or the SIEM
The analyst checks the Wazuh manager, the Security Onion or other SIEM console and the case tool for the expected alert, using the rule identifier and the test account tag as filters. They confirm the alert carries the fields defined in step one, that the originating host, account and application are populated, and that no required field is empty or truncated. If the alert does not fire, the team traces whether the log never arrived, the parser dropped it, or the rule logic did not match, and records the cause. The step is done when the alert, its fields and its ingestion path are captured with screenshots or exported records.
Measure time to detection
The team compares the timestamp of the emulated action in the source log with the timestamp of the alert creation in the SIEM and the timestamp when an analyst first viewed it. The gap between the source event and alert creation reflects pipeline latency, and the gap to analyst acknowledgment reflects triage readiness, so both should be recorded separately. Repeat the run if the first result is an outlier, and note any difference between runs. The step is done when the timing table exists for each platform in scope and the team agrees on the measured values.
Record fields present and missing
The analyst compares the alert payload with the field list agreed in step one and marks each field as present, partial or absent for each platform. Gaps are logged against the source configuration, such as an audit setting not enabled on a SaaS tenant or a connector that does not forward a particular event type. Each gap gets an owner and a retest date set by the client, not by DeployOpen. The step is done when the field gap register is complete and every gap has an assigned owner.
Log false positive observations and tune
The team reviews all alerts raised during the window, including those from ordinary administrative activity, service accounts and scheduled jobs, and classifies each as true, benign or unclear. Benign matches are used to refine the rule with documented exclusions tied to named accounts or applications, and each change is versioned and re-tested against the same data. The step is done when every alert in the window has a classification and each tuning change has a linked test result.
Sign off the detection for production
The detection owner, the SOC lead and the compliance contact review the test record, the field gap register, the timing results and the tuning log together. They decide whether the detection is accepted, accepted with conditions, or returned for rework, and they record the ATT&CK version and rule version it applies to. The sign-off also names the review date for the next validation, which should follow any platform upgrade or ATT&CK release. The step is done when the signed decision is stored with the detection's documentation.
Mitigations that reduce application specific password exposure
Application specific passwords sit outside normal sign-in protections, so their exposure is reduced through a small set of controls: user education, account management and retirement of legacy clients. The cards below cover what each control does for T1697 Steal application specific passwords and what to confirm in your own identity and office suite configuration.
User training for password handling
User Training (M1017) is the ATT&CK mitigation that teaches people not to disclose credentials and to recognize requests that ask for them. For application specific passwords, the lesson is narrow: these values are shown once, should be entered only into the app that needs them, and should never be sent through chat, email or a support form. Train administrators and developers as well as general staff, since they generate these passwords most often. Confirm whether your identity provider or office suite lets you show users a clear warning at creation time.
Account management for app passwords
User Account Management (M1018) covers the processes and controls that govern who can create, use and remove accounts and their credentials. For application specific passwords, this means deciding which roles may generate them, reviewing active entries during access reviews, and removing entries when a user leaves or changes role. Ask your identity provider whether it lists app passwords per user for administrators to audit and revoke, and whether that listing is available through an API or only through the console.
Scope application specific passwords
Limit where these passwords are permitted. Use policy to restrict them to the protocols and clients that actually require them, and prefer modern authentication for clients that support it. Where your platform allows it, keep application specific passwords out of accounts that hold privileged roles. Illustrative example: a mail client on a single managed device needs one entry, while a shared service account should have none. Confirm which scoping options your identity provider and office suite expose before writing the policy.
Review creation and usage
Make creation of application specific passwords visible. Forward the account's sign-in and credential-creation events to your SIEM so that a new entry for an account is an alert candidate, not a silent change. Review entries against known devices and clients, and treat a new entry created from an unfamiliar location or shortly after an unrelated sign-in as a question to investigate. Confirm which events your identity provider and office suite write to their audit logs and how long those logs are retained.
Retire legacy clients where possible
Many application specific passwords exist because an older mail, calendar or sync client cannot use modern sign-in. Each legacy client is a standing reason for a password that bypasses standard protections. Inventory which clients still depend on these passwords, set a retirement date with the business owners where operations allow, and move them to modern authentication. Where a legacy client must stay, document the owner, the scope and the review date. Ask your vendor which legacy protocols it still supports and when it plans to disable them.
What SOC analysts do when an application specific password alert fires
The first task for a SOC analyst is to decide whether the application specific password was created by the account owner or by someone who has taken over the account. Start by confirming the owner of the account and the source of the creation event: the IP address, device, client and time of the request, compared with the owner's usual sign-in pattern. Then check whether the credential was created recently and whether it was created in the same session as an unusual primary sign-in. An application specific password created shortly after a sign-in from a new location, or after a password reset, is a stronger signal than one created during a routine session from a known device. Record the answers before changing anything, because containment actions will alter the state you are trying to examine.
Next, review what the credential has been used for. Pull the session activity and mailbox or SaaS audit records for the account over the period between creation and the alert, looking for new inbox rules, forwarding settings, mass downloads, API activity from unfamiliar clients, and sign-ins that bypass multi-factor checks. Confirm which of your log sources actually retain these records and for how long. Retention periods differ between Office Suite, identity provider and SaaS tenants, and a short window can leave a gap that you only discover mid-investigation. Ask the platform owners to confirm retention and export status in writing before the incident starts, and note any gap in the incident record.
Containment decisions should follow your organization's own incident runbooks, including who is authorized to revoke an application specific password, disable an account, or reset a primary credential, and how the account owner is contacted. As a general pattern, revoking the suspect application specific password and resetting the primary credential, with active sessions ended, is the usual path when misuse is plausible, but the threshold and the sequence belong in your runbook. Document each action with the time, the person who approved it, the tool used and the evidence considered, and keep the record in the case file so that it can support the post-incident review and any regulatory reporting your sector requires.
Rehearsing T1697 detection in a private cyber range
The range should mirror the production path that matters for T1697: an identity provider that issues sessions for an office suite or SaaS tenant, and a log pipeline that receives authentication and application events. Use a test tenant for the office suite or SaaS application so that synthetic accounts and application passwords can be created and revoked without touching production users. Wazuh or Security Onion should collect telemetry from the identity provider, the tenant audit logs and the endpoints used by the test accounts. Keep the range in a private network segment with no path to production credentials.
- Identity provider: Configure a test directory with several synthetic user accounts, one of which holds a privileged application role.
- Office suite or SaaS tenant: Enable the tenant audit log export and confirm which application password or app-specific credential events it records.
- Log collector: Ingest authentication and application log content into Wazuh or Security Onion, and document the ingestion path and field names.
- Endpoints: Use a small set of test workstations so that logon session events can be correlated with account activity.
- Time sync: Synchronize all range components to one time source so that timelines match during review.
Before the exercise, check that every data component used by your analytics produces events in the range, because a detection cannot be validated against telemetry that never arrives.
Injects are scripted events the purple team triggers so the blue team can observe how the environment responds. For T1697, injects should describe the behavior in words and the expected telemetry, not the exact steps an adversary would use. Each inject should map to a planned detection strategy, state which data component should show it, and record the expected alert. Keep a written inject log with start and end times, so responders and analysts can be compared against the plan afterward.
- Unusual application credential creation: An application-specific credential is created for a test account outside the normal change window.
- Credential use from a new context: A test credential is used from a location or client the account has not used before.
- Privileged account activity: A high-privilege test account reads or changes application settings that a standard user would not touch.
- Revocation path: The purple team asks the blue team to revoke the credential and confirm the revocation appears in logs.
- Benign control: A normal, approved credential event is included so that false positives can be measured.
Review each inject with the detection owner before the run, and confirm that the controls for the test tenant allow the planned actions.
A good result is a chain of evidence that a reviewer can follow from the alert to the containment decision. The alert should fire within the window the team agreed for the exercise, carry the account and application context, and link to the raw authentication or application event. The analyst should pivot to the affected account, review recent sign-ins, check which application credentials exist, and confirm whether the activity is expected. Containment should be recorded: the credential is revoked or the session is ended, and the ticket names who acted and when.
- Alert timing: The alert fires inside the agreed window, and the time is recorded against the inject log.
- Context in the alert: The alert includes the account, the application, the source and the matching data component.
- Analyst pivot: The analyst documents the account review, including recent sign-ins and existing application credentials.
- Containment record: The revocation or session termination is logged in the tenant audit trail and the ticket.
- Closure note: The team records whether the inject was a true positive, benign or missed.
Ask the range operators to confirm that each step is visible in the telemetry, not only in the ticketing system.
A poor result is any point where the chain breaks. Common gaps include no alert, an alert with no account context, an alert that reaches an inbox nobody watches, or a containment step that is done but not recorded. Each gap should be assigned to a cause: missing telemetry, weak logic, an unclear runbook, or a missing control such as the User Account Management mitigation. Repairs should be tested in the same range before they are trusted in production.
- Missing telemetry: The tenant audit export is not enabled or the log collector drops application events. Fix the export and re-run the inject.
- Weak logic: The rule fires on every authentication, so analysts ignore it. Narrow the logic to the data component and the account population.
- Unclear ownership: No one is named to triage the alert. Assign an owner and an escalation path in the runbook.
- Unrecorded containment: Revocations happen in the tenant console but not in the ticket. Add a required field for the revocation record.
- Control gap: Application credentials are not reviewed on a schedule. Tie the fix to the User Account Management mitigation and retest.
Record each gap, the owner and the retest date, and confirm the retest passes before closing the item.
Questions SOC leads ask about detecting T1697
How do I tell a legitimate mail client sync from stolen application specific password use?
Start from the authentication record, not the mail client. An application specific password should authenticate from a small, known set of hosts, under a known client identity, from the same network ranges over time. A detection should flag a credential that is used from a new country, autonomous system or device, or that begins authenticating through a protocol the user never used before. Build a baseline per account over a representative period, then tune with the help of the mailbox owners. Illustrative example: a sync client that always connects from the corporate VPN range should raise an alert when the same credential appears from a residential address with a new client string. Confirm with your identity provider which fields record the client application, the protocol and the source address for these sign-ins, because the field names differ between platforms.
Which logs should I retain to detect application specific password misuse?
Retain the User Account Authentication records from your identity provider and the mailbox or Office Suite audit logs, because these are the data components most closely tied to this technique. Keep Application Log Content for the account management events: creation, rotation and revocation of application specific passwords, and changes to multi-factor authentication settings. Add Logon Session Creation records where your endpoint or directory platform exposes them. Retention periods should follow your own legal and compliance requirements, not a default in a tool. Confirm with each SaaS vendor which audit events are available on which license tier, how long they are kept in the native console, and whether they can be exported to your SIEM in near real time.
How do I map T1697 detections to ATT&CK version 20.0?
Record the ATT&CK version in every detection's metadata, and map to the technique and the data components named in the Enterprise ATT&CK 20.0 STIX bundle. Because ATT&CK v18 replaced technique-level detections with detection strategies and analytics, write your rules against the detection strategy IDs and data components rather than copying text from an older page. Re-check mappings whenever MITRE publishes a new release, since releases can rename, deprecate or revoke techniques. Store the mapping in version control so you can show auditors which version a rule targeted and when it changed. Confirm the current technique status directly in the attack-stix-data repository for the version you use.
How can I test T1697 detections without disrupting real users?
Test in a private cyber range or a dedicated test tenant that mirrors your identity provider and SaaS configuration. Create synthetic user accounts, generate application specific password sign-ins from controlled hosts, and confirm that each expected event reaches your SIEM with the fields your rule uses. Measure whether alerts fire, how long they take to appear, and whether the responders receive enough context to act. Run the same tests after each change to log pipelines or rules. Keep production tests limited to read-only checks of log ingestion, and coordinate them with the service desk so that no one is locked out during a rehearsal.
What should I do when a SaaS vendor does not expose the fields I need?
First, document the gap precisely: which event, which field and which platform or license tier. Then check whether the vendor offers an alternative source, such as an administrative audit log, a streaming export, or an API that returns sign-in details. Where no source provides the field, compensate with controls you can own: block or restrict legacy authentication where the vendor allows it, enforce multi-factor authentication for accounts that can create application specific passwords, and alert on the account management events that are available. Record the residual risk in your register and review it at each release. Ask the vendor in writing which fields are supported, how they are delivered, and whether the schema is documented.
Which mitigations should I prioritize for application specific passwords?
ATT&CK maps two mitigations to this technique in the Enterprise 20.0 data: User Training (M1017) and User Account Management (M1018). User Account Management is the one you can enforce technically. Review which accounts can create or hold application specific passwords, remove the feature where a business need does not exist, and set review cycles for those that remain. User Training helps users recognize requests to generate or share these passwords, which attackers often use in phishing. Confirm with your identity and SaaS administrators which settings are available in your tenants before you write the policy, because options differ by product and plan.
How long does it take to build T1697 detections in-house?
The effort depends on how many platforms you cover, how much logging is already in place and how many rules your team must tune. The main components are log source onboarding, parsing and normalization, baseline tuning with mailbox owners, rule testing in a range and response runbook writing. Most of this effort is one-time, but tuning, ATT&CK mapping updates and vendor schema changes recur. Ask any partner for a written scope that lists the platforms, the rules, the test cases and the handover deliverables. DeployOpen plans and implements these engagements on a fixed scope agreed in writing, and it does not publish a price list.
How DeployOpen builds T1697 detections and range scenarios
DeployOpen approaches T1697 Steal application specific passwords as a written, fixed-scope engagement inside the client's own environment. The work covers the Office Suite, identity provider and SaaS telemetry that reveals this technique, from scoping through to a tested detection set and a private cyber range rehearsal.
How we scope
- Confirm which Office Suite, identity provider and SaaS applications are in the written scope for T1697 detection.
- Map the User Account Authentication, Application Log Content and Logon Session Creation sources each application can actually emit.
- Record the ATT&CK version the detection mapping targets, so later releases can be reviewed against it.
How we build
- Build open-source collection and detection logic for T1697 in the client's own stack, with rules described and reviewed in plain language.
- Validate each detection against telemetry from the client's applications, checking for gaps in logging and retention.
- Rehearse T1697 detection and response scenarios in a private cyber range before the rules reach production.
How we hand over
- Deliver written documentation covering data sources, detection logic, tuning notes and known blind spots for T1697.
- Provide response runbooks that map alerts to the User Training and User Account Management mitigations in the client's processes.
- Walk the client's security operations team through the range results and the open items agreed in the written scope.
How we support
- Ongoing support, upgrades and continuous testing for T1697 detections are available as a retainer, agreed in writing.
- Review detection mappings when MITRE publishes ATT&CK releases that rename, deprecate or revoke related techniques.
- Confirm with the client's compliance lead which evidence from the detection work is useful for their assessment, since independent auditors issue any assessment outcome.
