Hunting Fileless Malware: Invisible but not Undetected
Fileless malware attacks are a growing concern in cyber-security with an interesting history that dates back to 2001. After remaining almost silent for several years, this type of threat began to gain fresh traction in 2014 with new concepts introduced at a fast pace. Today such attacks are so common that new strategies had to be developed to identify and contain them.
The security industry refers to such threats in different ways: non-malware attacks, in-memory (or memory-based) malware, living-off-the attacks or volatile threats, though fileless malware appears to be the most common form. Terminology aside, the assumption at the base remains the same:
a malware that operates in memory without requiring external malicious executables.
The concept of fileless malware is not new, in fact it dates back to DOS and some may remember TSR programs: Terminate but Stay Resident applications that could function even after returning control to the user. It didn’t take long for this feature to be abused by virus writers, one of the early examples dates back to 1991, dubbed the Maltese Amoeba, used to infect both .COM and .EXE files:
Followed by many others, including the somewhat popular Walker:
TSR viruses evolved towards a more modern connotation of “fileless” with the infamous Code Red worm that in 2001 infected computers only via network, exploiting a buffer overflow in Microsoft IIS server. The malicious payload existed entirely in memory, with no files written on disk, thus gaining the title of the very first modern fileless malware.
Code Red demonstrated that in-memory approaches were not only possible but also practical, given the right circumstances. It took several, years until 2011, with DuQu first and then finally in 2014, before a new breed of fileless malware gave the start to the wave of threats that is still in fast evolution today. That malware took the name of Poweliks and while technically fileless, it used to hide its encrypted payload in the Windows Registry, through a complex chain of actions that involved for the first time several scripts: a JScript followed by a Powershell script that was used to load and run a malicious DLL.
Poweliks gave birth to the concept of “living-off-the-land” attacks: a family of threats that leveraged on default components provided by the Operating System itself. The peculiar name clarifies the notion of relying on local facilities and not external payloads. This evolution was likely driven by two factors: the adoption of Application Whitelisting and the then emerging EDR technologies, that offered increased visibility over the endpoints and new detection capabilities.
Traditional malware requires a binary payload that can easily be scanned by an AntiVirus, or blocked by an Application Whitelisting software. Binary payloads also present a heavier forensic footprint, that can potentially reduce their stealthiness. Criminals and state actors had to find a novel way of delivering malware: stealthier and capable of bypassing application whitelisting.
Going fileless was a natural step, given the immense flexibility offered by interpreters like powershell and today slightly more than 50% of the attacks we detect are in fact driven by fileless malware.
In terms of analysis a fileless malware attack is quite interesting and it’s of course notable the absence of any external component. As shown in the below storyline, the attacker relied exclusively on powershell, from the initial intrusion down to the lateral movement to the next endpoint:
All components used by the attacker (whoami, notepad, sysprep, cmd etc) belong to Windows and the only payload ever seen on the system was a simple base64 encoded string containing the script used to run various utility functions, from process migration to privilege escalation. What is the complete infection pipeline of today’s fileless malware attacks?
Fileless Malware Infection Pipeline
While the absence of a binary payload is a pre-requisite for a fileless malware, it doesn’t mean that no code is present. Ideally a fileless malware should be delivered through an in-memory process, for instance by exploiting a browser and from there activating the in-memory payload. In practical terms browser – and more generally client-side – exploits are becoming harder to come by, so attackers rely heavily on social engineering. In such a case the malicious code is delivered by a script or a document macro.
A typical infection pipeline is shown in the storyline below, which is part of a recent spear-phishing campaign in which the malicious payload is run via a Office Word Macro:
Such attacks are still considered fileless as the payload is only a text string; strictly speaking no external executable code is ever injected on the victim’s machine. The malicious code runs entirely in the context of a trusted process.
Powershell of course is not the only possible vehicle, WMI (Windows Management Instrumentation) is another powerful tool that is widely exploited by attackers to carry out fileless malware attacks. Poshspy has been one of the first threats to adopt WMI as a vector, though not the first: The Moth, presented in 2008, explored for the first time the possibility of using WMI to create a fileless trojan.
The storyline of a WMI based attack doesn’t differ, in concept, too much from that of a powershell based attack:
Fileless malware combined with LOLbins are a lethal combination: low detection rate and capabilities to bypass Application Whitelisting solutions… Hold on: did we just say LOLBins?
LOLBins: completing the puzzle
LOLBins stands for Living off the Land Binaries and only recently they started to become an essential part of fileless attacks, APT34 (Lazarus Group) was among the first, at the end of 2017, to take advantage of LOLBins combined with a fileless attack (POWRUNER) in one of their attack campaigns. So why adding an additional layer to a family of attacks that is already inherently powerful?
The answer lies in the ability to remain undetected and to minimize the amount of code to deploy by avoiding to reinvent the wheel. A commonly used LOLbin, as seen in the image above, is bitsadmin.exe, a component normally used to schedule background transfers that can be used to download, upload and execute a payload (Mitre technique T1218), possibly bypassing the Application Whitelisting used. Such a technique doesn’t require the presence of download/upload/execute functionalities in the malicious code and at the same time it de-correlates the activities of the malware: several LOLBins are in fact executed in a different context, with no obvious link between the fileless malware used and its actions, also the action is performed by a trusted binary.
To clarify the meaning of de-correlation we can take a look at the below attack storyline that shows, in the same picture, both the fileless infection stage and the activity carried out by the attacker.
The infection stage starts from a malicious document, we can identify the network activity performed by the script while no operations appear to be run by the malicious payload. Shortly after, the actual malware is activated from a different context, that of wmiprvse.exe, that activates a new powershell instance with no apparent link to the initial infection.
LOLbins also help to maintain a low detection profile as they can be leveraged to execute activities that are normal for a specific binary. To clarify with a simple example: if a powershell instance fetching content from outside the corporate network can raise flags, maybe the same doesn’t hold true for another binary that exhibits that behavior during its normal operations. Also it should be noted that Microsoft enabled the analysis of powershell scripts (starting with Powershell 3) after the parsing stage, so obfuscation layers are less of a concern and detections are becoming increasingly more precise.
Scripts and LOLBins work in concert to take advantage of fileless operations, to evade application whitelisting solutions and to help the attackers to maintain a low detection profile.
Detecting Fileless Malware and LOLBins abuse
Interpreters such as Powershell, cscript and wscript are widely used both for administration tasks and from legitimate applications to carry out certain activities. It is simply not practical to raise an alert every time such a component is executed on an endpoint. A good practice is that of analysing scripts using the new logging capabilities offered by Powershell and when possible digitally signing those that are required. Of course all the security features found in Powershell 5 should be enabled to help analysts figure out what an “unknown” script is doing.
The counter side of this approach is that manual analysis is precise but time-consuming: the analysts cannot be allocated full time to just read powershell logs, so we strongly suggest to automate this process as much as possible.
ReaQta-Hive uses a novel technique to model the behavior of each endpoint and each component used, starting from the user’s activity down to internal behavior. This analysis process makes it possible to automate the detection of anomalous operations, that are atypical for certain endpoints or infrastructure zones, saving time for the analysts and reacting faster than a human operator could ever do.
While the algorithms filter the bulk of operations, the analysts can invest their time on the analysis of more immediate threats and on running proactive threat hunting activities that can be used to uncover already active threats.
Fileless malware attacks are evolving fast, defenders must be equipped with proper tools to be able to hunt and react before the attackers begin to wreak havoc. Visibility and hunting capabilities remain a key component in modern infrastructure but automation makes the difference when it comes to early detection and speed of reaction.
Get in touch with us for a live demonstration of our solution on the latest fileless malware, or if you’re curious to better understand how such threats operate.