The Dangers of Persistent Binaries and How to Spot Them – Part II

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

Identifying the Persistent Binaries that Matter

Finding all the persistent binaries in your environment, which we covered in the first blog of this series, is a vital first step to being able to identify malicious attackers who have a foothold in your network. But the existence of a persistent binary, in itself, isn’t an indication of the existence of an adversary. What’s needed next is to separate out the legitimate binaries from the ones that shouldn’t be there.

The key to stopping them is identifying them. You need to hone in on the binaries that are more rare and uncover the ones that are behaving abnormally to determine which are malicious and which are benign. This takes extracting more information about the binaries and their activity. Many questions can be asked to provide context about the behavior of the binaries in an organization. In this blog post, we will look into several important examples:

• Child Processes
• Network Communications
• Threat Feeds

With this enriched context, you can score features to determine the potential threat level of a particular binary and prioritize which binaries should be investigated in greater depth.

What Can be Learned from Threat Intelligence?

One of the first things you can do to determine whether a binary is malicious or not is to check them against threat intelligence services, such as VirusTotal. In some cases, these services enable you to quickly and easily determine whether a binary in your environment puts you at risk. If a binary is flagged by multiple antivirus engines, it’s a good indicator that the binary is malicious and you can take action to remove it.

However, if a binary is marked as benign by threat intelligence services, or does not exist in their databases, it doesn’t mean it’s not malicious. It might have been uploaded just recently (and is still unflagged by different AVs), or it might also be a built-in system binary (known also as “Living Off the Land” binaries) that is being abused. It still may be a threat, which is why it’s important to look at additional behaviors, such as the child processes and network communications of the binary, for additional context (see next sections).

Since attackers use a variety of built-in system binaries maliciously, many security products and detection rules attempt to detect these behaviors (at Hunters, we maintain a list of binaries, similar to the lists offered here, but you can research and create such a list yourself). There are also a number of detection rule sources and repositories that you can monitor to find out if there are suspicious flags, suspicious parent-child relationships, etc. to watch out for.

However, these rules often rely on detecting these binaries by their process name - for example, this Sigma rule for detecting suspicious PowerShell flags - which allows a common defense evasion technique of simply copying the built-in binary to a different name, and only then executing it.

What these attackers cannot change, is the OriginalFileName field in the binary’s executable metadata (in Windows executables). Threat intelligence services such as VirusTotal, or advanced endpoint sensors such as Sysmon, can be used to find discrepancies between the OriginalFileName of the binary and the process creation name it executed with, to detect attackers trying to evade detection with this technique.

What Can be Learned from Child Processes?

In general, we can learn a lot about a binary by looking at its child processes. This is especially interesting when the suspicious persistent binary is “unknown” (not an OS built-in binary). Adversaries can write malware that utilizes native OS APIs, and then they might not need to create any child processes, but malware writers often opt not to do so, for two reasons:

1. Laziness, as it’s much easier to use built-in functionality rather than develop it yourself
2. Distancing, in this way the primary malicious binary contains less code, and calls less APIs which can be detected as malicious which can help evading security products.

Even when the suspicious persistent binary is a built-in OS binary, its child processes are interesting – as built-in binaries that allow execution are perfect for establishing persistence while seeming benign, allowing fully fileless attacks. For example, registering wscript.exe (which is a known and signed tool by Microsoft), with a command-line running a remote script, to run persistently with an autorun registry key, does not seem so rare or suspicious and does not leave files on the disk. To detect this as an attack, you will need to look at the activity related to the execution of that wscript, such as its child processes, its command-line, executed scripts and network activity (which we will talk about next).

The large number of built-in system binaries provide a wide range of useful features and abilities for attackers, each of which could be utilized after successful persistent execution for different purposes and different parts of the kill-chain. Below are examples of several tactics and relevant binaries that are interesting to hunt for as child processes:

• Discovery – the most prevalent attacker tactic (according to recent threat intelligence reports), and for good reason – this tactic encapsulates many binaries that can be used:

  • net.exe, for enumerating the local users, domain groups and much more (net users, net groups /domain)

  • tasklist.exe, for enumerating all running processes

  • ipconfig.exe, for gathering information about the victim’s IP address and the network it is in

• Command and Control – binaries that can be useful, for example, for downloading the next stages of a malicious payload, or for fetching commands from the C&C server

  • curl.exe (for downloading payloads/commands)

  • bitsadmin.exe (for downloading payloads/commands)

• Privilege Escalation – binaries that are useful if the persistent binary is under-privileged

  • mavinject.exe – can be used to inject code into other processes and elevate privileges

• Defense Evasion –

  • regsv32.exe (can be used to execute malicious DLLs in a less suspicious context)

  • mshta.exe (can be used to execute malicious DLLs in a less suspicious context)

What Can Be Learned from Network Communications?

Network communications is a vast area, however it can prove effective to hunt in because it is a critical phase in the kill-chain that all attackers must tread through. Each persistent binary may create network connections, potentially examinable in the following ways:

• Whether the communication is using an inherently higher-profile port. For example, port 22, 3389, and 88 which can indicate SSH, RDP or Kerberos traffic are usually more interesting for an attacker to use internally than port 80, 443 and 53 that can indicate HTTP/HTTPS or DNS traffic

• Whether the connections are abnormal or common – do they follow expected behavior and patterns? We, at Hunters, maintain a database of known benign (process, port) tuples that we can quickly compare the traffic to (see snippet below), however, you can also manually ascertain whether the traffic is normal by analyzing the process name and port. For example, communication over port 88 is usually seen initiated by the LSASS.exe process, and any novel process communicating on this port is something that is worth being aware of.

• More about the destination IP or domain, such as its geoIP info, certificates, domain name, registration time, etc. This can help you determine the risk-level of the communication.

• The length of time and frequency of the interactions with this IP address. For example, communications at regular intervals could indicate beaconing behavior (or benign software updates for that matter, which is why it is always important to look at all the components together)

For each IP, you can build a prevalence score, which can help determine whether the network access is abnormal or not. Here is what you want to know:

• How many hosts accessed this IP? If no other host or processes accessed it, this should be noted.

• How prevalent is the process (name and hash) that communicated with this IP address?
• When was the first time there was a connection to this address?

  • If this is the first time that a persistent binary has accessed this IP address, it is interesting to check again repetitively in the coming days. If this access remains rare – and no other processes or hosts ever contacted this IP, be sure to raise another “flag” and take into consideration.

Snippet of known composites of Remote Port >> Destination IP >> Process Name

Scoring the Threat Level

After you’ve extracted additional contextual information about the persistent binaries in your environment, you can start to score them to identify the ones that are the most suspicious and potentially pose the biggest risks, so you know where to prioritize your investigation and remediation efforts. Some factors will be easy to score – you can even create rules to automatically assign scores for those that are clearly malicious, such as the ones that show up in a number of threat feeds. Some factors, however, can’t provide a definitive answer about whether or not a binary is malicious – they are more nuanced and take more correlation and investigation before a conclusion can be made.

For example, most trojans that start on boot time will try to connect to their C&C server, but there are many legitimate programs that also try to connect to a server (e.g. to check for an update). Because of this, that fact alone isn’t enough to make it a high priority binary. However, when combined with frequency, geoIP, and other information collected, that binary may go up or down in terms of its risk score.

At Hunters, we have developed machine learning algorithms that help you weigh in all these factors and score the binaries, so you can prioritize the ones that have the highest probability of being malicious. We treat this problem as a supervised learning problem, where benign samples have a score of “0” and malicious ones have a score of “100.” We continue to build and adapt our dataset, based on samples we see from our customers and our lab environment.

Regardless of whether you manually investigate and score the binaries or have a solution, like Hunters XDR, do it for you, simply knowing where you are at risk can give you an edge against the attackers. By honing in on the binaries that are potentially malicious, you can make it harder for them to operate and can take steps to make sure they are never able to ever accomplish their attack objectives.

For more information, or to see how we can automate the hunting of malicious binaries, as well as other attack tactics, operating in your network, please request a demo.