Crack Active Directory User NTLM hash

[TurboMatt]

First and foremost, this is an ethical hack. Unfortunately we are in a situation where a co-worker has reset the AD credentials on a very important account. Because of this, we are locked out of several devices that use LDAP for authentication. Lucky enough, nobody knows the local passwords for the devices. So that's where we are.

I have restored the NTDS.dit and system32\config folders from a few of the domain controllers dating about a week ago. The NTDS.dit should have the old account password. 

After this, I extracted the hashes for the account in question using DSInternals.

So, I have the NTLM hashes and the LM hashes. I have been trying to use hashcat to crack these but I honestly don't know the best way to go about this.

Any advice on the best method or command strings to run?

Thanks!
Matt

[DanielG]

I don't get what your goal is here, any domain admin can change the password of the account so that is your best option.
You don't need to crack the NTLM hash for most other 'less-ethical' use cases (using pass-the-hash attack). The NTLM hash can be used to do a lot of things (for example authenticate on those devices).

Anyway, if you have the current NTLM hash and want to change the password on the AD (and for some reason you are not an admin) use this:
https://blog.stealthbits.com/manipulatin...ChangeNTLM

You can use mimikatz to run the command lsadump::changentlm /server:that.ad.server.of.yours /user:co-worker /old:extracted.ntlm.from.ntds.dit /newpassword:TurboMatt from any connected computer (you can also do the same with DSInternals you already used).

But again, this is a weird story considering any administrator can change the account password.

[blacktraffic]

First and foremost, this is an ethical hack. Unfortunately we are in a situation where a co-worker has reset the AD credentials on a very important account. Because of this, we are locked out of several devices that use LDAP for authentication. Lucky enough, nobody knows the local passwords for the devices. So that's where we are.

I have restored the NTDS.dit and system32\config folders from a few of the domain controllers dating about a week ago. The NTDS.dit should have the old account password. 

After this, I extracted the hashes for the account in question using DSInternals.

So, I have the NTLM hashes and the LM hashes. I have been trying to use hashcat to crack these but I honestly don't know the best way to go about this.

Any advice on the best method or command strings to run?

Thanks!
Matt

If it's at all modern, the LM hashes won't hold anything useful. To crack the NTLM hashes, I would run this on my laptop to start with.

Code:

hashcat64.exe -a0 -m 1000 ntlm-hashes dict\Top32Million-probable.txt -r rules\l33tpasspro.rule  --loopback  -O -w3

That is, dict and rules mode, -m 1000 is NTLM, then actual hash file, then dictionary, then -r rules file (substitute rules/best64.rule maybe to start with and see how you go ? ) 
--loopback feeds any answers you get back into a second run.
-O optimised kernel
-w3 work factor (reasonable for windows laptop, -w4 is OK for unix CLI interaction) 

If you have something a bit bigger than a laptop, use bigger dictionary and/or rules I guess. 

Alternatively, incremental mode, like this, but I'd try the other method first: 

Code:

hashcat64.exe -m 1000 -O -a3 -i ntlm-hashes

[philsmd]

The general idea is good @backtraffic... but ...

we really are trying hard to discourage the use of hardware without (good) cooling solutions here. so it's probably better to say: do NOT use any laptop instead of "I would run this on my laptop"

we also try to make it very clear that for -a 3 you always *should* specify a mask... because users somehow tend to believe that without a mask it is just doing --increment ?b?b?b?b?b?b?b (but from the documentation it's very clear that it's not the case: https://hashcat.net/wiki/doku.php?id=has...ult_values)

Anyway, I think (except from these small cherry picks) you guys are giving some great advice. I like this kind of (quick) help/community a lot. Thx

[blacktraffic]

The general idea is good @backtraffic... but ...

we really are trying hard to discourage the use of hardware without (good) cooling solutions here. so it's probably better to say: do NOT use any laptop instead of "I would run this on my laptop"

we also try to make it very clear that for -a 3 you always *should* specify a mask... because users somehow tend to believe that without a mask it is just doing --increment ?b?b?b?b?b?b?b (but from the documentation it's very clear that it's not the case: https://hashcat.net/wiki/doku.php?id=has...ult_values)

Anyway, I think (except from these small cherry picks) you guys are giving some great advice. I like this kind of (quick) help/community a lot. Thx

Point taken; I run a lot on my laptop and have never had any major issues, but it is not the recommended way of doing such things.  Listen to phil, don't listen to me

[TurboMatt]

I don't get what your goal is here, any domain admin can change the password of the account so that is your best option.
You don't need to crack the NTLM hash for most other 'less-ethical' use cases (using pass-the-hash attack). The NTLM hash can be used to do a lot of things (for example authenticate on those devices).

Anyway, if you have the current NTLM hash and want to change the password on the AD (and for some reason you are not an admin) use this:
https://blog.stealthbits.com/manipulatin...ChangeNTLM

You can use mimikatz to run the command lsadump::changentlm /server:that.ad.server.of.yours /user:co-worker /old:extracted.ntlm.from.ntds.dit /newpassword:TurboMatt from any connected computer (you can also do the same with DSInternals you already used).

But again, this is a weird story considering any administrator can change the account password.

I can absolutely understand you questioning the details. Lets assume there are 100 devices configured with LDAP authentication. All using the same service/user account for the LDAP bind aspect. That account had it's password changed by another admin. Half of the devices we were able to get onto to change the LDAP authentication configuration with the new password. The other half we don't have physical access (another location) nor do we have the local admin credentials. They were domain authentication only and now that they are trying to LDAP bind with the old password, they obviously won't authenticate. 

My thinking was to crack the old NTLM hash, key it into AD then quickly authenticate to the devices we are locked out of and reset the local account passwords. At that point, we would have local account access and would be able to correct the LDAP authentication on all the devices and within AD. As a note, I have no idea why this was initially configured this way but it's the mess I have to figure out now.

I will look into the injection command you posted. From what I can tell, it will not allow me to reuse the old hash completely?

[DanielG]

"My thinking was to crack the old NTLM hash, key it into AD"

I think you can change it back without knowing what the old password was. You can set the old NTLM hash with
lsadump::ChangeNTLM /server:AD.local /user:accountname /old:current.hash /new:hash.you.found.in.old.file
then update those 50 devices then set the new password back.

this way you won't need to run hashcat to find the old password

[TurboMatt]

"My thinking was to crack the old NTLM hash, key it into AD"

I think you can change it back without knowing what the old password was. You can set the old NTLM hash with
lsadump::ChangeNTLM /server:AD.local /user:accountname /old:current.hash /new:hash.you.found.in.old.file
then update those 50 devices then set the new password back.

this way you won't need to run hashcat to find the old password

This is exactly how I resolved the issue. Thanks for posting the information. However, I used the DSInternals version of this. It allowed me to inject the old hash directly into the domain controller that was the first one listed that the locked out devices were replicating against.

Thanks so much for all of the help! This was a huge relief to gain access back into the equipment. This was far easier than traveling across the country and hoping local console access would have worked.

Thanks again!
Matt

[DanielG]

Cool, I'm glad to hear it worked. Mind sharing the code / process with DSInternals? I haven't really used it yet but sounds interesting.

[TurboMatt]

Cool, I'm glad to hear it worked. Mind sharing the code / process with DSInternals? I haven't really used it yet but sounds interesting.

I have it saved on a computer at work. I'll copy it and paste it tomorrow.