Triage for Android


We are extremely excited to announce the release of Triage for Android, a project we’ve been working on for some time. This major update expands our Hatching Triage sandbox to also support Android analysis, enabling automated behavioral analysis of mobile malware samples. The new module can:

Submitting an Android analysis doesn’t need you to do anything special - it is all bundled into the same Triage interface as Windows. Simply submit the APK file using the Automatic profile (selected by default), and Triage will detect the file type and launch and Android VM. You can then interact with this device using Triage Monitor.

In this blog post we will use the Anubis Banking Trojan as a case study for techniques abusing overlays, such as its persistence and infostealing functionality. However, as per our Windows analysis capabilities, we support many other Android malware families out of the box.

What are overlays?

Overlay attacks involve malicious code trying to override the window layout of a legitimate application (an “on-top” behavior) with another “fake” one, usually for the purpose of stealing confidential data or going through the process of a payment (as is the case with banking trojans).

These kinds of attacks take the form of a phishing attempt to lure users to enter their credentials or bank card numbers in an interface that resembles that of a legitimate app, duping the user into believing that they are dealing with the real application or service.

How it works

When started, the malicious code will check the name of the application in the foreground, send the result to the C2 server, then download the UI code (or web page) specific to the target app. The malicious code will then overlay the original window layout of the target app with its fake counterpart.

To accomplish the first step, a lot of these samples make use of Android’s AccessibilityService. This service is aimed at people with disabilities to help them interact more conveniently with their devices. A user has to enable this feature from the settings for an app before it can have access to this service/feature.

Once the app is registered with the accessibility service, it could:

With the basics covered, let’s now take a look at Anubis.

Anubis banker

Anubis is one of the most famous banking trojans that make use of overlays. It started out around 2017 and has received regular refinements and updates ever since. This particular kind of banking trojan originated back in 2016 with a sample called ‘BankBot’ - this in turn spun off a number of other families that are based on the same principle: LokiBot (2017), Razdel (2017), MysteryBot (2018), and ComeBot (2019).

Example report with extracted config for Anubis

Anubis doesn’t limit itself to only the use of overlays to steal banking credentials, it has additional features and capabilities which can be plugged-in at runtime. Once installed Anubis can also:

The sample would normally start off by setting up its configurations, which is done through communicating with the C2 server to set up the initial values. It then initiates a session with the C2 through which it can update its payload and keep listening for commands to execute based on the current environment.

Setting the configurations

Receiving commands from the C2 server

Runtime permissions

Now we will take a look at an excerpt of the AndroidManifest.xml file of an Anubis sample:

    "package_name": "wocwvy.czyxoxmbauu.slsa",
    "launcher_activity": "wocwvy.czyxoxmbauu.slsa.ncec.myvbo",
    "permissions": [
    "services": [
            "name": "wocwvy.czyxoxmbauu.slsa.egxltnv",
            "permission": "android.permission.BIND_ACCESSIBILITY_SERVICE",
            "intent_filters": [


We can see that the sample requests the android.permission.SYSTEM_ALERT_WINDOW permission, which is needed for it to be able to draw on top of other foreground applications. Starting from Android 6, an app is required to explicitly declare that permission in the manifest.

In the same screenshot we also see a service with an obfuscated name (wocwvy.czyxoxmbauu.slsa.egxltnv) which has the permission: android.permission.BIND_ACCESSIBILITY_SERVICE. This just means that only the system can bind to that service, and once the user grants it the permission from the settings, the malicious app can start to receive AccessibilityEvents accordingly.

In the manifest declaration of the service, a configuration file has to be defined which specifies the types of the event that the malicious app is interested in receiving:

    xmlns:android="" />


Once it has been granted the permission, the application will monitor attempts to uninstall it and effectively prevent the user from completing them:

At this point the malware will be able to know which applications are being launched on the device, and once that happens it will report to the C2 server which will serve it a web page. This web page will be rendered using a WebViewClient that loads a fake interface (specific to the target app) for the user to enter their credentials in.

Injection activity

Further, the app will also ask for the permission to receive SMSs by the system, which will enable it to collect OTP messages received as part of the payment process.

Interestingly, it should be noted that the malware could simply grant itself these permissions at runtime, given that the user had enabled the accessibility settings. However such usage was not observed to have been implemented in the samples.

Triage analysis

Running the sample through our sandbox can give us some information about what it does.

The malware begins with requesting the accessibility permission (which it will usually spam until granted). It does that by sending an intent to the system via a call to:

startActivity(new Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS));

In the sandboxed environment, we will automatically grant the sample all the permissions it requests in order to see how it will behave in those conditions.

Now, looking at an excerpt of the logs we can see a particular entry for a file being read:

*droidy.File ts=3363462918 pid=4740 srcpath=/storage/emulated/0/id.txt dstpath= kind=Read

The sample reads an id.txt file from external storage, which contains what seems to be an ID of this bot. That file gets dropped by downloading it from the C2 server. On application startup, it reads that value which it uses to communicate with the C2 server throughout the session.

We can also examine the SharedPreferences that the application writes to, where we will see some entries like:

*droidy.SharedPreferences operation=Put key=swspacket
*droidy.SharedPreferences operation=Put key=VNC_Start_NEW value=
*droidy.SharedPreferences operation=Put key=Starter value=
*droidy.SharedPreferences operation=Put key=urls value=ZWViZGQ3NjRjOGZlOWNjMjAzODhhNzFhNzg4MDJi
*droidy.SharedPreferences operation=Put key=urlInj value=
*droidy.SharedPreferences operation=Put key=interval value=10000
*droidy.SharedPreferences operation=Put key=del_sws value=false
*droidy.SharedPreferences operation=Put key=RequestINJ value=
*droidy.SharedPreferences operation=Put key=RequestGPS value=
*droidy.SharedPreferences operation=Put key=save_inj value=
*droidy.SharedPreferences operation=Put key=getNumber value=false
*droidy.SharedPreferences operation=Put key=spamSMS value=

This shows an interesting part about the sample as these are the configurations stored by the malware for its services to consume. Some of them are initialized at startup e.g. the C2 URLs for VNC that it communicates with. While the other values will be obtained from the C2 server. Based on the messages exchanged between the client and the server, the sample will know which functionalities to enable at runtime.

Some interesting configurations include:

VNC_Start_NEW       -->  URL for the VNC client to use for video streaming.
del_sws             -->  Flag to delete/ leave the SMS messages sent by the sample.
network             -->  Flag to enable/ disable location updates through the 'network' provider.
gps                 -->  Flag to enable/ disable listening for location updates.
save_inj            -->  The list of applications that will trigger the overlay injection.
getNumber           -->  Flag to get the numbers of the user contacts.
vnc                 -->  Flag to enable/ disable screen recoder.
cryptfile           -->  Sets the status of the file system encryption.
key                 -->  XOR key used for encryption.
keylogger           -->  Flag to enable/ disable keylogger.
recordsoundseconds  -->  Flag to enable/ disable sound recorder.
spamSMS             -->  Flag to do SMS spamming.

The C2 URLs are extracted in the triage report:

Anti-analysis techniques

Many variants of Anubis would not implement any malicious code at all in order to defeat static analysis attempts, and as well, bypass Google Play Store’s security control. Instead, it will unpack its modules dynamically at runtime.

When checking the file accesses made by the sample we can see that it drops a .jar file and loads it at runtime as shown in:

*droidy.File path=/data/user/0/com.xfhrpkcehqn.mqrvmxmd/app_files/xywqetxdjxvi.jar kind=Create
*droidy.File path=/data/user/0/com.xfhrpkcehqn.mqrvmxmd/app_files/xywqetxdjxvi.jar kind=Write
*droidy.File path=/data/user/0/com.xfhrpkcehqn.mqrvmxmd/app_files/xywqetxdjxvi.jar kind=Read
*droidy.File path=/data/user/0/com.xfhrpkcehqn.mqrvmxmd/app_files/xywqetxdjxvi.jar kind=Read
*droidy.File path=/data/user/0/com.xfhrpkcehqn.mqrvmxmd/app_files/xywqetxdjxvi.jar kind=Delete
*droidy.File path=/data/user/0/com.xfhrpkcehqn.mqrvmxmd/app_files/xywqetxdjxvi.dex kind=Delete

We can also see that this kind of behavior is detected and reported by a signature in the Triage output.

When analyzing the dropped payload we found that the dropped Dex has pretty much the same malicious services. Roughly, the same components are registered in the AndroidManifest.xml across the samples.

The installed apk loads the dropped .jar file via a ClassLoader instance, and overrides the ContextWrapper.attachBaseContext() method which delegates all application context related calls to a new Application instance, essentially replacing the benign application with a malicious one - this is a common technique used by packers.

Analyzed samples:



Overlay attacks are a threat especially for devices running Android versions lower than 10. Starting from Android 10 Google has deprecated overlay behavior, although it is still possible for the malware to use the AccessibilityService features for other malicious activities as outlined above.

Triage for Android is now available on the public server at We will be expanding on the available detection and functionality in future updates, and as usual feedback and suggestions are always appreciated. You can reach us using the feedback form on the website or via Twitter.

Not signed up yet? Head over to and register right away!

You may also like: