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!

WinRM in Workgroup Environments

Just a quick blog post this time, mainly focusing on some configuration items you “may” need to do if you are working with WinRM, in particular in workgroup environments. These are settings you may need to configure client side when trying to interact with servers. You probably saw these in the notes section of Get-WinRMPassword.

Firstly, how do you view your configuration?

winrm get winrm/config

Next, if you are connecting to systems where HTTP listeners have been configured on the server, if your running on a later Windows Client, you will need to allow for the connection to be made. By default “unencrypted” that is HTTP sessions will not be allowed.

winrm set winrm/config/service @{AllowUnencrypted="true"}

Now I recommend enabling basic auth, just incase.

winrm set winrm/config/client/auth @{Basic="true"}

Finally, the server a client connects to, actually needs to be listed in trusted hosts. This can be done like this:

winrm set winrm/config/client @{TrustedHosts="myserver"}

Note that the command above will clear any other trusted host entries you might have.

And that is pretty much all you need to do!

The easiest to understand guides are (in no particular order):

• vCenter Orchestrator Plug-Ins - Configure WinRM to Use HTTP
• vCenter Orchestrator Plug-Ins - Configure WinRM to Use HTTPS
• Installation and Configuration for Windows Remote Management
• Authentication for Remote Connections

PowerShell + WinRM = Get-WinRMPassword

Hi All!

So I was working out what I will be putting in the paper based upon my PowerShell Shenanigans presentation from CrikeyCon, and started to ponder a few things around WinRM. In particular:

How many machines have WinRM exposed to the public Internet?

Out of these, are they exposing HTTP or HTTPS endpoints?

Could this be an interesting remote dictionary/brute force attack?

Could this be written in PowerShell for humour sake?

Could we use this to breach a network and go from there?

Has anyone else thought of this?

Let’s take a look at the answers to these questions.

Well the first two are pretty easy to answer. Turning to our good friend, Shaodan, we can put in some queries to get some rough estimates:

WinRM HTTP Hosts (TCP 5985)     185316

WinRM HTTPS Hosts (TCP 5986)    83840

Now we can’t easily assume that there is 269156 individual hosts out there, because we might have some duplicates (hosts listening on both HTTP and HTTPS) as well as some hosts with other services out there. There could also be older Windows Server systems listening on TCP 80 and 443. Either way, almost 300K is a pretty nice number to work with.

Now surely people really are not enabling HTTP? Well, I found this on some of my “out of the box” test systems. Interesting.

I think this would be an interesting attack method…

Could we make an attack tool and could it be made in PowerShell? It turns out, Microsoft has given us a significant amount code to perform this attack. As usual, let’s see if there is anything in PowerShell which looks like the basis for a brute force or dictionary based attack tool…test-wsman looks good!

Get-Help Test-WSMan: http://pastebin.com/uxKeEPHr

And we know how to read files and build PSCredential objects dynamically. So what would the CMDLet look like then?

CMDLet, Get-WinRMPassword: http://pastebin.com/RdygF0J6

And how would it work?

Examples: http://pastebin.com/pUhVazW3

So has anyone else done this? Yes, and some very smart people pointed out this as a possibility several years ago. TheLightCosine and Mubix (disclosure: I am a massive fan of Mubix’ work) talked about this very thing back in November 2012, and even wrote a MetaSploit module doing just this.  And there were some very interesting discussions on Reddit about a year ago,  and even a post on NetSPI.Com.

So some bright people pointed it out, and no one really seemed to pay much attention, this is a real shame.

So where to from here? Well, it is really hard to tell to be honest. WinRM has be around for a number of years (almost 10) and yet it isn’t something that has gained a huge amount of attention in the IT community, from an automation or security point-of-view. Brian Krebs wrote late last year on Windows RDP enabled servers to which access was for sale on underground forums. Attackers had gained access to these systems via poorly selected passwords and RDP connections exposed to the internet, whilst it certainly is easy to brute force passwords via RDP, WinRM makes it even easier, yet there doesn’t seem to be much of an appetite.

It could be that we simply do not know about it. It could be the case that a lot of these systems with WinRM exposed could have been taken over my malicious users and we simply don’t know about it. I really hope to see more people looking at why they are exposing WinRM to the internet, and if they have indeed been attacked via it. Perhaps now that we are shinning some light on it, we might really see what is hiding in the dark.

Risky Business: Featuring ME! Kieran Jacobsen

Patrick Grey interviewed me for Risky Business on Wednesday, and on Friday, the whole world got to hear the result. You can find the interview here.

Here is a brief description from the site:

On this week's show we have a look at PowerShell, the Microsoft sorta scripting language admin thingy. As it turns out, PowerShell can be an attacker's best friend when it comes to lateral movement through a network. We'll chat with Kieran Jacobson about that in this week's feature interview. He did a cracker presentation at CrikeyCon where he demo'd owning a domain controller and dumping all its creds with something like five lines of PowerShell. I mean, there are caveats there, but wow... the demotime was food for thought.

I am still working on Video/Paper, and have also been side tracked on another super awesome use of PowerShell + WinRM.

Thank you all for all of your feedback over the past week!

Crikey, was CrikeyCon FUN!

I am still overwhelmed by the amazing and super positive response from my presentation at this year’s inaugural CrikeyCon. I really didn’t expect anywhere near the reaction from those who attended, it has taken the last few days for everything to really sink in. I never expected people to be so amazed by the lateral movement capabilities of PowerShell combined with WinRM, I expected some to be shocked but not as many as I did.

As requested, you can find the slide deck here, and the GitHub code is available here. If you take a look through my GitHub repositories, you will notice how much PowerShell code I normally write, and you can also see the previous version of the same code.

I have to admit, there are two minor inaccuracies in my presentation. One makes things better, the other makes things much, much worse.

1.            In the slides I stated that “WinRM is enabled by DEFAULT on domain 2012(R1/R2) joined servers”. I gathered this from Microsoft, but upon further investigation, this link from Microsoft actually states the situation is much worse: “In Windows Server 2012 R2 and Windows Server 2012, remote management is enabled by default.”

2.            During question time, I said that installing the Windows Remote Management 4.0 bundle onto Windows 2008 (R1/2) servers, will enable WinRM for domain joined systems. I currently don’t believe this to be true, there doesn’t seem to be any confirmation from Microsoft, I am still testing in my lab and will let you all know.

I am currently working on an extended video of my presentation, in which I will go into more detail around each of the issues and will show the code in detail as well. I am also planning on writing a paper which will discuss using PowerShell and WinRM for lateral movement, possible attack vectors as well as strategies to protect your environment. Once these have been completed, I will let you all know.

I would really like to thank Ash and Wade for convincing me to speak and for organising CrikeyCon as well as Patrick over at Risky.biz for being an excellent MC.

Lastly, sorry for the lame title for this post.

Once again:

Slides

GitHub