Windows Forensics: Lateral Movement Adversary Tactics and Detection

 

Once initial access has been established and privileges elevated, the lateral transfer of files and malicious payloads between compromised hosts becomes a critical operational requirement for many advanced threat actors. While not all lateral movement techniques necessitate the staging or transfer of malware and supporting files, such transfer becomes indispensable when the adversary intends to leverage tooling or capabilities not native to the target system's default configuration.

Remote Desktop Protocol

A foundational principle in reconstructing lateral movement is that threat actors, once established, tend to converge on the same administrative pathways legitimately used by system administrators—pathways your network architecture was deliberately engineered to permit or restrict. Upon acquisition of domain administrator credentials, adversaries rapidly operationalize them for intra-network pivoting, frequently exploiting enabled Remote Desktop Protocol (RDP) services where present.

Source System Artifacts

RDP remains the predominant remote access protocol in Windows enterprise environments and, fortunately, generates robust forensic artifacts. The most probative evidence, however, typically resides on the destination host—making the %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RDPClient%4Operational event log on the source system a critical data source for identifying pivot points without exhaustively triaging every potential target system. This log records outbound connections from the source system, principally through Event IDs 1024 and 1102. Analysts should flag anomalous indicators, such as RDP sessions to workstations or server connections occurring outside established administrative windows.

Other source-system artifacts:

1. The Registry key NTUSER\Software\Microsoft\Terminal Server Client\Servers contains the value UsernameHint. This value stores the domain and username of the last account used to authenticate to that specific remote host, thereby linking a particular destination to the credentials employed during the most recent session. The RegRipper plugin “rdphint” reliably parses this key. Under NTUSER\Software\Microsoft\Terminal Server Client\Default, the values MRU0 through MRU9 preserve a most-recently-used list of previously contacted hosts. Each value contains an IP address (or hostname) corresponding to a prior RDP destination. MRU0 always reflects the most recent connection. The last-write timestamp of the parent key records the moment a previously unseen destination was first added to the history (i.e., the first connection to a host not already present in the MRU list). 
2. Jump list entries generated by mstsc.exe.
3. Sysmon provides high-fidelity process telemetry for Remote Desktop client activity through Event ID 1 (Process Create) and Event ID 5 (Process Terminated). Key fields of investigative value include: Image path: C:\Windows\System32\mstsc.exe; Process Command Line; User context; and Process ID. These events enable precise reconstruction of both the initiation and termination of RDP client sessions on a per-user basis.
4. Event IDs 4688 (A new process has been created) and 4689 (A process has exited) capture the creation and termination of the Remote Desktop client. When the New Process Name field equals C:\Windows\System32\mstsc.exe, the following fields provide high-value investigative context:
• Process start and end timestamps (derived from the event log timestamps).
• Subject Account Name and Account Domain (identity of the user who launched the process).
• Token Elevation Type (indication of privilege escalation at process creation).
• Exit Status (process return value).
5. Event IDs 4663 (An attempt was made to access an object), 4656 (A handle to an object was requested), and 4658 (The handle to an object was closed) may record file-system interactions performed by mstsc.exe. Of particular relevance is access to user profile artifacts such as C:\Users\[User Name]\Documents\Default.rdp. Key correlative fields include:
• Object Name (target file path).
• Handle ID (enabling temporal linkage across related handle-open, access, and handle-close events).
• Access Request Information (e.g., WriteData / AddFile, AppendData).
• Keywords (Audit Success or Audit Failure).
6. Presence of Default.rdp in the user profile, with MAC timestamps as pivot indicators.
7. Execution artifacts documenting mstsc.exe invocation frequency.
8. RDP Bitmap Cache fragments, parseable via bmc-tools.py.

Although a broad spectrum of remote screen-sharing applications exists, only a subset is typically deployed in enterprise environments. Depending on implementation, these tools may or may not generate standard Windows logon authentication events. VNC implementations, for example, frequently produce a Type 2 (Interactive/Console) 4624 logon event on the target rather than a Type 10 (RemoteInteractive) event. Leading VNC variants (UltraVNC, TightVNC, RealVNC) maintain application-specific logs on the source system that record outbound connection attempts. Corresponding registry keys may additionally preserve recently connected hosts and confirm prior installation of the application.

TeamViewer, another widely observed remote access solution, generates artifacts on both source and target systems. On the source host, examiners should locate TeamViewerX_Logfile.log  within C:\Program Files\TeamViewer\VersionX (substituting the appropriate version number). On the target, incoming connections are recorded in Connections_incoming.txt.

In certain intrusions, adversaries deploy proprietary or non-standard remote desktop solutions to facilitate lateral movement. In such cases, evidence of unauthorized application installation—manifested in event logs, registry artifacts, and file-system remnants—serves as a strong indicator of malicious activity.

Defensive controls can materially reduce the risk of RDP-based lateral movement for high-value accounts. The Active Directory user right “Deny log on through Remote Desktop Services” GPO may be applied to the Domain Administrator and sensitive service accounts. At the host level, the Terminal Services service can be disabled, and Windows Firewall rules can be configured to deny inbound RDP connections in network segments where remote desktop functionality is not operationally required.

Destination (Target) System Artifacts

When investigating lateral movement, precise knowledge of evidentiary deposition is essential. On the destination (target) system, activity is predominantly recorded within the Windows Event Log infrastructure. Although ancillary registry, file-system, and memory artifacts associated with helper processes (for example, rdpclip.exe, which enables inter-session clipboard sharing) may be recoverable, the bulk of investigative value derives from the robust native logging capabilities of Windows. This reality underscores the critical importance of centralized log aggregation: once a malicious pattern is identified, it can be rapidly queried across the entire endpoint population.

RDP sessions manifest as Event ID 4624 with Logon Type 10 (RemoteInteractive). Such logons are comparatively uncommon in most environments and therefore constitute a high-signal indicator of remote desktop activity. Complementary RDP-specific events—Event IDs 4778 (session reconnect) and 4779 (session disconnect)—further enrich the timeline. Investigators should prioritize anomalous patterns, including RDP connections directed toward workstations or server access occurring outside established administrative windows. Depending on the environment, Event ID 4624, Logon Type 12, may be recorded in the destination host's Security event log.

Beyond the Security log, contemporary Windows versions maintain several specialized RDP operational channels that substantially augment visibility on the destination host:

• Microsoft-Windows-RemoteDesktopServices-RDPCoreTS/Operational
• Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
• Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

These channels are enabled by default and exhibit significantly slower log-rollover rates than the Security event log, thereby preserving a longer evidentiary window.

Within %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx, Event IDs 21, 22, and 25 frequently record both the originating IP address and the authenticated username. Event ID 41 may likewise capture the logon username. The %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx channel records Event ID 1149, which contains the initiating IP address and the associated logon username. Finally, %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx may log Event ID 131, again capturing the initiating IP address and username.

Further temporal and network context is available in the LocalSessionManager operational log. Event ID 21 documents session logon events (both local and remote) and, for remote sessions, includes the source IP address. Event ID 24 records session disconnection events and similarly preserves the remote IP when applicable. In the case of purely local logons, the Source Network Address field is populated with the literal value “LOCAL” rather than a network address.

Windows Admin Shares

Windows administrative shares constitute default, hidden network resources engineered to grant administrative processes unrestricted access to the host file system. Present across every modern Windows build—though concealed from standard enumeration—these shares are, in the overwhelming majority of environments, enabled by default. From a lateral-movement perspective, the most operationally significant shares are the volume root shares (e.g., C$), the Admin$ share (providing access to the %SystemRoot%\Windows directory), and the IPC$ share (commonly leveraged for named-pipe communication).

Source System Artifacts

Detection of administrative-share lateral movement is more readily achieved on the source system than on destination hosts. Source-side event logging is comparatively sparse, yet residual evidence may surface when alternate credentials are employed or when connection attempts fail. On the client initiating access to a remote administrative share, Event ID 4648 (A logon was attempted using explicit credentials) may be generated, contingent upon the authentication method employed. When a user supplies a Universal Naming Convention (UNC) path through the Windows Explorer graphical interface, the svchost process hosting the Netlogon service performs the authentication request on the user’s behalf. Consequently, Event ID 4648 records that the SYSTEM security identifier explicitly invoked the user’s credentials via an impersonation token, rather than operating under the security context of the Netlogon service itself. Event ID 4648 is likewise generated—or, in certain cases, Event ID 4624 with Logon Type 9 (NewCredentials)—when a user launches a process via the runas command or supplies explicit credentials to utilities such as net use. By contrast, a command that relies on the user’s existing security token (for example) does not produce Event ID 4648, because pass-through authentication is employed. However, the explicit provision of alternate credentials—illustrated by net use * \\server1\C$ /user:administrator—will reliably generate Event ID 4648. Where command-line auditing is enabled, examiners should specifically search for logged command strings such as "net use".

Because the native net suite remains the predominant mechanism for enumerating and mapping shares, program-execution artifacts associated with these binaries are of high investigative value. Shellbag artifacts record remote folders navigated within interactive Explorer sessions, providing visibility into specific paths accessed by an adversary who obtained interactive (e.g., RDP) control. ShimCache entries for net.exe and net1.exe preserve evidence of program execution. Background Activity Moderator (BAM)/Desktop Activity Moderator (DAM) records the last execution timestamps of net.exe and net1.exe. AmCache stores the first-observed execution timestamps of net.exe and net1.exe. Prefetch files named net.exe-{hash}.pf and net1.exe-{hash}.pf document recent executions of the native share-mapping utilities. When interactive access (for example, via RDP) was obtained, shortcut files (.lnk) and Jump Lists should be examined for references to remotely accessed files and shares.

A particularly valuable source-system artifact is the registry key NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2. Because the NTUSER hive is bound to a discrete user account, this key enumerates the complete set of remote systems to which that account has established connections. The data set can be further enriched through examination of Shellbag artifacts, which record the specific folders accessed during interactive sessions. Reconstructing an equivalent connection history solely from destination systems would require aggregating event-log entries across every potential target host—an inherently less efficient approach, given that Windows event logs predominantly capture activity at the destination rather than the source.

In the above example, a user’s MountPoints2 key demonstrates that administrative shares were accessed on at least two remote systems (10.3.58.4 and 10.3.58.5).

Destination (Target) System Artifacts

Threat actors routinely leverage administrative shares—enabled by default to permit remote host management via SMB—to stage tooling into virtually any writable location on a remote host. Volume root shares (C$, D$, etc.) grant unrestricted access to the entire file system and therefore constitute an efficient conduit for the remote exfiltration or enumeration of sensitive data. Because Server Message Block (SMB) retains design weaknesses conducive to NTLM-relay attacks, and because few environments have fully enforced modern mitigations such as SMB signing, pass-the-hash—the theft and reuse of hashed credentials for lateral authentication—remains a prevalent technique along this vector.

Contemporary Windows versions (Vista and later) impose a significant restriction: remote access to administrative shares requires either Domain Administrator privileges or the built-in local Administrator account (RID 500). This change substantially reduces the risk previously associated with local-administrator credential abuse that was common on Windows XP. Administrative shares have also served as a preferred propagation channel for numerous malware families; Conficker, Shamoon, WannaCry, NotPetya, and the North Korean tooling employed in the Sony Pictures intrusion all either enumerated existing shares or created new ones to facilitate lateral movement.

Detection opportunities exist on both source and destination systems. When Kerberos authentication is used, accessing an administrative share on a remote host generates a distinct—and more limited—sequence of events than a local interactive logon. If the client does not already hold a valid Ticket-Granting Ticket, one is requested first, recorded as Event ID 4768. The client then requests a service ticket—Event ID 4769—for the Service Principal Name (SPN) of the target host itself (typically the CIFS SPN, e.g., cifs/targethost.domain.com), not for the domain controller or for any workstation the user happens to be sitting at. This service ticket is what the client presents to authenticate the SMB session against the target's Admin, C, or IPC$ share.

On the destination (target) host, this authentication surfaces as a network logon—Event ID 4624, Logon Type 3. When the SMB session is torn down, Event ID 4634 (Logon Type 3) may follow on the same destination host; the two events can be correlated by their shared Logon ID. Note that 4768 and 4769 are always logged on the domain controller regardless of where the client or target reside, since the DC is the ticket-issuing authority—investigators should not expect a corresponding 4624 on the DC itself unless the DC is the actual target of the share access. It should also be noted that access to a remote file share frequently produces multiple short-duration SMB connections to the hosting system; this is expected behavior and bears no direct quantitative relationship to the number of files examined or the duration of content review. Where NTLM authentication is used instead of Kerberos—common when the target is addressed by IP rather than hostname, or in workgroup/non-domain scenarios—this ticket sequence does not apply at all. In that case, investigators should instead expect Event ID 4776 (credential validation) on the domain controller or local target, alongside the 4624 Logon Type 3 on the destination host.

When object-access auditing is enabled and appropriately scoped to the relevant shares or files, additional events are generated. On the accessed system, Event ID 5140 (A network share object was accessed) records each share interaction and supplies both the account name and the source network address of the accessing principal.

Anomalously elevated volumes of remote access originating from a single account—manifested as Event ID 4624 Logon Type 3 (Network) events—constitute a high-fidelity indicator that the account has been compromised and is being employed for lateral movement. The LogonTracer utility facilitates this analysis by generating statistical summaries of account and host activity and by rendering interactive graph visualizations that surface anomalous communication patterns. Once an account is assessed as compromised or otherwise suspicious, the PowerShell Get-WinEvent cmdlet, leveraging the -FilterXml parameter, can be employed to systematically retrieve all related event-log records across the enterprise. This approach enables precise quantification of the scope of malicious activity and identification of additional systems that may retain residual adversary artifacts.

In environments where workstation logons by administrative accounts are atypical (the majority of users operating under standard domain-user privileges), systematic examination of Event ID 4672 (Special privileges assigned to new logon) on workstations can reveal the illicit use of privileged credentials. Complementary scrutiny of Event ID 4776 (The domain controller attempted to validate the credentials for an account) on clients and member servers may expose attempts to leverage local accounts in order to circumvent domain authentication controls.

File-system timeline analysis can subsequently isolate files created or modified during periods of share utilization. Where network monitoring is available, SMB—being a well-documented and, in most enterprise deployments, unencrypted protocol—permits highly effective session reconstruction through network forensic techniques. Zeek (formerly Bro) parses SMB protocol traffic and records detailed telemetry across multiple log streams, including smb_cmd.log, smb_files.log, and smb_mapping.log. These artifacts can be leveraged to reconstruct and detect malicious SMB activity when traditional event-log sources are deficient.

PsExec

PsExec, developed by Microsoft Sysinternals, was conceived as a lightweight remote-administration utility. Its functionality encompasses non-interactive code deployment and execution, the extension of native system commands to remote-capable operation via return-channel data transmission to the originating host, and—most forensically significant—interactive console session establishment (i.e., spawning a cmd.exe shell on the remote target). The interactive mode substantially enlarges the tool’s forensic footprint, as it requires execution as a Windows service and the creation of named-pipe inter-process communication channels. A representative invocation appears as follows: 

psexec.exe \\host -u user -accepteula -d -c c:\temp\evil.exe

(where -d instructs the utility not to await process termination and -c copies the specified binary to the remote system).

Source System Artifacts

PsExec is employed with comparable frequency for legitimate administrative operations (such as distributing hotfixes) and for malicious activity. The incident responder’s challenge therefore lies in differentiating the two through careful artifact analysis. Fortunately, the tool generates a rich set of forensic evidence. In environments where PsExec is uncommon, application-execution artifacts constitute high-value indicators. Prefetch, ShimCache, BAM/DAM, and AmCache all record execution of PSEXEC.EXE on the source system.

A distinctive characteristic of the Sysinternals suite is the mandatory acceptance of an End-User License Agreement (EULA). This requirement renders the tools particularly conspicuous, as few malicious binaries demand explicit EULA acknowledgment. Upon first acceptance of the PsExec EULA on the source system, the registry value NTUSER\Software\SysInternals\PsExec\EulaAccepted is created where it sets the EulaAccepted value to 1. This key is named PsExec even if the attacker named the tool something else in an attempt to conceal its execution. The key is not subsequently deleted, and its last-write timestamp provides a reliable temporal marker of at least one execution by the associated user account.

While PsExec produces substantial event-log activity, the majority of these events appear on the destination host. An important exception occurs when explicit credentials are supplied: Event ID 4648 (A logon was attempted using explicit credentials) is recorded on the source system. In enterprises that have enabled command-line auditing within process-tracking events, the complete command line issued to PsExec becomes available to investigators on the source host's event log.

Finally, running process enumeration and memory forensic analysis represent a further avenue for detection, mirroring the execution-artifact methodology above—analysts should search for active PSEXEC.EXE processes. Note, however, that adversaries frequently rename the PsExec binary to evade signature- and name-based detection, necessitating supplementary detection logic (e.g., hash-based identification or behavioral indicators such as named pipe creation patterns).

Destination (Target) System Artifacts

PsExec execution against a remote host proceeds through a multi-stage operational sequence. Authentication to the destination system is first established, following which named pipes are established as inter-process communication channels between source and destination. The ADMIN$ share is then mounted, and PSEXESVC.EXE (together with any additional binaries specified for remote execution) is copied into the Windows directory by default. Finally, a Windows service is installed and started, resulting in execution of the copied files. This sequence generates substantial event-log activity on the destination host.

Authentication occurs under the context of the currently logged-on user by default and produces Event ID 4624 with Logon Type 3 (Network). When the attacker supplies alternate credentials via the -u option, the resulting authentication event is recorded as Event ID 4624 with Logon Type 2 (Interactive). In the latter case, a user profile is created unless the -e (do not load profile) argument is supplied, but since the attacker may omit that switch, checking for the presence of unusual user profiles can be a useful indicator of unauthorized activity. When the session ends, you may see an event 7036 in the System event log showing the PSEXESVC service entering a stopped state. Interactive (Type 2) logons cause the account’s security token to remain available in memory—an operational risk even for legitimate administrative use of the tool. Because PsExec mounts the ADMIN$ share, Event ID 5140 (A network share object was accessed) may also be generated. Service creation, start, and stop operations further populate the System event log with multiple records, including Event ID 7045 (A service was installed in the system). The staged executable may be uploaded under a randomly generated or explicitly specified filename; alternatively, the Service File Name may consist of a PowerShell invocation containing a lengthy Base64-encoded command. When auditing is appropriately configured, Event ID 4697 is additionally recorded in the Security event log, documenting the installation of the service on the destination system.

By default, the Sysinternals version of psexec will also install itself as a service with a service name of PSEXESVC and an associated executable of psexesvc.exe written to the destination Windows directory, making it easy to spot in the 7045 System event log records (and possibly Event ID 4697 in the Security event log if enabled). [However, the name of the service and its associated executable can be changed to any arbitrary name using the -r switch when psexec is run]. When the -c switch is employed to stage a binary that does not already exist on the target, that binary is likewise transferred. Both actions create recoverable file-system artifacts whose MACB (Modified, Accessed, Changed, Birth) timestamps can be correlated with the appearance of PSEXESVC.EXE. An executable or batch file created in close temporal proximity to PSEXESVC.EXE is highly likely to be related. Investigators should note that the -c option permits placement of binaries at arbitrary locations within the file system; absent command-line capture, additional artifacts may be required to determine precisely what was executed.

Application-execution artifacts for PSEXESVC.EXE are recorded on the destination. A useful mnemonic is that the binary name differs between source (psexec.exe) and destination (psexesvc.exe—note the absence of the letter “c”). Service creation produces a readily identifiable registry key at SYSTEM\CurrentControlSet\Services\PSEXESVC. This key may or may not persist post-session, as it is occasionally purged upon session termination; however, deleted registry keys remain recoverable through forensic techniques. Notably, the Metasploit implementation of PsExec substitutes a randomly generated service name in place of the default PSEXESVC string, which itself functions as a high-confidence indicator of malicious tooling.

By default, PsExec creates a user profile on the destination host unless one already exists or the -e (suppress profile creation) option is specified. The creation timestamp of the profile directory and its associated NTUSER.DAT hive, therefore, serves as an additional temporal indicator of PsExec activity.

Live process and memory analysis can further reveal residual PsExeSvc activity. Named pipes used for inter-process communication are visible through process handles and yield useful metadata, including the source hostname. Representative pipe names include:

• \\10.10.2.20\pipe\PSEXESVC-<sourcehostname>-<PID>-stdin
• \\10.10.2.20\pipe\PSEXESVC-<sourcehostname>-<PID>-stdout
• \\10.10.2.20\pipe\PSEXESVC-<sourcehostname>-<PID>-stderr

It is critical to recognize that many of the foregoing artifacts assume the default service and binary name PSEXESVC. Newer versions of PsExec introduce the -r option, permitting an adversary to substitute an arbitrary name. When this option is employed, the executable name, associated execution artifacts, service name, and named-pipe nomenclature all reflect the attacker-supplied value. While the volume of artifacts remains undiminished, the renamed components may evade detection filters that rely exclusively on the default identifiers.

Several alternative utilities implement variations of the PsExec remote-execution model, including CSExec, PAExec, and RemCom. Detection of the associated malicious services can be pursued through examination of Event ID 7045 (A service was installed in the system) and Event ID 7036 (A service entered the running/stopped state) within the System event log, as well as Event ID 4697 (A service was installed in the system) within the Security event log.

Windows Remote Management Tools 

Numerous native Windows commands possess remote-execution capabilities. Once an adversary obtains credentials sufficient for remote authentication—Domain Administrator privileges being the preferred acquisition—a broad spectrum of lateral actions becomes available across the enterprise. These utilities are especially valued by threat actors because they enable a “living-off-the-land” approach, allowing objectives to be achieved with minimal or no introduction of external tooling. The resulting reduction in attack-surface footprint frequently complicates detection.

Among the most commonly observed remote commands employed for lateral movement are those that create and start remote services and those that schedule remote tasks. Both artifact classes are standard fixtures in Windows-based incident response and command-execution forensics, given the several methods available for remote command execution on Windows systems and their exploitability by attackers.

Remote Service Creation and Execution

Services constitute a frequent mechanism for the remote execution of binaries and, when required, the establishment of persistence. They nevertheless generate high-value forensic artifacts. Service definitions are recorded in the registry and explicitly reference the binary path that was executed. Although adversaries may subsequently delete the service in an attempt to erase evidence, deleted registry keys frequently remain recoverable. In addition, the System event log contains extensive service-related telemetry.

sc \\host create servicename binpath= "c:\temp\malware.exe"
sc \\host start servicename

Remote Task Scheduling

Tasks may be scheduled either locally or remotely and can be configured to execute under any user context for which valid credentials are known. Scheduled tasks leave distinctive artifacts, including .job files that document both the scheduled action and the account that created it, together with comparatively robust event-log evidence.

at \\host 13:00 "c:\temp\evil.exe"
schtasks /CREATE /TN taskname /TR c:\evil.exe /SC once /RU "SYSTEM" /ST 13:00 /S host /U user

Remote Registry Interaction

The Windows registry represents a manipulable artifact space for a wide range of malicious purposes, and a native utility (reg.exe) exists to perform such operations remotely. Successful exploitation requires that the Remote Registry service be running on the target host, with prior authentication to the system already established, as reg.exe provides no native mechanism for supplying credentials. Adversaries therefore frequently mount an administrative share beforehand to establish the necessary authentication context. From an examination standpoint, Registry key last-write timestamps remain among the most reliable indicators of remote registry activity available to the investigator.

reg add \\host\HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v Data /t REG_SZ /d "C:\evil.exe"

Arbitrary Remote Command Execution via Windows Remote Shell

Windows Remote Shell (winrs), introduced with Windows Server 2008, is comparatively more obscure than WMIC or PowerShell yet remains an effective execution vector. When the Windows Remote Management (WinRM) service is enabled, winrs can execute any arbitrary command over encrypted-by-default traffic. Its functionality parallels that of PsExec, while frequently traversing host-based firewalls in scenarios where PsExec is blocked—provided WinRM is active in the environment. In certain intrusions, adversaries explicitly enable the WinRM service to achieve their objectives; consequently, the unexpected presence of this service may itself constitute an indicator of compromise. Execution of winrs further results in the instantiation of the winrshost.exe process on the remote system.

winrs –r:host –u:user command

All of the foregoing remote-command techniques may leave residual process artifacts in memory as well as application-execution artifacts on disk, including Windows Prefetch entries. Network forensic analysis can reconstruct a substantial portion of this activity; remote scheduled-task creation, service installation, and registry modifications are particularly amenable to packet-level examination. WinRM traffic generated by winrs constitutes a notable exception: while the presence of the protocol can be identified, the default encryption typically precludes detailed payload analysis.

Windows Remote Management Tools: Remote Services

Remote service operations leave comparatively sparse artifacts on the source system. Although execution of sc.exe is recoverable through application-execution artifacts, the absence of command-line auditing frequently precludes definitive determination of whether the utility targeted a local service or a remote host.

On the destination system, however, a substantially richer evidentiary set is available. Event logs furnish both the authentication context employed and detailed telemetry concerning the services that were created, started, or modified. Event ID 7045 records the installation of a new service and populates several fields of high investigative value.

• User Field: This field identifies the security identifier (SID) of the account that performed the service installation.
• Service Account Field: This field contains the name (not the SID) of the account under which the service is configured to run. The field may be empty for certain service types, such as kernel-mode drivers. Representative values include:
• LocalSystem — LOCAL SYSTEM
• NT AUTHORITY\LocalService — LOCAL SERVICE
• ComputerName\AccountName — local account (e.g., win81\Administrator)
• DomainName\AccountName — domain account (e.g., hqcorp\Andrei)
• Service Name Field: This field records the full display name of the service as presented in the Windows Services management console.
• Service File Name Field: This field captures the complete path and filename of the executable image associated with the newly installed service.
• Service Type Field: This field indicates one of two primary categories:
• user mode service — further subdivided into:
• Shared: a service that shares its process with other services (commonly hosted under svchost.exe)
• Own: a service that executes within its own dedicated process
• Both Shared and Own services may be either interactive (capable of interacting with a user session) or Win32 (non-interactive).
• kernel mode service — further subdivided into:
• Kernel: system driver
• Filesys: filesystem driver
• Rec: specialized filesystem driver responsible for early-boot filesystem version detection
• Event ID 7045 reports only the principal category (user-mode or kernel-mode) and does not enumerate the finer-grained subtypes.
• Service Start Type Field: This field records the configured start mode and may contain one of the following values:
• auto start — service starts automatically with the system
• demand start — service must be started manually
• system start — system driver started during kernel initialization
• boot start — system driver loaded by the boot loader
• disabled — service is disabled

Beginning with Windows 10 and Windows Server 2016, the Security event log records a dedicated event each time a new service is installed on the system. Event ID 4697 (A service was installed in the system) appears under the Task Category “Security System Extension” with the keyword Audit Success. Although Event ID 4697 shares many fields with Event ID 7045, several important differences exist.

• Service Start Type: This field is expressed as an integer rather than a descriptive string. Possible values are:
• 0 – Boot start
• 1 – System start
• 2 – Auto start
• 3 – Demand start
• 4 – Disabled

• Service Type: This field supplies a more granular classification than Event ID 7045, using the following hexadecimal values:
• 0x1 – System driver
• 0x2 – Filesystem driver
• 0x8 – Recognizer driver (specialized filesystem driver responsible for early-boot filesystem version detection)
• 0x10 – Win32 Own process
• 0x20 – Win32 Shared process
• 0x110 – Interactive Own process
• 0x120 – Interactive Shared process

In aggregate, Event ID 4697 furnishes a richer set of service-installation details than the corresponding System-log Event ID 7045.

When an attempt to start/stop a new system service is rejected with an “Access Denied” result due to insufficient privileges, Event ID 4656 (A handle to an object was requested) is recorded in the Security event log under the Task Category “Other Object Access Events” with the keyword Audit Failure. This event reflects a failed object-handle request directed at the Service Control Manager (SCM). The SCM is the system component responsible for all service-related operations; it maintains an internal service database and mediates start, stop, pause, and configuration actions.

• Object Server identifies the subsystem to which the handle request was addressed (SC Manager).
• Object Type is recorded as SC_MANAGER OBJECT, representing Service Control Manager objects generically.
• Object Name specifies the SCM database targeted by the request. For service-installation attempts, this value is invariably ServicesActive. Other possible values include NULL or the obsolete ServicesFailed. The ServicesActive database enumerates all currently installed system services.
• Process Name is ordinarily C:\Windows\System32\services.exe, the executable that implements the Service Control Manager.

The Accesses field enumerates the specific permissions requested against the ServicesActive database. The corresponding access-mask constants are given in the table below. The Access Mask field contains the hexadecimal sum of all requested access rights.

Access Mask	Constant Value	Description
0x01	%%7168	Connect to service controller
0x02	%%7169	Create a new service
0x04	%%7170	Enumerate services
0x08	%%7171	Lock service database for exclusive access
0x10	%%7172	Query service database lock state
0x20	%%7173	Set last-known-good state of service database
0x40	%%7174	Query service configuration information
0x80	%%7185	Set service configuration information
0x100	%%7186	Query status of service
0x200	%%7187	Enumerate dependencies of service
0x400	%%7188	Start the service
0x800	%%7189	Stop the service
0x1000	%%7190	Pause or continue the service
0x2000	%%7191	Query information from service
0x4000	%%7192	Issue service-specific control commands

Following the successful stop of a system service, Event ID 7036 is recorded in the System event log under the Service Control Manager. The event populates two principal parameters: param1 (which records the full service name) and param2 (which records the resulting service status). param2 may contain one of the following values:

• running
• stopped
• paused

A significant limitation of Event ID 7036 is the absence of a populated User field; the value is recorded as N/A. Consequently, attribution of the account responsible for the state change is not possible from this event alone.

The highest-priority service-related events for continuous monitoring are successful and unsuccessful service-installation records. Services remain one of the most frequently abused persistence and execution mechanisms employed by malware and adversarial tooling. Consequently, every new service installation—particularly on high-value assets such as Active Directory domain controllers or database servers—warrants immediate attention. Equally critical is the detection of service-account modifications that replace a built-in identity (LocalSystem, LocalService, or NetworkService) with a conventional local or domain user account. When a service executes under a standard user context, its credentials become recoverable by any process possessing administrative privileges, thereby elevating credential-exposure risk.

Recommended Monitoring Targets

• Windows 10 / Windows Server 2016 and later – All Event ID 4697 (A service was installed in the system) events on high-value and critical hosts. – Event ID 4697 events in which the Service Account field is not one of the following built-in identities: LocalSystem, NT AUTHORITY\LocalService, or NT AUTHORITY\NetworkService.
• All supported Windows versions – All Event ID 7045 events in the System event log on high-value and critical hosts. – Event ID 7045 events in which the Service Account (AccountName) field is not LocalSystem, NT AUTHORITY\LocalService, or NT AUTHORITY\NetworkService.
• Failed service-installation attempts – Event ID 4656 (A handle to an object was requested) Audit Failure events whose Object Server field equals “SC Manager” and whose Access Mask equals 0x3 (Connect + Create Service).

Service start and stop operations may be monitored on a selective basis. For example, to detect the intentional disablement of Windows Defender, System Event ID 7036 may be filtered for param1 = “Windows Defender Service” and param2 = “stopped.” Monitoring of unsuccessful service-stop attempts is optional because of the high volume of benign false-positive events typically generated.

When a newly introduced executable or dynamic-link library is leveraged to instantiate a service, the corresponding file-creation events and subsequent application-execution artifacts become recoverable and provide additional temporal and attributional context.

Windows Remote Management Tools: Scheduled Tasks

Scheduled task abuse (commonly MITRE ATT&CK T1053.005) for lateral movement or persistence leaves extensive forensic residue, especially on the destination system.

Source System Artifacts

• Standard process-execution artifacts for schtasks.exe or the legacy at.exe (Prefetch, Amcache, Shimcache, UserAssist, SRUM, etc.).
• Explicit credential use often generates Security Event ID 4648 (“A logon was attempted using explicit credentials”). This is common when the attacker supplies alternate credentials (via /U /P switches, runas, or tools that perform a similar operation).

Destination System Artifacts

As with most lateral movement techniques we have covered thus far, event logs on the destination system can be incredibly useful for identifying malicious activity.

1. Authentication / Logon Events

• Security Event ID 4624 (Logon Type 3 – Network) immediately preceding task-related activity.
• Event ID 4672 (special privileges assigned) when the account has administrative rights. These show which accounts were abused and from which source host/IP.

2. Security Log – Task Management Events

These require the “Audit Other Object Access Events” (or the older “Audit Object Access”) policy to be enabled:

• 4698 – A scheduled task was created
• 4699 – A scheduled task was deleted
• 4700 – A scheduled task was enabled
• 4701 – A scheduled task was disabled
• 4702 – A scheduled task was updated

3. Dedicated Task Scheduler Operational Log

Location: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational.evtx

This operational channel is not enabled by default on many modern versions of Windows. It must be explicitly activated via Event Viewer (Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational → Enable Log) or by executing:

wevtutil sl Microsoft-Windows-TaskScheduler/Operational /e:true

Once enabled, the log captures high-fidelity records of the full scheduled-task lifecycle. These events are of significant forensic value because they frequently persist longer than Security log entries, do not rely on the more restrictive “Audit Other Object Access Events” policy, and provide direct evidence of task registration, modification, deletion, and execution—critical for detecting both persistence and remote lateral movement via scheduled tasks. Key Event IDs of forensic significance include:

• 106 – Task registration (creation)
• 140 – Task modification
• 141 – Task deletion
• 200 – Task execution initiated (frequently records the full path of the executed action)
• 201 – Task execution completed

4. On-Disk Task Definition Files

The XML task definition files in %SystemRoot%\System32\Tasks are one of the highest-value artifacts on the destination system. When a task is created with schtasks.exe (or the Task Scheduler COM API / PowerShell Register-ScheduledTask), Windows writes a corresponding XML file that has the exact same name as the task and no file extension. These files are plain text XML and contain the complete task definition.

XML Section	Useful Field(s)	What it reveals
RegistrationInfo	Author	Account (and often the originating host) that registered the task
	Date	Local system time when the task was created/registered
Principals	UserId (or GroupId)	Security context the task will run under (e.g., SYSTEM, a domain user, or a local account)
Triggers	Various	Schedule type (Once, Daily, At logon, On event, etc.), start time, repetition, etc.
Actions	Exec → Command + Arguments	Exact program/script that will be executed and its command-line arguments

Practical notes for investigators

• The Author field is especially useful in lateral-movement cases. When the task is created remotely, it frequently contains the remote hostname or the account used for the remote connection (e.g., DOMAIN\Administrator or HOSTNAME\user).
• The Date field is recorded in the local time of the target system (usually ISO 8601 format with timezone offset).
• Even if an attacker later deletes the task via schtasks /delete or the GUI, the XML file is sometimes left behind or recoverable from Volume Shadow Copies / $MFT.
• If the XML file itself has been deleted, check the registry keys under:
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks.
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree.
  •  These often retain metadata even after the on-disk XML is removed.

5. Registry Artifacts

The registry under TaskCache is a critical complementary source to the XML files in C:\Windows\System32\Tasks. Even when attackers delete the on-disk XML, the registry entries frequently survive and can be used to reconstruct the task.

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks: This key holds one subkey per scheduled task. Each subkey is named with the task’s GUID, for example {0017043B-B863-4092-B894-6330CAA84DE9}. Under each GUID key you will typically find these values:

Value Name	Type	Meaning
Path	REG_SZ	Task path as seen in Task Scheduler (e.g. \MyMaliciousTask or \Microsoft\Windows\...)
Hash	REG_BINARY	Hash of the task definition
Triggers	REG_BINARY	Serialized trigger information
Actions	REG_BINARY	Serialized action information (what actually runs)
DynamicInfo	REG_BINARY	Runtime data (last run time, number of times run, etc.)
Author	(sometimes present)	Account that created the task
Others	varies	Additional metadata

The Path value is especially useful because it tells you the logical name/location of the task, which you can then match to the corresponding XML file (if it still exists) or to the Tree structure.

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree: This key mirrors the hierarchical folder structure that you see in the Task Scheduler GUI.
• Subkeys under \Tree represent folders and individual tasks.
• Each task entry under Tree contains an Id value (REG_SZ or REG_BINARY depending on Windows version) that holds the same GUID used under the \Tasks key.
• Using that GUID, you jump back to the corresponding key under \Tasks to retrieve the full settings.

This two-way link (Tree → GUID → Tasks) is how the Task Scheduler service locates and loads task definitions.

DF\IR Investigative Notes

• Deleted tasks: If an attacker removes the XML file from System32\Tasks but does not clean the registry, the GUID keys under \Tasks and the entries under \Tree often remain. These are valuable recovery sources. Deleted tasks may still leave recoverable data here (or in Volume Shadow Copies / memory).
• Hiding techniques: Some malware (e.g., Tarrask) deletes the SD (Security Descriptor) value under the Tree key. This can cause the task to disappear from schtasks /query and the GUI while still existing and executing.
• Parsing binary values: The Triggers and Actions values are binary blobs. Tools such as Eric Zimmerman’s Registry Explorer, or specialized parsers, can decode them. Alternatively, if the original XML still exists, it is far easier to read.
• Correlation workflow:
  1. Look under \Tree for suspicious task names or recently modified keys.
  2. Read the Id value → obtain the GUID.
  3. Open the matching GUID key under \Tasks.
  4. Check the Path, timestamps, and (if possible) decode Actions.
  5. Cross-reference with event logs (4698/106, etc.) and the XML file if present.

These registry artifacts, together with the XML files and the event logs previously discussed, give a robust multi-source view of scheduled-task activity on the system.

6. Application Execution Artifacts

• Prefetch – Records execution times for when the payload is executed.
• ShimCache – Records evidence of executable execution, including references to malicious binaries such as evil.exe.
• AmCache.hve – Tracks first-time execution of programs. Entries for malicious executables can establish the earliest observed execution timestamp of the payload launched by a scheduled task.

Practical Investigative Notes

• Correlate a Type 3 logon (4624) with a nearby 4698 / 106 event—this is a strong lateral-movement indicator.
• Always examine the actual task XML or the “Task Content” field in the event; names are frequently chosen to look legitimate (“WindowsUpdate”, “SystemMaintenance”, etc.).
• Look for tasks that run as SYSTEM, point to user-writable paths (%TEMP%, C:\Users\Public, C:\ProgramData), or contain encoded/obfuscated commands.
• Baseline normal scheduled tasks in your environment; anomalies become obvious once you know what belongs.

WMI Lateral Movement Artifacts

WMI (Windows Management Instrumentation) provides a flexible remote and local management framework that adversaries frequently abuse for lateral movement and execution. While PowerShell can leverage WMI, the infrastructure can also be used independently. Sophisticated attackers increasingly favor WMI (and PowerShell) because it often generates fewer traditional forensic artifacts than tools such as PsExec—most notably, no service is created. The most common WMI technique for lateral movement is the process call create method, which allows remote process execution. Example commands include:

cmd

wmic /node:host /user:user process call create "c:\temp\evil.exe"

PowerShell

Invoke-WmiMethod –ComputerName host –Class Win32_Process –Name Create –ArgumentList "C:\evil.exe"

WMI traffic is typically unencrypted unless conducted over WinRM (Windows Remote Management). Network forensics can therefore be valuable for detecting and tracking its use.

Source System Artifacts

Source systems retain relatively few records of WMI activity. Application execution artifacts for wmic.exe (or powershell.exe when using cmdlets) provide an initial indicator. Enabling command-line auditing through process creation events (Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Detailed Tracking) is essential for detecting malicious use of WMIC.

• Security Event ID 4688 (Process Creation) — When the “Include command line in process creation events” policy is enabled, this event records the full command line of wmic.exe (or related processes). This reveals the remote target (/node:), credentials used, and the exact process creation command (e.g., process call create "c:\temp\evil.exe").
• Sysmon Event ID 1 (Process Creation)—Provides equivalent or superior detail, including the complete command line, parent process, hashes, and other contextual fields, making it highly effective for identifying suspicious WMIC activity.

Without command-line logging, process creation events only show that wmic.exe executed, offering limited investigative value. With it enabled, analysts can reconstruct the full remote execution attempt and correlate activity between source and destination systems.

Destination System Artifacts

Artifacts on the destination system are significantly more useful for detection and investigation:

• Authentication events—Security Event ID 4624 (Logon Type 3 – Network) showing the account used for the remote WMI connection.
• Process creation—The launched payload commonly appears with WmiPrvSE.exe (WMI Provider Host) as the parent process. This parent-child relationship is a high-fidelity detection opportunity. Because WMI leaves a comparatively light footprint, enabling detailed process creation logging, monitor for WmiPrvSE.exe as a parent of unusual child processes
• Sysmon can be configured to monitor WMI permanent event subscription activity, which is a common persistence technique:
• Event ID 19 – WmiEventFilter activity
• Event ID 20 – WmiEventConsumer activity
• Event ID 21 – WmiEventConsumerToFilter activity
• These events provide visibility into the creation and binding of WMI event filters and consumers.
• WMI-Activity Operational Log (Microsoft-Windows-WMI-Activity/Operational) — In addition to Sysmon, the %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx log records detailed WMI operations, including provider loading and method execution. Event IDs 5860 and 5861 record details of event consumers. Analysts should review these events for encoded PowerShell commands, unusual scripts, or other suspicious content that may indicate malicious WMI usage.
• Tools such as Sysinternals Autoruns (WMI tab) can enumerate existing WMI event subscriptions and help identify persistence mechanisms that leverage WMI filters and consumers.
• Additional supporting evidence may appear in DCOM-related logs and standard application execution artifacts (Prefetch, AmCache, ShimCache) for the executed payload.

WMI permanent event subscriptions can be queried on a live system using PowerShell. The Kansa framework is particularly effective for this purpose, as it supports the collection and stacking of results across multiple systems for comparative analysis. PowerShell scripts can also be used to generate real-time notifications of WMI activity, which can be forwarded to a SIEM for enhanced detection.

On an offline forensic image, WMI subscriptions are stored in the WMI repository at %SystemRoot%\wbem\Repository. This database can be parsed using the open-source python-cim tool to extract event filters, consumers, and binding information.

PowerShell Remoting

PowerShell is a scripting engine with native access to WMI (and considerably more), making it a persistent object of interest during host and network examinations. PowerShell remoting, built atop the WinRM protocol, allows an adversary to scale a single-host action into an enterprise-wide operation with minimal friction. From an evidentiary standpoint, deploying a credential-dumping utility against one endpoint is nearly indistinguishable in effort from deploying it against a thousand—a fact examiners should bear in mind when scoping the blast radius of an intrusion. Remoting must be enabled to scale in this fashion, and increasingly it already is: Windows Server builds from Server 2012 onward ship with it enabled by default, which examiners should treat as a standing precondition rather than a notable finding on its own.

The two commands most frequently correlated with lateral-movement activity in casework are Invoke-Command and Enter-PSSession. The latter establishes an encrypted interactive session to the remote host, functionally analogous to an SSH shell—and forensically, it should be treated with the same evidentiary weight as any remote-access artifact.

Invoke-Command –ComputerName host –ScriptBlock {Start-Process c:\temp\evil.exe}
Enter-PSSession –ComputerName host –Credential user

Source System Artifacts

As with WMI-based tradecraft, reconstructing PowerShell activity from artifacts alone can be an uphill task for the examiner. On the source host, begin by establishing whether powershell.exe was executed at all—execution artifacts such as Prefetch and ShimCache serve as corroborating evidence of execution, even absent direct logging. 

Event log data is the examiner's primary evidentiary source here, and PowerShell version 5 (native to Windows 10 and later) finally provides logging robust enough to reconstruct activity with confidence. Process creation and command-line auditing — Security Event ID 4688 (with command-line logging enabled) or Sysmon Event ID 1 are indispensable to reconstructing the majority of WMI- and PowerShell-based intrusions; instrumenting this capability before an incident occurs is arguably the single highest-value detective control an organization can field. Fortunately, PowerShell version 5 also introduces a console history artifact — ConsoleHost_history.txt located at %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt— which retains the last 4,096 commands entered per user on the source host, offering a durable record independent of the event log. You can confirm the location on a system by running the Get-PSReadLineOption cmdlet and checking the HistorySavePath. The MaximumHistoryCount will show the number of lines that will be stored in the ConsoleHost_history.txt file before it starts overwriting older entries (the default is 4096). This can provide a great source of information regarding PowerShell use.

 The Microsoft-Windows-PowerShell/Operational log, resident on the source host at the path %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx, is the principal artifact for identifying local PowerShell sessions. 

Event ID	Description	Forensic Value
40961	PowerShell console / engine starting	Records the local initiation of powershell.exe and the associated user account. Useful for establishing when a PowerShell session began.
40962	PowerShell console / engine stopping	Records the termination of a PowerShell session. Helps determine session duration when correlated with 40961.
8193	Session created	Indicates creation of a PowerShell session.
8194	Session connected	Records that a session was successfully connected.
8197	Session closed	Indicates that a PowerShell session was closed.

Microsoft-Windows-WinRM/Operational, located at the path %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-WinRM%4Operational.evtx, meanwhile, provides the evidentiary trail for remote PowerShell activity—including the destination hostname, IP address, and the account under which the session executed. 

Event ID	Description	Key Details Recorded	Forensic Value
6	WSMan Session Initialization	Session created, Destination hostname or IP, currently logged-on user name	Strong indicator of outbound WinRM/PowerShell Remoting activity. Identifies the remote target and the interactive user on the source system.
8, 15, 16, 33	WSMan Session Deinitialization	Closing of WSMan session, Currently logged-on user name	Marks the end of a remote session. Useful for determining session duration when correlated with Event ID 6.

These events are generated on the source system during PowerShell Remoting or other WinRM-based activity. Event ID 6 is a strong indicator of outbound remote management activity and should be correlated with process creation logs for powershell.exe and corresponding events on the destination system (such as Event ID 91).

Finally, in environments where remote management is not used for routine administration, the examiner holds a modest advantage: enumerating hosts with the Windows Remote Management (WS-Management) service enabled can itself serve as a triage artifact, surfacing systems an adversary may have traversed. The principal complication in either case is that these same tools are heavily used for legitimate administration, which muddies the signal-to-noise ratio considerably. Even so, with adequate logging coverage, malicious activity tends to stand apart on close examination—legitimate administrators, for instance, rarely invoke wmic process call create or execute encoded PowerShell payloads. As with most incident response work, the examiner's first instinct should be to hunt the anomaly, not the tool.

Destination System Artifacts

When examining a target—that is, destination—system implicated in a suspected PowerShell-based intrusion, the examiner should first establish whether wsmprovhost.exe execution is present on the host. This process is the receiving-end artifact of a PowerShell remoting session, and its evidentiary value is environment-dependent: in some populations it is a rare and highly probative finding, in others it is ambient background noise that must be baselined before it can be trusted as an indicator. Beyond process execution, PowerShell is frequently leveraged to stage and execute arbitrary binaries on the destination host, so anomalous file-creation events and unexplained application-execution artifacts can serve as corroborating evidence even where direct PowerShell logging is absent.

Event logging remains, by a considerable margin, the examiner's most reliable instrument for reconstructing PowerShell activity. Version 5 substantially expanded the evidentiary yield available on both the source and destination sides of a remoting session. Expect to find Type 3 (network) logon events on the destination host, documenting the account authentication that necessarily precedes remoting activity—these serve as a useful cross-reference against the PowerShell-specific artifacts. 

Microsoft has significantly expanded PowerShell logging capabilities to help detect malicious use. These logging features must be enabled via Group Policy at Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell. Three primary categories of logging are available (depending on the Windows / PowerShell version):

• Module Logging records pipeline execution events and writes them to the event logs.
• Script Block Logging captures de-obfuscated PowerShell commands as they are sent to the engine. Records the commands only (not the resulting output). Writes entries to the event logs.
• Transcription captures both PowerShell input and output. Does not capture the output of external programs launched from PowerShell. Writes logs to text files on disk.

Once enabled, these facilities can provide extensive visibility into PowerShell activity. In environments that run large volumes of legitimate PowerShell scripts, the resulting data volume can be substantial. Thorough testing and tuning are recommended before production deployment to balance visibility against performance and storage impact. Script block logging can recover the full contents of what was executed via PowerShell, and scripts invoking blocklisted cmdlets are logged automatically regardless of local policy. This artifact resides in the Microsoft-Windows-PowerShell/Operational log on the destination system and should be treated as a primary source in any PowerShell-centric examination. Key Event IDs are given below.

 

Event ID	Description	Forensic Value
4103	Module / Pipeline logging	Records module and cmdlet execution details.
4104	Script Block Logging	Highest value. Logs the content of script blocks. In PowerShell v5, suspicious scripts are logged by default; all scripts can be logged if fully configured. Frequently captures the full commands or scripts executed during a remote session. Full details are typically logged only on first use to conserve space. Events appear at the “Warning” level when Microsoft classifies the activity as suspicious.
53504	Authenticating user recorded	Identifies the user account associated with the PowerShell activity.

Script Block Logging (4104) can be configured to log all script blocks or only those flagged as suspicious. Even with partial logging, it frequently captures attacker activity that would otherwise be invisible. Additional entries are located in the legacy %SystemRoot%\System32\winevt\Logs\Windows PowerShell log, as follows:

Event ID	Description	Forensic Value
400 / 403	Engine state change	Presence of ServerRemoteHost indicates the start or end of a PowerShell remoting session. The hostname field indicates whether the activity was local (console) or remote.
800	Pipeline execution details	Records the UserID (account used) and Hostname (local vs. remote). The HostApplication field should be examined for Base64-encoded commands, commonly indicated by the -enc or -EncodedCommand switch.

Process-creation tracking and command-line auditing (Security Event ID 4688, or Sysmon Event ID 1) — not enabled by default, and therefore not guaranteed to be present in a given evidentiary set — can, where configured, capture every PowerShell command executed on the host.

Of the major shifts in attacker tradecraft, the widespread adoption of PowerShell is among the most significant. It offers nearly unlimited capability while often blending into legitimate administrative activity. Most organizations have not yet invested the logging and detection engineering necessary to render anomalous usage visible. Comprehensive logging—particularly Script Block Logging (Event ID 4104) and command-line process creation auditing—remains the most effective defense against this stealthy and powerful attack vector.

The Microsoft-Windows-WinRM/Operational Log is also recorded in the destination system. Event ID 91 records the creation of a WinRM session. This event is generated when an inbound PowerShell Remoting connection (or other WinRM-based remote management activity) is successfully established. It serves as a primary indicator that a remote session was initiated against the system. Event ID 169 records the authenticating user associated with the WinRM session. This provides the account name used to authenticate the remote connection, which is critical for identifying the compromised or abused credentials involved in the activity. Together, these two events help confirm that a remote PowerShell or WinRM session occurred and identify the account under which it was authenticated. They should be correlated with Security Event ID 4624 (Logon Type 3) and PowerShell Script Block Logging events (particularly 4104) for a more complete picture of the remote activity.

Event ID	Location	Description	Forensic Value
6	Source system	Creating WSMan Session	Shows an outbound WinRM connection attempt. Includes the remote host connection string (hostname/IP and PSVersion).
91	Destination system	Creating WSMan shell / session	Indicates an inbound remote WinRM session was established. Often includes the authenticating username. Strong indicator of remote PowerShell activity.
169	Destination system	User authentication succeeded	Confirms successful authentication for a WinRM session and records the account used.
8, 15, 16, 31, 33	Both	Session lifecycle events (close command, close shell, close session, etc.)	Help establish the start and end of remote sessions.
224	Either	WinRM listener or firewall exception created	Useful for detecting when PowerShell Remoting is being enabled (Enable-PSRemoting).

Bear in mind that PowerShell remoting is transported over WinRM, and consequently the same detection methodology applicable to WinRM activity extends directly to PowerShell remoting—the examiner need not treat these as separate evidentiary categories. It is also worth noting, for anyone attempting content-based inspection of captured traffic, that regardless of whether the underlying WinRM transport is HTTP or HTTPS, PowerShell encrypts all remoting command traffic with AES-256 following initial authentication — meaning payload visibility at the network layer is foreclosed past that point, and examiners should not expect to recover command content from a packet capture alone.