Posted: August 29, 2018 by

Last updated:

In this series of articles, we provide an in-depth discussion of fileless malware and their related attacks. In part one, we cover a brief overview of the problems with and general features of fileless malware, laying the groundwork for technical analysis of various samples employing fileless and semi-fileless methods.

Traditionally, malware attacks as we have always known them are files written to disk in one form or another that require execution in order to carry out their malicious scope. Fileless malware, on the other hand, is intended to be memory resident only, ideally leaving no trace after its execution. The malicious payload exists dynamically and purely in RAM, which means nothing is ever written directly to the HD.

The purpose of all this for the attacker is to make post-infection forensics difficult. In addition, this form of attack makes it nearly impossible for antivirus signatures to trigger a detection. In some specific cases, as with SamSam, the only way to even retrieve a sample to analyze would be to catch the attack happening live. This is one of the biggest challenges when dealing with fileless malware.

Fileless malware: the series

In this series of articles, we will discuss the technical details of all types of fileless malware and their related attacks in depth. We will cover a brief overview of the problems with and general features of fileless malware, laying the groundwork for the specific in-depth technical analysis of various samples employing fileless methods. Finally, we will finish off with some theoretical fileless attacks and conditions.

Evolution of fileless attacks

Before continuing, it would be beneficial to take a look at an article we wrote a couple of years ago, covering the basics of fileless attacks.

Now, fileless attacks are not necessarily a new thing, as we saw memory-resident malware in the wild over 15 years ago. One example is the Lehigh Virus, in which it “fills an unused portion of the of the host file’s code in its stack space, causing no increase in the host’s size. It can infect another COMMAND.COM file if a DOS disk is inserted while the virus is in memory.”

However as time goes on, the techniques and tools used to carry out these attacks have become more and more advanced. In fact, this evolution is what has made fileless malware receive a lot of attention among security experts in recent years.

The progression over the years has been interesting:

As mentioned with Lehigh, the virus infector actually contained the malicious code and the payload running in memory.

Going forward in time, malware such as Poweliks used a “NULL” Runkey (which makes the content invisible) in the registry to run JavaScript and used PowerShell to run an encoded script hidden elsewhere in the registry. Essentially, the payload was stored in the registry, retrieving, decoding, and executing during runtime only.

Modern-day exploit kits, such as Magnitude EK, can stream the payload and have it executed without dropping it on disk first.

Malware like DNSMessenger retrieves the malicious PowerShell script from a C2 server.

SamSam writes an encrypted malware payload to disk, and is only decrypted when a script is manually run by the attacker feeding the decryption password.

The problem with fileless malware

When a SOC team or an in-house security engineer monitors a company’s network and receives an alert of suspicious activity during threat hunting, they can only hope that there is traditional, file-based malware involved. Why? It’s much easier for them to be able to track what damage has been done, as well as the scope of the attack.

Having traces of a file-based malware in the network gives the SOC team a definitive starting point to review. These files allow engineers to trace the malware’s origins and usually give a clear idea of how the network was breached. Whether it was via email that linked to a malicious download or website compromise, having the file history provides a clean timeline that ultimately makes the job that much easier. Even further, having the binary allows SOC teams to analyze the code and see exactly what went on, and which systems and data were targeted.

I like to make the comparison of fileless malware to a manual attack that a hacker might carry out if he gained direct access to a remote machine. Fileless malware is, in many ways, identical to the manual hacker approach, but instead of having to crawl around the remote victim, fileless malware can be executed automatically. In many cases, the exact same tools used by the manual hacker are used by fileless malware.

For example, an attack using PowerShell script execution uses built-in Windows tools to perform malicious activity. Since tools like PowerShell are typically whitelisted (as they are used on a daily basis for non-malicious activity), both manual attackers and fileless malware have a free tool at their disposal to carry out the attack. This makes malicious activity much more difficult to trace for a SOC team. There is no file to trace the history of. The security engineer must now look at other artifacts and logged events to try and form a conclusion. Whether it was a fileless attack or a manual breach, it leaves the security engineer with the same problem.

Mitigation

Now, there are ways to help fight this. I continue to call it a problem because handling and preventing these types of attacks are an ongoing process. The difference between benign PowerShell usage and malicious usage can sometimes be minute. An untrained eye may look at PowerShell’s execution and activity and not realize it is malicious at all.

Alternatively, the exact opposite often occurs. The observer may look at a benign activity log and think it is suspicious. The fact that discerning between these two conditions is tough even for security experts is why this problem is incredibly difficult to solve with modern technology. These types of attacks create a scenario where the solution is not an exact science. It is a problem that is ongoing and advancements continue to be made.

As I mentioned before, some of these attacks create a scenario of “living off the land” in that they leverage built-in Windows tools. Because of this, one method to prevent this attack would be to identify the threat at its point of delivery, before it gets on the system.

Let me elaborate a bit. In the example of the fileless/in-browser exploitation, it is important to first try and block the attack before it begins. This is why Malwarebytes developed technology like exploit mitigation in its software programs. Monitoring memory and examining the chain of execution is a big first step in being able to generically block these attacks from taking place. Our exploit mitigation tech has historically proven to be effective against this type of attack. However, even if the code is able to infect the system, a good endpoint protection solution can identify the anomalous activity, track down hidden code, and remove it from the system, which will disrupt the malware’s ability to restart after reboot.

As I explained, the fight is ongoing, which is why a big part of making sure these threats cannot do damage is also the responsibility of the SOC team themselves. Patching, and enabling logging and access control are a necessary precaution. Upkeep can sometimes make all the difference as the first and final line of defense. This will also help in speeding up reaction time in the event of a compromise.

Future series: fileless and semi-fileless types

The focus of the rest of this series will be to cover fileless malware types and attacks from about the last five years. The techniques used among this group are most common and provide better preparation and useful knowledge when dealing with any future fileless malware attacks.

In addition, we will look at not only pure fileless malware, but also some semi-fileless attacks. For example, Kovter uses non-ASCII characters to create unreadable registry keys that hold obfuscated JavaScript. In this case, the malicious script technically does exist on the disk as registry keys, however, it is not a file on disk in the traditional sense.

SamSam is another type of malware that I consider semi-fileless, in that after obtaining the files involved in the attack, you still do not have enough information to analyze the payload. While there are some files on disk, such as loaders and encrypted payloads, the payload is inaccessible unless you intercept the script that started the whole chain of events.

Tune in for part two of this series, where we will cover the technical details of the various tactics and techniques used in modern-day fileless attacks by running through a few custom demonstrations.