purpleteam

The Lowdown on Lateral Movement

Anton Ovrutsky

Feb 23, 2022 • 19 min read

What Is Lateral Movement ?

Lateral movement is a broad MITRE ATT&CK category, consisting of nine distinct techniques and numerous sub techniques.

Due to its breadth and linkages between other areas of the ATT&CK framework, lateral movement becomes an increasingly interesting category, presenting numerous challenges to defenders.

The category of lateral movement is indeed intrinsically tied to other ATT&CK techniques and categories. For example, a threat actor needs to have a foothold in the environment to move laterally (Initial Access). In addition, a threat actor also requires some kind of credential material to be able to access various assets on the network (Credential Access) and needs to have a target for their lateral movement (Discovery). All these techniques and categories work together in order to make lateral movement a viable option for a threat actor.

With the above as our contextualization, the aim of this blog post is to dig deeper into the "why" of lateral movement as well as providing some technical defensive guidance around lateral movement visibility and detections.

The Why

Let us think of lateral movement from a threat actor perspective for a moment.

You landed on a network through some kind of initial access technique and obtained a set of credentials; what now?

Perhaps your objectives could be met through the initial foothold.

Conversely, this initial foothold may not provide the required level of access desired in order to meet our fictitious and nefarious objectives.

In this case, then, we as the threat actor must attempt to move laterally and pivot to other systems on the network that either contain the desired objective directly or are necessary to complete a path towards the desired objective.

In other words, lateral movement decisions utilize a "graph based" way of thinking as opposed to "list-based".

This can be summed up neatly in using John Lambert‘s phrase – "defenders think in lists, attackers think in graphs"

Particularly in the context of an Active Directory environment, managing attack paths is a critical task in holistically defending your enterprise. The writings of Andy Robbins are a must-read in this arena.

We now understand what lateral movement is and are also aware that lateral movement techniques require an element of decision-making on the part of the threat actor.

How do we explore this concept through a framework or model that can help us, as defenders, make more intelligent decisions on lateral movement defenses?

For this we can turn to the work of Jackson_T and their brilliant blog post on Operational Mental Models.

This blog post is filled with thought-provoking concepts and frameworks that can all be explored in great depth. For our purposes however, let us focus on "Symmetrical Task Framing"

Symmetrical Task Framing proposes that both defensive and offensive procedures are "a series of generation and discrimination tasks" – this means that both attackers and defenders "perform tasks that generate or discriminate behaviors". Most importantly, in our opinion, this framework highlights the symmetry that exists between both attacker and defender tradecraft.

In the context of lateral movement, and according to the model outlined by Jackson_T, this means that attackers will base their lateral movement decisions around a level of situational awareness where it is then possible to generate a behavior which would leave behind an observable artifact. In addition, attacker options are also validated against a set of tradecraft constraint factors.

The Symmetrical Task Framing model can be visualized as follows (re posted with permission from https://jackson-t.ca/operational-mental-models.html)

Let us try to fit lateral movement into this model and come up with some intelligent questions to ask ourselves from a defensive standpoint:

Artifacts Observed:

How did the threat actor target a particular endpoint for lateral movement?
Can we observe this targeting or enumeration process ?
For aspects that we cannot observe, what other sources of information serve to inform attacker targetting options?

Tradecraft Policy:

How did our network topology influence the targeting of a specific asset for lateral movement ?
Are certain assets on the network “softer” targets for lateral movement ?
If lateral movement technqiues are observed through telemetry or other means, what does the observed technique tell us about the approach and motives used by the attacker; can we use this information to predict future behavior?

Decision Exceptions:

Did an expected or known “soft” target not get targeted ?
Did a mismatch in exepectation help uncover a technical or non-technical constraint imposed on the operator or threat actor?

Procedural Logic:

How was the lateral movement performed ?
Do we lack visibility into certain protocols used for lateral movement ?

Artifacts Produced:

What artifacts – on the host or network layer – are produced by lateral movement techniques ?
Do we have gaps in coverage that may bias our findings ?

Viewed through this model, we as defenders can now make more intelligent decisions regarding telemetry collection, asset prioritization as well as meaningful and actionable alert creation.

The How

We have now framed lateral movement and have used the "Symmetrical Task Framing" model to come up with a series of defensive-oriented questions to ask ourselves when thinking about building lateral movement detections and protections.

Let us move to a more technical level now, and crunch some MITRE ATT&CK data to see what prerequisites exist for successful lateral movement from a threat actor point of view as well as a look at the data sources required to collect the relevant telemetry for lateral movement TTPs.

There are many ways to slice and dice ATT&CK data. One of our favorites is using the Supporting Add on for MITRE Splunk app

Let’s look at this simple query to see how many MITRE techniques and sub-techniques fall into the lateral movement category:

index="attck" "kill_chain_phases{}.phase_name"="lateral-movement" 
| dedup name
| table name

Depending on which version of ATT&CK is being utilized, you should see about 20 techniques returned under the Lateral Movement tactic (TA0008)

Let’s also take a look what access is required to perform lateral movement with the following query:

index="attck" "kill_chain_phases{}.phase_name"="lateral-movement"
| rename x_mitre_permissions_required{} AS permissions
| stats values(permissions)

The results returned should look like:

Permissions
Administrator
Remote Desktop Users
SYSTEM
User
root

So we have a relatively large number of techniques to deal with, along with a broad level of required access. Indeed, according to the MITRE ATT&CK data, lateral movement can be performed with access ranging from a normal user account all the way to SYSTEM level access.

Let’s add data sources to the mix with the following query which counts the number of applicable data sources to each technique under the lateral movement category:

 index="attck" "kill_chain_phases{}.phase_name"="lateral-movement"
| rename x_mitre_data_sources{} AS datasources
| stats count(datasources) by datasources

Looking at the results using a pie chart, we see the following:

There are many applicable data sources, with a sizeable chunk of our pie chart represented by process creation events and process command line parameters. Towards the bottom of our pie chart we also see a lot of network-layer data sources. Authentication logs also feature prominently in our generated pie chart.

As we make our way through the detections section in the latter half of this post, the above highlighted data sources will indeed feature heavily throughout.

Using the same data "inverted" we can also look at what techniques have the largest amount of data source coverage:

index="attck" "kill_chain_phases{}.phase_name"="lateral-movement"
| rename x_mitre_data_sources{} AS datasources
| stats count(datasources) AS datasource_count BY name
| table name,datasource_count

We see "Remote Services" and "Lateral Tool Transfer" represented heavily in our pie chart which should be no surprise as "Remote Services" contains six sub techniques. Similarly, there are many ways to perform "Lateral Tool Transfer" with each variation potentially including a unique data source.

We have now equipped ourselves with a mental model to use for thinking about lateral movement defenses and we have also operationalized the MITRE ATT&CK framework to give us some idea of the data sources we need as well as the requirements from a threat actor point of view to perform lateral movement techniques.

Using this intelligence, we can:

Build better threat models in the context of lateral movement
Prioritize telemetry collection efforts
Prioritize detection engineering efforts
Form more comprehensive threat hunting hypotheses
Better identify telemetry gaps
Better understand threat actor decision making
Utilize graph-based view of network protection

Lateral Movement TTPs

So far we have contextualized lateral movement broadly and have also operationalized MITRE ATT&CK data, let us now dive into some technical lateral movement TTP detections.

T1210 – Exploitation of Remote Services

This category refers to lateral movement via exploitation of vulnerable software running on the target system. That is, an attacker may have a foothold on system A, perform a scan or probe, and determine that system B is vulnerable to some kind of remote code execution vulnerability and then exploit that vulnerability in order to gain a foothold onto system B.

This category is ever changing as new vulnerabilities are discovered. MS17-010 as well as CVE-2020-1472 aka ZeroLogon are good examples of the types of vulnerabilities that are exploited in this category.

We have written about Zerologon extensively here: https://www.lares.com/blog/from-lares-labs-defensive-guidance-for-zerologon-cve-2020-1472/

For categories like T1210 which are difficult to harden against and plan for, it is worth turning back to our MITRE ATT&CK data, particularly the data source analysis.

Although we cannot forsee future vulnerabilities found within our networks, we can ensure that the relevant telemetry is collected.

If we look at the data sources used to identify ZeroLogon exploitation, we can see data sources such as packet capture, process events and authentication events feature heavily.

T1570 – Lateral Tool Transfer

This is a broad category that includes transferring files between systems. In this example, let’s take a look at the SMB protocol and what events we can see when a file is transferred.

For this test we will generate a Metasploit executable and will copy this file from a host named win10-0 with an IP of 192.168.1.149 to a host named win10-1 with an IP of 192.168.1.158

Using the awesome Malcolm ( https://github.com/cisagov/Malcolm ) tool to monitor our network traffic, we can see the following interesting events as our file is transferred:

We can see that a file has been transferred and that it is an executable file. We can also see that the file has been extracted from our PCAP and is available on the system that collected it for further analysis.

We can also use Sysmon, particularly Event ID 3 (NetworkConnect) to look at this file transfer activity as well. With the following Splunk query:

index=sysmon Initiated=false DestinationPort=445
| table SourceIp,DestinationIp,DestinationPortName,Image

We can see all incoming connections over SMB to our "victim" machine (win10-1)

Using the following Arkime/Malcolm query combined with the Connections view, we can graphically examine file transfers over SMB, limiting our results to certain extensions if necessary:

ip.src == 192.168.1.149 && ip.dst == 192.168.1.158 && zeek.smb_cmd.command == CREATE && zeek.smb_files.name == .exe

Network monitoring and particularly Zeek in combination with Malcolm is an incredibly powerful tool in our threat hunting and detection arsenal and we can pivot off our runme.exe executable and get more info:

At this point we see that a file has been transferred to an SMB admin share and the file is unsigned.

Malcolm also has the ability to scan carved files with Yara, ClamAV and Capa

Looking at the ClamAV signatures, we can see that our executable file flagged:

Similarly, we can also see output from Capa analysis:

We now have a lot of data points to work from, without the file ever being executed. The Zeek/Malcolm data also contains file hashes which can be used to pivot back to the host layer if necessary.

T1563.002 – Remote Service Session Hijacking: RDP Hijacking

RDP hijacking involves a threat actor taking control or otherwise "hijacking" existing RDP sessions on machines.

In our example, we have two users, RDPUser1 and RDPUser2 logged into the same machine:

In the above example, we are logged in as RDPUser2 and want to hijack the session of RDPUser1 – we can use Mimikatz to perform the RDP Hijack:

And when the attack is successful, we are presented with the RDP window of RDPUser1

When this execution occurs, an Event ID of 4778 is logged. In addition, the AtBroker.exe binary is executed by the user that is being hijacked (RDPUser1). We can link these events using the user name as our pivot point, the following Splunk query attempts this:

index=winlogs OR index=sysmon EventCode=4778 OR (EventCode=1 AND Image="C:\\Windows\\System32\\AtBroker.exe")
| bin _time span=10m
| eval UserNameNormalized = coalesce(AccountName,user)
| stats values(ClientName),values(ClientAddress),values(SessionName),values(Image),values(ParentCommandLine) BY UserNameNormalized,_time

Here we are looking for the presence of Event ID 4778 OR the Sysmon Event ID as well as the execution of AtBroker.exe – we are then normalizing the fields that contain the user ID and are grouping our results on a time bucket as well as the normalized user name value.

Upon running the query, we get the following results:

When we compare the above activity to a normal RDP session; that is, a user opening some kind of Remote Desktop tool and connecting to a server, we do not see a 4778 event, nor do we see the execution of AtBroker.exe.

T1021.003 – Remote Services: Distributed Component Object Model

In order to test DCOM lateral movement, we can turn to Invoke-DCOM written by https://twitter.com/424f424f

For this test we will be using the MMC20.Application method:

Invoke-DCOM -ComputerName '192.168.1.158' -Method MMC20.Application -Command "calc.exe" this command will execute calc.exe on the machine with the IP of 192.168.1.158

Using the following query, we can identify network connections made to the mmc.exe process as well as list any processes that spawned from this mmc.exe process:

index=sysmon (Image="C:\\Windows\\System32\\mmc.exe" OR ParentImage = "C:\\Windows\\System32\\mmc.exe")
| eval normalized_guid = coalesce(ParentProcessGuid,ProcessGuid)
| stats values(Image),values(CommandLine),values(DestinationIp),values(Initiated),values(SourceIp),values(User),values(ParentImage),values(ParentCommandLine) BY normalized_guid

And looking at our results:

Digging into our PCAP data and looking at the RPC protocol, we notice the following network artifacts:

Zeek is unable to currently parse these values fully, but opening the same PCAP files in Wireshark reveals the following:

We see the our endpoint value, starting with a value of b19 and we see that this translates to IProvideClassInfo

This also leads us to the DCOM value highlighted above and a Causality ID – this information is useful as this can now tell us that this RPC traffic contains evidence of DCOM execution.

Although this data is not parsed in Malcolm, we can copy the hex bytes that make up our causality ID and execute a hunt for these bytes:

Looking at the hunt results, we see only sessions which executed DCOM over RPC and not all our RPC traffic:

Using the same technique of hunting for raw hex bytes within our Malcom data, we can also look at the CLSID of MMC20.Application, this technique is outline in the following paper:

https://atr-blog.gigamon.com/wp-content/uploads/2018/12/eu-18-Warner-Sirr-Network-Defender-Archeology-An-NSM-Case-Study-In-Lateral-Movement-With-DCOM-wp.pdf (page 09)

T1021.006 – Remote Services: Windows Remote Management

Windows Remote Management is a tricky lateral movement TTP to wrangle, particularly if your environment is utilizing Windows Event Forwarding.

To test this TTP, we will be using Evil WinRM ( https://github.com/Hackplayers/evil-winrm )

We execute a remote connection over WinRM from our Kali machine to our victim host at 192.168.1.149

Here we are just executing a simple whoami command and are taking a quick look at the options available to us through Evil WinRM.

Processes executed through our WinRM shell will all have wsmprovhost.exe as their parent, the following basic query will give you visibility into processes spawning from wsmprovhost.exe

index=sysmon ParentImage="C:\\Windows\\System32\\wsmprovhost.exe"
| table Image,CommandLine,ParentCommandLine,User

And the results:

Pivoting to the network layer, we know that WinRM operates over port 5985, so let’s take a look at our PCAP to see what we can find:

We see a lot of Windows Event Forwarding traffic in our quick search, so lets work on whittling that down.

We can use Malcolm/Arkime’s powerful SPI (Session Profile Information) view by clicking on the URI button and clicking "Open URI in SPI Graph"

This view will present us with overlay a timeline view in graph or bar format with the amount of session data sent over port 5985 broken down by URI, our results here are interesting:

We can see that legitimate URI’s used for Windows Event Forwarding all seem to hit the wsman/subscriptions endpoint, whereas the bottom two WinRM events seem suspicious, as they are not hitting that same endpoint.

We can look at this data in table format as well by clicking on the Graph Type option in Malcolm and selecting "table":

Using this view, we can more clearly see our potentially anomalous WinRM connections:

Let’s drill down into the values that contain our weird URI values with the following Malcolm query: port == 5985 && http.uri == 192.168.1.149/wsman

Upon expanding a session that was returned via our query used above, we see an odd User Agent in use:

Mentally referencing the Symmetrical Task Framing model covered earlier in this blog, it is worth pondering the question of how the presence of Windows Event Forwarding, as an example, would affect or not affect adversary tradecraft, particularly in the context of lateral movement using WinRM.

T1021.005 – Remote Services: VNC

Depending on the application that is used to establish VNC sessions, there may be various host-based artifacts left on the server. For example, TightVNC logs session authentications in the Application log channel. The following Splunk query can be used to gain visibility into this data.

index=winlogs EventCode=257  Name="'tvnserver'" 
| table  Message

Using the following Maclolm query: protocols == rfb || protocols == vnc we can also get visibility into VNC at the network layer:

T1550 – Use Alternate Authentication Material

This particular MITRE category speaks to threat actors using authentication material other than a standard username or password to authenticate to systems. This "alternate" authentication material can include cookies, Kerberos tickets, tokens and password hashes.

There are a number of approaches to detecting this kind of activity, one approach we wanted to highlight here is a general "access anomaly query"

Let’s lay out the following hypothesis: We expected a particular user in our network to access particular sets of systems during the course of normal business operations. We then suppose that a login to a system that is unexpected should be marked as an anomaly for further review.

This relatively simple dynamic can be summed up in the following chart:

Let’s implement this logic in Splunk, our hypothesis will be tested using the following scenario: our lab has two users RDPuser1 and RDPUser2 and two servers/workstations, Win10-0 and Win10-1 – from baselining activity within our lab environment, we know that RDPUser1 logging into Win10-1 is normal activity and RDPUser1 logging into Win10-0 is unexpected or abnormal activity.

We start by building a quick lookup tables with the values that we expect to be valid/expected:

Next, we use the following query logic:

``Looking at the index where the windows logs are, at the broad authentication tag and we are excluding computer accounts and some other noise``
index=winlogs tag=authentication (user=* AND user!=*$* AND user!=SYSTEM AND user!="DWM-2" AND user!="UMFD-2") AND dest!=localhost AND action=success
`<code>some fields within the authentication tag have user@domain format and some jusst have user so we clean that up</code>`
| eval user = split(user,"@") 
| eval user = mvindex(user,0)
`<code>Perform our lookup, output will be an expected_login field with a value of "yes" if there is a match</code>`
| lookup auth_anomaly.csv user as user, dest as dest OUTPUTNEW expected as expected_login
`<code>if the expected_login field is a "yes" then count that as a normal login, otherwise label it an authentication anomaly</code>`
| eval auth_anomaly=if(expected_login=="yes","Normal Login","Authentication Anomaly")
| table user,dest,auth_anomaly

And looking at our results, we see the following:

The results line up with our hypothesis, and the login that RDPUser1 performed to Win10-0 is marked as an authentication anomaly.

Although this is a simplified example, the concepts around baselining, building a lookup of expected behaviors and alerting on anomalies within this activity is an extremely powerful paradigm that should be able to capture various techniques and tactics within this broad category.

The below graph outlines some other – non exhaustive – login characteristics that can be used in a determination around whether a particular authentication was malicious or not.

Certain alerts in the lateral movement category are able to be crafted using a binary classification system. That is, a determination that labels a particular event as either malicious or benign.

The binary classification of behavior is less optimal when looking at the general "Alternate Credential Material" category. When it comes to alerting on credential theft and generally abnormal usage of credential material, it is a good idea to utilize a "it depends" approach.

This can be accomplished using "Hyper Queries" or something like Splunk’s Risk Based Alerting framework. Such alerting frameworks will allow you to alert on malicious activity with more flexibility and contextualization.

The Limitations of ATT&CK

Consider the following scenario as outlined by my colleague Andy Gill in his "Old but Gold" blog post; an attacker gets a hold of valid credentials in an Active Directory domain and proceeds to open mmc.exe on a victim host and uses it to connect to another victim host in the network, where they proceed to schedule a malicious remote task on the second victim machine.

The usual endpoint detections would apply for the creation of the scheduled task.

We would not, however, expect to see a process creation event for schtasks.exe but, if enabled, we will see an event with the Event ID of 4698.

Certain elements of T1053 were definitely involved in this attack scenario, but T1053 alone does not take into account the "remote" portion of our fictitious attack scenario outlined above.

This scenario outlines the dangers of utilizing the ATT&CK framework as an exclusive and sole barometer of detection coverage. As we see, this particular technique does not fit neatly into any existing ATT&CK categories.

This example also highlights the need to have different sets of telemetry at our disposal in order to be able to reconstruct these malicious events.

Looking at the generated 4698 event for the scheduled task in our above example, there is no overt information that tells us this task was created remotely. Let us then turn to the network layer.

Let’s use the following Malcolm query to look at the RPC traffic occuring between our victim and target host:

ip == 192.168.1.157 && ip == 192.168.1.149 && protocols == dce_rpc

And the results:

The RPC calls beginning with "Sch" look particularly interesting and after some filtering, we end up with the following:

Now we have a better understanding of the attack chain and are to pivot off this data to determine both a source and destination as well as being able to tie this activity to host-level telemetry.

Referencing our Symmetrical Task Framing model once more, this scenario introduces some interesting questions, both in terms of telemetry collection as well as attacker tradecraft. From an attacker point of view, perhaps this method of creating a malicious scheduled task is more stealthy than other methods, given the telemetry available in the environment.

Conclusion

The aim of this blog post has been to highlight the lateral movement ATT&CK category as one that presents network defenders with a myriad of issues in the context of threat detection and response.

Although difficult to wrangle, using mental models, data source analysis combined with intelligent alerts based on a rich set of host, authentication and network layer telemetry, network defenders posses the necessary tools required to identify and act on malicious lateral movement in their respective environments.

Having absorbed the material contained in this post, if you find yourself thinking about:

The risks that lateral movement poses to your environment
Whether the necessary telemetry collection is taking place
Whether detection and response capabilities exist in your environment to be able to successfully response to lateral movement
Whether your existing tool set and processes would prevent or detect lateral movement TTPs

Then a Lares Adversarial Collaboration Purple Team engagement is a good fit for you.

Please get in touch with our team!