Blogs

Botnets by Email

  • Comments 31
  • Likes

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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks for the read Mark,

    I'm really excited about the UAC article that you're going to post in the June issue of technet magazine though! Can we get any previews at all?

  • Interesting as usual!  Although it would have been more interesting had you actually discovered some activity.

  • Much people say that Windows is too unsecure, from my point of view the truth is that there is a lot of careless people and logically should have more careless people in Windows just for the amount of users

  • Thats an interesting article and interesting stuff. Now I want to playaround with Process Monitor.

  • Very interesting, glad to see you back with an article, I love em! :-)

    I think much of the novice users just click away dialogs and click links because they don't read them, they don't think it can be a scam and if they do, they don't understand what it all means. It's too much for them.

    Education is needed here!

  • Hi Mark, interesting read.

    Could Outlook be updated so that if the displayed URL and the linked URL don't match, then Outlook could launch InternetExplorer in a "Safe" mode that is more protected ( and maybe also has a indicator that that particular session could be dangerous - e.g, a RED border ).

    Unfortunately the ease of use of applications ( including Outlook ) make these types of attacks much more likely to occur, and much harder for non-tech savvy users to fall for.

  • PingBack from http://thanadon.com/news/botnets-by-email-bluemountain-greetings.html

  • I also got some of these "postcards", and they are crude malware. In fact, the executable is a WinRAR Self Extract Executable (SFX). When you run it, it unpacks the files and starts a script. You can see the WinRAR SFX icon in your screenshot.

  • Come on, man! What's happening to you? You used to post some great "research & internals" articles...

    Now this?!

  • Excellent! Very informative. And, I might add, gutsy.

  • Well, we all know that we shall not click on links in mails and stuff like that. Marc Russinovich did

  • I just wonder why Mr. Russinovich isn't aware of the security vulnerabilities in the HTML renderer? There are various ways to even fool the hovering text and the status bar to point at any URL you like, whereas clicking on the URL takes you somewhere completely different. Classical examples are styled form buttons within a label tag, or links within a table, and you know, these have never been patched (not even on Vista).

    Actually you should feel glad that you never clicked the Reply button, since this would allow the attacker to inject arbitrary HTML code into the reply window (including JavaScript and ActiveX being turned on there by default, yikes!).

    One would think that Mark should know how to differ a serious mail client from a hardly RFC-conformant wannabe-mail-client ActiveX Rich Platform Client.

  • Pocas veces uno tiene la oportunidad de entender que tan vulnerables somos en este ciber-espacio. Y peor

  • Hoy en cosas interesantes: Diseñando cubos en SQL Server para usarlos en PivotTables de Excel 2007, Creador

  • that's why i don't use mail client with use of IE rendering. My client has its own renderer, so there are less chances it can be vulnerable.