I recently saw a malicious invoice email with a ZIP file attached. Inside the zip file was a jar file. I did a quick blog recently on how to
decompile a jar file contents and see the actual Java code. So I did that on this email and here is the
nasty looking obfuscated code. Now this malicious jar file was sandboxed and so we know what it was doing. Essentially is extracts and drops a visual basic script (.vbs) file and executes it to deliver the payload. But if you were to look at the Java code linked above you may wonder how on earth the attacker accomplished that? Considering how deeply obfuscated the java code is, you cannot find any reference to command line executions, etc. So I did my best to take a stab at figuring out how this java code actually executed and worked. I don't believe I figured it all out, but I'm hoping I'm getting close.
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
- pagerank botnet sql injection walk-thru
- DOM XSS 101 Walk-Through
- php injection ali.txt walk-thru
Top Github Contributions
- Qualys Scantronitor 2.0
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
