I’m working on a larger post about the various types of login (network, local, rdp etc) and what each of them presents to an attacker; but i wanted to first understand a little more about NTLM based logon to a Windows/Active Directory environment.

I’m going to block Kerberos (Port 88) on the single domain controller in the lab environment to get started (with a simple block rule in Windows firewall). I’m also logging on with a brand new domain account to avoid any confusion with cached credentials.

The first thing to note is that logon was very slow, the process took about six minutes and i could see the client attempting to use kerberos over and over. Here’s an example showing the last time the client tried kerberos, 408 seconds into the trace before eventually logging in. I left a little extra in the image to show that the client is consistently trying to go back to kerberos, and the decision to eventually move forward with NTLM seems to be a tough one.

We can see the eventual NTLM authentication for both the RPC and LDAP communication by filtering with “ntlmssp”:

Once we do log in, things are roughly as we would expect the client side.

The most notable absences are kerberos tickets and a TGT.

The local security token looks good though, as a user, after the slow start, things seem ok.

In the image below i’m trying to illustrate that we added the ‘dropbear\chad’ account to a domain group called “testgroup1” just to show that despite not being able to use kerberos at all, our user ends up with the things they need in the local security token

To further illustrate the point we could show that even if we disable the network interface on this local machine so that no further NTLM is possible, we should be able to access resources requiring membership in the “testgroup1” group.

And of course, we can.

With that in mind, what do we actually have on this machine that might be useful to an attacker?

When we fire off: privilege::debug" then "securlsa::logonpasswords we notice that we are able to extract:

• Local user (the local admin account i used to fire a console up for mimikatz):
  • NTLM hash from memory (confirmed the hash matches the password with: https://www.browserling.com/tools/ntlm-hash)
  • SHA1 from memory.
• Domain User:
  • NTLM hash  from memory (confirmed the hash matches the password with: https://www.browserling.com/tools/ntlm-hash)
  • SHA1 from memory</li>
  • DPAPI information from memory (DPAPI: https://github.com/gentilkiwi/mimikatz/wiki/module-~-dpapi)
  • (most interestingly) The plain text password. TIL from GentilKiwi that when the Kerberos client cant talk to a domain controller, it just hangs on to the password for you :)

”

So with that in mind, what can an attacker find on a machine that that was logged on only with NTLM?

• We’ll, they could find, and probably pass your hash as usual.
• They could also try to crack the hash.
• But most interestingly (to me), if they are able to get the SeDebug privilege, they are going to be able to just take your password from the kerberos client that it was holding on to till it found a domain controller. This is despite modern versions of Windows not storing the password in memory.

Assuming credential guard is not in use

So having access to your human readable password is pretty great. But just to top off my interesting TIL moment, i also noticed that the computer password is in the same boat. Remember, the computer password obviously wasn’t typed in, but it was shoved into the kerberos client ready to encrypt the authentication data and all that wizardry and now it’s just sitting there available to be read - that’s fascinating!

Anyway, that’s a few notes about what a domain joined machine credentials look like when kerberos is unavailable.