Windows 2000 Root Kit Analysis

Attack of November 1, 2003


by Tim Jackson



            On November 1, 2003 a Microsoft Windows 2000 Pro machine on the Georgia Tech Honey Net was compromised by an attacker.  The attack originated from eastnet on Georgia Tech's Eastnet .  However, analysis of the data seems to indicate that this host was only a relay for the attack and not the attacker's actual machine.

            The attack first appeared as a standard Nachi attack, but after an initial attempt to compromise the machine revealed to the attacker that the machine had already been infected, he or she switched tactics and used an MSBlaster style exploit to open port 4444 with root privileges, thus indicating by the sophistication and the timing that this was a life attacker not an automated program.  He or she then began setting up a root-kit on the machine.

            The root-kit is made up of two self-extracting .exe files.  This attacker names them c.exe and x.exe.  The former extracts to a directory named "svchost" with a subdirectory "service" while the later extracts to "service" and "spools."  The "svchost" directory contains WinMngr.EXE, ident.bat, one.exe, svc.bat, win.dll, cygwin1.dll, lsass.exe, regsvc.exe services.exe, and svchost.exe.  These form the core of the root-kit.  The subdirectory "svchost\service" is used for storage of warez, but  because the attacker does not want disk usage to be noticed, he or she only places a few files on each compromised machine.  The "service" directory created by x.exe contains mostly duplicate files from the "svchost" directory (possibly to avoid path issues), but it does have one important file in thug.bat. 

            Our attacker extracts these files and directories to "C:\WINNT\system32\Setup."  The attacker then moves into the "svchost" directory and executes svc.bat.  This file is the primary installer of the root-kit.  The svc.bat file sets the user name of the IRC bot in win.dll (which is actually just a plain text file) and starts both the "Remote Registry Backup" service and the "Microsoft Networks" service, but binds both to the attacker's "svchost\lsass.exe" file.  This results in 3 processes called lsass.exe, though only one is legitimate.  The "Remote Registry Backup" service is also bound to "svchost\ident.bat" which executes WinMngr.EXE, while "Microsoft Networks" is also tied to "svchost\regsvc.exe."  The effect of starting all of these files as services is to make them impossible to kill via the Windows(r) Task Manager.  It is necessary to stop the services these files are attached to in order to bring them down.  The next step taken by svc.bat is to hide the directories created by the zip file.  Using the "attrib" command, the bat file runs: "attrib +S +H spools" (aka C:\WINNT\system32\Setup\spools) and "attrib +S +H svchost."  These commands set both the system bit and the hidden bit on the directories causing Windows to hide them unless the bits are unset or someone checks "show hidden files and directories" and unchecks "hide protected operating system files" in the tools->file options->view menu of any Windows Explorer window. 


Figure 1:  Windows Explorer view of system compromise



The fact that svc.bat which came from c.exe hides a directory "spools" that came from x.exe suggests that both files were created by the same person and intended to work together as a single root-kit.

            The other half of this root-kit, x.exe, provides similar tools to the attacker, but with some things added.  "Spools" for instance contains a number of utilities useful for hacking, such as wget, netcat, fport, and fscan.  None of these are called directly by the services that are set up.  This suggests the attacker wants the ability to hack other machines from this one.  While it is possible the attacker just wanted to have certain tools around for setting things up, the deletion of the zip files (presumably just so save space) combined with the small amount of warez stored on the machine seems to negate this as our attacker seems to be interested in saving space so as to not show up on a cursory disk usage analysis.  Given this evidence, and the sophistication of this attack, as well as the number of compromised boxes found (some 25 machines on Georgia Tech's campus alone, including the attacking host) it seems likely that the attacking host was being used a relay and the owner is not our attacker.

            The third directory created by our attacker contains more interesting tools, including one (kill.exe) that is very useful in purging the system of this root-kit.  The first file of importance is thug.bat.  This is where the "Virtual Guide Numbering" service is created and bound to "service\lsass.exe" (which gives us a total of 4 processes named lsass running) and "services\winampa.exe" (which the name of the popular media player Winamp's background executable).  This gives us two more processes running that are attached to services and can't be killed from the Task Manager.   The batch file then hides the "C:\WINNT\system32\service" directory in the same manner as the other two and removes x.exe.

            At some point in running these various programs, one of them creates a number of registry keys.  This is the root-kit's signature and can be found on any machine infected by an unaltered version.  The keys are placed in HKEY_USERS-->S-1-5-21-79052478-1383384898-1202660629-1107(this number may be unique to each install) -->Software-->Microsoft-->Internet Explorer-->Explorer Bars-->{C4EE31F3-4768-11D2-BE5C-00A0C9A83DA1}(again possibly unique to each install)-->FilesNamedMRU.  Each one registers the name of a file the attacker installed but not its full path.  Currently, it seems logical to conclude that the programs themselves both set and read these keys, thus executing all of the files listed if any one of them is started.


Figure 2: registry entry of compromised system


            This root-kit does not appear to cause any actual damage to the attacked system (in fact it patches the system against future attacks on port 135), but instead sets the machine up as a warez server via IRC.  The bot installed connects to and joins the channel #XiSO, where it broadcasts repeatedly the files it has available for download from the svchost\service directory.

            Fortunately, removing this root-kit is not especially difficult after it is understood.  To remove it, simply do the following:


1: Using the Administrative Tools, stop the services that are infected and set them to manual start.  (Be careful if you decide to disable them as doing so can cause headaches if the wrong services are disabled when the system is restarted).


2: Edit the C:\WINNT\system32\Setup\svchost\ file to find the process id (PID) of the IRC daemon.


3: Using the kill.exe found in either "service" or "spools," kill the pid using C:\kill.exe <pid>.  This stops the IRC daemon from running.  Your logs will no longer be flooded with IRC data.  You may also safely kill all WinMngr.EXE, winampa.exe and cmd.exe processes.  You may kill the lsass and svchost processes, but the legitimate versions of these need to be running and may or may not restart properly if killed.


4: Delete, or move the directories the attacker created:





5:  Using regedit, remove all the keys placed by the attacker.


6: If you have not stopped all the attacker's processes, or if you wish to be sure they are all gone, reboot the machine.


7: Upon first booting the machine, ensure that you have only one copy of lsass.exe running, the registry keys are gone, and that none of the illegal services started.  This is your indication that the machine is clean.


            In conclusion, this root-kit displays a fair amount of skill and is not the work of a "script-kiddie."  Analysis of the techniques used, as well as the tools involved, suggest an experienced, though not necessarily a highly-skilled, person conducted the attack.  The root-kit itself suggests that the machine attacking our Honey Net was a relay machine.  The hacking tools present in the kit suggest the intended use for this kit is not just to run an IRC bot, but also to allow remote control of and subsequent hacking using a compromised box.  The techniques used by the attacker make it difficult, though not impossible, to find his or her files.  Once located and understood, the root-kit is easily removed.  However, the complexity of the kit itself and its potential to reinsert parts of itself make it difficult to deal with until it is understood.  Had the attacker removed kill.exe, not used, and used executables instead of batch files the root-kit would have been very difficult to remove indeed.  In short, this was a basic attack, based on someone else's work, that used good tools that could be improved to be very difficult to remove.