Ian Gaither

This week I was presented with the task of identifying whether or not a particular file was malicious, and if it was, to understand what it was doing and how. This particular post is about one specific piece of malware I found and identified, how it worked, and how I designed a Yara signature to detect it.

Analyzing the Malware

The particular file in question has the MD5 Hash: 00670F2B9631D0F97C7CFC6C764DD9D9.

When I approach these files, I generally start with a simple string dump as you can gather a lot of information about what a file does from its string contents.

In this case I used the tool FileInsight where I was able to immediately identify some potentially malicious behavior. There was a set of command line calls to web addresses that were mostly nonsense.

While this isn’t guaranteed to be malicious, it immediately threw up some red flags as its not clear what these domains are for and the sheer number of them indicates that potentially its searching for valid update servers. I then started to look further into the strings for other potential signals which might help me identify how the malware functions. I ended up finding the following set of references to executable files:

Upon reaching for a web browser for a quick google search I was met with numerous warnings about the file “msns.exe” which seemed to be linked to some kind of trojan backdoor. A bit more digging the in the file told me that hau.exe was likely the original name of the file and that qusla.exe was set up to autorun upon a windows restart via some registry key hacks.

Between the autorun setup (which also hid the file with the attrib command), the various executable files and the obscure web pages, it was pretty clear that this file was malicious. It likely functions as a kind of backdoor/dropper which pulls information down from the internet to update or expand its attack. Without attempting to download those additional files its difficult to tell what the actual impact of this malicious software would be, but clearly it’s meant to create a backdoor into the system that can be further exploited down the line.

Yara Signature

In order to identify this malware in the future, I used a language called “Yara” which is designed to parse memory and files for specific string signatures. In doing so, it can help automate the identification of malicious files by finding common patterns in malware and flagging files which share those patterns. Now that I had an understanding how of the file worked, I wrote what’s called a “Yara Signature” in order to identify this file in the future:

rule malwaredetect
{
strings:
$str1=”hau.exe” wide ascii
$str2=”qusla.exe” wide ascii
$str3=”REG ADD HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run” wide ascii
$str4=”Program Files\\Internet Explorer\\IEXPLORE.EXE” wide ascii
condition:
($str1 or $str2) and ($str3 and $str4)
}

To start, the wide ascii addition is because the various strings and data in the file are encoded in different formats, requiring the strings to be considered under both formats. I even found the name of a function referencing the encoding process.

The first set of conditions (str1 and str2) are based on names that I found within the file using the string dump tool inside of FileInsight. As I mentioned above, the first filename seems to be the original name of the file as indicated by the metadata built into the file.

The second executable is referenced multiple times and specifically is the executable added to windows autorun via registry keys.

The reason I chose these first two conditions specifically is that they are clear unique indicators of the file and as long as it’s not modified, it will be easy to detect it via either of these executable names.

The second set of strings are effectively detecting what could be considered malicious behavior. I added this additional set of rules in case either of the names in the program is modified, it will still be able to detect the piece of malware. The first of these conditions (str3) is meant to detect the addition of programs to the autorun folder via registry keys. While not inherently bad, in conjunction with str4 which detects a web request via internet explorer, these two strings can be a clear indication of malicious code which restarts a process on startup and fetches data from web pages behind the scenes. This behavior combined with either of the two executable names is a pretty big red flag that the file is potentially malicious and is acting as a dropper for further malicious behavior.