AusCERT - Lessons Learned from Loving Melissa

HOME

About AusCERT

Membership

PKI Services

Training

Publications

Sec. Bulletins

Conferences

News & Media

Services

Web Log

Site Map

Site Help

Member login

Lessons Learned from Loving Melissa

Date: 05 July 2000

Click here for printable version

Rob McMillan
Australian Computer Emergency Response Team
5 July 2000.

1. Abstract

Between April 1999 and May 2000 a series of events relating to computer security received blanket worldwide coverage. The incidents were based in very different modes of attack. While they certainly led to loss for a number of organisations, the consequences could have been worse. The intense media coverage is symptomatic of a growing public awareness of computer security issues, and serves to improve this awareness.

There are a number of valuable conclusions that can be drawn from these incidents. This paper raises issues that were highlighted during this period. It is our belief that the conclusions drawn in this paper will be of interest to both management and technical staff of organisations with an Internet presence.

Some of these are lessons that are already being addressed within the marketplace. Other issues demonstrate that there is still some way to go before Internet technology is effectively harnessed.

2. Notable Events

The period 1999 - 2000 saw a number of notable events. The technology behind these events ranged from the well-understood to the very new. In some cases, there is clear potential for more complex attacks to be developed. However this is a normal environment for IT security staff. The emerging aspect of interest was the unprecedented media focus in some instances, and interestingly, the apparent independence of this focus from the technical difficulty or potential of the problem.

2.1 Melissa

In April 1999, Melissa arrived ([ TREND-1]). This was a virus specific to Microsoft Word macros. Its main goal was self-propagation. Two main methods were employed. The first was through modification of Word template files. The second method was by attaching itself to copies of the current document and mailing it out to the first 50 addresses in the user's Microsoft Outlook address book. This second method was very important as it had the potential to compromise organisational confidentiality. It spread rapidly, affecting several hundred thousand systems spread over hundreds, possibly thousands of sites. Media coverage was extensive. However, direct reports to AusCERT by members were minimal. Variants appeared quickly and continued to emerge for months.

2.2 Active-X

In September 1999, Microsoft released an advisory about a problem with two Active-X controls ([MS99-032]). SANS reports that this problem can be used to spread viruses via electronic mail without the user needing to open an attachment ([SANS]). There were no reports to AusCERT of sites compromised by this problem, and media coverage was almost non-existent. However the problem was technically more problematic than other e-mail-borne problems because it didn't require the attachment to be opened.

2.3 Y2K

The roll over between 1999 and 2000 brought the millennium bug. Again, there was extensive media coverage, with significant focus on the potential for dramatic failure. AusCERT attended a workshop that resulted in a threat assessment ([ AUSCERT-1]). The threat assessment concluded that while some minor problems were expected, there was no expectation of major catastrophe. This threat assessment proved accurate.

2.4 Distributed Denial of Service (DDOS)

In February 2000, a series of high profile Denial of Service attacks (DOS) were launched against a number of sites, the most high profile being US-based E-Commerce sites. The attacks relied on a new technique that became known as Distributed Denial of Service attacks (DDOS [AUSCERT-2]). There was extensive media coverage, with significant damage estimates. These attacks were crippling to the victim sites, and at the present time there is no technique available, short of disconnection, to completely avoid these attacks.

2.5 The Love Bug

Finally, May 2000 saw the emergence of the I Love You virus, also known as the Love Bug ([ TREND-2]). This virus used a number of propagation techniques, primarily a combination of electronic mail and VB script. There was an associated Trojan Horse program that had potential to obtain authentication information ([TREND-3]). The repositories required to deliver the Trojan Horse were disabled fairly quickly, and the risk associated with the Trojan Horse (as distinct from the actual virus) was classed by some anti-virus vendors as low.

The Love Bug was similarly virulent to Melissa. While it did have some destructive qualities, its initial form did not present the same level as organisational risk as Melissa. Although the Love Bug had potential to reveal authentication information (a serious enough problem), passwords are in general easily changed by the victim site. Melissa, on the other hand, had potential to allow uncontrolled release of confidential data.

Media coverage of The Love Bug was the most intense of any of these events, with the possible exception of the Y2K event. Variants emerged rapidly, but for the most part were simplistic.

A later version, NewLove ([TREND-4]), had more destructive qualities and is potentially more virulent. However community awareness was much higher by this stage and its rate of propagation and the media coverage were both significantly lower.

3. Survey Results

Independently of this paper, AusCERT conducted a survey after the main activity from the Melissa and Love Bug events. The experiences reported by surveyed sites, outlined below, indicate that some more sensationalised reports did not always accurately reflect the true situation. The respondents in general are likely to be technical staff and middle managers.

3.1 Melissa

This first survey was conducted among AusCERT members in May 1999. It is likely that this group is more security conscious than the wider Internet community as a whole (for example, having in place proactive computer security measures such as virus scanners, monitoring security bulletins and so on). So while the results may not be indicative of the wider Australian and New Zealand Internet community, we believe they are nonetheless useful.

The responses indicated that generally Melissa did not have a significant impact on most sites. The majority of sites did not become infected, and even for those that did, the impact was typically considered minimal. The majority of sites did detect the virus but did not suffer any significant damage due to measures already in place.

As a result of the publicity surrounding Melissa many sites reported taking the opportunity to update their anti-virus software. A number of these sites reported that while the newer software didn't pick up any Melissa problems it did identify a number of other viruses which were present but hadn't been found using previous earlier versions of the software, some of which were only a few weeks out of date. This reinforces the general recommendation of ensuring that anti-virus software is regularly updated.

Some sites reported that they had greater problems with other viruses than they did with Melissa. Some sites were not directly infected but still noted a significantly increased workload. The major causes seemed to be disseminating information to their users, fielding enquiries about the virus and getting and installing anti-virus updates.

3.2 The Love Bug

Parallel surveys were conducted in May 2000 among AusCERT members and the Systems Administrator's Guild of Australia (SAGE-AU, http://www.sage-au.org.au) members. The results from the parallel surveys were similar. As with the Melissa survey, it is likely that both of these groups are more likely to be security conscious than the wider Internet community as a whole (for example, having in place proactive computer security measures such as virus scanners, monitoring security bulletins and so on) and the results may be somewhat at odds with a less security-conscious audience. The observations below are based on the combined results of these surveys.

A total of 151 responses were received. Approximately 29% of responses originated from identifiably commercial organisations (based on second-level domains), 38% from educational institutions, and the balance fairly evenly spread among government agencies, Internet service providers and others.

Approximately 50% of sites were infected by the virus. Sites that were infected in general felt that the impact was minimal (0-10 systems), with 13 responses claiming significant impact (10-100 systems) and only two responses claiming a major impact. Less than 10% of respondents suffered inoperable mail servers due to infection.

The majority of respondents stated that losses incurred were less than $1,000, with only 19 respondents estimating losses between $1,000 and $10,000, eight respondents estimating losses between $10,000 and $50,000, with only two respondents estimating losses greater than $50,000.

Comments in the survey indicated that the losses were due to labour costs in addressing the threat. There were no comments directly linking losses to leakage of intellectual property or lost opportunity due to unavailability of systems.

A range of technical measures were mentioned as reasons why infections were low or non-existent. In a number of cases the use of UNIX systems as mail hubs and/or workstations mean that those systems were not vulnerable. Filtering software at mail hubs (both UNIX and otherwise) was also found to be an effective defence mechanism that could be speedily configured for specific characteristics of suspect messages. Some sites noted that the use of mail clients other than Outlook was also helpful in avoiding infection. Finally, a very common technical measure was the use of anti-viral software.

One survey question asked respondents how long it took between the time they first attempted to obtain an effective anti-virus update and when they finally obtained one.

Of the respondents to this question, 24% obtained updates within five minutes of their first attempt to obtain updates, 26% respondents within an hour, 18% within four hours, 8% within eight hours, 11% within 24 hours, and 12% experienced more than a 24 hour delay. There were a small number of comments about the response from anti-virus vendors, expressing mixed sentiments. Some sites suggested that the response was good. However others expressed frustration with both slow availability and poor results from the software when implemented. The positive and negative sentiments appeared to be reasonably evenly spread.

There were also mixed comments with respect to the damage avoided due to respective user communities. On the whole, comments appeared to indicate that user communities within the various organisations were very responsible and that prior awareness and/or notification during the outbreak were instrumental in preventing significant damage. While there were some organisations experiencing problems due to user naivety, the comments in general expressed a positive outcome. This is a sign that user education is crucial in addressing these kinds of incidents.

Impressions on the effects of media reporting were the one area where the numbers returned were significantly different, although the supporting comments were very similar.

In the SAGE-AU survey, around 62% of respondents felt that the media had no effect on the organisational response to the incident. Some sites (13%) found the media focus to be a hindrance, while the other respondents (25%) found the media exposure helpful.

However the AusCERT members told a different story. Around 29% of respondents felt that the media had no effect on the organisational response to the incident. Only a small number of sites (3%) found the media focus to be a hindrance, and the vast majority of respondents (68%) found the media exposure helpful.

Despite these differences, the comments expressed similar sentiments. In some cases the sensationalism contributed to anxiety at a number of levels (including senior management) which impeded response. Several respondents noted that the widespread exposure contributed to an increase in conversational communication either in person, on the phone or via email, and processing these conversations required a significant period of time. Additionally, inaccurate portrayals of particular circumstances caused some disappointment within some circles.

The positives from the media exposure were centred around the raised awareness that was created. This assisted in helping users understand what they should and shouldn't do. Further, the greater awareness throughout organisations helps provide a greater understanding for the need to implement proactive, technical safeguards ahead of time.

4. Conclusions

There are a number of conclusions that the Internet community can draw from these experiences. They are listed below in the subcategories of People, Process and Environment. It is expected that this is the categorisation that will best assist in understanding, rather than the more simplistic event based categorisation. (The subcategory Environment refers to the business environment and other environments within which the organisation must operate, rather than the ecological environment.)

4.1 People

Curiosity still kills the cat.

One of the reasons for the Love Bug's success was the social engineering aspect. Put simply, people were enticed by seductive messages. Technical defensive measures will always struggle to overcome human nature.

Sophisticated users can buy time in an emergency.

Technical defensive measures are useless without the support and education of humans. Users are called upon to become increasingly sophisticated with their use of this technology, and to a significant extent responding well. Many non-technical people are very capable with the use of electronic mail; yet what proportion of these users would have used e-mail 10 years ago?

There is a need for this sophistication to increase. In the case of the Love Bug, people knew to look for a particular subject line. However a better long-term strategy is to educate users to recognise more subtle warnings and to avoid risky behaviour even before warnings are issued. A sophisticated user base can buy a lot of time while technical countermeasures are being implemented.

Feedback from the surveys provided a clear indication that savvy users are a critical factor in minimising the effects of a computer virus. There is some anecdotal evidence that the level of user awareness is rising, but continued vigilance and evangelical efforts are still required.

4.2 Process

Feature-rich is not always more desirable. Use equipment suitable for the purpose.

Melissa and The Love Bug exploited the existence of several features offered by application packages. Some organisations will have a very specific need for these features. However this is almost certainly not the case for all infected organisations. One of the basic cautionary practices that organisations should have is that if a feature is not required, then either do not install it or if installation is mandatory, make sure it is turned off. Not all organisations are able to omit or disable particular features. In these cases there are options:

Use intense content filtering prior to delivery. This is an attractive option as it can reduce the dependence on user awareness. Some organisations report that they trap any mail attachments with any executable code. There is a delay in mail delivery, but it does have the benefit of helping to prevent, for example, attacks where the user only needs to read the message (and not actually open the attachment) for the attack to be successful.
Enable a feature on a case by case (e.g. message by message) basis, with the feature turned off again when not required. Examples include the Windows Scripting Host and application macros, and web-based executable content such as Java and Javascript.
Generate similar functionality on a platform that is not at risk. For example, some types of office applications are being developed for an array of UNIX based operating systems. While there have been some MIME-based attacks for UNIX platforms, they are rare.

Any option taken will be a function of the organisation's risk assessment and management.

Convenience and ease of use does not equate to lowest Total Cost of Ownership.

When evaluating IT equipment, the best option can easily appear clear-cut for many valid tangible reasons. However, once delivery has been taken of equipment, there are costs associated with maintenance, and these can be non-trivial. In many cases, particular software and hardware solutions may seem very cheap during the initial capital outlay. However the evaluation process should include at least the following issues:

How easy is it to update and configure the operating system, and how granular is this control?
What is the vendor's track record with the emergence of security issues?
How fast are they to respond to these issues?
How easy is it to obtain patches and install them?
What are the effects on other software on the system? On system availability?
Are there any patches that introduce incompatibilities with other patches or software?
Is the vendor's attitude "fix on fail" or "fix before fail"?

The market will get the security it asks for.

Software vendors are natural targets for the anger of victims when they suffer an incident. AusCERT's experience is that a range of vendors have at various times been targeted for criticism due to implementation errors or configuration choices that have led to security incidents.

In some cases this criticism is justifiable. However, there is another dimension to this problem.

The software business, both operating system and application, is very competitive. There are pressures on vendors to be first to market, to offer feature-rich software that is interoperable with other common packages, and to ensure maximum convenience for users. Their performance in these areas feeds into the bottom line and therefore affects the viability of the vendor's business.

Lost in this complex equation is the demand for security. Many organisations (rightly) want robust systems that are or can be installed with a secure configuration by default. However if this desire isn't expressed by the client organisation to the vendor as a purchasing criteria, then it is unlikely that the vendor will be motivated to make any changes that threaten the other purchasing criteria outlined above.

Anecdotal evidence from years of quietly expressed frustration among technical staff suggests that the desire for secure default configurations is a growing sentiment. However this sentiment must be explicitly expressed as a purchasing criteria by potential purchasers in a form that the savvy vendor can use as a marketing tool and an edge in potential sales.

Vendors will always have demands to produce software that is convenient straight off the shelf. A feature that security conscious sites may wish to request is a simple installation interface that allows for different secure levels of default installation. The types of variables that may be affected by such a feature might be default accounts, command or feature availability and power, and the availability of some network services, for example. The choice of requirement is then thrown to the client site.

Not all attacks can be repelled.

Not all attacks can be completely repelled. The DDOS attacks were based on consumption of resources from an external source. This means that no matter what steps a potential victim takes to defend itself, any increase in capacity may be matched by an attacker attacking this capacity from a domain beyond the control of the victim. Melissa and The Love Bug were very different. These tools exploited a configurable feature within the application suite of the victim machines. The implications here are that the problem could be completely repelled by the victim organisation within a domain controlled by it.

Preparation for defence against potential attacks is essential.

Organisations should ensure that all software is subject to regular backups and that maintenance cycles are regular and complete, including application of patches. It is perhaps even more essential that data backups are very regular - incremental backups on important servers may take place hourly, for example. Additionally, organisations should negotiate with network service providers ahead of time to ensure that adequate controls can be implemented rapidly in the event of DOS attacks.

A layered defensive strategy is essential.

Technical defensive measures are very important and are often a front line of defence. Technical defensive measures must be implemented in layers and making use of diversity, rather than reliance on a single silver bullet.

Over-reactions can cause harm.

Melissa and initial versions of The Love Bug did not exhibit mutating behaviour. Some reports occasionally confused the idea of variants with the idea of mutation. This is very important. A virus or tool with static content is much easier to identify than one that changes its appearance with propagation. One of the reasons why NewLove was a potentially more serious problem than the Love Bug is because it had a mutating function which made it potentially harder to detect. When organisations evaluate the threat of a particular attack tool, this is one of the questions that must be considered.

In an environment of hysteria or misinformation, it is very easy for suspected behaviour to be "confirmed" without evidence, for threats to be overemphasised, and for rumours to be regarded as fact. Be wary of basing threat assessments on information delivered by a non-technical messenger.

In determining the level of threat and appropriateness of response, its important that staff who are able to understand the technical issues are consulted before committing to any course of action.

For example, a number of organisations shut down mail hubs for various periods of time. While such short-term outages are a reasonable step while technical measures are implemented, they are an over-reaction if implemented unnecessarily or on a long-term basis. It can send negative messages to potential clients and partners.

Defensive implementation strategies have trade-offs.

A problem that can occur is that viruses can infect an array of servers and workstations.

For example, assume that an organisation has been infected by a virus, and that anti-virus software is installed on each system. The anti-virus software must be manually updated in each case. During the manual process of cleansing all machines, it is possible that re-infection of a server can occur from a naive user using a still-infected workstation. This makes widespread re-infection of cleansed machines a distinct possibility.

This simple example demonstrates the trade-off that all organisations must make - in this case a trade-off between risk and performance. The organisation in question presumably made the choice to run anti-virus software on each workstation because of performance reasons or because of the possibility of introducing the virus through a non-centralised path (eg an infected floppy disk or unsafe network client).

There are several ways to attack this problem.

If anti-virus software is installed on all systems, there is a painful manual cleansing and updating process that must take place. During this time, the only protection against further infection is user education or system unavailability.
A second alternative is to use memory-resident anti-virus software in a central location, which can introduce performance issues. It may also not cover non-centralised paths of infection.
A third alternative is to introduce a more centralised operating environment where execution of software can only take place on a server farm. This introduces capacity issues and a potential single-point-of-failure.

There is no single correct answer, just the option that best suits organisational process.

Digital signatures can be an important defence strategy.

If your mail recipients understand that all trustworthy mail from your site is digitally signed and they receive mail from you that hasn't been signed then this should arouse suspicion. This makes an assumption that digitally signing a message requires a manual action on the part of the user (such as entering a passphrase). If this assumption is valid, then three new guards against these kinds of attack come into play. First, if a user is requested to sign an outgoing message that was automatically generated by some kind of virus, then this should trigger suspicion. Second, if a user receives a message that may have been generated by another organisation indiscriminately as a result of this virus, then the absence of a signature should arouse suspicion. Third, forged messages are also caught.

4.3 Environment

A reporting and coordination facility is essential to obtaining the complete picture.

Many organisations are interested in obtaining war stories and damages estimates. However, many of these organisations (understandably) also have no desire to confirm their own situation to the outside world. Nevertheless if the Internet community is to learn from collective mistakes, a candid, trusted and universal facility for collating and reporting experiences is necessary.

Its role must be to gather information about specific incidents (either localised or widespread), the impacts of these incidents, and any emerging trends. It must be capable of coordinating effort and acting as a collation and analysis centre.

This argument is not meant as some type of obscure sales pitch for AusCERT's services. Although this is in fact one of the roles that AusCERT fulfills, it is nevertheless clear from anecdotal evidence that there is a demand for information about wider community experience.

Rapidly produced damages estimates should not be taken as authoritative.

It was notable in the case of The Love Bug that damage estimates were first raised within 24 hours of the first reports of infection. These estimates ran into the millions. When damages bills such as these are circulated so quickly, readers are entitled to ask two questions. First, what method was used to provide the estimate, and how reliable is that method. Second, what is the point of giving a damage estimate when the event is clearly still in progress?

The surveys conducted in the aftermath of the Love Bug indicated that among the 150 sites responding, the losses were likely to be under $1 million. It would be interesting however to revisit this question at some stage given the findings of the 1997 Computer Crime and Security Survey, carried out by the Office of Strategic Crime Assessments and the Victoria Police ([ OSCA97]). The survey found the following: "The costs of computer misuse were surprisingly low, with 77% of respondents estimating the total direct or indirect cost of incidents at under $10,000. This prompted a follow-up study with selected respondents which identified that the IT managers of organisations were not necessarily in the best position to estimate the full cost of computer abuse. For example, one bank estimated in the survey the total cost of computer misuse for the past twelve months at less than $10,000. However the compliance and fraud control officer at that organisation felt that 'a figure in excess of $500,000 would be more realistic.' Similarly, in follow-up discussions, a communications company and a university both estimated the real cost of computer abuse to each of their organisations to be close to $1 million for the past calender year."

The main point to draw is that damages are unlikely to be accurately estimated during the course of an incident for several reasons. Accurate damages estimates are likely to be possible only in the calm environment after an incident using an agreed methodology. Readers are therefore encouraged to regard estimates in an environment of hysteria with a grain of salt.

Hysteria does not always accurately represent the true threat.

Most of the notable events outlined earlier generated significant media coverage with varying amounts of hysteria. Using AusCERT's own media call logs as a metric, the Love Bug produced the greatest focus of attention, followed by Melissa and then the DDOS attacks. The number of media calls AusCERT logged for the Love Bug was twice the number of media calls for Melissa. Yet of these three attacks, the DDOS attack is the only one without a definitive solution. Additionally, Melissa was the attack with the greatest potential risk to individual organisations by virtue of the potential for confidential information leakage. The Love Bug event was notable for speed and volume, and less so for risk and complexity. This indicates that the intensity of public focus is not always a true indicator of a problem's importance.

Accurate and reasoned discussion is necessary to avoid worst case scenarios.

The consequences of the Love Bug and possibly also Melissa could have been much worse. Two important elements in reducing the threat were the length of warning prior to South East Pacific business hours, and the improving level of user education in these issues.

This highlights a very important and responsible role for organisations such as AusCERT and the media. Peddlers of Fear, Uncertainty and Doubt (FUD) produce confusion or disbelief when faith and speed are required. Organisations such as AusCERT and various media outlets are relied on to produce timely and accurate information so that potential victims can avoid becoming actual victims.

This role can only be fulfilled if the threat (whether profound or moderate) is accurately represented in reports. Sensationalised reporting is likely to grab attention in the short term, but over the long term the sensationalist reporter is likely to become less credible. Further, non-technical managers relying on this type of information may institute measures that are over-reactions, thus making a problem potentially worse. Finally, the situation may become even more clouded when the agency reporting a problem has a solution to sell. Ultimately, sensationalist reporting does a disservice to all parties if the reporting agency is in a position to pass on valuable information to a wide audience.

Public respect is gained by reporting agencies when they provide a reasoned assessment of a problem. This means that if a threat exists, but it is a lesser threat, then this should be stated. At a later stage when an important threat emerges, the public is likely to take notice of a particular reporting agency if it is well known that that agency is conservative in its comment.

On the other hand, habitual hysterical reporting leads to two dangers. The first is that important morsels of information can be lost in the extra traffic created by the hysteria during a particular incident. The second is that at some later stage, the public will ignore an agency with lost credibility when it has something important to say.

A responsible attitude to reporting by all agencies, whether they are vendors, media outlets or other kinds of agencies, will contribute to public respect and timely response when real emergencies arise.

Gossip helps no-one.

While many names are bandied around as victims during these types of events, generally those reporting names have little or no direct knowledge of a successful attack. Likewise, inaccurate technical information is sometimes reported. Reckless name dropping and technical assessment only adds to the hysteria.

Precision in problem descriptions is important to an effective solution.

There is not always good understanding of the technical meaning of terms such as virus, worm and so on. While to the non-technical reader this is purely semantic, there are important differences that are significant to the technical community. Misuse of this nomenclature can produce confusion in situations where clarity is required.

Hacktivism and Information Warfare are realities of Internet life.

The rise in hacktivism (ie attacks against computer networks for political motive) over recent years and the possible targeted nature of the DDOS attacks demonstrated that targeted information warfare (IW) is a possibility. It is unlikely that a major coordinated attack against multiple infrastructures will be possible without significant effort and without an array of tools. While particular sites or particular sets of platforms may fall victim to a single tool due to homogeneity, the diverse nature of national networks an infrastructures on the whole will require a range of tools. Furthermore, there is still a reliance on configuration issues to an extent. While a national IW effort is less likely, it is certainly to be expected that hacktivism in the form of DOS attacks and viruses will continue to occur ([DENNING]).

5. References

[AUSCERT-1]: International Y2K Workshop, Cyber Infrastructure and Malicious Expectations during the Y2K Transition Period , October 1999. Available on line: http://www.auscert.org.au/Information/Y2K/y2k-cyberthreats.html.
[AUSCERT-2]: AusCERT, Distributed Denial of Service Attacks , 21 February 2000. Available on line: http://www.auscert.org.au/Information/Auscert_info/Papers/ddos.html.
[DENNING]: Denning, D., Cyberterrorism - Testimony before the Special Oversight Panel on Terrorism Committee on Armed Services U.S. House of Representatives , 23 May 2000. Available on line: http://www.cs.georgetown.edu/~denning/infosec/cyberterror.html.
[MS99-032]: Microsoft Corporation, Microsoft Security Bulletin (MS99-032): Patch Available for "scriptlet.typelib/Eyedog" Vulnerability , 12 October 1999. Available on line: http://www.microsoft.com/technet/security/bulletin/ms99-032.asp.
[OSCA97]: Office of Strategic Crime Assessments, 1997 Computer Crime and Security Survey, 1997.
[SANS]: SANS, Alert: Viruses Spreading Without Opening Email Attachments , 10 May 2000. Available on line: http://www.sans.org/newlook/alerts/virus.htm.
[TREND-1]: Trend Micro, Incorporated., Trend Virus Encyclopedia - W97M_MELISSA , March 1999. Available on line: http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=W97M_MELISSA.
[TREND-2]: Trend Micro, Incorporated., Trend Virus Encyclopedia - VBS_LOVELETTER , May 2000. Available on line: http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=VBS_LOVELETTER.
[TREND-3]: Trend Micro, Incorporated., Trend Virus Encyclopedia - TROJ_LOVELETTER , May 2000. Available on line: http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_LOVELETTER.
[TREND-4]: Trend Micro, Incorporated., Trend Virus Encyclopedia - VBS_NEWLOVE.A , May 2000. Available on line: http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=VBS_NEWLOVE.A.