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.

0:000> .load C:\Windows\Microsoft.NET\Framework\v2.0.50727\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.

0:000> g
...
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=032e0504 ecx=00000000 edx=00000000 esi=02f3acd0 edi=02c85d50
eip=004c2297 esp=0031eba4 ebp=0031ebd4 iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010297
004c2297 8b01            mov     eax,dword ptr [ecx]  ds:0023:00000000=????????

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:

0:000> !IP2MD @eip
MethodDesc: 001c6200
Method Name: PoshExeHostCmd.VBSPoSH.GetValue(System.String)
Class: 003706b8
MethodTable: 001c6234
mdToken: 060000b4
Module: 001c2c5c
IsJitted: yes
CodeAddr: 004c21f8

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:

0:000> !CLRStack
OS Thread Id: 0x9f4 (0)
ESP       EIP    
0031eba4 004c2297 PoshExeHostCmd.VBSPoSH.GetValue(System.String)
0031ebdc 004c1e2d PoshExeHostCmd.VBSPoSH.Execute(System.String, System.String[])
0031ec1c 004c0ba9 PoshExeHostCmd.Program.RunPowerShell(System.String[])
0031ed54 004c011c PoshExeHostCmd.Program.Main(System.String[])
0031ef88 6d2d1b4c [GCFrame: 0031ef88]

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.

0:000> sxe -c "!bpmd WMIQueryPS1.exe PoshExeHostCmd.VBSPoSH.Execute; g" ld
0:000> sx
  ct - Create thread - ignore
  et - Exit thread - ignore
 cpr - Create process - ignore
 epr - Exit process - break
  ld - Load module - break
       Command: "!bpmd WMIQueryPS1.exe PoshExeHostCmd.VBSPoSH.Execute; g"
  ud - Unload module - ignore
 ser - System error - ignore
 ibp - Initial breakpoint - break
 iml - Initial module load - ignore
 out - Debuggee output - output
...

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

0:000> g
JITTED PoshExeHostCmd!PoshExeHostCmd.VBSPoSH.Execute(System.String, System.String[])
Setting breakpoint: bp 016A1B98 [PoshExeHostCmd.VBSPoSH.Execute(System.String, System.String[])]
Breakpoint 0 hit
eax=013d61ac ebx=029b6a10 ecx=029b6a10 edx=0309f09c esi=00000000 edi=0309f608
eip=016a1b98 esp=002aed24 ebp=002aee5c iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000212
016a1b98 55              push    ebp

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

0:000> !CLRStack -p
OS Thread Id: 0xfe4 (0)
ESP       EIP    
002aed24 016a1b98 PoshExeHostCmd.VBSPoSH.Execute(System.String, System.String[])
    PARAMETERS:
        this = 0x029b6a10
        command = 0x0309f09c
        args = 0x029b1f84

002aed2c 016a0ba9 PoshExeHostCmd.Program.RunPowerShell(System.String[])
    PARAMETERS:
        args = <no data>

002aee64 016a011c PoshExeHostCmd.Program.Main(System.String[])
    PARAMETERS:
        args = <no data>

002af090 6d2d1b4c [GCFrame: 002af090]

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

0:000> !DumpObj -nofields 0x0309f09c
Name: System.String
MethodTable: 6ca40ae8
EEClass: 6c7fd65c
Size: 1386(0x56a) bytes
 (C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: # ==============================================================================================
# 
# Microsoft PowerShell Source File -- Created with SAPIEN Technologies PrimalScript 2012
# 
# NAME: 
# 
# AUTHOR: Alex , Toshiba
# DATE  : 4/24/2012
# 
# COMMENT: 
# 
# ==============================================================================================

$pass = ConvertTo-SecureString "SUPERSTRONGPASSWORD" -asplaintext -force
$credentials = new-object -typename System.Management.Automation.PSCredential -argumentlist "SUPERADMINUSER",$pass

Get-WmiObject -Credential $credentials -query "Select * from Win32_DiskDrive" -computername "SUPERSECRETSERVER"

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.