A SOC is mapping ATT&CK T1059 command and scripting interpreter coverage across Windows hosts. Alerts can show file access, DNS queries, and interactive logons, but analysts cannot reconstruct what command a suspicious process ran. Which telemetry gap most directly blocks detection of this execution technique?
Select an answer to reveal the explanation.
Short Explanation
Think of process creation auditing as the camera that records who ran what command. Without it, you can see that a user logged in or a file changed, but you cannot prove the script interpreter actually executed the malicious line. That missing command-line view is the trap when you try to map T1059 coverage.
Full Explanation
Command-line execution techniques are detected by correlating the parent process, child process, and the arguments supplied to the interpreter. On Windows, this requires process-creation events with command-line auditing enabled, because the event shows the executable path, parent relationship, and the actual command string. Without that record, an analyst may see suspicious file activity or network calls but cannot establish that cmd.exe, powershell.exe, or another interpreter ran with malicious arguments. PowerShell module logging helps identify modules loaded by PowerShell, yet it does not reveal arbitrary command-line execution from other interpreters or native processes. DNS resolver query logging supports C2 or domain-generation detection, but it cannot prove local execution of a command. User logon event auditing confirms interactive or remote authentication, yet authentication is not execution and does not expose process arguments. Exam caveat: map the ATT&CK technique to the data element that proves the action, not merely to surrounding network or account activity. Operational check: enable Windows Security event ID 4688 with command-line inclusion in group policy, then validate that a test command appears in the SIEM with parent and child process fields.