Procmon Advanced Usage and Analysis

C. Highlighting

Highlighting (Filter -> Highlight..., Ctrl+H) allows events to be visually distinguished (e.g., by background color) without removing other events from the display.²³ It uses the same condition-building logic as filters. This is useful for drawing attention to specific events (e.g., highlight all ACCESS DENIED results in yellow) while still seeing the surrounding context. Highlight colors can be customized via Options -> Highlight Colors....²³

D. Event Properties (Details Pane)

Double-clicking an event or selecting it and pressing Ctrl+E (or Enter) opens the Event Properties window, which provides comprehensive details about the selected event across several tabs.²⁸

• Event Tab:
  • Displays general information about the event: Sequence #, Time of Day, Process, PID, TID, Operation, Path, Result, Class, Duration.
  • Crucially, the lower pane shows the parsed Detail column information, with each parameter on a separate line for clarity (e.g., Desired Access, Disposition, Options for CreateFile).²⁹
• Process Tab:
  • Information about the process that generated the event: Path, Command Line, PID, Parent PID, User, Session ID, Architecture (32/64-bit), Integrity Level, Virtualized status (on Vista+).²⁹
  • Module list: Shows DLLs and EXEs loaded in the process at the time of the event, with their load addresses and paths. Double-clicking a module shows its version information.²⁹
• Stack Tab:
  • Displays the call stack of the thread at the moment the event was logged. This is paramount for understanding the code path leading to the event.²⁹ Details are in section II.E.

E. Reading and Interpreting the Call Stack

The call stack is one of Procmon's most powerful diagnostic features, providing insight into the code execution path that led to a logged event.

1. Accessing the Stack:

The call stack for a selected event is available in the Stack tab of the Event Properties window (accessible by double-clicking an event, pressing Ctrl+E, or selecting Event -> Properties...).²⁹

2. Loading Symbols:

• Absolute Necessity: For meaningful stack traces, symbol files (.PDB files) are essential. Without symbols, the stack trace displays raw memory addresses (e.g., ntoskrnl.exe+0x1C34A0), which are difficult to interpret. With symbols, these addresses are resolved into human-readable function names, module names, and sometimes source file and line numbers (e.g., ntoskrnl.exe!NtCreateFile+0x1A).¹
• Configuration: Symbols are configured via Options -> Configure Symbols....
  • DbgHelp.dll Path: Procmon uses DbgHelp.dll for symbol resolution. It's important to ensure Procmon is configured to use an up-to-date version, typically found in the Debugging Tools for Windows installation directory or recent Windows Kits.³¹
  • Symbol Path (_NT_SYMBOL_PATH format): This path tells DbgHelp.dll where to find symbol files. A correctly configured symbol path is critical. A typical and recommended path structure is: srv*C:\MyLocalSymbols*https://msdl.microsoft.com/download/symbols This tells the symbol engine to first look in a local cache (C:\MyLocalSymbols in this example, which can be any local path) and, if not found, download them from the Microsoft public symbol server and store them in the local cache for future use.³² Private symbol paths for custom-developed applications or third-party drivers should also be added here, separated by semicolons.
  • symsrv.dll: This DLL is the symbol server client used by DbgHelp.dll to retrieve symbols from symbol servers specified in the path (like the Microsoft public server).³²
• Impact: Proper symbol configuration transforms an almost useless list of addresses into a rich source of diagnostic information, clearly identifying the functions and modules involved in an operation.³⁰

3. Structure (Reading Order):

The call stack is displayed with the most recent (deepest) function call at the top (frame 0 or 1) and the initial function call (closest to user-mode or the start of the kernel operation being logged) at the bottom. To understand the flow of execution leading to the logged event, read the stack from the bottom up.

• The bottom-most frames often show the transition from user mode to kernel mode (e.g., a system call invoked from ntdll.dll or win32u.dll) or the entry point of a kernel callback routine (e.g., a file system minifilter callback in fltmgr.sys or PROCMONXX.SYS).
• Each frame above it represents a function called by the function in the frame below it.

4. Identifying Modules:

Each frame in the stack trace typically follows the format Module!Function+Offset (e.g., ntoskrnl.exe!KeSetEvent+0x1a) or just Module+Address if full symbols aren't available.

• User-mode DLLs: Modules like kernel32.dll, user32.dll, advapi32.dll, application-specific DLLs (e.g., MyApplication.dll), and .NET runtime DLLs (coreclr.dll, clr.dll). These are often seen at the bottom of call stacks for operations initiated by user-mode applications. User-mode frames are marked with a 'U' on the left if user-mode stack walking is enabled and successful (availability depends on system architecture and OS version, generally available on 64-bit systems post Vista SP1).²²
• Core Kernel Components:
  • ntoskrnl.exe: The NT OS Kernel, containing core executive services, memory management, process management, I/O manager (parts of it), etc.
  • hal.dll: Hardware Abstraction Layer, providing an interface between the kernel and platform-specific hardware.
• Specific Drivers:
  • File System Drivers: ntfs.sys (NTFS), fastfat.sys (FAT32/FAT16), exfat.sys (exFAT), refs.sys (ReFS).
  • Network Stack Drivers: tcpip.sys (TCP/IP protocol driver), ndis.sys (Network Driver Interface Specification wrapper).
  • Filter Manager: fltmgr.sys (File System Filter Manager).
  • Procmon's own driver: PROCMONXX.SYS (e.g., PROCMON24.SYS).
• Third-Party Filter Drivers: These are crucial to identify, especially when troubleshooting compatibility issues or unexpected behavior. They are often identifiable by vendor names within the module path (e.g., AVDriver.sys, EncryptDrv.sys, BackupFlt.sys). The presence of LeakyFlt.sys in a stack trace, as shown in one example, indicates its involvement.³

5. Using the Stack for Diagnosis:

• Pinpointing Code Path: The stack trace reveals the exact sequence of function calls within the kernel (and potentially user-mode) that led to the specific event Procmon logged.
• Identifying Initiator: The lower frames of the stack (closer to the user/kernel transition or initial callback) often point to the ultimate initiator of an operation – a specific function in an application DLL, a system worker thread, or an interrupt handler.
• Understanding Driver/Filter Involvement: The presence of various driver modules (.sys files) in the stack clearly indicates their participation in processing the request. This is especially vital for diagnosing issues with file system filters, network filters, or other drivers interacting with the operation.³
• Correlating with Result Column: By examining which module's function is near the top of the stack (or which module is just below PROCMONXX.SYS in a post-operation for file I/O, or which module PROCMONXX.SYS called that returned an error), one can often infer which module likely returned the status code seen in the Result column. For instance, if VendorAV.sys!ScanFunction is high in the stack for a CreateFile operation that returns ACCESS DENIED, the AV filter is a prime suspect.

The call stack provides a narrative of causality. Each frame represents a function that called the function in the frame above it (or is the currently executing function, for the top-most relevant frame). Reading from bottom-up tells a story: "Process A called API B in ntdll.dll, which transitioned to kernel function C in ntoskrnl.exe, which called I/O Manager function D, which invoked filter E, then filter F (Procmon), then filter G, then file system H..." When an operation fails (e.g., ACCESS_DENIED), the stack trace helps identify the module that was likely executing or had just finished executing when that decision was made. If PROCMONXX.SYS is logging a post-operation, the functions immediately above it (or the component it called that returned the error) are key. Combined with altitude changes, this narrative can reveal "hidden actors" (other filter drivers) that influence outcomes. For example, if an operation succeeds with Procmon at high altitude, but fails or behaves differently when Procmon is at low altitude (revealing a new filter driver X in the stack), driver X becomes a suspect. Thus, the call stack is not just a list of functions; it's a critical diagnostic tool for assigning responsibility for an event's occurrence and outcome.

6. Stack Trace and Altitude Interaction (Revisited):

As detailed in Section I.C.2, Procmon's file system filter driver altitude directly influences which other filter drivers appear in the call stack above PROCMONXX.SYS (or its internal logging function within PROCMONXX.SYS).

• A lower Procmon altitude means PROCMONXX.SYS is invoked later in the pre-operation chain or earlier in the post-operation chain. Consequently, more filter drivers that are positioned higher in the I/O stack will have their function frames present on the call stack when Procmon captures it. This leads to a "longer" stack trace visible in Procmon, showing more modules above PROCMONXX.SYS.³
• A higher Procmon altitude (the default) means fewer such drivers will be visible above PROCMONXX.SYS in the stack trace.

F. Interpreting the Result Column

The Result column in Procmon is critical for understanding the outcome of an operation.

1. Primary Code System:

The Result column primarily displays NTSTATUS codes for kernel-originated operations (e.g., STATUS_SUCCESS, STATUS_ACCESS_DENIED, STATUS_OBJECT_NAME_NOT_FOUND).³⁴ Procmon often translates these hexadecimal NTSTATUS values into more human-readable symbolic names (e.g., SUCCESS, ACCESS DENIED, NAME NOT FOUND). For some user-mode initiated events or certain network operations, it might display Windows error codes (Win32 errors), which are often related to or can be mapped from NTSTATUS codes.³⁴

2. Potential Origins:

The Result logged by Procmon is the status code returned at the point Procmon intercepted the operation's completion (for post-operations) or the status determined at the point of pre-operation logging. This status can originate from various components:

• The ultimate target component:
  • The base File System Driver (e.g., NTFS.SYS, FASTFAT.SYS) for file operations.
  • The Network Stack (e.g., TCPIP.SYS, AFD.SYS) for network operations.
  • The Registry Manager (implemented within ntoskrnl.exe as the Configuration Manager) for registry operations.¹²
• A third-party filter driver positioned above Procmon in the I/O stack (for file operations) that intercepted and completed/failed the IRP before it reached Procmon's pre-operation callback or before it could proceed to lower drivers. Procmon might log the initial parameters of the request, but the result it records could be from this higher filter if it completes the IRP.
• A third-party filter driver positioned below Procmon in the I/O stack whose failure status propagated back up to or through Procmon's layer during post-operation processing. For example, an anti-virus filter below Procmon might return STATUS_ACCESS_DENIED, and Procmon would log this result.
• Core NT Executive subsystems¹⁴:
  • Object Manager: Responsible for managing kernel objects. Can return codes like STATUS_OBJECT_NAME_NOT_FOUND, STATUS_OBJECT_PATH_NOT_FOUND, STATUS_INVALID_HANDLE.
  • Security Reference Monitor (SRM): Performs access checks. The primary source of STATUS_ACCESS_DENIED if an operation is denied based on security descriptors and token privileges.³⁶
  • I/O Manager: Can return errors related to IRP parameter validation or structural issues.
  • Memory Manager: Can return errors related to buffer validity, memory mapping failures (e.g., STATUS_INSUFFICIENT_RESOURCES).

3. Leveraging the Interpreting Process Monitor Results Article:

For a comprehensive catalog and detailed explanation of specific Result codes (NTSTATUS values), their meanings, common causes, and potential origins (including the crucial role of filter drivers and core Windows components like the Object Manager or Security Reference Monitor), refer to the Interpreting Process Monitor Results articlearticle.

4. Using Procmon Context for Inference:

To accurately determine the source and meaning of a Result code in a specific trace, it's essential to use the surrounding context provided by Procmon, in conjunction with the detailed knowledge from the Interpreting Process Monitor Results article:

• Call Stack: As discussed in II.E.5, the modules present in the call stack, especially those near PROCMONXX.SYS or at the top of the stack when the error is returned, are strong indicators of the component that generated the result.
• Surrounding Events:
  • Retries: Does the application attempt the same operation multiple times after a failure? This can indicate transient issues or an application's error handling logic.
  • Subsequent Operations: What does the application do after receiving a specific result? Does it try an alternative path? Does it query for more information (e.g., querying file attributes after a CreateFile fails)? Does it log an error or terminate?²⁹
• Duration Column: An unusually long duration before a SUCCESS or a failure might indicate contention, network latency, a slow driver, or complex processing by an intermediate component before the final result is determined.
• Detail Column: This column provides operation-specific parameters (e.g., Desired Access flags, Disposition, Options for CreateFile; Type for RegQueryValueKey). Comparing these parameters with the object's actual state or permissions can often explain the result. For example, if Desired Access requests DELETE permission, but the file's security descriptor (DACL) doesn't grant this to the process, an ACCESS DENIED result is expected.²⁹

An NTSTATUS code like STATUS_ACCESS_DENIED is merely a symptom; it indicates that access was denied but doesn't inherently reveal by whom or precisely why. the Interpreting Process Monitor Results article will elucidate the general meanings and common origins of such codes. Procmon's true diagnostic power emerges when this code is analyzed alongside the call stack (pinpointing involved modules), the Detail column (showing request parameters), Procmon's altitude settings (which might reveal or hide intermediate filter drivers), and the sequence of surrounding events. This holistic view enables the analyst to progress from "the operation failed with code X" to a more precise diagnosis like "the operation failed with code X because filter driver Y intercepted the call made with parameters Z, originating from process P." The Result column is thus a starting point, and its interpretation requires synthesizing information from multiple Procmon features, underpinned by an understanding of Windows internals and the specifics of NTSTATUS codes.

A. Boot Logging

Boot logging allows Procmon to capture system activity from the very early stages of the Windows boot process, continuing through driver initialization, service startup, and user login.¹ This is invaluable for:

• Diagnosing issues that occur during boot or shutdown.
• Identifying causes of slow boot or login times.
• Detecting early-stage malware activity or persistence mechanisms that execute at startup.⁴⁰
• Troubleshooting service or driver failures that prevent normal system operation.

Enabling Boot Logging:

To enable boot logging, navigate to Options -> Enable Boot Logging in the Procmon menu.²⁷ Procmon will then configure its driver (PROCMONXX.SYS) to start logging events automatically upon the next system reboot. Options may be available to also generate profiling events (periodic thread stack dumps) during boot logging, which can aid in performance analysis.

Collecting and Analyzing the Trace:

After enabling boot logging and rebooting the system, log in as usual. Once the desktop is loaded (or when ready to collect the log), run Procmon.exe again. Procmon will detect that boot log data (typically saved to a file like C:\Windows\Bootlog.pml) exists and will prompt to save it to a new .PML file.³⁸

Boot logs can be extremely large, often containing tens or hundreds of millions of events. Effective filtering is absolutely essential for analysis. Key areas to investigate in a boot log include:

• Processes that terminate unexpectedly or return error codes during startup.
• Errors (Result codes other than SUCCESS or expected informational codes) occurring during the initialization phases of critical system drivers or services.
• Unusual file or registry access patterns, such as unexpected writes to system areas or autorun locations, which might indicate malware persistence attempts.
• Long delays between events or operations with high Duration values, which can pinpoint boot performance bottlenecks.

B. Process Tree View

The Process Tree view provides a hierarchical representation of all processes that were active and captured during the Procmon trace, illustrating parent-child relationships.¹

Accessing and Using the Process Tree:

The Process Tree is accessed via Tools -> Process Tree or by pressing Ctrl+T. The window displays processes in a tree structure, where child processes are nested under their parent process. This view is highly useful for:

• Quickly understanding the lineage of processes (e.g., seeing that services.exe launched svchost.exe, which in turn launched another service's executable).
• Visually identifying process chains, which can be important in malware analysis (e.g., Word document spawning PowerShell, which then spawns a suspicious executable).
• Identifying processes that were created and terminated during the trace.

Filtering from the Process Tree:

A powerful feature of the Process Tree is the ability to quickly filter the main Procmon event display based on a selected process in the tree. Right-clicking on a process in the tree offers options such as:

• Add process to Include filter: This action filters the main event list to show only events generated by the selected process.
• Add process and children to Include filter: This filters the main event list to show events from the selected process and all of its descendants in the process tree. This is an extremely efficient way to isolate the activity of a specific application and any processes it may have launched, significantly reducing noise in the trace.⁴²

C. Duration Analysis and Performance

The Duration column in Procmon is a key metric for identifying performance bottlenecks.²¹ For synchronous operations, this column displays the time elapsed between Procmon logging the pre-operation event and the post-operation event. The unit is typically seconds, often with microsecond precision.

Identifying Bottlenecks with Duration:

Sorting the event list by the Duration column in descending order quickly highlights the operations that took the longest to complete. These can be indicative of:

• Disk I/O bottlenecks: Slow physical disks, high disk queue lengths, or excessive seeking.
• Network latency: For operations involving remote file access or network communication (e.g., TCP Send, TCP Receive, ReadFile on a network share). The duration will include network round-trip times.
• CPU-intensive operations within a driver or kernel component: A filter driver performing complex analysis or a poorly optimized kernel routine.
• Overhead from filter drivers: Security software (AV, EDR), encryption drivers, or backup agents can add significant latency to I/O operations.
• Resource contention: Waiting for locks or other shared resources.

Interpreting Duration:

Context is crucial when evaluating Duration values. A 0.5-second duration for reading a small registry value is extremely high, whereas for reading a multi-megabyte file over a slow network, it might be acceptable.

• Compare durations for similar operations on similar resources.
• Look for outliers: operations with durations significantly longer than the norm.
• Consider the impact on user experience: even small delays in frequently executed operations on a critical path can lead to perceived sluggishness.
• For file operations, the Offset and Length details in the Detail column are important. A long duration for reading a large chunk of a file is different from a long duration for reading a few bytes.

Tools -> Count Occurrences...:

This dialog (Tools -> Count Occurrences...) provides frequency statistics for unique values within any selected column.⁴³ It is a powerful adjunct to duration analysis.

• Usage: Select a column (e.g., Operation, Path, Process Name, Result) and click Count. Procmon will display a list of unique values found in that column for the currently filtered events, along with the number of times each value occurred.
• Performance Insight: While not directly measuring time, Count Occurrences can reveal "death by a thousand cuts" scenarios. An application might perform an excessive number of individually fast operations, leading to cumulative performance degradation. For example:
  • Counting Path occurrences for a slow application might reveal it's reading the same small configuration file thousands of times.
  • Counting Operation occurrences might show an unexpectedly high number of RegQueryValueKey calls.
  • Counting Result occurrences can quickly show the prevalence of errors like ACCESS DENIED or NAME NOT FOUND.⁵³

Performance analysis in Procmon often requires looking at both individual operation Duration and the Count Occurrences of operations. A high count of individually fast operations can be as detrimental as a few very slow operations. For example, an application reading a large file one byte at a time would show many quick ReadFile events, but the overall time to read the file would be substantial. Count Occurrences on the Path for that specific file would highlight the excessive number of operations.

D. Identifying Filter Driver Influence

Filter drivers (especially file system and network filters) are common sources of application compatibility issues, performance degradation, and unexpected behavior. Procmon is a primary tool for identifying their influence. Key techniques include:

1. Observing Filter Driver Modules in Stack Traces: The most direct method. If a third-party driver (e.g., VendorAV.sys, EncryptionFilter.sys) appears in the call stack for an operation, particularly if it's associated with an error, a long duration, or is unexpected, it's clearly involved. This requires properly configured symbols (see II.E.2).³

2. Correlating Procmon Activity with fltmc instances Output:

• Run fltmc instances in an administrative command prompt. This command lists all currently loaded file system minifilter drivers, their assigned altitudes, and instance information.³
• Compare this list with modules observed in Procmon stack traces. If a filter listed by fltmc is in an altitude range relevant to the observed issue but isn't appearing in stack traces, consider adjusting Procmon's altitude (see I.C.4).

3. Analyzing Result Codes Known to be Frequently Returned by Filters: Certain NTSTATUS codes, while standard, are often returned by specific types of filter drivers. For example, security filters might return ACCESS DENIED, or backup filters might cause SHARING VIOLATION or FILE_LOCKED_WITH_ONLY_READERS. the Interpreting Process Monitor Results article on Result codes is essential here.

4. Observing Unexpected Operation Sequences or Retries: If an application attempts an operation, it fails, and then it immediately retries (sometimes multiple times), or if it performs a series of unusual preparatory queries before an operation, a filter driver might be interfering with the normal flow.

5. Methodically Adjusting Procmon's Altitude: As detailed in Section I.C, lowering Procmon's altitude can reveal the activity of filters operating below its default position. If new filter driver modules appear in call stacks when Procmon's altitude is lowered, and the behavior or result of an operation changes concurrently, this strongly implicates those newly visible filters.³

6. Methodically Disabling/Uninstalling Third-Party Software: If a specific third-party application known to install filter drivers (e.g., antivirus, endpoint security suites, disk encryption tools, backup software) is suspected of causing an issue, temporarily disabling or uninstalling that software (ideally in a controlled test environment) can help confirm its filter's involvement. Comparing Procmon traces taken before and after the disable/uninstall can pinpoint the differing behaviors.

E. Common Troubleshooting Scenarios

The techniques described can be applied to a wide range of diagnostic scenarios.

1. Application Crashes/Failures:

• Technique: Start by filtering for the crashing application's process name. Examine the events immediately preceding the process termination (often indicated by a "Process Exit" event, possibly with an error code in the Detail column, or by correlating with WerFault.exe activity if Windows Error Reporting is involved).
• Result Codes: Look for critical errors like ACCESS DENIED, OBJECT_NAME_NOT_FOUND, SHARING_VIOLATION, INVALID_HANDLE on essential files, registry keys, or DLLs.
• Stack Trace Analysis: If Procmon captures an event that directly leads to an unhandled exception (e.g., an access violation during a file read), the call stack for that event can be invaluable. It might point to the faulting module or a module that passed invalid data to a system call.³⁰
• Missing Dependencies: Look for NAME_NOT_FOUND results on Load Image operations (Procmon's way of showing DLL loads) or on CreateFile operations attempting to open DLL files.

2. File Access Denied/Sharing Violations:

• Technique: Filter for Result is ACCESS DENIED or Result is SHARING VIOLATION.¹⁸ Also include the process name of interest.
• Detail Column: For CreateFile operations resulting in these errors, examine the Detail column to see the Desired Access (e.g., Read, Write, Delete), ShareMode (e.g., Read, Write), and Disposition (e.g., Open, Create, Overwrite) requested by the application. An ACCESS DENIED may occur if the requested access rights conflict with the file's security descriptor (DACL). A SHARING VIOLATION occurs if the requested share mode conflicts with how the file is already opened by another handle (possibly in the same process or a different one).
• Call Stack & Altitude: Check the call stack to see if a filter driver (e.g., antivirus, data loss prevention, encryption) is returning the denial. If a filter is suspected but not visible, adjust Procmon's altitude (see I.C.4).
• Process Tree/Other Tools: Use Tools -> Process Tree (Ctrl+T) to identify other running processes. Tools like Process Explorer or Handle (also from Sysinternals) can then be used to see which process has a handle open to the problematic file and with what access/share modes.

3. Registry Access Issues:

• Technique: Filter for the relevant process name and for registry operations (Event Class is Registry) with Result codes such as ACCESS DENIED, NAME_NOT_FOUND, or PRIVILEGE NOT HELD.
• Common Causes:
  • Application trying to write to a protected registry key (e.g., under HKLM\SYSTEM or HKLM\SOFTWARE) without sufficient privileges (e.g., not running as administrator).
  • Application trying to read a key or value that does not exist (NAME_NOT_FOUND).
  • Application requiring a specific privilege (e.g., SeRestorePrivilege for certain hive operations) that its token does not possess.
• Call Stack: Can indicate if registry virtualization (e.g., UAC virtualization) or security software is intercepting and modifying registry access.

4. Slow Application Startup/Performance:

• Technique:
  • For system-wide slow startup or slow user login, enable boot logging (see III.A).²⁷
  • For application-specific slowness, start Procmon capture immediately before launching the application and stop it once the application is fully loaded or the slow operation completes.
• Filtering: Filter for the application's process name(s).
• Duration Column: Sort by Duration (descending) to find the single most time-consuming operations.⁴⁵ These are immediate candidates for investigation.
• Tools -> Count Occurrences...: Use this to identify operations that are executed an excessive number of times, even if individually fast (e.g., thousands of reads from the same configuration file, or excessive registry queries).
• Specific Operations: Look for long delays in Load Image operations (slow DLL loading), TCP Connect (slow network resource access), or lengthy file reads/writes to specific paths.
• Stack Traces for Slow Events: Analyze call stacks for high-duration events. This can reveal if specific drivers (especially third-party filters) or inefficient code paths are contributing to the delays.

5. Suspected Malware Activity Patterns:

Procmon can be instrumental in dynamic malware analysis by revealing characteristic malicious behaviors.⁵⁶

• Technique: Often involves looking for known indicators of compromise (IOCs) or common malware tactics:
  • Persistence Mechanisms:
    • Registry: Writing to Run, RunOnce, Userinit, Shell keys (e.g., HKCU\Software\Microsoft\Windows\CurrentVersion\Run). Filter for these key paths and write operations.
    • File System: Dropping executables or scripts into Startup folders (user or common), creating scheduled tasks (Procmon might see the schtasks.exe execution or direct registry writes for tasks). Filter for these paths.
    • Boot logging is crucial for detecting persistence mechanisms that execute early in the boot process.²⁷
  • Evasion/Stealth:
    • Process Injection: While Procmon may not show the act of injection itself, it can show the effects, such as a legitimate process (e.g., explorer.exe, svchost.exe) suddenly making unexpected network connections, dropping files, or modifying sensitive registry keys.
    • Attempts to Disable Security Software: Look for operations (especially writes or deletes) targeting files, directories, or registry keys associated with antivirus products or other security tools.
  • Command and Control (C2) Communication:
    • Unexpected network connections (TCP Connect, UDP Send) by processes that typically shouldn't have network activity, especially to unusual IP addresses, domains, or non-standard ports.
  • Data Exfiltration: Sequences of extensive file reads (especially from user document folders, databases, etc.) followed by network send operations.
  • Lateral Movement: Attempts to access network shares, enumerate other systems, or use tools like PsExec.exe.
• Other Indicators:
  • Processes running from unusual locations (e.g., C:\Users\<user>\AppData\Local\Temp, C:\Windows\Temp, recycled bin).
  • Suspicious process parent-child relationships (e.g., winword.exe spawning cmd.exe or powershell.exe). The Process Tree view (Ctrl+T) is excellent for visualizing this.
  • File operations that create hidden files or alternate data streams (ADS).

Troubleshooting complex system issues or analyzing unknown software behavior with Procmon is rarely a linear process. It typically involves an iterative cycle of observation, hypothesis formation, filter refinement, and detailed event examination. An analyst might start with broad filters (e.g., focusing on a specific process or time window), observe initial patterns (such as frequent errors or operations with long durations), and then form a hypothesis (e.g., "the application appears to be struggling with network access to a specific server"). This hypothesis then guides the refinement of filters (e.g., including only network operations to that server, looking for specific error codes like HOST NOT FOUND or CONNECTION TIMEOUT). Examination of call stacks for the suspect operations, coupled with tools like Count Occurrences or sorting by Duration, provides further data. If filter drivers are suspected, adjusting Procmon's altitude might be the next step. This iterative approach, combining Procmon's features with a solid understanding of Windows internals, is key to effective diagnostics. The scenarios outlined above serve as starting points for this investigative process, rather than rigid checklists.