Sysmon Event ID 1 is logged when a new process is created, and it provides extended process details including the full command line and parent process command line. It requires Sysmon to be installed, the ProcessCreate filter tag to be enabled, and hashing configured through HashAlgorithms in the Sysmon configuration.
What Event ID 1 Tells You About the Host
sysmon event id 1 is the process creation event, so it answers a very specific forensic question: which executable started, from what path, with what command-line arguments, and under which parent process. That makes it one of the most useful Sysmon records for tracing execution chains, spotting script or LOLBin abuse, and correlating suspicious child processes back to the original launcher.
Because the event is tied to process creation, it is only useful when Sysmon is deployed and configured to collect it. In practice, the event becomes significantly more valuable when command-line logging and parent process details are enabled, since those fields often show the difference between ordinary administrative activity and an execution path that deserves investigation. Sysmon Guide is the best starting point for understanding how that telemetry fits into a broader detection strategy.
What Must Be Enabled for Event ID 1 to Appear
Event ID 1 does not appear because Windows is “doing process logging” in the abstract, it appears only when Sysmon is installed and the ProcessCreate rule is enabled in the Sysmon configuration. If hashing is configured through HashAlgorithms, Sysmon can also record hashes alongside the process event, which gives analysts a stronger pivot for hunting and enrichment.
The practical implication is that missing configuration can look like missing visibility. If ProcessCreate is not enabled, or if the deployment is partial, you may still have Sysmon installed but no process creation events in the log stream. For Windows logging context, Windows Event Log Guide helps distinguish Sysmon telemetry from native Windows audit events and shows where Event ID 1 fits among the broader logging stack.
When the event is present, the full command line and parent command line are often the most operationally important fields. They help answer whether the process was launched interactively, by a script host, by an office application, by a service, or by another binary that should not normally be spawning that child process.
How Analysts Should Use It in Detection and Triage
Event ID 1 is most useful when treated as a process lineage record rather than as a simple “program ran” alert. A single event can expose command-line switches, encoded payloads, unusual working directories, renamed binaries, and parent-child relationships that reveal process injection chains, script execution, or post-exploitation tooling.
It is also valuable for baseline comparison. Normal administrative tools often generate predictable parents, paths, and arguments, while suspicious activity tends to stand out through uncommon parent-child combinations, unexpected execution from user-writable locations, or command lines that include obfuscation, downloaders, or remote execution options. PowerShell Security Guide is especially relevant when Event ID 1 shows PowerShell spawning in ways that warrant deeper inspection.
Analysts should correlate Event ID 1 with adjacent telemetry rather than treating it as a standalone verdict. Process creation often becomes meaningful when combined with network events, module loads, script logging, authentication activity, or later persistence events, because the event explains how execution began but not always what the process did next.
Risk and Threat Considerations
Process creation telemetry is high value because it often captures the first observable step in malicious execution. Attackers rely on living-off-the-land binaries, script hosts, and chained parent processes to blend into routine administration, so incomplete process logging can leave a gap right where initial execution, staging, or privilege escalation begins.
Failure mechanism: If Event ID 1 is not enabled, or if command-line and parent-process data are missing, defenders lose a key pivot for reconstructing execution chains and can miss the handoff from a trusted parent to a malicious child process.
Impact: Investigation quality drops, alert triage slows, and it becomes harder to distinguish benign administration from hands-on-keyboard activity, script abuse, or the first stage of malware execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Process creation logs expose script-host and command-line abuse patterns. |
| Recommendation — Map suspicious child-process chains to ATT&CK and hunt for execution patterns. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Sysmon Event ID 1 is an audit source that must be collected and retained for investigation. |
| Recommendation — Collect, centralise, and retain Sysmon process-creation logs for detection and forensics. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Event ID 1 depends on generating process-creation audit records with useful detail. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Analysts must review process telemetry to detect suspicious execution chains. | |
| SI-4 — System Monitoring | Sysmon process events support continuous monitoring for malicious execution behavior. | |
| Recommendation — Configure audit generation so process creation records include command lines and parent context. Review process-creation records for anomalies in parent-child lineage and command lines. Use process-creation telemetry to detect suspicious execution and trigger response. | ||
Practitioner Guidance
What to verify: Confirm that the Sysmon configuration actually includes ProcessCreate and that hashing is enabled where your detection workflow depends on file or process pivots. A deployed Sysmon agent without the right rule set is a visibility problem, not a logging problem.
What good looks like: Event ID 1 records should consistently show the executable path, full command line, parent process, and hashes where configured, and those fields should be available in the SIEM soon enough to support triage before a process chain disappears from memory or rotates out of retention.
Practitioner takeaway: Treat Event ID 1 as the foundation for process lineage analysis, and judge the configuration by whether it gives you enough context to explain why a process started, not just whether the event exists.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org