Fileless Malware
Turning ourselves into Ghosts
“ Hunting for a fileless threat can be a tedious and labor-intensive task for any analyst. It is, most often than not, extremely time-consuming and requires a significant amount of data gathering. On top of that, the traditional tools, methods, and defenses seem to be less effective when dealing with these almost invisible threats. Threat actors are frequently using attack techniques that work directly from the memory or using legitimate tools or services pre-installed in the system to achieve their goals (Trend Micro, 2017). It is a popular technique among targeted attacks and advanced persistent threats (APT), and now it has been adopted by conventional malware such as Trojans, ransomwares, and even the most recent emerging threat – cryptocurrency miners. In some incidents, searching for a malicious file that resides in the hard drive seem to be insufficient. This study explores the different variations of fileless attacks that targeted the Windows operating system and what kind of artifacts or tools can provide clues for forensic investigations.”
Fileless malware
Has been described as an attack that does not entail files being written onto the disk, this is partly true, as we have a few malwares that leave something behind to execute malicious code into memory and then delete itself to leave no traces behind. Its arrival can be through different methods, Exploitation, Brute-Force, USB and typically a phishing email with attachments.
To understand Traditional Malware this is typically done when a Binary or File is downloaded to disk and then executed with traditional malware this file is needed on the host machine to execute its payload. Below you can see the flow of traditional malware.
Traditional Malware
SANS image
Fileless Malware
The point of entry of Fileless malware is like traditional malware, anything the previous one can do, fileless malware can do as well. Unlike the traditional malware this does not need to store malicious code into a file and save this to disk, it can leverage exploits or launch scripts directly from memory using whitelisted tools (I will touch later this), The image below explains the chain of fileless malware attacks.
Fileless Malware
SANS image
Exploit:
The fileless attack that arrives via Exploit may be referred to as “Completely Fileless”. RCE (Remote Code Execution) allows an attacker to load shellcode directly to the memory without writing any files to disk.
Malicious Website/MailSpam/Phishing Email:
Arrival via malicious websites or phishing emails uses script-based programs such as Macros, PowerShell, VBScript, JavaScript, HTA, etc., to run the malicious code directly to the memory. Typically, the initial script acts as a downloader which connects to a malicious host and downloads the payload. The transition to fileless moves once the script runs in memory and deletes the document upon execution.
Persistence
The persistence would depend on the end goal of the attacker. Fileless malware may not be persistent at all. Since the malicious code is already running in memory, it can already launch its payload. Without any persistence, a simple reboot would clear the code in memory. WMI or Scheduled Tasks are common fileless persistence method that attackers use.
Some reasons to use Fileless Malware in an Attack
- Stealthy: Fileless malware uses legitimate tools to proxy execute payloads, sometimes it’s difficult to block these legitimate tools since they are used in an environment regularly
- Living-off-the-land: The legitimate tools are installed be default, what more reason do you need.
- Trusted: These tools are trusted and sometimes pass unnoticed when executing malware
Memory Injection
Memeory Injection technique involves hiding malicious code in the memory of a legitimate process. While processes that are critical to Windows activity are running, this malware distributes and re-injects itself into these processes, making it trickier to detect as these don’t trigger traditional red flags or whitelists.
Fileless malware exists only in a computer random-access memory (RAM) meaning that nothing is ever written directly to the hard drive. This makes it more difficult to detect as there are no stored files for defensive security software to scan, I will work on some samples that give an idea on how fileless malware can execute and stay living in memory, research from Microsoft categorizes them in 3 types:
In the research it states
Type I: No File Activity Performed
A fully fileless malware can be considered one that never requires writing a file on the disk. How would such malware infect a machine in the first place? One example is where a target machine receives malicious network packets that exploit the EternalBlue vulnerability. The vulnerability allows the installation of the DoublePulsar backdoor, which ends up residing only in the kernel memory. In this case, there is no file, or any data written on a file.
A compromised device may also have malicious code hiding in the device’s firmware (such as BIOS), a USB peripheral (like the BadUSB attack), or in firmware of a network card. All these examples don’t require a file on the disk to run and can theoretically live only in memory. The malicious code would survive reboots, disk re-formats, and OS reinstall.
Infections of this type of cab be particularly difficult to detect because most antivirus products don’t have the capability to inspect firmware. In cases where a product does have the abilities to inspect and detect malicious firmware, these are still significant challenges associated with remediation of threats at this level. This type of fileless malware requires high levels of sophistication and often dangerous, threats of this type are uncommon and not practical for most attacks.
Type II: Indirect file activity
There are other ways that malware can achieve fileless presence on a machine without requiring significant engineering effort. Fileless malware of this type doesn’t directly write files on the file system, but they can end up using files indirectly. For example, with the Poshpy backdoor attackers installed a malicious PowerShell command within the WMI repository and configured a WMI filter to run the command periodically.
It’s possible to carry out such installation via command line without requiring a backdoor to already be on the file. The malware can be installed and theoretically run without ever touching the file system. However, the WMI repository is stored on a physical file in a central storage area managed by the CIM Object Manager, and usually contains legitimate data. Even though the infection chain does technically use a physical file, it’s considered a fileless attack because WMI repository is a multi-purpose data container that can’t be detected and removed.
Type III: Files required to operate
Some malwares can have a sort of fileless persistence, but not without using files to operate. An example for this scenario is Kotver, which creates a shell open verb handler in the registry for a random file extension. Opening the file with such extension will lead to the execution of a script through the legitimate tool mshta.exe
When the open verb is invoked, the associated command from the registry is launched, which results in the execution of a small script. This script reads data form a further registry key and executes it, in turn leading to the loading of the final payload. However, to trigger the open verb in the first place, Kotver has to drop a file with the same extension targeted by the verb (in the example above, the extension is .bbf5590fd). It also must set an auto-run key configured to open such a file when the machine starts.
Kotver is considered a fileless threat because the file system is of no practical use. The files with random extensions contain junk data that isn’t usable in verifying the presence of the threat. The files that store the registry are containers that can’t be detected and deleted if malicious content is present.
Below are some programs and examples of what can be considered fileless malware.
Programs that can achieve Fileless Malware
- PowerShell.exe
PowerShell a powerful language that is built in Windows since Windows 7 it provides access to COM and WMI, it also provides a hosting API with which PowerShell runtime can be embedded inside other applications. An example of a Fileless technique with PowerShell can be the following:
Shell
No detection and no file left in the workstation since this is directly executed from the Console and the file has no need to be on disk and run.
- WMIC
WMIC provides a command-line interface for Windows Management Instrumentation (WMI). WMIC is compatible with existing shells and utility commands. WMI has the ability to proxy execute XSL files from remote location or to even start processes on its own let’s check some examples.
- WSCript.exe
Windows Scripting Host it provides the ability of scripting comparable to batch files, but with a wider range of supported features. It supports multiple languages such as VBScript (VBE, VBS) and Jscript (JS, JSE) it can also be worked with WHS which is a language independent filename extension. The advantage of this is that it allows multiple scripts (“Jobs”) as well as a combination of scripting languages within a single file.
In the following example will use VBScript, Jscript and Python in the same file and have an execution even though we are combining 3 different Scripting Languages:
For python or any extra languages to be working these need to be install and added to the PATH of the system and registered as a scripting alternative for WSH a great target for this are most likely Developer Workstations in the example we have a file on Disk so this comes into consideration as the script isn’t malicious only the file it calls after which can be PowerShell, Mshta, MSbuild that can execute our payload in-memory
File:
VB:
JS
Python popping calc
- Cscript.exe
Same as WSCript the difference is that this one does give you a CONSOLE window
- Scriptrunner.exe
I couldn’t find much information on what Scriptrunner is, but it seems to be a tool that allows to run multiple scripts instead of building a script that runs multiple things it helps to achieve this all with one line. This allows proxy execution via SMB
Example, there seems to be a warning when executing on remote servers
But we will ignore it and execute
- Regsvr32.exe
Is a command-line utility for registering and unregistering DLLs and ActiveX controls in the operating systems Registry. It’s a Microsoft signed binary the allows proxy execution (which is the ability to call remote files). This requires elevated permissions
- Mshta.exe
MSHTA is a utility that executes Microsoft HTML Applications (HTA) files. HTAs are standalone applications that execute using the same model and technologies of Internet Explorer, but outside the browser, it can run scripting languages such as JScript and VBScript.
Request:
Execution:
Let’s not stop with these, we are familiar with Execution via Microsoft Signed Binaries, but we also spoke about exploitation of vulnerabilities as these do not touch Disk, since malicious packets are sent to the target machine and inject our shellcode where necessary, a great example of the recent BlueKeep method which exploits the RDP protocol it’s a major vulnerability affecting primarily Windows 7 machines, other exploits can be EternalBlue.
The need of a file was completely unnecessary, and execution was done remotely.
C#
It gives access to an infrastructure of functions that developers use frequently and can build off. A few C2s have a great feature that allow us to execute C# binaries in memory without the need of placing these binaries on the disk. This is a great Post-Exploitation method to stay in memory.
Example:
I executed the Seatbelt tool to show me the most recent files the user has interacted with, and if we check our current path there is no Binary dropped to Disk.
After some talk with my Sensei it also came to mind that User Accounts may allow us to stay in memory without touching Disk onto a Targeted Machine some examples may be, PSRemote, RDP, SSH and/or Poor Configuration
PSREMOTE:
The feature from PowerShell to gain a sessionl to execute commands on a remote host.
RDP:
The remote Desktop Protocol which allows users for a fully interactive GUI remotely.
Poor Configuration:
When software is installed with poor security implementations a great rule would be such as only allowing specific users access to these features or giving the software sufficient permissions to only execute at a certain level of authority with the possibility of avoiding Administrator or SYSTEM Access. In this Demo what if someone left an Emergency Back-Door to access the system in case they get locked out? Well, this happens:
PHP Backdoor (Emergency Access)
This technique used there was no file left behind (well by the attacker) this is a legitimate “Emergency” Access that developers left behind for a “just in case”.
With these Demo’s and understanding we have techniques and methods on how to achieve a “Fileless Malware” to execute onto our Target machine and stay hidden. Staying hidden once already in the network and achieving to stay in memory would be already up to the Operator an example would be “Process Injection” is a well-used technique to stay hidden and in memory inside a legitimate Windows Process.
And lastly we also have hardware as a method of fileless malware a great demonstration for this would be the infamous Rubber Ducky and malicious USB that impersonates a Keyboard and interacts with the Computer if it were a user typing these commands no file touches disk and commands can be executed directly on a Command or Scripting Interpreter, such as CMD or PowerShell.
Demo:
References:
https://us.norton.com/internetsecurity-malware-what-is-fileless-malware..html
Python in WSH
https://help.objectiflune.com/en/knowledgebase/KB/HWT/PPW/KB1504.html