It is not uncommon to see executable file transfers within an organization. However, it is important to monitor those transfers to see whether they are routine and expected or if they could be coming from an untrusted or potentially malicious source. The ability to differentiate between these types of executable file transfers and determine whether the communication is new and has never been seen on the network before is essential to maintaining network visibility and security.
For most organizations, it is important to know when and where executables are present on the network so further investigation can be done. To do this, the security team could use Stamus Security Platform’s Enriched Hunting Interface and deploy one of the many guided hunting filters to simplify the discovery, investigation, and classification process.
Stamus Security Platform (SSP) automatically detects and identifies threats on the network, and presents security teams with incident timelines and extensive context for each threat. Many organizations take advantage of advanced SSP features and take an even more proactive approach to their defenses. When this is the case, they might task a security analyst with hunting for specific threat types, anomalous activity, or suspicious behaviors. To do this, they can use the Stamus Enriched Hunting Interface.
This interface provides security practitioners with over 100 ready-to-use guided threat hunting filters, including various filters for policy violations, that they can use to investigate, classify, escalate, and automate vast amounts of event data, alerts, and contextual metadata. For a more detailed look at the Enriched Hunting Interface, read the blog article titled, “Introduction to Guided Threat Hunting”.
What are lateral executable transfers?
An executable file is a file that contains an encoded sequence of instructions that are executed once a user clicks on the file. Some file types (such as EXE, BAT, COM, and CMD) do not even require the existence of additional programs in order to run on the system. A lateral executable transfer is the movement of an executable from one system within an environment to another. Lateral executable transfers are common for many organizations (especially those with a Windows environment using SMB), as IT team members use them to move tools or files around the network. Unfortunately, lateral executable transfers are also regularly used by malware actors to move malicious programs or other tools around a network after an initial breach.
Something that we want to see is whether or not lateral executable transfers are originating from non-IT, non-admin, or staging areas. For example, a lateral executable transfer from an end user PC towards a server or another end user PC. If this is seen on the network, it is a good indicator that there might be a malware actor present.
The goal of this hunt is to identify new, previously unseen lateral executable transfers via SMB that originated from unexpected or unapproved locations in our network.
Identifying lateral executable transfers with Stamus Security Platform
Stamus Security Platform (SSP) does most of the work for you. With Declarations of Compromise™, it definitively identifies serious and imminent threats. However, no system can automatically detect everything. That’s why SSP logs every possible indicator of compromise – otherwise known as “alerts''. These alerts can be used to create a trail of evidence in an incident investigation. Additionally – as seen in this series – they can also be used to perform a guided hunt for specific threat types or other unwanted activity.
So let’s take a look at the current alerts on our system:
In the past 24 hours, we have had about 1.7 million alert events which have triggered hundreds of thousands of results including protocol, flow, and file transaction logs and Host Insights for over 11,000 network endpoints and hosts.
The Hunt for plain lateral executable transfers using Stamus Security Platform
To begin this hunt, we are going to start by filtering for previously unseen traffic. This is done using “Sightings” . This feature gives us the ability to pinpoint the first time a piece of metadata (such as domain, TLS certificate, HTTP host/user agent/server, JA3, JA3S, file checksum, etc) has been seen in the enterprise.
To start, we switch off all “Alerts” and switch on “Sightings”.
This gives us a list of all new, previously unseen network metadata. We want to zero in on SMB executables, so we need to look for an SMB executable and add a filter.
The filter quickly narrows the hint down from 1.7 million alert events down to only 2 in the selected timeline. This is an excellent starting point.
Next, we conclude our filter by negating any metadata that is not coming from known IT admin or staging areas in the network. This can lead us to see which executable transfers are suspicious or unexpected. We also want to further enhance the filter to ensure that any newly seen SMB executable transfers go directly to the “windows” subfolder.
These steps bring us down to only one event and one file.
It is important to note that SSP Enriched Hunting also provides additional organization-specific context. Users can filter for queries from various departments or user groups within the organization, allowing them to hyper-focus on specific areas without having to aggregate events or organize IP addresses to find specific users or departments. (for example:)
There are several potential next steps we could take in this investigation, but I would like to take a closer look at the endpoints involved and see if any users that are seen there are still logged in. To get there, we need to see a list of all the hosts in order to know the full scope of what we are dealing with.
Knowing which clients and hosts are offenders and seeing additional information about the offense is important to get the full picture of this hunt. Specifically, we need to see which services are running on the offender’s host.
To do this, we can use Host Insights - a very powerful feature included with the Stamus Security Platform. Host Insights tracks over 60 security-related network transactions and communication attributes of a host. This provides a single place to view many aspects of the network activity relative to a given host, such as network services, users, or TLS fingerprinting forensic evidence.
We can click the “Hosts” tab on the left hand side panel and be transferred from the actual events logs to the Host Insights screen.
This filters our 1.7 million alert events which have triggered hundreds of thousands of results, including protocol, flow, and file transaction logs and Host Insights for over 11,000 network endpoints and hosts - to only 1 event taking place on 2 hosts. From here, investigating each host to get a better look at their activity is relatively simple.
Now we can look into each host and identify the user and view the network protocol log evidence. We want to review the specific information gathered in Host Insights such as the application protocol usage, user agent’s hostname, encrypted analysis, a timeline of events, and more.
What we learn here is that one of the hosts is actually a domain controller.
Now we can identify the specific user that is logged in to the endpoint and see a list of the events related to the executable download. In this case it is the Administration user.
What makes all this unusual is that there is no expectation whatsoever for an Administrator to copy executable files over to an end user PCs directly from a domain controller. This means there is a possibility that a malware actor is using these credentials to move executable to the end user. We need to gather additional evidence and escalate this event.
Evidence for Incident Response
With just a few clicks, We are able to view two important sets of evidence:
-
The associated network protocol transactions and flow logs
-
Host Insights - a single screen for reviewing 60+ network activity attributes collected for every host
The generated events are already enriched by SSP to include important metadata like DNS records, TLS protocol data containing certificate names, fingerprint JA3/JA3S, connection flow sizes, http user agent, http host, request body, status codes, file transaction info, and more.
Expanding the actual event details gives us those details and the related network protocol and flow transaction logs. Based on the extra http protocol information like status code, user agent, method, url, and response body, it is obvious that the file was downloaded and the transaction did in fact happen.
It is also helpful to view the file transaction log information with specifics like file magic, filenames, size, and checksums.
The sightings events details below provide me with the full SMB protocol and file transaction data needed, including extracted files.
With this information, we have located both the users and stations involved. We also have an IoC and details on where the file has been seen in the network.
Security analysts can use any piece of metadata to create simple or complex filters for things like wildcarding, negation, or inclusion. You can even include multiple fields for fast drill down capabilities. All domains, TLS SNI, IP addresses, HTTP hosts, and more can easily be checked with an external threat intelligence provider such as Virus Total.
Armed with the above information and evidence, a threat hunter has enough information and IoCs to generate an Incident Response ticket.
However, there are still two tasks left to complete:
-
1. We do not want to have to repeat this exact same process again in the future, so we need to set up classification and auto-escalation for future occurrences.
-
2. If anything like this has happened before, we want it to be found and escalated with all the associated evidence - all based on historical data.
Classification
In order to streamline the event review/triage process in the future, an experienced analyst can choose to tag/classify the events associated with this filter By doing so, SSP will tag future events that match the filter criteria as “relevant” or “informational,” depending upon the analyst’s selection. These tags can be used to automate event review/triage and make it easier for a less-experienced analyst to identify events that are relevant for manual review.
To do so, the analyst selects the Tag option from the Policy Action menu on the right hand side menu. This action will cause SSP to insert a tag into each event record as shown below:
This allows the analyst to easily filter out or search for them in any SIEM (Chronicle, Splunk, Elasticsearch, etc) or data lake using that tag.
It also allows for easy filtering out of those events in the Stamus Enriched Hunting GUI by switching to “relevant” only classified events.
Escalation and Automation of this Hunt
To set up an automation which causes SSP to escalate past and future occurrences, we can create a Declaration of Compromise (DoC) event from the Policy Actions drop down menu on the right hand side panel in the Stamus Enriched Hunting Interface.
The next step is to add some explanation about the type of threat. This also gives us a chance to provide informational context and helps convey knowledge to colleagues.
Select options to generate events from historical data and generate Webhook notifications.
Just like that, the hunt and all related activities are complete. Any past or future generated events from that automation will then be further auto-classified and escalated to the desired response process - via SOAR playbook, chat notification, or incident response ticket.
Our DoC escalation gives us exactly that.
With a timeline of hosts involved and their involved offenders with past occurrences.
Conclusion
The post-hunt activities completed in this example are just the tip of the iceberg when it comes to the automation and escalation capabilities of Stamus Security Platform. To learn more about these features and how to implement them, read our article titled “After the Hunt”.
To learn more about Stamus Security Platform (SSP) and see the enriched hunting interface for yourself, click the button below and schedule a live demo.