Discovered: April 20, 2000
Updated: February 13, 2007 11:34:12 AM
Also Known As: Win32.CTX.10853, DHF
Type: Virus
GriYo, a notorious member of the 29A virus-writing group, is responsible for many successful polymorphic viruses such as
W95.Marburg and
W32.CTX . His speciality is the creation of difficult-to-detect viruses. He released his latest creation, W32.Dengue, on his home page in April 2000. At this time, the virus is not known to be in the wild.
W32.Dengue is probably the most complex virus written this year. The virus, like several of GriYo's other virus creations, is a slow-polymorphic, inserting PE file, and in-memory Win32 infector. The virus replicates properly on all major Win32 platforms such as Windows 95/98 and Windows NT/2000.
GriYo based the virus on the W32.CTX virus family. W32.Dengue could be called W32.CTX_II since its polymorphic engine shows many similarities to W32.CTX. However, W32.Dengue uses in-memory infection on Win32 systems, which makes the virus sufficiently different from GriYo's earlier creations.
Generally, W32.Dengue is more difficult to detect than W32.CTX. Like W32.CTX, W32.Dengue uses multilayer polymorphism and an entry-point obscuring (inserting) file infection strategy. This means that execution of the virus code does not always occur when an infected file is executed.
The virus gains control only if a particular function of the original application is called. That location is randomly selected by the virus by replacing the original code with a CALL instruction to start the virus decryptor. Since the virus code is encrypted with multiple layers of polymorphism, and the virus body is very long--10853 bytes--the virus decrypts itself very slowly in some circumstances, especially on older machines. The encryption of the virus code uses various methods such as XOR, NOT, as well as SUB, ADD, INC with a byte, word, or dword key. Since the virus does not pay attention to the selected methods, the virus code becomes visible (unencrytped) in some cases. This happens when one polymorphic layer uses INC (increment one byte) while the next polymorphic layer selects DEC (decrement one byte), or an equivalent (SUB, etc.) method. In this situation, the virus can be detected very easily. However, in the majority of cases, the virus code is encrypted, and its detection is more difficult.
W32.Dengue uses Explorer.exe as its main host. The most important feature of this virus is the in-memory infection of Explorer.exe, which is always running on Windows NT/2000 and Windows 9x. When the virus code gets control, the decrypted virus gets the API addresses of all functions the virus needs to call (Win32 APIs such as CreateFileA, CreateFileMappingA, WriteProcessMemory, IsDebuggerPresent). The API names are checked using the checksum of the API strings only.
Thereafter, it checks to see if an Explorer.exe process is running in memory by using platform-specific APIs. Some of these process and module query APIs are available in both Windows 9x and Windows 2000. The virus also pays attention to the Windows NT platform and uses Psapi.dll (if available). The virus injects its code into the Explorer.exe API, DefWindowProcA. The virus runs its infection thread from there, searching for PE (Portable Executable) files to infect. Files that are not GUI applications or DLLs are not infected. The virus infects by appending its virus code to the last section of the PE image whenever the last section is not relocation. If the last section is relocation, the virus overwrites the relocation area and turns off the base relocation field in the headers. In some cases, the infected files will not be any larger after infection. The virus randomly selects a possible instructions start (0xE8, 0xFF) in the code section of the host program and replaces it with a call to the polymorphic decryptor of the virus in the last section. The garbage instructions contain memory access instructions to a garbage block of the virus body. These fake instructions are supposed to hide the real instructions responsible for decoding the virus body.
The size of the infected files is always divisible by 101. The virus searches for new files every five seconds, making it a slow infector. W32.Dengue is also a retrovirus. It deletes the checksum files of several antivirus programs such as avp.crc, anti-vir.dat, chklist.cps, chklist.ms, and ivp.ntz.
An interesting side effect of the virus is that Explorer.exe might cause page fault errors to occur. The virus uses SEH (exception handling) to avoid this situation, but Explorer is blamed because of a fault in the virus code. Since this error condition can happen, and Explorer.exe plays an important role in the Windows graphical interface, the system kernel might be able to restart the faulty process. Win32 systems typically try to execute Explorer.exe when Explorer.exe stops working properly. Since Explorer.exe might be infected, the virus is likely to be autoloaded when there is an error condition.
Other texts in the decrypted virus body:
[
Dengue Hemorrhagic Fever BioCoded by GriYo / 29A ]
Disclaimer: This software has been designed for
research purposes only. The author is not
responsible for any problems caused due to improper
or illegal usage of it.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