Greetings smart folks,

I've been working at redoing some LSA secrets code based on some comments mao had made here:

http://oxid.netsons.org/phpBB2/viewtopic.php?t=149

This works like a charm, but begins to fall apart on Windows 2008. It turns out that, at least on a default installation of Win2K8, the PolSecretEncryptionKey value does not exist. This makes it impossible to decrypt the NL$KM value without resorting to something like scanning LSASS memory to find it. There have been substantial changes to the code surrounding these operations in lsasrv.dll (which is called by lsass.exe), such that I wonder about how this value is being handled these days.

Before I go looking over copious amounts of very complicated code to sort through this mess, I'm curious if anyone has any insights into how this value is now being used within Server 2008. Cain works fine, but it seems to me that it's using the LSASS method of querying this data, rather than the registry-only method discussed in the above link. This is fine, obviously, but I'd love to know more about what changed if anyone knows. :)

--fizzgig

- When you dump LSA secrets from the local system Cain uses DLL injection method.
- When you dump LSA secrets importing them from external Registry Hive Files it does not use DLL injection.



I never tested Cain on a Win2K8 but maybe it works like in Vista....

In Vista PolSecretEncryptionKey is not present so you need to ...

1) get the entire PolEKList buffer from RootKey\\Policy\\PolEKList hive key.

2) decrypt the entire PolEKList buffer using the startup key of 16 bytes (bootkey).

this can be achieved with the following function that uses SHA_256 and AES cipher (these function are found in OpenSSL):

void Decrypt_LSA_Buffer(unsigned char *buffer, int len, unsigned char *key, int keylen, unsigned char *output, int* outlen)
{
int dec_len = 0;
unsigned char* temp = (unsigned char*) calloc (len, sizeof(unsigned char));
unsigned char zero16[16];

memset (zero16,0,sizeof(zero16));

SHA256_CTX ctx256;
unsigned char final [32];

SHA256_Init (&ctx256);
SHA256_Update (&ctx256,key, keylen);

for (int i=0; i<1000; i++)
{
SHA256_Update (&ctx256, buffer+28 ,32);
}
SHA256_Final (final, &ctx256);

AES_KEY aes_key;
AES_set_decrypt_key(final, 256, &aes_key);

unsigned char* offset = &buffer[28+32];

for (dec_len=0; dec_len < (len-60); dec_len+=16)
{
if (memcmp(offset+dec_len,zero16,16) == 0) break;
AES_decrypt (offset+dec_len, temp+dec_len, &aes_key);
}

memcpy (output, temp, dec_len);
*outlen = dec_len;

free (temp);

}

The above function is used as follows:

...
...
int decoded_len = 0;
unsigned char decoded[256];
memset (decoded,0,sizeof(decoded));

Decrypt_LSA_Buffer(poleklist, listsize, (unsigned char*) startkey, 16, decoded, &decoded_len);

...
...

3) Now you can get the main_key from the decoded buffer

unsigned char main_key[32];
memcpy (main_key, decoded+0x44, 32);

4) Finally you can enumerate LSA Secrets and use the new calculated main_key of 32 bytes to decode them.

So this time you can call

memset (decoded,0,sizeof (decoded));
Decrypt_LSA_Buffer(buffer, blen, main_key, 32, decoded, &decoded_len);


for each LSA secret buffer to decode.

This is very useful, and I was beginning to see at least parts of this I guess. :) I am working on 2008 now and will make sure it works the same, but I suspect it does. If I ever bump into you somewhere mao, I owe you a beer. :)

i only took a quick look, but it seems like i might have already implemented this in qforegsics

This does indeed seem to work on Win 2K8 - at least I get the valid NL$KM value back. I'm certain testing tomorrow will in fact give me the correct cache values - I think this was the hard part.

The method used to store cached creds changed too, I see. I'm getting the same results as Cain, but it doesn't appear to be valid data. So close, yet so far. :)

I'll post if I find out how to work with this newer stuff.

Guys, I'm struggling on this too, can you please explain what is 'bootkey' in Vista?
Also, I've done some research on cached credential format in Vista (hope to complete it soon) and will share this info.

Hi mao, thanks for the great information. Using that I am able to successfully get the NL$KM, however I am having trouble using the NL$KM to decrypt domain cached credentials as the method to encrypt them has clearly changed for Vista and on.

Do you have any insight (or code snippets) about the new scheme? They would be greatly appreciated!

the encryption now is same as before except there is extra "wrapping" using PBKDF 2.0

hash = PBKDF2( MD4 ( MD4 ($password).$username)), iterations )

by default, the iterations value is 10,240

this can also be used for kerberos

here is what you can do to research how it all works.
download the debugging symbols and use PDB plugin by determina, then all will be revealed in IDA Pro ;)

Hi bus_driver,

The encryption scheme doesn't seem to be quite the same, the RC4 decryption that works for XP and previous is not successfully decrypting the cached credential (no user names / domain names etc are visible after decryption).

You do bring up a separate question I had been wondering about, I had read that 10240 was the default iterations for the PBKDF2 however I'm not sure where that number is specified. I had assumed it would be in the encrypted section of the cached credential however since I haven't managed to decrypt successfully I haven't been able to check on that.

The more pressing question to me is where does the salt come from for the PBKDF2? For normal PBKDF use we need:
* key
* salt
* rounds

The rounds, as you described, are normally 10240. Key is likely the normal MD4 ( MD4 ($password).$username) hash you described before, but where does the salt come from? Is it the Cipher key (0x40 - 0x50 of the domain cached credential), some version of the hashed username, or something else entirely?

Based on how PBKDF2 is set up compared to MD4, i would guess the set up bus_driver is indicating is the following:
key = $password
salt = $username
digest = MD4

Hi jmesmon,

As far as I can tell what bus_driver seems to be saying, and what is definitely said by http://www.passcape.com/domain_cached_passwords.htm, is that the PBKDF2 is done on top on the output of the MD4(MD4 ($password).$username)). According to the passcape.com article the hash function is SHA, my guess would be SHA256 based off the new LSA Secret encryption methodologies. Unfortunately, the article doesn't specify where the salt comes from.

Interesting. Unfortunately, it appears the link tom posted is broken (at least at my end), so i cannot read further on it.

Remove the comma at the end... http://www.passcape.com/domain_cached_passwords.htm

Should have noticed that...

Anyhow, the article does indicate that the hashing is done as tom stated. Anyone have anyluck determining the remaining unknowns? (SHA type, what the key is set to, what the salt is set to)