Investigating Suspicious Windows Processes

Investigating process execution, network connections, and persistence mechanisms using Windows Event Logs and Sysinternals tools.

Introduction

A suspicious PowerShell execution, an unexpected child process, or an unusual outbound connection can trigger an alert in a Security Operations Center (SOC). However, identifying suspicious activity is only the beginning of an investigation.

An alert might reveal that powershell.exe initiated a network connection, but it does not necessarily explain what launched PowerShell, which commands were executed, or whether the activity was malicious.

To answer those questions, analysts must correlate evidence from multiple sources.

Windows provides several useful sources of endpoint telemetry, including Security Event Logs, Sysmon, and system configuration artifacts. Combined with tools such as Process Explorer and Autoruns, these sources can help reconstruct execution chains, examine network behavior, and identify potential persistence mechanisms.

In this article, I’ll walk through a practical Windows investigation workflow, focusing on the evidence analysts should examine, the commands used to retrieve it, and the limitations that matter when interpreting findings.

1. Initial Triage: Understanding Process Creation

Process creation events are often the starting point when investigating suspicious endpoint behavior.

Windows Security Event ID 4688 records the creation of a new process when Process Creation auditing is enabled.

Depending on the system’s configuration, the event can contain:

• New process name and process identifier (PID)
• Creator process information
• Security account and logon context
• Token elevation information
• Process command-line arguments

Command-line information is especially valuable because the executable name alone rarely provides enough context.

For example, rundll32.exe is a legitimate Windows utility used to execute functions exported by DLLs. It is also frequently associated with living-off-the-land techniques, where adversaries abuse trusted system utilities.

Discovering rundll32.exe in process creation logs is not enough to classify the activity as malicious. The analyst needs to examine the DLL being loaded, the arguments supplied, the execution context, and any subsequent behavior.

Retrieving Event ID 4688

The following PowerShell command retrieves process creation events from the previous 24 hours:

$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4688
    StartTime = $StartTime
} |
Select-Object TimeCreated, Id, Message

When reviewing these events, I generally focus on unusual executable paths, unexpected parent processes, privileged execution, and commands involving scripting interpreters or system utilities.

One important limitation is that command-line auditing must be explicitly configured. Without it, Event ID 4688 may not contain the arguments needed to understand how a process was used.

This is one reason Sysmon is particularly valuable during endpoint investigations.

2. Sysmon Event ID 1: Examining Process Execution

Sysmon, part of Microsoft Sysinternals, extends visibility into Windows system activity.

Event ID 1 records detailed information about process creation. Depending on the configuration, it includes the executable path, command line, parent process, execution account, process identifiers, and file hashes.

A particularly useful field is ProcessGuid.

Windows can reuse numeric process IDs after processes terminate. Sysmon’s Process GUID provides a more reliable identifier for correlating events associated with a particular process instance.

Retrieving Sysmon process events

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    ID = 1
    StartTime = $StartTime
} |
Select-Object TimeCreated, Id, Message

Several fields deserve particular attention:

FieldInvestigative purposeProcessGuidCorrelating activity associated with the processImageIdentifying the executableCommandLineExamining execution argumentsParentImageIdentifying the reported parent processParentCommandLineUnderstanding how the parent was launchedUserEstablishing the execution identityHashesIdentifying and comparing executable files

Consider a scenario where powershell.exe is launched by an application that does not normally start scripting interpreters.

That relationship warrants investigation, but it does not independently establish an attack.

The next step is examining the command line, determining whether the execution was authorized, and looking for related process or network activity.

PowerShell is extensively used for legitimate administration. The investigative value comes from its execution context and behavior rather than its presence alone.

3. Investigating Process Relationships With Process Explorer

Understanding parent-child process relationships can help identify unexpected execution chains.

Microsoft Sysinternals Process Explorer provides a hierarchical view of active processes and allows analysts to inspect their properties.

For example, consider a process chain resembling:

explorer.exe
   |
   +-- WINWORD.EXE
         |
         +-- powershell.exe

An Office application spawning PowerShell may warrant closer inspection, especially when the user was not performing an action that required scripting.

However, this relationship can also result from legitimate automation, macros, or approved software behavior.

The process tree provides an investigative lead rather than a definitive conclusion.

What to inspect

When investigating a running process, I would examine its executable path, command line, execution identity, digital signature, loaded modules, and parent-child relationships.

An executable located outside its expected directory may warrant further investigation. Likewise, a signed binary is not automatically benign, and an unsigned binary is not automatically malicious.

Process relationships also have limitations.

Windows supports mechanisms that can influence the parent process recorded during process creation. Consequently, the reported parent may not always represent the true origin of an execution chain.

This becomes particularly relevant when investigating process manipulation techniques.

Live analysis versus historical evidence

Process Explorer is most useful for examining the current state of a system.

If a suspicious process terminated before the investigation began, it may no longer appear in the process tree.

For historical reconstruction, analysts should rely on retained event logs, Sysmon telemetry, endpoint detection and response (EDR) records, or other forensic artifacts.

I generally treat Process Explorer as a live-triage tool and Sysmon as one of the sources used to reconstruct earlier execution.

4. Sysmon Event ID 3: Investigating Network Connections

After examining process execution, the next step is determining whether the process established network connections.

Sysmon Event ID 3 records network connection information associated with processes.

When available, useful fields include:

• Process GUID and PID
• Source and destination IP addresses
• Source and destination ports
• Protocol
• Associated executable
• Connection initiation information

Network connection logging must be enabled in Sysmon’s configuration; Event ID 3 is disabled by default.

Retrieving network connection events

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    ID = 3
    StartTime = $StartTime
} |
Select-Object TimeCreated, Id, Message

Suppose PowerShell establishes an outbound connection on TCP port 443.

That observation alone is insufficient to determine whether the connection is malicious.

Port 443 is commonly associated with HTTPS, and PowerShell may legitimately communicate with web services, internal APIs, deployment infrastructure, or management platforms.

The analyst should determine:

1. Which process instance initiated the connection?
2. What command was executed before the connection?
3. Is the destination expected for that endpoint or application?
4. Are there related DNS queries or subsequent process executions?
5. Does the activity match an approved administrative workflow?

The ProcessGuid field can help associate a network event with its corresponding process creation event.

This is more useful than investigating the destination address in isolation.

DNS telemetry

Sysmon Event ID 22 can also provide DNS query information when supported and enabled.

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    ID = 22
    StartTime = $StartTime
} |
Select-Object TimeCreated, Id, Message

DNS records can provide additional context regarding domains queried by a process.

However, a DNS query does not prove that a subsequent connection succeeded. Similarly, observing a network connection does not establish command-and-control activity or data exfiltration.

Those conclusions require additional evidence, potentially including firewall logs, proxy records, network captures, and EDR telemetry.

5. Investigating Persistence With Autoruns

If suspicious execution has been identified, analysts should determine whether the activity introduced a mechanism to execute code again.

Windows provides multiple legitimate autostart mechanisms. Some are frequently abused for persistence, including Registry Run keys, scheduled tasks, services, and Startup folder entries.

Microsoft Sysinternals Autoruns provides visibility into many of these locations.

Registry autostart locations

Two commonly examined Registry keys are:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

These locations can configure programs to execute when a user signs in.

They can be inspected using PowerShell:

Get-ItemProperty `
"HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"

An unfamiliar entry should be examined carefully.

Useful information includes the Registry value name, executable path, associated arguments, file metadata, and available timestamps.

An entry pointing to a user-writable directory may deserve closer examination, particularly when it correlates with other suspicious activity.

Nevertheless, its presence alone is not sufficient to establish malicious persistence.

Scheduled tasks

Scheduled tasks can be used to execute programs at predefined intervals or in response to particular triggers.

Windows Security Event ID 4698 records scheduled task creation when the relevant auditing is enabled.

Existing tasks can be enumerated using:

Get-ScheduledTask |
Select-Object TaskName, TaskPath, State

To examine the configured actions:

Get-ScheduledTask |
Select-Object TaskName, TaskPath,
@{
    Name = 'Actions'
    Expression = {
        ($_.Actions | ForEach-Object {
            "$($_.Execute) $($_.Arguments)"
        }) -join ' | '
    }
}

During analysis, I would pay particular attention to tasks invoking unexpected executables, unusual script paths, or commands inconsistent with the endpoint’s normal operations.

Windows services

Windows services represent another potential persistence mechanism.

Service Control Manager Event ID 7045, recorded in the System log, can provide information about newly installed services.

Services can be examined with:

Get-CimInstance Win32_Service |
Select-Object Name, DisplayName,
State, StartMode, PathName

The executable path and startup configuration are particularly relevant.

Autoruns can supplement these checks by presenting multiple autostart locations in one interface.

Its signature and publisher information can help prioritize suspicious entries, but neither a missing signature nor an unfamiliar publisher is sufficient to classify an executable as malware.

6. Correlating Events Into an Investigation Timeline

Individual event records become more useful when placed in context.

A process creation event may identify an execution point. A subsequent network connection may reveal communication. File creation or Registry modifications may indicate changes to the endpoint.

The challenge is determining which records are related.

A practical investigation can use the following evidence sources:

Investigation objectivePrimary evidenceIdentify process executionSecurity 4688, Sysmon 1Reconstruct process relationshipsSysmon 1, Process Explorer, EDRExamine network activitySysmon 3, DNS, firewall logsIdentify file modificationsSysmon 11 and other file telemetryExamine Registry modificationsSysmon 12–14Investigate scheduled tasksSecurity 4698, Task SchedulerInvestigate service installationSystem 7045Review PowerShell script activityPowerShell 4104, when enabled

Correlating Sysmon events

PowerShell can retrieve several relevant Sysmon event types for chronological review.

$Events = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    ID = 1,3,11,12,13,14,22
    StartTime = $StartTime
}

$Events |
Sort-Object TimeCreated |
Select-Object TimeCreated, Id, Message

This provides an initial chronological view of the recorded activity.

For more substantial investigations, structured parsing is preferable so that events can be correlated by their Process GUIDs, file paths, execution identities, and other relevant fields.

Why timestamp handling matters

Event records may be displayed using different time representations.

Before building a timeline, timestamps should be normalized into a consistent time zone, typically UTC.

Original timestamps and source records should be preserved so that the analysis remains reproducible.

Another important consideration is causality.

Events occurring seconds apart are not necessarily related. A credible correlation requires supporting relationships such as matching Process GUIDs, associated accounts, common file paths, or other evidence linking the activity.

Without these relationships, a timeline may introduce assumptions that the telemetry does not support.

7. Translating Findings Into Detection Engineering

Investigation findings can provide a basis for improving detection coverage.

Consider an execution pattern where an Office application unexpectedly starts PowerShell.

This behavior can be represented as a Sigma detection hypothesis:

title: Office Application Spawning PowerShell
status: experimental
description: Detects PowerShell launched by selected Office applications.

logsource:
  category: process_creation
  product: windows

detection:
  selection_parent:
    ParentImage|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'

  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'

  condition: selection_parent and selection_child

falsepositives:
  - Approved Office automation
  - Legitimate administrative workflows

level: medium

tags:
  - attack.execution
  - attack.t1059.001

This rule is intentionally simple.

It identifies a process relationship worth investigating, but it does not independently determine whether the execution is malicious.

Before deploying such a rule to a production SIEM, detection engineers should validate field mappings, test representative activity, review known-good behavior, and evaluate alert volume.

More contextual detections may incorporate command-line characteristics, execution identity, unusual file paths, and subsequent network or persistence-related activity.

However, requiring too many conditions can also reduce detection coverage.

The objective is to balance investigative value, false-positive rates, and visibility into the relevant threat behavior.

MITRE ATT&CK mapping

Several techniques are relevant to the behaviors discussed in this workflow:

TechniqueATT&CK IDCommand and Scripting Interpreter: PowerShellT1059.001System Binary Proxy Execution: Rundll32T1218.011Windows Management InstrumentationT1047Registry Run Keys / Startup FolderT1547.001Scheduled TaskT1053.005Create or Modify System Process: Windows ServiceT1543.003

These mappings should be applied only when supported by observed behavior.

For example, an ordinary PowerShell execution event does not automatically establish adversarial use of T1059.001.

ATT&CK is useful for organizing detection coverage and describing techniques, but it does not replace the underlying evidence.

8. Assessing and Documenting Findings

The final stage of an investigation is determining what the evidence supports and documenting the result accurately.

A technical assessment should distinguish between observations, interpretations, and unresolved questions.

For example, suppose Sysmon records a PowerShell process connecting to an external IP address.

An appropriately scoped observation would be:

Sysmon Event ID 3 recorded an outbound TCP connection associated with powershell.exe. The corresponding process creation record and command-line context should be reviewed to determine whether the communication was expected.

That statement is preferable to immediately describing the destination as a command-and-control server without supporting evidence.

An investigation report should address:

Execution: Which executable ran, how it started, and which account was involved.

Behavior: Which process, file, Registry, and network activities were observed.

Persistence: Whether any autostart mechanism was created or modified.

Scope: Which endpoints, accounts, or systems may be affected.

Confidence: Which findings are directly supported and which remain unresolved.

The absence of a particular event should also be interpreted carefully.

For example, if no scheduled task creation event is found, the analyst should verify whether the relevant auditing was enabled and whether the investigation window is covered by retained logs.

Missing telemetry is not the same as evidence that an action never occurred.

Conclusion

Investigating suspicious Windows activity requires more than identifying an unusual executable or network destination.

Windows Security Event Logs provide an initial record of process execution. Sysmon adds process identity, command-line context, and visibility into related activity. Process Explorer supports live process inspection, while Autoruns helps examine configured persistence mechanisms.

The value comes from correlating these sources.

A single event may suggest suspicious behavior, but a reliable investigation depends on execution context, supporting artifacts, and a clear understanding of the telemetry’s limitations.

For SOC analysts, the objective is not simply to identify potentially malicious activity. It is to establish what happened, determine which conclusions are supported by evidence, and communicate findings accurately enough to guide incident response.

References

1. Microsoft Sysinternals — Sysmon
2. Microsoft Learn — Sysmon Events
3. Microsoft Learn — Audit Process Creation
4. Microsoft Sysinternals — Process Explorer
5. Microsoft Sysinternals — Autoruns
6. Microsoft Learn — Get-WinEvent
7. MITRE ATT&CK — Enterprise Techniques

Sodik Tursunboev — Cybersecurity Analyst

Focus areas: SOC operations, detection engineering, Active Directory security, threat hunting, and offensive security.

Website: sodik.eu