RP2007: Lateral Movement using WinRM or Powershell Remoting

Summary

ID	RP2007
Brief Description	Response playbook for detected Lateral Movement using WinRM or Powershell Remoting.
Author	Alex@Cyberok
Creation Date	2023/02/03
Modification Date	2023/03/30
Tags	Status: Stable Severity:High Tlp: Amber Pap: White Windows
Usecases	WinRM or Powershell Remoting for Lateral Movement

Description

WinRM stands for Windows Remote Management and is a service that allows administrators to perform management tasks on systems remotely. Communication is performed via HTTP (5985) or HTTPS SOAP (5986) and support Kerberos and NTLM authentication by default and Basic authentication. Usage of this service requires administrator level credentials.

By default it might not be possible to connect to another system over WinRM and additional configuration might needed. The following commands will assist to configure the service properly for HTTP access from any host.

winrm quickconfig
winrm set winrm/config/Client @{AllowUnencrypted = "true"}
Set-Item WSMan:localhost\client\trustedhosts -value *

Usually defenders see simple commands such as “winrm get config” or “winrm quickconfig.”

Workflow

For better triage and response actions result you need to identify and analyze artifacts from use case.

When a WinRM connection is initialised Windows EventID 6 will be recorded (the source host) and when a WinRM connection is received Windows EventID 91 is recorded (the target host). Both events will be logged in Microsoft-Windows-WinRM/Operational (Windows Remote Management through the GUI).

We can further investigate any activities by collating Windows EventID 91 (a WinRM connection has been received – i.e. the target host) with PowerShell logging EventID 4103 (Module Logging), to see what may have been executed after the connection was made.

To expand your detection functions for this attack, you’ll need to monitor processes spawning from “wmiprvse.exe” and suspicious network connections to “svchost.” For those interested in monitoring processes spawning from WMI, be warned! It gets noisy, and you’ll need to establish a baseline of what looks normal in your environment. Once you can outline legitimate activity from your admins, you can focus on spotting evil.

1. Define the attack details. Identify means of attack and identify affected systems and users based on previously found identification moves. Define list of compromised hosts and users.

2. Block lateral movement. It's better to stop attackers early, whether attempting to establish a beachhead inside the network or compromising identity data to move laterally, escalate privileges, and acquire targets.

   • block internal ip address
   • block data transferring by content pattern

3. Take any eradication action depending on the situation and level of asset's criticality.
   The attacker steals valid credentials from a system and then uses those credentials to authenticate to other systems on the network. Look for credentials used in defined lateral movement attack:

   • revoke authentication credentials

4. Take recovery action depending on previous containment and eradication actions:

   • unblock qurantined host

5. Report incident, remove security breaches, conduct lessons learned exercises.

Mitigation

WinRM can be secured in a few different ways. First, system admins should establish a management network architecture that lends itself to increased security. This involves establishing a jumpbox that is only used for remote administration functions.
This strategy helps secure a network by forcing this privileged activity through a single controlled and hardened system, therefore not exposing sensitive credentials to attack. It also helps secure WinRM directly because we can limit the number of hosts trusted by the WinRM subsystem.

In an ideal environment, client computers in the organization should not trust one another, and they should only trust the jumpbox systems. To configure what trusted hosts are allowed to contact WinRM, we can execute the following command:

winrm set winrm/config/client '@{TrustedHosts="JumpBox1,JumpBox2"}'

This configuration can also be enforced using Group Policy objects in an Active Directory environment. This can be accomplished via a policy with the “Allow remote server management through WinRM” setting, and specifying a list of hosts to trust.

For authentication to WinRM for management, keep the defaults when possible as they don’t allow the less secure methods of authentication (Kerberos is default). Finally, WinRM default configurations establish both an HTTP and HTTPS listener. If you can, endeavor to disable the HTTP listener and only use WinRM over HTTPS. This may involve diving deeper into SSL/TLS certificates in your organization, so approach that with careful planning.

Response discovery mapping

ARTIFACT	RESPONSE ACTION	RESPONSE ACTION OBSERVABLES
Credentials	Identify affected systems and users Revoke authentication credentials Look for used credentials in lateral movement	Compomised credentials *After you defined compomised credentials it's reasonable to block user owner.
Remote Session	Examine content Block data transferring by content pattern Block remote session and possible execution action	Execution artifacts Search for compromised remote session. collect possible execution artifacts.

Response mindmap diagram

Playbook Actions

Preparation

Operational Preparations

Identification

Identify means of attack
Identify affected systems and users
Examine Content

Containment

Block Internal Ip Address
Block Data Transferring By Content Pattern
Lock User Account
Powershell disable AD user

Eradication

Reset Authentication Credentials
Revoke Authentication Credentials

Recovery

Unblock Blocked Ip
Unlock Locked User Account
Powershell enable AD user

Lessons Learned

Develop Incident Report
Conduct Lessons Learned Exercise

---

Artifacts

• Remote Session
• Credential