Scripting with Encrypted Passwords

The Dilemma

Please note: This page was written back in 2005 and I rarely have to pass credentials in a script. Most of it is outdated and is only intended to serve as a reference.

At some point, security-conscious run into the dilemma of needing to include a password in their script but not knowing how to hide this password so that anyone with read access to the script cannot get the username and corresponding password. This happens every now and then with systems administrators who want to create logon scripts or software packages that need to install and/or run with different credentials than those used by the user running the script.

There are a variety of ways to attack this problem. If you have a centralized point from which to run the script, you can us NTFS permissions. However, the solutions I find myself needing have to be portable; that is, they need to be part of the script itself, and work no matter who I give them to or where they are run. To this end, I have found three solutions:

Core Solutions

AutoIT: AutoIT is a scripting language (similar to VBScript) that also allows mouse, mouse button, and keyboard interaction with various windows. Additionally, it has the ability to compile the script into an EXE, and can even include other files upon which your script depends. This EXE is compressed and encrypted. Thus, you can write your plain-text script, test it completely on a system on which AutoIT is installed, then compile the script into an encrypted EXE, which can then be deployed to any system, regardless of whether or not it has AutoIT. This is especially useful when you just want to "wrap" an existing DOS command in AutoIT, as show below:
```
Run ("sc config sysmonlog obj= DOMAIN\svc-perfmon password= 123password start= demand","",@SW_HIDE)
```
The above line would configure the Performance Log service to use a domain accont "svc-perfmon" with a password of "123password". This is useful for performing remote perfmons. By compiling this script into an encrypted EXE, the user could perform the modification without ever knowing the username or password being used. Of course, the user might not have the rights to make this change, and you could always use the RunAsSet function within AutoIT to run the whole command under administrative context. Another example is listed below:
```
FileInstall (".\notemp.bat", "%TEMP%\notemp.bat", 1)
RunAsSet ("Administrator", "DOMAIN", "password", 0)
RunWait ("%TEMP%\notemp.bat","",@SW_HIDE)
RunAsSet ()
FileDelete ("%TEMP%\notemp.bat")
```
The one downside to AutoIT is that the compiled EXE must include extra code necessary to run the script on a system without AutoIT, which means a simple 500 byte script turns into a 121 kilobyte EXE.
Encrypted VBS: Use one of several products to encrypt your VBS code. Different vendors offer different levels of encyption. Microsoft has a free VBS Encoder program that is really just an obfuscator. Use of this method prevents casual access to the contents, but is not in any way secure. In fact, there is a public page here that decodes it.
To run a program with administrative rights regardless of who launches the process (e.g., REGEDIT.EXE), you can use the commandline like so:
```
runas /noprofile /user:Administrator regedit.exe
```
To automate the password entry, you can use SANUR.EXE:
```
runas /noprofile /user:Administrator regedit.exe |sanur password
```
A VBS script wrapper would look like so:
```
Dim WshShell
Set ws = CreateObject("WScript.Shell")
ws.Run("runas /noprofile /user:Administrator regedit.exe|sanur password")
Set ws = nothing
```
Encryption Utilities: Several utilities offer the ability to launch applications under a different user's context and encrypt the password at the same time.
- CPAU: Useful but does not allow the /noprofile flag.
- LSRunasE and Supercrypt: Both have been deprecated.
- ShellRunas: A SysInternals utility - I recommend them all.

Additional Options & Considerations

Non-encryption Utilities: Converting scripts to EXEs or COMs can obfuscate content. New BAT to EXE converters like the one from f2ko may be useful.

Compression Tools: Utilities like WinZip or PowerArchiver can create self-extracting EXEs. However, if the script is extracted to a temp directory, the password can be exposed if not cleaned up properly.

IExpress: Included with Windows XP and later. Deprecated.

SMS Installer: Creates an EXE that can install, execute with parameters (including passwords), and then delete the script.

PLEASE NOTE: Packaging utilities may, or may not, pass on error codes from the original script (e.g., IExpress and 7-Zip SFX).