Restricted Admin mode for RDP in Windows 8.1 / 2012 R2
<# EDIT .. there has been a wiki article posted by my colleague John Rodriguez at https://social.technet.microsoft.com/wiki/contents/articles/32905.how-to-enable-restricted-admin-mode-for-remote-desktop.aspx that discusses RDPRA configuration further which is a good source for information and seeing it’s a WIKI is also a better place to keep updated easily #>
So we released some information a couple of weeks ago on the upcoming OS releases that mentioned various security features that will be built into the new operating system. Specifically one that was mentioned at a briefing at Blackhat was a Restricted Admin mode for RDP where "theftable” (is that a word??) credentials would not be exposed to the target system. This is basically to add another mitigation for Pass the Hash attacks and will allow admins to more easily connect to systems to locally administer them without having to worry about exposing their credentials to that weaker/less secure system. Some good examples would be Help Desk personnel connecting to various workstations could utilize this without having to worry about losing/needing to change their passwords after the session, another good one would be a Domain Admin for some reason needing to connect to a member server to do some needed administration work for some reason.
So the setting comes in the form of a new command line switch for MSTSC.exe. If you run mstsc /? you will have the following a new option:
So lets launch a connection with this mstsc /restrictedadmin
The first thing I see after connecting to my remote box that looks new is the bar up top.
We have a little padlock on it so check that out and it says we verified the target using Kerberos. Great!! however that is not what restrictedAdmin is about so lets dig a little further.
Running a whoami /groups shows the following:
It still says that I’m the same person i.e. forest\kurt and from a group membership perspective I still am a “Domain Admin” / “Enterprise Admin” etc so I guess that’s good from the local administration of the server perspective. I also ran whoami /priv which shows privileges that you have on the system and they are also identical to the privileges I would have if I didn’t use the Restricted Admin mode.
However I heard that once you try to leave the box you are doing so in the context of the computer account so lets check that out. So I attempted to open \\pfes3ms4\C$ (Domain Controller) and immediately get an authentication prompt which shouldn’t happen if I truly am a EA/DA account so what gives?
So lets look at the other side of this connection from the DC side and examine what we see from an incoming perspective. I Fired up Procmon on the DC and start capturing (remember you need to turn off the default filter as I want to look at the System\Lanmanserver process for incoming file share requests). Normally if you are getting an Access Denied to the file system/share you can see it this way and see the user account attempting to access the share/file etc. Unfortunately Procmon on the target server showed absolutely nothing so either I did something wrong or it doesn’t get that far up the stack not sure. I tried netmon on the receiving server side next and we see the following:
So from this perspective I can see that an SMB TREE CONNECT request came in for \\pfes3ms4\c$ and we are getting denied access. If I knew my SMB2 parsing better here I might be able to tell which account I am seeing from the originating system but I don’t so I went to the security audit log to see what we see on the receiving side when this occurs
The security event log in turn shows me that this is NOT my FOREST\kurt account attempting to logon to the share but is instead the computer account PFES3MS5$ coming across the wire to access the share. So from an audit perspective now if I see failed attempts for resources from a computer account it could either be malware/legitimate services running in the system context OR it could be an admin using /restrictedadmin mode who tried to access something across the network while forgetting he/she was in restricted admin mode.
So what about auditing on the local target system of a restrictedadmin session what does that look like compared to a regular TS session?
Actually it looks pretty normal. I’m still seeing a Logon Type = 10 i.e. Terminal Server logon and the account is still my account no funkiness with the computer account etc so from an auditing perspective in my SIEM’s etc I can still expect to look for the same things. Now whether or not there is some attribute that points out that the connection was a remoteadmin one or not I cannot seem to find unfortunately although there may be a way to do that.
On another note it was mentioned at the Blackhat presentation that this was possibly controllable via a GPO i.e. you might be able to set a GPO on a group of say workstations and either say it’s require to use restrictedadmin to connect to them or perhaps you could force it on users that they are required to use restrictedadmin to connect to remote systems? Either way I looked through what I believe was every RDS setting on both the user and computer sides of GPO’s for 8.1/2012 R2 and have not been able to find such functionality so either I’m just missing it or possibly that’s a feature that will be forthcoming in a future build.
Edit 11/4/2013
Had another engineer point out the GPO setting for controlling this finally to me so adding that in here as well, shown in the picture below. This controls the RDP client itself so would apply this to the initiating system for a connection not the connection receiving machine. Example if I had 8.1 clients all over my network it would be a good idea to force this setting on my helpdesk personnel systems so that when they RDP to client systems they would be forced to use Restricted Admin mode. I have yet to test this setting out but have it here for completeness sake.
In general this is a great new feature and a good step towards limiting credential theft via PtH tools. Unfortunately at the onset this is definitely going to require 8.1/2012 R2 so unless we end up doing some backporting may not be immediately useful in your environment until you get those 8.1 migrations rolling 
.
Thanks for reading
Kurt
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
is there an option to completely disable "Restricted admin" mode ?Anonymous
January 22, 2014
The comment has been removedAnonymous
January 22, 2014
The comment has been removedAnonymous
May 19, 2014
Pingback from Windows 2012 R2: RestrictedAdmin Mode RDP | DevAdmin BlogAnonymous
May 27, 2014
Test
Anonymous
June 10, 2014
The comment has been removedAnonymous
June 10, 2014
can you point me to the reference malicious kernel driver?Anonymous
July 07, 2014
^ http://www.microsoft.com/en-us/download/driver.aspxAnonymous
January 03, 2015
like this video PTH attack with LSASS Bug
https://www.youtube.com/watch?v=NmfBPN_idWoAnonymous
February 19, 2015
This is a follow on post to my previous one about a year ago regarding RDPRA (yeah just made upAnonymous
March 21, 2015
Nice article. While I was testing /restrictedadmin mode, when accessing \SERVERC$ administrative shares I noticed that I could not connect using old NT style authentication (DOMAINUSERNAME), but I could connect using UPN (USERNAME@FQDN). You probably already know this but I'm posting it here for others to reference.Anonymous
May 10, 2015
Great article and very well explained. ThanksAnonymous
July 27, 2015
In other words, the regular user is up in deep S__t! & going to cost &.Anonymous
December 12, 2015
but how can you take restricted mode off