How to Use MITRE ATT&CK for Credential Access Incidents

Credential access incidents can involve stolen passwords, credential dumping, password-store access, session cookies, MFA interception, or other attempts to obtain material that enables account access.

Short answer: map the observed evidence to the narrowest supported MITRE ATT&CK technique, preserve the source and confidence, investigate whether the credentials were used, and track containment and validation as separate incident actions.

The Credential Access tactic describes the adversary’s goal. It does not prove that credentials were successfully obtained or used.

Start by defining what was observed

Record the facts before choosing a technique:

• Account, host, service, or credential store involved.
• Process, command, access request, or authentication event.
• Source system, timestamp, and data quality.
• Whether the activity was authorised or expected.
• Whether credentials, hashes, tokens, or cookies were exposed.
• Whether the material was accessed, copied, or used.
• Related accounts, hosts, sessions, or privilege changes.
• Actions already taken and evidence preserved.

Avoid writing “credentials stolen” when the evidence only shows a suspicious process or a blocked attempt.

Common ATT&CK techniques to consider

OS Credential Dumping: T1003

Use this family when evidence indicates attempts to obtain credential material from operating-system stores, memory, directory databases, or related sources.

The sub-technique should match the evidence. For example, LSASS memory, Security Account Manager, NTDS, LSA Secrets, and DCSync describe different behaviors and environments.

Do not infer a specific sub-technique from a tool name alone. Confirm the host, process, access pattern, and data involved.

Credentials from Password Stores: T1555

Consider this family when an application, browser, operating system, or cloud password store may have been accessed to obtain credentials.

The ticket should record the store, account context, access evidence, and whether the stored material was actually retrieved or used.

Input Capture: T1056

Consider Input Capture when the evidence suggests credential input was intercepted through a keylogger, screen capture, web portal capture, or another input mechanism. Use a sub-technique only when the observed behavior supports it.

Steal Web Session Cookie: T1539

Consider this technique when evidence points to the theft or use of web-session cookies as an alternative to a password. Authentication logs, browser activity, token changes, and session revocation records may be relevant.

Multi-Factor Authentication Interception: T1111

Use this mapping when the evidence supports interception of an MFA mechanism or factor. A failed MFA prompt or repeated push notification is not automatically proof of interception.

Build the investigation around the credential lifecycle

Ask questions in order:

1. What credential, token, cookie, or account was targeted?
2. Where was it stored or entered?
3. What evidence shows access, attempted access, or extraction?
4. Was the material copied, transmitted, or used?
5. Which accounts, devices, services, or data may be affected?
6. What sessions, keys, tokens, or credentials need revocation or rotation?
7. What evidence is required to validate containment?

This separates the initial access attempt from later use, persistence, privilege escalation, or lateral movement.

Use an ATT&CK-aware incident ticket

Keep credential containment actions separate from general investigation notes. A credential reset, session revocation, or key rotation should have its own owner, timestamp, evidence, and validation result.

Preserve evidence before changing the state

Containment can destroy or alter useful evidence. Coordinate the sequence with the responsible investigator and the organisation’s legal, privacy, and retention requirements.

Depending on the situation, preserve:

• Identity-provider sign-in and session records.
• Endpoint or server process and security logs.
• Access-control and privilege-change records.
• Relevant browser or application evidence.
• Mail, phishing, or user-report records.
• Cloud audit events.
• Hashes, file paths, and timestamps.

Do not collect unnecessary secrets or copy credentials into an incident system. Record the evidence location and access controls instead.

Validate that containment worked

Credential containment is not complete because a password was changed.

Validation may include:

• Confirming old passwords, sessions, tokens, or cookies no longer work.
• Checking for additional accounts or systems using the same credential.
• Reviewing new authentication activity after the change.
• Confirming MFA and recovery methods are trusted.
• Checking for persistence, account changes, or new access paths.
• Recording residual uncertainty and the monitoring period.

See How to Validate Whether an Incident Was Really Contained and How to Plan Recovery Actions Without Reintroducing Risk.

Connect credential findings to control improvement

Credential access findings may lead to improvements in:

• Privileged-access management.
• MFA enforcement and recovery methods.
• Password and secret storage.
• Endpoint and identity logging.
• Session lifetime and revocation.
• Access reviews and offboarding.
• Incident intake and escalation.
• Evidence retention and monitoring.

The MITRE ATT&CK mapping pillar explains how to preserve mapping confidence and investigation actions in the incident record. The security improvement loop explains how to carry those lessons into controls, policies, and evidence.

IncidentAI can support structured credential-related incident records, triage, ownership, evidence, timelines, and ATT&CK context where relevant. It does not decide whether compromise occurred, determine legal obligations, or replace human investigation.

Quick FAQ

Does a suspicious credential-related process prove credential theft?

No. It may indicate an attempted access, legitimate administration, a security tool, or another explanation. Preserve the evidence and record the confidence of the technique mapping.

Is Valid Accounts a Credential Access technique?

Valid Accounts can support several adversary goals, including Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Use it when the evidence supports adversary use of legitimate account access, not merely because a login was unusual.

Should credentials be stored in the incident ticket?

No. Record the evidence location and relevant metadata, protect sensitive material, and follow approved handling and retention rules.

Sources

• MITRE ATT&CK Enterprise Tactics
• MITRE ATT&CK OS Credential Dumping
• MITRE ATT&CK Credentials from Password Stores
• MITRE ATT&CK Input Capture
• MITRE ATT&CK Steal Web Session Cookie
• MITRE ATT&CK Multi-Factor Authentication Interception