Detecting malicious activity using Sysmon and Windows Event Logs

Windows endpoints still generate some of the most useful telemetry available to defenders, but only if the right events are enabled, collected, and reviewed in a structured way. For UK SMEs, the challenge is rarely a lack of data. It is usually too much low-value data, inconsistent logging across devices, and no clear method for turning events into detections.

That is where Sysmon and native Windows Event Logs complement each other. Sysmon gives richer endpoint telemetry for process, network, registry, and file activity. Windows Event Logs provide the operating system and security context around authentication, account changes, services, scheduled tasks, and directory activity. Used together, they give you enough visibility to spot suspicious behaviour without needing enterprise-scale tooling from day one.

This article focuses on practical detection work. It is written for security engineers, analysts, and IT administrators who want to improve coverage, reduce blind spots, and investigate alerts more effectively. If you are still deciding what to log in the first place, it may help to review our article on what security logs you actually need and why before going deeper into endpoint telemetry.

Why Sysmon and Windows Event Logs work well together

Sysmon is an additional Windows service that writes detailed telemetry into the Windows eventing framework. It is not a replacement for native logs. Instead, it adds higher-fidelity data that is often missing from standard auditing. In practice, that means you can see which process started, what command line it used, what network connection it opened, and whether it created or modified files or registry values.

Native Windows Event Logs still matter because they provide the security and identity context around that activity. A suspicious PowerShell process is more useful when you can also see which account logged on, whether the account was elevated, whether a service was created, or whether a scheduled task was registered at the same time. That correlation is what turns raw telemetry into a defensible investigation.

The main operational benefit is coverage. Sysmon is strong on endpoint behaviour, while Windows logs are strong on operating system and identity events. If you rely on only one source, you will miss part of the picture. If you collect both, you can often confirm suspicious activity from two independent sources before escalating.

What each telemetry source is best at

Sysmon is best for process lineage, command-line detail, network connections, image loads, and registry changes. It is particularly useful when you need to understand how a tool was launched and what it touched afterwards. That makes it valuable for hunting living-off-the-land activity, persistence, and post-exploitation behaviour.

Windows Event Logs are best for authentication, privilege use, account management, service creation, scheduled tasks, and policy changes. They are also the source of many audit events that matter during incident response, especially on domain-joined systems and domain controllers.

Where the gaps are if you rely on only one

If you only use Sysmon, you may have excellent process telemetry but weak identity context. You might see a suspicious binary, but not know whether the account was newly created, whether a group membership changed, or whether the activity was tied to a remote logon.

If you only use native Windows logs, you may know that something happened, but not how it happened. A logon event alone does not tell you which parent process launched the activity, what command line was used, or whether a script dropped a file and then executed it. That is why a combined approach is usually more effective in a SIEM or XDR workflow.

What to log first for useful detection coverage

For small teams, the priority should be to enable telemetry that supports common detection use cases rather than trying to capture everything. Start with the events that help you answer four questions: what executed, what connected, what changed, and who did it.

Core Windows event channels to enable and retain

At minimum, make sure you are collecting the Security log from endpoints and servers, plus relevant System and Application events where needed. On domain controllers, the Security log becomes especially important because it records authentication, account management, and directory-related activity.

Useful native events often include logon and logoff activity, special privilege use, service creation, scheduled task creation, account changes, and group membership changes. If you are already using Windows Advanced Audit Policy, check that it is consistently applied through Group Policy and that audit settings are not drifting between hosts.

For investigation quality, retention matters as much as collection. If logs are overwritten before an analyst can review them, the telemetry is not operationally useful. Our article on retaining evidence and logs for investigations covers the evidence side of that problem in more detail.

Sysmon events that usually give the highest value

For Sysmon, the highest-value events for most environments are process creation, network connections, file creation, registry changes, image loads, and DNS queries. These are the events that most often support practical detections for suspicious execution, persistence, and lateral movement.

If you are tuning Sysmon for the first time, avoid enabling every possible event without a plan. High-volume telemetry can overwhelm a small team and make the useful events harder to find. A focused configuration is usually better than a broad one. If you want a deeper implementation view, our guide to tuning Sysmon configuration for high-fidelity process telemetry is a useful companion piece.

How to interpret the event data without drowning in noise

The value of endpoint telemetry depends on whether you can interpret it quickly. A single event rarely proves malicious activity on its own. The goal is to understand the sequence of events and compare it with what is normal for that host, user, and time of day.

Key fields to review in process, network, and authentication events

In process events, focus on the image name, parent image, command line, user, integrity level, hash values, and process ID. Parent-child relationships are often more informative than the executable name alone. For example, a legitimate system binary launched by an unusual parent process can be more interesting than a clearly suspicious filename.

In network events, look at destination IP, destination port, protocol, process image, and whether the connection is outbound to an unusual host or service. A process that should not normally make network connections, such as a document viewer or a scripting host, deserves closer inspection.

In authentication events, review the account name, logon type, source workstation, source IP, and whether the logon was interactive, remote, or service-based. The logon type is often the difference between a routine admin action and a suspicious remote session.

How to separate normal administrative activity from suspicious behaviour

Context is everything. A scheduled task created by a known management tool during a maintenance window may be normal. The same event from an unusual host, under a rarely used account, outside business hours, may warrant investigation.

Build baselines for your own environment. That does not mean you need a full behavioural analytics platform. It means you should know which admin tools are commonly used, which servers generate service changes, which accounts perform remote administration, and what normal PowerShell or WMI usage looks like. Without that baseline, almost any event can look suspicious.

High-value Sysmon event IDs for defenders

Sysmon event IDs are widely used in detection engineering because they map well to attacker behaviour. You do not need every event ID to get value, but a handful are especially useful.

Process creation, network connections, and file creation

Event ID 1, process creation, is usually the starting point for most hunts. It gives you the executable path, command line, parent process, user, and hashes. This is the event most analysts use to identify suspicious execution chains and unusual command-line arguments.

Event ID 3, network connection, helps you identify which process opened a connection and where it went. This is useful for spotting unexpected outbound traffic from administrative tools, scripting hosts, or binaries that should not normally talk to the internet.

Event ID 11, file creation, can show dropped payloads, staging activity, or files written into unusual locations such as user profile directories, temp paths, or startup-related folders. When combined with process creation, it helps you reconstruct what happened before and after the file was written.

Registry, driver, image load, and DNS events

Event ID 12, 13, and 14 cover registry object creation, registry value set, and registry key or value rename. These are useful for persistence and configuration tampering, especially where malware modifies autorun locations or policy-related keys.

Event ID 6, driver loaded, can be important on servers and privileged systems where kernel-level activity is relevant. Event ID 7, image loaded, can help identify suspicious DLL loading patterns, although it can be noisy if not filtered carefully.

Event ID 22, DNS query, is often overlooked but very useful. It can reveal suspicious domain lookups from processes that should not be making them, and it can support correlation with network events when investigating command-and-control style behaviour.

High-value Windows Event Log IDs for defenders

Native Windows logs are still essential for identity and system activity. The exact event IDs you prioritise will depend on your environment, but several are commonly useful for detection and investigation.

Logon, privilege, service, and scheduled task events

Event ID 4624 records successful logons. It is one of the most useful events in the Security log because it gives you the account, logon type, source, and session context. Event ID 4625 records failed logons and is useful for spotting password spraying, brute force attempts, or misconfigured services.

Event ID 4672 indicates special privileges assigned to a new logon. It is often associated with administrative activity, so it is worth correlating with the account, source host, and time of use.

Event ID 4697 and 7045 are both commonly used for service creation, depending on the logging path and platform. Service creation is a useful persistence and execution indicator, especially when the service name or binary path is unusual.

Event ID 4698 records scheduled task creation. This is a common persistence mechanism and should be reviewed alongside process creation and account activity. If you want a deeper view of task-based persistence, our article on scheduled task persistence shows how to turn that telemetry into hunts.

Directory and account management events that often matter in investigations

On domain controllers and privileged systems, account and group management events are critical. Event ID 4720 records user account creation, 4722 account enablement, 4723 password change attempts, 4724 password reset attempts, and 4728 group membership changes. These events help you spot privilege escalation, unauthorised account creation, and changes to administrative access.

Event ID 4732 and 4733 record local group membership changes, while 4737 records a security-enabled global group change. Event ID 4737 is often relevant when you are checking whether a privileged group was modified. In practice, it means a security-enabled global group was changed, which can include changes to the group’s attributes or membership-related state depending on the context and environment.

Event ID 4740 records account lockouts, which can be useful when investigating password attacks or misused credentials. Event ID 4768, 4769, and 4771 are Kerberos authentication events that often matter in Active Directory investigations, especially when you are correlating suspicious logons with ticket activity.

Common malicious patterns to hunt for

Most malicious activity on Windows leaves a pattern, even if the individual events look ordinary. The trick is to look for combinations rather than isolated records.

Suspicious parent-child process chains and LOLBin abuse

One of the most common patterns is an unusual parent-child process chain. For example, a scripting host launching a system utility, a document viewer spawning a shell, or a service host starting an interactive tool can all be worth reviewing. These patterns are especially useful when hunting living-off-the-land binaries, which we cover in more detail in our Sysmon process events guide.

Look for command lines that include encoded content, suspicious download behaviour, or execution from user-writable directories. Also pay attention to binaries launched from temporary folders, downloads locations, or paths that resemble legitimate system locations but are not the real Windows directory.

Persistence, privilege escalation, and lateral movement indicators

Persistence often shows up as a new service, scheduled task, registry autorun entry, or startup folder change. Privilege escalation may appear as a new privileged logon, a group membership change, or a process running with elevated integrity after a low-privilege start.

Lateral movement indicators often include remote logons, service creation on another host, administrative shares, and repeated authentication attempts across multiple systems. If you are investigating credential abuse more broadly, our article on credential theft and misuse patterns is a useful adjacent reference.

How to investigate Windows event logs during an alert

When an alert fires, do not start by asking whether the event is malicious in isolation. Start by building a timeline. The timeline should include the host, user, process tree, logon context, and any related network or directory activity.

Build a timeline from host, identity, and process activity

Begin with the alerting event and work backwards and forwards by a sensible time window. Identify the parent process, the account in use, the source host, and any immediately related events such as logon, service creation, or file writes. Then check whether the same account or host generated other unusual events in the same period.

If you have a SIEM, use it to pivot across event sources. A process creation event in Sysmon can be matched to a 4624 logon event, a 4698 scheduled task event, and a 4625 failure pattern if the attacker is testing credentials. That cross-correlation is often what turns a weak signal into a strong case.

Correlate one event source against another before escalating

Before escalating, confirm whether the activity is consistent with the user’s role and the host’s function. A domain administrator on a jump host will generate different telemetry from a finance user on a laptop. Correlation reduces false positives and helps you avoid wasting time on expected admin activity.

For teams using Microsoft Sentinel or a similar platform, KQL can be used to join Sysmon and Security events by host, account, and time. If you are building that capability, our article on KQL threat hunting with Microsoft Sentinel is a practical next step.

Sysmon versus native Windows logs: when each one matters most

There is no universal winner between Sysmon and native Windows logs. The right answer depends on the question you are trying to answer and the operational cost you can support.

Detection fidelity and operational trade-offs

Sysmon generally gives higher fidelity for endpoint behaviour, especially around process trees, command lines, and network activity. That makes it excellent for detection engineering and threat hunting. The trade-off is that it needs configuration, testing, and tuning to avoid excessive noise.

Native Windows logs are easier to enable and already present on the system, but they are less detailed in some areas. They are still indispensable for identity and administrative activity, and they often provide the context needed to interpret Sysmon events correctly.

How to use both sources in a SIEM or XDR workflow

In a SIEM or XDR workflow, use Sysmon as the behavioural layer and Windows Event Logs as the identity and control layer. Alert on suspicious process behaviour, then enrich it with logon, service, task, and account events. That layered approach gives you better precision than either source alone.

For many UK SMEs, the practical target is not perfect coverage. It is enough visibility to detect the most likely attack paths, enough retention to investigate them, and enough tuning to keep the alert queue manageable.

Practical tuning tips for small security teams

Small teams need detections that are maintainable. If a rule generates too many false positives, it will be ignored. If logs are too sparse, the rule will never fire with confidence. The balance matters.

Reducing false positives without losing coverage

Start by excluding known-good administrative tools, service accounts, and management hosts only after you have observed their normal behaviour. Avoid broad exclusions that hide entire classes of activity. It is better to suppress a specific known pattern than to remove visibility from a whole event type.

Use allowlists sparingly and review them regularly. A common mistake is to allowlist a tool because it is noisy, then forget that the same tool can be abused by an attacker. Where possible, tune on context such as host role, user group, or time window rather than on the executable name alone.

Retention, centralisation, and baseline considerations

Centralise logs as early as possible so that local tampering does not erase your evidence. Keep enough retention to support both short-term triage and longer investigations. The exact period depends on your risk profile and storage capacity, but the principle is simple: if you cannot review the event later, you cannot rely on it operationally.

Build baselines for key hosts first, especially domain controllers, jump servers, file servers, and administrator workstations. Those systems often generate the most valuable telemetry and are the most likely to be targeted. If you need a broader architecture view, our article on achieving centralised visibility across endpoints, identity, and network is a good companion piece.

Mapping detections to MITRE ATT&CK

MITRE ATT&CK is useful because it gives you a common language for describing what your detections cover. Sysmon and Windows Event Logs map well to many ATT&CK techniques, including process execution, scheduled task persistence, service creation, credential access, and lateral movement.

How Sysmon and Windows logs support ATT&CK techniques

Sysmon process creation supports techniques involving command execution and scripting. Network connection events support command-and-control and remote access behaviour. Registry and file events support persistence and configuration tampering. Windows Security logs support logon abuse, account manipulation, and privileged activity.

When you map detections to ATT&CK, you can see where your visibility is strong and where it is weak. That helps you prioritise the next logging improvement rather than guessing. If you want a structured method for that work, our article on mapping detections and controls to MITRE ATT&CK goes into the framework in more detail.

Using the mapping to prioritise coverage gaps

Focus first on the techniques most likely to affect your environment: initial execution, persistence, privilege escalation, credential access, and lateral movement. Then check whether you can actually observe those behaviours from your current logs. If not, add the missing telemetry before you try to write a detection rule.

That approach keeps detection engineering grounded in operational reality. It also helps you explain to stakeholders why a logging change matters, because you can tie it directly to a known attack technique rather than a vague desire for more data.

For UK SMEs, the most effective endpoint detection programmes are usually the ones that start small, stay consistent, and improve over time. Sysmon and Windows Event Logs are a strong foundation for that approach when they are configured with purpose and reviewed regularly. If you would like help designing a practical logging and detection approach for your environment, speak to a consultant.

Frequently asked questions

What are the differences between Sysmon and Windows event logs?

Sysmon is an additional Windows telemetry source that records detailed endpoint activity such as process creation, network connections, registry changes, and file creation. Native Windows Event Logs are built into the operating system and are especially useful for authentication, account management, services, scheduled tasks, and system events. In practice, Sysmon gives you more behavioural detail, while Windows logs give you more identity and operating system context.

What does Event ID 4737 mean?

Event ID 4737 indicates that a security-enabled global group was changed. In investigations, it is often relevant when you are checking whether a privileged group was modified or whether group-related attributes changed unexpectedly. It should be reviewed alongside related account and group membership events, plus the source host and user context.