I bet I went about learning PowerShell the wrong way, so I may need your help, readers of this blog. If only to organize my knowledge and use it for the fight against malware and not just to figure out how it was used in malware.
The first serious look I had at PowerShell was when I was trying to figure out what some piece of malware was doing. But the most important lessons I learned back then was that PowerShell is very versatile and that its execution policy is hardly stopping anyone from performing malicious acts on an infected computer.
Both of these properties make it a powerful weapon in the hands of hackers, pen testers, and malware authors. Given the current tendency to use legitimate tools and programs in an attack, I want to learn more about it and see how we can use it to our advantage. Sort of as white hat hackers would.
Bypassing the execution policy
The PowerShell execution policy is what controls how much PowerShell can do on the system at hand. The possible settings can be found in this Technet article about Using the Set-ExecutionPolicy Cmdlet, where “Restricted” is the default setting.
But one of the first things I noticed was how trivial it is to bypass this restriction. The easiest way to run your PowerShell program is to “pipe” it and add a -executionpolicy bypass switch. This will ensure the command will run without taking the current execution policy into consideration. If the script is too complex to pipe, you can encode the entire script (base64) and use the switch –EncodedCommand. For malware authors, this has the added benefit that it will take the average user a lot longer to figure out what was done.
But let’s start with the basics first. PowerShell uses so-called cmdlets. These cmdlets typically perform a task and return a .NET object that can be piped to the next command. They are NOT standalone executables like some of the commands that we used in the command prompt, but rather .NET framework classes.
Windows PowerShell uses a verb-noun pair for the names of cmdlets and their derived classes. This makes it easy to understand what to expect. For example, if we look at the cmdlet ConvertTo-Xml it should be clear enough to figure out what will happen when you use it. And for cmdlets that aren’t so clear, or when you’d like to know more about the cmdlet or its syntax you can use the Get-Help cmdlet.
Another important thing to know about in this context, however, especially when reverse engineering a script, are aliases. A lot of cmdlets have an alias that triggers the cmdlet, but that doesn’t use the naming convention for them. For example, the alias del is in use for the cmdlet Remove-Item. An overview of the basic cmdlets, aliases, and functions can be obtained by running Get-Command which will show you an extensive list.
This was a quick summary of the working knowledge I have together with some de-obfuscation techniques and a lot of “looking stuff up”, it has been enough to serve my purpose of being able to figure out what others were doing. But I feel it’s time to learn some more, and since I learn best using the hands-on method, in the next post we will be doing some basic programming.
See you then!