Spanish Telecom Virus aka HOLOCAUST, TELEFONICA

             *********************************************

             ***   Reports collected and collated by   ***

             ***            PC-Virus Index             ***

             ***      with full acknowledgements       ***

             ***            to the authors             ***

             *********************************************

  Report from Jim Bates - The Virus Information Service - 23rd

  December 1990

  === Spanish Telecom Virus aka HOLOCAUST, TELEFONICA ===

  Another virus attempting to make a political (?) point has recently

  come to hand from Spain.  This is being called the "Spanish Telecom"

  virus for reasons which will become apparent as this analysis

  progresses.

  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 Record of the first fixed disk drive

  as well as the boot record 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 servicio.

         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 one of the most untidy pieces of code that 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" coding to

  detect the presence of debugging software and also several

  randomised instructions which are presumably intended to prevent the

  extraction of a reliable search string.  Within the code 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 if the virus is resident in memory.  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 passes directly back to the host program.  The actual

  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.  Collection is via direct access to

  page zero of memory where the interrupt vectors are stored.  All of

  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 ideas may have been tried

  (or are being prepared) within this code.  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 01 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 monitoring software which uses

  installed handlers will need to contain reliable self-testing

  routines to guard against this type of subversion.

  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 is another area which gives

  rise to speculation that further developments may be in hand.  The

  SEEK function (42H) is intercepted when accompanied by subfunction

  02 (to End of File).  This checks to see if 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 replaced 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 and then the encryption routine is executed.  The

  whole of the virus code is 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 either 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

  (IDF or FRODO) virus by adding 100 to the year field.  Modified

  interrupt vectors are then reset to their previous values before

  processing returns to the calling routine.

  During the installation of the handlers, a check is made to see if

  the Master Boot Record 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 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 contain 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

  of the first two floppy drives are NOT running.  INT 13H requests to

  the first hard drive are intercepted and tested to see if they are

  Read or Write.  A Write request to the Master Boot Record 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.  Thus in a similar way to the

  original Brain virus, it is not possible to examine the true boot

  sector of an infected machine with ordinary utilities while the

  virus is resident.

  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

  - the table looks like this :-

      Floppy Type        Head and Sector of second part of virus

      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 this table 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).

  Trigger Routine

  When a machine is booted from an infected hard disk, a counter

  within the boot code is incremented and tested to see if 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 that I have yet seen since it will overwrite 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 mentioned above will be displayed.

  Recognition

  It has been necessary to extract a different recognition string for

  each version of the parasitic code and these are as follows:-

  Header 1 - 8B1D B200 83FB 0074 18BF 5500 B2         Offset - 34H

  Header 2 - 83ED 09BE 2001 03F5 FCB6                 Offset - 24H

  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 presence 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

  VIS Classification - BfmCARKD3700A

  The information contained in this report is the direct result of

  disassembling and analysing a specimen of the virus code.  I take

  great pains to ensure the accuracy of these analyses but I cannot

  accept responsibility for any loss or damage suffered as a result of

  any errors or omissions.  If any errors of fact are noted, please

  let me know at :-

The Virus Information Service,

Treble Clef House,

64, Welford Road,

WIGSTON MAGNA,

Leicester  LE8 1SL

  or call +44 (0)533 883490

  Jim Bates

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  ++++++++++++++++++++++++++ end of reports ++++++++++++++++++++++++

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++