An earlier blog post described the growing threat of fileless malware and its potential to harm enterprises. This post will focus on how to get better at finding it and what you can do about defending your organization.

Fileless malware leverages what hackers call “living off the land,” meaning that the malware uses code that already exists on the average Windows computer. When you think about the modern Windows setup, this is a lot of code: PowerShell, Windows Management Interface, Visual Basic scripts, Registry keys that have actionable data, and .NET framework. Malware doesn’t have to drop a file to use these programs for evil intentions. The combination of all of these code sources is generally called “process hollowing.” It is called that because the malware uses a particular process as a storage container and distribution mechanism for its code. Here is one recent attack which is described here that combines PowerShell, VB Script and .NET in a lethal package.

In this blog post from last fall, IBM X-Force IRIS demonstrates just how potent PowerShell-based attacks can be, because executable code is done directly from the PC’s memory. Plus, PowerShell can be used for remote access attacks and can get around application whitelisting protections.  Researchers cited in that post claim that these style of attacks are quickly increasing.

So the general thrust of how to find it is to first make sure that your Windows computers have been patched quickly and are up to date. To delay is to introduce a vulnerability into your network, because one of the first tenets of hackers is to take advantage of an unpatched, or older system. When we look at the spread of the EternalBlue malware, this is a good illustration: the patch was available for more than a month before this exploit was launched. A similar situation happened with the Helminth Trojan that took advantage of a Word-based zero-day vulnerability in 2017.

The next step is to ensure that you have a solid security awareness training regimen. This doesn’t mean running annual exercises and sending out the occasional test phishing email. Instead, come up with a program that operates continuously and is always making users aware of the dangers of email attachments and clicking on links willy-nilly. Most of the fileless attacks begin their life with a simple phishing email, so it is important to try to nip these entry points quickly.

Third is understanding the behavior of the built-in Windows code so you can spot anomalies. For example, when encrypted PowerShell scripts are installed to run as a service. The combination of the two – the encryption and the service feature — should be a red flag. Analysts sometimes see compression tools instead of or in addition to encryption too. Another red flag is finding a PowerShell script hiding in the \TEMP directory; while not technically fileless, this code quickly moves to more dangerous parts of the OS.

Next is understanding what happens when the malware first detonates. Just because you have a user who clicked on a malicious attachment doesn’t mean the malware will stay on their PC. Instead, a typical behavior is for the malware to move across your network to find a richer target, such as a domain controller or web server. To prevent this, you should segment your network carefully and make sure you understand access rights, especially of third-party applications and users.

Another common attack method used by all malware is to try to escalate privileges as it moves arounc your network. This blog describes how you can use PowerShell for this activity. They don’t call it PowerShell for nothing: you can issue commands for reverse DNS queries, enumerate access control lists on any network share, and find members of a particular domain group. This means one of the more basic controls for any malware is to restrict administrator rights to the minimum number of systems. Many of the fileless exploits count on profligate use of these rights that aren’t needed, or are attached to users that have since left the company or don’t even access the targeted applications anymore. This blog post mentions how X-Force IRIS found how the FIN7 hacking group was using WMI scripts to deploy its malware across an enterprise. You should have ways to detect when these situations occur and be able to shut them down quickly.

Windows can be used for more than just desktop computers, and one common approach is to target embedded Windows point-of-sale machines. The attraction here is that these computers have direct access to payment card data.

Another tactic is to disable Windows programs that aren’t needed. Not everyone needs PowerShell running on their computer, or support for .NET Framework. Even more compelling is to eliminate support for ancient protocols such as Server Message Block (SMB) v1, which was what caused all the trouble with WannaCry.

While PowerShell can get around application whitelisting, it still is a good idea to deploy such controls if you have the right tools to do so. The more you know about how your users consume applications, the more likely you will be able to catch a piece of malware doing something that no other legit app has ever been observed doing. Another way is to disable macros, include Office macros, which are often abused by malware writers, although this isn’t a universal solution because many users do need them to do their jobs.

Microsoft hasn’t been standing still while fileless attacks happen. They have developed an open interface called Antimalware Scan Interface that some vendors have begun to use to make it easier to detect these “tells” of the fileless world, especially when it comes to analyzing scripting behavior, and are now incorporated into Windows Defender.

Finally, researchers who want to gain a better understanding of fileless attacks should check out the open source project AltFS. This is a complete filelessvirtual file system to demonstrate how these techniques work. It can be deployed on Windows and Mac PCs.