W95.Babylonia

Printer Friendly Page

Discovered: December 07, 1999
Updated: February 13, 2007 11:47:51 AM
Type: Trojan Horse, Worm, Virus


W95.Babylonia was originally posted to an Internet news group on December 3, 1999, as a Windows Help file named Serialz.hlp. It appeared to be a list of serial numbers for commercial software. When this Windows help file is run, it executes the virus. The virus appears to have been written by the same individual who released the W32.Coke and W95.Fono (El_Inca) viruses.

Antivirus Protection Dates

  • Initial Rapid Release version December 21, 2000
  • Latest Rapid Release version September 28, 2010 revision 054
  • Initial Daily Certified version December 21, 2000
  • Latest Daily Certified version September 28, 2010 revision 036

Click here for a more detailed description of Rapid Release and Daily Certified virus definitions.

Writeup By: Peter Szor

Discovered: December 07, 1999
Updated: February 13, 2007 11:47:51 AM
Type: Trojan Horse, Worm, Virus


W95.Babylonia is a complex virus that propagates using mIRC, or as an email attachment. All infected .hlp and .exe files can cause infection on other systems. This Windows 95 virus employs many proven infection techniques, which have been developed by virus writers for the Windows 9x platforms over the past few years.

Opening a help (.HLP) file
When an infected .hlp file is run under Windows 9x, the virus code is activated. The virus modifies the entry point of .hlp files to a short script routine. This routine transfers control from the script interpretation to the binary virus code that is placed at the end of the infected .hlp files in variable packed form. When the binary virus code assumes control, the virus attempts to install itself to the kernel memory area of the computer, and it hooks the file system to its own code. The virus then creates a 4 KB file named C:\Babylonia.exe. This file then executes.

Execution of Babylonia.exe
When Babylonia.exe starts, it copies itself to the \Windows\System folder as Kernel32.exe, and adds its value to the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

As a result, Babylonia.exe executes each time Windows starts.

This module is registered as a system service, and as a result, it cannot be seen on the Windows 9x task list. The Trojan checks to see if the Rnaapp.exe application is running by enumerating the active processes. If it does not find a similar process, it sleeps for some time and tries again later. Rnaapp.exe is active under Windows 9x during dial-up connections. When the application is loaded, the virus attempts to connect to a virus writer's Web site in Japan.

If it is successful, the Trojan downloads a text file named Virus.txt. This text file lists a few file names (currently four). The file names are:

  • Dropper.dat
  • Greetz.dat
  • Ircworm.dat
  • Poll.dat

They appear to use a special file format with a header that begins with "VMOD." This stands for "Virus Module." The header of the virus modules contains an entry point for the module. The Trojan then downloads the files and executes them, one by one, inside its own process. By doing this, the Trojan can introduce additional functionality on the already infected system. If the system is disinfected, but the Trojan is active, the virus code is reintroduced by the dropper virus module. It creates a 17 KB application (Instalar.exe) and executes it. This file is infected by the virus. Finally, the file is deleted.

When the month is January, the Greetz.dat module modifies the C:\Autoexec.bat file. Part of the "marker" for this virus includes the following text in the C:\Autoexec.bat file:

W95/Babylonia by Vecna (c) 1999

The Ircworm.dat appears to be an mIRC worm installer. The worm seems to propagate two files:

2kBug-MircFix.exe
2kbugfix.ini

to everyone on the active mIRC channel.

The last module in Virus.txt sends messages to babylonia_counter@hotmail.com containing the text:

Quando o mestre chegara?

This information was intended by the virus writer to track the number of infections that W95.Babylonia causes.

Infected .exe and .hlp files
W95.Babylonia hooks the file system to itself and checks for .exe and .hlp file extensions. It infects such files whenever they are accessed. Infected Windows .hlp files and 32-bit PE.exe files can introduce the full functionality of the virus to new systems.

The virus uses an insertion technique (does not modify the entry point of PE files) when it infects files, probably in an attempt to avoid detection by heuristic analyzers. The virus body is attached to the end of the infected files.

As long as the virus is in memory, it cannot be easily removed from the system. This infection mechanism is very similar to the W95.CIH virus.

Wsock32.dll modifications
Another very important detail is that W95.Babylonia is able to modify Wsock32.dll when the file is not loaded in memory. The virus adds a very short hook routine to the "Send" API of Wsock32.dll similar to the Happy99 worm. This short hook routine transfers control to the active part of the virus code when an email is sent. The end result of this code is that the virus adds a MIME-encoded attachment of itself to all outgoing email, thus increasing its rate of spread. W95.Babylonia is technically a worm, as well as a virus.

The possible file names of the email attachment are:
  • I-watch-u.exe
  • Babilonia.exe
  • X-mas.exe
  • Surprise!.exe
  • Jesus.exe
  • Buhh.exe
  • Chocolate.exe

It appears that the virus has a bug in this routine and therefore only the X-mas.exe file name is used. This file appears to be the same as the Instalar.exe that is created by one of the virus modules. It has a Santa Claus icon:




Recommendations

Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":

  • Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world.
  • Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromised.
  • Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application.
  • Disable AutoPlay to prevent the automatic launching of executable files on network and removable drives, and disconnect the drives when not required. If write access is not required, enable read-only mode if the option is available.
  • Turn off file sharing if not needed. If file sharing is required, use ACLs and password protection to limit access. Disable anonymous access to shared folders. Grant access only to user accounts with strong passwords to folders that must be shared.
  • Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack.
  • If a threat exploits one or more network services, disable, or block access to, those services until a patch is applied.
  • Always keep your patch levels up-to-date, especially on computers that host public services and are accessible through the firewall, such as HTTP, FTP, mail, and DNS services.
  • Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files.
  • Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media.
  • Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Simply visiting a compromised Web site can cause infection if certain browser vulnerabilities are not patched.
  • If Bluetooth is not required for mobile devices, it should be turned off. If you require its use, ensure that the device's visibility is set to "Hidden" so that it cannot be scanned by other Bluetooth devices. If device pairing must be used, ensure that all devices are set to "Unauthorized", requiring authorization for each connection request. Do not accept applications that are unsigned or sent from unknown sources.
  • For further information on the terms used in this document, please refer to the Security Response glossary.

Writeup By: Peter Szor