Latest Macro Virus Developments and Future Trends

1 Introduction

Theoretically, macro viruses were predicted in 1989 ([Highland]). It took them about six years to become a reality, though—the first macro virus, WM/Concept.A, appeared in 1995. Distributed accidentally by Microsoft on one of their CD-ROMs, it became probably the most widespread virus in the world in a matter of months—something which, by that time’s standards, could be characterized as “like wildfire”. Since then, macro and script viruses have predominated the computer virus infections around the world. Virtually all studies of macro virus prevalence (see, e.g., [Table], just as an example) show that about 75% of the virus infections are caused by such viruses. (Most of the rest is caused by Windows viruses, while the boot sector viruses and the “old” DOS file viruses have all but disappeared).

The reason for this “popularity” is because macro viruses infect documents (i.e., seemingly data files)—and people exchange data files much more often than they exchange executable files or attempt to boot from an unknown diskette. The fact that people somehow don’t expect a data file to be able to release virus and that the modern operating systems do not rely on the BIOS and have made classic boot sector viruses virtually unable to operate, only contributes to the issue.

There are other reasons as well. Writing a “classic” file infecting virus requires knowledge of assembly language (except if created with a virus construction kit or in some compiled high-level language—but the former are easily detected by the anti-virus programs and the latter tend to be large and usually of the overwriting or companion type and, therefore, have few chances to survive in the wild)—and in these days of point-and-click interfaces few virus writers can boast that.

The macro viruses, on the other hand, are written in a relatively simple high-level language—usually some variant of BASIC—and for many people BASIC is the first programming language that they learn. Furthermore, macro viruses don’t have to be disassembled or decompiled—they come, essentially, in source code form. All this makes it very easy for the virus writers to examine each other’s creations and learn from each other.

Predictably, all this (the “popularity” of the macro viruses and the ease with which they can be analyzed) has resulted in accelerated development of new tricks and techniques on the macro virus writing front. In this paper, we shall try to give the reader an overview of the major developments in the past five years and try to glimpse into what awaits us in the near future.

2 The Present

First, we shall begin with an overview of the present situation and the major developments that have lead to it.

2.1 Glut

The most trivial development—one that has always been present since computer viruses exist—is the glut. This means more and more new viruses being created, at an increasing speed. For the five years since they first appeared, the number of macro viruses reached about 7,000 and its increase shows no sign of reduction. There are three main factors contributing to this—genuine creation of new macro viruses by the virus writers, creation of new macro viruses by the many macro virus construction kits in existence, and automatic virus creation due to various bugs and peculiarities of the macro supporting environments.

2.1.1 Virus Writers

One of the major sources of new viruses is, of course, the virus writers. There are several factors contributing to the fact that many people began creating new macro viruses.

First, just the fact that a virus becomes “popular” (i.e., widespread and “talked about”) attracts many virus writers and tempts them to create copycat variants.

Second, since the macro viruses are a relatively new area, there is still a lot to explore there; a lot of things to be done “for the first time”. This tends to attract another subset of virus writers who are tempted to explore and be the first to implement a particular new trick.

Third, the fact that a virus is widespread means that more people are likely to discover it—and some of them are likely to “play” with it, creating new variants sometime unintentionally—by trying to deactivate the virus, or by accidentally changing something in it.

Fourth, macro viruses are written in different dialects of BASIC (a very simple programming language known by many people) and come essentially in source code form. This means that they do not require any particular effort to disassemble or decompile and are easier to understand. This consequently means that even people who did not have the knowledge and experience to create a “classic” file-infecting virus in assembly language could easily create a macro virus. (Still, there are many wannabe virus writers who are so stupid and ignorant, that they are unable to write even a working macro virus. We have seen many macro programs, clearly written in the intent to create a virus, but too buggy to work—something which their author has failed to notice, being too afraid to run his own creation on his machine even once. We call such pseudo-viruses “Intended”.)

2.1.2 Virus Construction Toolkits

Another major source of new macro viruses is the macro virus construction toolkits. They are programs (usually, but not always, implemented in the same macro language) which are not viruses themselves but which can generate new macro viruses. Creating new viruses with them is extremely easy—it is usually just a matter of selecting a few options from a point-and-click graphical user interface.

Some kits create the viruses only in source form; in a text file—and the virus author has to “revive” the created viruses manually, by inserting their source as a macro in a document. Other kits create readily infected documents.

Some of the most popular macro virus construction toolkits are W97M/Class and W97M/VMPCK1—dozens of known macro viruses have been created just with these two.

While the creation of a macro virus with one of the available macro virus construction toolkits is extremely easy and requires no programming experience (i.e., anybody can do it), using them is often considered “lame” among the virus writers (i.e., only the most inept of them use virus construction kits and, by doing so, they seemingly admit that they are incapable of writing their own virus from scratch). This tends to be a somehow limiting factor—i.e., relatively few people create macro virus this way.

2.1.3 Automatic Virus Creation

Due to several peculiarities of the applications from Microsoft’s Office programming suite, these applications often can generate new viruses from the old existing ones. This virus creation is entirely automatic and almost always happens without the consent of the user. There are three main ways in which new macro viruses can be produced this way—via random corruption, via code snatching, and via upconversion. We shall consider each one of them in the following subsections.

2.1.3.1 Office as an Automatic Virus Construction Kit

There seems to be some kind of bug in the Office applications—or, more likely, in the OLE2 DLLs used by them. This bug results in random corruption of the documents when the latter are edited with these applications. We don’t know where exactly the bug is or even under what particular circumstances it occurs. It happens extremely rarely, so chances are that a normal user will never observe it. Even if it occurs, the user might decide that the corruption is caused by something else (and, in most cases, it usually is)—a bad floppy disk, for instance. Or the corruption might occur in places where it will not be easily recognized as a corruption by the user and might look like user error—for instance the font with which some portion of the text is formatted might change. We could not even figure out any kind of rule regarding how large areas are affected by these corruptions—sometimes it is a single bit that changes, sometimes a whole byte, sometimes a sector (512 bytes) and sometimes a completely random number of bytes…

However, this “rare” corruption has a devastatingly different effect on macro viruses. Since BASIC is an interpreted language (and both WordBasic and VBA are just two different dialects of BASIC) and since usually a very small portion of the virus (usually a couple of lines) is directly responsible for the replication, this means that a random corruption of the virus body will result in something which, very likely, will still be able to replicate. That is, it will still be a virus. Except that it will be (slightly) different from the original one—i.e., the corruption would have generated automatically a new virus variant from the original one.

Furthermore, since viruses replicate themselves often and travel across many documents and machines, they are exposed to a much higher probability of corruption than a single, static document—and, when the corruption happens, it is preserved forever in the new virus as it moves to other documents. A good example of how often this happens is the WM/Npad virus family. This family consists of about 300 different variants, of which only a single one, WM/Npad.A, has been created by a human. All the others have been created automatically by Microsoft Word via random corruptions of the original one. Note that while this number might seem alarmingly high, it also shows us how rare the corruption is—the virus has probably replicated itself millions of times on the users’ machines (it used to be a very widespread virus) without being corrupted.

Macro viruses written in WordBasic (i.e., the WordMacro viruses) are more vulnerable to this automatic creation of new variants via random corruptions. The reason is because WordBasic programs are essentially loaded in memory as one big lump and then interpreted token-by-token. Therefore, if an error (caused by the corruption) exists after the replication code—and even if it receives control at all—the error will occur after the replication has already been performed. As opposed to that, macro viruses written in Visual Basic for Applications (VBA - the macro programming language of the Office 97 applications) are much more “capricious”. This is because VBA has much more complex internal structure than WordBasic—and a single random corruption of this structure usually results in the Office application refusing to open the document at all, let alone execute the virus. Nevertheless, VBA viruses are not “immune” to this random corruption problem either. We have received several variants, which differed from the original viruses only in some integer constant, in some (corrupted) comment, or have “True” changed to “False” (or vice versa. We are pretty confident that the random corruptions are responsible for these new variants.

2.1.3.2 Code Snatching

In a sense, most macro viruses are of the overwriting type. They replicate as a set of macros—but, if macros with those names already exist in the target document, they will be overwritten by the original ones. This property often results in the creation of new virus variants via code snatching.

There are three different kinds of code snatching. The first occurs when the target document is already infected by another macro virus. Infection of such a document with another macro virus would result in a mixture of the sets of macros of the two viruses. The new set of macros (or at least a subset of it) is often still able to replicate itself (i.e., is still a virus)—but is different from any of the original two sets (i.e., is a new virus). This effect is described in details in [Bontchev97a].

How exactly will the new virus replicate depends on the properties of the original two viruses. We can have the replication code of one of the two viruses entirely overwrite the other (while, for instance, the payload might remain that of the original virus), or the two replication codes might “cooperate” (e.g., one of them might infect documents—with the whole set of macros— while they are opened, while another might do it when they are closed). Or some of the macros of one of the two viruses might disable some of the replication code of the other (e.g., so that the new set of macros now replicates only on File/Save, while one of the original viruses replicates both on File/Save and on File/SaveAs).

The second kind of code snatching occurs when the user installs some kind of macro package in an already infected system (e.g., in an infected global template). The results are not much different from that of the first kind, except that this time one of the “participants” is not a virus and none of its parts could be responsible for replicating the new virus. They still, however, overwrite parts of it, resulting in disabling some parts of the replication code and/or payload.

In practice, we have observed this kind of code snatching occur most often with Microsoft’s macro anti-virus package. This makes sense, having in mind that the user is likely to download and install it precisely when s/he suspects to have a macro virus. That is, we will have the typical case of installing a non-viral macro package on a system which is already infected with a macro virus. And, indeed, many (hundreds) of the existing multi-macro virus variants have been created by snatching macros from this package.

The third kind of code snatching occurs when two viruses infect pseudo-parasitcally one and the same macro. In practice, we have most often observed this effect among the so-called class infectors. These are VBA viruses (usually for Word 97) which infect the special class module, which is present in every VBA project and is usually named ThisDocument. (Its name is language version dependent—for instance, it is “DiesesDokument” in the German language version of Word 97).

Again, depending on how the two viruses work, the resulting “cocktail” could look and behave very differently. In the simplest case, one of the viruses completely overwrites the other and the other is simply lost—i.e., we don’t have a different, new virus. In a slightly more complicated case the two viruses could both be present entirely—appended one after the other in the module (i.e., result in what we call a “sandwich”). We have decided to consider such cases as multiple infection (i.e., more than one virus present in the document)—not as a new virus. Finally, the “mixture” can result in one of the viruses overwriting only parts of the other but continuing to replicate the whole module further—i.e. result in a new virus. What the properties of the new virus will be depends mostly on the properties of the original two viruses and on what parts of them are present in the new one.

2.1.3.3 Upconversion

Yet another very serious problem of automatic virus creation occurred when Microsoft released Office 97 (and, later, although to a lesser extent, Office 2000). The applications of this version of Office have the ability to open documents created by the older versions and automatically convert them to the new format. Unfortunately, this conversion also covers the macros that might be present in these documents.

The macro conversion occurs without the consent of the user—s/he is not informed about it when the document is about to be opened; only when the automatically upconverted document is about to be closed does the application ask the user whether to save it in the new format. Furthermore, this conversion performs very drastic changes on the macros. Especially when WordBasic is upconverted to VBA, the resulting new program is in a completely different language, with a completely different internal representation (e.g., it is compiled instead of being just tokenized) and in a completely different place in the document. Needless to say, this usually results in completely new macro viruses being automatically created from the old ones, too. Similar changes are made when an Office 2000 application opens a document created by an Office 97 application—although then the differences are not so drastic, we have decided not to consider such viruses different, and technical means exist that allow the anti-virus programs to treat them as the same viruses (see, for instance, [Bontchev2000]).

This upconversion process and a detailed explanation of why exactly it results in the creation of new macro viruses from the old ones is described in details in [Bontchev98]. It also presents a serious dilemma to the anti-virus researchers—on the one hand, the users have the right to expect that their anti-virus programs will protect them from the upconverted viruses while, on the other hand, most anti-virus researchers have ethical problems to create the new viruses themselves (e.g., in order to implement protection against them). Again, see [Bontchev98] for a detailed discussion of this issue, as well as a set of technical methods for resolving this dilemma.

2.2 Stealth

Another area in the macro virus field, which saw significant developments during the past years, was stealth. Stealth is defined as the ability of the virus to hide itself and prevent the user from discovering it. Ideally, a system infected with a full-stealth virus should have exactly the same look-and-feel in all aspects visible to the user as an uninfected system. In the next few subsections, we shall examine these developments in details. See [Bontchev99] for an even more detailed discussion of this issue.

2.2.1 Disabling the Macro Examination Functions

For most users, the most natural way to check whether their system is infected with a macro virus is by using the macro inspection functions provided by the office applications. These functions are accessed by invoking the Tools/Macro (or Tools/Macro/Macros in Office 97 and above) dialog from the menus, by using the Organizer (accessible by clicking on a button from the Tools/Macro dialog or from the File/Templates or Tools/Templates dialog) or, in Office 97 and above, by launching the VBA Editor (by pressing Alt-F11 or selecting Tools/Macro/VBA Editor from the menus).

Naturally, the first step many virus writers took towards making their creations more difficult to discover was to simply disable these macro inspection functions. This was achieved by using basically two different sets of means.

First, it was achieved by disabling or simply deleting the menus and removing the key shortcuts used by the Office applications to invoke the macro examination functions. The environment of the Office applications is highly customizable—the presence, arrangement and functionality of the different menus, buttons and key shortcuts can be changed freely by the user—or by a macro being run by him/her (for instance, a macro virus ). There are viruses like XM/SW.A or XM/Team.A which remove more than a couple of dozens of menu items or key shortcuts of the underlying Office application (Excel 95 in these particular cases) in order to make macro inspection more difficult.

Second, disabling of the macro examination functions was achieved by having the viruses contain small macros (or, in the case of VBA, subroutines) with the same name as that of the system functions—ToolsMacro, FileTemplates, ViewVBACode—and having them do nothing or simply display some kind of error message intended to fool the user that the respective macro inspection function is temporally unavailable.

Another trick, which some macro viruses use in order to reduce the likelihood of being discovered, is to turn off various prompts of the Office applications. For instance, most applications of Office 97 have a built-in macro virus protection. That is, they display a warning dialog when the document that is about to be opened contains macros. (Regretfully, they could also display this dialog when the document does not contain any macros. This and some other annoying properties greatly reduce the practical usefulness of this “protection”.) Unfortunately, once a macro virus is allowed to run, it can easily turn off the protection, so that the warning is never displayed again. (That is, unless the user happens to notice that the protection has been turned off and figures out how to turn it back on again—something which is not very likely.

Similarly, Word can be configured to display a warning and ask whether to save a modified global template—it could be modified because a virus has just infected it, for instance. However, this, too, can be easily turned off, so that the warning never appears—and many existing viruses take care to turn it off as a matter of course.

2.2.2 Spoofing of Macro the Examination Functions

The second of the methods described in the previous subsection can be taken easily and naturally one step further. As we already mentioned, the environment of the Office applications is incredibly flexible and programmable—and all this flexibility and programmability is fully available to the macros (and, in particular, to the macro viruses) running in this environment.

One of the things a macro can do in this environment is to construct and display almost any kind of Windows dialog. Therefore, it was only natural that the virus writers have created viruses which intercept the attempt of the user to invoke the Tools/Macro dialog and spoof the look of this dialog almost perfectly—except that, of course, they make the fake dialog claim that there are no macros in the infected document.

This dialog spoofing has several limitations, although they are not immediately obvious to the unsuspecting user. First of all, the original Tools/Macro dialog has rather rich functionality. It can be used not only to see what macros are present, but also to delete and run them, to examine different global templates (or all of them simultaneously), to start the macro editor in order to create a new macro or edit an existing one, to change the description of a macro, or to launch the Organizer dialog. It is too difficult for the virus writer to emulate each one of these functions perfectly (while still hiding the original macros of his virus as if they are not present). This is why, in most cases the buttons of the spoofed dialog either do nothing or display some kind of error message (except the Cancel button which closes the spoofed dialog, just as the corresponding button does with the original dialog).

Second, the spoofed dialog often suffers of different kinds of imperfectnesses, if the virus writer has been too floppy to make a perfect copy of it. For instance, it could be of different size and proportions—especially if it was constructed by the virus writer on a machine with a different screed resolution size that that which the infected user machine is currently using.

Third, the dialog is static, while the virus containing it can move to very different environments. In particular, if a virus carrying an English Tools/Macro dialog infects a German language version of Office (or vice versa), the dialog will look very different from the original one to the user of that version of Office.

2.2.3 On-the-fly Disinfection

In the DOS virus world, some of the best stealth viruses can be completely “invisible” in the infected objects if these viruses are active in memory. They achieve this by intercepting all access requests to the infected objects and by modifying the result returned by those requests in such a way that the objects look virus-free to the issuer of the requests. The same idea can be implemented even simpler (and some viruses do just that)—as soon as an access request has been intercepted, remove the virus from the infected object, wait for the request to finish and re-infect the object.

Some macro viruses have successfully implemented the latter idea. They are only VBA viruses, because a WordBasic macro cannot delete (or even rename) itself while it is running. VBA macros, however, can, and several VBA macro viruses are using this approach.

Some of them go for a more simplistic implementation of this idea. When the user attempts to invoke one of the macro inspection functions (e.g., the VBA Editor), such viruses simply remove themselves from the infected document. Naturally, this prevents them from spreading further—but, obviously, their authors consider this a fair price to pay for reducing the probability of detection. After all, relatively few users will suspect that a macro virus is present and will try to use the macro examination functions (even if they know how to do it—which most users do not) so, most of the time, the virus will spread just fine.

Other viruses are much more sophisticated, though. One of them, when it detects an attempt to launch the VBA Editor removes itself from the document—but remains running in memory. It allows the user to do normal work by using a primitive form of multi-tasking (via the extensive use of the DoEvents primitive) and, simultaneously, keeps checking whether the VBA Editor is still in use (by inspecting the contents of the Application.ShowVBAEditor variable). As soon as this is no longer the case, the virus immediately re-infects the document.

2.2.4 Infection of Unusual Places

Another set of tricks used by the macro viruses in order to reduce the likelihood of them being discovered by the user is to reside in places where the user is unlikely to look. There are three main approaches to this that are currently in use—keeping the virus in a non-standard global template in the STARTUP directory, using remote templates, and class infection.

2.2.4.1 The Word STARTUP Directory

The first macro virus that appeared, WM/Concept.A, stored itself on the infected system in the global template—the file named NORMAL.DOT which resides in the Templates subdirectory of Office—and infected documents from there. Indeed, this file is the natural to store user-installed (or, in this case, virus-installed ) macros on the system—so that they are always available. This idea was later plagiarized by so many viruses that the users were incorrectly lead to believe that the file NORMAL.DOT was the only place where the virus could hide itself on the infected system (besides the infected documents, that is); that by deleting this file the user could get rid of the virus and that by write-protecting it in some way s/he could prevent a virus from ever infecting the system. Unfortunately, this is not the case—and the virus writers were quick to discover that.

When Microsoft Word is started, it examines the contents of the STARTUP subdirectory of Office. If any files with the extension .DOT are found there, Word opens them and treats them as alternative global templates. That is, all fonts, styles, menus, etc., including macros that reside in these files become automatically available to the Word environment. A macro virus residing there could infect documents exactly as well as a virus residing in the “conventional” global template. At the same time, few users (or even few professional macro packages) make use of the STARTUP directory (most of them just use the normal global template)—so, few users are aware of it and few users would be likely to look there for viruses.

Some macro viruses have developed this idea even further. They not only reside in an alternative global template in the STARTUP director but even change the location of this directory (this can easily be done from within Word). So, even if the user knows about the STARTUP directory and looks in the place where s/he thinks it resides, s/he will only find an empty directory while the virus will reside elsewhere.

2.2.4.2 Non-Standard Global Templates

The second idea has to do with where the virus resides in the infected documents (as opposed to where it resides in the infected system, which is what the previous idea was about). Most macro viruses go the obvious way and simply store their macros in the infected documents. There are less straightforward approaches, though—and some viruses have opted towards them in order to reduce the chances of discovery.

Every document created by Microsoft Word is based on some template. Usually this is the global template (the file NORMAL.DOT)—but it can be any template, residing anywhere on the system. Information about which template a document is based on is kept within the document itself and can be found by selecting the Tools/Templates dialog from the menus of Word. If the template a document is based on contains macros, these macros become available to the system as soon as that document is opened—pretty much the same way as if they resided in the document itself.

Some macro viruses use this fact on infect documents in less obvious ways. Instead of storing themselves in the documents, these viruses store themselves in a template file and then “infect” documents by specifying that these documents are based on the template containing the virus. We call this kind of macro viruses companion macro viruses.

This approach has one significant drawback (from the point of view of the virus writer)—such viruses are difficult to spread from one machine to another. With conventional viruses, it is much easier for the unsuspecting user to pass an infected document containing the virus to another unsuspecting user. With companion macro viruses, it is much less likely that the user will pass the template containing the macro virus together with the “infected” document when sending this document to another user. In addition, if the template a document is based on does not exist, Word will simply use the global template.

A significant improvement of the above idea was the use of remote templates. It is not a well-known fact, but with Word 97 and above the specification of the template a document is based on does not necessarily have to be a file. It can just as well be an URL like http://www.attacker.com/virus.dot. When such a document is opened, Word will use the machine’s Internet connection to fetch a copy of the file VIRUS.DOT from the location specified by the URL and will use that copy as the template the document is based on. So, a few viruses were written (for instance, those of the W97M/Nail family) according to this idea. The attacker would put the macros of the virus in some template available from some Web site and would make them “infect” documents by making them based on this remote template.

This idea has several advantages from the virus writer’s point of view. First, it guarantees that just passing an “infected” document to another user will result in the infection of that user’s machine. No need to pass simultaneously another file (the template which the “infected” document is based on)—because this file is always available through its URL. Second, it is much more difficult for the user to find and examine the virus—because it does not reside in the “infected” documents and remote copies of it are only temporarily fetched (into temporary files) when the “infected” document is opened. Third, the virus writer can easily modify the behavior of the virus in all “infected” documents all over the world just by changing the file at the Web site. Fourth, this kind of infection presents serious problems to the anti-virus programs. Few of the on-demand scanners can even detect the fact that a document is based on a remote template—and even fewer would go as far as top fetch the remote template specified in the document and scan that for viruses when scanning the document. Fifth, the built-in macro virus protection introduced by Microsoft in Word 97 which is supposed to trigger when a document containing macros is being opened does not activate if the document being opened does not contain macros but is based on a template which contains some. This is a bug, which has been fixed in a patch to Office issued by Microsoft—but it is not very likely that too many users would have this patch installed.

However, the idea has disadvantages too. First of all, it is rather obvious. When Word fetches a local copy of the remote template, it displays a small dialog box. While this dialog disappears soon and all by itself (i.e., without the user having to click on any buttons), it is nevertheless difficult to miss. Furthermore, if the user is connecting to the Internet via a dial-up line and is not on-line when opening an “infected” document, the Dial-Up Networks dialog of Windows will pop up—and that one is certainly hard to miss and is likely to raise the user’s suspicions. So, such a virus is not very “stealth”, after all—just the opposite, it is a rather obvious one. Second, since the virus physically resides only at a constant, known location on the Web, it can easily be removed from here and the site carrying it—shut down. Therefore, viruses relying extensively on this idea do not have great chances to become widespread.

2.2.4.3 Class Infectors

Probably the most successful one among the “infect unusual places” idea in the macro virus world was that idea of so-called class infectors. These are macro viruses written in VBA and which keep their code not in regular VBA modules but in the so-called class modules. More particularly, such viruses usually keep their code in the class module, which is usually named ThisDocument.

This class module is present in every document that contains a VBA project. The name of the module is application– and language version-dependent. For instance, it is “ThisDocument” in the English language version of Word 97, “DiesesDokument” in the German language version of it, “ThisWorkbook” in the English language version of Excel 97 and so on. However, at least in Word 97 and above, this module can be addressed in a language version independent manner by using its number instead of its name. It is always the module number one in the Word documents that contain VBA projects and can be addressed by using the VBA expression Me.VBProject.VBComponents(1) or ActiveDocument.VBProject.VBComponents.Item(1).

Using this module offers many advantages from the point of view of the virus writer. First of all, the fact that it can be addressed in a language version independent way allows a class infector to work successfully in any language version of Word. Therefore, a class infector is much more likely to become widespread worldwide than a virus that uses regular modules.

Second, macro viruses which reside in class modules have access to many additional activation methods—while still enjoying the activation methods available to viruses that reside in regular modules (auto macros, system macros, menu interception, key shortcut interception, button interception; see [Bontchev96] for details), class infectors can also intercept system events such as Document_Open, Document_Close, Workbook_Activate and many, many others. In addition, while the automatic execution of, say, the auto macros can be disabled (e.g., by the means of WordBasic.DisableAutoMacros), the activation of the event handlers cannot be similarly disabled.

Third, if the subroutines of the virus are declared Private and reside in a class module, they will not be visible in the Tools/Macro dialog. Even when the document is inspected with the VBA Editor, the ThisDocument class module is listed as “Microsoft Word Object”—not as a “Module”, which makes it less likely that the user will discover what is in there.

Fourth, at the beginning many anti-virus programs had problems disinfecting class infectors (in fact, many of them still have such problems). At the beginning many anti-virus producers haven’t even noticed that the class modules can contain executable code, so their products were not even looking there. Then, even after they become able to locate the class infecting viruses, they had problems removing them. Unlike regular modules, the ThisDocument class module cannot be simply removed. If it is removed and if the document still contains a VBA project (e.g., because it contains some user macros besides the virus), Word will crash when trying to open the document. Therefore, when disinfecting a class infector the anti-virus program has to overwrite this class module with an empty, clean one. Unfortunately, the contents of this empty module is different, depending on what particular kind of document is being disinfected—one created by Word 97, one created by MacWord 98, one created by Word 2000 and so on. Finally, a class infector is much more likely to interact with other class infector (as they both attempt to infect one and the same module)—therefore leading to all kinds of code snatching and pseudo-parasitic infection which again creates different identification and disinfection troubles for the anti-virus programs.

All this made the class infecting viruses extremely successful and widespread and nowadays the vast majority of new viruses created by the virus writers are of the class infecting type.

2.2.5 Other Tricks

At different times during the past few years the virus writers have discovered that tried out several other minor ideas designed to make their macro viruses more difficult to discover—or at least to understand. Among them are:

1. Starting the virus module with a lot of empty lines and/or preceding every line in it with a lot of spaces. This makes the virus module look “empty” when examined with the VBA Editor—simply because the virus code is outside of the Editor’s window.

2. Changing the screen attributes of the code pane window of the VBA Editor to “white-on-white”, so that the virus code (as well as any other VBA program) looks “invisible” when the module containing it is inspected with the    Editor. This can be achieved by setting the Registry keys

HKEY_CURRENT_USER\Software\Microsoft\VBA\Office\CodeBackColors

and

HKEY_CURRENT_USER\Software\Microsoft\VBA\Office\CodeForeColors

to “1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1”.

• Hiding the Excel sheet associated with the virus module. If a sheet is given the attribute vbVeryHidden, it cannot be “unhidden” from the menus of Excel; it can be “unhidden” only by another VBA program.

• Using different kinds of encryption of the virus body—either the default one of WordBasic by copying the macros of the virus as execute-only, or by programming some more sophisticated encryption of most of the body of the virus and decrypting it on-the-fly at runtime, as most viruses in the W97M/Lys family do.

• Protecting the VBA project or the macro sheet containing the virus with a password. This is not a problem for ExcelFormula viruses (i.e., macro viruses written in the programming language of Excel 4.0) but, normally, a VBA module residing in a password-protected VBA project is not allowed to copy itself. This limitation has been circumvented in the X97M/Jini.A virus by having the virus copy the data (i.e., the sheets of the workbook in this particular case; it is a macro virus for Excel) from the target document to the one containing the virus and then overwriting the target document with this copy.

2.3 Polymorphism

Programs which detect known viruses (scanners) are the most widely used kind of anti-virus programs. This is so because they are easiest to manage and because their output is most understandable by the average user. Not surprisingly, they are also the kind of anti-virus programs most often attacked by the virus writers.

One of the most effective form of attacks against scanners is polymorphism. This is the ability of a virus to modify itself as it replicates—so that each replicant of it looks different. Since scanners work mostly by looking for some part of the virus which is one and the same in all infected hosts, not having such a part makes a virus very difficult to detect with a scanner.

Many forms of polymorphism have been developed by the authors of DOS viruses. It is only natural that many of the same ideas have been used by the authors of macro viruses as well. In fact, this is a field, which is still in active development. Much more complex things can be achieved in the macro programming languages (and especially in VBA) than in assembly language—and they can be achieved much more easily in those languages than in assembly language.

In the next few subsections, we shall consider the basic methods developed for use in various macro viruses over the past few years. They can    be divided into two major groups—insertion of “dead” (do-nothing) code and code scrambling.

2.3.1 Do-Nothing Instructions

The simplest way to make a virus polymorphic is to intersperse its body with instructions which do not affect its behavior in any significant way and then change these instructions with other, equivalent ones, each time the virus replicates.

2.3.1.1 Variable Comments

The simplest piece of code that does not affect the execution of a macro in any significant way is the comment. Therefore, it is not surprising that some of the first polymorphic viruses interspersed their bodies with randomly-generated comments that were re-generated each time these viruses replicated.

Some of the typical examples are some members of the W97M/Class family. Every second line in the body of the virus is a randomly generated comment. Both Rem-style and apostrophe-style comments have been used and the contents of the comment can be generated in many different ways—from a totally random string of characters to seemingly meaningful but often varying things like the current date and time, the name of the document, the name of the system’s printer, the name of the user, and so on. Although it doesn’t really matter much from the point of view of virus detection, the latter methods often provide useful information to the anti-virus researchers, allowing them to trace the infection back to its origins.

This polymorphic method became so popular among the virus writers, that many anti-virus products simply ignore the comments in the macro viruses as a matter of course—this way such viruses look non-polymorphic to them.

2.3.1.2 Variable Statements

A significantly more advanced polymorphic method is to intersperse the body of the virus not with lines which do nothing (as described in the previous subsection)—but with seemingly meaningful lines which simply do not affect the basic algorithm of the virus.

Again, some typical examples of viruses using this method can be found in the W97M/Class virus family. An “easier” implementation of this method has every second line of the virus looking like this:

<identifier1> = <identifier2> + <identifier3>

where all the identifiers are randomly generated every time the virus replicates. This method is “easier” because the anti-virus program could simply assume that these lines are part of a virus that is using the “variable identifiers” polymorphic method described in section 2.3.2.1. That is, by simply ignoring the identifiers (something very easy to do for VBA viruses) the anti-virus program can make all replicants of such a virus look the same (i.e., non-polymorphic) to it.

Unfortunately, things that are much more devious are possible. Some other members of the W97M/Class macro virus family mentioned above use a slight variation of this method. Every second line in them is a sum of randomly generated identifiers, assigned to a randomly generated identifier. Except that, unlike in the above example, the number of such identifiers is random—not fixed. For instance, one such line could read

R = QfHLy + NqVCf + NsDKv + VxAHn + UoISh + OkVHp + JkDJo + L

while the next could be

J = BkLMv + KjQIg + QyNPz + I

and both the identifiers and their number would change as the virus replicates.

This results in significant changes of both the size and the look of the virus—and makes it much more difficult for the anti-virus programs to identify such a virus correctly. In fact, few do so successfully nowadays—most use some generic scan string which is picked from a single line. Since the lines of the virus themselves do not change—only the do-nothing lines do—it is possible to pick a scan string from one of them and it will remain constant. That is, it will be found in all instances of the virus—only at different places.

An alternative approach is for the anti-virus programs to do some kind of trivial parsing of the virus code and to ignore the assignment operators when identifying the virus. Unfortunately, this approach has its drawbacks too. First of all, they run the risk of ignoring some assignment lines in the virus that are significant—i.e., to ignore not only the do-nothing lines. Second, viruses could use many other kinds of do-nothing lines—not just assignments. In the extreme case, a virus could use do-nothing blocks like

If <condition> Then
<line1>
<line2>
:
<lineN>
End If

where <condition> is never true and <line1>,… <lineN> consist only of lines which are found elsewhere in the virus and are part of its algorithm—not do-nothing lines. (See also [Bontchev96] for a detailed discussion of this method.) This way, if the anti-virus program decides to ignore all these lines, it will end up ignoring all the code in the virus.

In the simplest case, a virus could simply use its replication line as a “do-nothing” line. It will not even have to “deactivate” it by surrounding it with an If statement with condition which is never true—because the virus will work perfectly even if its replication line is executed multiple times.

2.3.2 Code Scrambling

As mentioned in the previous subsection, anti-virus programs can still detect a polymorphic macro virus which uses do-nothing lines by picking a scan string from one of its meaningful lines. Some viruses attempt to make this approach impossible by using various forms of code scrambling techniques.

2.3.2.1 Variable Identifiers

One of the simplest invariant modifications a macro virus can do to its code is to change randomly the names of the identifiers it uses. Of course, in order not to modify its algorithm, the virus still has to use one and the same new identifier in every place where the old identifier was. For instance, replacing

X = X + Y

with

ABC = ABC + DEF

is a valid modification, while replacing it with

ABC = DEF + GHI

is not. However, it is relatively easy to fulfil this condition by using the built-in search-and-replace capabilities of the macro language. A typical example of such a virus is W97M/Bebop.A.

Interestingly, this kind of polymorphism is amazingly trivial to handle. In WordBasic, each identifier is preceded by a special token, indicating that “identifier follows”. Therefore, it is very easy for the anti-virus programs to ignore the identifiers when scanning for macro viruses written in this macro programming language.

Viruses using this polymorphic method and which are written in VBA are even easier to handle. In VBA, the identifiers are not stored in the body of the module. Instead, the identifiers of all modules are stored in a separate OLE2 stream (named “dir” in VBA3 and “_VBA_PROJECT” in VBA5 and above). The p-code instructions of the VBA modules contain operands that point to this common pool of identifiers. In fact, it takes special effort to make the anti-virus program take the identifiers into account—so, most do not. To them, VBA viruses, which use the polymorphic method described in the section, look non-polymorphic.

Since the virus writers usually have very little knowledge about the complex internal formats used by the different macro programming languages, they are also blissfully unaware that they are wasting their efforts when trying to cause trouble to the scanners by using this polymorphic method. The method is more troublesome when used in script viruses (e.g., viruses written in VBScript or JavaScript). This is so because these languages do not support the “common pool of identifiers” concept and do not mark the identifiers in any obvious way. Therefore, if the anti-virus program wants to ignore the (variable) identifiers, it will have to use some form of parser for the respective script programming language—and implementing such a parser is by no means a trivial task.

2.3.2.2 Line Splitting

One way to make scan strings less usable for macro virus detection is to split the lines of the virus at random places. This can be done by using the “line continuation” operator (“_”) of VBA. For instance, the some of the W97M/Ded viruses use this technique (alongside with inserting random do-nothing comment lines).

The virus could modify a line that originally says

I = I + 1

to make it say, e.g.

I _
= _
I _
+ _
1

Fortunately, the technique is trivial to counter, too—because the line continuation operator compiles to a particular p-code instruction that is extremely easy to ignore at a p-code level when scanning the VBA module. Anti-virus programs, which scan the compressed VBA sources in the module (instead of the p-code), have more problems with this technique—but even they can handle it quite easily.

An alternative approach, used e.g., by the W97M/Service.A virus, consists of randomly splitting and joining lines using the “line separator” operator (“:”). While this technique does present some problems to the anti-virus programs which examine the VBA modules line-by-line and perform exact identification, it cannot prevent the anti-virus producer from picking a good scan string from a single “elementary” line. Unfortunately, when combined with the previous technique, it can make the selection of such a good scan string extremely difficult—unless, of course, the scan string matching function of the anti-virus program is able to automatically ignore the line continuation operators.

2.3.2.3 Encryption

A much more sophisticated method for making the usage of simple scan strings impossible—a method also “borrowed” from the field of DOS viruses—is the extensive use of encryption. Here by “encryption” we do not mean the trivial encoding used by WordBasic macros when they are copied as “execute-only”—or the similarly trivial encoding used by Encoded VBScript and Encoded JavaScript (the latter two available with the Windows Scripting Host versions 5.0 and higher). These encoding methods are trivial to break—but that is not necessary anyway, because they always encode one and the same program to one and the same thing, so a scan string can be picked from the encoded body of the virus without having to decode it first. By “encryption” we mean that the virus itself scrambles its own body in some way with a variable key—so that the different keys result in different encodings for one and the same program. One typical example of a macro virus using this technique is the W97M/AntiSocial family of macro viruses.

Of course, the usage of non-standard encryption methods means that the virus has to have some part of its body unencrypted. The purpose of this part is to receive control at runtime and decrypt the rest of the virus. This part can be made small enough, generically-looking enough, and even polymorphically generated and variable enough to make picking a good scan string from it impossible. (And, since the encrypted part will look differently every time a new encryption key is used, it will not be possible to pick a scan string for it, either.)

The macro programming languages have some limitations that make this technique a bit difficult for the virus writers. In WordBasic, for instance, a macro cannot be “execute-only” if it wants to modify itself. Furthermore, it cannot modify itself while it is running—a macro virus written in WordBasic will have to consist of at least two macros, each of them modifying the other. Furthermore, the string manipulation functions of WordBasic are very limited and slow—so, any virus written in this language that uses this technique will be very slow and noticeable. Still, it is perfectly possible to write such viruses—and several such viruses have been written, at least as a proof-of-concept.

VBA is much more powerful and faster in this aspect. It has some other limitation—if a subroutine in a VBA module tries to modify itself while it is running and copying itself, it will almost certainly crash the VBA p-code interpreter with a General Program Fault (GPF) error. However, VBA seems to cache the p-code of the VBA modules at a subroutine level, so it is perfectly possible for one small subroutine in the module to modify everything else there. For instance, many of the W97M/AntiSocial viruses consist of two event handlers—Document_Open and Document_Close. The first of them is unencrypted and receives control when the infected document is opened. Its only function is to decrypt the other event handler, which is kept in encrypted form (usually stored in commented lines). Once the second event handler is decrypted, it can receive control and its code performs the main replication functions of the virus.

We would like to emphasize that this polymorphic technique is still in its infancy, as far as macro viruses are concerned. The virus writers have not discovered and tried even 10% of what is theoretically possible. Undoubtedly, they will continue to explore this technique in the future. Implementing detection of some of the most “difficult” implementations will probably require the anti-virus programs to have some kind of VBA interpreter, so that they could interpret the plaintext part of the virus, until the encrypted part of it is decrypted and becomes available to the scanner.

2.3.2.4 Code Permutation

A rather unique polymorphic technique is used by some variants of the W97M/Walker virus family. Each line of the virus ends with a Goto statement to the next line. At runtime, when the virus replicates, it generates a random permutation of its lines (while always preserving its first line at the beginning, in order to ensure that control is received at the right place) and then adjusts the operands of the Goto statements, in order to preserve the order in which the lines are executed. As a result, the body of the virus is scrambled significantly, while its algorithm remains one and the same.

While an interesting curiosity, this technique does not pose any significant problems to the scanners. Those of them that rely on scan strings can always pick a scan string that does not span a line boundary. This string will always be present in all replicants of the virus—although it will be found at different places in them. Scanners which prefer to employ a more precise form of virus identification can compute a checksum of every line in the virus body and then perform the logical operation eXclusive OR (XOR) between the partial checksums to produce a final checksum of the macro (or module). Since the order of operands in an XOR expression does not matter, this approach will produce one and the same checksum for all replicants of the virus.

2.3.2.5 Code Generation

While encrypting most of the virus body and prepending a small polymorphic decryptor in the front of it is the easiest way to achieve reasonably complex polymorphism (and the way most often used by the polymorphic DOS viruses), it is by far not the only one. One alternative is to modify polymorphically not just a small part of the unencrypted virus body (the decryptor)—but the whole body, without using encryption at all.

There are some DOS viruses that use this technique—but they are few and far between, because it is extremely difficult to implement this idea in assembly language. However, implementing it in one of the macro programming languages—with their powerful built-in string manipulation functions—is immensely easier. Therefore, it does not come as a surprise that we saw this idea realized in macro viruses much faster than it was realized in the DOS virus world.

While VBA is much more powerful and suitable for the implementation of this technique than, say, WordBasic, it is in a WordMacro virus (WM/Vicis.A) that we saw it implemented for the first time ([Bontchev97b]). When this virus replicates, it can select a random number of consecutive lines from its body, make sure that the selection does not intersect and open If or For statement, cut the selection, replace it with a Call statement to a subroutine with a randomly generated name, construct a subroutine named like that at the end of the virus code, and paste the removed lines in the body of this subroutine. It could also perform the opposite transformation—select a random subroutine call, replace it with the body of the subroutine that is being called there and remove this subroutine from the virus.

Implemented like this, the idea does not represent any significant problems to the scanners. It is still possible to pick a scan string for the virus. Provided that this scan string does not cross line boundaries, it will be found in all replicants of the virus—just at different places. This is because the polymorphic transformation is line-based. However, it is perfectly possible to combine this technique with the some of the ones previously discussed in this subsection. The result would be a virus, the code of which varies significantly, despite the fact that no encryption is used. If the lines of the virus can both be broken using the line continuation operator (“_”) and joined using the line separator operator (“:”), this would mean that a scan string would be limited to a single term, if the scan string matching routine does not automatically skip the line continuation p-code instructions—or at most to a single simple line, if it can skip them. Additional code obfuscation techniques could be used to make this process even more difficult.

Again, the virus writers have not even begun exploiting the full depths of the possibilities provided by the code generation technique. (Although [Nikishin] describes a good first step.) A good implementation would be able to take any elementary piece of code from the virus and replace it with an equivalent but different piece of code that performs the same functions but looks very different. As a very simple illustration of what is possible, a virus could take a line like

X = 2

and replace it with the following piece of code:

Y = 1 : Z = Y + Y: Z = Z * Z : X = Z / 2

and even obfuscate this expression further by using the various line-splitting, line-joining and line-permutating techniques discussed earlier in this subsection. The proper detection, recognition and identification of such a virus would be extremely difficult—even if the anti-virus program had a full-blown VBA emulator—because there is no constant part that can be revealed and scanned by emulating some small part of the virus (like the decryptor). Moreover, by implementing it in VBA instead of in WordBasic, it is possible to make such a virus fast enough not to be too obvious because of the slowdown it causes to the infected system. If (or when) such macro viruses become prevalent, the anti-virus programs will have to develop and employ alternative detection techniques—heuristics, code frequency analysis, and so on.

2.4 Multi-Platform Support

Since all applications of Office 97 and above use one and the same programming language (VBA) and since this programming language is very similar to VBScript, the virus writers came up long time ago with the idea to write a “universal” macro virus—a virus which infect all these platforms. First they implemented a support for multiple VBA platforms and later included support for the slightly different VBScript platform as well.

2.4.1 VBA Platforms

The obvious first step towards implementing such a “universal” virus was to make a macro virus that could infect just two platforms—Word 97 and Excel 97. The first such viruses (O97M/Teocatl and O97M/Shiver)    used rather clumsy and primitive methods. For instance, O97M/Shiver starts a minimized copy of the other application via the Shell command and then drives it via Application.DDEExecute and SendKeys. The O97M/Teocatl viruses carry within themselves infected NORMAL.DOT and PERSONAL.XLS files, encoded as DEBUG scripts. The drop these files in Word’s Templates folder or in Excel’s XLStart folder respectively, ensuring the infection of the other platform. These viruses are slow and clumsy—but they work (although just barely). It is interesting to note that when Microsoft was informed about the existence of a “Word-and-Excle virus”, their reaction was that “it cannot be done”.

But the most powerful way for implementing a multi-platform VBA virus was discovered by the virus writer who uses the handle “1nternal”. This method was first implemented in his family of multi-platform viruses O97M/Hopper and to this date remains the state-of-the-art method for implementing multi-platform infectors.

The method relies on using the VBA function CreateObject(). This function can be used to start in the background an invisible copy of any installed program that supports the OLE2 automation model. The function returns a COM object that is associated with the started application. This object can be used to drive that application from a VBA program residing in another application (and which VBA program is currently running). For instance, one can delete all lines in the ThisDocument module of the global template of Word 97 with the following lines of VBA code:

Set WordObj = CreateObject("Word.Application")
Set NT = WordObj.Templates(1).VBProject.VBComponents(1).CodeModule
WordObj.Options.SaveNormalPrompt = False
NT.DeleteLines 1, NT.CountOfLines
Set NT = Nothing
WordObj.Quit

The above code could be running from Excel 97, Access 97—or any other application that supports VBA version 5 or higher. By clever usage of the above function and by discovering what are the right parameters passed to it, the virus writers could created multi-platform viruses infecting Word 97, Excel 97, PowerPoint 97, Access 97, Project 98, even Visio and AutoCAD. One of these viruses, O97M/Tristate.C, a virus able to infect Word 97, Excel 97 and PowerPoint 97, became extremely widespread worldwide.

Of course, being able to move from one VBA-supporting platform to another is only half of the problems a successful multi-platform virus must solve. The other half is being able to receive control when the document containing it is opened on the other platform. The virus writers achieved this by clever usage of multiple event handlers like Document_Open, Document_Close (receive control in Word 97), Workbook_Activeate, Workbook_Deactivate (receive control in Excel 97), linking the virus to a shape added to all slides (PowerPoint 97) and so on.

It is surprising to note that while many multi-platform viruses exist, to this date we are not aware of the existence of a multi-platform virus that can infect every single one of the VBA-supporting applications. There are no reasons why such a virus cannot be written and we expect to see it written soon.

Another interesting observation is that support for some of the “exotic” platforms does not contribute much to the “widespreadness” of a multi-platform virus—however, it contributes to its survival. The reason is that people exchange most often Word documents. Therefore, a multi-platform virus is most likely to enter a clean system from an infected Word document. The fact that it can also infect such things like Visio documents would not help the virus spread much better—because people exchange such documents relatively rarely. However, each new platform uses different internal file formats—and each new supported platform costs enormous efforts to the anti-virus researchers who have to reverse-engineer these (undocumented) file formats and figure out how to detect and remove the virus from the documents created on the other platform. This means that a longer time passes until the anti-virus product cover the new platform—time which the virus can use to survive longer on the infected system and infect additional documents and/or systems.

Microsoft has licensed VBA to dozens of companies. The most well-known products which recently added VBA support are AutoCAD and WordPerfect 9.0 (as well as the other applications from the Corel Office 2000 suite)—but there many, many others. Interestingly, the object model of the VBA kit licensed by Microsoft does not have VBA functions for copying of VBA modules (e.g., the equivalent of Application.OrganizerCopy in Word 97). Initially, this lead the author of this paper to conclude that macro viruses for the applications using licensed VBA are either not possible, or are limited to self-contained viruses (e.g., like the X97M/Papa.B virus which mass-mails the document in which it resides and does not attempt to infect other documents), or to clumsy and obvious replication methods (e.g., cut-and-pasting the source of the virus using SendKeys to drive the underlying application). However, the latest research ([Szappanos], [Svajcer]) shows that by using the CreateObject function and passing the parameter “MSAPC.APC” to it, it is possible to obtain access to the VBA Editor object and from it—to many methods for accessing the source of the VBA program and modify and copy it in various ways.

2.4.2 VBA and Script Platforms

The VBScript language used by Internet Explorer in HTML Web pages and by the Windows Scripting Host in Windows is essentially a subset of VBA. Therefore, it is not surprising that the virus writers soon attempted to port their ideas for VBA viruses to the VBScript platform. They also came up with the idea to create multi-platform viruses that would infect HTML Web pages and VBScript files as well as Word 97 documents.

The initial support for VBScript in these VBA viruses was rather primitive. They did not really infect VBScript files—instead, some of them had a VBScript “phase”. That is, they dropped a small VBScript program and either immediately executed it or scheduled it to be executed the next time the computer was rebooted by setting a key for it in the

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

hive of the Registry. This VBScript program could perform different activities—from just changing the settings some Registry keys (e.g., in order to disable the built-in macro virus protection of Office 97) to being a VBScript virus on its own.

However, the idea was “floating in the air” and it was obvious that it was only a matter of (relatively short) time until the first VBA-and-VBScript virus would appear. The “pioneer” was again the virus writer known as “1nternal”—and again his idea was based mainly on the extensive use of the CreateObject function which both VBA and VBScript support.

His virus, Hopper.A, could infect Word 97 documents, VBScript programs (i.e., files with extension *.VBS) and HTML Web pages (files with extensions *.HTM and *.HTML). Since in some of its forms the virus needed lines which were not syntactically correct in the other forms (e.g., the HTML form of the virus used HTML tags like <html>, <script language="VBScript">, etc.), the virus used comments to “disable” these lines and prevent the parser from reporting syntax errors.

It should be noted that although the virus could infect HTML Web pages, it could not spread over the Internet. Its HTML form could replicate only if loaded as a local file with the Internet Explorer. This is because some of the ActiveX objects used by the virus (e.g., CreateObject("Word.Application")) are not marked as “safe for scripting” and cannot be executed from a remote Web page.

Nowadays there are many viruses like this one. Some of them can infect not only files with extensions HTML and HTM but also other kinds of HTML documents—for instance, files with extensions HTT, HTS, CSS and others. However, we have yet to see a multi-platform virus able to infect each of all existing platforms for which viruses have been created.

2.5 Network Awareness

At the time when DOS viruses were prevalent, it took a virus several months to a year to become really widespread—because people exchange executable files or attempt to boot from floppy disks relatively rarely. When macro viruses appeared, they begun spreading much faster—because people exchange documents very often and Microsoft Office is very popular (and, therefore, a very large population of infectable environments exists). A macro virus could become widespread in a matter of weeks. However, the prevalence and speed of distribution reached truly amazing levels when the so-called network-aware viruses appeared.

Network-aware viruses, or worms, are viruses which actively use the networking capabilities of the computers they have infected to spread themselves to other machines. Since nowadays most computers are connected to the Internet in one way or another, this gives to a network-aware virus fast and convenient access to a vast population of infectable machines.

There are two main kinds of network-aware viruses—mass-mailers and network creepers.

2.5.1 Mass-Mailers

Mass-mailers are viruses that spread themselves mainly by using the e-mail system of the infected machine. Most of the time, they rely on the user who receives them to be naïve enough to execute the virus—although some (e.g., the viruses from the JS/Kak family) exploit security holes on the target system to receive control even when the user only reads the message containing them. Most users would open an e-mail attachment contained in a message that appears to have been sent by somebody they know. It is extremely easy to do so—because in most e-mail programs for Windows the attachment is represented by an icon and can be launched by just double-clicking on this icon. The things are even easier for the macro viruses—because the attachment containing them is a document, something that most users consider to be “data”, not “code” and which they will open without a second thought.

As usual, the first mass-mailers (WM/ShareFun.A, WM/PolyPoster.A) were clumsy, proof-of-concepts, which did not have any real chances to become widespread. They used the SendKeys command of WordBasic to drive Microsoft Mail or Free Agent respectively and make them send the infected document to a random address from the address book or to some USENET newsgroups respectively. Not only was the implementation slow and clumsy but these programs are not even the most commonly used ones—and they had to be already running for the viruses to be able to use them.

Unfortunately, the virus writers caught up very quickly. The most widely installed program for both e-mail and newsgroup reading is Outlook Express—because it comes installed by default with Windows 9x. In particular, Outlook Express 98 provides to the user a very rich object model. This model can be accessed in a very fast and convenient way by using the CreateObject function to launch an invisible copy of Outlook Express in the background, if it is not already running. (If it is already running, it can be accessed by using the GetObject function.) The model provides convenient means for opening the address books, enumerating and examining the entries in them, sending e-mail messages, attaching files to the messages, and so on.

The first mass-mailing virus to make use of this method in full was the W97M/Melissa.A virus. It examines the addresses of all address books and sends itself as an e-mail attachment to the first up to 50 of them in each address book. The virus was so “successful” that it spread explosively all over the world in a matter of days. Its mass-mailing method was later copied almost literally by scores of other mass-mailing macro viruses. Only a few of them used creative variations of the method—e.g., sending themselves as replies to the messages in the user’s mailboxes instead of to all addresses in the address books.

Later another mass-mailing, VBS/LoveLetter.A, spread all over the world in a matter of hours after its release in the Philippines. Although it used essentially the same mass-mailing algorithm as the W97M/Melissa.A virus, VBS/LoveLetter.A could spread faster and wider, because it was written in VBScript instead of in VBA—and the number of computers capable of running VBScript programs exceeds by far the number of machines with Office 97 installed. All that is needed in order to run VBScript programs is the Windows Scripting Host—and it is installed by default in Windows 98. It would be installed (again by default) if the user installs Microsoft Internet Explorer version 5.0 or higher, too, no matter the brand and version of the operating system. In addition of being able to infect a larger population, this virus also had a destructive payload. By very rough estimates, the amount of damage caused by it all over the world exceeds $10 billions.

There are two kinds of mass-mailing viruses—fast mass-mailers and slow mass-mailers. The fast mass-mailers send themselves to a large number of recipients at once in explosion-like bursts. The two viruses described in the above two paragraphs are fast mass-mailers. Such viruses have the advantage to be able to become widespread very fast. However, they also have a very serious disadvantage. This very same speed of spreading causes them to bog down the e-mail servers and become noticed quickly. Since their “annoyance factor” is very high, the users (or their system administrators) quickly take measures to remove the virus from the infected systems. As a result, such viruses become widespread very fast—but they become extinct very quickly too.

The slow mass-mailing viruses, on the other hand, use a different, much more modest approach. Instead of sending themselves to a large number of recipients at once, they usually send themselves to a single recipient—either as a reply to a message received from this recipient or as a follow-up to a message sent to the recipient by the legitimate user of the infected system. Such viruses need much more time to become widespread, compared to the fast mass-mailers. However, once this happens, they are much more difficult to eradicate—because they cause only minor load on the infected systems and the users tend not to notice them. A typical example of a slow mass-mailing virus is Win32/Ska—although it is not a macro virus. Nowadays this is one of the most widespread viruses in the world.

2.5.2 Network Creepers

The network creepers are network-aware viruses that spread from one machine to another by using the direct LAN connections of the machine they are running on and searching the network for another machine to infect. Unlike the mass-mailing viruses, the network creepers do not require the user to execute them. They also spread much less vigorously than the mass-mailers. They need more time to become widespread—but also run a lower risk of being noticed early, since they do not overload the network with thousands of copies of themselves. Another important difference is that while the mass-mailers spread “naturally”, during the normal exploitation of the e-mail system, the network creepers usually rely on some security hole or misconfiguration to invade the victim system.

A typical example of a network creepers is the VBS/Netlog family of viruses. They simply generate random IP addresses and check for the presence of a writable drive C: at those IP addresses. If such a drive is found, the virus maps it to a local drive letter and attempts to copy itself to the directory \Windows\Start Menu\Programs\Startup or \Win95\Start Menu\Programs\Startup that drive. If the copying operation succeeds, this means that the remote machine is running the English language version of Windows 95 and will execute the virus the next time it is restarted in single-user mode. The security hole this virus relies on is that many users have world-writable C: drives on their machines that are connected to the Internet. This has allowed the VBS/Netlog viruses to become rather widespread.

2.6 Payloads

There haven’t been any particularly interesting developments of the destructive payloads of the macro viruses in the past five years. Simply every kind of payload we have seen in the DOS virus world has been implemented there as well. These payloads range from displaying simple messages, through changing some properties of the infected system (e.g., the wallpaper used by the desktop or the settings of Microsoft Office), to deletion of files, formatting the hard disk, and so on.

Just like in the DOS world, the most dangerous kind of payload here is not the immediate destruction of all the available information (e.g., by formatting the hard disk), but its slow, slight, and unnoticeable corruption. The reason why this kind of destructive payload is more dangerous is the following. When all the information on the attacked machine is destroyed immediately, the user will notice it and will restore it from backups. However, if the information is modified slowly and slightly, the user is unlikely to notice it for a long time. And, when it is noticed, it is usually too late—because the corrupted files have made their way to the backups and because there are usually no ways to determine whether a file is corrupted or not other than by examining it manually (which is usually a very time-consumming operation).

Viruses, which perform this kind of slow data corruption, are called data diddlers. A typical example of data diddlers are the viruses from the XM/Extras virus family which modify the contents of random cells of the Excel documents they have infected.

3 The Future

What kind of developments can we expect in the near future? The future is always difficult to predict. We have tried to predict the future trends in virus writing in a paper published in 1994 ([Bontchev94])—and have failed to spot all the three major trends that have developed in the next few years (32-bit viruses, macro viruses, network-aware viruses). Still, the obvious developments that can be expected are essentially more of the same that we have seen so far, macro virus support for additional software and hardware platforms, further improvements in the polymorphic engines and the network awareness.

3.1 More of the Same

• More viruses. Probably the most probable and obvious development that can be expected is the further increases in the number of viruses that are being created. The virus writers are not going away any time soon—there always will be a few people willing to experiment with new ideas and many more willing to plagiarize their ideas. It is unlikely that the applications of Microsoft Office will stop acting as automatic virus generations, either.

• More polymorphism. As mentioned in section 2.3.2.5, the virus writers have not even scratched so far the surface of what can be implemented as polymorphic engines in VBA. We expect significant developments in this field in the near future. Their result will be polymorphic viruses that will be extremely difficult for the anti-virus products to detect, recognize and identify reliably.

• More platforms. Having in mind how many software developers have licensed VBA from Microsoft, we expect many new products to appear on the market in the near future—products, which would have VBA support. Probably in most cases, it will be possible to create a VBA virus for the respective VBA-supporting product. Writing macro viruses for a new VBA-supporting application is likely to be much easier than to reverse-engineer the underlying data formats and figuring out how to implement detection and disinfection of such a virus. Viruses which support multiple platforms (one of which is Microsoft Word) will have more chances to become widespread. We shall probably see the appearance of “universal” VBA viruses—viruses that are able to infect every VBA-supporting platform.

• More network awareness. A virus, which uses actively the network to spread itself to other machines, has much higher chances to become widespread than a virus that does not have this property. Therefore, we expect to see more network-aware viruses in the future. Currently such viruses use mainly Outlook to mass-mail themselves or crawl the LAN connections using some particular security hole to invade the remote machines. We expect to see support for other popular e-mail clients (e.g., Outlook Express, Netscape, Eudora) and network crawlers using whole ranges of security holes.

• Security-compromizing payloads. The Remote Access Trojans (RATs) are very popular forms of non-viral malware, since they allow the attacker to gain control on the victim’s machine. However, they rely on the attacker’s ability to trick the user into executing them. In the future, we expect to see more often viruses, the payload of which is to install a backdoor or a RAT on the infected system. Since the virus has already infected the system, no user cooperation would be required to run the RAT—the virus can do this all by itself. A typical example of such a virus, the payload of which is opening a backdoor on the infected system is Win32/QAZ—although it is not a macro virus. We also expect to see computer viruses (and macro viruses, in particular) more often used in the future for the purpose of breaking successfully into otherwise well-protected systems and/or for performing distributed denial-of-service (DDoS) attacks against such systems.

3.2 WAP

Recently, devices using the so-called Wireless Access Protocol (WAP)—mainly cellular phones—have gained increased popularity, especially in Europe. As the wireless devices (like phones) increase in sophistication, they become more and more similar in functionality to personal computers. Naturally, some people have come up with the idea of writing viruses for such devices.

There has been even a hoax circulated around, warning about a virus that infects mobile phones. Fortunately, this is just a hoax—no such viruses exist yet. Furthermore, with the current state of development of WAP, no such viruses are possible. Unfortunately, things are unlikely to stay that way for long.

It should be noted that although mobile phones cannot be infected with a virus, they certainly can be affected by one. For instance, the VBS/LoveLetter.A virus sends itself to all addresses in all Outlook address books of the infected machine. If one of these addresses is the address of an e-mail-to-SMS or e-mail-to-fax gateway, the virus can be sent to faxes, pagers or mobile phones—although it cannot, of course, run on such devices. As another example, the VBS/Timofon.A virus has a payload that sends SMS messages to a range of phone numbers in Spain. Still, it is unable to infect any such phones.

Devices that support the WAP protocol can accept WML cards. These are equivalent to the HTML pages that can be accepted and displayed by a Web browser running on a PC. A WML card can contain script programs written in the WMLScript language—a very close relative to JavaScript. The new version of the WAP protocol, which is supposed to become standard in 2001, support WMLScript extensions which have some rather exciting features. For instance, a WMLScript program would be able to access and search the phone book of the cell phone that is executing it, to make phone calls, display different messages on the phone’s screen and so on.

Even with the new WMLScript features, it is still impossible to write a virus that would infect a cell phone and spread from it to other such phones. This is because there is no way for a WMLScript program to remain permanently resident in the phone’s memory and to transfer itself to other phones. However, it is possible for a WMLScript virus to spread itself with the help of the cell phone system.

The author of the virus will have to start a WAP portal service and install its virus there. Then he could spam a wide range of cell phone numbers known to him with an SMS message. The message would use social engineering techniques to fool the user into connecting to the malicious WAP portal—for instance, by promising some cool feature available there (like a game).

Once a WAP-enabled cell phone connects to the malicious WAP portal, it will be sent a WMLScript program. This program would search the phone book of the phone running it and would send an SMS message to all phone numbers found there—the same message that attempts to trick the recipient into connecting to the malicious WAP portal. Although there will be no program code spreading from one phone to another in the classical sense of a PC virus, such epidemic of SMS messages could nevertheless cause significant trouble. Fortunately, since the attack comes from a centralized source (the malicious WAP portal), once it is detected, it will be relatively easy to find and shut down the attacking service.

In addition to annoying users by spamming them with SMS messages, such a virus could cause other kinds of damage as well. For instance, it could steal the phone user’s PIN by faking a reboot ([Hyppönen]), or it could make calls to a pay-per-minute phone number and so on.

3.3 Hand-Held Devices

Another class of platforms for which we shall very probably see active virus development in the near future are the various hand-held devices or personal data assistants (PDAs). So far there is only one known virus for the Palm Pilot and several Trojan horses for the Palm Pilot and the Psion PDAs.

The virus, Palm/Phague.A, is a very simple, proof-of-concept virus. It is not a macro virus. It is a simple overwriting virus, which damages the programs it infects. It is too obvious and has no chances to spread. However, the PalmOS platform is very “virus-friendly”—just like MS-DOS, it does not have any kind of protection and a virus can easily modify other programs and even the operating system itself. Since most PDAs support some kind of wireless communication between themselves (e.g., via infra-red ports), a specially written virus could easily hijack this communication link and send itself to all other PDAs the infected machine is communicating with.

There are some problems, however. A Palm Pilot device cannot simply send programs to other such devices in range, like a computer can send programs to other computers on the same network. Instead, the transfer is impossible to be performed by the explicit consent of the user of the machine that accepts the program sent to it. The two machines have to specially aligned against each other in order for the communication between them to be possible. Furthermore, the receiving machine pops up a warning, if a program (as opposed to a data file) is being sent to it.

Finally, the culture of file sharing among the Palm Pilot users is very different from that of the PC users. The Palm Pilot users usually exchange data files—not programs. They download programs from well-known archive sites on the Internet. Presumably, the programs on these sites are checked before being made available to the public—although still, it might be possible for an attacker to submit a malicious program there. Still, since the file transfer of executable files is mainly in one direction (from the archive site to the users), a virus will not be able to spread this way; at most a Trojan horse introduced this way would be able to damage many users. Therefore, we do not expect computer viruses to become a significant problem for the Palm Pilot users in the near future.

Another interesting PDA platform is PocketPC. It runs the Microsoft Windows CE operating system. Since this OS supports only a small subset of the APIs of Windows 9x or NT, none of the existing viruses for the latter two operating systems are able to work under WinCE. However, it is perfectly possible to create a virus that uses only the subset of APIs available to WinCE programs. PocketPC machines are not designed to communicate directly with each other like Palm Pilots. However, they have built-in programs for reading e-mail via a standard dial-up Internet connection. It would probably be possible to create a mass-mailing virus that uses Pocket Outlook to spread itself by e-mail.

Although the PocketPC has both Word and Excel, their Pocket versions do not support any macro programming language. Furthermore, while the PocketPC has a Pocket version of Internet Explorer to browse the Web, it has no equivalent of the Windows Scripting Host and cannot run VBScript or JavaScript programs. Therefore, at the present state of development it is not possible to write a macro virus for the PocketPC platform.

However, in our experience, future development is like to bring more features to this platform—not improved security. We would not be surprised to see in the near future versions of PocketPC applications supporting some form of VBA macros or scripts.

4 References

• [Bontchev94] Vesselin Bontchev, “Future Trends in Virus Writing”, 4th Int. Virus Bull. Conf., 1994, pp. 65–82.
• [Bontchev96] Vesselin Bontchev, “Possible Macro Virus Attacks and How to Prevent Them”, Proc. 6^th Virus Bull. Conf., 1996, pp. 97–127.
• [Bontchev97a] Vesselin Bontchev, “Macro Virus Identification Problems”, Proc. 7^th Virus Bull. Conf., 1997, San Francisco, pp. 175–196.
• [Bontchev97b] Vesselin Bontchev, “Veni, Vidi, Vicis”, Virus Bull., October, 1997, pp. 10–11.
• [Bontchev98] Vesselin Bontchev, “The ‘Pros’ and ‘Cons’ of Macro Virus Upconversion”, Proc. 8^th Int. Virus Bull. Conf, 1998, München, Germany, pp. 153–172.
• [Bontchev99] Jakub Kaminski, “Hide and Seek—Stealth Techniques of Macro Viruses”, Proc. 9^th Virus Bull. Conf., 1999, Vancouver, pp. 133–148.
• [Bontchev2000] Vesselin Bontchev, “Solving the VBA Upconversion Problem”, Proc. 10^th Virus Bull. Conf., 2000, Orlando, pp. 273–299.
• [Highland] Harold Highland, “A Macro Virus,” Computers Security, 8 (1989), pp. 178–188.
• [Hyppönen] Mikko Hyppönen, “WAP Viruses—Can Your Mobile Phone Get Infected?”, Proc. 10^th Virus Bull. Conf., 2000, Orlando, pp. 71–76.
• [Nikishin] Andy Nikishin & Mike Pavluschick, “A Nightmare on Researcher Street”, Virus Bull., April, 2000, pp. 8–9.
• [Svajcer] Vanja Svajcer, “VBA Implementation & Virus Risks”, Proc. 10^th Virus Bull. Conf., 2000, Orlando, pp. 301–324.
• [Szappanos] Gabor Szappanos, “Generic VBA Virus Technology”, Virus Bull., May, 2000, pp. 16–17.
• [Table] “Prevalence Table—August 2000”, Virus Bull., October, 2000, p. 3.