First I noticed the manifest file above.
When I opened it I noticed that the BEER class is where the jar file starts execution if double-clicked.
Above are all the java code files after I decompiled the class files contained in the jar archive. Now I went into the BEER.java file, but it was heavily obfuscated with no obvious path towards what was going on. So I tried a different methodology, instead I searched for any interesting method calls in any file. I found 2 that perked my interest the most. write and invoke. Hmmm those 2 sound to me like perhaps we have a file being written to disk and executed in some manner. Let's dig a little deeper by doing a reverse lookup of the stack trace for those methods.
public class ua
{
public static byte[] v(InputStream d)
{
ByteArrayOutputStream a = new ByteArrayOutputStream();
write();
}
}
So above the write() function caught my eye. I believe here the Java ByteArrayOutputStream write method is likely being called to save a file to the victim's disk. Which file you ask? Let's see who calls this ua.v() method and what parameters they pass.
public class ue
{
public ue()
{
m = ua.v(ur.v("/jabber/server/website/listener.k"));
l = ua.v(ur.v("/instagram/mobile/chat/generic/log.txt"));
}
}
Well, there are multiple calls to ua.v(), the 2 that are readable are found in the ue constructor , so I am pretty confident that it appears that some portions of the above files (listener.k and log.txt) are being written to the victim's disk. Perhaps not the whole file, or perhaps a decrypted/deobfuscated version of those files.
public class BEER
{
public static void main(String b[])
{
ue a = new ue();
}
}
And to complete the circle, I can see that in the BEER class which was the main function that starts the execution, the ue constructor is getting called. Thus clearly when the Jar file is executed we now can show that something is written to disk.
Now to look at the invoke method call and traverse back up the stack trace again, we start with where I found the invoke method. Now I am familiar with the invoke method having done Java programming in the past. This is reflection, or a way to programmatically at run-time call whatever function/method you want in whatever class you want. Reflection is cool because you don't have to know or specify which class or method you are calling at compile time in your code, instead you can load it dynamically on the fly. This is extremely powerful but also has it's downsides, including performance. It's expensive for a java program to have to look up information about itself (reflection) while executing. The other downside as we see here is the fact that is can be abused by malicious actors to abstract and obfuscate malicious code to the point where it's near impossible to find since the code getting executing doesn't necessarily even live in any of the code your analyzing.
public class uj
{
public static void v(Method c)
{
c.invoke(null, a);
}
}
So above we see the uj.v() method calling invoke which means that some Java Class/Code was loaded from somewhere, and now it's executing that method or code. This is likely where the main damage is being done by the malicious actor. In fact when this jar file was run against a sandbox we saw it executing several command prompt commands such as these that are likely invoked with the reflection code above using the Java Runtime exec command.
exec 'cmd.exe' '/C' 'cscript.exe' 'C:\Users\ADMINI~1\AppData\Local\Temp\Retrive3314751364727523362.vbs'
exec 'xcopy' '"C:\Progra~2\Java\jre1.8.0_0"' '"C:\Users\Administrator\AppData\Roaming\Oracle\"' '/e', null, null
Above you can see from the sandbox that perhaps a VBS script (.vbs) was extracted and written to disk with the write() method we discussed above. Then after that perhaps the xcopy command was executed to get some critical files into the AppData folder where that attacker has the ability to write and tinker with files. Just to complete the circle, let's follow the stack trace back up to see who or what called the uj.v() method which triggers the invoke call.
public class ug extends uu
{
private void v()
{
java.lang.reflect.Method e;
uj.v(e);
}
public ug(String b, HashMap a)
{
v();
}
}
Above you can see that the ug.v() method calls the uj.v() method. And the ug constructor calls the ug.v() method. Just a nested obfuscated mess!
public class uz
{
public uz(byte h[])
{
jarinputstream = g = new JarInputStream(new ByteArrayInputStream(h));
String f;
HashMap d;
f = uk.v(jarinputstream);
d = new HashMap();
ug c = new ug(f, d);
}
}
And above you can see that the ug constructor was called from the uz constructor. This method is interesting too because I'm seeing code in here that seems to load (perhaps from one of those files mentioned way up top) what appears to be a Jar input (using JarInputStream) from within this jar file (so now we have inception! a dream within a dream!). And with that jar file in the uk.v() method I see some keywords (e.g. java.util.jar.Attributes.Name(); that seem to indicate to me that maybe it's loading a class file from this jar file and then calling a method within that class file within that nested jar file using the invoke method we discussed above. Interesting. Now to load the file that contains the buried or nested Jar file they used the ByteArrayInputStream object which if we follow further up the rabbit hole ...
public class ue
{
public ue()
{ byte b[];
uz a = new uz(b);
}
}
We see that the uz constructor is getting called from within the ue constructor. I found it interesting that the byte array that is being passed in and used to load the JAR file mentioned in the previous segment is declared, but never actually filled. If you are a normal java programmer, you typically declare a variable such as int x; and then perhaps a few lines later you assign it a value such as x=5; but in this case they declared the byte array b but never assign it. OR SO YOU THINK! Thru the beauty of obfuscation, they actually are filling it without you noticing it. To understand you have to dig back in your mind to your assembly language days where you learned about the Heap and the Stack. In this case, the obfuscation occurs because the malicious actor is use Java ByteCode (essentially Java assembly language) to manipulate the stack values without actually touching the high level variables names like b seen above. In the code you may see several lines like this ... CORRECTION 6/21/2016: I believe the bytecode showing up is a limitation of the decompiler, not necessarily an obfuscation technique by the attacker
JVM INSTR new #21
JVM INSTR pop2 ;
JVM INSTR dup ;
Above are just some samples of the many java bytecode / assembly instructions you see in this obfuscated mess. For example, the dup instruction duplicates the value at the top of the stack, the pop2 function pops 2 values off the top of the stack, and the new function actually allocates memory in the heap for a new class (similar to C malloc). So you can clearly see now that it's possible to manipulate the stack and obfuscate your payload very well using these java bytecode options directly in your java code.
public class BEER
{
public static void main(String b[])
{
ue a = new ue();
}
}
To complete the circle again we notice that the ue constructor that we mentioned just earlier is again called in the BEER class, so the main function that starts the execution. So this main function in the BEER class is going to for certain write files to disk and call methods from with java code. Add that on top of all the obfuscation and you can say pretty confidently before even sandboxing this, that it's probably malicious in nature, especially since it arrived in an email about an Invoice!
I hope this helped get you a layer deeper into analyzing malicious email attachments and in particular ones that contain JAR and java code files.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Best email technical support helpline number in usa. You are facing any kind of email problems call us: +1-888-511-0014.
ReplyDelete