Triage for Android

2020-08-11

Written by
Muhammed Ziad

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:

Interact in realtime with Android through our UI
Detect suspicious use of the Android APIs.
Unpack dynamically loaded .dex files.
Capture dropped payloads as well as monitor accesses to the filesystem.
Analyze network traffic.
Monitor application related processes and services.

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:

Read text from the screen.
Recognize what applications are running in the foreground.
Write input into text fields.
Perform gesture recognition.
Receive events containing actions performed by the user such as clicking on views.
Seamlessly perform actions on behalf of the user.

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:

Record audio
Record user screen
Steal SMS data
Log keystrokes
Encrypt storage directories.
Listen for user location as well as device sensors updates.
Spread itself through sending messages to the user’s contacts.

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.

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": [
        "android.permission.ACCESS_FINE_LOCATION",
        "android.permission.GET_TASKS",
        "android.permission.RECEIVE_SMS",
        "android.permission.READ_SMS",
        "android.permission.WRITE_SMS",
        "android.permission.PACKAGE_USAGE_STATS",
        "android.permission.SYSTEM_ALERT_WINDOW",
        "android.permission.ACCESS_NETWORK_STATE",
        "android.permission.CALL_PHONE",
        "android.permission.INTERNET",
        "android.permission.SEND_SMS",
        "android.permission.WRITE_EXTERNAL_STORAGE",
        "android.permission.READ_EXTERNAL_STORAGE",
        "android.permission.RECORD_AUDIO",
        "android.permission.READ_CONTACTS",
        "android.permission.READ_PHONE_STATE",
        "android.permission.WAKE_LOCK",
        "android.permission.RECEIVE_BOOT_COMPLETED",
        "android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"
    ],
    "services": [
        {
            "name": "wocwvy.czyxoxmbauu.slsa.egxltnv",
            "permission": "android.permission.BIND_ACCESSIBILITY_SERVICE",
            "intent_filters": [
                "android.accessibilityservice.AccessibilityService"
            ]
        },

    ]
}

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:

<accessibility-service
    android:settingsActivity="com.example.root.myapplication.MainActivity"
    android:accessibilityEventTypes="typeWindowContentChanged|typeWindowStateChanged"
    android:accessibilityFlags="flagDefault|flagIncludeNotImportantViews|flagReportViewIds"
    android:canRetrieveWindowContent="true"
    xmlns:android="http://schemas.android.com/apk/res/android" />

Persistence

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.

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 value=com.google.android.apps.messaging
*droidy.SharedPreferences operation=Put key=VNC_Start_NEW value=http://ktosdelaetskrintotpidor.com
*droidy.SharedPreferences operation=Put key=Starter value=http://sositehuypidarasi.com
*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:

03e9e52588575c2acbf6811cb06a93bc5365fa20eaf7e9bed497373fde446475
b44bfa1d1c49d7642aee5b96112f20811bb3f001de519df3d89ed44aa2e6fcd2
0e33a0200df97e40d691d6f57749ac9584652f832c28fd8ad017154b5f9db2b3
cb07eaf6e2334e4f406a896572372eb646265893eb9255ede881e60eee1762ec
0ea083f31822c18ba2905c3aeabd83c7b09237e5443319cc27352bb4a3ac7e13
cbe3323456aa1f07afda2575e0115390ed6efa9faee3d8c160b4798760b2b44e
0ffdf82f55912d00705d91f90894abbbc728ecd9bad1b850c4b490f7a0796d45
cc8a7f8ee12441c01c28dfb48dc5b926694a42f94693cf139dd4208585f3e3f3
18832427a4a7dd1c2960a40fc13fc0dfc5357ecafdf7dae9f89d721f4138bc25
cd04470c86979749d70cae2190bee2dbf046bc14963a3f384648e44f6ad30dcd
230df3d3ce419e7988931c3d99ec0ab538d386f4b2e9d19e4ea639fa574ef294
cf59967f1a76cf44500e50b59f366748beff7c53227a564c60bd1faa693173a6
2b6c83dc1f0601e1c29270121eee020e8cd1b74ec61bb619a9c6b8008e587e26
d284f29b845cc2f73a86c6142f84ee57f6dfeca1a54971cec342ac81d84203dc
2bcee3c1f3e29927963428a5cea7c6a7ae2bdce1e3ae5ccd6769766c9475ae81
d906bc2b169d8c6d09a1eb2b77ec4d29e636b65ce6749a4b241d0eeecf8233ce
35e39edb87400ea0c3bca47748808f0f8d7e0182a36d0fe67b6c1448822e2905
dad0e376029b0a33e54ce2eab8e8f2b7459982ac2c955bc58938dc667a902dd5
4c203725a9591a80d8ee1e46d4e92d0d1f446aed02ae29e4d569eda195c53d8d
e10ecdf92e22bf97fef56382c3e398a2e0700829d645dfbf905911a35643568b
525f4dd1ca19868391115be0cac96d275581d53a506c030d58a52a214a223ff5
e2bc0c142624328af7a95cd17adf1fc6c93f7a069e34535f869bd2738203f256
5fd956642d2bd46108a4314af609b10fa41a19161618e413b9a6fbcf56892670
e65bed84ac1d140629f470a3bb2631df7a20193906d758bc8a1ecc514a02a7e6
6292fca792ab35f111b8abcd0e204b575880a2cabd80941ca014a94f63137219
e81d5f39c0c4da685bbfed9ca6ff079f10c46bd0118b0bd7793e94a9f6d624d2
6c74f7603d538ee818e79b025c0713e2efbce7e406a78f882b8cb0857f2cc52a
ea8feca4c616f97d782ccdcaa02f849e3f09021b3b6e09afcf15f2d9d9ea3970
7b2093d8c6f2fb507d5db2805b95fa6aa490db063924b522d5f83cfa82b9592b
ec034fc9f5e2d55d5f3581601d33757f7e6570afee463f2869c5ec8fa9920cd7
7ce509f579c92df91305cdd1f798d4f86edfa738533e746ee82befd52e987c36
f978b8de2c2c68002c57cab4a1f8dee6a2c2550d1a0a15f9e866fa948dffb7f6
8523c34321681ef5c63adb0a983adcc703bfdcd5017db50187e44e1e57f354f7
fa7f19cfa2848158923661d7c4b753ec340645041987b7fa2c3771b168dcb4ad
9852b3c4e21718089ac9fa0f22283498ead24a8e788626929fe94bdd6b5d37de
fbc9286c9d5e9135784422aac8b1346b18c05a48fe80224c21f71bc8c24618d6
9ffca9c9d28592426344789a3d3010cd55c426f5b9db0fd33bd16ec47779472b
fc2be987f2aae89ed2ee120a1e98cb0a8f4fe4b63489bb464e24ec9eeeca110b
aa9e58f4b732f91bb63d130e196f66cb97b09e8eed2bc14712812df55d6a99e4
ab35ff6f9ad9a5fba0687ee9e8ef1dfec0c32efc06d09055a4fe148feee1a637
af7dc844d3ccbf56aedc0287168dce837d29001db6f520b95487dd06b52adb75

Conclusion

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 tria.ge. 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 https://tria.ge/ and register right away!

Android