DarkStrata and MITRE ATT&CK®
Every finding is tagged with the ATT&CK techniques the artefact evidences (observed) or implies (inferred). The tag travels with the finding in the API, webhooks, CEF, LEEF, STIX and the Splunk add-on.
How we decide a tag
We follow CISA's Best Practices for MITRE ATT&CK Mapping. Each tag carries a basis:
- Observed: the technique is evidenced in the artefact we hold, or there is no other technical way the artefact could exist. A browser login inside a stealer log is observed Credentials from Web Browsers.
- Inferred: a precondition or next step we did not see. Inferred tags are always labelled inferred.
- We tag a sub-technique only when the data supports it, and the parent technique otherwise.
Valid Accounts (T1078) is never tagged, even when Lens has confirmed the password is current. A valid credential is not a used one: nothing in our data proves an attacker logged in with it, so we do not claim it.
Finding classes and their techniques
Generated from the same table the feeds use. Technique IDs link to the ATT&CK site.
| Finding class | What it means | Techniques |
|---|---|---|
| Stealer log, fresh infection | A staff credential in a recent infostealer log from an infected device. | |
| Stealer log, password also breached | A real infection whose password also appears in an older breach. The infection is still real. | |
| Stealer-channel combolist | A credential traded in a stealer channel that looks recycled from a combolist, not freshly stolen. |
|
| Stealer log, limited data | A stealer log with too little context to judge freshness, where the malware family is known. | |
| Customer logins at stuffing volume | Outsiders' saved logins to your own service, with 50 or more distinct accounts in one alert window. | |
| Breach record with password | A third-party breach record holding a password or password hash. |
|
| Breach record, identifier only | A third-party breach record holding the email address but no secret. |
|
| Combolist | A credential pair from a curator-flagged combolist. |
|
Extra techniques from the stealer log's contents
When a stealer log shows the malware also took these artefacts, the stealer findings above gain the matching technique, always observed. Combolist rows never do.
| Artefact in the log | Technique |
|---|---|
| Browser cookies | T1539 Steal Web Session Cookie |
| Password manager data | T1555.005 Credentials from Password Stores: Password Managers |
| SSH keys | T1552.004 Unsecured Credentials: Private Keys |
| VPN configuration | T1552.001 Unsecured Credentials: Credentials In Files |
| FTP client credentials | T1552.001 Unsecured Credentials: Credentials In Files |
| Wi-Fi profiles | T1552.001 Unsecured Credentials: Credentials In Files |
| Discord tokens | T1528 Steal Application Access Token |
| Telegram session | T1528 Steal Application Access Token |
| Messaging app data | T1528 Steal Application Access Token |
| Two-factor app data | T1555 Credentials from Password Stores |
| Email client credentials | T1555 Credentials from Password Stores |
Stealer family and ATT&CK Software
When the log names its malware family, the finding carries the family's ATT&CK Software ID. Families with no ATT&CK entry are sent by name only; we do not invent IDs.
| Stealer family | ATT&CK Software |
|---|---|
| redline | S1240 RedLine Stealer |
| lumma | S1213 Lumma Stealer |
| raccoon | S1148 Raccoon Stealer |
| vidar | S9050 Vidar |
| strela | S1183 StrelaStealer |
| cuckoo | S1153 Cuckoo Stealer |
| azorult | S0344 Azorult |
| agent tesla | S0331 Agent Tesla |
| lokibot | S0447 Lokibot |
| xloader / formbook | S1207 XLoader |
| darkgate | S1111 DarkGate |
| StealC | name only |
| Rhadamanthys | name only |
| META | name only |
| RisePro | name only |
| Atomic (AMOS) | name only |
Where it fits ATT&CK's detection guidance
ATT&CK v20 detection strategy DET0460, Credential Stuffing Detection via Reused Breached Credentials Across Services, names a lookup against known leaked credentials as an optional enrichment in its analytics. DarkStrata supplies that enrichment: the leaked credentials and the accounts they belong to.
We tag the input to credential stuffing. Your SIEM detects the use.
MITRE D3FEND™ countermeasures
Findings point to these D3FEND countermeasures. D3FEND 1.6 has no leaked-credential artefact, so this mapping is our own analysis, not part of D3FEND.
| D3FEND tactic | Countermeasure | Why a finding points to it |
|---|---|---|
| Detect | D3-CCSA Credential Compromise Scope Analysis partial | Shows which accounts and services a leaked credential reaches. |
| Detect | D3-IAA Identifier Activity Analysis partial | Gives identity analytics the exposed identifiers to watch. |
| Evict | D3-CR Credential Revocation | A live exposed credential should be revoked. |
| Evict | D3-AL Account Locking | Lock the account while the exposure is investigated. |
| Evict | D3-ANCI Authentication Cache Invalidation | Clear cached authentication tied to the exposed credential. |
| Evict | D3-ST Session Termination | End sessions, especially when the log held browser cookies. |
| Harden | D3-PR Password Rotation | Rotate the exposed password and any reuses of it. |
| Harden | D3-SPP Strong Password Policy partial | Reused and breached passwords show where the policy is not holding. |
| Harden | D3-MFA Multi-factor Authentication | A second factor limits what an exposed password alone can do. |
| Restore | D3-RIC Reissue Credential | Issue a replacement credential to the account owner. |
In your SIEM
- CEF: technique IDs in
cs6, tactic IDs inflexString1, ATT&CK Software ID inflexString2, and a finding-class suffix on the signature ID. - LEEF:
mitreTechniques,mitreTacticsandmalwareFamily. - STIX and Splunk:
kill_chain_phasesandexternal_referenceson indicators, and amitre:label per technique on Splunk observed-data.
Full field reference on the SIEM integrations page
The same tags are on alert webhooks and in the MCP server's alert tools. See also infostealer monitoring and stolen data monitoring.
Frequently asked questions
Which ATT&CK version do you map to?
Enterprise ATT&CK v20. Every tag records the version it was made against, so older findings keep their original tags when we move to a new release.
What do observed and inferred mean?
Observed means the technique is evidenced in the artefact we hold, or there is no other technical way it could have happened. Inferred means a precondition or next step we did not see. Every tag carries one of the two.
Why is Valid Accounts (T1078) missing?
Because validity is not use. A Lens confirmation proves the password is the user's and still current, which is exactly why it is urgent, but it does not show an attacker logging in with it. Your identity provider sees that; we do not. Tagging T1078 would claim an intrusion we have no evidence of, so we never tag it.
Does this mean DarkStrata detects credential stuffing?
No. We tag the input to credential stuffing: the leaked credentials an attacker would use. Your SIEM or identity provider detects the login attempts, and our findings are the enrichment that makes that detection sharper.
Is this mapping evaluated or endorsed by MITRE?
No. It is our own mapping, made against the published ATT&CK and D3FEND content and following CISA's mapping guidance. MITRE has not evaluated or endorsed it.
How often is the mapping updated?
With each ATT&CK release, in April and October. We check every technique and software ID against the new release before moving to it.
MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. MITRE D3FEND is a trademark of The MITRE Corporation. DarkStrata is not affiliated with or endorsed by MITRE.