Pages

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\svchost.cab' 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.

"Summary"


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
TDS: No
JNLP: 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:
None
Delivered malware:
(JAR)MD5 - 839d43c69935a8a93e0b9f6c3d715c53
virustotal.com - link
(EXE)MD5 - 27af067a2dd507862290779679c68b6d
virustotal.com - link


Additional Information

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

Monday, 7 October 2013

Unknown EK: "I wanna be a billionaire so freaking bad..."

NOTE: Information is based on a sample captured on 2013-10-02

I'm not sure if definition 'exploit kit' is actually applicable here. Yes, there is an exploit code copied from PSA(Packet Storm Advisory) for 'CVE-2013-2465', but I'd expect more code around it before calling it a 'kit' and I can't imagine there is a server side code exist. There is no any sort of environment validation: plugins and their version identification, initial payload encryption, data encoding, code obfuscation. Base64 encoding is used just once to 'hide' a single string. So, another 'interesting' work.

"Landing page"

URL pattern is short and simple.


The landing page is also short and simple.


The parameter name is the first hint to the possible origins of this Java exploit. 'kurban' translated from Turkish means 'victim'. The value held by this parameter is the Initial Payload location.

"JAR file"

JAR file is 'packed' with goodies. The execution begins with an attempt to exploit 'CVE-2013-2465' vulnerability.

part of PSA exploit code for CVE-2013-2465

Just before diving into screwing 'storeImageArray()' function, a single call for 'base64coder' is made to decode a single and the only encoded string.


The author was rushing because mum just called him/her for dinner and didn't bother cleaning up someone's  'base64coder' code that might have been copied from 'source-code.biz'. All encoding methods were left in even though are not used.


A few more hints pointing at the origins or one of the languages the author is speaking.


Google translated from Turkish: 'dosyayazdirici' - printing a file, 'baglantiaƧ' - open link, 'bayt' - byte. The screenshot above is a part of the code that fetches the initial payload via URL passed from the landing page. Once it's downloaded, it'll be stored in the default temporary-file directory with hardcoded filename - 'thefire.exe'.


The link to the initial payload was dead by the time the capture was performed. Judging by the filename - 'install_flash_player.exe', it could have been 'ZeroAccess'.

One rather odd thing is the name for the method performing the exploit - 'uganda'. Maybe the author's favourite country or maybe the target, who knows.


"Summary"


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


Infection vectors detected: Java
Vulnerabilities targeted:
CVE-2013-2465


Landing page
Transfer mode: plain text
Obfuscation: No
TDS: No
JNLP: No
JVM parameters: 1


Java infection vector
Captured with: Direct download - Firefox/14.0.1
Obfuscation: None
JAR hidden content: None
Initial Payload delivery method: URL
Initial Payload encryption/encoding: No
Initial Payload store location: Default temporary-file directory
Initial Payload filename: Hardcoded - 'thefire.exe'


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


Automated analysis
Exploit components:
Java JAR - virustotal.com
Delivered malware:
No sample available


Additional Information

Possibly originated from Turkey or
the author speaks Turkish