POST BY: FRED O’CONNOR
What is fileless malware?
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 fileless malware 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.
PowerShell
PowerShell is a powerful scripting language that provides unprecedented access to a machine’s inner core, including unrestricted access to Windows APIs. PowerShell also offers the benefit of being an inherent part of Windows that’s completely trusted so the commands it executes are usually ignored by security software.
PowerShell’s ability to run remotely through WinRM makes it an even more appealing tool. This feature enables attackers to get through Windows Firewall, run PowerShell scripts remotely or simply drop into an interactive PowerShell session, providing complete admin control over an endpoint. And, if WinRM is turned off, it can be turned on remotely through WMI using a single line of code.
Using PowerShell in a fileless malware attack completely blurs the line between compromising a single machine and compromising the entire enterprise. The moment an attacker has a user name and password for one machine (which can be easily obtained in PtH and PtT scenarios), the path to complete compromise is laid wide open.
Traditional approaches to security are rendered useless in the face of fileless malware attacks that use PowerShell since the tool is highly reputable, has a trusted signature, is loaded directly through system memory (which cannot be scanned using heuristics) and has unrestricted access to the OS because it’s an integral part of Windows.
Windows Management Instrumentation (WMI)
WMI allows administrators to perform a variety of actions, such as gather metrics, install software and updates or self-query the OS. WMI has access to every resource on a machine, and is divided into classes for different tasks, such as executing files, deleting and copying files and changing reg values. This tool is built into every modern version of Windows, and is the backbone of the agentless agent.
These inherent features make WMI a blessing because it allows admins to perform tasks very quickly, but when used for malicious operations it very quickly turns into a curse. The same way an administrator uses WMI to query metrics and execute code, a hacker can use it to silently and instantly run malicious code across an entire network of machines. WMI also allows for persistence by auto-running programs stealthily on startup or based on specific events. WMI can’t be uninstalled, but it can be disabled. However, doing so impairs and limits what an administrator can do, such as update software across multiple machines.
Examples of fileless malware attacks
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.
Learn more about Operation Cobalt Kitty
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.
The increasing threat of fileless malware
Technically, fileless malware attacks aren’t new. Many of the techniques used by fileless malware attacks have been around for awhile. In-memory exploits, for instance, were prominent in the SQL Slammer worm from the early 2000s.
But the development and large-scale distribution of exploit kits has made fileless malware attacks much more common. For example, offensive PowerShell frameworks like Empire and PowerSploit and post-exploitation frameworks like Metasploit and CobaltStrike are especially abused since they can be used to quickly create PowerShell attack payloads.
And, of course, fileless malware attacks appeal to adversaries since antivirus software can’t really detect them and many advanced security tools also struggle with picking up malicious PowerShell use.
The difficulty organizations face in detecting these attacks combined with the availability of these techniques is exactly why this tactic is being increasingly adopted. No longer a rogue technique, a third of organizations polled for the SANS 2017 Threat Landscape survey reported facing fileless attacks.
Detection and prevention of fileless malware
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.
