Shortcuts: The Illicit Command Prompt

Posted on Posted in Security, Windows

Let me give you a scenario. Begin with net.exe, which is located in %windir%\System32. It’s a fairly powerful command-line utility that can be used to map network drives or shared printers, create fileshares, modify time settings, et cetera. Most notably for this post, however, net can also be used to create user accounts and user groups.

net user john Pa$$w0rd /add /fullname:"John Doe"                                                                       
net localgroup administrators john /add                                                               

These two commands create a user named John and add him to the Administrators group. Since the /domain parameter was not used, all actions are local. The user account is local and the Administrators group is BUILTIN\Administrators, not DOMAIN\Administrators. For this reason, the creation of the new user is nearly undetectable to domain and network administrators unless account management auditing and event forwarding are configured.

Before you close your browser because you think this post doesn’t apply to you since you have Command Prompt and silent batch processing disabled, read on. The topic of discussion here is shortcuts, not your command prompt restrictions, remember.



What if, for the sake of arguement, a user right-clicked, chose New > Shortcut, and created a shortcut pointing to C:\Windows\System32\net.exe? What if they then opened the properties of this shortcut and appended user john Pa$$w0rd /add /fullname:”John Doe” to the target path?


Running this shortcut as administrator would create a new local account, just as running the command at an administrative command prompt would.


Modifying the shortcut target to the parameters of the second command from above would add the user to the local admin group.

Yes, the user would need some way to open the shortcut as an administrator so creating a local admin account may not be the huge exploit you were expecting, but that wasn’t the point. The point being that this new user account has no User Configuration GPOs applied to it and it has much less accountability compared to a managed domain account with proper restrictions, even if auditing is enabled in the machine configuration.

The second part of this is that the user was even able to execute the net command to begin with. Net is only one command of the dozens available. Users should have access to none of them.



The most direct way to deal with this is a Software Restriction GPO. Run down through all the directories specified with the %path% variable and make a note of any commands or utilities that users shouldn’t be privy to and pop these in a software restriction policy for your users. Also, consider any well-known third-party utilities that you want to disallow. I’d start with the SysInternals Suite.

Obviously, this approach is far from perfect since it operates on the premise that administrators know of each and every little tool that users may launch via a “customized” shortcut. With that said, it is certainly a good place to start if a whitelist and blanket-block┬átype of solution isn’t feasible.

Leave a Reply

Your email address will not be published. Required fields are marked *