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.
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.
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.
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.
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.
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.
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.