Windows Monitoring with Sysmon: Practical Guide and Configuration

One might think that, considering how effective some companies are at logging everything we do to serve us ads, they’d at least apply that to help us understand what’s happening on our systems and monitor their performance and security. But in the case of Windows, traditional logs fall short — and that’s where the importance of Sysmon comes in.
Sysmon is a Windows service that logs operating system activity into the event log. However, it’s not installed by default, so you’ll need to download it from here.
Once installed, Sysmon logs are significantly more advanced and comprehensive than the default Windows Event Log, which is critical for ensuring the security of your systems.
That’s why we’re taking a deep dive into Sysmon.

How to Install Sysmon

Sysmon isn’t installed like a common Windows program, and here are the steps to do it without running into weird errors:

• Run PowerShell as Administrator.
• Use the command line to navigate to the location where you retrieved the previously linked Sysmon file.
• Then run: .\Sysmon64.exe -i -accepteula
• You’ll see some installation messages, and just like that, Sysmon will be up and running.

Sysmon Log Location and Management

So, how can we view Sysmon logs? Microsoft enjoys hiding things from us, but it’s “easy”:

• Press the Windows key and search for Event Viewer, then open it.
• You’ll see several folders — go to: Applications and Services Logs.
• Open the Microsoft folder, then the Windows folder.
• In the central panel, scroll down until you find Sysmon, then click on it. You’ll see a log named Operational, which you may manage using the options on the right-hand side. Click to open it.
• Everything that’s happening is recorded there, and you can select events, copy them, save them, etc.

Why Sysmon Logs Are Essential for a SIEM

With Sysmon’s detailed logging, our SIEM— such as Pandora SIEM — can analyze and correlate those records, detecting and alerting the SOC about threats that would otherwise go unnoticed with basic logs..

For example, a process hollowing attack — where a malicious actor creates a “legitimate” process like svchost.exe, but injects it with malicious code — would likely slip past default event logs, assuming they haven’t been disabled altogether.
But thanks to Sysmon, our SIEM can detect and raise alerts for this and other techniques by analyzing its logs. That’s why in today’s security landscape, Sysmon is essential if you’re managing Windows systems and dealing with threats more advanced than a basic DDoS attack.

Events Logged by Sysmon

With Sysmon, we go from logging almost nothing to logging nearly everything. The service assigns an Event ID number to each type of activity it monitors, and these are the events it records:

• 1: Process creation.
• 2: A process changed the creation time of a file.
• 3: Network connection.
• 4: Sysmon service state changed.
• 5: Process terminated.
• 6: Driver loaded.
• 7: Image loaded.
• 8: CreateRemoteThread.
• 9: RawAccessRead.
• 10: ProcessAccess.
• 11: FileCreate.
• 12: RegistryEvent (object creation and deletion).
• 13: RegistryEvent (value sets).
• 14: RegistryEvent (key and value names).
• 15: FileCreateStreamHash.
• 16: ServiceConfigurationChange.
• 17: PipeEvent (pipe created).
• 18: PipeEvent (pipe connected).
• 19: WmiEvent (WmiEventFilter activity detected).
• 20: WmiEvent (WmiEventConsumer activity detected).
• 21: WmiEvent (WmiEventConsumerToFilter activity detected).
• 22: DNSEvent (DNS query).
• 23: FileDelete (archived file deletion).
• 24: ClipboardChange (new clipboard content).
• 25: ProcessTampering (image change in a process).
• 26: FileDeleteDetected (logged file deletion).
• 27: FileBlockExecutable.
• 28: FileBlockShredding.
• 29: FileExecutableDetected.
• 255: Error — reserved for when Sysmon fails to complete a task or encounters other issues.

As you can see, it logs everything from file creation and modification, to clipboard activity and network requests. With this granular logging, we can correlate events that may appear harmless on their own but together may be the signs of a sophisticated attack.

Sysmon Log Lifecycle

To manage logs efficiently, we need to define what happens at each stage of their lifecycle.
Sysmon begins recording events in real time based on the configuration defined in an XML file.
By default, it uses a generic configuration to start logging, but the real power—and what any SOC truly cares about—is customizing that XML to suit the organization’s needs security policies risk management approach, and infrastructure (such as the SIEM being used).
This allows us to configure Sysmon to ignore irrelevant “noise” and focus only on what matters.
Once event logging begins, entries are stored until the log reaches its maximum defined size, which can be adjusted through the Event Viewer.
To configure this, navigate again to Operational, right-click it, select Properties, and there you can define:

• Maximum log size.
• What happens when the limit is reached: Overwrite events starting with the oldest, archive the log so it won’t be overwritten, or choose not to overwrite at all (because you’ll manually clear the logs—something you probably promise to do and never will).

These logs reach their full potential when analyzed by a SIEM, Manually going through every Sysmon line for clues might build character—but also eye strain—and is much slower and more error-prone than letting a SIEM handle it, implying a high risk of overlooking issues such as malware.
For example, Pandora SIEM’s agent collects these logs and sends them to a centralized server for analysis and correlation alongside other logs—without burning through your eyelashes. This allows you to detect real-time threats that might be buried within endless log lines, and correlate them with other activity across the network, even from non-Windows machines.
Even better: if the Windows endpoint is compromised beyond recovery, you’ll still have a centralized copy of the log in your SIEM, which is vital for forensic analysis to understand what caused the catastrophic failure.
And what happens to the logs once they’ve been analyzed?
That depends on finding the right balance between smart archiving and deletion, and meeting both forensic investigation needs and regulatory compliance regarding long-term log retention.

How Eventlog Analyzer Processes Sysmon Logs

A Sysmon log captures a vast amount of information, but what we truly need is actionable insight for our defense strategies. To achieve this, various tools can leverage Sysmon logs to detect malicious patterns and alert us accordingly.
Eventlog Analyzer, a tool by ManageEngine, includes powerful log analysis capabilities—not just for Sysmon, but also for routers, IDS systems, and more.
It normalizes, correlates, and presents the most relevant data visually through dashboards and alerts.
This simplifies threat detection, forensic investigations during security breaches, and ensures compliance with regulatory requirements.

Monitoring Sysmon with Pandora FMS and Pandora SIEM

Pandora SIEM also enables centralized and advanced analysis of Sysmon logs (as well as logs from other areas of your IT infrastructure) via the Log Collector. It then transforms that information into actionable insights and quickly detects threats, It doesn’t matter if you’re running both Windows and Linux machines, and Sysmon data needs to work in harmony with Syslog or Auditd—everything gets integrated and analyzed together.
One of Pandora’s strongest features is its adaptability— you can fully tailor the tool to match your workflows, organization structure, and specific needs.
Similarly, Pandora dashboards can be configured to display exactly what matters to you—such as listing Sysmon events sorted by severity —and alert you only when needed, filtering out the noise.
It also provides advanced reporting and search capabilities, going far beyond the features offered by many other tools.
Pandora is a comprehensive solution—think of it as the Enterprise’s central computer—designed to monitor and manage diverse systems so they run in sync. Its SIEM is synonymous with top-tier security, but you can also incorporate remote monitoring, control, and ticketing into a single unified platform.
This prevents your stack from turning into a Frankenstein’s monster of stitched-together tools—something all too common in IT—which also brings the added headache of fragmented support, where each vendor blames “the other applications.”

How to Properly Configure Sysmon

With great power comes great responsibility… and complexity. That’s why anyone who needs to filter out “noise” and receive only critical information from Sysmon should use a custom XML configuration.
You can do this with the following command:

.\Sysmon64.exe -i -accepteula c:\micarpeta\mixmlpersonal.xml

But writing that XML from scratch can feel like one of Hercules’ labors—which is why Pandora provides a starter configuration file, which you can download here.
This file is based on best practices and specially adapted to help Pandora extract the key information necessary for effective protection. However, it should always be tailored to fit your environment.
The file comes well-commented (which makes working with it much easier) and includes some Pandora-specific rules, but you can and should customize it as needed.
Some key points in the XML you may want to adapt include:

• Critical processes (search for
• Ports commonly used by attackers (search for
• Registry modifications (search for
• Executables launched from suspicious locations, like /temp or the Recycle Bin.

Becoming familiar with the XML format, its structure, and the meaning of each field is one of the best skills you can develop for protecting Windows systems.
This way, you can ensure that Sysmon’s potential doesn’t go to waste, quietly collecting gigabytes of dusty virtual logs.
As we’ve seen, if you manage Windows endpoints, Sysmon is essential—because while Microsoft might know everything about us, the default event logs leave us knowing little about Windows itself. That’s why you need to start logging with Sysmon—but don’t stop there.
Its massive logging capabilities are also its biggest challenge, which is why the best approach is to customize its XML and integrate it with a SIEM. The SIEM can then do the heavy lifting of detecting threats hidden among the thousands of log lines