MDR insights: Tracking lateral movement in a Windows environment (part 2)

Data & research · 5 MIN READ · BRANDON OVERSTREET · MAR 28, 2025 · TAGS: Get technical / Guidance / SOC

TL;DR 

• This is part two of a blog series focusing on tracking lateral movement using Windows event logs (part one is here)
• The blog is designed to be used as a quick reference to aid in lateral movement investigations
• These event logs are specific to Windows systems and provide a summary of key indicators to watch for when investigating potential lateral movement activities

As discussed in Tracking lateral movement in a Windows environment (part 1), we highlighted where event logs are stored, parsing Windows event logs, and details specific to logs used to investigate six common lateral movement techniques. 

We know that attackers often move laterally through environments to achieve their final objectives. This series is designed to guide you on how to respond to such behaviors from threat actors. Here are four more techniques you might encounter when responding to lateral movement in a Windows environment.

Technique 1: Distributed Command Object Model (DCOM)

Lateral movement via Distributed Command Object Model (DCOM) is a technique used by attackers after gaining access to a system. According to Microsoft, typically only administrators can remotely activate and launch Command Object Model (COM) objects using DCOM. DCOM is a Windows feature that allows software components to interact across the network via remote procedure calls (RPCs). The ability to interact across the network via RPCs, coupled with administrative account privileges, makes it easy for attackers to interact with and move around the network and control systems remotely.

 In Security.evtx logs, look for the following event IDs: 

• 4688 – New process creation (log not enabled by default)
• 4624 – Logon type 3 
  • This represents a successful network login, indicating that a user or computer accessed a system remotely over the network.
• 4672 – Elevated or admin rights granted at logon
• 5140 – Network share object accessed (log not enabled by default)
  • This event log provides information on the account, source IP address, and the network share accessed. It logs the first access attempt during the login session.
• 5145 – Network share object was checked to determine if the source endpoint can be granted the desired permissions

After seeing the type 3 logon, look for evidence of process creation—svchost.exe launching with the argument “-k DcomLaunch” and a socket listening on network ports typically greater than 49152, as this can indicate DCOM abuse when it’s the parent of subsequent suspicious process events. 

Here’s an example of this relationship:

The process relationship outlines how the various processes are initiated on the victim host, in the context of DCOM lateral movement.

Technique 2: Netsh portproxy

Attackers can use netsh portproxy to create a local port forwarding rule. The network shell, called netsh, is a Windows command line tool used to view and modify the network configurations of a system. Note that Windows firewall logs like this one aren’t enabled by default, though—but when they are, they’re great port proxy changes. In security.evtx logs, look for the following event IDs when looking for evidence of lateral movement related to firewall connections:

• 5156 – Permitted connection
  • This event ID is logged by the Windows Filtering Platform (WFP) when connections are permitted and provides details about the process, application, and network parameters involved. Review this log to reveal unexpected or malicious connections that could be part of a lateral movement attempt. 
  • The log gives us insights into:
    • The connection direction (whether the connection is inbound or outbound) 
    • Source address (where the connection was initiated)
    • Destination address (where the connection was made)
    • Application name (provides the full path and name of the process executable)
    • Process ID (for the process receiving the connection)
      
• 5154 – Permitted an application or service to listen on a port for incoming connections
  • This event ID is logged by WFP when an application or service is permitted to listen on a port for incoming connections. The event log indicates the setup of internal proxies using netsh portproxy.
    
• 5447 – WFP filter has been changed  
  • This event ID provides insights helping identify changes to the WFP, indicating modifications to the firewall rules or setup of internal proxies using netsh portproxy to redirect traffic.

Technique 3: Windows Remote Management (WinRM) 

Windows Remote Management (WinRM) is a Microsoft tool used for remote management and command execution. WinRM uses transmission control protocol (TCP) port 5985 for HTTP traffic, and 5986 for HTTPS traffic by default. Keep in mind that by default, a non-administrator cannot execute WinRM commands. 

Check the %systemroot%\Windows\System32\winevt\Logs\Security event logs for: 

• 4624 – Logon type 3

Additionally, review the WinRM connection logs %systemroot%\Windows\System32\winevt\Logs\Microsoft‐Windows‐WinRM%4Operational for:

• 91 – Session creation (log records account used to authenticate the connection)

If the WFP is configured to log, you can search for permitted connections to identify the source host the tool execution originated from.

• 5156 – Permitted connection
  • This event ID is logged by the WFP when connections are permitted, and provides details about the process, application, and network parameters involved. Some of the most interesting fields to review from the log are the direction field, source address, source port, and protocol.
    • Direction field: Can highlight an inbound connection, since this is lateral movement via WinRM.
    • Source address: Names the source IP address the connection originated from.
    • Source port: Confirms the default ports used for WinRM (5985 HTTP) or (5986 HTTPS). 
    • Protocol: This should be 6 TCP. WinRM can only operate over TCP.

Technique 4: Windows Management Instrumentation (WMI) 

Windows Management Instrumentation (WMI) can be used to perform remote command execution via the wmic.exe utility. When WMI is invoked remotely on the target system, the process wmiprvse.exe is created, with child processes running under it. (Note that the child processes vary, and will often be simple commands like cmd.exe, powershell.exe, or even notepad.exe in an attempt to blend in.) This is helpful when identified within a process tree. Seeing an unexpected process wmiprvse.exe on the victim’s system may indicate lateral movement. Further confirmation is required and the logs list can help.

Identifying %systemroot%\Windows\System32\winevt\Logs\Security security event logs include: 

• 4624 – Logon type 3
• 4672 – Logon by user with admin rights
• 4688 – New process creation

There’s also a WMI-specific log, %systemroot%\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational, where you can look for: 

• 5857 – This log indicates time of process execution and the path to the provider’s dynamic link library (DLL) file
• 5860 – Registration of temporary event consumers, which are typically used for persistence, but can also be used for remote execution
• 5861 – Permanent event consumers, which are typically used for persistence, but can also be used for remote execution

And a final log you can use to check for WMI lateral movement is the %systemroot%\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational sysmon WMI logs. However, sysmon events aren’t logged by default and must be enabled. When they are, look for: 

• Sysmon (Event ID 1) – Process creation
• Sysmon (Event ID 19) – WmiEventFilter activity
• Sysmon (Event ID 20) – WmiEventConsumer activity
• Sysmon (Event ID 21) – WmiEventConsumerToFilter activity

Remediation actions

As soon as lateral movement is detected in the environment, it’s crucial to take immediate remediation steps to contain the threat.

1. Isolate the affected host(s): This helps prevent the threat from spreading further. Isolation can be achieved through an endpoint detection and response (EDR) solution.
   • Disable the network interface card (NIC): This step ensures that the affected host cannot communicate with the network. This step is only necessary if EDR is unavailable. 
2. Identify and isolate the source asset responsible: If the source is unmanaged, install an EDR sensor to gain better visibility and control.
   • Disable the NIC: This further ensures that the source asset is isolated from the network. Again, this step is only necessary if EDR is unavailable. 
3. Disable compromised accounts: Immediately disable any accounts that have been compromised.
4. Kill all active sessions: Ensure that all active sessions for the compromised accounts are terminated to prevent further unauthorized access.