Lateral Movement is a key technique for attackers: Once they entered your infrastructure, the next step is to look around and move horizontally (i.e. to other, possibly more valuable machines and accounts) and vertically (i.e. obtain access to higher-privileged accounts). The MITRE ATT&CK framework provides the following definition:

Lateral Movement consists of techniques that adversaries use to enter and control remote systems on a network. Following through on their primary objective often requires exploring the network to find their target and subsequently gaining access to it. Reaching their objective often involves pivoting through multiple systems and accounts to gain. Adversaries might install their own remote access tools to accomplish Lateral Movement or use legitimate credentials with native network and operating system tools, which may be stealthier.

Pros & Cons of using built-in tools

It is important to understand that using system tools “may” be stealthier – but it may also simply get your movements discovered more quickly. As Raphael Mudge, the developer of Cobalt Strike explains: It always depends.

PowerShell is a native tool that allows to call Windows APIs, spawn processes, load and execute data from remote locations without leaving artifacts on disk – PowerShell can basically do everything an attacker could ask for. This is not a problem specific to PowerShell. As the Australian Cyber Security Centre explains:

This is not due to any security vulnerability within PowerShell, rather it is an indication of its tight integration with the .NET Framework allowing for an extremely powerful and easy to use interface to sensitive system functionality.

By not dropping malicious code to disk, identifying when a cyber intrusion is underway can be difficult, and forensic investigations can be very difficult to perform. Combined with the extensive functionality PowerShell provides, it is clear PowerShell is an extremely powerful post-exploitation tool.

However, since this was exploited so heavily, blue teams are often closely monitoring PowerShell. For security monitoring solutions like QRadar SIEM there are ready-made rulesets that discover typical post-exploitation activities performed in PowerShell. In other words, using these built-in mechanisms is convenient, but a real danger for an adversary’s OPSEC. The same is true when using other well-known methods like PSexec: CERTs have abundant threat intelligence on this kind of activity.

Of course, there are many businesses that do not monitor these events – or do not even enable auditing at such granularity level. However, since all these techniques are so well-understood and signatured, it is not rocket science to discover them.

Unfortunately, attackers have many more options to perform lateral movement and these are increasingly difficult to spot.

Customization to avoid detection

Cobalt Strike for example still uses PowerShell for many activities – although its reliance on it is decreasing – but usually only to spawn a stager which is preparing the stage for the real payload which is then executed somewhere else – for example in a trustworthy process using process injection. The challenge for the attacker is of course to spawn processes in such a way that the process tree does not look overly suspicious.

If for example iexplorer.exe (the executable for Internet Explorer) spawns cmd.exe (i.e. a command-line), it would look “not right” and EDR software would potentially detect you. I explained this kind of process tree analysis in my tutorial on Process Explorer. The attacker could of course come up with a unique, customized, and highly targeted attack, preparing the session in a kind of process tree that is very close to what is usually happening in that environment. However, this is a lot of effort and many less experienced or less determined adversaries will still resort to the default mechanisms that are easy to detect: Notepad.exe connecting to the internet? Not good, but easy to detect.

Movekit: Semi-automated customization for attackers

Bad news for the defenders is that there are newer technologies that allow to make customization just convenient enough so that an attacker will be able to have “one-of-a-kind” lateral movement activities (e.g. process trees) without putting too much effort into it. With an ever-increasing spectrum of possibilities for lateral movement, out-of-the box detection rules will not work anymore.

For Cobalt Strike for example you have an extension called Movekit, which combines a huge number of different options to perform lateral movement. These options allow for a whole lot of customization, making it very difficult for defenders to write effective detection rules that on the other hand do not wildly create false positives.

Among other techniques, Movekit allows to simply override legitimate existing process configurations and to revert them after the job is done:

·  Modify Service binpath (over WMI) — Uses Win32_Service WMI class to update the existing binpath of an existing service, starts service, pauses and resets the service back to original state
·  Modify Scheduled Task Action — Modifies an existing scheduled task’s action with a command, runs the task, and resets back to original state

Since the manipulated processes are trusted inside the attacked environment, a quick look or a whitelist / blacklist approach will not suffice to discover this kind of movement.

Even more options for attackers

Of course, the gain in convenience from using tools like Movekit still can leave some kind of common “identifier” between customized attacks to detect them. Nevertheless, since options to perform lateral movement are so abundant and time for preparation and scrutinization for blue teams is limited, a determined hacker will be able to remain under the radar for quite some time. Moreover, with discovery tools like Bloodhound, attackers do not need to be poking around in the dark, but can focus on the potentially most valuable targets. There are even ways for attackers to use security software itself to move inside the environment, e.g. to exploit the privileges of a Splunk log monitoring forwarder.

Takeaways for Blue Teams

The takeaway for the defending site is of course not new: Start your preparation with the low-hanging fruits and critical assets. A low-hanging fruit would be for example to implement ready-made rulesets for well-known attack vectors, critical assets would traditionally be domain controllers.

But then you will need to be aware that crafting more and more rules that monitor process trees and PowerShell commands will not help you a lot, for the simple reason that you will not be able to cover and foresee everything an attacker could do. Try to get the big picture, collect meaningful logs that help you to correlate events to discover tactics and not only specific techniques, reduce the attack surface by hardening: limit the selection of allowed applications and reduce user rights.

But as I wrote before: With ever more options and tools available, detecting lateral movement once the attacker is in will not become easier in the future…

Update 5th of September 2020: A colleague of mine brought to attention this very interesting article on Lateral Movement using WMI Event Subscription. Apart from the technical details which are worth checking out, it caught my eye that also from a red teamer’s perspective things are not getting easier:

Performing lateral movement in an OpSec safe manner in mature Windows environments can often be a challenge as defenders hone their detections around the indicators generated by many of the commonly used techniques.
[…]
Navigating and minimising these IoCs while attempting to use public tools such as Cobalt Strike, Impacket or similar can be a minefield.

While slightly ironic that both for red and blue teams things seem to get harder, I guess this is a natural process: Attackers try some technique, defenders develop countermeasures, attackers need to go to greater lengths and develop more sophisticated attacks, which in turn force blue teams to try harder, too.