The Case of the Intelligent Spambot

This is the second case study that was sent to Mark Russinovich, Microsoft, which earned me signed a copy of the 5th Edition of Windows Internals.

I woke up last Sunday to my friend’s unforgivable rumblings about the Internet Speed sitting at the lone desktop in our room. I quickly ducked my head under the covers, what would I expect from a 128 Kb line, 13 or maybe 14 Kbps transfer speed? I tried to convince him half sleepily that it was natural, but when he said he had been downloading a 642 KB Word Document for the past 15 minutes, I had to sit up in bed. We never had a speed issue with the ISP, was hoping this was a first.

I quickly opened the Windows Task Manager, expecting to see any unheard process trying to steal my bandwidth. The processes didn’t look funny, at least not all of them, because I hardly have 15 different processes running on my system. But two things stood out. There were an unexpected number of svchost.exe running and a process called rs32net.exe. I quickly fired up Process Explorer for a more detailed look and to see what new services were being run. The Process Monitor’s Image tab of the Properties for rs32net.exe quickly confirmed my suspicions about its intentions.

I had seen files like these before. Although I wasn’t sure what was eating my bandwidth yet. I fired up the prompt and type netstat –a. I almost fainted at the speed at which the screen went by. My computer was trying to connect to the smtp ports of several systems online! I was taken aback at my systems betrayal. Here’s a snipped output from netstat.

I needed professional help. I quickly fired up TCPView from Sysinternals. Looking at the hundreds of connections being requested did not hurt as much as knowing which processes were responsible.

I had to finally agree that my system was infected by a spambot. Anybody else would have been terrified, I was excited. This was the first time that I had come face to face (well not literally) with a spambot. I still couldn’t figure out how rs32net.exe fit into the picture. So I simply killed it to take a look at it later. The spambot was connecting first to multiple http servers, presumably to download a list of addresses to which it had to attempt connection. It then proceeded to connect to the several computers that were visible in the list in TCPView.

I first checked the strings in memory for one of the svchost and saved them for later analysis. The strings that I saw were definitely not part of svchost.

Since svchost was involved, I opened up the Management Console and checked what services where running on my system. Two services looked out of place, without any descriptions, and set to automatic yet not started.

I had never heard of them before, decided to take a look at their properties to determine what executable it was. Was surprised to see a colon in the filename of the executable. I immediately realised what it was. I honestly had not expected an NTFS Alternate Data Stream SpamBot to affect my system.

The ext.exe that comes after the svchost is an NTFS ADS or Alternate Data Stream. To access an ADS you have to specify the “host” file followed by a colon and the filename of the ADS. By default all files on an NTFS partition have an ADS, the data in the file itself is stored as an ADS without any name as filename::$DATA

That was interesting enough to wet my appetite to go on. I took a quick morning break, freshened up myself and sat back at the desk to continue my investigation. So I now knew the exact file that was causing the issue. I wanted to extract the ADS and store it in the collection of malware that I have on my computer. I used Streams from Sysinternals to view the ADS size. Streams provides you an option to delete the ADS but I wanted to extract it.

That is when I had to use a GUI tool that I had written long long ago, called NTStream for a software competition when I was still in college. I ran NTStream, just to be safer, on the whole Windows Directory. NTStream scanned 2318 directories and 26802 files in under a minute and displayed the search result in its ListView Interface.

I extracted the stream for later research and then deleted it and the FCI and the ICF services entry from the Windows Registry under the HKLM\System\CurrentControlSet\Services\FCI and HKLM\System\CurrentControlSet\Services\ICF respectively. I then deleted rs32net from the System32 directory, just in case, and then proceeded to enable my Network Connection that I had disabled to prevent the ISP calling up or disconnecting me forever from the online world for using my system to spam.

As soon as I enabled the Internet Connection, the flurry of Network Activity was reported again by TCPView. Damn! This was definitely the sign of an executable in memory or some driver or dll that was still doing what it was supposed to do, spam.

I fired up Procmon to view disk activity just in case to see if svchost was acting funny elsewhere on the hard drive. Never before in my life was I greeted with this by Procmon.

I was sure I was an Administrator on my system. Very sure about it. I checked just in case wondering whether I was downgraded to a limited user by a hitherto unknown power. The command net user %username% at a command prompt told me I was very well an Administrator and a member of the Debuggers Group. I ran Procmon again and viewed its properties in Process Explorer to make sure I had the SeLoadDriverPrivelege enabled. I very well had.

This was weird. The only hope I now had was Sysinternals’ RootKit Revealer. I quickly pulled it out of my toolkit and ran it scanning in default mode. I was hoping it would return something more concrete.

The scan revealed several discrepancies, but what caught my attention was the lone result from the file system right at the bottom of the 3576 entries. Now the only way to access the file, that I thought of was to boot from an alternate medium and check. But luckily I had installed a copy of the Recovery Console on my system. I restarted the computer in Recovery Console, navigated to the C:\Windows\System32\Drivers directory and issued a dir tj* command. I was delighted to see the file there. Although I had not exactly figured out the role of the TJTXSGTX.SYS driver in this whole case, I was nevertheless delighted to see that the file was at least visible under the recovery console. I promptly deleted the file and restarted the computer normally. I then enabled my Internet Connection and waited with bated breath for the sequence to start again. After 5 minutes of suspense, when nothing happened, I decided to close the case after running an sfc /scannow.

PS: By the way, my friend installed a popular antivirus and managed to clean other infections later in the evening. He claimed it took him little over 30 minutes, unlike me. I appreciate his humor.

The Case of the Persistent Executable

This is the first of the 2 case studies which won me a signed copy of Windows Internals, 4th Edition, by Mark Russinovich, Microsoft last year.

I woke up last Saturday around 11:00 in the morning to find my friend sitting at the computer typing some document in MSWord, he then minimized the document and proceeded to open the D: drive from My Computer. My usually fast Windows responded extremely slowly to the double click. I sat bolt upright in my bed and asked him to repeat the procedure with the other drives. The same delay was noticed on the other drives too. I then asked him to right click on any drive expecting a change in the context menu due to the presence of an autorun file. The menu was intact. I then got down and sat at the chair and used the attrib command at the prompt for each drive. This is what I got.

Certainly signs of malicious presence. I used the type command to read the contents of autorun.inf although I knew what it would point at.

I then immediately fired Process Explorer to see if the process was running. Failing to find the process or a handle to it, I then used the attrib –s –h –r fppg1.exe to reset attributes and proceeded to delete it using del fppg1.exe. I repeated the same procedure with the autorun.inf file. Since I have 6 partitions on my hard drive, I wrote a bat file, named it clean.bat and saved it in %systemroot% with the following contents.

@echo off
attrib -s -h -r fppg1.exe
del fppg1.exe
attrib -s -h -r autorun.inf
del autorun.inf
echo All done
echo.

I then ran clean.bat from the console on each partition. Happy that my system was back to normal, I restarted explorer to remove the effects of the autorun.inf file on the default open option on the drives. I then proceeded to open F: drive using the double click through My Computer. I was surprised to see the delay occurring again. The attrib command confirmed my doubts. The two files were back. I decided to dump the strings from the fppg1.exe file to see if I could find any clues. I ran the strings utility and piped the output to a text file called fppg1.text.

The file contained loads of ASCII characters and just three APIs that I recognized. That didn’t help much.

I then fired up Process Monitor to see what process was writing these files to disk. I used two filters with Path contains autorun.inf then include and Path contains fppg1.exe then include. I was surprised to see which process was writing, setting attributes and querying information.

It wasn’t only explorer.exe that drained my happiness out of me.

I then right clicked on Explorer to view its stack when IRP_MJ_CREATE Operation was performed. The stack had one unfamiliar entry.

I used the find handle or dll feature of Process Explorer to search for amvo0.dll. The returned results didn’t raise my spirits.

The dll had attached itself to other processes I had opened after restarting explorer. I then opened up cmd, changed to C:\Windows\System32\ and used the attrib command to confirm my suspicions about the attributes of amvo0.dll. I wasn’t disappointed.

I suspected that there could be an associated executable also present in the same directory and hence used attrib amv*. With my suspicions confirmed, I used strings.exe to dump strings from amvo.exe and did a file compare with fppg1.txt. Bingo! They were the same files in essence. The dll amvo0.dll was making explorer.exe and the system process to recreate the files fppg1.exe and autorun.inf whenever they were not found in the root of the drives. I used attrib again to remove the system and hidden attribute from amvo.exe and amvo0.dll and deleted amvo.exe through the command prompt. The file amvo0.dll was in memory and hence could not be deleted. One shortcoming of Process Explorer, I found would have really helped me, was to unload dlls which would have allowed me to delete the file immediately. I used autoruns.exe, another of Sysinternals creations, and found that amvo.exe created a registry entry in HKCU\Software\Microsoft\Windows\CurrentVersion\Run that caused it to be run at system startup. With the file gone, I restarted my system and then deleted amvo0.dll manually, fppg1.exe and the autorun.inf file using the bat file.

Case closed. I then went on to start my morning.