Windows Remote Management, or Win RM, is a web-based SOAP interface to the WMI, or Windows Management Instrumentation Service, on Windows platforms. WMI and, through Win RM, allows the execution of queries for the configuration of the system. So, using Win RM a remote user can actually send web requests and get information about how a system is configured, what users are set up on it, what hardware is there, etc.This is all available to you without actually having to first gain a shell in the box by sending a payload, which could be detected or blocked by an IPS system or antivirus. So it gives us, right off the bat, some great reconnaissance abilities.
On top of that, Windows Remote Management comes with a second piece called Win RS, or Windows Remote Shell. Windows Remote Shell actually takes those requests and executes arbitrary commands on the victim machine, again, without ever sending a payload that could be detected by defensive measures.
The Win RS will the send the output back. So this allows us, just like the WMI portion to gain information. This allows us to actually perform actions on the system without having to worry about sending a payload to our victim.
In addition, we have an actual exploit module in Metasploit for abusing this service, specifically the Win RS service, that comes with two basic exploitation methods. The first uses power shell. The exploit will try to detect the presence of power shell, and if it finds power shell is present on the machine, it will use Win RS to write out a power shell script to the file system, and that power shell script will then get executed and talked back to our Metasploit instance to set up the rest of our payload transaction. This is really important because the power shell portion of this payload is not detected by any known current antivirus solution.
The fall back method if power shell is not available is a little less reliable in terms of antivirus. It uses VB script to actually set up an executable on the file system. So what happens in this case is a Base64 encoded file is first place on the file system. A Base64 file is an encoded version of our .exe payload. Then a VB script file is also written out to the file system, and that VB script is then run. The VB script reads in the contents of that Base64 encoded file, decodes them, and writes it back out as an .exe on the file system and immediately executes it. While this is a good fall back and is reliable because VB script exists on all modern versions of Windows, because we're writing an .exe to the file system, we are going to have problems with antivirus detection.
Why this is really important is a couple of things. It gives us the ability to gain an unprecedented level of information about a machine without ever getting a session on that box first. It also provides an alternative to the PsExec module, which has been around for a long time. PsExec has always been useful for taking known credentials on a box and turning it into a session. The problem is that PsExec, of course, drops an .exe, whereas with our power shell method on this exploit we can avoid that antivirus detection pitfall.
So that's it in a nutshell for Win RM. If you want more information, you can check out the blog post about the same topic on Rapid7's community site SecurityStreet or check out the webcast I'll be doing with EthicalHacker.net. Thank you and we'll see you next week.
