During our incident response training conducted all over the world, we work with security professionals to identify various trends related to how malicious actors persist and move within a compromised organization. Once the patient zero has been compromised, the malware typically proceeds with credential harvesting, internal reconnaissance, and attacking other internal systems to spread further into the network. Lately, the so-called east-west, or lateral spread of malware has gained more interest. “Can I monitor lateral movement with NetFlow?” asked one of our customers the other day. “Not only that, but you can alert on it as well,” was my answer.
Let’s start with the basics
When we talk about lateral movement, we typically refer to the techniques cybercriminals use to move through a network as they search for key assets and top-secret data. Leveraging the daily operating systems, tools, and protocols that your organization relies on serves yet another purpose: evasion. For instance, exploiting already-whitelisted tools such as remote desktop protocol, scheduling tools, PowerShell, Kerberos, communication protocols, and many others would allow malware to move throughout your network undetected.
The three key techniques that are associated with lateral movement are:
- Internal reconnaissance, which relies on the built-in tools such as PowerShell, netstat, IPConfig/IFConfig, ARP cache, and routing tables
- Credentials harvesting with keylogging, certificate capture tools, stealing plaintext passwords from the memory of the infected machine, and exploiting a domain controller to generate a Kerberos ticket-granting ticket for any user
- Pivoting attacks to compromise other hosts with the help of Remote Desktop Protocol (RDP), PsExec, VBScript, and open source tools such as Metasploit. Attackers can use PowerShell and WMI to connect to remote systems, modify the registry, access event logs, and even execute commands on remote machines.
How to monitor lateral movement
In his blog, my colleague Michael describes building a user behavior baseline by learning who is authenticating to what on a regular basis. Then we can then start to recognize authentication behaviors that appear irregular or exceed a threshold of tolerance, which will trigger events.
The customer I was working with wanted to know if a certain host was talking to another host on the same subnet. This is where Scrutinizer IP Groups came in handy, as they allowed us to break the customer’s network into multiple segments, such as Sales, Marketing, London headquarters, backup servers, etc.
Once we identified IP groups for all of his user segments, we created the Conversation App report filtering for each IP Group. In my example below, I am using the Marketing IP Group as the source and destination filter. It is the desired behavior when there are no results found. It means that the hosts on the subnet are not communicating to one another, which would be indicative of lateral movement.
Bonus: Yes, you can alert on it too
By adding a threshold to the report we just created, we can turn it into a proactive alerting tool. Now should there be any amount of traffic exceeding 1 byte per each individual conversation, our security team will get an email and investigate the incident:
For extra bonus points, we came up with an API script that checks for any IP groups talking to the same IP group and writes a syslog entry.
What do I do now?
Downloading a trial version of our incident response solution, Scrutinizer, would be a great first step. As your head starts spinning from endless possibilities of using NetFlow to proactively monitor the network, do not hesitate to pick up a phone and dial (207)324-8805 ext 4 to speak with a member of Plixer support team.