Sunday, December 31, 2017

Happy New Year!








The Joe Security team wishes you success, satisfaction and many pleasant moments in 2018!

Friday, December 22, 2017

Loapi - from Static to Dynamic Instrumentation



You might have already heard about Loapi - the Android malware which will kill your phone due to exhaustive bitcoin mining. Loapi was found by Kaspersky, an excellent write-up can be found here: Jack of all trades.

While Kaspersky's blog post gives a good overview, it does not provide a fine-grained analysis to deeply understand Loapi's behavior. Interesting forensic information, like Loapi's unpacking and obfuscation techniques being left out.

In our opinion, Loapi is one of the first Android trojans which uses multi-stage unpacking and dynamic code loading. Therefore, this blog post is dedicated to explaining how unpacking works and also shortly outlining why Loapi is challenging to be dynamically analyzed - especially through instrumentation approaches.


Layer 1


If we launch Loapi in Joe Sandbox Mobile we get two executed methods:


The more interesting method is attachBaseContext:


The method constructs the DexClassLoader class and contains some very large string. If we browse the code we can indeed see that the long string is decrypted (first base64 decoded) and then stored to a zip file:


The zip file is mapped by the DexClassLoader:


Next method etxtfvw.cqwwrwk.attachBaseContext is called via Java Reflection. Jave Reflection is super cool because it lets you dynamically call method during runtime. During static analysis, it is not clear what method is actually called.



Unfortunately, we do not have any method with that name in the Joe Sandbox report. Why that? Because we first have to understand how static instrumentation works.

Static instrumentation is a method to extract additional runtime information from a program. To achieve that, a program is statically analyzed and new code is added (instrumentation). The purpose of that code is often to log method calls, arguments, class invokes etc. For APK the process looks like this:


To problem with Loapi is that the modified APK is loading new code from itself - to be precise from a string in the APK code. Further, the string is encrypted, then decrypted at runtime and finally loaded. Due to that, no instrumentation takes place and the behavior of that code is fully hidden.


Dynamic Instrumentation


So what can we do? The answer is Dynamic Instrumentation. The instrumentation of the original APK can be done in a way that the newly added code not only logs method calls but also fully controls it. In our case, we can instrument the DexClassLoader constructor call. If it is called we can instrument the DEX code that will be loaded:

So we added a dynamic instrumentation of DEX code. Pretty cool? Yes and, for Loapi this is really a necessity.

Thanks to dynamic instrumentation we can now inspect function etxtfvw.cqwwrwk.attachBaseContext:




We can see an interesting String called /system/framework/XposedBridge.jar and some code to kill the current process. Anti Analysis? You are right. The Xposed Framework is used in CuckooDroid / Cuckoo Sandbox and likely also in some Checkpoint products. Loapi checks the stack trace for method names used by this hooking Framework.

Layer 2


So what is next? After the Anti Analysis check method, YRkfJMV is called:
Let us have a brief look at it:




Another DEX file? Right. This time it is an encrypted file inside the APK resources:



Please note that any API call in method YRkfJMV is done via Reflection. It's important because this is already unpacked / dynamic code. Finally, the newly created DEX file is loaded via reflective constructor call:


From a high-level perspective, the unpacking can be understood as follows:



Any string in the original APK, as well as the stub, are XOR encrypted:


Final Words

Loapi uses a multilayer unpacking approach to obfuscate its payload. It first decrypts a stub which contains an Anti-Analysis technique and the same stub will then decrypts the main trojan. Loapi uses heavily string obfuscation and Java Reflection in the unpacker. All those approaches are well known for Windows malware and now are more and more transferred to Android. 

With dynamic instrumentation, Joe Sandbox Mobile can inspect, instrument and control any DEX code - loaded from a decrypted resource file or downloaded from the internet. For any DEX code, Joe Sandbox Mobile provides some deep content, including method calls, arguments, and other dynamic data. This provides a deep understanding of threats and a best in class malware detection.

Interested in trying Joe Sandbox Mobile? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!

Full Joe Sandbox Analysis Repor of Loapi.


Tuesday, December 5, 2017

Threading based Sleep Evasion



Recently we came across an interesting sample: MD5: 52540f430c060a7e5753c999891514a1. A first look at the analysis revealed the following characteristics:




Besides a small spike in the classification chart towards Evader, the sample does not show any interesting behavior. It becomes more intriguing when we look at the slideshow, there we can see that the executable crashes on launch.

If we dig in further and look at the process we find some interesting sleeps:



The sample sleeps twelve times 0.1 seconds and one time 30 seconds. Thanks to Hybrid Decompilation we can easily understand the goal of the two delays:


This is the entry point of the sample. It first initializes a variable named _v8 and then creates a thread and passes _v8 by reference. Right after it sleeps for 30 seconds (0x4e20 >> 1 + 0x4e20 = 30'000). Finally, it uses the variable _v8 to calculate a function address which is added to 0x40b917. This function address is also called (passing _v12 as an argument).

Let us now have a look at the thread entry point, function 408B56:


The function is very simple. It is an endless loop that increases _a4, which is the address of _v8. For each increase, it sleeps for 0.1 seconds. When Sleep in the main function ends, _v8 is equal to 300 because the Sleep was for 30 seconds and the thread function increases _v8 by one for every 0.1 seconds.

As we saw at the beginning, the sample crashes, so the calculation of function address and _v8 must be wrong. But why?

Sleep evasions are a common trick to evade sandboxes. The simplest trick is just a sleep which delays execution of the payload. The delay usually is greater then the time the sandbox executes the sample. As a result, the payload is never executed during analysis.

To tackle this evasion, sandboxes automatically modify sleep values. In Joe Sandbox this can be defined by the user:


Let us assume we used the command _JBShortenSleepsGreaterThan(20000, 100) in the analysis above. With this setting, all sleeps greater than 20 seconds are shortened to 0.1s.

What is the effect on the code above? Well, the sleep in line 11 does not take 30 seconds anymore but rather 0.1s:


Due to that, the thread function 408B56 only runs for 0.1 seconds and _v8 is equal to 1. Therefore the function address called in line 12 is wrong and the sample crashes.

To summarize, the sample exploits the fact that sandboxes shorten sleeps/delays based on a threshold.

Full Joe Sandbox Report (with evasion working) below:


By changing _JBShortenSleepsGreaterThan we can easily bypass the evasion and see that sample is a ransomware:






Interested in trying Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!


Monday, November 27, 2017

Retefe loaded with new MUILanguage Sandbox Evasion


Lately, we came across a new Retefe version which uses some nice trick to bypass sandboxes (Retefe is a well know and sophisticated e-banking trojan). The initial analysis looks quite normal, there is no suspicious behavior, no dropped files, domains requests etc.





One interesting fact though is the WMI query:



If we extract the memory strings (strings taken from memory dumps) we detect a fully VBA script:




The interesting function performing the WMI query is called "CheckTest":



The function enumerates the MUI languages, which basically is a list of all installed languages for the Windows interface (MUI stands for Multiple User Interface). If only one language is installed, and this language is en-US then Retefe will not execute any payload.

Within 2 working days we added a new VM to Joe Sandbox Cloud which has several language packs installed:


Executing Retefe on that multi MUI language machine reveals all the IOCS & payloads:







Have a look at the full Retefe analysis report:




Interested in Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!