The Kneber Botnet

The term Botnet is used to refer to a collection of software robots or bots which are automated applications that infect multiple, possibly geographically disbursed, computers. These infected computers can then be controlled remotely via a central Control and Command Center (C&C) which the Botnet herder sets up. Botnets are used in underground criminal activities to steal credit card information, perform Distributed Denial of Service attacks, creation or misuse of SMTP mail relays for spam, click fraud, spamdexing and the theft of application serial numbers and login IDs of personal banking accounts and online mail accounts.

While the term “botnet” can be used to refer to any group of bots, such as IRC bots, this word is generally used to refer to a collection of compromised computers (called zombie computers) running software, usually installed via drive-by downloads exploiting web browser vulnerabilities, worms, Trojan horses, or backdoors, under a common command-and-control infrastructure. This setup is remotely controlled by a Bot herder, also called as Bot master using a C&C via IRC channels or through Web Servers. When a botnet has become sufficiently large, criminals may try to acquire them for undisclosed but large sums of money to gain access to all the data and resulting information from the infected machines and subsequently from the networks associated with them.

The Kneber botnet, discovered by NetWitness, a company that deals with network monitoring and threat analysis solutions, is a new variant of the already massive ZeuS botnet, which has reportedly compromised 75000 machines in 2500 business worldwide. The Kneber botnet is based on the older 1.2 version of ZeuS which is given away for free. ZeuS, also known as Zbot, is readily available to buy in underground forums for as little as 700 USD. The package contains a builder that can generate a bot executable and Web server files (PHP, images, SQL templates) for use as the command and control server. While ZeuS is a generic back door that allows full control by an unauthorized remote user, the primary function of ZeuS is financial gain stealing online credentials such as FTP, email, online banking, and other online passwords via keystroke logging. Zeus’ current botnet is estimated to include millions of compromised computers (around 3.6 million in the United States alone). Zeus is spread mainly through drive-by downloads and phishing schemes. First identified in July 2007 when it was used to steal information from the United States Department of Transportation, it became more widespread in March 2009. In June 2009, security company Prevx discovered that Zeus had compromised over 74,000 FTP accounts on websites of such companies as the Bank of America, NASA, Monster, ABC, Oracle, Cisco, Amazon, and BusinessWeek.

The Kneber botnet is a relatively small botnet considering the number of compromised computers, although the number of organization and business infected is quite high. The Kneber botnet uses rootkit technologies, undocumented Windows API and other stealth techniques to hide its presence on the infected machine. The Kneber botnet infects only Windows computers and has been known to infect Windows XP Professional SP 2 machines more than any other flavors. The explanation for this could be attributed to the nature in which machines are infected. Computers at the work place can be infected via accesses to sites that cause drive by downloads, URLs of which may be received via spam mails. Also vulnerabilities in the browser (IE 6 and IE 7) and security issues in the OS itself may trigger an infection. No reports of Windows 7 computers being infected have been seen yet possibly due to the use of IE 8 and patching of critical vulnerabilities found in older versions of Windows.

Symptoms of infection may include unexplained bandwidth usage, unknown processes being created, unexplained usage of CPU and memory resources and frequent stalling of applications. The ZeuS botnet is very difficult to detect even with up-to-date antivirus software. Ironically, there are other botnets that have installers made for ZeuS, like the Trojan SpyEye, so that when it affects a computer already infected with ZeuS, it can kick out Zeus and claim the machine for itself. Of course, the computer is still a bot, just with a different Control and Command Center and Bot Herder. The Kneber botnet on the other hand is easily detected and cleaned by most antivirus programs due to its usage of the older version of ZeuS. Egress filtering on traffic at the network perimeter between internal private networks and the Internet may help detect early infection and coupled with active intrusion detection systems may protect organizations and businesses alike. Using virtual keyboards, found on the login pages of most banking applications, or the Microsoft On-Screen Keyboard (osk.exe), when entering sensitive data on even trusted sites, will help protect user identities, financial information and data confidentiality. Common utilities like TCPView, Process Monitor and Process Explorer from Sysinternals (Microsoft) will help identify Network, CPU and Memory congestion factors. It is advisable that businesses continue to train its employees to prevent them from clicking links in emails or on the web, opening malicious attachments while also keeping up with antivirus and operating system updates. Securing the operating system goes in preventing several unrelated issues as well.

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

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.