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.

DirectAccess with Computer Certificates and SHA512 algorithms

I have posted this as a question on the TechNet forums, but also wanted to post it here.

I have just finished another test lab deployment of Direct Access, and have noticed one interesting issue which I am trying to confirm.

In the lab I deployed the PKI part of the infrastructure quite a while ago, its a typical deployment, with an offline root and online issuing authority. They were configured to use the SHA512 for the Signature and Signature Hash algorithms. This selection might seem paranoid, but has never been an issue as all clients have been Windows 7 or higher and thus have full support.

I deployed direct access, and using basically the default settings, everything appears to be working correctly, clients could successfully connect.

I then switched to requiring computer certificates, issued a certificate to the DA Server and the test clients based upon the "Computer" template.

Clients could no longer connect. Looking at the diagnostic logs for Direct Access it appeared that the tunnels were not being established correctly. Looking at get-DAConnectivityStatus, there was definitely an issue present, with a sub status error referring to errors with remote network authentication. Nothing really appeared out of the ordinary in the client diagnostic logs or event viewer.

I went looking on the server, nothing appeared at first to point to a problem, however on inspection of the system event log, there were errors in regards to TLS:

'An TLS 1.2 connection request was recieved from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed'

So I looked around and didn't find anything out there, I couldn't see anything obvious, then it occurred to me that we are using SHA512 in our certificates.

I quickly fired up a new CA in the test environment, this time basically accepting the defaults. Reissued certificates computer certificates to the DA server and the test clients, and I am now successfully connecting.

Does anyone know of this incompatibility? is it documented anywhere? IS this known by anyone? Has anyone seen this as well?

Any more info would be great.

Automating Nmap analysis with PowerShell

Nmap is one of the best tools in a sysadmin's toolkit; this powerful tool allows us to quickly determine what computers and devices are on our network, what software and operating systems are running.

In most environments, esp. when there are a large number of servers and workstations in quite a number of subnets, its handy for system administrators to be able to easily find a free IP address.

There have been several times when various security managers have requested to know the following items:

• All servers/workstations that are up
• Are the following services running: SSH, Telnet, FTP, HTTP, HTTPS, RDP, SMTP
• Is there anonymous FTP?
• Is there anonymous FTP uploads?

Nmap is obviously the tool to complete the task to find out this information. If we could automate this, then we could easily generate reports for upper management!

Thankfully, the guys over at SANS have already completed most of the work for us. In the post: PowerShell Script To Parse nmap XML Output, the provide a script which gets Nmap XML output and makes it into a format that allows any powershell user to manipulate the results using all the usual commands (format-table, format-list, where-object, select-object).

I developed a simple script to find IP addresses that were in use and provide a simple output that any system administrator or service desk operator could read. The script is simple, and does the following tasks for each subject listed in an array:

1. Make a user friendly filename
2. Run nmap to perform a number of ICMP and TCP scans to find servers that are up (I recommend TCP SYN scanning on top of ICMP Ping to ensure you find firewall protected servers and workstations)
3. Parse the results of nmap and put them into a file in a more friendly format

The script looks like this:

nmap Command breakdown:

-PS20,21,22,23,25,3389,80,443,8080 is a TCP SYN Ping sweep of the subnet of ports 20, 21, 22 etc

-PE is ICMP ping (usual ping command)

-R is perform a reverse DNS look up

--dns-servers is specifying all of our DNS servers (incase you have reverse lookup zones across differing DNS servers)

-p 20,21,22,23,25,3389,80,443,8080 we want to scan these ports for possible reports later on

-oX $nmapfile --no-stylesheet outout the results to the filename and don't use a XML sylesheet

-A enable all advanced options

-v we want verbose output for reporting.

We end with the subnet we want to scan.

PowerShell RoboCopy Wrapper

So I find myself copying files from point A to point B on a regular basis, so much so, that I find myself using robocopy in a Windows scheduled task. The problem with this approach, is that there isn't many easy ways of working out if it worked, or worse, if something bad has happened!

I bashed out a script several years ago, and finally updated it to make use of the template that I posted up previous.

There are a few things to note with the script:

• I always check if the source and destination exist, and report an error if they don't
• My scripts always use the /MIR command, and limit retries to 3
• Robocopy return codes:
  0: Completed sucessfully, but didn't copy any files
  1: Completed sucessfully and copied files
  rest: some error has occured

The bulk of the code is:

#robocopy task
$result = robocopy $source $destination /MIR /R:3

#robocopy sucess is:     0: no errors, but no copying done
#                        1: one or more files were copied sucessfully

#check there were no errors in the robo copy
if ($lastexitcode -gt 1)
{
    if ($lastexitcode -eq 0)
    {
        $messagebody = "Robocopy completed but no files copied! `n"
        foreach ($x in $result) {$messagebody = $messagebody + $x + "`n"}
        send-email $messagebody $false
    } elseif ($lastexitcode -eq 1)
    {
        #do nothing, it worked
    } else {
        $messagebody = "Robocopy returned an unknown error! `n"
        foreach ($x in $result) {$messagebody = $messagebody + $x + "`n"}
        send-email $messagebody $false
        exit 3
    }
}

The entire script is in the samples section, here.