Exobot v2 update - staying ahead of the competition

Wesley Gahr, Niels Croese, July 2017

Abstract

In the last couple of months since our previous blog on Exobot we have seen many different samples of the Exobot v2 Android banking malware pass by. They have been busy developing new features for the bot to stay ahead of their competition. Several of the changes in the bot we have seen are interesting enough to warrant a new blog post, so here we go!

Modularity

The most interesting feature that has been added to Exobot (in our opinion anyway) is the module system. When the bot is started for the first time it will first try to obtain the "main" module from the C2 server and will not do anything until it gets this module. After the module is retrieved it is saved in the private app storage (/data/data/packagename/) and loaded by a DexClassLoader. The "main" module provides most of the default bot functions:

/blog/SFY20170701/main_module_functions.png
Main module functions

After the main module is loaded the bot will keep polling the server for additional modules to load (so far none are returned). Having this module system makes it easier to hide functionality (since it is not present in the bot by default) and sell pieces of functionality seperately. An example of another module could be one with socks proxy capabilities.

Socks proxy

All strings used in the Exobot code are obfuscated. Going through all these strings we noticed recent additions hinting to the implementation of a socks proxy:

/blog/SFY20170701/socks_proxy_strings.png
Socks proxy related strings

Previously we've only seen hints of a socks proxy in the C2 code. This proxy functionality could make it easier for attackers to stay hidden and bypass ip-based fraud detection. So far the strings are not used in the current code, possibly indicating that the proxy code is placed in a module.

Network traffic encryption

Network traffic has received an upgrade in the form of an encryption layer. All requests and responses (except for the module download) are now encrypted using AES/ECB/PKCS5Padding and then base64 encoded:

/blog/SFY20170701/network_traffic_encrypted.png
Encrypted HTTP traffic

/blog/SFY20170701/network_traffic_decrypted.png
Decrypted HTTP traffic

The encryption key is a hex encoded MD5 hash of a string located in the same location as the other obfuscated strings (so far set to "not-cache"). Note that the "Cache-Control" header in the request is also set to this same value, making it easier to obtain it. Exobot v2 is the only Android banking malware with an additional encryption layer above TLS.

Additional obfuscation

Some Exobot samples seem to have included additional obfuscation in the form of a loader: The original application's classes.dex file is encrypted and included as an asset file. When the Android app is started the loader decrypts the asset and uses a DexClassLoader to load the classes.dex and replaces the loader application with the unpacked application. This makes it a lot harder for static analysis tools to detect the malware and manual analysis takes more time. The loader is fairly easily recognized by the asset file (*.dat), the type of code obfuscation used and the fact that it implements a custom Application class to do it's magic as soon as the app is started.

/blog/SFY20170701/loader_obfuscation.png
Obfuscated loader code

Samples with loader

1cd3095b176520e4bf7d3fa86ec91e852ee93b2172c8bd3113f91e2569a7c481 (10 Jul 2017)
ca2cc26e81196a2031a5cdeda91a6624ba9d34e03e5b1448dd682b0215134d15 (10 May 2017)
77e26712490e8ec681881b584c5e381af0dcece21f0dcfa483661f125a399a2d (25 Apr 2017)
8e9bdb1f5a37471f3f50cc9d482ea63c377e84b73d9bae6d4f37ffe403b9924e (21 Apr 2017)
ca859564cfbfca3c99ab38c9cb30ad33ec9049fe67734bae9d9b69cd68845188 (17 Apr 2017)
59ada6b530bd2c7c15d8c552c7ebf3afcc14976bfa789a6e2c2fca3e354baab0 (11 Apr 2017)

For sale through a public website

Another noticeable change in tactics seems that the actors behind Exobot are selling their service using publicly available website, including screenshots of their Panel.