Penetration Testing mailing list archives

Re: pwdump 2 & 3


From: miguel.dilaj () pharma novartis com
Date: Thu, 16 Dec 2004 10:39:17 +0100

Hi!

Well... the facts first:
The logon credentials of the last 10 users that login into a particular 
machine (that's true, you can see that the last 10 users that login into a 
machine are able to login even when disconnected from the network, thanks 
to the cached credentials) are cached somewhere in the local machine 
(someone mentioned to me the LSA Secrets, but I'm not sure about this 
location, can also be somewhere else in the protected section of the 
registry. LSA itself is one of these protected sections. Please read on).
Take into account that the caching can be (and should be? ;-) disabled 
with the following registry key:
HKLM\SOFTWARE\MICROSOFT\WINDOWS 
NT\CURRENTVERSION\WINLOGON\CACHEDLOGONSCOUNT (change it to 1 to disable 
the caching)
My guess is that this information is SYSKEYed or encrypted in some other 
way.

Cain (http://www.oxid.it) has the ability to show the contents of the LSA Secrets, and you can 
see, for example, all passwords for DUN there (under RASDialParams) and 
the machine account, but you won't see any useful user cached logon 
credentials, at least not in the clear.
lsadump2 (http://www.bindview.com/Support/RAZOR/Utilities/Windows/lsadump2_readme.cfm) produces exactly the same 
results as Cain.
If I suppose that they have really dumped anything, and I don't have any 
reason to think otherwise, then the cached credentials are NOT in the LSA 
Secrets.

On the other hand, there's a very suspicious location on the registry (I'm 
accessing the registry as SYSTEM, I don't know if this location can be 
accessed as administrator):
HKLM\Security\Cache
Guess what? There are 10 items there, NL$1 to NL$10 ;-)
Every one of them is a binary key, that doesn't look like plain-old hashes 
or anything like that, but my guess is that this is the place to 
investigate.
To have confirmation of the above, read: http://support.microsoft.com/default.aspx?scid=kb;en-us;199071

So far so good. Now to the bad news (extract from a post of Nicolas Ruff 
in the full-disclosure list, http://seclists.org/lists/fulldisclosure/2003/Dec/0794.html):
"Cached logon are stored in some kind of "double hash" way ( 
LM(LM(password)) or NTLM(NTLM(password))
) - very difficult to break in a reasonable time, but still vulnerable to 
dictionnary attacks.
However I do not know any publicly released tool able to retrieve and 
crack cached logon (even if I
am working on it :-). "

So the point is that you can still modify an Open Source password cracking 
tool like Lepton's Crack (I prefer this one because you simply have to 
create a new module, and it will be heavily based on the LM and NTLM 
modules already existing) to do the double operation mentioned above, and 
check how to match the result with the information you obtained from the 
registry...
The idea will be to hash a know plaintext (the password) to obtain the 
BINARY hash (not the hex representation of it) and hash it again, you can 
represent the result in hex.
Then you've to look for the hex string in the cached logons section.
Of course to do the test you'll use a know cached logon (get a snapshot of 
your current cached credentials, create a new user with a know password, 
logon as this user, and check what's new in the cached logon storage, this 
will correspond to the know user+password).
For a manual test, doesn't sound too dificult.
IF IT WORKS (i.e., if you found the hex string corresponding to the 
password), it will be better if someone creates a tool to dump only the 
relevant bytes from HKLM\Security\Cache\NL$1 to NK$10 to a text file as 
hex strings, then this file can be attacked with the modified password 
cracker that does double hashing...

Perhaps it's not only the password that was double hashed, but also the 
userID (remember that the items NL$1 to NL$10 don't show any plaintext, so 
no userID, but it can also be that the userID is indicated by the numeric 
ID, not the name...)

OK, who has time to test all the above? ;-)
Cheers,

Miguel Dilaj (Nekromancer)
Vice-President of IT Security Research, OISSG

PD: FYI, there's also pwdump4, it more or less combines pwdump2 and 3, and 
also incorporates some extra functionality 
(http://www.xfocus.net/tools/200309/549.html)






IndianZ <indianz () indianz ch>
15/12/2004 20:41

 
        To:     pen-test () securityfocus com
        cc:     (bcc: Miguel Dilaj/PH/Novartis)
        Subject:        Re: pwdump 2 & 3


Hi

Well it is possible, that logon-information is not cached locally (I mean, 
only in memory) for security reasons. Seems like you have to get the SAM 
(with all domain-users inside) from a domain-controller ;-)... Did you 
check for other SAM-files in the local filesystem (%windir%\repair)?

GreetZ from IndianZ

mailto:indianz () indianz ch
http://www.indianz.ch


On Wed, 15 Dec 2004 19:17:19 +0100
Guillaume Lavoix <glavoix () altadis com> wrote:

Hello,

Does anyone knows if it is posible with pwdump to get the information
About a logged on user.

For instance, If I log on my computer, I use a domain logon, and when I
execute pwdump I only see local user....

Any idea ?

Thanks for your help,

Sincerely,
Guillaume




Current thread: