Tuesday, 8 October 2013

Unknown Java Malware: "Forget it, Jake. It’s Chinatown."

NOTE: The information is based on a sample captured on 2013-10-03

Another 'piece of art' work by some actor learning how to 'copy/paste' code. There is nothing wrong with copy/paste as long as you understand what the code does. Judging by the amount of unused code that even includes 'System.out.println' statements, seems the author was afraid to change and accidentally break it. This in turn helped to narrow down a potential region where the Java code is coming from. This is also another example of Java malware that is not using any exploit code, but targeting users with administrator privileges on their machines. I'll tag it 'Java Malware' as it doesn't fit the definition of an exploit kit. The real danger of this type of malware is stealthiness - as long as the payload it delivers is not being detected by AV(and it's quite easily achievable).

"Toto, I've a feeling we're not in Kansas anymore."

The URL pattern for this sample is short and simple.

The landing page doesn't have any sophisticated parts either, but at least there are simple checks for Java presence and OS type performed before pulling down Java JAR file.

checking for Java Web Start or JNLP support in the browser

Even though the checks above are performed, JNLP technology is not utilized to deliver the JAR file. These checks simply identify if Java RE is present. Returned 'boolean' value steers the execution and if found to be 'false' will stop the script execution and exit. If Java is found the following condition is checked next.

OS type check and JAR request through 'document.write'

This Java Malware targets Windows machines only. Even if Java is present the script execution will stop if no Windows OS is found. The detection is based on browser's 'User-Agent' value.

"This one time, at band camp..."

As mentioned earlier, there is no exploit code in the JAR file. The execution starts with creating a simple folder structure on drive 'C'.

call for 'docmdsyn' to create two folders

'docmdsyn' function calls 'cmd.exe' to run the commands

Regardless of the outcome of running the two commands, the execution will continue with a request for the Initial Payload using hardcoded URL and a 'borrowed' Java code.

hardcoded URL & 'downloadFile' function call

'downloadFile' function

Thinking that 'this url is error' sounds like rather strange English, I did a search for 'System.out.println("this url is error");' expression and noticed that most of the search results are pointing at Chinese websites. From what I can figure out using Google Translate, the websites are forums/boards used by Java developers to exchange knowledge and share different code samples for different purposes. The code samples there are almost 100% matching the function in the screenshot above.

The Initial Payload is XORed with a single value key - '0x12'. The encoded version of the payload will be stored in 'c:\users\public\' and passed to a function do decode it.

part of 'xorEn' function code

There are tons of unused code and the declaration of 'XOR_CONST' variable is just a small example of it. Hoping to find something interesting, did another search using just a part of the declaration statement - 'public static final byte XOR_CONST' . Surprisingly, the search result page contained links pointing at the same Chinese websites with Java code samples that match quite closely the code in the screenshot above even including the 'xor' key value. So, if not the author's location, at least some parts of the source code seem to be specific to one particular geographical region.

Once the Initial Payload is decoded, it'll be stored in 'c:\users\public\svchost.exe' and executed using the same 'docmdsyn' function. It's not all though. There is a small bonus in the form of some registry changes and a clean up operation.

Windows Terminal Services changes

Number of commands will be executed to enable Windows Terminal Services and delete the encoded Initial Payload. One of the registry key changes enables spawning 'Windows Command Prompt' at the login screen by hitting a key on the keyboard a few types - also known as 'sticky keys' vulnerability.


General Information
Name: Unknown
Date captured: 2013-10-03
Date analysed: 2013-10-07
Source/Credits: Live Fiddler capture

Infection vectors detected: Java
Vulnerabilities targeted:
'sticky keys' - login bypass

Landing page
Transfer mode: plain text
Obfuscation: No
JVM parameters: None

Java infection vector
Captured with: Java 1.7.17
Obfuscation: None
JAR hidden content: None
Initial Payload delivery method: URL
Initial Payload encryption/encoding: XOR single value key - 0x12
Initial Payload store location: c:\users\public\
Initial Payload filename: Hardcoded - 'svchost.exe'

Adobe infection vector
Captured with: Not implemented
Initial Payload delivery method:
Initial Payload store location:
Initial Payload filename:

Automated analysis
Exploit components:
Delivered malware:
(JAR)MD5 - 839d43c69935a8a93e0b9f6c3d715c53 - link
(EXE)MD5 - 27af067a2dd507862290779679c68b6d - link

Additional Information

Some of the code used seems to be
coming from Chinese websites sharing
public Java code samples

No comments:

Post a Comment