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.


Comments (31)

  1. Anonymous says:

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

  2. Anonymous says:

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

  3. Anonymous says:

    "HSANTOS: There is only one solution – stop running DATA as CODE!"

    You mean, we should stop using stored program machines? Go back to the days when you have to rewire the system to make it do different things? I'm sure that'll go over really well…

  4. Anonymous says:

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

  5. Dani Sarfati says:

    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?

  6. ML49448 says:

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

  7. Erwin Ried says:

    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

  8. kalyan says:

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

  9. nick says:

    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!

  10. richardst1 says:

    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.

  11. Didier Stevens says:

    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.

  12. Camus SoNiCo says:

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

    Now this?!

  13. Rusty Campbell says:

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

  14. Anonymous says:

    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.

  15. wrootw says:

    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.

  16. Kevin says:

    I was actually wondering… Since so many of these programs require administrator access anymore… Why isn’t there a simple "Do not run this program as Administrator" option in the Compatibility section. It would at least make users a little more happy when a program has the requirement for Admin rights (Say an installer) and dumb it down a bit. That way, users could be (stupid) and run these types of programs NOT as administrators. >.>

    Some of the Administrator rights should be up to the users, not the devs of the programs they make >.<

  17. Janosch Ulmer says:

    @wroot: Actually, Outlook2007 does not IE for rendering, as I understood it is the rendering engine from Word.

    @Anonymous: "re: Hovering URL can’t be trusted either "

    Outlook IS a serious mail client – just because it is used by so many businesses. I think you did not get the message of what Mark was trying to do – he was just showing how an usual everyday-attack via Mail works and what a typical user would most likely sees – not to show what could be possible beneath this.

  18. Anonymous says:

    > Outlook IS a serious mail client – just

    > because it is used by so many businesses.

    Many people abusing it as a mail client doesn’t make it one.

    > how an usual everyday-attack via Mail works

    > and what a typical user would most likely

    > sees

    No, he didn’t. Everyday-attacks involve spoofing whereas the hover text will not show the real destination, and in fact one should wonder why the attacker didn’t even install the malware without the user’s consent (since there are so many unpatched vulnerabilities that Microsoft don’t care for).

    Sorry, but in the scenario Mark pointed out, you have already lost from the beginning, where untrustworthy content getting processed by Outlook.

  19. thumb says:

    thanks Mark for this little enjoyable article

    as some people said ,the point is user attention to the attack based on ‘social engineering’. right?

    anyway,Most of your works impressed me and i’m looking forward to reading your professional detailed articles.

  20. Alexei says:

    It’s interesting to look into that bot program a little deeper.  It seems like a generic bot.  I downloaded a couple of those.  The only difference between them was channels they connect to and users that can control them.  I connected to some of those channels.  On one of them there were about a hundred users with seemingly random names.  Those are bots.  Or in other words they are compromised machines that are just sitting there waiting to be taken control of.  Users who can control them are usually channel admins.  So you can immediately tell who the hackers are.  They can control all the bots on the channel simulteneously with commands posted to the channel.  This is some serious power that can be leveraged in many ways.  For example, If programmed for a DDoS attack they can take down a moderate bandwidth site.

  21. james says:

    In a similar vein, I have a student’s laptop beside me which is doing "novel" things; winlogon.exe has decided that opening a TCP connection to an Estonian webserver seems like a fun thing to do, and services.exe has gone into the spam business. Replacing the compromised winlogon.exe (booted from CD) doesn’t help – something detects that at boot, restores the compromised version and reboots immediately – and of course all McAfee VirusScan can offer is attempting to delete winlogon.exe, which (fortunately?) fails every time.

    It would make an interesting test of Windows Defender’s capabilities – but, needless to say, the laptop was supplied with XP Home and has been upgraded to a copy of XP Pro which flunks validation.

    I’ve submitted the compromised winlogon.exe itself to McAfee for analysis, but there are clearly other components involved; given the closing paragraph’s reference to work in progress at MS, is this one already on radar, or is anyone interested in helping investigate? (There’s a working address for me on the homepage linked, or use jas@spamcop.net.)

    (Yes, I could just wipe the machine and reinstall – or could, given the copy of XP Home it shipped with – but like Mark, getting a proper understanding of what is being done and how is much more appealing to me!)

  22. alex says:

    Wow goes to show how complicated spyware has gotten. I just don’t know why someone would stay on the computer so long to make some spyware to hurt someone else’s computer. It’s rediculous. At least webhosters are doing some good to the world.

  23. Eeyore says:

    Seems like an extremely crude piece of malware.

    Got to agree with Camus SoNiCo, writing about such a poorly constructed malware is a dissapointment.

    I suspect you were hoping to infiltrate the irc channel and bring the botnet down from the inside out, pity it didn’t work out like that.

  24. Rowan says:

    I’ve been seeing various forms of the postcard.jpg.exe attachments since late December.  Mostly the victim of the onces I’ve has been postcard.com.

    I have a unix account that has been the same since 1994. I use it as my whats new in spam hit list.  Since I’m running shell mostly I use wget to download the usually RAR encoded self-extracting files to see what they want to do.  Each attempt has varied between 700K to 1.5M, mIRC is popular.  I’ve noticed that the accounts hosting the files are closed in a day.  I would guess that the companies who write malware detectors are fairly quick after the ISP’s involved or the ISP doesn’t like the extra traffic of people who missed the various clues downloading a few hundred thousand copies of a 1mb file.  The usually Eastern European website hosting the file is probably a hacked site or account and a cheap DNS entry at some bulk host.

    As for a check on these files at download, the system should flag on anything with a double or more extension (.jpg.exe).  Ditto for SCR, BAT, COM, and VBS links from email, all of which I have seen attempted.

    The real solution to really end/reduce spam would be painful to implement at first, but would be a longer lasting solution.  It would require properly configured mail servers (some people are laughing here).  ESMTP (site1) already can check if the hostname(site2) provided in the HELO matches the IP (rDNS) of the host (site2) connecting to it. Most servers are configured to allow the connection even if the data doesn’t match. This email data is sanitized by a mail filter right now.

    What I would add to this is an extension to ESMTP which is a check by site2 back to site1 to see if site1 had initiated the original message, call it VerifiedESMTP.  An additional check could be to if site1 is a listed MX server for the domain that it claims to sending mail from, which would allow the many virtual mail domains to continue without impact.

    This of course won’t stop all spam, it will cut down on Trojan Infected Home PC spam.  Also by verifying that the sender is real before allowing the connect it will cut down on network traffic. It won’t catch a "monkey in the middle attack" or some form of compromised router. It will take care of roughly 80 percent of the spam currently being sent.

  25. HSANTOS says:

    Mark, excuse me if I sound critical. There is really nothing here new to discover.  The infamous CodeRed virus was 100% based on the idea that there will always exist a market of unsecured Windows machine.  It took nearly 4-5 years before CodeRed propagation dwindled and stop spreading.  Microsoft OSes simple need to stop spawning & running DATA as CODE!  This *use* (and still is frankly) to be ENGINEERING TABOO, but in the name integration, Microsoft stepped over the line and didn’t quite having the "engineering integrity" to cover its bases.  While VISTA and "virtual sandboxes" might help, curing the problem is a based on a presumption that everyone will have the same system, same security – not going to happen.

    There is only one solution – stop running DATA as CODE!  Period.  This isn’t rocket science.  We could of long ago added logic to run DATA as CODE in our electronic mail hosting servers and end-user mail readers, etc.  But we from a engineering ethical standpoint we chose not to do so – MS stepped over the line and the world is suffering because of is.  

    MS is once again faced with the new and same engineering challenge of PINGING and REGULATING remote computers, in the name of "security" (wink wink).

    But this is still an UNETHICAL practice and  while MS might be the "GOOD GUY" doing this practice, opening pandora’s box will lead to "Bad Guys" following and this will create even more remote networking chaos if this concept is allowed to continue to sneak and get around current US interstate commence and consumer privacy laws (UTICA).

    I’m being critical because the SOLUTION has always been quite simple – STOP RUNNING DATA as CODE.

  26. Jonathan Homer says:

    Interesting that the program asks to open a firewall port.  The problem with Microsoft’s firewall is that you can add an entry with no user rights to the registry to give access to the port.  The user would of have to wait for a reboot to use the port but that should in the majority of cases be within a day or a month or two for a server.

  27. Dragomir Tenev says:

    Spam and phishing is something very very bad. You are right that many programs detect such email spam letters, but there are still plenty of email providers that can not catch all the spam. I think that there is always a race between spammers and security managers. They both try to outsmart the other.

  28. Commentcles says:

    "HSANTOS: There is only one solution – stop running DATA as CODE!"

    Are you referring to an executable data? Seriously? Did you read the article? Oh lordy…