Botnets by Email
I make no effort to hide my email address, which means that I know the instant a new email-based virus, phishing attack, or penny-stock-pumping scam launches when my inbox floods. Most such emails are easy to distinguish from legitimate emails because of their lack of personalization, poor grammar, or low-quality images that attempt to foil spam filters. On occasion, however, I get a message that causes me to examine it a little more closely in order to make sure it’s junk. I also look out for ones that might trick unsophisticated users.
My family uses BlueMountain greetings to send eCards, so when I received this email I took a second look:
There are a couple of immediate clues that the email is a fake. For example, the body doesn’t address me by name and there’s a space between “friend” and the exclamation point. Hovering the mouse over the link shows that it masks an address at a different site, but the presence of BlueMountains and the legitimate-looking KoKoCards in the name might be sufficient to fool a casual scan.
Curious to see what kind of con the email was perpetrating, I fired up a virtual machine that was isolated from the local network and clicked on the link. Instead of being taken to a web site like I expected, an Internet Explorer dialog appeared and asked me if I wanted to save or run “Postcard.jpg.exe.” Most users that might have followed the ruse this far would probably be suspicious and not run it, but out of curiosity I started Process Monitor to watch the action and ran it. What I found isn’t very sophisticated, but it’s interesting because it’s an email virus that’s making the rounds today.
First I saw the flash of a command prompt window starting and exiting and then a prompt from the firewall appeared:
I immediately recognized that the program wanting through the firewall is a popular Internet Relay Chat (IRC) client. I unblocked it, waited a couple of minutes, and then turned my attention to Process Monitor to see what had transpired. I opened the process tree tool from the Tools menu, which shows all the processes that generated activity in a tracing session, including ones that have exited. I saw evidence of the initial installer, the command prompt that I had seen, and a Regedit child process of the command prompt, all of which have faded icons to show that they had exited by the end of the collected trace:
The command prompt’s command line, visible in the process tree, indicates that it was launched to execute a batchfile, sup.bat. Sup.bat was left in the System32 directory, so I could see from its contents that it passes Regedit a registry file named sup.reg, which creates two auto-start entries:
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run]
"taskmgr"="C:\\WINNT\\system32\\explorer.exe"
"IExplorer"="C:\\WINDOWS\\system32\\explorer.exe"
The seemingly redundant entries simply ensure that mIRC will autostart when the system boots regardless of whether the system directory is Winnt or Windows.
The process tree showed only one additional process still running, mIRC, which was using Explorer as its cover name to blend into the list of legitimate programs a user would see in Task Manager. Process Monitor of course reveals “explorer’s” true identify by showing the mIRC icon, description and company name:
The mIRC I had on my system was unmodified from the one on the mIRC homepage. My guess is that the malware author didn’t alter the description or company name because they don’t show up in versions of Task Manager prior to the one in Windows Vista, and antivirus is left faced with the difficult position of flagging a legitimate program as malware.
Having completed my examination of the process tree, I returned to Process Monitor’s tracing window and scanned through the output. I set a Category filter to include operations in the Write category, which narrowed the output to modifications made during the installation and first run of mIRC. I quickly ran across a string of writes to .ini files in the \Windows\System32 directory:
I’m not familiar with mIRC, but after studying the contents of the files for a few minutes I figured out that the files cause mIRC to automatically join chat channels named mp3-w4r3z and mp3-download on a chat server randomly selected from the ones stored in the Server.ini file, all of which are in the undernet.org domain. Finally, the heart of the operation is the script.ini file, which appears to implement commands that remote users can execute, including “run.”
At this point I concluded that what I had installed was a very simple Botnet client. I left it running for several hours, but didn’t notice any further activity. Surprised that the system hadn’t become an active Bot, I opened mIRC and manually connected to several of the servers listed in the Servers.ini file, but none of them had mp3-w4r3z or mp3-download channels, so they had either been shut down or hadn’t been configured, yet.
A few days later I received a similar email, but this time Microsoft’s spam server had stripped the contents and indicated that what I had installed was Trojan-Spy.HTML.Pcard.w, but an Internet search for more information didn’t yield anything meaningful.
I’m left wondering how successfully this type of lure brings users into a Bot herder’s web. There are numerous warnings that something funny is going on, from the lack of personalization to being asked to run a program and open a port in the firewall (and on Windows Vista there’s an additional UAC elevation prompt to give administrative privileges to Postcard.jpg.exe). The fact that this Bot herder didn’t bother with more sophistication leads me to believe that it’s still unnecessary: enough people ignore the warnings.
Users will get more wary, however, so we’re in store for craftier attacks that will fool even paranoid users. Other spam and virus emails I’ve received address me as Mark, which I assume they get from my old mark@sysinternals.com address, but there are other tricks for guessing or even obtaining a user’s name, like contact harvesting. Exploits of zero-day and unpatched vulnerabilities can deliver malware without user interaction, and malware can use communications techniques, like proxy servers, http traffic, or outbound-initiated bidirectional connections, to avoid causing firewall popups.
Windows Vista’s UAC and Protected Mode IE can help mitigate attacks, but adoption will take time and even these technologies give malware a lot of room to play. There’s work going on at Microsoft to address these threats, but there’s no silver bullet. The fight against malware continues.
