Identifying malware infected reply messages

A technique for identifying reply mailer computer program viruses detects whether a reply message is generated in less than a threshold reply time and whether or not the reply message includes an attachment. The generation of a reply message in less than a threshold reply time and including an attachment is deemed indicative of an infected reply message and accordingly that message will be quarantined, deleted, disinfected or the like. The mail server using the present technique maintains a temporary log of email messages sent indicating the sender, the recipient, and the time of sending. This log is used to identify replies and determine whether or not those replies have been received in less than the reply threshold time.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of data processing systems. More particularly, this invention relates to the identification of malware infected reply messages, such as, for example, reply email messages infected with computer viruses, worms, Trojans etc.

2. Description of the Prior Art

An increasingly common and serious malware threat is that of email propagated computer viruses, worms, Trojans and other items of malware. Using email propagation, such items of malware can rapidly multiply and spread to an extent that causes considerable disruption and economic damage. One type of email propagation involves so called mass mailer viruses. When a computer is infected with such a mass mailer virus, then the mass mailer virus sends itself to some or all of the email addresses in the infected computer's email address book. An outbreak of a mass mailer virus can be identified by observing the email usage characteristics of an email server, such as noting the occurrence of a large number of emails being sent to a large number of different recipients, the occurrence of a large number of emails sharing a common title, a common attachment, or other common features. This type of characteristic behaviour can be identified and anti-malware actions, such as quarantining etc, taken even before a new virus has been fully identified and a proper signature identified and distributed. Existing computer programs which serve to monitor email server behaviour to identify this type of mass mailer virus include Outbreak Manager produced by Network Associates, Inc.

A new type of malware has emerged which propagates by email and has the potential for causing considerable damage and yet does not give rise to characteristic patterns of email traffic that can be proactively detected using the known techniques as mentioned above. These so called reply mailer viruses act on an infected computer by waiting for an email to be received from another computer user and then automatically replying to that specific other computer user with an infected reply email. This infected reply email can reuse the message title of the originating email from that other user and the other user will recognise the sender of the infected reply email as a person known to them. Furthermore, the receipt of a reply email of some sort by the other user will not be unexpected since they have just themselves initiated the email exchange. The result is that the recipient of the infected reply email is likely to consider the infected reply email as genuine and open or deal with it in other ways which cause their computer to become infected.

The known techniques for dealing with mass mailing computer viruses are ineffective against reply mailer computer viruses since the reply is generally made to a single user making the increase in email traffic relatively slight, the email titles can be copied from the originating email messages giving no consistent title that identifies an infected email and there is no sending of a single email message to a large group of recipients which could otherwise be suspicious. Thus, until the specific virus signature for the reply mailer virus has been developed and deployed in the email virus scanning systems, then the known types of email scanners are unable to detect and accordingly provide a defense against reply mailer viruses.

SUMMARY OF THE INVENTION

Viewed from one aspect the present invention provides a computer program product for controlling a computer to identify a malware infected message, said computer program product comprising:

reply time detecting code operable to detect a reply message generated in less than a threshold reply time from a reference event associated with a corresponding originating message;

attachment status detecting code operable to detect an attachment status of said reply message matching a trigger attachment status; and

infected message identifying code operable to identify said reply message as a malware infected message if said reply message was generated in less than said threshold reply time and said reply message has an attachment status matching said trigger attachment status.

The present technique recognises that relatively distinctive characteristics of the behaviour of a reply mailer virus and other malware operating upon a similar principle is that the reply message is generated quickly and the reply message has an attachment carrying the infection. Infected behaviour is of the type whereby a reply message is generated very rapidly, for example in a matter of milliseconds after the originating message is sent, in a manner which would not occur as a result of a genuine user opening the originating message, reading the originating message, composing a reply to the originating message and then sending that reply. However, this characteristic cannot be used in itself as there are some known legitimate automated reply generating mechanisms, such as out of office mechanisms, which will rapidly generate a reply message when an originating email is received. However, a further feature of an infected reply message is that it will have an attachment carrying the infection. Also requiring this characteristic helps to avoid false triggers based upon legitimate out of office mechanisms which do not utilise attachments but merely send a simple message in the form of plain text indicating, for example, that the recipient will be unable to read or reply until a certain date.

The present technique uses a combination of a reply message being generated in less than a threshold reply time and an attachment status of the reply message matching a trigger attachment status in order to identify a message as an infected message. This mechanism is able to provide a defense against malware, such as reply mailer viruses, by detecting their characteristic behaviour rather than having to wait until a specific virus detecting signature has been developed and deployed. The higher level of protection against this new type of malware threat is strongly advantageous.

The rapid generation of the reply message which is detected is relative to a reference event associated with the originating message. This reference event could take a variety of different forms, but in preferred embodiments is one of the sending of the originating message or the reading of the originating message. The reading of the originating message may be the reading of the originating message by the mail client program of the receiving user from the mail server database as opposed to the reading of the message by a human user.

The attachment status associated with the reply message could take a variety of different forms. A simple type of attachment status may be the presence or absence of an attachment of any sort. The presence of an attachment of any sort may be taken as a characteristic of the type of malware behaviour for which identification is being sought. Increased selectivity and reduced false alarms can be achieved by seeking to detect attachment status corresponding to the presence of an attachment having a size exceeding a threshold attachment size (this type of malware behaviour requires an amount of coding which is relatively large and thus provides a practical minimum size for an attachment that may carry an infection) or an attachment file type matching a type which can carry computer code to be execute, such as an EXE, COM or VBS file type or the like.

The originating message and the reply message can take a variety of different forms. Current message forms to which the present technique is directly applicable are email messages. However, it is possible that the technique may be applied to other types of message that can carry malware.

It will be appreciated that the threshold reply time varies depending upon the particular characteristics of the system operating the technique, e.g. the processing speed, communication link speed, memory capacity etc. In order to deal with this variability, preferred embodiments of the invention provide a calibration mechanism whereby a calibrating originating message is generated, a calibrating reply message automatically generated and the time between the generation of the calibrating originating message and the generation of the calibrating reply message measured to provide a basis upon which the threshold reply time can be set. The calibrating behaviour is intended to follow the type of behaviour that this sort of malware would show and accordingly be subject to roughly similar processing times giving at least a starting point for the determination of threshold reply times.

These threshold reply times can be calculated for a mail server as a whole, individual users on the mail server or possibly even individual users on a mail server in respect of mail being sent to specific other mail servers or within the same mail server.

It will be appreciated that the malware being identified could take a wide variety of different forms, such as a computer program virus, a computer program worm, a computer program Trojan etc. Other types of malware may also share this type of behaviour.

Viewed from another aspect the present invention also provides a method of identifying a malware infected message, said method comprising the steps of:

detecting a reply message generated in less than a threshold reply time from a reference event associated with a corresponding originating message;

detecting an attachment status of said reply message matching a trigger attachment status; and

identifying said reply message as a malware infected message if said reply message was generated in less than said threshold reply time and said reply message has an attachment status matching said trigger attachment status.

Viewed from a further aspect the invention provides apparatus for identifying a malware infected message, said apparatus comprising:

reply time detecting logic operable to detect a reply message generated in less than a threshold reply time from a reference event associated with a corresponding originating message;

attachment status detecting logic operable to detect an attachment status of said reply message matching a trigger attachment status; and

infected message identifying logic operable to identify said reply message as a malware infected message if said reply message was generated in less than said threshold reply time and said reply message has an attachment status matching said trigger attachment status.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1schematically illustrates three email servers2,4,6each with respective attached users8,10,12,14,16and18. The email server2has a dedicated direct connection to the email server4, such as may be provided within a large organisation operating multiple sites and utilising different email servers at those sites. The email server6is connected via the interne to other email servers in a way that represents a different organisation to which email may be sent.

In operation, when a user10sends an email message to another user10on the same mail server2, if the other user10is infected with a reply mailer virus, then an infected reply email will be automatically generated by the reply mailer virus and received by the user8very rapidly and in a consistent amount of time. In a similar way, an email message originating with the user8and sent to the user14who is a user of a co-operating mail server4will also typically show relatively rapid and consistent reply times when the user14is infected.

If the originating email message from the user8is being sent to the user16on a distant mail server6, then it is possible that the reply times will be relatively long even when the user16is infected. However, whilst it may be more difficult to use the present technique to detect infected reply emails from the mail server6, this may still be done in some circumstances. Furthermore, it is generally the case that a typical user will receive a large number of emails from within their own organisation and from users connected to their own mail server compared with the number received from elsewhere. Thus, detection of reply mailer computer virus characteristics within a mail server or within a group of consistently connected mail servers is highly beneficial and provides a good degree of protection.

FIG. 2schematically illustrates the operation of a reply mailer virus. At step18an originating non-infected user sends an originating genuine email to an infected recipient. At step20the infected recipient receives the originating email. At step22the reply mailer virus code which is executing on the infected recipient's computer responds to the received originating email by reading the sender's email address and the originating email title and then generating an infected reply email reusing the email title and directed to the sender of the originating email. The infected reply email may, for example, include some text encouraging the originating user to open the attached reply mailer virus code so that it may be executed and infect the originating user's computer. At step24the originating user receives the infected reply email. At step26the originating user opens the infected reply email in a manner which leads to their own infection and accordingly propagation of the virus.

FIG. 3is a flow diagram schematically illustrating a computer program thread which may execute as part of the mechanisms for implementing the present technique. This thread typically executes as part of a malware scanning program operating on an email server or in association with an email server.

At step28a check is made for originating emails being sent from an originating user. When such an originating email is sent, then step30serves to generate a stored reference event log entry for the originating email indicating the email address of the sender, the email address of the recipient and the time that the originating email was sent. Processing can then return to step28to await the next originating email.

FIG. 4is a flow diagram schematically illustrating another computer program thread which operates on the originator's computer. When an email is received at step32, then processing proceeds to step34at which a check is made to determine whether the received email is a reply email. This check may be performed by comparing the sender and recipient of the email received at step32with respectively the recipient and the sender of the reference events logged at step30ofFIG. 3. The reference event log will typically serve to store reference events of originating emails generated within a preceding period of time, such as within the last ten minutes. As reply mailer virus behaviour typically generates infected reply emails within millisecond delay periods, buffering ten minutes worth of logged reference events will typically be more than sufficient to identify potential infected reply emails.

If the determination made at step34was that the received email has a sender and recipient matching a recipient and sender in the log, then it will be determined to be a reply email. An additional check for a matching title may be made for improved selectivity, although this is not necessarily required and could lead to a loophole that a virus writer could exploit.

If the determination at step34was that the received email was not a reply email, then the thread terminates, or in practice returns to step32to await the next received email. If the determination at step34was that the received email is a reply email, then processing proceeds to step36. Step36compares the elapsed time from the current time at which the reply email has been received with the logged time for the sending of the originating email and determines if this difference is less than a threshold reply time. If this determination is that the elapsed time is greater than the threshold, then the thread again terminates. If the determination is that the elapsed time is less than the threshold, then processing proceeds to step38at which a determination of the attachment status of the received reply email is made.

The attachment status can take a variety of different forms. A simple form is merely to check whether or not there is an attachment. An attachment is required by a reply mailer virus to carry the infection (virus code) to a new victim. Accordingly, the absence of an attachment may be taken to indicate that the received reply email is not infected and may be safely passed to the intended recipient without risk. An example of a rapidly generated reply email without an attachment would be an out of office message generated in response to an originating email message. Further examples of attachment status characteristics being matched could be that the received reply email contains an attachment over a predetermined size sufficient to carry a reply mailer virus or that the attachment has a file type suitable for carrying computer program code that can infect a victim computer.

If the determination at step38was that the received reply email has an attachment status matching the trigger attachment status, then processing proceeds to step40at which infected email actions, such as quarantining, disinfection, deletion, alert message generation etc may be triggered. If the determination at step38was that the attachment statement did not match the trigger attachment status, then the tread will be terminated or returned to step32without triggering the infected email actions at step40.

FIG. 5schematically illustrates a reference event log of the type which may be generated in step30ofFIG. 3. This reference event log contains records indicating a sender, a recipient and a sending time for each originating email message. It will be appreciated that the reference events logged relate to all email traffic through the email server concerned irrespective of whether or not the email messages are newly composed messages, reply messages in themselves, forwarding of messages or other types of messages. The reference event log will typically keep a log of reference events for a predetermined buffer period.

It will be appreciated that the reference events that are logged could alternatively take the form of recording the time at which an email message was read (notified to the email client of the intended recipient). It is normally this reading/notification at an infected user which enables the reply mailer virus computer program at that infected user to obtain the email address of a new victim. Triggering off the reading/notification time rather than the sending time may be advantageous in dealing with situations in which the recipient has been offline (e.g. not yet logged in for the day) and then becomes active and accordingly allows their infected computer to rapidly generate infected reply messages once they have connected to the email server where their email has been waiting for them.

FIG. 6schematically illustrates a database of threshold reply times associated with different users. Furthermore, in the example ofFIG. 6the users have respective threshold times associated with more than one recipient email server to which their email may be addressed. In a simple embodiment only a single threshold time may be associated with each user corresponding to rapid reply generation when the recipient is a user connected to the same email server. In a more complicated system, multiple threshold times may be recorded in respect of different email servers to which the user will generally send a relatively large number of email messages and which email servers will respond in a consistent and rapid time when displaying infected behaviour.

FIG. 7is a flow diagram schematically illustrating the calibration of reply threshold times. This calibration procedure may be manually initiated or automatically initiated on a regular basis, or when system configuration changes are made. At step42the out of office behaviour for a recipient, which may be a dummy recipient, is switched on. At step44a calibrating originating email message is sent to that dummy user so as to trigger the automatic generation of an out of office reply. At step46, the time at which the calibrating originating message was sent is logged. At step48the system waits until the calibrating reply email is received. When this calibrating reply email is received, processing proceeds to step50at which the time at which the calibrating reply email is received is logged. At step52the times logged at steps46and50are compared to determine a typical automatic response time for the email message path concerned. This may be subject to a multiplication factor to provide some resistance against false alarms and a reply threshold time thus calculated in respect of the originating user and the recipient email server on the path being calibrated.

FIG. 8is a further figure illustrating operation of the present technique. A user54sends an originating email message56to a recipient user58. The recipient user58then generates a reply email message60. This reply email message may be genuine, such as generated after a user reads and composes a reply, or an automatically generated out of office message not having an attachment, or may be an infected reply message automatically and rapidly generated by a reply mailer computer program virus.

The mail server62via which all of these email messages are routed is first to inspect the reply email message60. It utilises its stored reference event log64to determine if the reply email message is a reply or a new email message that should be separately considered. If the reply email message60is identified as such, then the mail server62references its store of threshold data66to determine if the reply email message60has been generated in less than a threshold reply time. If the reply email message60has been generated in less than the threshold reply time associated with the originating user and the mail server to which the originating email message60was sent, then a check is made as to whether or not the reply email message includes an attachment. If the email message does include such an attachment, then the infected message mechanisms are triggered and the reply email message60sent to a quarantine store68or otherwise processed, such as by disinfection, deletion, triggering generation of an alerting message or the like. If either the reply email message60was not generated in less than the threshold reply time or the reply email message60did not have an associated attachment, then it is treated as a genuine reply message and returned to the user54.

FIG. 9schematically illustrates a general purpose computer200of the type that may be used to implement the above described techniques. The general purpose computer200includes a central processing unit202, a random access memory204, a read only memory206, a network interface card208, a hard disk drive210, a display driver212and monitor214and a user input/output circuit216with a keyboard218and mouse220all connected via a common bus222. In operation the central processing unit202will execute computer program instructions that may be stored in one or more of the random access memory204, the read only memory206and the hard disk drive210or dynamically downloaded via the network interface card208. The results of the processing performed may be displayed to a user via the display driver212and the monitor214. User inputs for controlling the operation of the general purpose computer200may be received via the user input output circuit216from the keyboard218or the mouse220. It will be appreciated that the computer program could be written in a variety of different computer languages. The computer program may be stored and distributed on a recording medium or dynamically downloaded to the general purpose computer200. When operating under control of an appropriate computer program, the general purpose computer200can perform the above described techniques and can be considered to form an apparatus for performing the above described technique. The architecture of the general purpose computer200could vary considerably andFIG. 9is only one example.