Tutorials | A brief history of Malware Detection
In the summer of 1999, a strange message started appearing when some computer users tried to open files with an EXE extension:
"Cannot find [Msrexe/Mueexe/Windos/Win32].exe. This program is needed for opening files of type: Application"
Soon, computer help boards were being swamped by users whose systems were rendered unusable because EXE files could not be opened.
The cause was a new generation of the SubSeven trojan, a more versatile and malicious development of the remote access trojan, NetBus. In its earlier versions, the SubSeven file was activated by appending the file name to the Load= or Run= lines in Win.ini, the Shell=Explorer.exe line in System.ini or writing its startup call to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun key in the main body of the Windows registry. This was very difficult for the average user to detect, and most were unaware that their computer and the information stored on it could easily be accessed by outsiders, or that a network of infected systems could be utilised for nefarious purposes, such as Distributed Denial of Service attacks against specific sites.
Ironically, the most versatile development of SubSeven - version 2.1, also known as Gold or SubStealth - was the catalyst for the development of malware detections methods simply because it tried a new kind of trojan activation - the insertion of the trojan file name in the .EXE file type handler: HKEY_CLASSES_ROOTexefileshellopencommand. The reason for that was that even if the other registry startup locations were detected and deleted, the trojan file would be activated by opening any file with an EXE extension. At around this time, antivirus programs were beginning to include SubSeven and other trojan patterns in their heuristic technology, so the trojan file name and location became evident when an antivirus program deleted the trojan file itself. As that file name was part of the path to open EXE files, the 'Cannot find...' message appeared when attempting to open any EXE file while the trojan file was missing. Later developments of SubSeven 2.1 allowed random trojan file names to be generated. However, the author of SubSeven, MobMan, and the SubSeven developers had effectively shot themselves in the foot by trying to be too clever with the 'sneaky' startup.
EXE-Fix programs were compiled to restore the registry defaults. By far the most comprehensive of these fixes was EXEFix08, written by a DOS programmer who went by the name of rmbox. EXEFix08 quickly became the standard fix for this infection - it allowed the registry defaults for all registry file extension handlers to be restored (in addition, correctly anticipating the release of other 'sneaky' malware activation methods that used the defaults for other file types such as BAT, COM and JPG. For example, the Blebla worm corrupted 22 file extension handlers, including DOC, XLS and ZIP). For the fix to work, all that needed to be done was to run EXEFix08, then locate and delete the trojan file.
While EXEFix08 solved the immediate problem, SubSeven was just the beginning of the avalanche to come. More and more areas of the arcane Windows registry were identified by malware writers for more and more esoteric startup locations. There was a need for a DOS-based program for Windows 95/98/ME that could enumerate all the known program startup locations of the Windows registry and write them to a text file, enabling helpers to identify where the malware program(s) were being called from. Having finished the development of EXEFix08 (we tested eight versions from v.01 onwards before the final v.08 was released in early 2000), rmbox wrote the first version of StartUp Log for Win 9.x/ME and I continued with the testing and development of the new program.
This was the birth of malware detection as we know it today. StartUp Log was finally made available to the public in the summer of 2000 after further testing and improvements based on input from others (WhitPhil and Rollin' Rog) who confirmed it worked on Windows 98 as it did on Windows 95. While StartUp Log was in development, rmbox released two tiny programs - Edit-SI and Edit-WI - to simplify the process of dealing with trojan startups in both System.ini and Win.ini.
SubSeven was still the king of the trojans at the time, although Bymer, Qaz, PrettyPark and others were widespread. They all had one thing in common: they wrote their startup calls to the registry (which includes system.ini and win.ini), sometimes very aggressively with multiple startup locations.
Now that malware startups could be enumerated to a text file, helpers had a very powerful tool with which to identify not only the malware involved, but also the various startup locations it was loading from. EXEFix08 could fix the 'signature' (file extension handler) trojans, System.ini and Win.ini could be easily edited with rmbox's tools, but the registry startup calls had to be fixed manually using Windows native Regedit.exe (or a custom REG file).
Malware programmers continued to find and use little-known and little-understood areas of the registry where they could write their malware startup calls to. Startup Log was continually developed during 2000/01 and rmbox also released DOS-Delete for files that were reported as being in use by Windows. DOS-Delete, some would say the predecessor to Option^Explicit's KillBox, ingeniously used a NUL= statement in Wininit.ini to delete the rogue file at reboot as Wininit.ini kicks in very early in the boot process.
June 2000 saw the birth of automated spyware removal with the release of OptOut by Steve Gibson of Gibson Research (grc.com). OptOut was limited in the sense that it only targeted Aureate/Radiate and Conducent Timesink. However, shortly afterwards the first version of Lavasoft's AdAware was released, targeting a wider scope of adware and spyware and incorporating a larger database of known malware. Some time later, Patrick Kolla released Spybot Search & Destroy to add to the helpers' arsenal. With manual and automated detection, these were the 'salad days' for helpers - they knew what they were dealing with, and could easily identify and get rid of new malware almost as soon as it appeared, something the antivirus companies were either unable or unwilling to deal with. The helpers were winning the battle...but not the war as it would turn out.
The introduction of Windows XP in late 2001 was a turning point for all concerned. Arguably, it was the most insecure operating system that Microsoft had ever released. One security expert, on first using XP. likened it to a monolithic trojan such was its ability to attract malware.
StartUp Log, which had been instrumental in helping clean so many Windows DOS-based systems, was rendered ineffective by XP's DOS emulation, and its tortuous and sometimes user-defined paths. The desktop, for example was, no longer located at %SystemRoot%WindowsDesktop, but %SystemRoot%Documents & Settings"User Name"Desktop. Services were introduced, adding further complexity for the home user, as well as myriad opportunities for malware writers.
But XP's DOS emulation was not what many had feared. In fact, some of the commands had been enhanced with extra switches. This would prove to be very useful for future DOS-based detection programs such as FindNFix and FindIt.
It only takes a few vulnerabilities in the software of an operating system or browser for attacks on it to be successful, and the first release of XP had many 'holes' that could be exploited. Attackers are opportunistic, take the easiest and most convenient route, and exploit the best-known flaws with the most effective and widely available attack tools. They count on organizations not fixing the problems, and they often attack indiscriminately, scanning the Internet for any vulnerable systems. The easy and rapid spread of the Code Red and NIMDA worms in 2001 can be traced to exploitation of unpatched vulnerabilities.
It's hard to believe now that it took the best part of a year before there was an alternative to StartUp Log - especially since all that needed to be done was to rewrite StartUp Log's DOS code in Visual Basic! During this time, helpers had to deal with adware, spyware, worm and trojan infections on XP systems just from Msinfo32 logs. Fixes were made using direct registry editing and on-the-fly REG and BAT files. We were struggling. There was no way of knowing what exactly was loading from where, and the malware writers were finding more 'holes' that could be exploited. The 'salad days' were over. This was the point where we were no longer dealing with script kiddies writing the likes of LoveBug for 'fun' - there was a malicious, even criminal intent on the part of a new breed of coders who were now in it for the money.
[As an aside, the first piece of spyware as we know it was released in mid-1998. It was a toolbar called Dashbar, and its founder and Executive Vice President of Client Services was Joshua A. Abram. After Dash folded, he went to work for Direct-Revenue.com and is listed as the co-owner of none other than VX2.org, abetterinternet.com and Stop-popup-ads-now.com, among others.]
In September of 2002, Merijn Bellekom, a member at Spywareinfo, came up with the first version of StartupList that essentially acted the same as StartUp Log, but with running processes and extra startup locations enumerated, as well as verification of the location of Explorer.exe. It worked in Windows 2000 and XP! The 'dark ages' were over and a new era of malware detection began.
The only esoteric registry startup location that StartUp Log listed was StubPath (Active Setup). StartupList gave us much more. It was highly versatile as well, to the extent that Merijn was able to release improved versions within hours of receiving feedback from helpers.
A development of StartupList was released shortly afterwards - HijackThis. What differentiated HijackThis from StartupList was the fact that it was not just a text file generator - it was in fact a registry interface. No more direct registry editing - helpers had enumeration of baddies and a fix in just a few clicks! Not many helpers realised the awesome capability that HJT had; we felt comfortable with what we were used to. But HijackThis quickly became the standard for malware identification and removal, and it continues to be the standard to this day.
Copyright Edmond Joyce (HKEd) 2005
This document or any part of it may not be used without the author's permission.
Please Note: if you have any questions about this tutorial please ask on our support forums
If you have written a tutorial of your own and would like to have it here on Cyber Tech Help all you have to do is Submit your tutorial and it will be reviewed by the Administrator.