// >>

So I realize this isn’t exactly security related, but I felt compelled to post since it relates to errors with the Windows Update service. I recently dusted off some old virtual machines which were running Windows Server 2003 and when attempting to update via WU I encountered error 0xC80003FB and 0xC80003FA.  These errors do not quite explain what your potential issues may be and in searching for the answer I came across some posts which actually worked and others which left me scratching my head. If you encounter this error, here are a few things to try:

View the contents of your Windows Update log file to see what it is complaining about. This file is located in %windir%/WindowsUpdate.log. The last few lines will show your most recent attempt at running WU. If you see the following lines:

WSUS server: http://name ofyourinternalWSUSserver
WSUS status server: http://name ofyourinternalWSUSserver
Target group: (name of the group this system was in…may be Unassigned Computers)
Windows Update access disabled: No

Then your system was trying to connect to WSUS. What I found interesting is that I had allowed this system to go out to the internet for updates as part of the WSUS options, yet it failed. Ask yourself if you added this machine to a WSUS installation and then deleted WSUS. I was testing WSUS at some point in the past and had pointed this system to the WSUS server for updates which is not longer part of my test environment. Here are some steps you can try that worked for me:

Stop the Windows Update service by going to Start->Run->service.msc
Backup, then delete, the registry key located at HKLM/SOFTWARE/Policies/windows/windowsUpdate (you’ll notice this has the WSUS server info you may have entered at some point in the past)
Restart the Windows Update service and go Windows Update
If this doesn’t work continue on to the next steps (I have a bad habit of trying many things at once when troubleshooting)

Stop the WU service again. Go to %windir%\SoftwareDistribution and find the DataStore directory. Delete the .edb file and Logs directory from this folder and restart the WU service. Try to connect to WU. If this doesn’t work, you can stop the WU service, rename the Software Distribution folder to something else, restart the WU service and again run Windows Update. This will rebuild that entire directory and should remove any corruption you had in these files that was causing an issue. In the end, a combination of removing the reg key and deleting the database worked to get updates flowing again. Hope this help.

According to a post by the ISC and Skull Security tonight, its possible to scan for Conficker-infected hosts using something as simple as Nmap. All you need is the latest BETA version 5 of Nmap 4.85 and run it with the following flags:

nmap –script=smb-check-vulns –script-args=safe=1 -p445 -d <target>

Source:
http://www.skullsecurity.org/blog/?p=209
http://isc.sans.org/diary.html?storyid=6097

We recently faced the problem of auditing Microsoft patch compliance on systems that do not have File and Print Sharing installed. Most enterprise patch compliance tools, including Shavlik and MBSA, use F/P sharing to connect and query the registry for installed patches. An interesting way to get around this problem is WMI scripting. Using WMI, you can connect to a remote machine, provide alternate credentials, and pull system information, all without having access to F/P sharing.  Additionally, all Windows hosts can natively run WMI scripts so it doesn’t require the installation of any additional libraries or frameworks.

I put together a number of scripts using WMI to pull different types of system information. The first difficulty came in feeding the target computer and credentials to the script.  The following script excerpt prompts the user for the host and authentication information.

‘Get target host and credentials
Wscript.StdOut.Write “Please enter target host:”
strComputer = Wscript.StdIn.ReadLine

Wscript.StdOut.Write “Please enter your user name:”
strUser = Wscript.StdIn.ReadLine

Set objPassword = CreateObject(“ScriptPW.Password”)
Wscript.StdOut.Write “Please enter your password:”
strPassword = objPassword.GetPassword()

The second sticking point was that we needed to use local authentication for the hosts.  As such, we needed a way to dynamically assign the hostname as the domain for the credentials.  Alternatively, if you are using domain credentials, you would simply replace “strComputer” with the domain name.

strDomain = strComputer

After that, it’s just a matter of choosing what values to pull from the registry.  I developed three scripts to pull three different sets of information that I thought would be helpful.

The first script addresses the original reason for the WMI scripts, monitoring patch compliance.  It pulls a list of installed MS patches from the host, including the KB number.  The full script can be found here.

The second script was an extension of patch and vulnerability monitoring and pulls a list of all applications installed on the host, including version numbers.  This information can be useful if a new vulnerability is discovered for a non-MS application that may be installed in your environment and you do not have a robust application patching procedure.  The full script can be found here.

The final script I created was designed to be used for incident response.  It pulls a list of all services on a host, including the service name and full path of the executable.  This provides a quick and free way to pull services from a machine that may be infected.  The full script can be found here.

All of the scripts output the results to a tab-separated text file that incorporates the script name and target hostname into the filename for easy identification.

There are many other applications that WMI scripting can be used for, but I will not cover them all here. If you have any questions or want additional detail or examples, leave a comment.