It is a well known security risk that LSASS stores clear-text passwords if a user has performed a keyboard-interactive logon on a machine - be it local login to his/her workstation or using RDP to a remote workstation.
There is also a classic fix to this - disable wdigest and tspkg. So far so good, but if Kerberos is supported, then it apparently needs the clear text password to renew the Ticket Granting Ticket (TGT) and so you're left between a rock and a hard place - don't support Kerberos and enjoy all the risks associated with hash passing or support Kerberos and accept the risk of cleat-text passwords. The linked post gives the following advice which I think is unacceptable:
Therefore, the most effective protection is to avoid interactive logons to any untrusted hosts.
A big enterprise has 1000s of servers, how do you known which one is compromised and login should be avoided?
My question: are there any practical measures other than rolling out a 2FA (onto those issues later) that would permit a secure keyboard-interactive logon?
P.S. About 2FA. The most common methods are passcode + OTP and X.509 PKI on a smart-card. They aren't flawless either:
- if you have hijacked the lsass process, then you could arguably use the otp+passcode to log on to other servers while the passcode is valid. Using auotmation, this could mean you've logged on to tens of servers or more during the 60 second window
- As per this TechNet article the user sends the PIN to the server and makes the smart-card available to the RDP server. Same process as in the first item can be used to hack many servers while the admin is clicking away at the compromised server.
2018 Update: Starting from Windows Server 2012 R2 and Windows 8.1, the LSASS can be ran as a protected process by enabling the RunAsPPL setting and inhibiting credential dumping. Starting with Windows 10 and Server 2016, the Windows Credential Guard is enabled by default and achieves similar outcomes.