Every Credential Exposure Finding Now Carries Its MITRE ATT&CK® Techniques

The Rule We Held Ourselves To

It is easy to decorate an event with technique IDs. It is harder to do it honestly. The temptation with intelligence data is to tag everything an exposure could lead to, which turns a leaked password into a wall of Initial Access, Persistence and Lateral Movement techniques that nobody saw happen.

We followed CISA's Best Practices for MITRE ATT&CK Mapping, which says, in effect: do not infer a technique unless it is explicitly evidenced or there is no other technical way the behaviour could have happened, and map to the sub-technique only when the data supports it. That gives every tag we emit a basis, and there are only two values:

• Observed. The artefact we hold is evidence the technique ran. A stealer log's browser field is proof the credential came out of a browser password store. The log sitting in an adversary channel is proof it was gathered.
• Inferred. A step the finding implies but we did not see. We use it sparingly, and the event says so.

What We Tag

The anchor technique is one most intelligence vendors skip: T1589.001, Gather Victim Identity Information: Credentials. ATT&CK v20 rewrote its description this month, and it now describes breach dumps, dark web markets and the Telegram channels that distribute infostealer logs by name. That is our entire collection surface. When we find your domain in a combolist or a stealer dump, that technique has demonstrably occurred, so it is tagged as observed on every finding.

Infostealer findings add the Credential Access techniques the log itself proves. A browser-saved password is T1555.003, not the parent T1555 that most tools settle for. Cookies in the log add T1539, Steal Web Session Cookie. SSH keys, VPN configs, password-manager vaults and application tokens each add their own sub-technique, and only when that artefact class is actually present in the log. Where ATT&CK has a Software entry for the family, the finding carries it too: RedLine is S1240, Lumma S1213, Raccoon S1148, and Vidar got its own entry in v20 as S9050. For families ATT&CK has not catalogued, we give you the name and no invented ID.

Breach records are tagged differently from stealer logs, because they are different evidence. A breach row says a credential was gathered; it says nothing about a browser or a device, so it does not get a browser technique. A record with no password at all gets T1589.002, Email Addresses, and nothing more. The full mapping, generated from the same table the feeds use, is on the MITRE ATT&CK page.

What We Refuse to Tag

You will not find T1078, Valid Accounts, on a DarkStrata finding, even though a leaked password is the textbook precondition for it. The reason is simple: validity is not use. We can know a password is valid, because Lens lets the employee confirm it is theirs and still current, and that confirmation rightly makes the alert critical. What nothing in our data proves is that an attacker logged in with it. Your identity provider sees that; we do not. Tagging T1078 on a raw exposure would claim an intrusion we have no evidence of, and it would quietly inflate every coverage chart downstream. The same goes for Credential Stuffing (T1110.004), which we tag as inferred only when the pattern genuinely suggests it: dozens of outside users' saved logins to your own service surfacing in a single window.

This is the honest shape of exposure intelligence. It is dense before the perimeter, from Reconnaissance through Credential Access, and silent after it. We would rather tell you exactly where our evidence stops than paint half the matrix.

Where It Fits Your Existing Detections

ATT&CK v20 shipped its own answer to "what is a leaked-credential feed for?". Detection strategy DET0460, Credential Stuffing Detection via Reused Breached Credentials, includes analytics whose optional enrichment is a lookup against a known-leaked-credentials database. DarkStrata is that enrichment. Your SIEM detects the login attempt; our tag tells it the password was already in adversary hands, and from which kind of source.

For remediation, we map to MITRE D3FEND™ in docs rather than in events, because D3FEND describes what the defender does, not what the attacker did. Findings point to Credential Revocation, Session Termination, Authentication Cache Invalidation and Multi-factor Authentication, and we say plainly that D3FEND has no leaked-credential artefact, so that mapping is our analysis rather than part of the framework.

In Your Tools

• CEF: technique IDs in cs6, tactics in flexString1, the family's Software ID in flexString2, and a signature ID that now names the finding class, so Sentinel and ArcSight rules can split fresh infections from recycled lists.
• LEEF: mitreTechniques, mitreTactics and malwareFamily.
• STIX 2.1: kill_chain_phases and MITRE external references on every indicator, so OpenCTI and Elastic link straight to the ATT&CK objects they already hold.
• Splunk: add-on 1.2.0 extracts the techniques into mitre_technique_id and annotates the Enterprise Security correlation searches, so notable events arrive with their techniques attached.
• Webhooks and tickets: data.alert.mitre on every alert event, flattened into ServiceNow, Jira, Zendesk and Freshdesk tickets automatically.

There is also a downloadable ATT&CK Navigator layer of the techniques our findings can carry, generated from the live mapping table. Import it next to your detection coverage and the gap it fills is obvious.

Keeping It Current

ATT&CK releases twice a year, and v20 was not a gentle one: a tactic renamed, a new tactic added, a family of techniques revoked. Our mapping table is versioned, every event states which ATT&CK version stamped it, and we re-check the table against each release so you never receive a retired ID. History is never re-tagged.

Read the full finding-by-finding mapping, or open your feed and look at the next event. The techniques are already there.