Monday, May 14, 2012

Extracting hard-coded credentials using managed code debugging techniques in Windbg

tl;dr version

Using some simple managed code debugging techniques, you can easily pull out hard-coded credentials from a binary claiming to protect them.

A friend of mine (@Obscuresec) referred me to a blog post from a software vendor claiming that if you absolutely have to hard-code credentials into a PowerShell script, that you'd at least be safer by using their product to wrap the script into a binary. If all reverse engineers were monkeys this might be true... and there are a lot of monkeys out there. To their credit, they advise their readers to never hard-code credentials into scripts. However, this monkey, when armed with a debugger will dispute (i.e. throw feces at) the vendor's claim that their product offers an additional layer of security.

Today, I'll be analyzing WMIQueryPS1.exe which can be obtained via the link above. WMIQueryPS1.exe is simply a .NET-compiled binary wrapper for a PowerShell script. The script used in this example passes domain credentials to a remote machine in order to execute a WMI query. The goal of this exercise is to pull out the credentials without decompiling the binary. Here's my step-by-step walk-though of how this was achieved.

1) Fire up the executable in WinDbg.

2) Load the CLR debugging extension for WinDbg - SOS.dll.

SOS.dll is a WinDbg extension used to aid in debugging managed code. More details on SOS.dll can be found here.

3) Let the program run its course and see what happens.

Lol. We have a null-pointer dereference and conveniently, a good place to stop and inspect the CLR environment.

4) First, let's see what method in managed code triggered the exception:

The !IP2MD command will tell you what method a particular JITed address belongs to. In this example, an exception was thrown in the PoshExeHostCmd.VBSPoSH.GetValue method.

5) Now let's see the CLR call stack and get some context as to how we got to where we did:

Considering this binary just wraps an obfuscated PowerShell script, it has to pass the deobfuscated script block as a parameter at some point. PoshExeHostCmd.VBSPoSH.Execute(System.String, System.String[]) looks like a good candidate method worth inspecting. Let's launch the assembly again and set a managed breakpoint on that method

6) In WinDbg, you can only set breakpoints on native code. To break on managed code, you rely upon the !bpmd command. Note: You cannot execute CLR debugger extension commands until mscorwks.dll has been loaded. Therefore, I'll set a conditional breakpoint upon the loading of a module and set a breakpoint for the managed method in a single instruction.

The sx command confirms that my 'conditional' breakpoint was set. Now, let the program run and it will break on the method in question.

7) Here we are. Let's check out the string that was passed to the method as an argument.

8) After poking around a bit, it turns out that the address of the 'command' object (0x0309f09c) is what we want to dump

9) Boom! All your creds are belong to me! I've just dumped the secret credentials that this vendor is claiming to protect. Not a difficult exercise.

I could have used these techniques in conjunction with a tool like .NET Reflector to decompile the method (SimpleDecodeData) that pulls the obfuscated scriptblock from the PE file's resource section and then deobfuscate the Powershell scriptblock but that would just be redundant. That, and the vendor might not appreciate it that much.

So what's the lesson in all this? Do not ever, EVER hard-code credentials into a file! If someone wants them bad enough (me), they will get them.


  1. Yeah, isn't THAT what the blog post says?

  2. Isn't WHAT what the blog post says? If you're referring to the post that I linked to, they show that after wrapping the script in the binary that you can't find the password with hex editor. I merely showed that the obscured password was just as vulnerable.

  3. The vendor claimed to add another layer of difficulty. He never claimed it was possible to get to the creds. Considering your efforts, the vendor was absolutely right. His binary wrapper does make it harder (not impossible) to get to the creds.
    I agree though that hard-coding creds is a security breach.

  4. I don't dispute any of what you're saying. In my opinion though, another layer of obscurity != another layer of security. That's the only point I'm making.

  5. Here, here good sir! I just want to comment to prove that I read this blog, but not "someone else's" blog... hehe. Good work, I don't understand any of it, but it's awesome. Maybe someday I will be there...

    1. Here, here old chum!

      You'll get there soon enough, Aaron Barr. ;D