Yes, we get it. The term “fileless” is confusing. It sounds like yet another new marketing buzzword, but what it actually refers to are evasive attack techniques that, in many cases, have been around for quite a while.
Why all the fuss about “fileless” techniques now?
For one thing, they’re more prevalent. As new attack tools and frameworks make these techniques easier to use they’re getting more popular and widespread.
Another reason is they’re working.
The Ponemon Institute recently found that 77 percent of successful compromises involved fileless techniques, and that attacks incorporating fileless techniques were 10x more likely to succeed than traditional file-based attacks.
That success highlights obvious gaps in the traditional endpoint security approach of scanning files to identify malware (hence the marketing interest from new vendors).
Buzzwordiness aside, the increasing widespread adoption of fileless attack techniques is a real problem. We all need to be aware of it, and we need to be taking steps to address it. That’s what this guide is all about.
This may currently be the most widely-used term, but it’s also responsible for the majority of the confusion on this topic. Doesn’t malware refer to executable programs and files? How can it be fileless? If it is “fileless” is it really malware? What is “malware,” anyway? Rather than get lost in such deep, existential questions let’s just agree it’s a bad term and move on.
We’ve never found it very useful to name something based on what it isn’t. It’s like an app that labels anything that isn’t a hotdog “Not hotdog” — it’s not especially helpful or descriptive.
Using the term “fileless” to describe attacks that don’t leave executable files behind on the victim’s hard drive is all the rage now, but that doesn’t mean the concept is new. In fact, attacks that store malicious code solely in memory date back to the prolific Code Red and SQL Slammer worms of the early 2000s. For a good history of fileless attacks and usage of the term, see this post from Lenny Zeltser.
According to the Ponemon Institute’s 2017 State of Endpoint Security Risk report, 42 percent of organizations experienced one or more fileless attacks that successfully compromised their data or IT infrastructure in 2017.
Super shocking statement alert: A single attack can involve both files and fileless techniques — they’re not mutually exclusive (gasp!).
For example, many attacks may begin in a traditional way we’ve all become accustomed to (say, a user opens a file attached to a spam email), but once initial compromise is established, they can shift to using fileless ways of gathering information and spreading.
Vice versa, attackers can also gain initial compromise filelessly (by exploiting a vulnerability, for example), and then use that access to deploy malicious executable files.
The point is attackers can leverage both files and fileless techniques at different stages during an attack. For that reason, rather than get into semantic disputes over which attacks are truly fileless and which aren’t, let’s acknowledge that often what the term “fileless” is actually referring to are the techniques attackers use to avoid dropping malicious executable files on disk.
A clear, simple definition:
With that out of the way, let’s take a closer look at specific types of fileless attack techniques and explain how they work.
Download the Fileless Attack Checklist for practical tips on preventing and mitigating the most common fileless techniques.
By utilizing exploits and code injection techniques attackers can load and execute malicious code directly in memory.
Attackers can gain persistence on compromised machines by storing malicious scripts in the registry. Kovter and the QakBot banking trojan are two notorious examples of malware that sets up shop via autorun registry entries to help it survive system reboots and make itself frustratingly difficult to remove.
Scripts can be used as droppers in early attack stages and for a wide variety of post-exploitation activities.
By abusing powerful legitimate system administration tools like PowerShell, Windows Management Instrumentation, PsExec, etc. that are built into Windows, attackers can carry out malicious activities without raising red flags. For more on "Living off the land" techniques, see Symantec's ISTR report on the topic.
Lesley Carhart, tisiphone.net
By operating in memory or residing in the registry, attacks can avoid being detected by many of today’s security solutions.
David Bisson, TripWire
With few artifacts to examine, attacks are harder to attribute and reverse engineer.
Abusing legitimate administration tools and utilities allows attackers to bypass whitelisting and hide in plain sight.
Thanks in part to pentesting frameworks like Metasploit, Empire, Cobalt Strike, PowerSploit, etc. many fileless attack techniques are pre-packaged and available to anyone, regardless of their motives or technical expertise. In particular, Meterpreter, a component of Metasploit specializing in in-memory attacks, has been tied to a wave of fileless attacks carried out against banks and financial institutions in 2017.
An estimated 77 percent of successful compromises in 2017 involved fileless techniques (Ponemon Institute’s 2017 State of Endpoint Security Risk).
To understand how attackers are using fileless techniques, let’s look at how attacks are structured.
At a high level, attacks can be broken down into two primary stages: the initial compromise that gives attackers access to the system, and the post-exploitation activities they conduct once they have access.
Attackers have different goals during each of these stages, and there are wide varieties of fileless techniques they can utilize to accomplish them (with the list of options growing all the time). Let’s cover some prominent examples.Back to top
Exploiting vulnerabilities in software or operating systems can allow attackers to gain access and control over a machine. Prominent examples of attacks exploiting remote code execution (RCE) vulnerabilities include the WannaCry and NotPetya outbreaks (which utilized the EternalBlue exploit), and the Equifax breach, in which attackers were able to exploit a vulnerability in the company’s unpatched version of Apache Struts and use it to execute malicious commands.
While we tend to think of attackers gaining access to computers primarily via malicious emails or exploit kits, a large number of attacks start off much more simply — attackers just guess their way past weak passwords. In fact, brute force attacks have become the compromise of choice for a growing number of ransomware groups (SamSam, CrySiS, BTCWare, etc.), who specifically target organizations with Remote Desktop Protocol (RDP) exposed to the Internet.
RDP is a protocol developed by Microsoft as a remote management tool. It is commonly exposed in internal networks for use in administration and support, but when it's exposed to the wider Internet it can be a beacon for attackers. Port scanning tools like Nmap and masscan make it incredibly easy for attackers to hone in on devices with vulnerable RDP connections, and launching attacks that way allows them to bypass a wide variety of security solutions.
RDP isn’t the only potential target for brute force attacks, of course. Other remote access tools like Teamviewer are also frequently targeted (though many have mitigations such as account lockouts or progressive delays built in).
Once executed, scripts and macros can serve as downloaders and payload launchers, or they can trigger a wide variety of fileless post-exploitation activity.
In any of the cases described above, once the initial compromise is successful attacks can move forward in either a traditional file-based or a fileless direction.Back to top
Once a machine has been compromised, an attacker’s attention can shift to accomplishing a wide variety of post-exploitation goals, from launching malicious payloads to moving laterally throughout the network. Here are several examples, along with fileless techniques attackers use to achieve each.
Unless an attacker has the good fortune of landing on a machine with administrator privileges, initially the amount of access and functionality they have is going to be limited. This often makes privilege escalation one of the first orders of business during an attack.
Depending on settings, Windows User Account Control can allow or deny a program the ability to elevate its privileges by prompting users for confirmation. To get around this, attackers can hijack legitimate Microsoft programs and tasks that are designed to auto-elevate — meaning they can be launched by unprivileged users but they run with elevated privileges. In doing so, attackers can execute PowerShell scripts and commands they otherwise couldn’t, and launch high-privilege programs without triggering UAC prompts. Security researcher Matt Nelson has documented several of these workarounds, including using SilentCleanup, eventvwr.exe, and sdclt.exe.
Tools abused: Windows Task Scheduler, Microsoft-signed binaries that auto-elevate (ex: eventvwr.exe, sdclt.exe)
Mitigation: Use the highest UAC enforcement level whenever possible, including setting UAC level to “Always notify” (yes, this can be annoying), remove users from the local administration group, and enable Admin Approval Mode to enforce UAC for the built-in Administrator.
There are several places where Windows stores credentials — (LSASS process memory, the Security Accounts Manager (SAM) database, and Credential Manager to name a few — and they can even include credentials of domain users and admins who have logged into the machine. Attackers and penetration testers have naturally developed tools and tactics to take advantage of this. We’ll cover specific examples in more detail in the Propagation section.
Fareit adds an entry to the registry that establishes the malware (in this case, “sick.exe”) will execute any time a .msc (Microsoft Saved Console) file is opened.
Then it launches Microsoft’s Event Viewer, which queries HKCU\Software\Classes\mscfile\shell\open\command in order to start mmc.exe (Microsoft Management Console) and open eventvwr.msc, which now executes Fareit, instead. Because eventvwr.exe doesn’t require UAC permission to run with high-privilege, any child process it executes (in this case, Fareit) will run with high-privilege without triggering UAC prompts, too.
Note: While this attack abused eventvwr.exe to launch an executable file, to keep the attack fileless it would be just as easy to substitute "sick.exe" for any malicious PowerShell script or command attackers want.
To avoid writing malicious files and scripts to disk (subjecting them to AV scanning and possible detection), attackers have several ways of loading and executing them directly from memory, instead. These techniques primarily rely on injecting malicious code into a legitimate process (often with the help of PowerShell and/or Windows API functions), thereby hijacking its memory space and privileges to execute.
The techniques below are two of the most common fileless methods of process injection. You can find a larger list (including methods that require writing a DLL to disk) on the Endgame blog here.
One of the most common ways attackers insert malicious code into a legitimate process is through DLL injection. Dynamic Link Library (DLL) files contain instructions that multiple programs can call on as needed during runtime. By writing a path to a malicious DLL in a host process, attackers can trigger that process to execute it. As researchers at ReaQta discovered, there is even a legitimate, trusted Microsoft program called Mavinject.exe attackers can use to conduct malicious DLL injection without raising red flags.
With reflective DLL injection, attackers are able to copy an entire DLL into process memory, which avoids having that DLL reside on disk (making it easily detectable) and being registered with the process it’s being injected into. Reflective DLL injection has become a popular technique heavily incorporated into attacks as well as penetration testing tools such as Metasploit, Cobalt Strike, Empire, PowerSploit, etc. which make deploying it easy.
Tools abused: PowerShell, Metasploit’s Meterpreter, Cobalt Strike’s Beacon, Empire, PowerSploit, etc.
Mitigation: Monitoring processes and API calls can result in a lot of noise to filter, but tools like Process Explorer, which provides a variety of info on active processes, including DLLs and memory-mapped files they’ve loaded, and Get-InjectedThreads, which scans active threads on the system for suspicious start addresses, can help. There are also specific calls in the PowerShell operational log that can provide strong indication of an attack.
Another well-established evasive execution technique is process hollowing, which involves creating a suspended process, swapping out the original executable code from that process with a malicious payload, and resuming the process so the payload is executed. Sorebrect ransomware uses this technique to hijack svchost.exe, using the legitimate process as cover to run the malware’s encryption routine.
Researchers at enSilo presented a new, stealthier take on process hollowing at Black Hat Europe 2017. Dubbed “process doppelgänging,” it abuses the Windows NTFS Transaction feature and an outdated but still supported version of Windows process loader to hide malicious code in the memory of otherwise legitimate processes.
Tools abused: PowerShell
Mitigation: One way of spotting traditional process hollowing activity is to monitor for processes being spawned with the CREATE_SUSPENDED flag.
DoublePulsar is the backdoor implanted by the Eternal family of exploits (EternalBlue, EternalRomance, etc.) for remote payload execution. Shellcode in the kernel injects additional shellcode into the lsass.exe process, which can then load and run payloads via reflective DLL injection. For more details, see Countercept's DoublePulsar analysis.
Landing on a machine is one thing. Sticking around past a reboot and/or removal attempts is another. To avoid detection, attackers can create fileless load points that take advantage of several built-in Windows features and functionality.
The most common way of achieving fileless persistence is by planting malicious scripts in the Windows registry. Poweliks and later Kovter are two examples of malware that has evolved to become completely “registry resident,” with code spread across multiple registry keys and designed to be extracted and run on the fly whenever the machine restarts or a shortcut or batch files are triggered.
Tools abused: PowerShell
Mitigation: The good news is because registry contents are stored on disk they can be monitored. Microsoft’s Sysinternals Autoruns program can help with inspecting registry keys and even has VirusTotal integration to help identify malicious entries.
Windows Management Instrumentation (WMI) provides system administrators with a wide range of powerful capabilities, including locally or remotely executing scripts via the command line tool wmic.exe or PowerShell. Those capabilities also make WMI an extremely useful tool for attackers, who can also abuse it to trigger scripts to execute based on various events such at startup, specific time of day, etc.
For more information on how attackers abuse WMI, see this paper by researcher Matt Graeber.
Tools abused: PowerShell, WMI
Mitigation: One way to combat malicious WMI abuse is to… use WMI. As Graeber explains, WMI event subscriptions can be created that log and respond to suspicious WMI activities (examples here and here).
Another basic way of establishing persistence is by creating scheduled tasks and using them to trigger scripts and commands. The QakBot trojan is a good example. Not only does it create a registry entry to automatically launch itself each time the infected computer starts up, it also creates two recurring, scheduled tasks to ensure it's still running and hasn't been removed. The first periodically attempts to launch QakBot, while the second launches a downloader to reinfect the machine should the payload be removed.
Tools abused: PowerShell, Task Scheduler
Mitigation: Monitor for scheduled task creation (event ID 4698). This PowerShell script from Netwrix creates instant alerts.
Kovter is click-fraud malware well-known for its fileless persistence. Its latest method involves creating registry keys that run the payload command any time a file with a custom file extension (ex: .cnc9974d) is opened.
Kovter uses .lnk and .bat files pointing to files with the custom extension in order to launch itself at each system startup.
Land and expand by achieving lateral movement.
Harvesting credentials stored on a compromised machine can be extremely useful for lateral movement, especially when password reuse is so high and there’s also a chance they can include credentials of domain users and admins who have logged into that machine. By using Mimikatz, an incredibly popular and versatile penetration testing tool, attackers can scrape cleartext passwords and NTLM hashes from the memory of lsass.exe (the process responsible for Windows authentication), or extract saved credentials from Windows Credential Manager (even domain credentials). Thanks to this PowerShell script, Mimikatz can be run entirely in memory.
Mimikatz isn’t the only option available to attackers. Metasploit’s Meterpreter payload can be used to pull account info from the NTDS.dit file (the database for Active Directory), including not only the current NT and LM hashes, but the saved history going back to 20 previous passwords.
Windows Credential Editor is another option. This legitimate administrative tool can be abused by attackers to grab NTLM credentials and Kerberos Tickets as well as dump cleartext passwords stored by Windows authentication packages.Additional techniques can be found here.
Tools abused: Mimikatz, Metasploit Meterpreter, Windows Credential Editor (WCE), pwdump, etc.
Mitigation: Techniques for credential dumping are constantly evolving, but (when possible) a few basic steps like disabling credential caching, disabling or setting PowerShell in Constrained Language mode when full functionality isn’t needed, and following the usual best practices around least privilege and avoiding credential overlap across systems can go a long way towards making credential dumping more difficult.
One of the most notable aspects of the NotPetya outbreak (in addition to its use of the leaked EternalBlue exploit) was its abuse of the legitimate command-line tools PsExec and wmic.exe to execute copies of itself on remote machines. This helped the malware spread internally throughout infected networks.
While the technique wasn’t new, seeing it applied successfully to such a large-scale, high-profile attack caused other malware authors to take notice. The tactic has since been utilized by a variety of ransomware (ex: Sorebrect, HC7) and trojans (Emotet, QakBot, TrickBot, etc.).
Tools abused: PsExec, wmic.exe, RDP, PowerShell, Metasploit
Mitigation: Since both PsExec and wmic.exe require administrative credentials to fully leverage, credential dumping mitigation efforts apply here, as well. In addition, network segmentation best practices and requiring two-factor authentication (2FA) can help provide barriers for lateral movement.
NotPetya utilized a modified version of LSADump (Mimikatz) to extract user credentials stored in the memory of the lsass.exe process. These can include credentials of domain users or admins who log into the machine.
It then used those credentials in an attempt to establish connections and remote execution on other machines in the network using PsExec and wmic.exe.
This approach has since been mimicked by several malware families...Back to top
Download the Fileless Attack Checklist for a complete list of practical steps that can make your company more secure now.
The good news is, in addition to the mitigation tips provided throughout this guide, there are several general, high-level things you can do to reduce your organization's susceptibility to fileless attack techniques:
With no files to scan, detecting and blocking these attacks comes down to being able to identify malicious behaviors — ideally before damage is done. If you have the staff and resources to handle it, enabling and monitoring extended PowerShell logging can help you identify suspicious scripts. Alternatively, solutions like Barkly can help you proactively block malicious scripts automatically.
Warn users to be extremely wary of Microsoft Office documents that prompt them to enable macros (or "enable content"), and utilize endpoint protection that blocks malicious macros before they can execute. Speaking of Microsoft Office, make sure you've taken measures to block DDE attacks, too.
The liability they present simply isn't worth it. First and foremost on the list is PowerShell. If disabling PowerShell isn't a realistic option, consider using Constrained Language Mode to limit PowerShell to basic functionality, which makes many fileless attack techniques unusable.
And when you can't patch, isolate.
Ensure that user access and privileges are limited to the bare minimum they absolutely need. Microsoft's Just Enough Administration technology can help.
Looking for more info on the fileless attack techniques and defensive tools described in the guide? The following are great resources to check out.