How secure are Logon Script parameters passed to a script in Active Directory?

Posted on 2010-08-30
Last Modified: 2012-06-27
Hi all, I'm hoping someone with some intricate knowledge of Activity Directory could provide some advice.  My knowledge of it doesn't really extend to the security side of things.  I write VBScripts quite regularly to perform tasks at Logon.  Sometimes I have certain passwords in the script, for database connections, or limited install privileges, etc.  I have used the Microsoft Script Encoder to obfuscate these in the past, but I know that the obfuscated code can be reversed relatively easily by anyone determined enough.  I have also used tools to convert the VBS to an EXE, which seems to be the best current solution for me.  When I trace the EXE with process explorer, I cannot see any hint of the raw VBS, so I'm happy with that (although I don't know for certain this EXE cannot be decompiled by anything).

My question is, if in my script I were to use
strPassword = WScript.Arguments.Item(0)

to obtain the password from the Parameters section of a Logon Script assigned by Group Policy, it is secure enough that it can't be "sniffed out" very easily?  I understand that it would be passed in plain text, but the password is not directly exposed to any user.

Any advice would be appreciated.


Question by:RobSampson
  • 3

Accepted Solution

sstone55423 earned 250 total points
ID: 33563924
It seems to me that the password is not embedded in the VBscript or EXE file, but is placed in strPassword during run time (at login).  As such it is exposed only within memory within the server/DC that it is running on when the process is running.
For someone to see the "cleartext" password, they would have to be examining memory of a system process while it is running.  Since memory for a process is protected, the other process examining memory would need to have administrative rights to other memory.
I view this as a minimal security risk.
Consider that if you had the password stored in encryped form, then it would be exposed equally during the process of decryption and passing the parameter to the database connection string.  The only way that this can be avoided is for the database itself to  authenticate using kerberos, or some other method where the encrypted password is never decrypted in memory.
LVL 65

Author Comment

ID: 33564148
Right....that makes sense....thanks for the clarification....

The password definately wouldn't (or certainly shouldn't) be embedded into the script, because it is accepting it as a parameter.  Given that one might somehow have access to write to the script, they could simply use
WScript.Echo strPassword
to obtain it, but that's easily overcome by locking down NTFS restrictions (which is default in the NetLogon share anyway).

Just one more question along the lines of what you have mentioned...

Seeing as the process for the script itself (when executed) would be running in the context of the user logging on, would they be able to read that memory space? Or is this still locked down to SYSTEM rights?

Thanks for your input,


Assisted Solution

firemanf29 earned 250 total points
ID: 33564181
First,  make sure the VBSTOEXE converter you're using does not write the script to the temp or another directory on execution.  Most of them do.  Assuming a hacker grabs the file from the temp directory and decodes it.  Then determines that the script is being passed a password during execution.  Then finds the GP that's executing the script.  Assuming all that they should be able to read the password from the GP object.  Chances are very slim that it would happen but their is a small chance.  If it's running as the user then they would be able to read that memory space.
LVL 65

Author Comment

ID: 33564338
Yeah, I did start with one tool that simply appeared to wrap the VBS in some compiled code, and on execution, would dump the VBS to a temp folder, and run it....obviously no good.  The tool I am now using though, does not show any trace of the script engine or a vbs file through ProcMon and Process Explorer, so I'm happy with that.

@firemanf29, >> Assuming all that they should be able to read the password from the GP object.

How is that possible?  The \\\sysvol\\Policies folder is locked down, as is the HKLM policies tree....

Overall though, the comments you guys have posted give me a fair assurance that this is a safe way to go.  The alternatives certianly don't seem to stack up to that:
  - The CPAU encoding seems to be the next best option I can find, by encoding a batch job, which I could run
  - PSExec offers no security via encryption
  - I could use MS Encryption, but the decryption requires a "secret" word, which when placed in a VBS file as plain text is hardly "secret"

It also seems a far more simple, and far more centralised way to pass such a parameter....and I'm not too worried about the ability of anyone to run a memory "sniffer".

I'll leave this open for a day or two just in case we can pull more heads together.

Thanks guys, appreciate it.


LVL 65

Author Closing Comment

ID: 33582927
 Thanks guys for your clarification.

Featured Post

Gigs: Get Your Project Delivered by an Expert

Select from freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely and get projects done right.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Learn about cloud computing and its benefits for small business owners.
While rebooting windows server 2003 server , it's showing "active directory rebuilding indices please wait" at startup. It took a little while for this process to complete and once we logged on not all the services were started so another reboot is …
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

805 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question