WSH, RUNAS, Automation, etc…

Okay… So, I’ve been working on getting an automation script to work that runs a dos command as another user (namely Administrator) without requiring user interaction. So the RUNAS command is a good choice for a start.

One way to accomplish this is to download the program SANUR (runas backwords) and place it into your %PATH% and then use the command:

runas /user:CompOrDomainAdministrator Command to run | sanur password

That sanur command sends the password provided (could also place the password in a file so it is not immediately noticed) but this requires that you place SANUR into the %PATH% on all computers that will run the script, so lets try another way that also can help hide the password.

Here comes WSH scripting to the rescue. We can look at the Run, AppActivate, and SendKeys methods of the WScript.Shell object and use them to run the command, activate it, and then send the password to it.

First is the Run method. I would much rather use the newer Exec method, but for some reason, it does not seem to work with dos commands like runas and the like. Using Exec when possible would allow the AppActivate to be a little bit simpler by storing the WshShellExec object as a variable and look at the ProcessID property instead of the window title. But since it does not work quite the way we want, we use Run. The easiest way to do the run is (in JScript, I’ll add the VBS code in our final product):

var WshShell = WScript.CreateObject("WScript.Shell");
WshShell.Run("%comspec% /C runas /user:CompOrDomainadministrator CommandToRun");

That will create the WScript.Shell object and then use the Run method to run the runas command we spoke of earlier.

Now we have a window open running the specified command… now what? What if someone clicks away from it? That’s where the AppActivate method comes in.

WshShell.AppActivate("title of window" or ProcessID)

Okay, so we can use the title of the window we want to activate, or it’s PID. How do we get that? And if there’s more than one window with the same title, then what?

What I came up with was using the dos command TITLE to change the title of the running window and name it “Window” followed by a random number between 1 and 100000, so the chances of having two windows with the same name are very much minimized. But that chance does exist, which is why the WshShellExec.ProcessID method would be much better because a process ID can only point to one process. But this way gives us a better way than looking for “runas blahblahblah”. So here’s what we have so far:

var WshShell = WScript.CreateObject("WScript.Shell");
var strTitle = "Window " + (Math.round(Math.random()*100000) + 1);
WshShell.Run("%comspec% /C title " + strTitle + " & runas /user:CompOrDomainadministrator CommandToRun");

Note the WScript.Sleep(1000); That ensures that there’s enough time for the title and runas commands to start running. So now this works to open the command and activate the command’s window. Now it’s asking for the password (assuming you have one). Now lets plug it in with a call to the SendKeys method. SendKeys sends the string of keys to the currently activated window like the following:


Notice the tilde (~) at the end. That is SendKeys‘ quick character to send an enter keypress or carriage return character. So now, we should have our completed code now. The following is the WSF file that contains the VBS and JScript versions of the same code:


Set objShell = CreateObject(“WScript.Shell”)
strTitle = “Window ” & Int(Rnd * 100000 + 1)
objShell.Run(“%comspec% /c title ” & strTitle & ” & runas /user:CompOrDomainadministrator CommandToRun”)
WScript.Sleep 1000
objShell.AppActivate strTitle
objShell.SendKeys “ThisIsAPassword~”

var WshShell = WScript.CreateObject(“WScript.Shell”);
var strTitle = “Window ” + (Math.round(Math.random()*100000) + 1);
WshShell.Run(“%comspec% /C title ” + strTitle + ” & runas /user:CompOrDomainadministrator CommandToRun”);


So there you have it. It will also work for windows programs as well.

But how about security? You definitely could just look at the script source and get the password, so there are two ways off hand to help secure the password. One way is to make sure the permissions on the file does not allow anybody other than those who would be using the script to read it. Or you can encrypt the script using Microsoft Script Encoder. But know that having it encrypted with that does not make it 100% secure. There is a VBS script out there that allows you to just drop any VBE or JSE file onto it, and it spits it all out in plaintext. So my recommendation is to use both security methods I mentioned.

Well, that’s all! I hope you all have fun with this information!