Fileless Malware is one of the top cyber threats that can infiltrate your network and cause serious damage. Take a look at what hackers know about fileless malware and you should too.
What is Fileless Malware?
Fileless malware is a malicious code that does not require using an executable file on the endpoint’s file system besides those that are already there. It is typically injected into some running process and executes on in RAM. This makes it far more difficult for traditional AV and other endpoint security products to detect or prevent because of the low footprint and the absence of files to scan.
There are many ways to run code on a device without using executable files. These often utilize systems processes available and trusted by the OS.
A few examples include:
- Batch files
- Mshta and rundll32 (or other Windows signed files capable of running malicious code).
Another type of attack that is considered fileless is malware hidden within documents. Although such data files are not allowed to run code, there are vulnerabilities in Microsoft Office and PDF readers that adversaries can exploit to obtain code execution. For example, an infected document could trigger malicious PowerShell command. There are also a few built-in functionalities that allow code execution within documents, like macros and DDE.
How Does Fileless Malware Work?
Traditionally, AV and other endpoint security products have focused on files (executables) to detect and prevent malware. There are several advantages to this. Files can be hashed, queried in reputation services, examined by both static analysis and machine learning, and easily excluded for false detections.
But for many attackers, the name of the game is monetary gain: threat actors aim for cost-effectiveness, seeking the highest return for the least amount of effort. Yet the rewards for creating and delivering file-based malware diminish as soon as it ends up on public feeds. If the malware’s signature is detected two days after release, the attacker’s ROI (return on investment) may be significantly less than expected, or even negligible. Another reason fileless malware is compelling to threat actors is that security products cannot just block the system files or software that are utilized in these kinds of attack.
Over the past few years, threat actors have increasingly turned to fileless malware as a highly effective alternative. Source
What Hackers Know About Fileless Malware
One of the reasons ﬁleless malware is so compelling is that security products cannot just block the system ﬁles or software that are utilized in these kinds of attacks. For example, if a security admin blocked PowerShell, IT maintenance would suffer. The same applies to blocking Ofﬁce documents or Ofﬁce macros, which would likely have an even bigger impact on business continuity.
The lower footprint and lack of “foreign” executables to scan makes it difﬁcult for traditional AV and other endpoint security products to detect or prevent these kinds of attacks.
Enterprises understand that the lack of effective protection from ﬁleless malware could leave their organization extremely vulnerable. As a result, security vendors came under pressure to address this growing threat and created all kinds of patches in order to claim (or to demo) their “ﬁle-less attack” coverage. source
Fileless Malware Detection Techniques
Unfortunately, many of these attempts to solve the problem are less than ideal. Here are some of the common solutions, and why they are inadequate:
- Blocking PowerShell – as noted above, PowerShell has become an essential tool for IT teams and has largely replaced Microsoft’s old cmd tool as the default command-line utility. Blocking it would cause severe disruption to IT teams. More importantly, from a defensive point of view, blocking it would be futile: there are other ways to use it that bypass the PowerShell.exe block. To name a few:
- Run PowerShell with dlls only with a simple rundll32 command using PowerShdll.
- Convert PowerShell scripts into other EXE ﬁles with tools like PS2EXE
- Use malware that utilizes its own copy of PowerShell.exe or modiﬁes the local PowerShell to avoid recognition of PowerShell by security products
- Embed a PowerShell script in the pixels of a PNG ﬁle and generate a one-liner to execute it using Invoke-PSImage
- Blocking MS Ofﬁce macro ﬁles – in an attempt to eliminate this attack vector, Microsoft added an option to disable macros as a site setting (starting in Ofﬁce 2016). However, most environments still allow them, so security vendors have mainly tackled this in two ways:
- Block macros across the board – this enforces the same restrictions being offered by Microsoft for organizations that can do without
- Extract the macro code for static analysis or reputation checks – This can work in some cases. However, the shortcoming of this approach is that such code is extremely difﬁcult to classify and detect within a tolerable false positive rate, especially for never-seen-before malicious macros. In addition, very few repositories of benign and malicious code exist. Another option is looking for common functions typically found in attacks, but again these are variable and not widely-cataloged.
- Server-side detection – Some products use agent-side monitoring only and make the decision on the server or in the cloud. This approach has the same disadvantages as any detection that does not happen on the
What can be done to mitigate such attempts?
The key is to look at the behavior of processes executing on the endpoint rather than inspecting the ﬁles on the machine. This is effective because, despite the large and increasing number of malware variants, they operate in very similar ways. The number of malware behaviors is considerably smaller than the number of ways a malicious ﬁle might look, making this approach suitable for prevention and detection.
The behavioral approach is extremely good at detecting and preventing this type of attack because it is agnostic regarding the attack vector.
How to Detect Fileless Malware
Through our Managed Detection and Response service, Cybriant’s security team monitors all activities on the agent-side at the kernel level to differentiate between malicious and benign activities. Since the agent already holds the full context: users, processes, command-line arguments, registry, ﬁles on the disk, and external communication, any malicious activity can be effectively mitigated completely. We can rollback all the bad deeds and allow the user to work on a clean device.
We help you waive the hidden costs of keeping your network clean from bad code, across your entire network.
To implement this approach effectively, Cybriant employs the concept of “Active Content”, which solves the problem of apportioning blame to the root cause of malicious activity.
For example, suppose a user downloads a malicious attachment via Outlook, which then tries to encrypt ﬁles on the disk. In this scenario, blaming and quarantining Outlook as the parent process would miss the true source of malicious activity. Instead, Outlook should be included as the source for forensic data to show but not mitigate against. You do, however, wish to mitigate the entire threat group, regardless of any additional ﬁles dropped, registry keys created, or any other harmful behavior.
Using Active Content lets us determine — and point the blame towards — the root cause of a given malicious ﬂow, with or without a ﬁle, and allows the customer to handle the incident accurately. Source