What is an example of ATT&CK Enterprise Data Source in practice?

What ATT&CK Enterprise Data Sources look like in day-to-day detection work

In practice, an ATT&CK Enterprise Data Source is the telemetry your detections can actually observe and reason over. MITRE ATT&CK Enterprise Matrix uses data sources to connect attacker behavior to the evidence defenders can collect, so the value is in whether the source can show a technique in motion, not just whether it exists in the environment.

Process command-line data is a good example because it captures the arguments used when a process starts. That makes it useful for spotting encoded commands, suspicious script runners, odd parent-child chains, or a legitimate binary being repurposed in an unusual way. On its own, the raw event is only a clue; its value rises when it is normalized and compared with endpoint, identity, and network telemetry.

Other common Enterprise Data Sources follow the same pattern: process creation events, Windows event logs, authentication logs, file activity, registry changes, network connections, DNS, and cloud audit records. Each one represents a different slice of system behavior, and the strongest detections usually correlate several slices instead of relying on a single noisy indicator.

Why command-line telemetry is so useful for ATT&CK mapping

Command-line data is especially valuable because many adversary techniques leave a semantic trail in the arguments, flags, and invoked utilities. A suspicious string can reveal a living-off-the-land binary, a hidden download-and-execute step, or an attempt to disable logging. That makes it a practical bridge between a technique in ATT&CK and a measurable event in an endpoint data pipeline.

The data source also helps with triage. Analysts can see whether a process launched from an expected parent, whether the invocation pattern matches normal administration, and whether the same command appeared across multiple hosts. This is why ATT&CK data sources are often more useful for detection engineering than for broad inventory alone.

For defenders, the real question is not whether command-line logging is enabled somewhere, but whether it is consistently collected, retained, and searchable where the technique matters. If the source is missing from a key endpoint class, the ATT&CK mapping may look complete on paper while the control is blind in practice.

How teams turn a data source into a usable detection signal

A data source becomes operational when it is paired with a concrete analytic question. For command-line telemetry, that usually means asking whether the arguments are normal for the parent process, whether the command implies a high-risk action, and whether the process appears in a sequence that fits an attack path. The same source can support both broad hunting and precise alerting if the field quality is good enough.

That is why ATT&CK mapping should be tied to the actual telemetry schema in use. A detection team needs to know whether the source includes full command lines, whether truncation is possible, whether scripts are decoded before storage, and whether event volume makes retention practical. If those details are not understood, the “data source” label can overstate real coverage.

In mature programs, the source is treated as one part of a detection chain, not as the detection itself. Command-line data is most effective when paired with process lineage, user context, and alert enrichment so analysts can decide whether the behavior is suspicious, expected administrative activity, or a benign automation pattern.

Practitioner Guidance

What to verify: Confirm that the data source is collected at the hosts that matter most, especially servers, admin workstations, and high-value endpoints. Check whether command-line fields are complete enough to distinguish a normal utility invocation from an abused one.

What good looks like: A usable ATT&CK data source should support both hunting and alerting, with enough context to explain why a process launch is unusual. If analysts still need several manual pivots to understand the command, the telemetry is probably too thin.

Common mistake: Treating ATT&CK coverage as a documentation exercise. A mapped source only matters if it is retained, queryable, and correlated with the other events needed to confirm or dismiss suspicious behavior.

Practitioner takeaway: The best ATT&CK data sources are the ones that let you prove or disprove a technique quickly, not the ones that simply sound comprehensive on a matrix.

Related resources from NHI Mgmt Group

• Guide: MITRE ATT&CK Guide for Defenders
• How does ATT&CK Enterprise data source work?
• ATT&CK Enterprise Data Source
• What is an example of Execution (MITRE ATT&CK Tactic) in practice?
• Why does linking threat intelligence to MITRE ATT&CK and live vulnerability data improve cloud defense decisions?