Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Let's say that I have a machine on my domain that has been compromised by an unknown attacker. If I use my domain credentials to log into that machine remotely, via RDP, does that expose my credentials to the attacker?

I know AD uses kerberos internally, but I'm unclear if the RDP client gets the kerberos ticket directly from the domain controller, or if it sends the login info to the server, which then gets the ticket.

To clarify, the computer running mstsc is Windows 7, and the possibly compromised machine is 2008 R2.

share|improve this question
    
How about changing your password prior to login, then chaging it again right after? –  uSlackr Apr 30 '12 at 3:06
    
Why are you even leaving the compromised system on the network? If you log into it, your credentials aren't even needed to take over AD (say, reset the password to every account in Domain Admins) - your session is enough. –  Shane Madden Apr 30 '12 at 5:04
    
We have systems where they run untrustworthy code. We've done our best to lock it down, but at the end of the day it's still code we don't really trust. I'm ultimately trying to determine how paranoid we need to be in terms of passwords. I didn't really want to confuse the question with details like that though. –  devicenull May 1 '12 at 0:30
add comment

2 Answers 2

up vote 1 down vote accepted

You may want to adjust your expectations, as today's attacker has more of advantage than you may think.

Any windows machine that has been compromised, anyone that has logged on to that machine, their token remains in memory until the machine is restarted. It is possible, and has been widely known for several years, to compromise the tokens in memory, and impersonate those accounts. Those compromised tokens can be used to attack other systems over the network with those credentials.

It is also worth noting that although Kerberos tokens have an expiration, windows process tokens do not - they are indefinite. This was a particularly curious design decision, given that authentication tokens do have an expiration field, but it isn't used by Windows.

http://www.mwrinfosecurity.com/assets/107/luke_jennings_mwrinfosecurity_MakingSenseOfRisk_one-token-to-rule-them-all2.ppt

share|improve this answer
    
That's.. pretty awful. I guess at the very least I should stop logging into machines with a Domain Admin account. –  devicenull May 2 '12 at 1:33
add comment

It would expose your credentials the same way as if you entered them at the terminal on the compromised machine (eg. possibly not at all, but quite possibly). Although SSPI (especially Kerberos) is supported starting from RDP6.0, usually mstsc does not obtain the kerberos ticket; it sends your keystrokes over the RDP connection (encrypted against the compromised machine's machine certificate), and the RDP server obtains the kerberos ticket. To rely on the fact the server can't steal user's credentials you must be 100% you are using Kerberos for authentication. But credentials are not the only subject of a potential stealing: as others pointed out, an adversary might hijack your authenticated session instead, no matter which protocol you used to get in.

share|improve this answer
1  
Happen to have any references for that? Based on even the quick description at msdn.microsoft.com/en-us/library/aa374743.aspx , the remote server should not be getting the password. –  devicenull Apr 30 '12 at 1:25
    
+1 - I'd also add that it makes sense to assume the credential is compromised if such a situation occurs. –  bangdang Apr 30 '12 at 1:26
2  
But this is pretty much one of the things that kerberos is designed to prevent. If the client is the one getting the ticket (as it should be), the password never makes it to the remote server. All the remote server gets is a ticket, which is valid for that specific machine, and for <5 minutes. See en.wikipedia.org/wiki/Kerberos_%28protocol%29#Description –  devicenull Apr 30 '12 at 1:34
    
Yes, that would be nice, wouldn't it. One thing you could do to avoid such problems as this would be to use smart card authentication for windows login; mstsc does support using certificates on the local machine to authenticate to the DC from the remote one. However, this still exposes you to MitM. The best thing to do with a compromised machine is either boot a PE and remove the local admin password before repairs, or just reimage it. –  Falcon Momot May 1 '12 at 19:14
    
One addendum to this. Although in most cases RDP just provides a way for you to interact with the login window on the remote computer, you can use the CredSSP support.microsoft.com/kb/951608 to delegate your kerberos ticket to the remote computer. However, this is still a possible compromise of your credentials. –  Falcon Momot May 2 '12 at 0:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.