Open elevated command window without runas.exe

This post is about how to open up an elevated command window using your admin account if your security team blocked runas.exe. I’m using this to have one starting point running with my admin credentials, which allows me to run all my admin tools like the SCCM Console, TS Monitor, Active Directory, SQL Management Studio etc. without having to enter my admin credentials in each tool. It makes remote access to other clients a lot easier as well. My script will navigate to a specific folder where all my shortcuts and *.lnk files are.

User Account Control

You may know that we are not able to “run as different user” and “run as administrator” at the same time (right click on icon). So, running “as different user” may solve your problem if you need to run a process as another user but this process is not necessarily elevated and therefore lacks the rights to alter your local system. That’s why you would first run an elevated cmd window and then use runas.exe to kick off the process with a different user.

I need to mention that my day-to-day work account is member of the local admin group as well (shame on me). That’s one reason for this strange behavior. The other reason is software and tools that do not request the UAC admin token when started. Using a non-admin user would trigger a login automatically if you start a process elevated. Or running mmc.exe does request the UAC admin token automatically because Microsoft implemented this the right way. In this case you get “run as” and “elevation” at the same time.

Blocking runas.exe

But what if security blocked runas.exe? You may get the following message:

RunAs without runas.exe – Workaround

Luckily there’s PowerShell. The Start-Process cmdlet allows for running processes with the options “Credential” and “Verb”. The command “-Verb RunAs” is used to trigger the elevation prompt. But damn, it won’t allow us to use both parameters at the same time! What a shame! That’s why we need to split up the command in 2 pieces.

The script basically consists of three parts:

1. Create credential object
2. Run a command using the -Verb parameter
3. Run a command using the -Credential parameter

In the end we are running powershell.exe with the credentials of another user which then runs another powershell command with the parameter “-Verb RunAs”, which runs the cmd.exe including a CD command to change directory to our working directory. This code is running in PowerShell which we can trigger from a batch file 🙂

The script

<#
.SYNOPSIS
    This script creates an encrypted password file, and runs an elevated cmd window starting with a custom work dir.
.DESCRIPTION
    This script creates an encrypted password file, and runs an elevated cmd window starting with a custom work dir.
    Be aware that your admin password will be saved to a file in %AppData%. Make sure you are the only one to access that file.
    Start-Process has a bug sometimes: it needs the absolute path to the command AND a WorkingDirectory if you use -Credential.
.PARAMETER User
    Specify the user name to run the elevated cmd window with (must have admin rights of course).
.PARAMETER Domain
    Specify the domain of the user to run the elevated cmd window with.
.PARAMETER WorkDir
    Specify the working directory you want to start with when running the cmd window. If omited the cmd opens in 'c:\windows\system32'.
.EXAMPLE
    Start-ITBElevatedAdminCmd -User 'bill' -Domain 'contoso' -WorkDir 'C:\Work'
    Opens an elevated cmd window running as 'contoso\bill' in C:\Work.
.EXAMPLE
    Start-ITBElevatedAdminCmd -User 'john' -Domain '.' -WorkDir 'C:\Work'
    Opens an elevated cmd window running as local user '.\john' in C:\Work.
.NOTES
    Author:     Fabian Szalatnay
    Customer:   
    Date:       April 18, 2019
    Ver. 1.0:   Initial release
    Update 1.1: Made it dynamic using commandline parameters, added PowerShell header and documentation. Fixed a Start-Process bug
                to allow the use of local users with domain ".".
#>

# Get parameter from CommandLine
param(
    [Parameter(Mandatory=$true)] [string]$User,
    [Parameter(Mandatory=$true)] [string]$Domain,
    [string]$WorkDir
)

# Create Credential file first
if (!(Test-Path "$env:AppData\crazyscrambled_$($Domain)_$($User).txt")) {
    Read-Host -AsSecureString "Please enter your password" | ConvertFrom-SecureString | Out-File "$env:AppData\crazyscrambled_$($Domain)_$($User).txt"
}

# Configure Credential
$CrazyScrambled = Get-Content "$env:AppData\crazyscrambled_$($Domain)_$($User).txt" | ConvertTo-SecureString
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "$Domain\$User",$CrazyScrambled

# Works including working directory!!!
$ArgumentList = "-NoProfile -Command &{Start-Process -FilePath 'cmd.exe' -ArgumentList '/K cd $WorkDir' -Verb RunAs}"
Start-Process -FilePath "$env:windir\System32\WindowsPowerShell\v1.0\powershell.exe" -ArgumentList $ArgumentList -Credential $Credential -WorkingDirectory "C:\"

Save the code as “Start-ITBElevatedAdminCmd.ps1” and run it either in PowerShell or from a batch file.

PowerShell:

.\Start-ITBElevatedAdminCmd -User 'bill' -Domain 'contoso' -WorkDir 'C:\Work'

Batch file:

powershell -Command "&{.\Start-ITBElevatedAdminCmd.ps1 -User 'bill' -Domain 'contoso' -WorkDir 'C:\Work'}"

Please note that the script saves your (encrypted) password to a file in %AppData%, so make sure you are the only one to read that file.