Detecting PowerShell Malware Hacking - It's popular, so you better start doing this!

The Post Exploitation Kit known as PowerShell, included with every version of Windows since Win 7 is being taken advantage of more and more by criminal malware authors. SET and MetaSploit also use this method.

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:

First, the malware tried to hide the fact that a PowerShell script was being used.
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?

Logs are your best friend here!  The SEXY Six to the rescue...

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 * \\\c$ /u:TestUser /p:OhCrap'.
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!

1.  PowerShell -ExecutionPolicy bypass
2.  PowerShell -noprofuile
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!

You are looking for executions like this which are way outside the norm of what RunDll32 normally executes. Also this will occur on boot or infection. Check your Run keys and services for these type of executions as well. Malwarians LOVE replacing good Dll's with bad ones. And everyone must watch CMD.exe executions!!! Active Defense 101.

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

PoSeideon malware is incredibly easy to detect

Here we go again. A new PoS Malware variant dubbed PoSeidon has been analyzed by Cisco and the details made public. When I read this I said out loud, "This is stupid easy malware to detect".

Practicing Malware Management shows us there is so much to learn or validate that your defenses can indeed detect this type of attack. The Process also provides you with details to improve your defenses by adding or adjusting some checks.

PoSeidon uses typical malware vectors and seems to have nothing sophisticated, nor any improvements to hide or conceal the infection. If you have been practicing Malware Management or reading my other blog entries on the subject of malware, it will become apparent how typical and easy this malware variant is to detect. Let's take a look.

First off this is Windows malware so Eventcodes are key.

1. The loader is an odd .EXE that can be detected with EventCode 4688
2. The malware uses the Run Key for persistence to survive a reboot. Detectable by EventCode 4663 if you audit the Run Keys, which you should, it's Active Defense 101
3. The loader downloads and installs a file called FindStr.exe. We all know what the CMD FindStr does, so seeing this execute in a way that is not looking for a string in a file would be easy if you enabled command line logging (See below for the setting). Detectable by EventCode 4688.
4. If you look at the strings of the malware (after you found it), the project file name is a dead give away, "keylogger.pdb", hello McFly, really? They are not even trying to hide it. Detectable after you find the suspect file and use (strings -n 5 malware.exe | find /I ".pdb"). Not to mention the loader file also used "loader.pdb" as the project title, and even FindStr.pdb was found. Thank you malwarians for making it easy to see the project titles and that it's obviously malware.
5. Two file names were used, WinHost.exe and WinHost32.exe and saved in... You guessed it \Windows\Systems32. Detectable with EventCode 4663 if you enabled auditing for System32 for NEW files. Read the "Windows Logging Cheat Sheet" for more on this. Also detectable with EventCode 4688 as it will be an executable you have not seen before, thus suspicious.
6. There is mention the loader tries to install a service. Detectable by EventCode 7045, NEW Service installed, this too is Active Defense 101. Know your services!
7. Command lines, you gotta love them! To delete the loader the command "cmd.exe /c del >> NUL" was executed. If you are not watching what command line parameters are being called with ALL CMD.exe executions, you are missing the Goose that laid the Golden Egg! Detectable with the command line logging Reg Mod and Event Code 4688, focused on executions of CMD.exe
8. Of course there is the network traffic too, but that is another area of expertise and between "IPConfig /DisplayDNS" and "NetStat -abno" you can see what IP's and Domains are being used by the funky executables, IF you know what your systems normally run.This malware is almost laughable in the effort to hide what they are doing. Clear readable .pdb project names clearly indicating the files are malware shows strings are a powerful step in malware analysis.

I promote the SEXY Six Windows Event Codes and this malware is easily detectable using the SEXY Six.Read more about how to log Windows with my recent BSides presentations.

Get my presentations HERE to learn more on Malware Discovery and Logging

Remember, the goal is to take this information, tweak your tools to look for and detect the behaviors discussed and to improve your Incident Response and Information Security Programs to detect and respond to these persistent attacks.


And...  Enable Command Line logging on ALL Windows systems!  And Audit this key and alert to ANY and ALL changes.  Win 7 and Server 2008 R2 and later with patch KB3004375 installed (Feb 2015), Win 8.1 and Server 2012 already have it by design.


reg add "hklm\software\microsoft\windows\currentversion\policies\system\audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1
 
Happy Hunting !

Cisco details on PoSeidon malware

#InfoSec #HackerHurricane #Malware #CommandLine_Logging