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 |
No comments:
Post a Comment