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
With all the Conficker (over)hype in the news lately, I thought it would be relevant to blog about a few ways to traverse some of the less than reputable parts of the Internet without messing up your computer. In our line of work, visiting sites that end in .ru and .cn are all too common. You all saw Hostel…you know what happens in those places. On with the show.
1) VMWare
Most obvious choice. Our team uses this for incident response at the Firm. Whats nice about this solution is that you don’t have to worry about the same controls that you would a normal computer (AV, firewall, patches). I have gold images of unpatched versions of Windows XP/2003/8 Beta and Ubuntu ready to go. Whether I intentionally or unintentionally infect myself, this becomes irrelevant when I roll back to my original image after I’m done.
2) Sandboxie
I’ll admit it… I am a computer nerd with an embarrassingly slow computer at home (I have only since upgraded it to 768MB of memory). For this reason, VMware isn’t a great option as you’ll effectively be needing the resources of 2 systems. Sandboxie allows you to spawn every application imaginable inside itself and prohibits it from modifying the critical parts of your computer. After you close out, you can back out your changes and everything will be as it was before you started. I use this for Web and Usenet browsing.
3) CCLeaner/SDelete
This doesn’t really go along with theme here, but I do think its of honorable mention. Occasionally you’ll find yourself performing activities online that would make you seem less than honest in a court of law should your computer ever be seized (heres lookin’ at you, RIAA). Although this doesn’t apply to me per se, I am paranoid to the point where I have both of these scheduled to run on a monthly basis. CCLeaner is set to wipe all cookies, browsing histories, and temporary files. Once that is complete, Sdelete has the abililty to scan through all my harddrives and zero out any unallocated space so that any deleted data could not be forensically recovered. Oh yea, and I also have a magnet built into my doorframe to degauss any HD’s that pass underneath…
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.