One of the more popular techniques used by malware is to download a "dropper" program containing files, programs and program components attached to it as "data". (This technique seems to be commonly used in order to bypass anti-virus software). The additional programs then installs (or updates) the spyware, and perform all sorts of modifications to the users' browsing environment, including, but not limited to: adding extra (sometimes offensive) bookmarks and "favorites", adding "toolbars", installing hidden software (which can perform information gathering or keylogging) , changing (hijacking) the default home and search pages, and downloading other file droppers (of course, we can't forget the extra "helpful" popups). These other file droppers then repeat the process, downloading DLLs, cab files, executables, BHOs, etc. In one well documented example (Parts I, II,III and IV), visiting a single website -- without downloading anything -- with an unpatched machine resulted in more than more than 20 files being downloaded and installed (with further analysis still to be published!).
Unfortunately, I have noticed that a user does not call their Help Desk when their machine is in the early stages of a malware infection, since a single malware infection may cause extra popups and slow a machine down but the machine will still be usable. Users may only contact Help Desk after initial malware infection loads additional spyware, adware, and hijackers, until major slowdowns or instability have occurred.
It also seems that some users are afraid to call their help desk, until their machine contains so much malware that it becomes completely unusable, because of the fear that they will be blamed for downloading an application or for visiting a web site they shouldn't have.
Therefore, PC Support doesn't typically get their hands on a machine until the spyware "gestation period" has passed, and other "opportunistic" malwares have been downloaded via the dropper programs. By then, the machine has likely been infected with more than one spyware application -- complete with dozens of new registry entries, hidden and randomly named background processes, and multiple startup entries.
Since it can take several hours to fully clean an infected machine, or to reimage the machine and copy the user's files, a Tech Support staff can quickly get overwhelmed, especially with staffing ratios of 75:1 (or worse). Webroot recently conducted an analysis of the presence of spyware within corporate networks. They found that 2.5 percent of corporate PCs had some sort of adware installed, with each infected computer having an average of 20 adware "pieces". Over five percent of computers had a Trojan Horse installed (Source: webroot). This average is less than the astonishing infection rates of home PCs, perhaps due to better browsing habits and security measures. A survey by the same company found that less than 10 percent of responding corporations believe they have deployed an enterprise-class anti-spyware solution.
It is therefore important to be proactively detect (and if possible, prevent) either the initial malware download, or the subsequent downloads via the "dropper" programs, and limit it to as few machines as possible.
However, even under the best case scenario, with users exercising extreme caution and desktop patching being up-to-date, there is still a time period after an exploit has been discovered and the patch being released, downloaded, and installed. In addition, some corporate software will not run unless the user has been configured as a "power user" or, gasp, an administrator. Therefore, even with extensive user education, secure browser settings, and user profile lockdown, machines will still get infected with spyware and adware. Users and desktops in the "higher risk" category will simply get infected first, and more often.
By proactively monitoring and scanning the network, installed malware may be detected early in the infection cycle. Steps can then be taken to prevent these machines from becoming completely infested with malware "crud". In addition, steps can also be taken to prevent other machines from becoming infected as well. The "high risk" machines may even act as an "early warning system" for the detection of malware.
One of the more common methods used by spyware is to launch themselves upon system startup by adding themselves to the startup registry entries. Another very popular methods used by spyware is to integrate itself with Internet Explorer via a Browser Helper Object (BHO). The next section briefly describes the concept of a BHO, and how spyware exploits the ability of a BHO to customize Internet.
HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/Browser Helper Objects
registry hive and loads all the objects whose CLSID is stored there upon Browser
(or new Browser Window) launch. Many BHOs were created for legitimate purposes and
add extra functionality to Internet Explorer, such as filling in forms automatically or
adding a search bar. BHOs can perform any action on the available windows and modules, detect events, create windows to display additional information on a viewed page, and monitor messages and actions. According to Computer Associates , Microsoft calls BHOs "a spy we send to infiltrate the browser's land." Unfortunately, BHOs are also used by spyware and adware: to monitor and track internet usage, or to serve unwanted advertising and popups. Some exploits of this technology search all pages viewed within IE and replace banner advertisements with other ads (Sources: Computer Associates, PestPatrol ).
A CLSID is a unique identification tag that's associated with a BHO (and other objects). This article explains how to build a BHO with a unique CLSID). Therefore, one way to detect malware is by the presence of an unauthorized BHO.
Some of the popular anti-spyware and anti-malware tools maintain databases of CLSIDs, BHOs, and startup items associated with malware. However, some malwares attempt to hide their existence by changing their product just enough to avoid detection until the next version of the detection software comes out. This includes using random file names and random CLSIDs.
One of the most complete and comprehensive databases of CLSIDs, from CastleCops, does not add the CLSIDs of these BHOs to their master list, because "the number of possible names and combinations could therefore literally run into the billions" (http://castlecops.com/postt7736.html, http://computercops.biz/print-1-7736.html.
How does one identify these randomly-named CLSIDs? How do we detect a malware infection if the same spyware will have totally different CLSIDs on two different machines?
As mentioned previously, an ability to proactively monitor or scan a network for spyware would aid in the fight by detecting an infection as early as possible. Countermeasures can then be taken to prevent other users from getting infected. The scanning, monitoring, and reporting needs to be performed in a centralized manner, without the need to visit individual desktops. However, unlike antivirus solutions, there are very few anti-spyware scanner products which provide centralized administration and management.
One of the more interesting network-based malware detection techniques utilizes snort to detect malware. (Snort is a network-based Intrusion Detection System (IDS) which scans and alerts on suspicious traffic patterns.) This involves loading up snort signatures which match traffic patterns of known spyware, adware, and malware. Many of these signatures have been conveniently aggregated into "bleeding malware" rules located on the Bleeding Snort web site. I have detected many malware-infected computers by having snort (with the bleeding-malware rules) "listen" (monitor) to network traffic and alert on a match with the "Bleeding Malware" rules.
When Matt Jonkman announced a partnership between Nessus and Bleeding Snort, I became immediately interested, because I did not know of any free/GPL/open source remote malware scanners. (A partial list of commercial network-based "enterprise" malware scanners is located in the Appendix.)
Since, as mentioned earlier, there are so many possible combinations of CLSIDs, my preference was to keep a list of "approved" BHOs, scan each machine, and flag those which were not on the "approved" list.
While I was researching (on my own time) how to program such a Nessus plugin, I noticed references to "TieRegistry" and downloaded a script called SrvCpuMem.pl which opens a remote registry and reports the CPU and memory size for each server in a domain. (The original script is located at http://www.roth.net/perl/scripts/scripts.asp?SrvCpuMem.pl and I wish to thank Paul Popour and Roth Consulting for releasing their scripts into the public domain.
This script was extensively rewritten to report on remote BHOs instead of CPU and memory information for remote desktops. I also provided an option to use a "bhoignore" file which would ignore those "approved" BHOs (who wants to see a list of Acrobat Reader BHO's on every machine?). (Note: Use of the bhoignore file seems to cause problems in some environments.) There is also an option to only report on BHO's considered malware by the CastleCops BHOList. (We wish to thank CastleCops for publishing this list and giving us permission to use it. ) I also added code to flag "unknown" CLSIDs, which are not on the CastleCops list, because those would likely be malware using random CLSIDs.
The program scans the remote registries of all machines in a Windows domain, so the host computer must be a member of the domain and have rights to read the registry of the remote machine. The program outputs reports in simple html format as well as a tab-delimited file for import into a spreadsheet.
It has been tested on W2K server as well as an AD domain but should be considered late alpha to early beta software. It is free software and can be redistributed or modified it under the terms of version 2 of the GNU General Public License with only minor modifications (the full license can be found in the download page).
There are many TODOs, such as adding extra scanning functionality to scan by ip address or specific host name. Other registry entries, such as Startup Entries, Toolbars, remote host files, etc. need to be added. I am also looking for volunteers to help test the program as well as extend the code.
Please remember this is not a malware removal tool. This program scans remote nodes in a network for BHOs, which is one of the tell-tale signs of a malware infection.
I have not installed any commercial network-based malware appliances or malware scanners. (Several are
listed in the Appendix.). Since employing a single technique against spyware is simply not enough, the following
techniques can be used in addition to the purchase of any commercial package.
Partial list of "enterprise" Enterprise Anti-Malware Tools (some are client-server based, some are appliances):