A Primer On Android Forensics

January 28, 2022

A lot has already been said on iOS forensics for the purpose of discovering traces of compromise and spyware execution. And although a lot more is left to explore on that subject still, in this post instead we take a first look at approaching suspected Android devices.

Opposite to iPhones, due to the high fragmentation of its market, it is challenging to define a unified process to extract forensic data and identify traces of compromise from Android consistently. Devices can come flashed with different flavors of the operating system, with unique characteristics not only in user functionality and available apps, but in security features and restrictions as well. Practicing the analysis of as many disparate devices as possible will help us familiarize with this diverse ecosystem, train a keen eye, and more easily spot anomalies which might turn out to be suspicious. Unfortunately Android, contrary to iOS, does not seem to keep a lot of historical records, so you are less likely to find traces of past compromises, other than maybe in SMS messages and browsing history.

Although Mobile Verification Toolkit (MVT) launched with a particular attention to the analysis of iOS devices, support for Android continues to develop. Before proceeding further, you should have both MVT and all required dependencies (including Android debugging tools) installed. (You should know that, while on Linux and Mac should be straightforward, mvt-android’ support on Windows is partial and you should consider running from Windows Subsystem Linux instead. You might still incur in USB-related issues, in which case you might need to connect over Wi-Fi.)

To interact with an Android device MVT requires to enable USB Debugging. In order to do so, you typically should enable the Developer Options in the Settings by tapping 5 times on the builder number in the About phone section, then navigate to this menu and toggle on “USB debugging”.

At least at the first connection you will be requested to authorize the host by allowing the connection when a prompt will appear on the phone. Make sure you have unlocked the phone and look out for the prompt. If needed, you can trigger it by launching an adb shell command.

A full acquisition from the device can be simply launched with:

$ mvt-android check-adb --output /path/to/results/folder/

Try running this command and observe the output from the terminal.

MVT will run a number of modules in sequence, extract relevant records and, if provided with the --output argument, store the results on disk at the specified path. At the time of writing, with MVT v1.4.9, the available Android modules are ChromeHistory, DumpsysAccessibility, DumpsysBatterystats, DumpsysPackages, DumpsysProcstats, DumpsysReceivers, DumpsysFull, Files, Getprop, Logcat, Packages, Processes, RootBinaries, Settings, SMS, Whatsapp.

All of these modules provide a wealth of information useful to diagnose the state of the device. However, some of them can be particularly revealing of suspcious traces of compromise. In this text we cover some of the more interesting ones, and leave others for the near future.

Check installed Packages

While the command above will run all these module in sequence, we can also decide to only run a specific one by specifying its name. So, let’s try running the Packages module alone:

$ mvt-android check-adb --module Packages --output /path/to/results/folder/ --fast

This module can take a minute to run, due to the amount of commands it needs to send to the phone. The more packages are installed, the longer the execution will inevitably take. After a couple of minutes we should see an output similar to this:

INFO     [mvt.android.modules.adb.packages] Running module Packages...
INFO     [mvt.android.modules.adb.packages] Found non-system package with name "com.sec.android.app.voicenote" installed by "com.samsung.android.app.omcagent" on 8 17:39:43
INFO     [mvt.android.modules.adb.packages] Found non-system package with name "com.network.android" installed by "None" on 2022-01-27 02:51:05
INFO     [mvt.android.modules.adb.packages] Found non-system package with name "com.sec.android.app.sbrowser" installed by "com.samsung.android.app.omcagent" on 8 17:39:09
INFO     [mvt.android.modules.adb.packages] Found non-system package with name "com.sec.android.app.popupcalculator" installed by "com.samsung.android.app.omcagent" on 2021-08-12 17:40:22
INFO     [mvt.android.modules.adb.packages] Found non-system package with name "com.samsung.android.voc" installed by "com.samsung.android.app.omcagent" on 2021-08-12 17:39:32
INFO     [mvt.android.modules.adb.packages] Found non-system package with name "com.samsung.android.app.notes" installed by "com.samsung.android.app.omcagent" on 2021-08-12 17:38:42
INFO     [mvt.android.modules.adb.packages] Extracted at total of 338 installed package names    

As we can see at the end, the module extracted details about a total of 338 install packages. It highlighted a handful it identified as non-system and provided the date it was installed and by what. This information already helps narrow down from a large total to at least a subset of apps which, being non-system, should more likely contain any malicious ones.

Through this we can also already notice that 5 out of these 6 apps were installed by a Samsung system service called com.samsung.android.app.omcagent. Without knowing much about Samsung internals, we can at least start to have a first look at the remaining app which is installed by None, meaning that the installer is not known. I can already tell you this particular app is in fact a sample of Pegasus for Android, and that None was caused by my manual installation of the malicious app using adb install. In a different case, a package installed manually from the device by navigating to the phone’s Downloads appears installed by com.google.android.packageinstaller instead.

Let’s now have a look at the records stored at /path/to/results/folder/packages.json, which should contain a rather large JSON dataset. Searching for example for com.network.android would show us the following entry:

    "package_name": "com.network.android",
    "file_name": "/data/app/~~orn3MqdVWNE5GQlHv99UVQ==/com.network.android-cY8D9yC2MuzVOyShQeveXg==/base.apk",
    "installer": null,
    "timestamp": "2022-01-27 02:51:05",
    "first_install_time": "2022-01-27 02:51:06",
    "last_update_time": "2022-01-27 02:51:06",
    "uid": "10014",
    "disabled": false,
    "system": false,
    "third_party": true,
    "files": [
            "path": "/data/app/~~orn3MqdVWNE5GQlHv99UVQ==/com.network.android-cY8D9yC2MuzVOyShQeveXg==/base.apk",
            "md5": "7c3ad8fec33465fed6563bbfabb5b13d",
            "sha1": "e5920f3723e62e1850157f09baf556006bf80f74",
            "sha256": "ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5",
            "sha512": "75da7c118879d9430fb13c5a51d76e1278f0c1474d5cc25c4b9684b7d8c0f93b2e44584eee0f8b0d12016bc1efad367b45ff9ca5609853ae345b6d802ff63d10"

Besides the name, installer and dates, MVT tells us this app is not disabled ("disabled": false), is not a system app ("system": false), and is considered user installed ("third_party": true). Looking at other records with similar values, because I am using a rather empty test phone, I see only one package com.sec.android.emergencylauncher as disabled, and a handful of others as third party. In a real case scenario we are likely to see a much larger amount. Have a look nevertheless, as it helps with familiarizing with the device.

We also get a list of files bundled with this package, in this case only the base.apk. MVT should provide us with hashes of all installed packages APKs, and they can be useful to look up. For example a lookup for one of those hashes on VirusTotal immediately alerts us of the malicious nature of this particular package.

Walking through this packages.json file is an important first step. Prioritize looking at non-system and third-party apps. Look out for any that were disabled (for example, a commercial security app marked as disabled might be a red flag). Search online for package names and hashes of those apps that do not look familiar, have odd names, or might show an unusual installer.

However, on particularly cluttered devices, going through all of this manually can be a tedious process. Thankfully MVT helps us doing a quick triage too. If we remove the --flag flag from the mvt-android command we used earlier, MVT also performs a Koodous of the non-system packages it highlighted (a VirusTotal lookup is also supported, but currently disabled, due to unresolved issues with the API):

02:19:21 INFO     [mvt.android.lookups.koodous] Looking up all extracted files on Koodous (www.koodous.com)
         INFO     [mvt.android.lookups.koodous] This might take a while...
Looking up 6 packages... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
                                                                   Koodous Packages Detections
┃ Package name                        ┃ File name                                                                                  ┃ Trusted ┃ Detected ┃ Rating ┃
│ com.sec.android.app.voicenote       │ /data/app/com.sec.android.app.voicenote-OQ-xiRQ7ys4X-3QspVDmsA==/base.apk                  │ no      │ no       │ 0      │
│ com.network.android                 │ /data/app/~~orn3MqdVWNE5GQlHv99UVQ==/com.network.android-cY8D9yC2MuzVOyShQeveXg==/base.apk │ no      │ yes      │ -16    │
│ com.sec.android.app.sbrowser        │ /data/app/com.sec.android.app.sbrowser-xuoOPvmDUh4NJemgIfnBsw==/base.apk                   │ no      │ no       │ 0      │
│ com.sec.android.app.popupcalculator │ /data/app/com.sec.android.app.popupcalculator-QffqBIVbqt7TkzwoDSdxbQ==/base.apk            │ no      │ no       │ 0      │
│ com.samsung.android.voc             │ /data/app/com.samsung.android.voc-DmqvpdwlPNWlrusQ2SDULw==/base.apk                        │ no      │ no       │ 0      │
│ com.samsung.android.app.notes       │ /data/app/com.samsung.android.app.notes-t-OC5DWjGVhvpUt1HmsacQ==/base.apk                  │ no      │ no       │ 0      │

In the Koodous results we can see that the package com.network.android is in fact marked as detected with a rating of -16.

If we want to obtain a copy of the installed packages in order to reverse engineer them or process them with other tools, we can use the following command:

$ mvt-android download-apks /path/to/apks/folder/
INFO     [mvt.android.download_apks] Starting extraction of installed APKs at folder /tmp/apks
INFO     [mvt.android.download_apks] Selected only 8 packages which are not marked as system
INFO     [mvt.android.download_apks] Downloading packages from device. This might take some time ...
INFO     [mvt.android.download_apks] [1/6] Package: com.sec.android.app.voicenote
INFO     [mvt.android.download_apks] Downloading /data/app/com.sec.android.app.voicenote-OQ-xiRQ7ys4X-3QspVDmsA==/base.apk ...
INFO     [mvt.android.download_apks] [2/6] Package: com.network.android
INFO     [mvt.android.download_apks] Downloading /data/app/~~orn3MqdVWNE5GQlHv99UVQ==/com.network.android-cY8D9yC2MuzVOyShQeveXg==/base.apk ...
INFO     [mvt.android.download_apks] [3/6] Package: com.sec.android.app.sbrowser
INFO     [mvt.android.download_apks] Downloading /data/app/com.sec.android.app.sbrowser-xuoOPvmDUh4NJemgIfnBsw==/base.apk ...
INFO     [mvt.android.download_apks] [4/6] Package: com.sec.android.app.popupcalculator
INFO     [mvt.android.download_apks] Downloading /data/app/com.sec.android.app.popupcalculator-QffqBIVbqt7TkzwoDSdxbQ==/base.apk ...
INFO     [mvt.android.download_apks] [5/6] Package: com.samsung.android.voc
INFO     [mvt.android.download_apks] Downloading /data/app/com.samsung.android.voc-DmqvpdwlPNWlrusQ2SDULw==/base.apk ...
INFO     [mvt.android.download_apks] [6/6] Package: com.samsung.android.app.notes
INFO     [mvt.android.download_apks] Downloading /data/app/com.samsung.android.app.notes-t-OC5DWjGVhvpUt1HmsacQ==/base.apk ...
INFO     [mvt.android.download_apks] Download of selected packages completed

Now we will have a new packages.json as well as a an apks folder containing all APKs at the specified folder.

By adding --all-apks we can select all installed APKs for download instead of just the non-system ones. Specifying --all-checks we can also request to lookup all the selected APKs on all available services. You can also use the --from-file in combination with --all-checks to lookup all the APKs previously identified by check-adb like following:

$ mvt-android download-apks --from-file /path/to/results/packages.json --all-checks

Check Broadcast Receivers

Android apps can register Broadcast Receivers called when certain events, or Intents, are triggered and broadcasted system-wide. The dumpsys command allows to inspect which receivers are registered on the device for all available actions and events. Through this we can identify apps equipped with receivers for events that might be sensitive or particularly prone to abuse.

At the moment, MVT highlights receivers for the following intents:

Any receivers registered for these events can help quickly identify apps which might attempt to intercept SMS messages and phone calls. For example, running the DumpsysReceivers MVT module yields the following results in my case:

INFO     [mvt.android.modules.adb.dumpsys_receivers] Running module DumpsysReceivers...                                                                                
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring telephony state/incoming calls: "com.network.android/.AndroidCallDirectWatcher"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring telephony state/incoming calls: "com.network.android/.roomTap.AutoAnswerReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring telephony state/incoming calls: "com.facebook.katana/com.facebook.confirmation.util.BackgroundVoiceCallReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring telephony state/incoming calls: "com.network.android/.agent.NetworkReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver to intercept outgoing SMS messages: "com.network.android/.agent.NetworkReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver to intercept incoming SMS messages: "com.network.android/.agent.NetworkReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver to intercept incoming data SMS message: "com.network.android/.agent.NetworkReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring outgoing calls: "com.sec.android.app.safetyassurance/.emergencyreporthelper.EmergencyReportStartMonitorReceiver"

We can see one receiver for telephony state registered by com.facebook.katana, the package name for the Facebook app, and one for a Samsung component. All others are related to the malicious package com.network.android we previously identified:

If we inspect the decompiled code of this Pegasus sample, we can see that AndroidCallDirectWatcher is used to monitor incoming calls and determine whether they ought to be recorded:

public void onReceive(Context context, Intent intent) {
    try {
        String stringExtra = intent.getStringExtra("state");
        String stringExtra2 = intent.getStringExtra("incoming_number");
        a.a("AndroidCallDirectWatcher phone_state: " + stringExtra + " Incoming number: " + stringExtra2);
        if (TelephonyManager.EXTRA_STATE_OFFHOOK.equals(stringExtra)) {
            a.a("AndroidCallDirectWatcher incoming call");
            if (b.e(context).booleanValue()) {
                a.a("AndroidCallDirectWatcher no need to record call");
                if (!AutoAnswerReceiver.a()) {
                    a.a("AndroidCallDirectWatcher start recording.");
                    a.a("AndroidCallDirectWatcher record post");
                    this.e.post(new a(this, context));
            } else {
                a.a("AndroidCallDirectWatcher record got incoming call. NOT suppose to record according to configuration");
        if (TelephonyManager.EXTRA_STATE_IDLE.equals(stringExtra)) {
            a(context, this.e);
        g = stringExtra;
        h = stringExtra2;
    } catch (Throwable th) {
        a.a("AndroidCallDirectWatcher Call Listener Exception- " + th.getMessage(), th);

If it wasn’t suspicious enough that such an undescriptive package name has registered broadcast receivers for these events, the suggestive name roomTap definitely adds up.

As a matter of fact, roomTap.AutoAnswerReceiver is registered to monitor incoming calls from a configured phone numer. When such number calls, the phone screen is purpusefully blackened to hide it, the call is auto-answered, and in this way the attackers are able to silently turn the device into a room bug and listen in the proximity of the phone’s microphone:

public final void run() {
    try {
        String unused = AutoAnswerReceiver.l = this.f114a.getStringExtra("state");
        String unused2 = AutoAnswerReceiver.o = this.f114a.getStringExtra("incoming_number");
        com.network.android.c.a.a.a("berez isOffHook = false");
        AutoAnswerReceiver.c = false;
        com.network.android.c.a.a.a("AutoAnswerReceiver phone_state: " + AutoAnswerReceiver.l + " Incoming number: " + AutoAnswerReceiver.o);
        if (AutoAnswerReceiver.l.equals(TelephonyManager.EXTRA_STATE_RINGING)) {
            if (!AutoAnswerReceiver.b(AutoAnswerReceiver.o)) {
                com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve - this is not the room tap number");
                if (TelephonyManager.EXTRA_STATE_OFFHOOK.equals(AutoAnswerReceiver.h) && AutoAnswerReceiver.a()) {
                    com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve isOffHook = true");
                    AutoAnswerReceiver.c = true;
                    com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve Interfering tap with waiting call. killing tap. not answering. lastCall: " + AutoAnswerReceiver.h);
                    b.a(1, 63, "ROOM_TAP_ENDED_INCOMING_CALL");
                    AutoAnswerReceiver.d = true;
                } else if (c.b() && !AutoAnswerReceiver.a()) {
                    b.a(1, (short) 63);
                    com.network.android.c.a.a.a("Auto answer tap window ended be incoming call" + AutoAnswerReceiver.h);
                    AutoAnswerReceiver.d = true;
                    c.a(this.b, "httpPing");
            } else if (!AutoAnswerReceiver.a()) {
                if (c.b()) {
                    com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve TelephonyManager.EXTRA_STATE_RINGING");
                    if (!BlackScreen.f111a) {
                        com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve BlackSCreen screen is not shown and got call!!! disconnecting");
                        b.a(1, 56, "ROOM_TAP_NOT_ALLOWED_HIDE_ROOM_TAP_FAILED");
                    String unused3 = AutoAnswerReceiver.p = AutoAnswerReceiver.o;
                } else if (AutoAnswerReceiver.a(AutoAnswerReceiver.o)) {
                    com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve disconnecting. we are getting call from pbx and we are not on tap window");
                    new Handler().postDelayed(new b(this), 3000);
            } else if (AutoAnswerReceiver.a(AutoAnswerReceiver.o)) {
                com.network.android.c.a.a.a("AutoAnswerReceiver onRecieve - got another call from tap pbx. doing nothing!");


Another spyware called MobiiSpy for example would appear like following:

INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring telephony state/incoming calls: "com.mobiispy.system/com.android.system.IncomingCallsReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver to intercept incoming SMS messages: "com.mobiispy.system/com.android.system.IncomingSMSReceiver"
INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver monitoring outgoing calls: "com.mobiispy.system/com.android.system.OutgoingCallsReceiver"

In a real case scenario we most definitely will have several more legitimate apps with registered receivers, and those would typically be messaging apps. For example, Signal would at least appear as following:

INFO     [mvt.android.modules.adb.dumpsys_receivers] Found a receiver to intercept incoming SMS messages: "org.thoughtcrime.securesms/.service.SmsListener"

Not to worry, this is legitimate behavior. Signal most likely uses this receiver to catch verification SMS messages sent at the first setup. We can expect similar apps to do the same. So, with this in mind, don’t immediately jump to wrong conclusions, but also use these results as filters to narrow down the number of applications we might want to inspect more closely.

Now, we can find a lot more information about other event handlers that are not highlighted by DumpsysReceivers by inspecting the content of the DumpsysPackages module’s output.

$ mvt-android check-adb --module DumpsysPackages --output /path/to/results/folder/

If we search in /path/to/results/folder/dumpsys_packages.txt for com.network.android we can see mentions of other services, for example of com.network.android/com.network.ussd.CDUSSDService which appears to be used by the spyware to intercept and block certain USSD messages.

Check Accessibility Services

In some cases malware can attempt to abuse Android Accessibility services, which were designed to enhance the use of the device by users with visual or other forms of impairments. Malware can abuse Accessibility to perform a variety of malicious operations, such as hijacking applications launch, or grabbing SMS messages and injecting malicious content in web views.

MVT’s DumpsysAccessibility module highlights services active on the device leveraging Accessibility Services:

$ mvt-android check-adb --module DumpsysAccessibility
INFO     [mvt.android.modules.adb.dumpsys_accessibility] Running module DumpsysAccessibility...                                                                                 
INFO     [mvt.android.modules.adb.dumpsys_accessibility] Found installed accessibility service "com.samsung.accessibility/.universalswitch.UniversalSwitchService"
INFO     [mvt.android.modules.adb.dumpsys_accessibility] Found installed accessibility service "com.samsung.android.accessibility.talkback/com.samsung.android.marvin.talkback.TalkBackService"
INFO     [mvt.android.modules.adb.dumpsys_accessibility] Found installed accessibility service "com.malicious.package/.bad.Service"

While these lines don’t immediately inform us on the purpose of these services, we can at least notice that along with legitimate Samsung applications, we find others which might be worth looking further into.

Check Settings

Often times, malicious Android applications will modify certain system settings typically in order to either disable automatic software updates or to disable security features. MVT extracts all settings and warns of unsafe configurations of particularly sensitive features:

$ mvt-android check-adb --module Settings
INFO     [mvt.android.modules.adb.settings] Running module Settings...
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "samsung_errorlog_agree = 0" (disabled sharing of crash logs with manufacturer)
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "send_security_reports = 0" (disabled sharing of security reports)
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "install_non_market_apps = 1" (enabled installation of non-market apps)
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "package_verifier_user_consent = 0" (disabled Google Play Protect)
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "package_verifier_enable = 0" (disabled Google Play Protect)
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "send_action_app_error = 0" (disabled applications errors reports)
WARNING  [mvt.android.modules.adb.settings] Found suspicious setting "upload_apk_enable = 0" (disabled Google Play Protect) 

In this case we can see crash logs reporting and installed package verifications have been disabled. While we won’t be able to right away learn which app performed these modifications, these results are alarming and warrant further inspection of the device.

Check for Root/Jailbreak Binaries

A rather straightforward check to do is to check look binaries known to be associated with rooting/jailbreaking procedures. This can be simply done by running MVT’s RootBinaries command:

$ mvt-android check-adb --module RootBinaries
INFO     [mvt.android.modules.adb.root_binaries] Running module RootBinaries...
WARNING  [mvt.android.modules.adb.root_binaries] Found root binary "su"
WARNING  [mvt.android.modules.adb.root_binaries] Found root binary "busybox"

Unless the user of the device knowingly rooted it, the presence of such binaries could be a canary. Mind you that spyware often also places su binaries at different locations and under different names, and those would not be highlighted by this module.

There’s work to be done to proper euristically detect jailbreaking, and I will likely get back to this in the future. Nevertheless, having a quick look with this module can help shake down some low hanging fruit.

Checking Indicators of Compromise

As anticipated at the beginning, a wealth of additional information is available to us. Undoubtedly, records such as running processes, files on disk, SMS links and more, can be revealing, especially if compared to known indicators of compromise. Most of MVT modules support checking their produced records against any STIX2 indicators provided through the --indicators command-line argument:

$ mvt-android check-adb --iocs /path/to/file.stix2

At the moment these indicators can include domain names, process names, email addresses, file names, file paths, file hashes, package names and configuration profiles.

For example, consider an additional custom STIX2 file like following:

    "type": "bundle",
    "id": "bundle--b34f30e5-3314-42b6-8334-c3d956141ede",
    "objects": [
            "type": "malware",
            "spec_version": "2.1",
            "id": "malware--7015d8e4-7a1d-41c0-bdcd-08ed9a0fbb32",
            "created": "2022-01-28T00:00:00.00000Z",
            "modified": "2022-01-28T00:00:00.00000Z",
            "name": "Pegasus for Android",
            "description": "Pegasus for Android IOCs",
            "is_family": false
           "type": "relationship",
           "spec_version": "2.1",
            "id": "relationship--0aa9c821-8a78-4ebf-ad99-e1f50ed84ab2",
            "created": "2022-01-28T00:00:00.00000Z",
            "modified": "2022-01-28T00:00:00.00000Z",
            "relationship_type": "indicates",
            "source_ref": "indicator--c0557532-fcc4-4695-8793-c0a0773cd701",
            "target_ref": "malware--7015d8e4-7a1d-41c0-bdcd-08ed9a0fbb32"
            "type": "indicator",
            "spec_version": "2.1",
            "id": "indicator--c0557532-fcc4-4695-8793-c0a0773cd701",
            "created": "2022-01-28T00:00:00.00000Z",
            "modified": "2022-01-28T00:00:00.00000Z",
            "indicator_types": [
            "pattern": "[app:id='com.network.android']",
            "pattern_type": "stix",
            "pattern_version": "2.1",
            "valid_from": "2022-01-28T00:00:00.00000Z"

If we store it on disk and provide it to MVT’s Packages module we obtain the following new line:

$ mvt-android check-adb --iocs /path/to/new.stix2 --output /path/to/results/folder/
WARNING  [mvt.android.modules.adb.packages] Found a known suspicious app with ID "com.network.android" matching indicators from "Pegasus for Android"

And we’ll have a new file located at /path/to/results/folder/packages_detected.json with the following content:

        "package_name": "com.network.android",
        "file_name": "/data/app/~~orn3MqdVWNE5GQlHv99UVQ==/com.network.android-cY8D9yC2MuzVOyShQeveXg==/base.apk",
        "installer": null,
        "timestamp": "2022-01-27 02:51:05",
        "first_install_time": "2022-01-27 02:51:06",
        "last_update_time": "2022-01-27 02:51:06",
        "uid": "10014",
        "disabled": false,
        "system": false,
        "third_party": true,
        "files": [
                "path": "/data/app/~~orn3MqdVWNE5GQlHv99UVQ==/com.network.android-cY8D9yC2MuzVOyShQeveXg==/base.apk",
                "md5": "7c3ad8fec33465fed6563bbfabb5b13d",
                "sha1": "e5920f3723e62e1850157f09baf556006bf80f74",
                "sha256": "ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5",
                "sha512": "75da7c118879d9430fb13c5a51d76e1278f0c1474d5cc25c4b9684b7d8c0f93b2e44584eee0f8b0d12016bc1efad367b45ff9ca5609853ae345b6d802ff63d10"
        "matched_indicators": {
            "value": "com.network.android",
            "type": "app_ids",
            "name": "Pegasus for Android"

You can also download some public indicators from a pre-compiled list. They will be subsequently loaded automatically at each launch of MVT:

$ mvt-android download-iocs

Now, we can start creating STIX2 files for the known malware we are on the hunt for. To suggest new ones that could be added to the compiled list for download-iocs, please open a ticket.


We reached the conclusion of this text. We learned some first steps to approach assessing an Android device and getting acquainted with MVT. Naturally, there’s a lot more left to be covered as well as many features yet to be developed. As I further research this subject and develop MVT and other tools, I will come back soon with some additional technical notes.