Spanish Telecom

Another virus attempting to make a political (?) point has recently come to hand from Spain. (The virus was identified at two separate academic sites -- Oxford University and City University, London, UK, in December 1990, although no further reports of 'real world' infections have yet been received. Ed.) The virus has been called "Spanish Telecom" for reasons which will become apparent as this analysis progresses.

Multi-Partite Structure

This virus is a true multi-partite virus in that it functions both as a parasitic virus infecting COM files, and as a boot sector virus which infects the Master Boot Sector of the first fixed disk drive as well as the boot sector of any type of floppy disk. The code contains a particularly vicious trigger routine which will overwrite all data on both the first and second fixed disk drives. The trigger routine is invoked from the boot code section of the virus after the 400th infected boot cycle. The parasitic code is encrypted and contains plain text at the end of the code which reads:

Virus Anti -- C.T.N.E. (c)1990 Grupo Holokausto.
Kampanya Anti-Telefonica. Menos tarifas y mas servicios.Programmed in Barcelona (Spain). 23-8-90. -666-

The final "666" may be a reference to the 666 (Number of the Beast) virus since certain techniques first noticed there have been used here! The phrase translates roughly as "Lower tariffs, more service." Another message which is separately encrypted is displayed during the overwriting activity of the trigger routine:

Campana Anti-TELEFONICA (Barcelona)

Analysis of this code is best undertaken by considering the parasitic and boot sections separately.

Parasitic Analysis

This is undoubtedly the most untidy code which I have examined. There are many repetitions and several bugs which will reveal the presence of the virus long before the trigger routine is invoked.

The virus code is attached at the end of COM files between 128 and 60999 bytes in length (inclusive). COMMAND.COM is specifically excluded from infection as is any file beginning with the letters "IBM" (the IBM system files). The initial four bytes of the host file are saved within the virus code and overwritten with an appropriate jump instruction to pass processing to the virus code.

The infective length of the parasitic code is 3,700 bytes (this includes the boot code). The virus code begins with an 85 byte section which contains "armoured" code to detect debugging software and several randomised instructions which are presumably intended to prevent the extraction of a reliable search string. There are two different versions of this 85 byte "header" routine, only one of which is actually positioned for use during the file infection process. There are, therefore, two distinct search strings for the parasitic code although each confirms the existence of the same virus.

Both "header" code routines perform the same functions: check for debug presence, locate the position of the virus code within the host segment and decrypt the remaining code.

Processing then checks to see whether the virus is memory- resident . This is done by collecting the byte at offset 1BCh of low memory and XORing it with 13h, the result is then checked against the next byte at offset 1BDh. If they are the same then the virus is resident and processing returns to the host program. The values of these two bytes are changed regularly by the virus during its intercept operations but by simply XORing them together, regardless of their values, the result will be 13h if the virus is resident in memory.

If the virus is not resident, the current Int 21h vector is collected and stored in memory via direct access to page zero of memory where the interrupt vectors are stored. The virus code is then installed in high memory and 3984 bytes are removed from system memory to accommodate it.

The next set of instructions collects a pseudo-random number from the system clock and uses it to index into a table of word addresses. The selected word is then inserted as the offset portion of the Int 21h vector in low memory, the segment portion being set to the virus' own segment in high memory. This random process of selection ensures that the actual offset stored in the interrupt table will vary from infection to infection. Each address, though different, points to a jump instruction which takes processing to a single Int 21h handler within the virus code. There are 14 entries in the address table although only 7 of them are used and this, together with other sections of the code, suggests that other techniques may have been tried (or are being prepared). Once the interrupt handler has been installed, a special call is made to it which completes the installation process. This call consists of putting 4B21h into AX and issuing an Int 21h request.

The special call is routed by the virus' handler to an installation routine which uses the single step INT 01h capability in the same way as the Flip virus (VB, Sept 90) to "strip" out any extraneous handlers from the targeted interrupt chain. Interrupts treated in this way are 13h, 21h and 40h and the stripped vectors are temporarily installed during file infection and repaired when the process has completed. Thus any TSR monitoring software which uses installed handlers will need to contain reliable self-testing routines to guard against this type of subversion.

Interrupt Handling

The virus interrupt handler intercepts six different function requests within the DOS services interrupt: function 4B21h has already been mentioned and there is another special call using a value of 4B20h which does nothing. This gives rise to speculation that further developments may be planned. The SEEK function (42h) is intercepted when accompanied by subfunction 02 (to End of File). This checks to see whether the file has been infected and if so, modifies the pointer to subtract the length of the virus code before returning the End of File position. The two alternative sets of Find First and Find Next functions (11h - 12h and 4Eh - 4Fh) are similarly intercepted to return a modified file size on infected files.The main intercept however, is that applied to the Load and Execute function (4B00h). This is used to select and infect files with a COM extension (subject to the name and size exceptions mentioned earlier). Once a suitable file has been identified, the INT 13h and INT 40h vectors are temporarily r eplaced with their stripped equivalents and a simple handler for the critical error interrupt (24h) is installed.

The usual process of file infection is then invoked whereby the target file date, time and attributes are collected and stored, and the file is opened for Read/Write access (attributes are modified if necessary). The correct initial jump is calculated and the first four bytes of the target file copied and stored before being overwritten by a jump to the virus code. Certain sections of the virus code are then modified by the addition of random data values generated from a system clock reading.

The next stage involves using one of these data values as the new encryption key into one of the two 85 bytes decryption headers (chosen at random). The header is written (unencrypted) to the end of the host file. All the virus code is then encrypted and written to the end of the host file one byte at a time -- each byte is collected, encrypted and written on an individual basis. This removes the need for a special buffer or a decrypt/recrypt cycle.

The final stage is to close the file and reset the date, time and attributes to their original settings. As a marker to indicate that the file is infected, the date setting is modified in a similar way to the 4K (or FRODO) virus by adding 100 to the year field. Modified interrupt vectors are reset to their previous values before processing returns to the calling routine.

During the installation of the handlers, a check is made to see whether the Master Boot Sector of the first hard drive is infected with the virus' boot code. If the disk is not infected then the boot section of the virus code is installed in Sector 1, Head 0, Track 0. The second sector of virus code is stored in sector 6 of the same track and the original boot sector is stored in sector 7. This will cause problems of access on some machines which use these sectors for other purposes.

Boot Sector Analysis

The boot section of this virus functions completely independently of the parasitic portion and both sections will almost certainly be in memory simultaneously. This may explain the almost obsessive concern with revectoring interrupts during the parasitic file infection. However, while the parasitic code contains all the virus routines, the boot section is limited to two sectors of self-contained code. Thus a machine infected with only the boot code will not infect files, only other disks.

The only items worthy of note in the boot code are the trigger routine, the floppy infection routine and the interrupt redirection. The interrupt redirection intercepts requests to Int 13h for both floppy and hard drives. A Read or Write request to either the first or second floppy drive will result in the disk being checked for infection and infected if possible. The routine is unusual in that it will only complete the check and infection if the motors of both the first two floppy drives are not running.

Int 13h requests to the first hard drive are intercepted and tested to see whether they are Read or Write. A Write request to the Master Boot Sector of the first hard drive is changed into a Verify call so that the sector will not be overwritten if the virus is resident. Read requests are tested to see which sector (on Head 0, Track 0) is wanted and re-routed accordingly. Requests for sector 1 are given sector 7 (where the original boot sector is stored) and requests for either sector 6 or 7 are given sector 5. In a similar way to the Brain virus, Spanish Telecom, when resident, will attempt to prevent inspection of the true boot sector by ordinary utilities.

Floppy Infection

If an uninfected floppy is accessed, the virus will attempt to infect it and the storage sectors used for the second sector of code will vary according to a table maintained within the virus code. Remember that both first and second (A: and B:) drives are affected.

Floppy disk infection indicating the head and sector location of the virus code on diskettes is shown below:

Floppy Type           Virus Location
                      Head     Sector
160K - 5.25"            0        6
180K - 5.25"            0        8
320K - 5.25"            1        1
360K - 5.25"            1        2
720K - 5.25" or 3.5"    1        4
1.2M - 5.25"            1   0Dh (decimal 13)
1.44M - 3.5"            1   0Eh (decimal 14)

From the figure above, it will be seen that infected disks may become unreadable as virus code overwrites sections of the FAT or root directory. To complete this information you should note that the virus code occupies sectors 1 and 6 of a hard disk, with a copy of the original boot sector being stored in sector 7 (all on head 0, track 0). [This is the first virus known to VB which will infect all diskettes regardless of density -- the table above is a graphic reminder of the need to write-protect floppies, even those dedicated to pure data transfer. Ed.]

Trigger Routine

When a PC is booted from an infected hard disk, a counter within the boot code is incremented and tested to see whether it has passed 400 (190H). If it hasn't, the code is rewritten back to the boot sector and processing continues normally. However, when the counter does reach this number, processing immediately passes to the trigger routine. This is one of the nastiest, most destructive triggers I have seen; it overwrites all sectors of both the first and (if there is one present) the second hard drive with random information from boot-time low memory. The overwriting routine will be completed a number of times (for each drive) depending upon the number of heads on the drive. On each pass, the encrypted message reproduced on page 22 will be displayed.

Detection

It should be noted that the presence of either of these strings at the appropriate offset (into the virus code) is an indication of infection. Infective length of the parasite is 3700 bytes (appended on LOAD and EXECUTE).

Recognition of the boot virus code is simpler but note should be taken of the interrupt redirection discussed above. The code is not encrypted and the recognition string is as follows:

8A0E EC00 BE70 0003 F18A 4C02 8A74 03C3 ; Offset 0B3h

Virus Bulletin: Telefonica / webmaster@virusbtn.com

© 1998 Virus Bulletin Ltd.