Virus Busters Home


What to Do With Suspicious Email Attachments

by Bruce P. Burrell (bpb@umich.edu)
for the U-M Virus Busters (virus.busters@umich.edu)
Last significant update: 08 November 2002

This information can be freely reproduced in any medium, as long as the information is unmodified.

Suppose you have received email that has a suspicious attachment, or that you know contains a virus, Trojan Horse, or other malware. What should you do?

  1. The easiest solution, of course, is to delete the email and be done with it -- or better yet, filter it out so that it never reaches your mailbox in the first place.

    The latter can be attained both by your email provider scanning for hostile code at the email gateway, before it reaches your mailbox, and by imposing filters so that stuff that does get to your mailbox never is actually presented to your email client.

  2. Sometimes, just deleting the incoming email may not be enough. Why not? Here are some possibilities:

    • The sheer the volume of the email may have an impact that it requires action. [For example, each W32/SirCam email attachment is at least 190 KB, and so long as the computer remains connected to the Net, it will continue to send email to all the addresses it has harvested, over and over.]

    • You have reason to believe that if you do not take action to identify the victim promptly, "Something Bad Will Happen(TM)" -- whether that Bad Thing is to you, or to the victim, or to someone/something else. [For example, you may know that a particular virus has a payload that will, in the very near future, delete data on the victim's computer.]

    • You are motivated by a sense of duty or altruism to help the victim (both the current one, and potential new ones)

    • You are motivated by a fanatical sense of zeal to destroy viruses (if so, come with me while I attack this windmill. "Chaaaaarge!!!")

  3. So, how to decide whether to do something?

    • Different malware has different propagation characteristics. For example, some viruses email infected attachments to any given address only once (e.g., W95/Ska.A). Others, like SirCam, keep pumping out infected attachments over and over, to every address the virus has harvested on the current victim's machine. Everything else equal, stopping Ska is less important than curtailing SirCam.

    • Different viruses have different "victim pools." For example, it's probably the case that every machine susceptible to CodeRed or Nimda has already been infected by these viruses: they spread very rapidly, and machines not protected against them were infected months ago. For the "new, fast-spreading Virus du Jour" (whatever that virus might be), which is not yet recognized by antivirus software however, taking action NOW is much more important: There are lots of machines not yet infected, so identifying victimized computers and disinfecting them means that fewer uninfected will become compromised.

    • One virus may put the victim at more risk of identity theft than another.

    • A given virus may behave differently for different victims. For example, on one machine it may send out lots of infected email, while on another, it may send infections but rarely

    • A given virus may behave differently for the same victim, based on various parameters. For instance, a virus may behave differently after it has infected a machine for a certain period of time.

    • If the email is old -- over 2 days or so, perhaps , and certainly if it is more than a week old -- it may have been fixed already. Unless you have a more recent sample, think twice about doing anything with it.

    Using these metrics may help to decide whether the case at hand is worth extra effort on your part (beyond merely deleting the email).

  4. So, suppose you decide that further action is warranted. What should you do?

    FIRST: Note that you should never send potentially hostile code to ANYONE you don't know and trust -- so think twice think twice before you forward hostile or suspicious code to us ... or to anyone else.

    That said, here is a list of actions you may want to consider:

    1. Contact your competent antivirus tech support; follow their proper procedures for what to do. This may be antivirus tech support provided by your employer, ISP, or antivirus software vendor.

      If you decide to alert your antivirus tech support, be sure to follow their policies for when it is appropriate to contact them. If you have no such guidelines, I suggest that you contact them only when you know or suspect that a virus (or other malware) is the problem.

      • U-M folks: Assuming (a) that you consider us to be "competent antivirus tech support" -- and that's something that you, not we, must decide -- and (b) that this is not an outbreak of massive proportions, make sure that you send them the entire message (email body, attachments if any, and full email headers. Otherwise we may not be able to identify the victim, and we'll all waste precious time with back-and-forth to get the proper info.

      • (Still to the U-M audience): If this is a U-M (or worldwide) epidemic, please do NOT forward us the whole email. Better to send us a short note and ask what we need from you. If we don't get back to you, we're probably working on the problem and will reply when things die down.

        Also: If you received the suspicious file in email sent to a group -- instead of to you alone -- please send email to the group indicating that you have passed the email along to us for analysis, and that others in that group need not send that same email to us. One copy of any particular email -- assuming it was forwarded according to the recipe outlined at our page on how to send suspect email -- is enough!

    2. Contact your postmaster and ask that email from the offending machine be blocked. Again, see our page on how to send suspect email for how to get email headers for your postmaster. But it may be better to contact that competent antivirus tech support first, so that postmaster doesn't get flooded with similar requests.

      If you decide to alert your postmaster, be sure to follow their policies for when it is appropriate to contact them. If you have no guidelines I suggest that you contact your postmaster only when you know or suspect that network load (network slowdown) is the problem. In any event, don't forward suspicious or infected code to postmaster unless your postmaster explicitly requests that you include attachments.

    3. Contact your abuse staff

      If you decide to alert your abuse staff, follow their policies for when it is appropriate to contact them. If you have no guidelines, I suggest that you contact your abuse staff only when you know or suspect that network abuse (spam, harassment, etc.) is the problem. Again: In any event, don't forward suspicious or infected code to postmaster unless your postmaster explicitly requests that you include attachments.

      For the cases above, there may be overlap. Think before you contact anyone. It may, of course, be proper to contact more than one of these units; probably using one email to all appropriate parties is best, so that everyone knows who has been contacted.

    4. Contact the victim's postmaster/ISP/abuse department. But caution: this can be tricky. For example, the W32/Klez.E@MM virus often forges its From: field, so be careful that you contact the proper party. That's why usually it is better to send the information to competent antivirus tech support than to try to do it yourself (unless you are a computer antivirus guru, of course).

    Again, I repeat: You should never send potentially hostile code to ANYONE you don't know and trust -- so think twice think twice before you forward hostile or suspicious code to us ... or to anyone else.

       -BPB

    University of Michigan AntiVirus Team Leader
    University of Michigan Data Recovery Team Leader
    PGP 2.6.2 key fingerprint: 0D A5 98 3C 91 DA E0 DD 9C 6D FA 8F 4D 34 95 ED

  5. Virus Busters Home


    Last updated: Wednesday, 25-Dec-2002 13:48:32 EST.
    University of Michigan Virus Busters - virus.busters@umich.edu

    visits to this page since 15 April 2002 16:53 EDT