Java.Cogyeka
Recently there has been a lot of attention drawn to the vulnerabilities in Java and how they can lead to malware being created. However, it is worth noting that a vulnerability is not always required for malware to exist, as is the case with Java.Cogyeka. While this threat does not exploit any vulnerability in Java itself, it is written in the Java language and performs numerous malicious activities, which I intend to explore throughout this series of blogs.
Java.Cogyeka was discovered in July 2012 and is still active now. This malware has five features, which I have broken down into the following categories:
- Propagation through autorun.inf
- Stealth techniques
- Downloader functionality
- Obfuscation
- Infostealer functionality
Other Java malware we have seen does not have this combination of malicious features. Typically, when we encounter Java in a malicious program, its only purpose is to download other malware, which then performs further malicious actions. However, Java.Cogyeka is a malicious program in its own right and with its own purpose—the Java code itself is being used to perform malicious activities without requiring an additional malicious module. This makes it the most comprehensive Java-only malware that I have ever come across.
This is the first in a series of three blogs on Java.Cogyeka and in this blog I will discuss the following features:
- Propagation through an autorun.inf file
- Stealth techniques
- Downloader functionality
The remaining functions, Obfuscation and Infostealer functionality, will be discussed in future blogs.
Propagation through an autorun.inf file
As previously mentioned, this worm uses autorun.inf to spread and attempts to copy itself to a removable drive using a file name in the following format:
- %DriveLetter%:\RECYCLER\[SID]\[RANDOM FILE NAME].[THREE RANDOM LETTERS FILE EXTENSION]
It then attempts to copy an autorun.inf file to the root folder of the removal drive in order to execute the worm whenever the removable drive is inserted into another computer.
Technically, a problem exists when creating the autorun.inf file on the removable drive. By design, Java operates within a sandbox and cannot interact directly with the resources of the operating system. Because of this, a Java application cannot directly determine the drive letter of a removable drive, but the Java Native Interface (JNI) offers a possible solution to this problem. The worm needs to know the drive letter of a removable drive in order to store and use the autorun.inf file effectively. To solve this problem, it attempts to call a native WIN32 API method GetDriveType through a Windows binary DLL file that the malware author made specifically for this purpose. This DLL is then accessed indirectly by the Java code using JNI. Symantec also detects the malicious DLL file as Java.Cogyeka.
Figure 1. Determining the name of the removable drive
Stealth techniques
Java.Cogyeka uses certain stealth techniques when compromising a computer. It is doubtful that these techniques successfully trick users of the compromised computer or fool security products for that matter. The threat uses three stealth techniques.
Compromised removable drive icon
The removable drive that is compromised by this malware has its drive icon changed to a folder icon. It is easy to change a drive icon, the malware simply adds “icon=[PATH OF ICON IMAGE]” to the autorun.inf file. This malware uses the folder icon from the shell32.dll file.
Figure 2. Removable drive with changed icon
Changing the icon of an executable file is a well-known camouflage technique. If an executable file has a document file icon, like Microsoft Word or Adobe PDF, users may misidentify the executable file as a document file. However, changing the icon of a removable drive is a slightly different case. I do not know why the malware changes the icon of the removable drive, but this is one of the malware's meaningless stealth techniques. If found on the compromised computer, it can be seen as a sign that the malware may be present.
Repacked, not copied
Previously, I stated that the malware copies itself, but this is not entirely accurate. The malware actually repacks itself to the following location:
- %Temp%\jar_cache[RANDOM DIGITS].tmp
The malware spreads itself as a JAR file. It may try to change the hash value of the JAR file by adding random bytes. The JAR format is like a Zip format that is used to pack Java classes into one file. The malware attempts to add random bytes to an extra field in the Zip headers. However, most security vendor virus scanners can extract Zip files to scan files contained in the archive. They do this so that they can scan the malicious .class file within the JAR file and detect it even though the hash value of the JAR file has changed.
As a result, the malware's modification of the hash value of the JAR file is meaningless.
java.exe instead of a system process
The malware copies java.exe to the following location:
- %Temp%\hsperfdata_[USER NAME]\[SYSTEM EXECUTABLE FILE NAME].exe
It uses one of the following system executable file names:
- csrss
- explorer
- lsass
- services
- smss
- svchost
- winlogon
Users, even if they have administrator privileges, cannot end these processes, except for the explorer.exe process. The malware aims to deter users from ending the process that the worm is running on. However, it uses “javaw” in the StubPath registry subkey, as described in our detection write-up, instead of "[SYSTEM FILE NAME].exe" with "SYSTEM FILE NAME" representing one of the processes listed above. Users who find this malware running as a system process cannot manually end the malware process by using Windows Task Manager. Third-party software, however, can be used to end the process. It is also worth noting that Symantec Endpoint Protection and Norton Internet Security/Norton 360 products will end this process automatically as soon as it starts.
While the malware author makes it inconvenient for users to end this process manually, the technique used is far from successful.
Downloader functionality
After the malware compromises a computer, it attempts to connect to a server in order to download an additional module. Apparently, this module is a JAR file. It downloads and extracts class files into its memory space and then loads them with the ClassLoader Java class. Through any class loading, a malware author can gain control of the compromised computer. The malware can also download updates with new features for itself or other modules.
To be continued…
This blog is an overview of Java.Cogyeka and how it works to compromise computers. The next blog in the series will discuss obfuscation techniques used by the worm as well as its main module.
