SOURCE CODE:
http://oss.coresecurity.com/pshtoolkit/release/1.3/pshtoolkit_v1.3-src.tgz
BINARIES:
http://oss.coresecurity.com/pshtoolkit/release/1.3/pshtoolkit_v1.3.tgz
DOCUMENTATION:
http://oss.coresecurity.com/projects/pshtoolkit.htm
http://oss.coresecurity.com/pshtoolkit/doc/index.html
WHATSNEW:
Pass-The-Hash Toolkit 1.3 by Hernan Ochoa (hochoa@coresecurity.com, hernan@gmail.com)
=====================================================================================
What's new?:
* PASSTHEHASH.IDC: This .IDC IDA Pro script can be used to obtain the addresses
iam and whosthere need to obtain/modify logon session credentials. Load LSASRV.DLL
into IDA Pro (make sure to import the symbols) and run the script to get the
addresses you need to add to the source code to add support for the LSASRV.DLL version
you have, in case it is not supported yet.
If you use the script, please send me the addresses so I can include them in
the next version of the toolkit.
* IAM-ALT and WHOSTHERE-ALT: two new tools written from scratch that do the
same thing that IAM and WHOSTHERE do but using a slightly different technique,
aiming at making the tool work on more systems without requiring users to
modify the source code of iam/whosthere (or wait for the next version:)).
The good thing about this 'alt' version of the iam/whosthere tools is that
they SHOULD work on more windows versions without modifications.
The 'bad' thing is that both tools need to execute code inside lsass.exe.
The tools basically use the functions MSV1_0.DLL!NlpDeletePrimaryCredential,
MSV1_0.DLL!NlpAddPrimaryCredential, and MSV1_0.DLL!NlpGetPrimaryCredential;
these are the functions gsecdump uses (if I'm not mistaken).
The current heuristics used to find the functions inside MSV1_0.DLL is horrible
but it works.
whosthere uses a method tha allows it to obtain credentials just by
reading memory, without executing any code. iam does not, but just
because I'm lazy, it will do it eventually, the downside to this approach
is that although it does use heuristics to verify hardcoded addresses, it
does have hardcoded addresses anyways.And that's why to help solve this issue
but at the same time maintain the possiblity of obtaining credentials
without executing code inside lsass.exe, I created the passthehash.idc
script. If you don't care about executing code inside lsass.exe, use
whosthere-alt.
*iam/whosthere: Added support for more windows versions. including different languages.
*iam/iam-alt: new syntax. now you have to use -h to specify the credentials.
*whosthere/whosthere-alt: new -o switch to dump credentials to a file
*whosthere/whosthere-alt: new -i switch that will make whosthere/whosthere-alt
display current logon credentials found in memory and then wait forever for
new logon sessions and display only those new sessions. you can use this switch
together with the -o switch to dump credentials found to a file. Now you can leave the
tool running and it will log all unique interactive logon sessions created, it makes
easier the job of waiting for the administrator to log into the compromised
machine where whosthere/whosthere-alt is running. Thanks to heathengod for the
idea of this feature.
*several bugfixes and stuff
9 comments:
unless I am missing something? 1.3 has the same three hardcoded addresses as 1.2
an option you might want to consider is letting the user specify which logon session to modify. this will let terminal service users enjoy modified credentials, the tool just has to be run as SYSTEM.
and I cannot get your IDA script to work, neither of those functions are found. I am loading the symbols and searching for addcredentials and addmemory by hand finds nothing also. any tips on what I'm missing?
strike my last. IDA is being a bitch but olly comes through.
Ok,
1-If the IDC script doesn't work, is that for some reason the right symbols are not being loaded into IDA Pro. The script does nothing more than looking for the symbols and printing those symbols for you in the format you need to have them to add to the source code. In the next release I'll add an option to specify the addresses of the symbols without having to recompile the apps. Some users have already reported me that the script didn't work for them, but in all instances I've seen the issue is that the right symbols are not loaded. These same users have made the script work after 'tweaking' the symbols loading process into loading the needed symbols. If you can't make IDA Pro do that, please send me an email, with the IDA Pro version you're using and I'll try to troubleshoot the problem with you.
2-About the addresses not being there, damn! I thought I had put those in there, sorry :) I'll check again. Anyways, send me an email, I can send you a working version very easily. Or just use iam-alt/whosthere-alt, I think they should work.
3-About terminal services, ok, I'll add the option to let you choose the logon session to change. I was not too concerned about that because you are supposed to be running iam.exe/iam-alt.exe from your own machine from the main 'console', never thought someone would actually use iam.exe/iam-alt.exe from a terminal service session. Anyways, its a good option to have, so I'll add that.
Keep it coming!. :)
Thanks!.
I don't know why IDA isn't loading the correct symbols, it says it is retrieving then loading '129' symbols. Doesn't matter though, now that I know what to look for I can get the from Ollydbg just as easy. I'm not in a in a hurry for more addresses since I found the addresses for the 2003sp2 version via olly. Addresses for 2000sp4 would be nice though, haven't been able to find those.
The terminal server thing might seem a little more black hat but that's certainly not my intent, I just noticed that it did not work under a ts session. Just a suggestion, I don't need that myself.
Nice work btw :)
mm, yes, there's a problem there, because lsasrv.dll has way more than 129 symbols. Did you ever loaded lsasrv.dll into ida before? have you ever imported a PDB for lsaasrv.dll before? I don't know, all I can think of is that there's an old PDB or 'incomplete' pdb or something that is messing things up. What IDA version are you using? 5.x?
If you ever can make it work, please let me know if you figured out the problem! :)
Thanks!
so i got to playing with the psh1.3 toolkit.
when i run iam.exe and iam-alt.exe i get a credentials successfully passed but nothing "appears" to be changing. if i do a whoami, i get the local acct i logged in as, if i start a process it says its owned by the local acct i logged in as. i am doing all this thru psexec. is there a better way to do this? something else i should try?
if you run iam.exe/iam-alt.exe and then whosthere.exe/whosthere-alt.exe do you see the changes?
If you do, you're probably running the tool in the wrong interactive session, or something even more weird :).
What windows version are you using? is your box using NTLM auth or kerberos?
you don't have interactiv access to the machine you are running the tools on?
Thanks!,
Hernan
I'm having troubles using iam-alt.exe. The whosthere-alt.exe is working fine, it gives me the correct hashes, I have double-checked them. If I use iam-alt.exe, something really strange happens. It sets the username and domain correctly, but not the LM hash and NTLM hashes. For example if the LM hash is 1234567890abcdef... than it sets 2040608000b0d0f0... I have also tried the IDC script with a fresh 5.4 IDA Pro demo, but I think the pdb part is doing something wrong. I can also see pdb(c:\windows\system32\lsasrv.dll): Class not registered. Is it normal or is it an error? I am using a Hungarian Windows XP SP2.
Many Thanks
Post a Comment