I recently evaluated a SPAM barrage that included a Word Doc and ZIP file containing a Word Doc. At first I thought "laaame", but after throwing it into my lab malware analysis system, I was surprised what I found. Keeping in mind this was commodity malware since it came via Email, not APT, it had components that one would find in more advanced attacks.
PowerShell is well, powerful since it utilizes .NET. PowerShell can do just about anything on a Windows system. With this kind of capability PowerShell is a perfect exploitation option for malwarians as it is already on every system making it a no brainer for the criminal malware writers to utilize and reduce payloads on the system.
So what was special about this Word Doc SPAM I was given to analyze? For starters it bypassed the Word script protection we see when we open a Word document for the first time which is suppose to prompt the user to accept or enable macros. The malware had MS Word automatically run the embedded script displaying in the only page of the document, "There was an error contacting your financial institution". Another version I received had gibberish and failed the script bypass, clearly the BETA attempt of their malware.
So what was in the Word Doc? A quick peak at the file showed embedded script so I knew something bad was within. I opened it on my malware lab system to see what malness was hiding. The file dropped a .BAT, .VBS and .PS1 file and launched the batch file which called the .VBS file which then launched the PowerShell script. Oddly enough each script obfuscated the name of the next by using variables for parts of the name that were then assembled to create the commands to execute the next script. So if you ran strings against the files for things like .vbs or .ps1 you wouldn't have seen any results, maybe to hide from IPS and network sniffers too, lame.
In addition to the three scripts, an executable and PNG were dropped. The PNG a was the Google logo and the amount of writes that occurred to the image indicated to me the PNG was the keystroke logger file, hiding as an image. The malware pinged a site in China and then made a connection to a system in Germany. It's nice to play with multi-national malware. So what did the malware do from a PowerShell perspective?
A vew of the PowerShell reverse shell after MS Word closed as the parent:
Second, the VB script bypassed the PowerShell ExecutionPolicy in order to run the malware.ps1 script. PowerShell by default disables the ability to run .ps1 scripts without changing the ExecutionPolicy. Oh yeah, Microsoft has a built-in bypass for ExecutionPolicy, #fail.
Third, the script bypasses any profiles used, such as the default profile.ps1. Oh yeah, Microsoft has a built-in bypass for Running profiles, #fail. So if you are using a default profile, which I recommend everyone does due to the capabilities of PowerShell, the malwarians bypassed this as well. Why? Because this is where you set the two variables to enable command line logging to catch behavior just like this. All this from commodity malware used in a SPAM campaign. WOW!
PowerShell Bot for sale!!!
If you have not heard of this, there is a commodity bot named "Phase" that claims a "Fileless" malware to infect the targets. How? By using PowerShell to run the reverse shell. Using yet another flaw in Windows, Rundll32.exe, used to,load Dll's, common for services can launch JavaScript which in turns calls wscript, which in turn launches PowerShell, pOOf - Got Shell?
How does "Phase" persist? Lamely it is via the Run Key calling the PowerShell script via Rundll32 calling JavaScript which uses wscript to call PowerShell. And the kicker, the payload is hidden in the Registry as a benign entry waiting to be read, decrypted and executed.
So what are we learning from these two unrelated malware?
1. Bot Kits utilizing PowerShell as the heavy lifter are available making the injector virtually Fileless.
2. We are seeing malware using PowerShell more frequently.
3. If you set a default profile (profile.ps1), which I recommend everyone do to set command line logging for every PowerShell session, it can be bypassed.
4. If you have a default install of PowerShell and think it can't run .ps1 scripts, think again, the malwarians can bypass the PowerShell ExecutionPolicy, regardless of what you set it to.
5. Most people do not monitor for PowerShell execution or monitor the 'Windows PowerShell' logs.
6. PowerShell is used by system admins to manage Exchange servers for example.
So how do we deal with this new threat? How do we monitor for PowerShell nefarious behavior?
Of course you first must Enable your logs and Configure them. Please read my "Windows Logging Cheat Sheet" on How and What to enable and configure. If you feel you have your logs enabled and configured, then you are ready to detect PowerShell p0wnage!
1. Set 'Detailed Tracking - Audit Process Creation to Success'
2. Set the registry tweak to enable process command line logging (see below)
3. Check that you are capturing execution of a process and capturing the command line executing. Open a command window and type 'net use * \\
4. Open EventViewer, Splunk, WEvtUtil, LogParser or (snicker) PowerShell and look for EventCode 4688 in the Security log and find your Net Use test.
5. Do you see your test? If so then you are ready to detect PowerShell exploitation. If not, then you have not configured things correctly.
Now test that you can detect the following commands being executed. Open a command window and type the following:
1. "PowerShell -ExecutionPolicy bypass -noprofile"
2. "Rundll32 JavaScript wscript" and some other words
3. "CMD /c Cscript" and some fake script name
If you see any variation of the above three command lines in EventCode 4688 (Process Create - SUCCESS), then you are detecting PowerShell hacking! If you see any combination of the items below of PowerShell security bypasses being executed - INVESTIGATE!
3. cmd /c PowerShell -ExecutionPolicy bypass -noprofile
If you see any combination of powershell, javascript, mshtml, wscript, cscript or cmd.exe being executed in the command line of a 4688 event, you are probably being or have been hacked!
From the Phase bot:
Rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";eval((new%20ActiveXObject("WScript.Shell")).RegRead("HKCU\\Software\\Microsoft\\Active%20Setup\\Installed%20Components\\{72507C54-3577-4830-815B-310007F6135A}\\JavaScript"));close();
Watch the Registry for large key/value/data sizes
Look for large Registry keys and validate they are normal. Look for keys over 50k and work your way down to 20k as you build a Whitelist of normal large keys, there are a few that are normal. Use a tool like 'RegScanner' by NirSoft to search for large keys, a nice GUID utility. Any keys with data starting with "MZ" or "4D5A" are clearly bad and executable content. Of course if the key is encrypted in some way, as the case with Phase using RC4, then the starting values can be anything and the size, location and uniqueness will be your indicator of badness.
I hope this example of Malware Management, reading of malware analysis and tweaking your defenses helps you improve your capabilities.
Send me your comments.
Here is how to enable Command Line logging for Windows systems (kb3004375 patch needed):
reg add "hklm\software\microsoft\windows\currentversion\policies\system\audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1
The Windows Logging Cheat Sheet
Great articles on PowerShell based malware:
MalwareTech article on Phase - Part 1
MalwareTech article on Phase - Part 2
Great article on Poweliks PowerShell malware
Happy Hunting!
#InfoSec #HackerHurricane #PowerShell #Hacking