In November of 2022 we announced a Suricata ruleset specifically focused on detecting lateral movement in Microsoft Windows environments. In this article, we explain how that ruleset, as a part of SELKS or any Suricata installation, can be used to detect living off the land techniques. It is important to note that this example demonstrates a feature of SELKS, our open-source Suricata intrusion detection/prevention system (IDS/IPS), network security monitoring system (NSM), and threat hunting implementation.
Let’s start with the basics so we don’t miss out on anything important.
One of the many powerful features of Suricata is that it can create protocol and transaction logs even in the absence of alerts. These logs include flow, anomaly, alert, protocol, and file transaction logs, plus file extraction and packet capture (PCAP).
Here is a full list and details of what those logs and transactions look like.
With the capabilities of Suricata in mind, let’s review the open lateral movement ruleset.
This ruleset is specifically developed for SMB Windows environments on top of Suricata 7+ capabilities and is meant to:
The detection methods of the ruleset highlight and provide traceability. For example, it could detect any sort of query or configuration change over SMB
Let’s look at an example:
Let’s say something or someone creates a remote scheduled task (we will review others as we move alone in this article). Usually, for that purpose, the standard MS-TSCH Task Scheduler Service Remoting Protocol is used. The task can be scheduled in multiple ways, via the default windows command line or GUI tools like the Remote Server Administration Tools (RSAT) for Windows for example.
Does a remote scheduled task instantly signal something malicious? No, not at all. However, we should investigate further because there are some important things to consider.
Sometimes, a remote scheduled task is an indicator that a threat actor is using the default tools and privileges on a system to conduct malicious activities. With that in mind, and in the case of our example, we need to find out what or who triggered the scheduled task. If we find that it did not come from an expected location, then we know we have something to worry about.
So, what does an event like that look like using the free, open-source lateral movement ruleset for Suricata?
The following screenshot is from SELKS, more specifically the hunt interface. The data displayed contains the alert itself, other related alerts, flow, SMB protocol logs, and a PCAP. Suricata produces all this information and correlates it by flow id by default. Please note that Suricata will produce all these logs (SMB, flow, PCAP, etc.) regardless of the presence of an alert. This is due to Suricata’s ability to function as a fully developed network security monitoring engine (NSM) that can operate regardless of rules or signatures.
The reason this alert event was triggered is simple – it just followed the Microsoft protocol definition for creating a remote scheduled task, as we can see from the Signature tab in the screenshot below.
As we mentioned above, if the remote scheduled task is not coming from the expected infra management servers or locations/tools, then it would warrant further investigation. However, there can be many different interesting occurrences worth highlighting and looking into, such as driver installation, remote permissions additions, creating services, resetting passwords, etc.
Here are some examples from the SELKS hunting interface:
Now, if these critical configurational changes do not come from an expected source (based on the Source IP) then we would certainly have something to investigate. For example, maybe the Source IP is tracing back to end user clients rather than management infrastructure.
So how do we filter out the critical configurational changes from all the events?
It’s actually is very simple! In every such alert event from Open Lateral Movement Ruleset there is a subsection from the full JSON log denoting its importance in terms of configuration activity (highlighted in bold).
That log looks like this:
{
"metadata": {
"lateral_function": [
"SASetAccountInformation"
],
"source": [
"smb_lateral"
],
"signature_severity": [
"Critical"
],
"lateral_asset": [
"src_ip"
],
"lateral_key": [
"dcerpc.iface"
],
"provider": [
"Stamus"
],
"stamus_classification": [
"lateral"
],
"updated_at": [
"2024_02_07"
],
"created_at": [
"2022_03_23"
]
},
"signature_id": 3115117,
"gid": 1,
"rev": 3,
"source": {
"port": 50805,
"ip": "10.136.0.69"
},
"severity": 3,
"category": "",
"target": {
"port": 445,
"ip": "10.136.0.64"
},
"action": "allowed",
"signature": "Stamus Networks MS-TSCH service - SASec SASetAccountInformation"
}
Take note of the signature severity level. There are two options - Critical or Informational.
The Critical level is used for an active configuration change – addition, deletion, adjusting permissions, creating deleting tasks, services, etc.
The Informational is for everything else.
"signature_severity": [
"Critical"
],
The bold section above is easily available and used as a filterset in the SELKS hunting GUI, however the exact same query can be executed in any SIEM that holds Suricata data.
In the Stamus Community Edition Hunting interface, as a part of SELKS, we can see that information by selecting the filter sets from the upper right corner, typing “lateral” in the search bar, and selecting the critical lateral changes filter set:
This results in the filter set query itself being applied to the Suricata data:
In Kibana/Elasticsearch or any other SIEM, the query below can be used to highlight critical config changes done remotely over SMB:
alert.metadata.source:smb_lateral AND alert.metadata.stamus_classification:lateral AND alert.metadata.signature_severity:critical
Below you will find a list of the critical configurational changes that the open lateral movement ruleset is capable of detecting via SMB. Each line/name represents the Microsoft protocol and the separate function being used (which is also part of the alert message):
For more information or active online discussion please join our community on the Stamus Networks Discord server: https://discord.gg/e6GQKGS5HN
The following resources can provide additional information:
Please note this this example is with regards to the Open Lateral Detection Ruleset with SELKS or any stable Suricata installation. The Stamus Security Platform (SSP) offers auto escalation, based on organizational context and automated triaging that is more suitable for the Enterprise level deployments.
To stay updated with new blog posts from Stamus Networks, also make sure to subscribe to the Stamus Networks blog, follow us on Twitter, LinkedIn, and Facebook, or join our Discord.