Hardening of a server system is an omnipresent topic. We all tend to provide the most secure environment (hopefully) to reduce the amount of possible attacks on the system. One of the applicable measures is the restriction of the user access to the system. There are several ways to restrict the user access, but in most environments that I’ve seen, Active Directory group policies have been used to achieve this. Besides the prohibition of the access to the Windows Registry and Command Prompt, there are thousands of other settings that might be applied because of security or user requirements.
As probably known, all policy settings configured under „User Configuration \ Policies \ Administrative Templates” are applied in the user’s registry hive under „HKEY_CURRENT_USER\Software\Policies” and „HKEY_CURRENT_USER\Software\Microsoft\Policies”. Unlike other user registry paths, where the user usually has full control, these registry trees are configured with read only permission for the user. This circumstance ensures that the user is not allowed to change any of the applied settings.

BUT there is one simple function (actually two), that can be used to easily avoid all of your configured user group polices and to use all applications the user has access to unless the appropriate NTFS permission has been removed.

RunAs and Run as different User

With the command “runas /user:domain\user application” or the use of “Run as different User” from the context menu (shift + right click) applications can be started with different user credentials. So far so good, but did you ask yourself what these functions actually do?

RunAs and “Run as different User” allow a user to start an application with different user credentials. When one of these functions is performed, an authentication occurs and a new process will be created with the specified user account. Unless nothing else defined, the user’s profile or a temporary profile will be loaded. As this procedure does not include a typical user logon process, no user group policies will be applied and you will hardly find any other footprints beside the profile and the user’s registry hive under HKEY_USERS.
You can double-check that by opening the Task Manager. You will find the appropriate process running with the specified user account, but the user will not be listed in the users menu of the Task Manager. Additionally there will be no group policy settings listed in the user’s registry hive under HKEY_USERS\SID of the user or temporary profile\Software\Policies or Software\Microsoft\Policies.

And that’s the point! This circumstance allows a user to work without any user policies, i.e. the likelihood of attacks increases.  The user account is a normal user on the system and the NTFS permissions still apply to the user. These two factors continue complicating the possibility to harm the system. Nevertheless a few doors are opened now, and a clever user might take advantage of this situation.

Before continuing with the article, I would like to point out, that the presented use case as well as the further explanations and recommendations are related to a user session. The purpose of this article is to restrict the users whereas the administrators retain the access to this functionality.

Imagine the following use case. One of your users is having two Active Directory user accounts, which is very common as a lot of users have a normal and a test account within the same domain. Both accounts are just local users on the system and the usage of RunAs or “Run as different User” is not prohibited. The user is signed in with the normal account and uses now the second account to start a program with the RunAs or “Run as different User” method. Under these conditions, the user would be able to start any program he has access to.

How to prohibit the access to programs

From my point of view, the only way to do the application restriction right, is to use the AppLocker rules or other third-party tools. In general I recommend my customers to use the AppLocker rules, because they are for free and offer enough flexibility to configure the restriction according to your needs. All AppLocker settings reside under „Computer Configuration \ Polices \ Windows Settings \ Security Settings \ Application Control Polices” and therefore all configurations are applied in the registry under „HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\SrpV2”. Thus with AppLocker the RunAs and “Run as different User” method will not work, because all settings are applied on the computer and are not user related.

If you are not willing to use the AppLocker rules for any reason, you can still restrict the RunAs and “Run as different User” function by removing the access to it.
In the earlier days it was very simple. Removing the user permission from runas.exe was enough to completely restrict the access to both functions. But since the release of Windows Server 2008 R2, the „Run as different User“ command has changed and does not base on runas.exe anymore. You have to perform two steps to completely remove the RunAs and “Run as different User” functions:

1. Restrict the access to runas.exe. There are two ways to achieve that:
a) Configure an AppLocker rule and deny the access to C:\Windows\System32\runas.exe for the appropriate user groups.
b) Remove the user permission from C:\Windows\System32\runas.exe

2. The second step is to remove the „Run as different User” entry from the context menu. Therefor you have to delete the following registry keys
HKEY_CLASSES_ROOT\exefile\shell\runasuser
HKEY_CLASSES_ROOT\batfile\shell\runasuser
HKEY_CLASSES_ROOT\cmdfile\shell\runasuser
HKEY_CLASSES_ROOT\mscfile\shell\runasuser
HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser
(This change will affect the administrators as well)

Even if you have already restricted the application access through AppLocker rules or another third-party tool, I still recommend to remove the context menu entry to provide the most secure solution possible.

If you are still looking for a simple way to restrict the access to the functions for everyone (administrators and users), then disable the Secondary Logon service (thanks Martin Latteier for the input).

Let’s have a final look at the risk management. I agree that this is a rather rare scenario. However, it is crucial not to underestimate the internal hazard and its possible negative impacts on the system. As you can see, there are only a few steps ahead of you to reduce the risk exposure. Therefore I strongly recommend to implement the above described measures to ensure high system security.

I hope you enjoyed the reading.

Best regards

Saša Petrović