A closer look at fileless malware, beyond the network

Cybersecurity is an arms race, with defensive tools and training pushing threat actors to adopt even more sophisticated and evasive intrusion techniques as they attempt to gain a foothold in victim networks. Most modern endpoint protection (EPP) services are capable of easily identifying traditional malware payloads as they are downloaded and saved on the endpoint, which means attackers have now turned to fileless malware techniques that never touch the victim’s storage.

We’ve covered the anatomy of an endpoint attack in detail before, so let’s dig into fileless malware specifically and examine a real-world endpoint infection to illustrate key defense best practices you need to have in place today.

Understanding fileless malware’s M.O.

Fileless malware is a bit of a misnomer, as it can – and often does – start with a file. While traditional malware contains the bulk of its malicious code within an executable file saved to the victim’s storage drive, fileless malware’s malicious actions reside solely in memory.

When it comes to traditional malware, deleting the executable means you delete the infection. This makes it easy for EPP solutions to quickly identify and clean up. Fileless malware, on the other hand, only uses the initial “dropper” file (usually an Office document or something similar) to open up a built-in system management tool like PowerShell and run a short script. It then hides from defensive tools by injecting its malicious code into other processes, all the while never touching the victim’s storage drive.

Part of the reason fileless malware has become such a popular attack technique is that it is exceedingly difficult to accurately identify and block the initial stages of these attacks without accidently triggering false positives and preventing the same tools from carrying out legitimate activities.

Examining fileless malware in action beyond the network

Although the majority of fileless malware starts with some form of dropper file, more evasive variants exist that truly don’t require a file. These instances generally originate in one of two ways, either A) by exploiting a code execution vulnerability in an application or B) (and more commonly) by using stolen credentials to abuse a network-connected application’s capabilities to run system commands.

WatchGuard Threat Lab recently identified an ongoing infection that used the latter technique. We investigated an alert generated through the Panda AD360 threat hunting console and pieced together indicators and telemetry from a server endpoint in the would-be-victim’s environment to identify and remediate the threat before it accomplished its goal.

This particular infection had an uncommon entry point: the victim’s Microsoft SQL Server. While SQL Server’s primary role is to store data records, it also includes procedures capable of executing system commands on the underlying server. And while Microsoft’s best practices advise using service accounts with limited privileges, many administrators still deploy SQL Server with elevated system-level accounts, giving the database application and any command it runs free reign over the server.

Before starting the attack, the threat actor obtained credentials for accessing the SQL Server. While we’re not certain how they acquired them, it’s likely to have been through a spear-phishing email or by simply brute-forcing their way in by attacking weak credentials. Once they had access to executing SQL commands, the attackers had a few potential options for launching commands on the underlying system.

The most common method (by far) is enabling and then using the xp_cmdshell procedure. The attackers either used this approach, or (less likely) loaded their own shellcode into the SQL Server engine to copy the Windows PowerShell application (PowerShell.exe) to the server’s Temp directory under the new name sysdo.exe. Renaming the PowerShell application before using it was an attempt to evade detection rules that don’t look past the application’s name when trying to spot PowerShell command execution.

After creating the disguised version of PowerShell, they executed the following encoded and obfuscated command (redacted for safety) as the first stage of the intrusion:

The command became a little easier to understand after we decoded and deobfuscated it:

The PowerShell script turned out to be very basic. It first makes a web request out to a malicious domain and downloads the second stage payload, a text file named nc.txt. The contents of that text file was another PowerShell payload, this time Base64-encoded. The script decodes the new payload and then executes it using the Invoke-Expression module. The threat actor included some additional minor obfuscation by not calling Invoke-Expression directly and instead accessing it through its alias using GAL I *X (Get-Aliases IEX).

The second-stage payload was a slightly modified version of the popular PowerSploit module Invoke-ReflectivePEInjection. After execution, the second stage calls out to the same malicious domain and downloads the third stage, a DLL binary called duser.dll.

Using the PowerSploit reflective injection module, the PowerShell script is able to load the DLL into memory and execute it. This third-stage binary ended up being a generic cryptominer, which would have used the SQL Server’s extensive processing resources to mine cryptocurrency if we hadn’t been able to detect and block the attack.

Fending off fileless malware

We were ultimately able to identify the intrusion through a variety of methods including evaluating its process behavior and recognizing the cryptominer. Since the threat actor never touched the would-be victim’s server storage drive throughout the course of this entire attack, endpoint defenses that only monitor files would have missed it entirely.

Fileless malware usage will only continue to grow in prevalence moving forward, as tools like PowerSploit make it easy for even novice cybercriminals to launch evasive attacks. To combat the threat, focus on deploying EPP and Endpoint Detection and Response (EDR) security solutions capable of identifying indicators that exist solely in memory.

It’s also critical that you promote strong password practices across your company, backed by multi-factor authentication wherever possible to prevent credential theft from initiating an attack. Combined, these strategies can help to significantly reduce your risk of sustaining a breach due to fileless malware beyond the network.

Source: https://www.helpnetsecurity.com/2021/01/04/fileless-malware/?web_view=true