Mike Howells's Blog

Just another WordPress.com site

Archive for March, 2011

Reading a Remote Registry Key Through Scripting

Posted by Mike Howells on March 19, 2011

I’ve been working a lot lately with SCCM DCM (System Center Configuration Manager Desired Configuration Manager).

If you’ve worked with ConfigMgr you know how powerful the tool is. The DCM portion of ConfigMgr is particularly powerful when scanning collections for compliance against a set of baselines (comprised of configuration items).

The one thing that you quickly realize with either ConfigMgr or DCM is that you need to script a lot of stuff to get what you want. DCM will allow you to use three different scripting frameworks: PowerShell, JScript, or VBScript. For my situation, PowerShell is not an option because the target servers must have PowerShell installed, which is not a guarantee. So, I chose VBScript.

One of the scans we are performing is to check for the existence of a registry key and key value. The registry entry is the following:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf
Value: (Default)=@SYS:DoesNotExist

The above registry key and value is one of those Windows Secrets that prevents AutoRun attacks.

Note: Details of the AutoRun attack and how to prevent it is listed at the end of this article.

Reading the local registry via scripting is relatively straightforward. Using the WshShell object’s RegRead() method you can display the value located in the above registry hive by running the following VBScript.

Set ObjWshObject = WScript.CreateObject(“WScript.Shell”)
strResults = objWshObject.RegRead(“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf”)
WScript.echo strResults

If you’re wondering how to run the above script you can take the above green text and paste it into Notepad (or my favorite Notepad++) and save as RegRead.vbs and then execute it by double-clicking the vbs file.

Note: If this registry hive does not exist when you run the script you will receive an error.

The question now becomes how do you run this script against a remote system to see if this registry value exists? It’s too bad we can’t just wave our magic remote wand and make VBScript magically do this. If only it were that easy…

To get VBScript to work remotely you have to invoke WMI (Windows Management Interface). WMI is a massive topic and way beyond the scope of this article. Suffice it to say it is the magic you will invoke to gain access to remote stuff.

The first problem in trying to execute the above script against a remote system is that we are interrogating the registry for subkeys when we actually want the default value of the key.  The second problem is that WMI’s StdRegProv (WMI interface for remote registry access) is really hard to use.  It is full of all kinds of pitfalls because the results depend upon the type of data found in the registry.  For example, if the default value is not set it only returns a scalar value (single value) as opposed to returning an array (multiple values). Also, you need to determine the value’s data type before you can read that value.  That is to say every value type requires a different method to extract its value. Wow that just turned difficult fast. Microsoft should examine this portion of StdRegProv because it is unreasonably complicated. However, my belief is that Microsoft’s focus is more on PowerShell as a solution as opposed to using VBScript so it is what it is…

In our example, life is a bit easier because we already know that the default value is going to be a string value.

Cobbling all of this extraneous information into a script to gain what we need looks like this:

const HKEY_LOCAL_MACHINE = &H80000002

ExistOrNot = “Key does not exists”

strComputer = “.”

Set objReg=GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” & strComputer & “\root\default:StdRegProv”)

strKeyPath= “SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf”

objReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath, “”, strValue
if instr(strValue, “@SYS:DoesNotExist”) <> 0 then
ExistOrNot = “Key exists”
ExistOrNot = “Key does not exist”
end if
WScript.echo ExistOrNot

Without going into the gory details of the script the magic really happens in the last section when we issue the following function : if instr(strValue,”@SYS:DoesNotExist”) <> 0.

The Function will return the position of the first occurence of @SYS:DoesNotExist within the variable strValue. The Function will return a value of zero if @SYS:DoesNotExist is not found. Therefore, if the value returned is not zero then our key exists as our script shows above.

Scripting is akin to playing an instrument. Just like in anything the more you do it the better you become at it.

One quick trick prevents AutoRun attacks


Microsoft Script Center


Posted in Scripting | 3 Comments »

Using Sysinternals’ Process Monitor to Troubleshoot a Known Unknown

Posted by Mike Howells on March 13, 2011

I was recently tasked to determine why the ASP.NET State Service would not start on a Windows 2003 Terminal Server. All I had to go by was the error message, “Error 5: Access is denied.”

Not a lot to go on...

In addition to the above error message a cryptic Event 532 was being logged in the security log of event viewer.


According to Microsoft the ASP.NET State Service provides support for out-of-process session states for ASP. ASP has a concept of session state. If this service is stopped or disabled, out of process requests will not be processed and subsequently the developers using this Terminal Server for their development work are out of business.

Ok, now what? As Donald Rumsfeld would say, “We also know there are known unknowns; that is to say we know there are some things we do not know….”

Researching either “Error 5: Access is denied” or “Event ID 532” yielded no useful results and in some cases pointed you in completely the wrong direction.

I recently watched Mark Russinovich’s on-line video titled, “Case of the Unexplained 2010,” which is an excellent tutorial on how to use the Sysinternals utility Process Monitor.

Note: Video of this webcast is listed at the end of this article.

So, what better time to put this knowledge to use and find out what is going on underneath the hood by firing-up Process Monitor.

Note: A link to the download for Sysinternals is at the end of this article.

After opening Process Monitor the first thing I did was reduce the noise by including only services.exe. After scrolling through the many results I finally hit paydirt when I saw “ACCESS DENIED” in the results column.

You can run but you can't hide from Process Monitor...

Ok, now we’re getting somewhere…

You can see in the above screenshot that the QueryOpen operation on aspnet_state.exe is successful but as soon as the operating system attempts the CreateFile operation it fails with the access denied error message.

I then opened Windows Explorer and saw that someone did something that they should not have done. A user modified the NTFS file permissions on the aspnet_state.exe file from its default permissions. You can see from the below screenshot that the user not only modified NTFS file permissions but he prevented inheritable permissions from the parent folder.  Not good…

User = FAIL

This was quickly remedied by enabling inheritable permissions from the parent folder.

I then opened Services.msc and I was able to successfully start the ASP.NET State Service.

A mechanic is only as good as the tools he has at his disposal. The Sysinternals Suite is one of those must-have tools in any IT admins toolbox.

Incidentally, I e-mailed Mark Russinovich and he will be including this in his future Case of the Unexplained presentations and in his new Sysinternals book that he is co-authoring.

Sysinternals Suite

Case of the Unexplained 2010 – Mark Russinovich

Mark Russinovich’s Blog

Posted in Sysinternals | 2 Comments »