Dr. Vesselin Bontchev, anti–virus researcher
FRISK Software International
Postholf 7180, 127 Reykjavik, ICELAND
E–mail: bontchev@complex.is
| Download this paper as a Word document |
By the end of January we received an interesting sample of a new kind of macro virus for Excel from a colleague of ours—Jimmy Kuo, anti–virus researcher at Network Associates (former McAfee Associates). It had been found by their French department and, reportedly, was in the wild in France. The most interesting thing about it was that, unlike all Excel viruses known so far, it contained no VBA modules.
According to the initial reports, it worked only under the French version of Excel 95 and was implemented entirely in as cell formulas. Its payload, invoked with a probability of 1%, was to set the title of Excel’s window from “Microsoft Excel” to “Enfin la paix…” (“Peace at last…” in French), so we decided to name it ExcelFormula/Paix.A, or XF/Paix.A for short.
The above preliminary information turned out to be not entirely correct. For instance, we discovered that the virus infects and replicates happily under any language version of Excel 95. It is unable to infect a clean Excel 97 system—however, if the system is already infected (e.g., because Excel 95 was installed and used in the past and the virus has infected the system then), the virus will have no problems replicating under Excel 97 too.
Also, calling it a “formula virus” isn’t quite correct. We were afraid that, if the virus was indeed implemented as cell formulas, scanning for such viruses would cause a tremendous slowdown of our scanners—because essentially all useful Excel workbooks contain some kind of formulas, which means that there wouldn’t be a fast and easy way of determining that a workbook is not infected. Fortunately, the virus does not consist of “normal” cell formulas. Instead, it is implemented as a Excel 4.0 macro sheet—although it relies heavily on the extensions to the Excel 4.0 macro language introduced first in Excel 5.0 and cannot run under Excel 4.0. An Excel 4.0 macro sheet has cells just like a normal sheet, and its operators look very much like cell formulas—which explains the initial confusion.
The virus consists of five separate routines, all of them contained in a single column (A) of the viral macro sheet. The names of these routines are respectively Auto_ouvrir, activation_feuille, protect, GO and Auto_fermer. We shall describe them in details below. The viral sheet itself is named !!!GO and is marked as “very hidden”—which means that the user cannot “unhide” it from Excel’s menus. Instead, one has to use either a hex editor (that is, if one is familiar with the OLE2 formats and the format of Excel’s Book stream), or one has to create and run the following short VBA module:
Sub Unhide()
For Each sh in Sheets
End Sub
sh.Visible = True
Next
That would reveal the hidden sheet “!!!GO”—but the sheet would seem empty. The reason for that is because the sheet is additionally protected with a password—so that it cannot be modified and the formulas in it are not visible. Fortunately, breaking weak protection schemes is something like a hobby of ours, so after a little hacking we were able to crack the password. To reveal the contents of the sheet, one has to make that sheet active, then select Tools/Protection/Unprotect Sheet from Excel’s menus. When Excel asks for a password, “!!!GO97” (without the quotes, of course) should be used.
As mentioned above, the virus consists of five separate routines. We shall describe them one–by–one, in their order of appearance in the virus code.
The main purpose of the routine Auto_ouvrir (Auto_open in French) is to determine whether the system is already infected, infect it if it is not the case, and activate the virus, so that it begins infecting. The routine first disables the error checking, so that Excel does not display any messages if an error occurs and continues with the execution of the macro. Then it disables the screen updating too. Its next task is to determine whether the name of the active workbook is “xlsheet.xla” and, if this is the case, to prevent the routine activation_feuille on the sheet !!!GO from running, if that sheet resides in a workbook named TEST1.XLS. That is probably how the virus writer’s sample has been named and the above gymnastics prevent the virus from getting out of control on its author’s system.
Next, the virus examines the list of all active workbooks and installed add–ins. If at least one of them is named “xlsheet.xla”, the virus decides that it has already infected the system and takes no further action, besides restoring the screen updating and the error handling. Otherwise, it examines the first character of the full absolute path of the directory where the current (infected) workbook resides. If that character (corresponding to the drive letter) is not ‘C’, then the virus decides to install itself in the directory C:\WINDOWS—otherwise it is installed in the same directory where the infected workbook is.
The next step is to convert the current workbook (i.e., the workbook where the virus is run from) to an add–in named “xlsheet.xla” and residing in the directory where the virus has decided to install itself. This is precisely the command which fails under Excel 97 and this is the reason why this particular virus is unable to infect clean Excel 97 systems.
Finally, the virus activates the !!!GO macro sheet containing its code, uses the add–in manager to instruct Excel that the xlsheet.xla add–in is installed and restores the screen updating and error handling.
The activation_feuille routine takes care of replicating the virus to new workbooks. Its first actions are to obtain the name of the currently active workbook, to turn off the screen updating and error reporting, activate the xlsheet.xla add–in, and to unhide the !!!GO sheet both in the add–in and in the current workbook. If no error occurs during the last action, it means that the current workbook already contains a sheet named like that—so, it is assumed to be infected by the virus. In this case the virus calls the GO routine which contains its payload. Otherwise the virus copies the “!!!GO” macro sheet from the add–in to the active workbook and saves the workbook—i.e., it replicates. Finally, the virus hides the “!!!GO” macro sheet both in the add–in and in the newly infected workbook and restores the screen updating and the error handling.
The protect routine is never executed by the virus. It simply defines the various variables and routine names used in the virus code, password–protects the viral macro sheet and marks it as “very hidden”. Obviously, this routine is there only because the virus writer had to somehow perform these initialization tasks before the virus could begin spreading on its own. Of course, they could have been performed just as well by a separate macro—this would have made the virus about twenty lines shorter and would have caused us to spend a few additional minutes trying to crack the protection password—but the virus writer obviously did not care.
The GO routine contains the payload of the virus. Its first action is to turn off the error messages. Then, with a probability of 1% it does the following. First, it hides all menus. Then it hides all the 13 standard button bars. Next, it hides the formula bar, the status bar, the display of outline symbols and zero value, the horisontal and vertical scroll bars, and the sheet tabs—all of these are configurable via the Tools/Options/View menu. Finally, the virus hides all opened workbooks and changes the title of Excel to “Enfin la paix…”, leaving it (and the user) in a rather confused state. The last action of this routine is to re–enable the error messages.
The last routine of the virus, Auto_fermer (Auto_close in French) is very short—just three lines. All it does is to turn off the error messages if the xlsheet.xla add–in has been just created. The purpose for this is to disable the “Save changes in <workbook>?” question Excel would normally ask in this case when the user tries to close the workbook.
An interesting question is, since the virus uses French names for its Auto_Open and Auto_Close routines, why does it replicate under any other language version of Excel too? The key to the answer lies in the protect routine and in the way Excel treats reserved names like Auto_Open, Auto_Close, etc.
For instance, the protect routine defines the name Auto_ouvrir in the following way:
=DEFINE.NAME("Auto_ouvrir","=L2C1",2,,TRUE,14)
If this line is executed under the English language version of Excel, it will not have the desired effect for two reasons. First, there a cell is referred to as =RxCy—not as =LxCy and, second, there the name “Auto_ouvrir” does not have any special meaning. However, in the virus this line has been executed only once—by the virus author—and under a French language version of Excel. In that language version of Excel the cell reference is perfectly correct and the name “Auto_ouvrir” has a reserved meaning—it indicates a name which automatically receives control whenever a workbook is opened. So, the execution of the above line has instructed the French language version of Excel to record somewhere in the workbook that the macro starting from the cell which is at the intersection of row 2 and column 1 is to be executed automatically each time that workbook is opened. (The remaining arguments specify that it is an Excel 4.0 macro, there is no shortcut associated with it, its name is hidden, belongs to the user–created category number 14, and is global for the whole workbook; not local for the sheet.)
Once this information is recorded in the workbook, it is preserved even when the workbook is opened by other language versions of Excel and the macro is executed there. However, if the source of the virus is extracted, then inserted into another workbook, and initialized by running the protect routine under an English version of Excel—then it would not replicate, unless extensive changes are made in the protect routine—to translate its language–dependent operators into English.
While the detection and disinfection of this new kind of macro virus poses no particular problems (even, for a change, all the necessary documentation of the respective stream formats and data structures is freely available from Microsoft), it nevertheless requires significant redesign of the current macro scanning engines. Essentially, the scanners should examine the Book (or Workbook in documents created by Excel97) stream for BOUNDSHEET records describing Excel 4.0 macro sheets. In a normal workbook there would be none of those, so a scanner can determine relatively quickly that a workbook is not infected. In case any Excel 4.0 macro sheet description records are found, the FORMULA records of these sheets should be searched for the virus. Our recommendation, as usual, is to use exact identification and to checksum all BLANK, LABEL and FORMULA records of the Excel 4.0 macro sheets (skipping their variable parts, of course). Those who prefer to rely on scan strings instead (a rather bad idea) could probably use the following scan string for this particular virus:
However, the scan string should not be used to scan blindly anywhere in the Excel documents. Instead, the scanner should be aware of the OLE2 formats and of the format of the Book/Workbook stream and look for the scan string of this virus only in the FORMULA records of the Excel 4.0 macro sheets.