I received the following question in an email today:

What authentication is being “two factored”? For instance; is a pass the hash technique, where the Hash from an admin is captured and used to connect to another machine through e.g. smb, always made impossible because a two factor authentication is required? Or is pass the hash still possible because you’ll only prevent an RDP from being single factor?

That's a perceptive question considering that most admins have never even heard of a "pass the hash" attack, or considered what it means to say that you have "two-factor authentication" and what the limits are. So I have reproduced my answer below, hoping it will be of general interest!

The answer to your question about credential capture and re-use is quite nuanced. You can enforce 2FA everywhere, or only on some systems, etc., depending on your needs. Other 2F solutions are only secure if you create a completely sealed boundary (VPN, etc.) of 2-factor-ness, but all the logic inside that perimeter still runs insecurely. That works fine if you don't make any mistakes and if your threat model is only external attackers. For protection of domain admin accounts, that's pretty insufficient in my opinion.

To clarify things, let's start out by forgetting password hashes for the moment; we will say the attacker captures the password itself via a key logger or watching you type, or guessing etc. They now know one of your authentication factors. The attacker can use this knowledge to gain access to any systems that allow one-factor (password only) authentication. But any system or service that requires 2-factor would be protected from this attack.

Now we can add into the discussion some similar but more subtle attacks. Plain hashes are not very often sent on the wire these days, but if an attacker can obtain in some way the true MD4 hash of your password (what is commonly referred to as "the" hash) then they can authenticate to any services that use NTLM authentication, again only if those services don't enforce 2-factor. There are several ways to make them enforce 2-factor auth however, so this can be protected.

More insidiously than hash passing is ticket "passing". It simply means, if the attacker can obtain an authenticated kerberos ticket, they can use it to gain access to other services. This is why it's not sufficient to block things at the authentication point. What we want to do is to stamp the kerberos ticket with information about how the login was done (1 vs 2 factor group) so that later on, services can examine it and authorize or block based on that knowledge. AuthLite is the ONLY two factor solution (apart from smart cards) that can do this fairly important operation. (And strictly speaking the smart cards aren't quite as good because they have an underlying hash that can be replayed to access NTLM services, but that's a separate issue.)

Lastly we can discuss the worst case, the "man in session" attack, where the attacker gains access to your true, 2-factor authenticated session, by for example having a root kit on your workstation or other major compromise. In this case, the attacker for all practical purposes is really you and can do whatever you can do. They cannot produce additional OTP authentications to use in the future, but they have your current well-authenticated session and your true 2FA kerberos ticket to use until it expires. (Unless the attacker is offline and waits until the session is expired, in which case you'd be OK.. but why assume they are sleeping? If they have rooted you, it should be assumed they or their tools are paying attention!).

Every single authentication product will fall to this last attack. You only begin to make progress against it with solutions that audit and control every operation going on in the network, which goes very far beyond the concept of simple authentication.

Hope this helps!