Zeltser Challenge Update

It’s now Day 3 of my Zeltser challenge, and I’m excited to say that after a brief poll on last week’s Forensic Lunch, the theme was decided as Malware Mondays. A huge thanks to Mary Ellen Kennel (@icanhaspii) for her help and allowing me to borrow the name. I’m going to use this chance to ask folks to go check out Mary’s blog and see some of the awesome lists she has put together. Mary publishes an Excel spreadsheet with multiple tabs that contain a wealth of information. She’s also an active contributor to the SANS DFIR mailing list. Thanks for all of your help and contributions Mary!

Malware Monday: Fileless Malware

For today’s post, I’m going to discuss fileless malware. I’m choosing this particular topic for a few reasons:

I just had a discussion with a few students about this, It’s prevalent among many threat actors and malware authors at the moment, It can be a pain in the butt to to detect, and This week, I’ll be taking part in a SANS webcast on fileless malware with Amit Serper from Cybereason. The webcast is this upcoming Wednesday, December 14 at 12:00pm CST. You can find more information and register here.

A Brief Intro to Fileless Malware

Fileless malware is a concept has been around for a few years now, if not more. The general categorization applies to malware that don’t follow “normal” routines, such as dropping a copy of the malicious files on disk. Instead, malware authors and attackers have found that they can bury malicious code inside of repositories like the Windows Registry or run malware solely in memory. These tactics obviously leave less, if any, artifacts on a system and often evade traditional endpoint security products, such as A/V.

Other fileless tactics often involve abusing legitimate operating system features, such as WMI or PowerShell, to execute malicious code on a local or remote system. As WMI and PowerShell allow code execution, de-obfuscation, and a wealth of other capabilities, they have quickly become a favorite of many attack groups.

One important note is that while fileless malware leaves less disk artifacts, it may still need to establish a persistence mechanism. Some fileless malware families, such as Poweliks and Kovter, store their data within the Windows registry and utilize a Run key to establish persistence.

Remember: malware can hide, but it must run.

Other types of fileless malware, such as first-stage malvertising, often exist in memory and do not require a persistence mechanism. It has a simple job, which is to gather system information and download an additional payload. By running only in memory, it can usually get to stage two, at a minimum, before being detected by endpoint security products.

Examples of Fileless Malware

There are a multitude of excellent articles written about fileless malware, including many detailed write-ups and de-obfuscation and analysis techniques. I won’t re-invent the wheel, but instead focus on a variant of the Kovter family to illustrate a couple of points about fileless malware.

Kovter

Kovter has been around for a few years now, and is often associated with ransomware and click-fraud. I’ve investigated quite a few cases of Kovter on clients’ systems, and can say it’s quite a nuisance. Get ready for a trip down the rabbit-hole, as here is a basic overview on how Kovter works:

The malware adds a value to a registry key that utilizes the legitimate tool mshta.exe, used to execute HTA files, to execute JavaScript commands. This “first-layer” of JavaScript, once de-obfuscated, executes and often executes a “second-layer” of JavaScript. The “second-layer” of JavaScript in turn executes malicious PowerShell code, which often executes shellcode loaded into memory.

To get an idea of what the “first-layer” of JavaScript looks like, take a look at this sample over at Hybrid-Analysis:

The readable text obviously shows initiation of a new ActiveXObject that in turn calls a WScript.Shell, which allows for program execution. Furthermore, we can also discern RegRead(“HKLM\\software…), which reads a Registry location. Lastly, we can also see an eval() statement. Every other character is either syntactic or intentionally-obfuscated. This is a good sign that something fishy is going on, unless you’ve got a really evil developer or system administrator.

Note that much of the obfuscated or nonsensical text above, including the SOFTWARE hive key path, are typically generated dynamically per infected host. The following registry key path HKLM\\software\\0XhyxVPNt6\\YXfi2uwWS will most likely contain additional JavaScript, and will be unique to this infected host only. This can obviously cause a lot of issues if the IR team was hoping to generate IOCs to detect activity across an enterprise.

Digging into the analysis further, take a look at this dirty little PowerShell command (the “third-stage” of malware execution)

powershell.exe iex $env:aiaf

Let’s break this down:

powershell.exe, a tool I don’t need to explain any further iex is a alias for Invoke-Expression, used to evaluate the following string $env refers to an environment variable aiaf refers to an dynamically-generated variable assigned by the malware to execute shellcode.

See how tough this can be to track and trace throughout an environment?

Another important note about these malware families is that they use a unique technique to hide in plain sight. Often times, these malware “hide” their malicious registry entries (the “first-layer” discussed above) by assigning a registry key name that begins with a null or 0-byte character. Symantec has a good example of this over here.

Why begin a registry key with a null or 0-byte? Native Windows tools such as regedit.exe, which many system administrators or responders may use for quick triage, cannot display these values and either error out or simply fail silently. You can try to open the key, which may force an error message, and we’re still at a state where we cannot read the offending “first-stage” key. The system, however, has no issue reading the registry key and executing the commands within.

Detecting Fileless Malware

Going through these quick details, DFIR analysts and threat hunters may be wondering how they can possibly look at detecting this type of activity. As previously mentioned, many endpoint security products are waiting for files to hit the disk, scan them with heuristics, and flag them. Some endpoint products monitor for registry changes, but again, the organization is banking on the malware fitting within the profile that the product is looking for. This may not always be the case.

In a threat hunting scenario, I tend to first focus on some of the latter stages of the malware execution. For example, instead of combing through thousands of AutoRun registry keys looking for weird values, I instead like to rely on command-line parameters for mshta.exe or powershell.exe anomalies. Anomalies could include:

parent/child process analysis (see what spawned powershell.exe or what powershell.exe has spawned) or

if available, looking through PowerShell command logs for suspicious iex commands

My former colleague Matt Dunwoody at FireEye put together an excellent article discussing PowerShell Module and Script Block logging. One of my top recommendations for clients facing PowerShell-based attacks is to enable these heightened logging levels and use those for hunting.

If an analyst or threat hunter is able to get raw registry contents, you could run searches or build IOCs for entries that contain suspicious strings. Here’s a few more samples from Hybrid-Analysis.com:

javascript:mN4lqP="vZ";CZ6=new%20ActiveXObject("WScript.Shell");Cbh98KW="Y0HPHd3M";RZ2PP=CZ6.RegRead("HKCU\\software\\O5PDj0b\\LLIogee3");l9WsqL7u="Js";eval(RZ2PP);CPpLn6xZ="EN0pKn4"; javascript:yMnnXW1u="Vk6j1K";z2g0=new%20ActiveXObject("WScript.Shell");n9Ejol2="Mk";H3fhx=z2g0.RegRead("HKCU\\software\\v71I9AH\\5aKzf9QcK");A2LUWrLU="qar";eval(H3fhx);PH0pHVh="r03"; javascript:rhZf05l="QSa";b8m=new%20ActiveXObject("WScript.Shell");UbWE35Nor="Q";qL5Td8=b8m.RegRead("HKCU\\software\\p44WCm\\OoinuDAY");OtgtZYI0="6JEAX";eval(qL5Td8);fGJ2LD="tNH57i";

Note that despite the variant in text, we do have a few static items such as “ActiveXObject”, “eval(“, “javascript:” and “WScript.Shell”. We could build IOCs to look for these particular strings in the registry, especially if they all hit within the same key. There may be a low-level of false positives, but it’s more likely to be malware hiding in the registry.

Wrap-Up

In this post I briefly discussed fileless malware, and took a quick look at an example of a Kovter variant. While this post has barely scratched the surface on fileless malware (there are hundreds, if not thousands, of more examples), it’s important that DFIR analysts are aware of this growing and increasingly-frustrating malware trend. These types of malware can sometimes be difficult to detect, and may force an analyst to find new ways to examine registry hives. But we’re not completely helpless, we just have to get a bit creative with the artifacts that we are analyzing.

Until tomorrow, happy forensicating!