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

Posted on 2010-08-30
Medium Priority
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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3

Accepted Solution

sstone55423 earned 1000 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 1000 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 \\domain.com\sysvol\domain.com\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

Are your AD admin tools letting you down?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

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

This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
Compliance and data security require steps be taken to prevent unauthorized users from copying data.  Here's one method to prevent data theft via USB drives (and writable optical media).
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses

764 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