For more technical explainers on PowerShell, read our PowerShell 101: A Technical Explainer for IT Pros report.
One of the major weaknesses associated with traditional antivirus software is that it works by scanning files in an effort to detect signatures of malicious code. Modern antivirus applications also use heuristic-based detection, but conventional wisdom has long held that malware infections are tied to malicious files. However, it is possible for a malware attack to occur without the victim ever coming into contact with a malicious file—otherwise known as fileless malware.
Fileless malware attacks vary widely in scope, but one infection method involves attackers running the malware on their own machines and directing instructions to remote targets. In this type of attack, no file is ever sent to victims’ computers. Instead, the victims’ machines merely receive a series of individual instructions from the attackers computers.
In this article I will explain how fileless malware attacks work and what role PowerShell plays. In a related article, I demonstrate what a fileless malware attack using PowerShell looks like.
Before I get started, there is one really important thing that I need to mention. Even though the techniques I will be demonstrating are performed within PowerShell, I am not suggesting that PowerShell is inherently insecure. Attacks like the one I will show you can succeed only if the necessary permissions exist. Elevation-of-privilege attacks are beyond the scope of this article series, so, for the sake of demonstration, I am going to be working under the assumption that the required privileges already exist and that the bad actors have already gained access to the target resources.
This, however, raises a big question. Why doesn’t PowerShell do anything to stop a fileless malware attack?
PowerShell includes a variety of native protective mechanisms. One such mechanism is execution policies, which are designed to prevent scripts from being run. PowerShell execution policies have their place, but an organization cannot assume that it is impossible (or even difficult) for an attacker to compromise PowerShell just because a system’s execution policy is set to Restricted.
There are at least three reasons why an execution policy might not be able to prevent an attack.
First, if an attacker has gained the permissions that are necessary to use PowerShell to compromise one of your servers, that attacker presumably also has permission to set the system’s execution policy to Unrestricted.
Incidentally, if you are curious as to your current execution policy level, you can check it by using the Get-ExecutionPolicy cmdlet. If necessary, you can change the execution policy by using the Set-ExecutionPolicy cmdlet. You can see examples of these cmdlets in Figure 1.
Figure 1
This is how you check and modify PowerShell’s execution policy.
The second reason why an execution policy might not be able to protect you against an attack is because it is relatively easy to circumvent an execution policy without disabling it. There is a free tool called PS2EXE that can be used to compile a PowerShell script into an executable file. This executable file works completely independently of PowerShell, and can run even if the execution policy is set to Restricted. Again, though, a number of things would have to have gone wrong for an attacker to be able to run a random executable file on your server.
The third reason why an execution policy might be powerless to stop a PowerShell-based attack is because execution policies are designed to prevent unauthorized scripts from being run. More specifically, an execution policy is designed to prevent the use of unauthorized .PS1 files. Fileless malware attacks do not use .PS1 files. In fact, the script runs on the attacker’s machine, not the victim’s machine, so there is no script for an execution policy to block.
Even though execution policies are powerless to stop a fileless malware attack that is targeting PowerShell, you should still make sure that your execution policies are set to either RemoteSigned or Restricted. These execution policies aren’t likely to block an attack by themselves, but they are one piece of a defense-in-depth strategy.
Of course, I still haven’t answered the question of why PowerShell doesn’t do anything to stop a fileless malware attack. The reason is because PowerShell is designed to be an administrative tool. Part of its job is to allow for the remote administration of Windows servers. A fileless malware attack uses exactly the same cmdlets and techniques as an administrator might use to remotely manage their servers. As such, PowerShell does not view such an attack as being malicious; it sees it as legitimate administrative activity. As previously noted, though, PowerShell itself is not to blame for such an attack. It’s the administrator’s job to harden servers and the underlying infrastructure to the point that an attacker is unable to launch a fileless malware attack.
(For Part 2 of this article series, click here.)
