What does a Sysmon Event ID 1 record contain that Windows Security 4688 does not by default?
answer
- one is native, one is deployed
- hashes and a stable process identifier
- 4688's command line is a policy switch
- PID reuse versus ProcessGuid
- creation is not behaviour
basics
~20 sSysmon Event ID 1 adds file hashes, a unique ProcessGuid, and the parent's image path and command line. Windows Security 4688 also records process creation, but carries no hashes and includes the command line only when audit policy enables it.
solid answer
~50 sBoth are process-creation records, but they are not the same evidence. Windows Security **4688** is native: it needs the Audit Process Creation subcategory switched on, names the new process and its creator, and carries token elevation type. Critically, it holds no file hash, and it shows the command line **only** if the "Include command line in process creation events" policy is enabled — otherwise you get a path with no arguments. **Sysmon Event ID 1**, from a deployed agent writing to `Microsoft-Windows-Sysmon/Operational`, always carries the command line, MD5/SHA-256 hashes, `OriginalFileName`, integrity level, the parent image and parent command line, and a `ProcessGuid` that stays unique across PID reuse and reboots. Neither proves anything about behaviour: a process-creation record proves the OS created a process with those attributes, not that the code succeeded, did harm, or that a human was present.
go deeper
Be ready to name both records and one concrete field each has that the other lacks: hashes and a stable ProcessGuid on the Sysmon side, native availability and token elevation type on the 4688 side.
Explain the mechanics behind the gaps: 4688 needs the Audit Process Creation subcategory on, and its command line needs a separate policy setting; Sysmon's config file decides which events are recorded at all.
Show the investigative consequence. Say what question you cannot answer when the command line is absent, and how you check whether a host's telemetry is actually arriving before drawing conclusions from silence.
Own the estate-wide call: which execution telemetry you standardise on, what the extra fields cost on the wire, and the risk that command lines carrying secrets end up in a broadly readable log.
## Two records for the same moment When a program starts on Windows, two independent things can write it down. One is the operating system's own audit trail; the other is an agent you chose to deploy. Knowing which fields each carries — and which fields exist only if somebody turned them on — is the difference between answering an investigative question and guessing. ### Windows Security 4688 Event ID **4688** ("A new process has been created") lands in the **Security** log. It is not on out of the box: the *Audit Process Creation* subcategory has to be enabled for success. A 4688 record gives you: - the new process's image path and process ID; - the creating (parent) process ID, and on current Windows versions the creator's image name as well — older builds gave only the creator PID; - the subject: the account and logon ID under which the creation happened; - **Token Elevation Type**, which tells you whether the process ran with a full, limited or default token. What it does **not** give you: any hash of the executable, and — by default — the **command line**. The arguments only appear if the policy setting *"Include command line in process creation events"* (Computer Configuration > Administrative Templates > System > Audit Process Creation) has been enabled. Without it, `powershell.exe` looks identical whether it printed the date or ran an encoded payload. This single switch is the most common reason an investigation into a Windows host stalls. ### Sysmon Event ID 1 **Sysmon** is a separately deployed Sysinternals driver and service; it is not shipped enabled on Windows. Its **Event ID 1** is process creation, written to `Microsoft-Windows-Sysmon/Operational`, and a record typically carries: - `Image` and `CommandLine` — always, no extra policy needed; - `Hashes` — MD5, SHA-256 or IMPHASH of the image, as configured; - `OriginalFileName` — the name the binary was compiled with, which is how you notice a renamed copy of a signed tool; - `ProcessGuid` and `ParentProcessGuid` — identifiers that stay unique even after PID reuse or a reboot, so you can join a child to the exact parent instance; - `ParentImage` and `ParentCommandLine`; - `User`, `LogonId`, `IntegrityLevel`, `CurrentDirectory`, `TerminalSessionId`. Sysmon is also configuration-driven: its config file decides which events are recorded and which are filtered out, so "Sysmon is installed" and "Sysmon recorded this" are two different claims. And because it is an agent, it can be stopped, uninstalled or blinded — while 4688 is written by the OS itself and travels with the Security log. ### On Linux, the equivalent question The Linux counterpart is the kernel audit subsystem: an explicit rule on the `execve` syscall produces a `SYSCALL` record plus an `EXECVE` record holding the arguments split as `a0`, `a1`, `a2`, and so on, rather than one rendered command string. There is no execution auditing at all until the rule exists. ### What a process-creation record proves — and does not This is the part interviewers actually press on. A process-creation record proves that **the operating system created a process with these attributes at this time**. It does not prove: - that the program ran to completion, or did anything at all — it may have failed a line later; - that anything malicious happened — the record is neutral evidence, and most of them are your own software; - that a person did it — a service, a scheduled task or a management agent produces identical records; - what the process then touched. Files, registry keys and network connections are separate record types entirely. The hash is the most portable field: it identifies the bytes on disk that were executed, which lets you ask the same question of every other host, or compare against intelligence. It still says nothing about intent — plenty of signed, hashed, perfectly legitimate binaries are used to do harm. ### Practical consequence If you can have both, keep both. Sysmon gives you the richer record; 4688 gives you coverage on hosts Sysmon has not reached and survives the agent being tampered with. And if you can only fix one thing today on a Windows estate, it is usually the 4688 command-line policy setting, because without arguments the record names a program and tells you nothing about what it was asked to do.
- If Sysmon is deployed, why keep Windows 4688 at all?Coverage and resilience. Sysmon is an agent: it can be uninstalled, stopped, or configured to filter the very events you need, and rollout is never complete. 4688 is written by the OS itself, exists on every host with the audit subcategory on, and carries token elevation type. When the two disagree, that disagreement is itself a finding.
- What does the Hashes field in a Sysmon Event ID 1 record let you conclude?That those exact bytes were loaded as the process image. It is the most portable pivot you have: search the estate for the same hash, or compare it against intelligence. It says nothing about intent — a signed, well-known binary has a well-known hash and is still abusable. The interesting case is a familiar filename whose hash is unfamiliar.
- Does a process-creation record tell you the program did anything?No. It proves the OS created a process with those attributes. The program may have exited immediately, failed on its first line, or done nothing observable. Whether it touched files, the registry or the network is carried by entirely different record types, and you need those before claiming impact.
saying these in an interview costs you the question
- Claims Windows 4688 always includes the command line
- Thinks Sysmon ships enabled on Windows by default
- Treats a process-creation record as proof the program did harm
- Confuses Sysmon Event ID 1 with Windows Security event 1
- Assumes Sysmon records everything regardless of its config file