Why You Should Use RDP RestrictedAdmin

When Mark Simos and I documented Microsoft’s public guidance for deploying a Privileged Access Workstation, one of the features we leveraged is Remote Desktop’s /RestrictedAdmin feature (RDPRA for short).  This feature, one of many introduced in the massive KB2871997 update (and its siblings), allows administrators to connect to remote systems without exposing their credentials to the target system.  I can’t stress how important this change is – an administrator who connects using “normal” RDP exposes his or her credentials to the remote system with every connection.  RDPRA, on the other hand, ensures that credentials aren’t exposed to the attacker on the remote computer being managed.

RDPRA remains a hidden gem, so in this blog I want to demystify it a bit and reinforce why you too should use it any time you remotely manage a device (especially devices which are less secure than the one from which you’re connecting).  Ultimately, I want everyone to use RDPRA every time you use Remote Desktop for administration (including connections to servers and workstations).

[caption id="attachment_155" align="alignnone" width="289"] Figure 1: The modified RDP RestrictedAdmin title bar.[/caption]

Remote Desktop has long been an administrator’s best friend, allowing interactive access even if the target system is on the other side of the world.  Assuming that the target system allows remote access and the requesting user has been granted the right to log on via Remote Desktop, the remote user connects to the target system using a Type 10 Remote Interactive logon request across TCP 3389 (the default RDP port).  [There’s a bit more to it if you require Network Level Authentication, but the basics are still the same.] If you peek into the local security agent (LSASS) with common attack tools on the target system, you’ll see that the remote user’s credentials now appear in memory.  This is the source of the security risk with normal RDP – if the credentials are on the target system, they’re exposed to theft by an attacker on that system.

[caption id="attachment_145" align="alignnone" width="300"] Figure 2: WCE output showing credentials captured during a normal (non-RDPRA) Remote Desktop session[/caption]

Here’s an example of how an attacker would exploit this:

• Alice is a user at Contoso, and she uses her workstation to browse the Internet and read email.  She falls victim to a phishing attack and inadvertently downloads malware to her workstation.
• Bob, the attacker, now has access to all identities on that system, but at this point Alice is the only person who’s logged into the workstation.
• Bob wants the lure privileged users into logging into Alice’s workstation, so he deletes files on Alice’s system that will break Outlook.
• The next morning, Alice can’t start Outlook, and calls the help desk for assistance.  Alice is based in New York, but the help desk agent, Carlos, is based in Mumbai – too far for an in-person visit, obviously, but that distance is nothing to Remote Desktop!
• Carlos logs into the workstation using RDP to troubleshoot the problem, and as a result his credentials now appear in LSASS memory.
• Bob has been waiting for just this opportunity, and he grabs Carlos’ reusable credentials and uses them to connect to systems which only Carlos can access.  The initial compromise has now turned into a wider breach.

[caption id="attachment_135" align="alignnone" width="739"] Figure 3: This attack timeline shows how an attacker can compromise credentials provided via traditional Remote Desktop.[/caption]

Why does this work?  From a technical perspective, Remote Desktop connections are functionally equivalent to those issued when an end user is sitting directly in front of the target system.  A Type 10 Remote Interactive logon is indeed an interactive logon – the end user has authenticated to Active Directory and the local security agent (LSASS) on the target system now has a copy of that user’s credentials, which can be used by a malicious individual to impersonate the remotely-connected user.  [For more on credential theft, please see Mark’s excellent video at https://aka.ms/credtheftdemo.]

So if connecting remotely exposes our credentials like this, how do we securely administer remote systems? Enter RDPRA.  When you connect using the /RestrictedAdmin switch, Remote Desktop uses a modified Remote Interactive logon through which the user is authenticated, but reusable credentials are never sent to the target system.  Because the administrator signs on with network authentication, the target system receives only a Kerberos service ticket or the NTLM challenge responses, rather than the user’s actual credentials – which on the whole is a very good thing.  In our example above, Carlos used normal RDP to connect, and thus exposed his credentials (username and password, or provided access to his smart card).  If Carlos instead used RDPRA, neither his username/password combination nor derived credentials would ever appear in LSASS memory, and Bob wouldn’t be able to even see them, let alone steal them.

It’s no accident that we recommend that administrators use RDPRA with Privileged Access Workstations.  PAWs provide a safe starting point for privileged access, while RDPRA minimizes the exposure of the credentials on the targets.  By using these together, I can have a very high degree of confidence that my privileged credentials are never exposed to attackers at the source (PAW) or at the target (RDPRA session).

[caption id="attachment_125" align="alignnone" width="770"] Figure 4: This attack timeline shows how privileged credentials enable remote support without exposing privileged credentials to an attacker on the target workstation.[/caption]

[As an aside, RDPRA is a poor fit in general for “Jump Servers” scenarios where users connect to an RDP server and from there connect to other resources. This is because credentials are never provided directly to the target system (jump server) and any additional connection you try to make from that jump server requires you to enter new credentials.]

When we introduced RDPRA in KB2871997, it was initially enabled by default.  After feedback from the wider security community, we changed this because many organizations use RDP for remote access to their environment over the internet and this increased their attack surface without notice. Because of this, you now have to enable RDPRA for workstations and servers (see this article for instructions).

Some of those same security professionals who raised the aforementioned issue also raised a specific technical concern about how RDPRA “enables” attackers to combine RDP with credential reuse in order to access remote systems interactively in ways they couldn’t before.  While technically accurate, those concerns are overblown in the real world. This new “attack” requires the attacker to have already stolen valid admin credentials, and these credentials can already be used in numerous other ways besides RDP (accessing Active Directory, modifying services, connecting via Remote Registry, and so on). The attacker could even crack the credential information to access the original passwords. Furthermore, to launch an RDPRA-based credential reuse attack, you need to use a special RDP client (for example, this one described by Portcullis Labs).  Every new piece of software downloaded onto your systems is another opportunity to catch the bad guys at work – attackers can’t just reuse the default Remote Desktop client. Simply put, the additional protection from RDPRA (reduced exposure of privileged credentials) far outweighs the additional risk represented by the RDPRA credential reuse “attack” (minimal within the intranet environment).  And when combined with other credential protection mechanisms (e.g. PAW), it’s extremely secure.

RDPRA isn’t meant to be a complete security solution on its own, but it is a critical component of a complete credential theft mitigation program.  Every administrator should include RDPRA in his or her standard toolkit because it’s the most secure way to remotely access and manage target systems. To see how to adopt RDPRA as part of your security standards, you can also check out Microsoft’s recommended Operational standards.