Lateral Movement – Methods and Good Practices

We did a few previous posts on PowerShell Empire, command and control channels, and establishing agents on compromised hosts. In this post, we’re going to talk about one of the next steps after compromising a system – lateral movement. We’ll be using Empire for our examples, so it’ll help to have some familiarity with the framework.

If you need a refresher on command and control or PowerShell Empire specifics, you can check out our previous blog posts on them here:

C2 w/ Empire – Part 1

C2 w/ Empire – Part 2

C2 w/ Empire – Part 3

Whenever we perform lateral movement, there are usually a few steps that come before actually establishing C2 channels to additional remote systems. First, we need to identify potential targets. Then we’ll want to test our access to those systems before attempting (and maybe failing) any authentications.

Finding Where to Pivot

Often when performing lateral movement, you’ll have already performed network scanning and built a list of targets. In other scenarios you won’t have had any previous visibility into the network. In either case you’ll want to further build out your target list to identify potential systems to pivot to and extend your access on the network.

One way to accomplish this very quickly is through querying Active Directory. PowerShell Empire comes with a number of situational awareness modules which help gather target lists. For instance, you can use the “Get_Computer” module to query AD for all computers joined to the current domain. This should give you a pretty thorough list of systems in the environment and is a great place to start.

Using Empire’s “Get_Computer module to list computers in Active Directory.

Using Empire’s “Get_Computer module to list computers in Active Directory.

We could probably do a whole post on system enumeration, and in large environments it’s an even more important step in the attack chain. For now, we’ll leave you with this example and let you explore some of the other Empire enumeration module on your own.

Testing Access to Remote Systems

After identifying potential systems to pivot to, you’ll want to make sure you have the correct access before attempting any lateral movement. By checking for access before performing any authentication attempts, you can reduce noise from failed authentication attempts and be a little stealthier.

One way to do this is with Empire’s “find_localadmin_access” module. This module will enumerate the local admin group of remote systems, including nested groups, and determine if the current user is a member. This is super helpful for us since local administrators generally have remote access to the system.

Identifying local admin access to remote systems with Empire’s “find_localadmin_access” module.

Identifying local admin access to remote systems with Empire’s “find_localadmin_access” module.

Another way you can test for access is by attempting to list the contents of an admin share on the remote system. There’s no guarantee that the share you try will exist but attempting to list the contents of “\\target-system\c$” is a pretty safe bet. Again, this will require local admin access to the remote system. Note that this method will perform a remote authentication.

Listing the contents of an admin$ with the “dir” command.

Listing the contents of an admin$ with the “dir” command.

Lateral Movement Methods

Once you’ve identified the systems you want to move to, you’ll need to establish an agent on them via a lateral movement method! Generally, lateral movement is accomplished through some type of remote management of the system. There are only so many ways to do that, so your options for lateral movement tend to be somewhat limited. Two popular and reliable methods are through PSExec and WMI.

PSExec

The PSExec executable is part of the Sysinternals tool suite. It will execute commands on a remote system by creating a service on the system, copying an executable to the ADMIN$, then kicking off the service to run the executable. Typically, this executable will contain code to establish a command and control agent on the system. The tool is a Microsoft signed binary, which makes it generally trusted in most Windows environments. However, the artifacts it creates during this process are easily identifiable. Most defensive toolsets will detect (or at least have the ability to detect) lateral movement via PSExec.

Lateral movement via PSExec.

Lateral movement via PSExec.

WMI (Windows Management Instrumentation)

WMI is commonly used to perform and automate administrative Windows tasks, including interacting with remote computers. There is an included executable (wmic.exe) in the Windows operating system to perform these remote admin tasks, or the same Windows APIs can be interacted with through PowerShell or other scripting languages.

By using the wmic.exe executable, you’ll be creating a new process on the currently compromised system. This can be a flag to defenders that there may be some malicious activity going on. On the other hand, PowerShell is often heavily monitored for similar calls. Which method to use will depend on the specific situation. We usually like to stay in memory and call WMI through Empire’s “invoke_wmi” module.

Lateral movement via WMI.

Lateral movement via WMI.

Every lateral movement method, including the methods we didn’t cover, is going to have its pros and cons. It’s important to consider your particular situation prior to moving laterally in an environment and pick the method you feel is going to best fly under the radar of defenders. By targeting specific systems and testing your access beforehand, you can help to further reduce the risk of getting caught.