Fileless malware most commonly uses PowerShell to execute attacks on your system without leaving any traces. This type of attack is also known as a zero-footprint attack and can be particularly hard to detect because it does not rely on infiltrating external malicious (and detectable) binaries into your systems. Rather, it uses your own tools against you.
From a cybersecurity perspective, what makes fileless infections so difficult to counter is that they get around many of the key processes you can use to secure your system. With no file to act as the infection source, virus scanners cannot detect fileless attacks, and signature-based detection systems don’t fare much better. That doesn’t mean that fileless malware is undetectable. Rather, it means that you need to deploy a system that can detect the type of activity that this kind of attack generates. One such system is Varonis.
Get the Free Pentesting Active
Directory Environments E-Book
There has never been a better time to deploy activity monitoring software like this because it seems that attacks that use fileless malware are on the rise. Last year brought many tech headlines about this technique, and security experts are saying it’s on the rise.
Our course on PowerShell will help you keep your data safe, while we’ll explain what fileless malware is, how it works, and how to stop it from infiltrating your computer system and stealing your data. Think of this article as Fileless Malware 101, and as a complement to our more detailed guides.
- What is Fileless Malware and How Does it Work?
- Reasons Attackers Use Fileless Malware
- Malware Examples and Attack Types
- Detection and Prevention of Fileless Malware with Varonis
Fileless Malware Guides
At Varonis, we’ve been pointing out the dangers of fileless malware for ages, and way before the recent spike in attacks. A couple of years back, we wrote a series of detailed guides on fileless malware. These covered everything from the basic principles of this type of attack to more advanced obfuscated VBA scripts.
What is a Fileless Malware Attack?
Let’s start with the basics. A fileless malware attack typically (but not always) starts with a phishing mail containing a payload that automatically establishes contact with the remote hacker — e.g., through a remote access trojan or RAT. So with little effort, the cyber thieves are behind the firewall and have the ability to launch native apps, as well as navigate and search the file system for sensitive data.
Crucially, fileless attacks don’t have to copy external binary executable to devices. Instead, they can use existing software, particularly PowerShell, to download additional scripts and run them purely in memory, making them extremely difficult to detect.
Then once an attacker has access to your system, they use a variety of existing tools and techniques to move laterally within the system and continue to search for sensitive data beyond the initial entry point.
SecureWorks has pointed out that even plain Windows Remote Desk Protocol (RDP) is used by attackers to effectively become insiders, allowing them to hop between servers. And then vanilla FTP, which is usually available on the system, can provide the means to exfiltrate data.
We might add that other utilities such as ncat, psexec, ssh, and PowerShell tools play an important role in reducing malware baggage. There’s not too much you can do about putting a ban on the aforementioned: they’re essential for IT admins, developers, and many other users.
But when hackers exploit on-site software, it means that they won’t leave much of a forensic trail. The new breed of attack vectors circumvents firewalls (or uses public ports), avoiding detection by enterprise-grade intrusion systems and evading virus scanners.
How Does Fileless Malware Work?
Fileless malware essentially works by repurposing existing Windows system tools, like the aforementioned PowerShell but also other scripting languages, primarily VBA and JScript. And then leverage them to run other Windows software. Key point: nothing out of the ordinary would be overserved by a security admin observing these activities
How Does an Attack Happen?
Fileless attacks normally rely on social engineering to get users to click on a link or an attachment in a phishing email. Unlike a standard malware attack, the initial payload file is often a small embedded script. Its job is to get into the “inner sanctum” and then run itself using whitelisted Windows Script Host — wscript.exe or script.exe
Often, these small scripts will be obfuscated or partially encrypted so that obvious keywords can’t be detected by internal monitoring software. Once the scripts are launched by the unsuspecting employee, they will typically trigger a chain of malware downloads that will be hard to detect because they run in memory (see below).
Beyond this general description, there are a few common scenarios in which fileless attacks can occur:
- Windows Management Instrumentation (WMI) and Microsoft PowerShell are some of the powerful tools that hackers use to manipulate almost every part of a Windows system.
- Phishing emails, malicious downloads, and links that look legitimate are the most common ways in which fileless malware is delivered. Unlike typical malware, however, the tiny scripts that lead to fileless attacks are typically encrypted.
- Common user applications like Microsoft Word or Excel are a major delivery mechanism for fileless malware. VBA would be the choice for Office files, but also JScript can be embedded in ordinary files, which can be disguised — through say a .”.doc” suffix — to look like a Word file. In any case, when the file is clicked, the script is launched.
- Lateral infiltration is often the primary objective of fileless malware attacks. Hackers are not only interested in accessing PowerShell or Word . Rather, they will first compromise these systems and then use them to gain access to others.
- Legitimate-looking websites and other watering holes that actually are malicious are another means for fileless malware to be delivered. JS embedded in these sites is an increasing threat.
Reasons Attackers Use Fileless Malware
The primary reason why attackers use fileless malware is that it is far stealthier than binaries, and the scripts are designed to evade virus scanners.
In addition, once an attacker is able to access trusted, whitelisted programs like PowerShell and other on-site tools, they can execute commands without internal monitoring software raising alarms.
PowerShell, in fact, remains the primary target for most fileless malware, and in some places, you may even see this attack type referred to as “PowerShell malware”. The reason that attackers target PowerShell, beyond those already mentioned, are that PowerShell implements a kind of native encryption — the encoded option — that can be leveraged by fileless malware to avoid detection.
In order to understand in more detail the reasons that attackers use fileless malware – and to understand what makes it dangerous – it’s useful to define a few key terms:
- Stealth is a key technique in all types of hacking, but the “ultimate stealth” of fileless malware means that it can evade detection by all but the most advanced threat detection software. Although, ahem, it cannot escape Varonis.
- Living-off-the-land is a term that refers to hackers who use the systems and programs already installed on your system – like PowerShell and JavaScript – to execute attacks. Because these systems are pre-installed and already trusted by both your OS and your threat detection systems, they offer attackers a huge opportunity without the need to infiltrate extra software into your systems.
- Trusted and frequented programs are those that are used by system admins to monitor and manipulate systems. These programs have two key characteristics which make them a target for hackers, and for fileless malware in particular. First, they have high levels of access to many other parts of your network, and in fact, this is what makes them useful. Second, they are highly trusted by all the other programs on your system, which makes spotting malicious activity extremely difficult.
Analyzing PowerShell Samples and Attack Techniques From the Wild
A good introduction to the way that fileless malware attacks work are the scripts we covered in our article on PowerShell. There, we explored the Hybrid Analysis site, which maintains a repository of fileless malware that had been captured in the wild.
Besides the samples, HA also provides great insights into what the malware is doing, so check out the site for yourself. Hybrid Analysis runs the submitted malware in their own sandbox, and monitors for system calls, processes launched, and Internet activity, as well as pulling out suspicious text strings.
For binaries and other executables in particular, where you can’t even look at the actual high-level code, this container technique allows HA to decide whether the malware is evil or merely suspicious based on its run-time activity. And then they’ll rate the sample.
For the malware-free PowerShell and other scripting samples (Visual Basic, JavaScript, etc.) I was looking for, I could see the actual code. For example, we came across this PowerShell creature:
If you’ve read our obfuscation posts, you’ll know that the -e parameter indicates that what follows is base64 encoded. By the way, Hybrid Analysis helpfully provides the decoded PowerShell as well. If you want to try decoding base64 PS on your own, you can run this command to do the work:
$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))
We decoded the script using this technique, and you can see the resulting plaintext PowerShell malware below.
We’ve seen this particular attack style before — in the PS obfuscation series — wherein the base64 encoded PS is itself pulling more of the malware from another site, creating a .Net Framework WebClient object to do the heavy lifting. Why this approach?
For security software that’s scanning the Windows event log, the base64 encoding prevents text-based pattern matching from doing some easy detection – matching on say the string “WebClient”.
Note in the above the sample, the use of the DownloadString method for the WebClient object. This is the way additional PowerShell malware is downloaded and injected into the PS app itself, completely evading detection!
Or so we thought.
It turns out with more advanced Windows PowerShell logging enabled – see this post — you can effectively see the downloaded string in the event log. However, hackers then responded by base64 encoding the downloaded PowerShell from the remote site, so it would then show up in the Windows event log like the encoded sample above. Makes sense, right?
The real-world samples in Hybrid Analysis then take this idea a step further. As we mentioned above, hackers cleverly hide this PowerShell attack in Microsoft Office macros written in Visual Basic and in other scripts. The idea is that the victim receives a phishing mail from say, FedEx, with a Word doc described as an invoice. She then clicks on the doc that then launches a macro that then eventually launches the actual PowerShell.
You can see the Visual Basic script itself is obfuscated so that it evades virus and malware scanners!
Yes, it’s complicated and evil. And this is only a very shallow dive.
In the spirit of the above, we decided as a training exercise to encase the above PowerShell within some obfuscated JavaScript. You can see the results of our hacking handiwork:
There is one technique we borrowed from “in the wild” samples: the use of Wscript.Shell to launch the actual encoded PowerShell. It’s the way you get out of the script environment to interact with the rest of the system.
By the way, JavaScript is on its own vehicle for delivering malware. Many Windows environments have by default the Windows Script Host, which will directly run JS. In this scenario, the encasing JS malware is attached as a file with a .doc.js suffix. Windows will only show the first suffix, so it will appear to the victim as a Word doc. The JS icon is rendered as a scroll-like graphic. Not surprisingly, people will click on this attachment thinking it’s a document.
For our own encasing JavaScript malware, we modified the PowerShell sample above to download a script from a web site we control. The remote PS script merely prints out “Evil Malware”.
Not very evil.
Of course, real hackers are interested in gaining access to a laptop or server, say, through a shell…
Fileless Malware Detection and Prevention with Varonis
When hackers use fileless malware to exploit on-site software, it means that they won’t leave much of a forensic trail. The new breed of attackers is going around firewalls (or using public ports), avoiding detection by enterprise-grade intrusion systems and evading virus scanners.
Of course, implementing two-factor authentication, limited networking for average users, and enforcing password policies are just some of the low-hanging fruit for making it more difficult for hackers to live off the land.
SecureWorks also recommends focusing on attacker behaviors and then alerting when the hacked users’ account’s activities differ from normal. For example, an RDP connection that occurs at an unusual time for that user, files copied or viewed that are not typical for that user, or some other outlier that’s discovered.
Of course, at Varonis this is music to our ears!
Our solutions have been powered by user behavior analytics or UBA long before this has become a trendy topic. With hackers now more focused on using less malware or no malware at all, UBA becomes perhaps the only way to discover you’ve been breached.
That’s something to keep in mind as you plan your security strategies for next year and beyond.
A Final Word
Fileless malware is not only a dangerous threat: it is also a growing one. This type of attack uses your own tools – and in particular, your PowerShell tools – against you, and so can be extremely difficult to detect.
Thankfully, there is a solution. By carefully monitoring user activity on your systems using a tool like Varonis, you can spot malicious activity, and even that created by fileless malware attacks.
