QuickPost – disabling the Run command (without killing everything else)

I often have to do a bit of security hardening (in fact myself and fellow CTP Dave Brett did a lot of security hardening at one point, to the extent we did a presentation about it, and – quick plug – we shall be doing a second part of the presentation at the UK Citrix User Group very soon!) One thing we discovered in this project was that disabling the Run command in Windows gives you some unique problems.

The Run command is accessed via the WinX menu (the right-click Start Menu), or by pressing Win+R, or by choosing the New Task option from Task Manager, or by simply typing “Run” into the Start Menu, or even by finding it in the Start Menu subfolders under “Windows System”. We should all be familiar with it (in fact admins such as myself find it utterly invaluable for quickly running the consoles and programs we need).

Unfortunately, because it is so handy, it’s a key tool for an attacker to get hold of. The key to good hardening is to remember that an attacker will get in, sooner or later, and your job is to present enough hoops for them to jump through to limit the scope of their intrusion until your auditing and detection can spot them. Restricting the Run command, along with restricting PowerShell and command prompts and FTP and the like, is a vital way to slow an intruder down by making it more time-consuming, fiddly and frustrating to start achieving lateral movement through your network.

Of course, there has been a Group Policy Object to deal with this for a very long time. It sits in User Configuration | Admin Templates | Start Menu and Taskbar and is called Remove Run Menu from Start Menu. However – and this is a point both Dave and myself have made before – the GPO goes way beyond what you’d expect it to do. As well as blocking the Run command, the Win+R shortcut and the New Task button in Task Manager (which is all good), the “Remove Run” GPO also blocks you from accessing local drives, local folders and (most crucially) accessing UNC paths from the address bar or Explorer. The only way to access UNC paths is by network drive mappings (shudder) or created shortcuts, and that just makes it a real pain to apply, especially if your users are even remotely used to accessing network shares.

So is there any way we can remove the Run command without crippling a load of other UI functionality for our users?

Firstly, we need to remove the Run command from the WinX menu. This is pretty straightforward. I have a detailed article and video here about customizing the WinX menu, but if it’s just a case of removing the Run shortcut, you simply need to delete the following file from your users’ profiles:-

%LOCALAPPDATA%\Microsoft\Windows\WinX\Group2\Run.lnk

Sometimes, though, you may find you need to set up a GPP for this different file path instead (as the presence or function of the desktop.ini file in this folder may render the file unfindable by the GP engine:-

%LOCALAPPDATA%\Microsoft\Windows\WinX\Group2\1 – Run.lnk

(If in doubt, set up a GPP for both file paths and you should be good)

You could easily do this with a Group Policy Preferences Delete File Action as below:-

You can also use Item-Level Targeting to scope this to particular groups of users, thereby allowing some users to use it and others to have it removed.

Next, we need to stop “Run” from appearing in the Start Menu or when the Start Menu is searched.

This again is pretty simple (once you think about it). It’s just another shortcut within the user’s profile, so another GPP Delete File Action will suffice. This time the target is %APPDATA%\Microsoft\Windows\Start Menu\Programs\System Tools\Run.lnk. It is also important to note that because of the desktop.ini file, the folder that holds this file appears to be called Windows System (and that’s the name that shows on the Start Menu), but the real folder path (and hence the one you need to delete) is actually System Tools.

Again, you can apply an Item Level Target to scope this as required.

Bear in mind that with the two shortcuts above you could actually remove them from your default profile instead, but I prefer using this route as it is more robust.

Next we need to stop the Win+R key from being used to bring up the Run command. This again we can do with Group Policy Preferences. Create a GPP Registry item for the user and set it in Replace mode for the following item:-

• Action – Replace
• Hive – HKEY_CURRENT_USER
• Path – Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
• Value – DisabledHotKeys
• Value type – REG_EXPAND_SZ
• Value data – R

This will block the Windows + R key combination from being used. It applies to all combinations, though, so this would also block Windows + Shift + R (which doesn’t do anything as far as I know, but just for awareness). Incidentally, if you wanted to block more keys, you could just add them to the Data (so RM, for instance, would block Win+M as well, which minimizes everything)

That takes care of the hotkey. Now, what about Task Manager and the New Task command?

This is a little bit more restrictive to configure. The obvious way to handle it is just to fire up the GPO that blocks Task Manager entirely, which is in user Configuration | Admin Templates | System | Ctrl Alt Del Options and is called Remove Task Manager.

It does however mean users are unable to use Task Manager should you wish them to. I am currently doing some experimenting with Registry permissions to see if I can find a way to allow users to run the Task Manager without triggering the New Task function, I will update this post if I succeed.

However, there is one more secret way you can access the Run command. The Run command is simply an Explorer shell command, and if you create a shortcut pointing to the following path

%windir%\explorer.exe shell:::{2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}

this actually lets you trigger the Run command!

Now, I did think of a way of dealing with this but it was getting rather late, so hat tip to Jacques Bensimon for going and digging around a bit further to assess this. The GUID above does appear in the Registry (in two places) and if you remove it, then the Run command can’t be triggered from this shortcut – it throws this error instead.

However, it also means that you’re killing it for all users on the device, which isn’t great. So, instead, we have opted to hide the Registry keys from the users we wish to restrict the Run command for. We shall use FSLogix, because that’s the easiest way and doesn’t involve fighting TrustedInstaller for ownership first.

Simply create an FSLogix Hiding Rule and hide both of these Registry keys:-

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}

And restrict the assignments so that the users you want to lose access to Run in this way are the ones the rule applies to

For the record, I didn’t extensively test this method, so do your due diligence to make sure anything else isn’t affected by this, but it seemed to work fine.

This post is an interesting example of the “usability versus security” that myself and Dave originally presented about. We want to increase security but not at the extent of crippling the user’s work flows. This method is a good trade-off between making it harder for an attacker but at the same time allowing the user a bit of flex to get their job done. This way of blocking the Run command comes without the extra blocking provided by the GPO, but just does enough to slow down an attacker trying to laterally move through your network so that you have a better chance of spotting them before they do any damage. It’s a decent halfway house and when combined with a good layered defence strategy, it should hopefully buy you a bit of time.