Security 101: The Rise of Fileless Threats that Abuse PowerShell

by Marvin Cruz (Trend Micro Threat Researcher)

Convenience, efficacy, and stealth are the likeliest reasons why cybercriminals are increasingly abusing legitimate tools or services already in the system to deliver their malware. Leveraging them allows these threats to blend in with normal network traffic or IT/system administration tasks, for instance. Exploiting these legitimate system utilities also enables these threats to do its malicious bidding while leaving fewer footprints, which in turn make their detection more challenging. This is the case with threats such as fileless malware.

Fileless infections don’t entail files being written or downloaded and executed in the affected machine’s local disks. Instead, they are executed in the system’s memory, or reside in the system’s registry for persistence. In a typical fileless infection, payloads can be injected into the memory of an existing application/software, or by running scripts within a whitelisted application such as PowerShell.

Even if they aren’t file-based (or executable) threats, we know they’re out in the wild due to their notoriety as a technique in targeted attacks. Tell-tale signs of fileless infection are network traces, like command-and-control (C&C) connections, and other malicious code artifacts left behind in the affected machine. Fileless threats, unfortunately, are also readily available in public project repositories, and even in the cybercriminal underground as a product (or service). Fileless infections are also a staple feature in exploit kits such as Angler. For example, the cybercriminal group Lurk used a fileless infection to steal more than $45 million from financial institutions using their own exploit kit.

[From the Security Intelligence Blog: A technical overview of the fileless ransomware, UIWIX]

Malicious PowerShell scripts are a key ingredient to many fileless malware. Windows PowerShell is a built-in tool based on the .NET framework comprising a command-line shell, an interface that lets users access services of the operating system (OS), and a programming language that can be used to create scripts. PowerShell is designed to automate system administration tasks, such as view all USB devices, drives, and services installed in the system, schedule a series of commands and set it in the background, or terminate processes (like Task Manager). PowerShell is also designed to enable administrators to seamlessly manage the configurations of systems and servers as well as the software or services and the environments they run on.

And like any potent tool, PowerShell’s capabilities have drawn the attention of cybercriminals. We’ve already seen how PowerShell was abused—from the Poweliks Trojan downloader that emerged in 2014, the information stealer FAREIT, and banking malware VAWTRAK to ransomware families such as PowerWare and Cerber version 6. Many fileless malware embed malicious PowerShell scripts whose commands are often the ones responsible for downloading and launching or executing the payload.

[READ: How cybercriminal group Lurk used fileless infection to steal over $45 million from financial organizations]

Why are attackers abusing PowerShell?

Abusing PowerShell heightens the risks of exposing systems to a plethora of threats such as ransomware, fileless malware, and malicious code memory injections. This can be exacerbated with:

• Scale and scope. PowerShell is a built-in feature in Windows XP and later versions of Windows’ operating systems (OS). Last year, it also became an open-source, cross-platform framework that can be run on Linux.
• Legitimate use. PowerShell is not inherently malicious and is, in fact, a legitimate tool. Its use and abuse can blur the line between it being used to maliciously hack or infect a system, or to accomplish IT/system administration tasks.
• Accessibility. PowerShell scripts are relatively easy to write and run (and learn) for many IT/system administrators, information security professionals, penetration testers, and black hat hackers.
• Expediency. PowerShell scripts aren’t just easy to write; PowerShell’s flexibility, along with the availability of third-party modules, makes it relatively simple to obfuscate them.
• Capability. PowerShell can virtually access a considerable range of Application Program Interfaces (APIs) to execute important functions such as VirtualAlloc, VirtualProtect, and CreateThread, all of which can be abused by attackers.

PowerShell is restricted by default as a way to mitigate its abuse. Specific PowerShell commands can be executed, for instance, but script files are prevented from running. That doesn’t seem to be putting off hackers though. We have seen several PowerShell script-toting malware employ techniques to bypass PowerShell’s default execution policy, such as running the malicious code as a command line argument.

A fileless attack’s typical infection chain

[READ: Currently trending: using shortcut (LNK) files to execute malicious PowerShell scripts]

Fileless attacks abusing PowerShell are increasing

How common are fileless, PowerShell script-toting malware becoming? Trend Micro identified over 78,600 malspams, or malware delivered via spam email (detected as W2KM_POWMET and POWLOAD), affecting enterprises from January to February 2017. Both are macro malware downloaders that leverage malicious PowerShell scripts to deliver the payload to the affected system. During the first quarter of 2017, Trend Micro’s sensors were able to monitor PowerShell-related attacks on more than 12,000 unique machines.

In November 2016, attacks employing fileless malware reportedly saw an uptick of 13%. In the last quarter of 2016, fileless malware-related attacks surged by 33% compared to the first quarter.

Given PowerShell’s popularity among IT/system administrators and its ubiquity in Microsoft operating systems, fileless threats and PowerShell abuse will only continue to gain traction throughout this year as cybercriminals hone their tactics and techniques to better evade traditional security solutions.

[READ: How advanced sandboxing techniques can thwart elusive threats such as fileless malware]

Enterprises need to implement proactive security measures

There is no silver bullet when it comes to fileless malware, and organizations should practice defense in depth, where multilayered safeguards are placed to reduce exposure and mitigate damage. But apart from cultivating a security-aware workforce, what actionable countermeasures can organizations do?

Here are some best practices that can help mitigate fileless threats:

Apply the latest patches and keep the systems updated. Fileless attacks are known to exploit vulnerabilities in whitelisted applications (which mean they’ve been permitted to run in the system). This allows attackers to embed and execute their malicious scripts or codes by piggybacking on the privileges of the application. A robust patch management policy that balances business productivity and security is recommended. Virtual patching and vulnerability protection mechanisms can also be deployed to shield systems and networks from unknown vulnerabilities, even without a patch.

Adopt best practices for securing and using PowerShell. PowerShell has its own logging capability that can be used to further scrutinize suspicious or malicious behavior within a system. Microsoft also has best practices on how to use PowerShell in operational or cloud environments, or hardening systems via PowerShell commands (i.e. execution policies or setting PowerShell to ConstrainedLanguageMode).

IT/system administrators and information security professionals can also consider listing triggers for detection, which can be based on commands known to be used by malicious PowerShell scripts. Threat actors, for instance, often use the “^” symbol to obfuscate their command prompt parameters when invoking PowerShell.

Other triggers for PowerShell script scans that can be considered are:

• Using sensitive PowerShell command-line arguments, such as: ExecutionPolicy Bypass, -Exec Bypass, -ep bypass, -EncodedCommand, -enc
• PowerShell command-line arguments that can be used for aggressive detection, such as: -NonInteractive, -NonI, -NoLogo, -NoProfile, -NoP, -WindowStyle Hidden, -w Hidden
• PowerShell parent processes such as: wscript, MS Office program
• Powershell command-line arguments characteristics like Entrophy and Length

A code snapshot of macro malware that uses “^” for command shell obfuscation

Implement the principle of least privilege. Exposure to threats can be further reduced by only granting enough access or privilege for a user to accomplish his task, or an application to be run. This limits the risks and even actual damage that can result from exploits or unauthorized use.

Deploy behavior monitoring mechanisms. Fileless attacks misuse tools like PowerShell to bypass the system’s restrictions. Since fileless malware aren’t written in the disk, they can bypass traditional security solutions that depend on files to detect threats. Mechanisms like application control, where applications are prevented from executing, offer little or limited help in this regard. Additionally, PowerShell is a legitimate tool regularly used by IT/system administrators and information security professionals, so it cannot just be easily blocked by application control. This can be mitigated by deploying a behavior monitoring mechanism on the endpoint, which helps prevent and limit data leakage and malware infection by monitoring and blocking malicious behaviors and routines associated with malware, as well as unusual modifications to the OS or software/applications, including PowerShell. A good behavior monitoring system not only looks into an application’s behaviors, but also anomalies in the process chain, like how Explorer launches Command Prompt to invoke a malicious PowerShell script.

Enable a custom sandbox. Fileless Trojan downloaders and macro malware typically utilize PowerShell scripts and shellcode to deliver their payloads. IT/system administrators can contain them in a sandbox—a controlled, virtual environment where suspicious files are quarantined for further analysis. The sandbox must be configured to mirror the actual system’s configuration to better identify how a suspicious file would affect the system. A sandbox that can analyze the various routines and behaviors of the malware can help identify the obfuscation or evasion tactics that these threats use.

Secure possible points of entry. Fileless malware’s attack vectors are known to be spam email, malicious websites/URLs, especially if it uses an exploit kit, and vulnerable third-party components like browser plug-ins. Securing these points of entry significantly reduces the system’s exposure to these threats and even stops these malware from getting into the system in the first place. Securing the email gateway and adopting best practices that mitigate email-based threats are recommended. Security mechanisms that can filter and categorize malicious URLs add an extra layer of protection against web-based, fileless threats.

Disable unnecessary components. A fileless attack can also come in the form of exploits in vulnerable third-party components like browser plug-ins, or even tools like PowerShell itself. Disabling unneeded or outdated components limit the ways an attacker can breach a system or network. The same restrictions should be applied for tools like PowerShell, which is typically only used by IT/system administrators.

Proactively monitor your systems and networks. Fileless, information-stealing malware, for instance, have malicious code that can indicate command and control communications to the attacker’s servers. Employing firewalls as well as intrusion detection and prevention systems will help deter incursion or data exfiltration attempts. This can be complemented by a security mechanism that can actively monitor inbound and outbound network traffic for any suspicious behavior.

While fileless attacks aren’t as visible compared to traditional malware, they can still leave behind indicators of compromise such as code artifacts. IT/system administrators must regularly keep logs and record system activities, whether in applications, registry, and system or network events, and ensure they are safe from modification. Not only do they aid in incident response and remediation; these logs also help security researchers better understand the threat.