1

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.

devicenull
  • 5,572
  • 1
  • 25
  • 31
  • How about changing your password prior to login, then chaging it again right after? – uSlackr Apr 30 '12 at 03: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 05: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 01 '12 at 00:30

2 Answers2

4

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.

If you want to make sure the server can't steal your password, you need to be certain you are using kerberos to authenticate over RDP. You could also use certificate-based (that is, smart card) authentication - but bear in mind that unless configured otherwise, RDP will pass through smart card auth in many cases.

Bear in mind, also, that stealing your credentials isn't the only threat here. No matter what, the target machine will at some point have your ticket-granting ticket on it, meaning that it will be able to perform actions as you for the validity of the ticket-granting ticket. This is basically session fixation. The compromised server could also just hijack your session.

In short, no, this isn't particularly safe.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
  • 1
    Happen to have any references for that? Based on even the quick description at http://msdn.microsoft.com/en-us/library/aa374743.aspx , the remote server should not be getting the password. – devicenull Apr 30 '12 at 01: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 01: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 http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Description – devicenull Apr 30 '12 at 01: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 01 '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 http://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 02 '12 at 00:02
3

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

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • That's.. pretty awful. I guess at the very least I should stop logging into machines with a Domain Admin account. – devicenull May 02 '12 at 01:33