How to detect an unauthorized PowerShell remote session

Understanding the threat

PowerShell remoting, implemented by WinRM, lets an administrator run PowerShell commands on a remote Windows host over the network. When a user opens a remote PowerShell session without permission, either using stolen credentials or by abusing WinRM settings, this becomes a high-value intrusion vector. Attackers can run commands, create accounts, change services, move laterally, and perform other actions while using only built-in tools. Because no new binaries need to be uploaded, these actions can be harder to spot if logging and controls are not in place.

Log360 identifies unauthorized PowerShell remote sessions by analyzing Windows event logs, PowerShell script activity, and registry changes in one place with prebuilt detection rules. It detects abnormal PowerShell execution, like encoded commands, unexpected downloads, or registry edits linked to RDP, and ties them back to the originating user and host. This helps security teams quickly confirm when PowerShell remoting is being misused and respond before it leads to lateral movement or privilege abuse.

Category

• External threat

MITRE ATT&CK® mapping

T1021.006 | Windows Remote Management (WinRM)

T1059.001 | PowerShell

Compliance mapping

CMMC (C001 - AC.1.001), CIS Controls (Safeguard 8.2)

Scenario

An attacker compromises a workstation and obtains a valid domain user credential. From that workstation, the attacker runs the following command:

The workstation establishes a WinRM connection to DC01 on port 5985 or 5986. The target host spawns the WinRM host process, for example, wsmprovhost.exe or a ServiceHost instance, to host the remote PowerShell session. The attacker remotely executes administrative commands over WinRM, performing actions such as creating a local account or changing group membership without uploading external tools. This behavior leverages native Windows management channels and is commonly seen in lateral movement and post-compromise activity.

Scenario infographic

Why this happens

• WinRM is a built-in remote management channel that accepts authenticated requests. If credentials are compromised or allowed too broadly, an attacker can reuse that channel.
• Using PowerShell and WinRM is a living-off-the-land technique. It relies on native tools and avoids writing files to disk, which can make detection harder when command logging is not enabled.
• Misconfigurations make abuse easier. Examples include WinRM being enabled across all systems, weak firewall restrictions on management ports, and overly broad access permissions for user accounts.

What can go wrong

• Rapid lateral movement while using only native operating system tools
• Remote execution of commands, changes to system configurations or services, and persistence through registry or PowerShell-based modifications
• Execution of obfuscated or encoded PowerShell scriptblocks that download additional stages or exfiltrate data; scriptblock or module logging is often the place where these payloads appear when logging is enabled

Prerequisites

Before configuring this detection:

• Event log collection from all Windows endpoints and servers must be set up in Log360.
• PowerShell Script Block and Module logging (event ID 4104) should be enabled via Group Policy.
• WinRM should remain enabled only on systems that require remote management.
• Ensure that Windows Event Collector or the Log360 agent is forwarding security, system, and PowerShell logs.

Detecting unauthorized PowerShell remote sessions using Log360

Step 1: Confirm log collection

In Log360, verify that security, PowerShell, and system logs are being collected from the target systems. These logs are required for identifying remote PowerShell execution and related activity.

Step 2: Enable the detection rules

Navigate to Security > Manage Rules > Rule Library and install the following rules:

• Powershell XML Execute Command
• Suspicious PowerShell Download - Powershell Script
• Potential Tampering With RDP Related Registry Keys Via Reg.EXE

These rules are preconfigured with the necessary event conditions to identify unauthorized PowerShell sessions and related behavior.

Step 3: Review detections

Once the rules are active, Log360 continuously analyzes incoming event data and highlights suspicious PowerShell activity. You can view these detections within the product’s incident or alert view. Look for events involving:

• PowerShell sessions initiated over WinRM (ports 5985 or 5986)
• Encoded or XML-based PowerShell commands
• Registry modifications linked to RDP or persistence attempts

Next steps

Investigate alerts in context: Use Log360’s search or Incident Workbench features to trace suspicious PowerShell activity by filtering events based on user, host, or command line. Review linked activity and entities with Zia Insights to understand the full attack path and confirm whether the session was unauthorized.

Harden remote management: Restrict PowerShell remoting (WinRM) to trusted hosts, disable it on endpoints that don’t require it, and enforce strong authentication and access controls.

With these detection methods and preventive steps, Log360 gives security teams the visibility needed to detect and respond to unauthorized PowerShell remote sessions before they lead to lateral movement or data compromise.