Investigate a Process with Sysmon

Use Sysmon telemetry to trace a safe Windows process and write a SOC finding.

Introduction

30 Second Summary

A command can look suspicious when you see it without the story of how it started. That missing context can turn ordinary activity into a false alarm.

In this project, you will use built-in System Monitor (Sysmon) to investigate a safe process on Windows. You will turn its process evidence into a SOC-style verdict.

What You'll Build

Your finished investigation lets you open a saved report that ties a safe Windows PowerShell command to its Sysmon process-creation evidence.

By the end of this project, you'll have:

  • A parent-child process chain showing Command Prompt launching Windows PowerShell for a read-only Security log query.
  • A filtered event view that isolates Sysmon Event ID 1 from a busy Windows Event Viewer log.
  • An evidence-backed SOC finding that captures the UTC timestamp, full command line, parent process, hash, and Process GUID. Its verdict includes a detection hypothesis plus a false-positive note.
  • Secret Mission: Run the same child command under a different parent process. Compare both process chains to refine your detection hypothesis.

Are there any prerequisites?

You need a Windows 11 device with administrator privileges. You also need permission to enable an optional Windows feature.

Before We Start

Before the hands-on investigation begins, commit to examining a deliberately generated read-only PowerShell Security-log query. Your goal is to evaluate the parent process alongside the command-line context before deciding what the event means.

Enable Sysmon Telemetry

A process investigation needs endpoint telemetry before any event can become evidence. Built-in System Monitor (Sysmon) creates that evidence source on Windows 11.

This setup checks for an existing Sysmon service before changing the device. Built-in Sysmon cannot coexist with a standalone Sysmon installation.

In this step, get ready to:
  • Verify the built-in Windows investigation tools.
  • Check for an existing Sysmon service before enabling the optional feature.
  • Confirm that Sysmon telemetry is visible in Event Viewer.
Verify the Windows tools

Windows PowerShell handles the administrative setup. Command Prompt launches the safe child process in the next step.

Event Viewer displays the captured telemetry. Windows Notepad stores the evidence report later.

  • Use Start search to open Windows PowerShell.
  • Use Start search to open Command Prompt.
  • Use Start search to open Event Viewer.
  • Use Start search to open Windows Notepad.

Each tool should open to a usable window. This confirms that the built-in investigation toolkit is available.

Administrator access allows the next commands to change an optional Windows feature. Windows shows a permission prompt before granting that access.

  • Return to Start search.
  • Search for Windows PowerShell.
  • Right-click the Windows PowerShell result.
  • Select Run as administrator.
  • Approve the Windows permission prompt.
  • Keep the elevated Windows PowerShell session open for setup.
Check for an existing Sysmon service

The service check protects your device from a conflicting installation. A returned Sysmon service means an implementation is already present.

  • Inspect the existing Sysmon services by running this command in the elevated Windows PowerShell session:
Get-Service sysmon*

What does this check prove?

  • The Get-Service sysmon* command searches for services whose names begin with Sysmon.
  • A returned service means you should keep the existing implementation.
  • No returned service means the built-in optional feature still needs to be enabled.

✔️ A Sysmon service appears

The existing service confirms that Sysmon is already installed. Installing the optional feature again could create an unsupported conflict.

  • Keep the existing Sysmon implementation.
  • Confirm that its service reports that it is running.

ⓧ No Sysmon service appears

No returned service means you can enable built-in Sysmon. The installation command adds the Sysmon service and driver.

  • Enable the optional feature and install Sysmon by running these commands:
Enable-WindowsOptionalFeature -Online -FeatureName Sysmon
sysmon -i

What do these commands do?

  • The Enable-WindowsOptionalFeature -Online -FeatureName Sysmon command installs the built-in Windows optional feature.
  • The sysmon -i command installs the Sysmon service and driver with the default configuration.

Windows PowerShell should complete both commands without reporting a failed installation.

Installation did not complete?

  • Confirm that the current Windows PowerShell session was opened with Run as administrator.
  • Check that the original service query returned no existing Sysmon installation.

Ask for help with the installation output before trying another implementation: Help me troubleshoot built-in Sysmon setup.

Before you check again, what do you expect the service query to show?

  • Confirm that a Sysmon implementation is present by running the service check again:
Get-Service sysmon*

What does the second check confirm?

The second query verifies that Windows can find the existing or newly installed Sysmon service. Its reported status confirms whether the service is running.

You should see the existing Sysmon service or the newly installed Sysmon service. The service should report that it is running.

Service still missing or stopped?

  • Return to the outcome tab that matched your first service check.
  • Confirm that every command in that path completed.
  • Stop before enabling another implementation if an existing Sysmon service appears.

Get help interpreting your service output: Why is my Sysmon service missing or stopped?

Confirm telemetry in Event Viewer

Sysmon writes its records to a persistent Operational log. Visible records prove that the service and driver are collecting telemetry.

Before you select the log, do you expect it to be empty or already contain telemetry?

  • Switch back to Event Viewer from earlier.
  • Expand Applications and Services Logs in the left console tree.
  • Expand Microsoft.
  • Expand Windows.
  • Expand Sysmon.
  • Select Operational.

You'll see Sysmon event records listed in the center pane. Their presence confirms that built-in Sysmon is enabled with an active configuration.

Operational log looks empty?

  • Confirm that Operational is selected beneath Sysmon.
  • Return to the elevated Windows PowerShell session from earlier.
  • Repeat the service check from the previous substep.

Get help tracing the missing telemetry: Why is my Sysmon Operational log empty?

That's the setup locked in: Sysmon is now producing telemetry you can investigate.

Next, you will launch a safe process chain and see why an unfiltered event stream makes reliable triage difficult.

Generate a Safe Process Chain

Your Sysmon service is running. That is the evidence source ready: its Operational log is receiving endpoint telemetry.

A live Windows device mixes activity from many processes into one stream. You will create a known-safe process chain from Command Prompt to test whether one event stands out in that stream.

In this step, get ready to:
  • Prepare an elevated Command Prompt with an execution-time anchor.
  • Launch a read-only Windows PowerShell query from Command Prompt.
  • Assess the refreshed Sysmon Operational log for the new process record.
Open an elevated Command Prompt

An execution-time anchor gives you a reference point for the process activity you are about to generate. The Windows taskbar clock provides a quick anchor for this investigation.

  • Press the Windows key to open Windows Search.
  • Type Command Prompt into the search box.
  • Use the administrator launch option shown with the Command Prompt search result.
  • Approve the Windows permission request.
  • Confirm that the window title indicates administrator privileges.
  • Record the current time shown in the Windows taskbar as your execution time anchor.

Your elevated Command Prompt is ready. The recorded time gives your investigation a precise place to begin searching.

Run the read-only Security log query

Starting Windows PowerShell from Command Prompt creates a parent-child process relationship that Sysmon can record. The child process reads the local Security event log without changing it.

Before you run this, make a quick mental prediction about what Command Prompt will show.

  • Generate the safe process chain by running this command in the elevated Command Prompt:
PowerShell -Command "Get-EventLog -LogName Security"

What Does This Command Do?

  • The PowerShell executable starts a Windows PowerShell child process from Command Prompt.
  • The -Command option executes the following string as PowerShell code.
  • The Get-EventLog -LogName Security query reads records from the local Security event log.
  • Wait for Security log entries to populate the Command Prompt window.
  • Inspect the output for multiple Security log records.

You should see Security log records in the console. That is your safe signal created: a Command Prompt parent launched a Windows PowerShell child that read the Security log.

Do Not See Security Log Records?

  • Confirm that you ran the query in the elevated Command Prompt from this substep.
  • Check that the command matches the code block exactly.
  • Run the command again after confirming that the Command Prompt window has administrator privileges.

Need help with the query?

Test visual triage in the unfiltered log

The new process telemetry now sits inside the Windows Event Viewer session from earlier. This is your chance to test whether an unfiltered event stream gives you enough context for reliable triage.

Before you refresh, make a quick mental prediction about whether the exact Windows PowerShell event will stand out.

  • Switch back to the Event Viewer session from earlier.
  • Refresh the Sysmon Operational log using the control in the right-side Actions pane.
  • Try to locate the matching event near your execution time anchor by visually scanning the unfiltered records.

You will see many mixed Sysmon records. The matching process-creation record does not stand out clearly in the unfiltered stream.

This shortfall is intentional. The stream proves telemetry is flowing while showing why visual scanning alone is unreliable for triage.

Do Not See Fresh Sysmon Activity?

  • Confirm that the Sysmon Operational log from the previous step is still selected.
  • Check that the Security log query ran after the time you recorded.
  • Refresh the selected log once more.

Need help finding the new activity?

You have generated a known-safe process chain and watched it disappear into a busy telemetry stream. Next, you will narrow the evidence and reconstruct the parent-child relationship.

Filter and Reconstruct the Chain

The process you generated is buried in mixed Sysmon records inside Event Viewer. The execution-time anchor from the previous step gives you a starting point.

Event ID filtering narrows the log to Process Create records. Those records expose the parent-child process relationship needed to reconstruct what ran.

In this step, get ready to:
  • Filter the Sysmon Operational log to Event ID 1 Process Create records.
  • Locate the known PowerShell event using its time anchor plus exact command line.
  • Record the event fields needed to reconstruct the process chain.
Filter to Process Create events

Sysmon Event ID 1 records process creation. Filtering the existing log to that event type removes unrelated telemetry from your current view.

  • Switch back to the Sysmon Operational log in Event Viewer from earlier.
  • In the Actions pane, click Filter current log.
  • Enter 1 in the field for event IDs.
  • Use the filter window's confirmation control to apply the filter.

You'll now see only Event ID 1 Process Create records in the log.

Good progress. The mixed stream is now a focused list of process activity.

What Does Event ID 1 Capture?

Each Process Create record includes the full command line. It also identifies the parent process.

The record contains a cryptographic hash. A globally unique Process GUID helps identify the process across events.

No Process Create Events?

  • Confirm that you entered only 1 in the field for event IDs.
  • Confirm that you applied the filter to the Sysmon Operational log from earlier.

Need help with the filter?

Locate the PowerShell event

The time anchor narrows the search window. The command line acts as a fingerprint for the exact execution you generated.

  • Use this exact command line as the matching fingerprint:
PowerShell -Command "Get-EventLog -LogName Security"

What Does This Command Show?

  • The -Command parameter tells PowerShell to execute the following string.
  • The Get-EventLog -LogName Security query reads records from the local Security log.
  • The query is read-only in this investigation.
  • Start with Event ID 1 records closest to the execution-time anchor from earlier.
  • Open a nearby PowerShell record.
  • Compare its full command line with the fingerprint above.
  • Continue through nearby records until the full command line matches exactly.
  • Confirm that the record identifies Command Prompt as its parent context.

You found the right event. Its process chain connects Command Prompt to the known PowerShell child.

Can't Find the Matching Event?

  • Return to the execution-time anchor from the previous step.
  • Inspect the nearest PowerShell records one at a time.
  • Keep searching if the command line matches but the parent context does not.

Help me locate the event.

Record the evidence fields

A defensible investigation preserves observed values before interpretation. Sysmon records event timestamps in UTC.

  • Label your evidence as Sysmon Event ID 1.
  • Record the event's UTC timestamp here: your observed UTC timestamp.
  • Record the full command line here: the observed full command line.
  • Record the parent process here: your observed parent process.
  • Record the cryptographic hash here: your observed cryptographic hash.
  • Record the Process GUID here: your observed Process GUID.

Before you compare your notes with the event, which field do you expect to prove the launch relationship most directly?

  • Compare each recorded value against the open Event ID 1 record.
  • Confirm that the full command line matches the fingerprint exactly.
  • Confirm that the parent process identifies Command Prompt.

You'll see the same full command line under Event ID 1 with Command Prompt as its parent context. Your notes will also contain the UTC timestamp, cryptographic hash, plus Process GUID.

Your process chain is now backed by timestamped evidence. Next, you'll turn those facts into a concise SOC finding.

Write the SOC Finding

Your filtered Sysmon Event ID 1 record shows what ran. Its parent process shows how execution started.

A SOC finding turns endpoint telemetry into an evidence-backed decision. You will use Windows Notepad to preserve that reasoning in a report.

The report will label this known-safe query as benign. Your detection hypothesis will keep the false-positive context visible.

In this step, get ready to:
  • Create a structured investigation report in Windows Notepad.
  • Reconstruct the recorded process chain from its evidence.
  • Write a benign verdict with a context-dependent detection hypothesis.
Create the report structure

An investigation report separates raw evidence from interpretation. Consistent section headings make your reasoning easy to audit.

  • Switch back to Windows Notepad from earlier.
  • Create a blank document in Windows Notepad.

You should see an empty editing area ready for your report.

  • Enter Summary, Evidence, Process Chain, Analysis, Verdict, Detection Hypothesis, and False Positives as separate section headings.
  • Save the document to your Desktop as sysmon-process-investigation.txt.

You should see sysmon-process-investigation.txt in the Notepad title bar. Good start. Your report now has a clear structure for separating evidence from judgment.

Can't Find the Saved Report?

  • Check that the file name is exactly sysmon-process-investigation.txt.
  • Check your Desktop for the saved text file.

Get help finding or saving the report.

Document the event evidence

Evidence records what you observed before analysis begins. The values from Event ID 1 tie your report to a specific process creation.

  • Place your cursor below the Evidence heading in Notepad.
  • Populate the section with Event ID 1, your recorded UTC timestamp, the full command line PowerShell -Command "Get-EventLog -LogName Security", the Command Prompt parent process, the cryptographic hash, and the Process GUID.
  • Switch back to the filtered Event Viewer log from earlier.
  • Compare the six report entries with the matching Process Create record.

You should see the same values in the report and the matching event. This gives every later conclusion a traceable source.

Why These Fields Matter

  • The UTC timestamp anchors the process in your investigation timeline.
  • The full command line records the exact action performed.
  • The parent process records the launch context.
  • The cryptographic hash supports comparisons of the executable.
  • The Process GUID distinguishes this process instance from other executions.
Explain the verdict and hypothesis

Interpretation explains what the evidence means in this investigation. It also keeps a reusable triage lead separate from proof of malicious intent.

  • Under Summary, describe the intentionally generated Security-log query in one sentence.
  • Under Process Chain, state that Command Prompt launched PowerShell to query the Security log.

Your report now identifies the observed behavior. It also explains how the child process began.

  • Under Analysis, explain that you generated the query intentionally as a read-only action.
  • Under Verdict, identify the activity as benign in this investigation.

The analysis now connects intent to the evidence. The verdict records your incident-specific conclusion.

  • Under Detection Hypothesis, prioritize Sysmon Event ID 1 records where Command Prompt launches PowerShell to inspect the Security log.
  • Under False Positives, explain that this pattern requires surrounding context because it does not prove malicious intent by itself.

Why the Verdict Stays Benign

Sysmon records behavior. No single event proves intent.

You deliberately generated this read-only query during the investigation. The detection hypothesis remains useful as a triage lead when future events appear in a different context.

  • Save sysmon-process-investigation.txt.
  • Close the saved report in Windows Notepad.

Before the final check, predict whether every conclusion traces back to one of your recorded evidence fields.

  • Reopen sysmon-process-investigation.txt by double-clicking it on your Desktop.

What Should You See?

The saved report contains Summary, Evidence, Process Chain, Analysis, Verdict, Detection Hypothesis, and False Positives sections.

The evidence includes Event ID 1, your UTC timestamp, the full command line PowerShell -Command "Get-EventLog -LogName Security", the Command Prompt parent process, the cryptographic hash, and the Process GUID.

The verdict identifies the intentionally generated read-only query as benign. The hypothesis prioritizes the process pattern while the false-positive note preserves the need for context.

That's the investigation complete. You have turned one raw process event into a saved SOC finding with evidence that supports its verdict.

Secret mission

Change the Parent Process

Repeat the same known-safe PowerShell child command from a different parent. Compare the new Sysmon Event ID 1 record with the original event. Then refine your report so the hypothesis uses parent-process context.

Clean Up Your Resources

Clean Up Your Resources

Everything from this investigation stays on your Windows 11 device. There are no paid services or ongoing charges.

Choose whether to keep your resources running, pause the lab for later, or delete the evidence entirely. Sysmon continues collecting events across reboots while it remains installed.

Resources you used:

  • The installed Sysmon service and driver collecting endpoint telemetry.
  • The persistent Sysmon Operational event log in Event Viewer at Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.
  • The sysmon-process-investigation.txt report saved with Windows Notepad.

Keep everything running

Keeping the lab available requires no cleanup action. Choose this option if you want to continue investigating new process events.

  • Leave Sysmon installed so it continues collecting endpoint telemetry.
  • Keep the existing Sysmon Operational event log for future investigations.
  • Keep sysmon-process-investigation.txt as your completed evidence report.

Pause - I'll come back to this later

Stopping collection now lets you return later with your report still available. You can reinstall Sysmon when you are ready to continue.

  • Return to an administrator Windows PowerShell window from earlier.
  • Pause Sysmon telemetry by running this command:
sysmon -u

What does this command do?

The sysmon -u command removes the Sysmon service and driver. Your saved investigation report remains on your device.

  • Confirm that the Sysmon service is gone by running this check:
Get-Service sysmon*

What does this check do?

The command looks for installed services whose names begin with Sysmon. An empty result confirms that the service is no longer installed.

You should see no Sysmon service in the returned results.

Did Sysmon stay installed?

Confirm that your Windows PowerShell window has administrator privileges. Run the uninstall command again after returning to an elevated window.

Help me troubleshoot why the Sysmon uninstall command did not complete.

  • Resume Sysmon collection later by running this command in an administrator Windows PowerShell window:
sysmon -i

What does this command do?

The sysmon -i command installs Sysmon with its default configuration. The service begins collecting endpoint telemetry again.

  • Return to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational in Event Viewer.
  • Confirm that new Sysmon events are arriving in the Operational log.

No New Events Arriving?

Confirm that the install command completed in an administrator Windows PowerShell window. Refresh the Sysmon Operational log after the service starts.

Help me troubleshoot why new Sysmon events are not appearing.

Delete - I don't want to use this again

Deletion permanently removes the local report and the collected lab records. Your other Windows files remain untouched.

  • Return to an administrator Windows PowerShell window from earlier.
  • Remove the Sysmon service and driver by running this command:
sysmon -u

What does this command do?

The sysmon -u command uninstalls the Sysmon service and driver. This stops future Sysmon event collection.

  • Verify that the Sysmon service was removed by running this check:
Get-Service sysmon*

What does this check do?

This check searches for any remaining Sysmon service. An empty result confirms that the service and driver are no longer active.

You should see no Sysmon service in the returned results.

Does the Service Still Appear?

Confirm that only one Sysmon implementation is present. Run the uninstall command again from an administrator Windows PowerShell window.

Help me remove the remaining Sysmon service safely.

  • Return to the Sysmon Operational log in Event Viewer.
  • Use the log-clearing control in the Actions pane to remove the existing records.
  • Review any save prompt before continuing.
  • Choose the clearing option after confirming that you do not need another copy of the records.

You should see an empty Sysmon Operational view. This confirms that the collected lab events are gone.

  • Press the Windows key to open Windows search.
  • Search for sysmon-process-investigation.txt.
  • Use the matching result to open the folder containing the report.
  • Delete sysmon-process-investigation.txt from that folder.
  • Search for sysmon-process-investigation.txt again.

You should see no matching file. The Sysmon service, collected lab events, and saved report are now removed.

Nice Work!

Nice Work!

You did it! You turned raw endpoint telemetry from Sysmon into a defensible SOC finding that uses process context to support its verdict.

You've learned how to:

  • Capture a safe Command Prompt to PowerShell parent-child process chain in the Sysmon Operational log.
  • Isolate the matching Event ID 1 record in Windows Event Viewer. Reconstruct its process context from the UTC timestamp, full command line, parent process, cryptographic hash, and Process GUID.
  • Write a SOC-style investigation report in sysmon-process-investigation.txt that separates evidence from verdict. Frame a reusable detection hypothesis with a false-positive caveat.
  • Secret Mission: Compare the same child command under Command Prompt and Windows PowerShell parents. Refine the detection hypothesis to require parent-process context.

Ready to quiz yourself?