The Dangers of Persistent Binaries and How to Spot Them - Part I - HUNTERS

The First Blog in a Two-Blog Series on Persistent Binary Risks and Strategies.

The Dangers of Persistence

By ‘getting your foot in the door’ you are getting a chance to do something more. It represents an opening, which is the first step on the path that can ultimately take you where you want to go. For cyber attackers, getting into the network is the first step to achieving their attack objectives. Once in, they can use other tactics to accomplish whatever it is they are trying to do.

If an attacker can establish a persistent foothold – a perennial foot in the door, so to speak – within your network, it greatly increases the risks to your organization and the likelihood they will succeed.

A persistent presence enables an attacker to operate in a target organization for a sustained period of time. A recent report by IBM found the average attack dwell time, from compromise to detection, in 2019 was 206 days, and the average lifecycle of a breach, from compromise to containment, was 314 days.

That gives an attacker plenty of time to operate in the network and figure out how best to succeed – if something doesn’t work, they can come back and start over. Ultimately, they can try again and again to reach their goal, which can be anything, from disrupting operations to stealing valuable IP and sensitive data. Damage related to cybercrime is projected to hit $6 trillion annually by 2021.

How Attackers Establish Presence

Given the payoff, attackers will do whatever they can to achieve persistence. Luckily for them, there are many different tactics they can use to bypass an organization’s defenses and establish a presence on a system, typically a server or endpoint, that will persist, even in the face of reboots, restarts, credential changes, etc.

MITRE ATT&CK® describes, “Techniques used for persistence include any access, action, or configuration changes that let [an attacker] maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.” MITRE lists 63 different known techniques attackers use to achieve persistence.

Interestingly, the majority of these techniques leverage a particular malicious binary to establish their foothold. Unfortunately, the sheer number of legitimate persistent binaries coupled with the wide variety of tactics attackers can use to compromise a system makes it nearly impossible to identify each and every persistent threat.

So what can you do?

We developed this two blog series to help you determine how to spot persistent binaries and hone in on the ones that matter, so you can take steps to minimize the risks they pose to the privacy and integrity of your data and operations.

How to Spot Persistent Binaries

Before we can identify malicious binaries, we have to be able to detect persistent binaries in general. Persistent binaries don’t require any necessary user interaction – they are automatically launched when the system boots up. So, it follows that to detect a binary, we simply need to look for processes that launch right after the machine does, which can be implemented rather easily, as long as you have basic data processing capabilities.

This will allow you to catch every persistent binary because it works for:

• All OSes – it doesn’t matter whether the system uses Windows, MacOS, Linux, or even some Internet of Things (IoT) OSes – as long as there is a sensor collecting process data, the underlying concept works.
• All detection tools – any endpoint detection and response (EDR) solution, host based intrusion detection system (HIDS), Windows event log collector, Sysmon, or other visibility tool, such as osquery, can identify these common events.

The visibility you need to see the persistent binaries in your network

Regardless of what you are using (EDR/HIDS/etc.), you likely have the visibility into your organization’s endpoints you need to identify the persistent binaries in your environment. Basically, you need to be able to identify:

1. Process creation events on the endpoints.
2. Binary boot times per host. These times can be extracted from an ad-hoc event that some products generate; alternatively, it can be calculated heuristically, using these following methods:

• • Identifying the OS process creation time – some binaries, such as csrss.exe, lsass.exe, services.exe in Windows and coreaudiod, xpcproxy and logd for MacOSX initiate upon boot, so their creation time can be equivalent to the boot-time of the host. Note, these binaries will not be initiated more than once, except for very rare circumstances, so it is a fairly reliable way to get their boot time.
  • Detecting a time gap between events on a host – the boot time of the binary will be the time of the second event. For example, if there is a gap of at least 60 seconds between 2 consecutive OS events from a single endpoint, it is likely that the reason for not having events during this time is the endpoint being shut down / put on sleep. In this example, the timestamp of the first event after the gap is likely the endpoints’ boot time.

The goal is to identify the specific boot time of a host and all the processes (by SHA-256) that were spawned in a 30 second time period after that boot time to detect all the binaries. Once detected, we can group the results together and analyze them to uncover the ones that are potentially malicious (which will be covered in the next blog).

Example of how to get the visibility you need

For example, the image below shows the three steps we took, using SQL, to identify all persistent binaries and then hone in on the ones that are active on less than five hosts in our environment (which is a number we chose to represent a percentage of the hosts in our sample environment). We made the assumption that anything present on less than five hosts is anomalous and something we want to be aware of.

• Step 1: Enumerates all the boot sessions across the entire network.List_of_boot_events:

		Input:
		 Raw_event_table
		
			

		
		Filter:
		 Boot_time (event)
		
			

		
		Output:
		 Host_ID, Boot_time
	

• Step 2: Gets a list of all unique processes (SHA256) that were executed in the first 30 seconds upon boot-time. We set up a filter to group the results and return only the process hashes that participated in the boot sequence of less than 5 hosts.

Return_hash_in_boot_procedure:
		
Input: Raw_event_table , Host_ID, Boot_time
		
Filter: Process_creation_time > '30' from boot AND the total Amount of hosts with this persistent binary < 5 
		
Output: host_ID, Hash256
	

• Step 3: Returns the list per process hash:
  • Execution time after boot (in seconds)
  • The number of hosts that this hash was used in boot
  • List of all the paths that this hash was executed from
  • The number of hosts that this hash was executed on, regardless of boot-time

After executing these queries, this is what the results looked like:

Even when we narrowed down the results to only those binaries present on less than five hosts, you can see there is a lot to go through. This list contains a number of legitimate auto run binaries and binaries that were quickly executed by users after boot, as well as malicious binaries.

What’s next?

The next blog will discuss how to separate the legitimate from the malicious. It will go into how to spot the interesting leads and how to accurately pinpoint the ones that matter, so you can take steps to get rid of those that have no business being in your network.
Stay tuned.