Since the inception of PowerShell, it has been a blessing for Windows administrators everywhere. As Don Jones so eloquently puts it, "you can either learn PowerShell, or learn to ask, 'would you like fries with that?'” I couldn’t agree with that sentiment more. After all, with server core being the default installation option of Windows Server 2012, knowledge of PowerShell is becoming increasingly crucial. This is what Microsoft wants because they know deep down that an IT workforce armed with powerful automation is more productive, profitable, and able to focus more of their time on difficult problems – versus becoming mindless, button-pushing drones.
However, (cliché warning!) with great power comes great responsibility. PowerShell, in my opinion is an extremely viable attack platform. To my knowledge, PowerShell has only recently emerged as an attack platform, starting with Dave Kennedy and Josh Kelly’s seminal Defcon talk – PowerShell OMFG. In fact, as a security researcher, it was their talk that inspired me to learn PowerShell in the first place.
Infosec professionals know that getting access to a target machine is only the first step. There is such a wealth of exploits and social engineering techniques out there that the fear isn’t if you’ll be compromised, it’s when or how long you’ve already been compromised. That is, assuming you’re a valuable enough target to warrant being targeted in the first place. Post-exploitation tactics and strategy is everything if you want access to the crown jewels.
So why is PowerShell such a juicy target in a post-exploitation scenario? To understand why, it will help to understand the primary roadblock attackers will run into on a Windows platform – Antivirus/Host-based IDS/IPS.
Malicious binaries (exes/dlls) enable an attacker to perform any attack imaginable primarily due to an executable’s unfettered access to the Win32 API. However, between sophisticated heuristical runtime signatures and reputation-based signatures, AV vendors have certainly raised the bar when it comes to executing malware compiled to native assembly.
Scripting languages offer an advantage to an attacker because they provide a layer of abstraction that AV has no idea how to interpret. For example, a common AV bypass technique is to package malicious Python scripts into an executable. AV has a hard time distinguishing the resulting binary as malicious or legitimate because the Python interpreter itself has plenty of legitimate uses. PowerShell offers a distinct advantage in this scenario due to its tight integration with the Windows OS and considering it’s based upon the .NET framework. With such a powerful scripting environment, there is no need to drop files on disk. Everything, with the possible exception of the script itself run entirely memory-resident.
Furthermore, access to the .NET framework enables an attacker to choose their target’s poison both at a lower-level via P/Invoke (i.e. direct access to Win32 API) or via a higher-level interpreted “language/framework” - .NET. Both have their advantages and disadvantages and if you read my previous blog posts, you’ll begin to understand the merits of both methodologies. Recently, my research has lead me to believe that reflection is the ideal compromise between the high and low-level languages in terms of bypassing Antivirus. In fact, I hope to have a tangible product in the near future (~ 6 months) to substantiate my claim.
Another increasing trend of attackers is that they are leveraging existing tools to carry out their attacks. This is a logical progression since it enables one to remain under the radar by mixing in with legitimate administrative chatter. After all, who needs to execute a binary with a reverse shell payload when you have RDP, psexec, net, cmd, cscript, wmic, wbemtest, mofcomp, PowerShell, etc. at your disposal. Obviously, I’m generalizing but you get my point. So why do I choose PowerShell? Quite simply, it combines the functionality of all the aforementioned admin tools while adding its own unique functionality. In particular, I’m referring to the following:
- Simple access to network sockets
- Ability to assemble malicious binaries dynamically in memory
- Direct access to the Win32 API
- Simple interface to WMI
- A powerful scripting environment
- Dynamic, runtime method calls
- Easy access to crypto libraries
- Ability to hook managed code
- Simple bindings to COM
- Etc…
With a few notable exceptions, PowerShell has just about everything an attacker could ask for.
The bottom line is, PowerShell is not the exploit itself, it’s the enabler of further compromise. However, this should come as no surprise. Any tool that can be used for legitimate purposes can and will be used for malicious purposes. PowerShell simply mitigates many of the risks malicious actors face when operating on an already compromised machine. In the mean time, the cat and mouse game will continue and when PowerShell is sufficiently locked down, attackers will move on to the next target. The ultimate goal is to prevent, mitigate, detect, and respond to attacks rendering the PowerShell attack vector null and void.