This is an old trick, but I still see a number of Administrators that think they have locked users out of the command prompt by simply removing the icon from the menu and disabling the Start–> Run option. In this post I’ll discuss how to create a command prompt with Visual Basic for Applications (VBA), as well as how to mitigate (although never completely eliminate) the risk of someone achieving access to the prompt.
Creating a command prompt with VBA
This technique will work with any application that supports VBA, but I’m specifically going to use Microsoft Word in my example. Here’s what you need to do:
- Launch Microsoft Word
- Press “ALT-F11” to launch the VBA editor
- Double click “ThisDocument” in the left pane
- When the editor window appears, type in the text shown in Figure #1
- Press the “F5” key
Figure 1: Our simple VB script
You should see a command prompt window appear in your task bar. Here’s a copy of the code you need in step 4 so you can copy/paste:
Sub GetCMD()
Shell “cmd.exe cmd.exe”
End Sub
How to prevent VBA from spawning a command prompt
Execution of the command prompt can be disabled with the Group Policy Editor tool. Here are the steps:
- Click Start –> Run
- Type in “gpedit.msc” (without the quotes)
- Click User Configuration –> Administrative Templates –> System
- Search down the list for “Prevent access to the command prompt” and double click it
You have two options available to you:
- Enable/Disable access to the command prompt
- Yes/No Disable command prompt scripting process
If you only disable the first option, direct access to cmd.exe is prevented but a smart user can still get to it via a batch file. To prevent script access, need to disable the second option as well. This prevents ALL scripting however and can play havoc in many environments. Also, both of these settings will apply to the Administrator account as well. This can make admin and troubleshooting far more difficult.
Even with both options disabled, a user can still get around these settings by using command.com instead of cmd.exe. To fix this, you need to restrict access to command.com via user permissions. If you are still running some old 16-bit apps, this fix will break them.
All of these steps do not completely solve the problem however. A user who knows what they are doing with debug can simply copy cmd.exe to another location and modify it so a prompt is achieved when using it to run a bogus command. So we also have to delete “debug.exe”.
Even then, a savvy programmer can create an executable to get around all of the above security checks. So we need to remove all ability to copy or write to the drive as well. Needless to say we have a pretty useless computer at that point.
Exec Summary
If someone smart has access to your system, it is doubtful you will be able to prevent him or her from getting to the command line. The Group Policy Editor can most certainly make it more difficult, but the tool simply reduces the risk of attack. You cannot completely eliminate the risk without severely hampering the system’s operation and usefulness.
