Tag Archives: security

Obfuscations
In my previous blog, I discussed some stealth techniques Java.Cogyeka uses. These stealth techniques are not effective at deceiving users or security researchers, but their use proves that Java malware is continuously improving.

Aside from the stealth techniques, Java.Cogyeka is designed to evade security researchers through various obfuscation techniques. Some are effective, some are overdone. Overdone obfuscation techniques will often cause malware to be less effective.

Java.Cogyeka uses three obfuscation techniques:

1. Autorun.inf obfuscation
The autorun.inf file helps Java.Cogyeka spread through removable drives. This file is made up of three parts:

1. Action
2. Icon
3. ShellExecute

It must contain a ShellExecute function in order to execute itself in the removable drive Recycler folder. As I wrote in my previous blog, Java.Cogyeka employs a folder icon and also displays the message “Open folder to view files.”

Java.Cogyeka uses an obfuscation technique to ensure that security scanners do not detect autorun.inf. The obfuscation technique inserts garbage between entries. The garbage consists of a control character between 0x00 and 0x1F. This obfuscation technique is often found in malicious .inf or .html files.

Figure 1. Obfuscation technique fills in garbage

Uppercase and lowercase capitalization is used randomly in the ASCII characters to create inconsistency. The volume of the garbage is between 0 and 50 bytes and it is in clusters located alongside the tokens in a crafted autorun.inf file. Symantec detects the autorun.inf file crafted by Java.Cogyeka as Java.Cogyeka!autorun.

2. Zelix obfuscation tool
This Java malware spreads itself as a JAR file with 15 class files (a.class to o.class). Originally, these classes may have been named based on the functionality of each class. The Java obfuscation tool—named Zelix KlassMaster—modifies class names, method names, Java byte codes, and strings.

Figure 2. Zelix bitmap of encrypted and decrypted strings with XOR table

The Java obfuscation tool is not malware but rather a legitimate tool. Java developers may want to hide important data and code in Java class files. It is difficult to decompile a Java class file if Zelix obfuscation has been applied.

Java.Cogyeka is not the only object to use this tool; many malicious Java applets that exploit Java vulnerabilities, for instance, are also use this tool.

3. Network connection obfuscation
Determine server name and port number
To download an additional module from the command-and-control (C&C) server, Java.Cogyeka has to connect to it. However, it is difficult to successfully connect an existing server while also attempting to connect many fake servers. It takes a long time to download an additional module this way. The difficulty results from the complicated server name and port number.

The C&C server’s host name is made up of five to eight random letters and the randomly selected domain is based on a dynamic DNS. A random seed based on the time the malware is run is used to select the random letters. The domain is selected from 22 famous dynamic services by the same random seed used to obtain the random letters.  The port number is also randomly generated by the same random seed. The seed number is based on a 64-bit integer.

Figure 3. Random seed used to determine host name, domain name, and port number

There is a possibility that the generated C&C server name is the same as a legitimate one hosted by another user in the dynamic DNS service. If so, the malware tries to connect the server name with a generated TCP port number. If the server denies connection with the port the connection will be closed immediately, but the malware has to wait until it knows the connection cannot be established.

Negotiation
The protocol used to download an additional module is the original one, but it is obfuscated. The protocol will likely establish a secure connection because it uses a stream cipher created by a pseudo-random generator.

Java.Cogyeka and the server program have the same random seed and pseudo-random generator. The malware negotiates by exchanging two byte streams.

Figure 4. Java.Cogyeka and server program negotiation

Java.Cogyeka generates the first byte stream, and its length, with a pseudo-random generator and then sends it to the server through a TCP connection. The server then receives the data. If the server was created by the malware author, the server program runs and has the same random seed and pseudo-random generator as the malware. The server can verify the byte stream, and the length, by using the same generator. To perform a double check, the server creates a second byte stream. The malware receives the second byte stream and verifies the data with a byte stream it has generated.

If the negotiation is successful, the malware has confirmed the server has the same random seed and pseudo-random generator.

Downloading a module
After a successful negotiation Java.Cogyeka downloads the settings, including the size of the module to download, but the settings are encrypted by the stream cipher. After obtaining the size, it downloads a module encrypted by the stream cipher. The settings include a hash value of the downloaded module. The malware can make sure the download is successful by using SHA-512.

Made with a purpose
I discussed three obfuscation techniques used by Java.Cogyeka. The obfuscation techniques used by the malware are somewhat complicated, but the autorun.inf file in the malware should be easy to detect by security scanners. Part of the obfuscation technique used for the server name and port number is ineffective because of too much obfuscation. The streaming cipher may be effective against network-type security scanners. This obfuscation technique demonstrates that this malware was not created as a hobby, but instead, made with a specific purpose.

To be concluded…
The third and final blog in this series will show the purpose of the malware as well as what information it obtains and how it obtains it.