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.
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