Fileless Malware

What is it?

Unlike attacks carried out using traditional malware, fileless malware attacks don’t entail attackers installing software on a victim’s machine. Instead, tools that are built-in to Windows are hijacked by adversaries and used to carry out attacks. Essentially, Windows is turned against itself.

The fact that traditional malware isn’t used is an important point. This means that there’s no signature for antivirus software to detect, greatly decreasing the effectiveness of these programs in detecting fileless malware attacks. And while next-generation security products claim to detect malicious PowerShell activity, the reality is that discovering fileless malware attacks is very challenging.

How does it work?

Fileless malware attacks entail taking default Windows tools, particularly PowerShell and Windows Management Instrumentation (WMI), and using them for malicious activity, like moving laterally to other machines. PowerShell and WMI are an adversaries’ tools of choice since they’re installed on every Windows machine, capable of carrying out commands (PowerShell, for example, can be used to automate tasks across multiple machines) and have been incorporated into the daily workflow of many IT professionals, making banning employees from using them pretty much impossible.

Using legitimate programs makes these attacks nearly undetectable by most security programs and even skilled security analysts. The reason is simple: since PowerShell and WMI are legitimate programs, any command they execute is assumed to also be legitimate.

Examples

While fileless malware may not grab as many headlines as ransomware or other cybernasties, these attacks are still a major security issue and used in many attacks. In fact, Cybereason has seen fileless malware used in several campaigns, including Operation Cobalt Kitty, which targeted a major Asian corporation. The attackers developed a very sophisticated PowerShell infrastructure and used it to drop an obfuscated PowerShell payload consisting of Cobalt Strike’s Beacon payload on the victim’s computers as well as fetch payloads from the command-and-control server. Using PowerShell to execute malicious commands allowed the attackers to operate undetected for nearly six months. Since a trusted program executed these commands, the company’s security staff as well as the security tools it used assumed the commands were legitimate.

Another incident observed by Cybereason shows just how prevalent fileless malware attacks have become. Cybereason’s security operations team observed odd PowerShell activity in a customer’s environment. Supposedly, an administrator had executed a PowerShell session using an encoded command via the command line. However, this behavior is typically attributed to an automated script, not a person. After investigating the incident, the security operations team determined that the company’s red team was conducting penetration testing and had incorporated fileless malware attacks into the exercise. If fileless malware wasn’t a concern among security professionals, red teams wouldn’t be adding it to their penetration testing exercises.

Detection and prevention

So what makes detecting fileless malware attacks so challenging?

These attacks reside almost completely in memory, and use legitimate system administration tools to execute and propagate, making determining what’s legitimate PowerShell use and what’s attacker activity very challenging. PowerShell is used by IT administrators to conduct a variety of tasks on a daily basis so heavy amount of PowerShell use wouldn’t raise concerns. And since PowerShell is used so frequently, security professionals lack the time to review logs, note suspicious behavior and then investigate the incident.

Plus, certain features in PowerShell make it difficult to figure out when the tool is being used by attackers. For example, PowerShell 2, which is likely the most used version of the tool, generates event logs that can tell when the PowerShell engine was started and stopped, but don’t provide much more information. This means that these logs can’t be analyzed to determine if a malicious payload was run.

In PowerShell 3, Microsoft added the option for manual module logging, which allows analysts and security products to determine script files were invoked and the corresponding parameters that were passed to them. Module logging has its shortcomings though: analysts and security products may not be able to handle the amounts of data it produces PowerShell 5 includes serious security improvements but they’re not enabled by default and attackers can evade these features by downgrading to version 2.

A common misconception is that disabling PowerShell will prevent fileless malware attacks. Unfortunately, this approach will only make the jobs of IT professional more challenging. Microsoft has made PowerShell nearly essential to using any of its products. For example, starting with Exchange 2007, Microsoft designed a GUI that only allows users to complete common administrative functions. PowerShell is required to carry out less common functions. Additionally, all Microsoft products will eventually use PowerShell. If administrators become skilled in PowerShell, then they can manage most of Microsoft’s newer products. Restricting PowerShell usage limits administrators’ abilities to hone skills that could help their careers.

So how can security professionals figure out when PowerShell is being used against an enterprise? Behavioral detection is the best way to answer that question. Looking for signs associated with malicious PowerShell use (like a PowerShell session executed using an encoded command via the command line), provides security teams with the evidence they need to investigate incidents that could turn out to be instances of malicious PowerShell use.