Intro

Recently, reports (1, 2) identified a piece of Android malware the masquerades as the application “RedAlert” used by Israelis to receive alerts about inbound rocket attacks. I wanted to learn more, so let’s dig in deeper.

Based on Cloudflare’s reporting, it looks like this was delivered via a website impersonating the legitimate domain and delivered the APK file as a download, rather than through distribution of an official app store.

Triage with Automation

With any malware analysis efforts, you should use automation to your advantage. Let’s run the APK file through MobSF and see what it highlights. I used the public mobsf.live public environment, but you could host MobSF locally if you are unable to share the sample. I also grabbed the legitimate APK, when you have the opportunity to look at the two side by side, it should highlight the interesting aspects of the malicious sample.

You can find the malware here and the legitimate application here. [EDIT - Mobsf.live seems to be having some stability issues at the moment, I will update the links again once it’s stable]

A great place to start with your analysis is the digital signature. If you look at the signer certificate of the malware, it uses the Android Debug certificate. This is the default that is used when you create your project in Android Studio, and is not intended for production applications. If we hop over to the legitimate application, we can confirm that’s it’s not using the debug digital certificate. This doesn’t guarantee that our sample is malicious, but it’s certainly a strike against the application.

2023-10-16_22-55-04.png

Next let’s review the Android Manifest. The manifest will identify the permissions the app needs and the different components of the application. It is a plaintext XML file you can open with any text editor, but MobSF helpfully parses this data for us, and allows us to sort by the permission status. You’ll see it call out several “dangerous” permissions right off the bat. If we compare side by side with the legitimate application, you’ll see the malware requests several additional dangerous permissions:

  • android.permission.GET_ACCOUNTS
  • android.permission.READ_CALL_LOG
  • android.permission.READ_CONTACTS
  • android.permission.READ_PHONE_NUMBERS
  • android.permission.READ_PHONE_STATE
  • android.permission.READ_SMS

This allows us to approximate the functionality of the malware. At this point, it’s clear to say that something is off about this sample since there’s a certificate mismatch from the known good copy and additional functionality known to be abused by attackers. There’s certainly more we could dig into in MobSF but this is a good jumping off point to our decompiler, JADX.

Jumping into JADX

Going through the application statically and my opening up the Android Manifest, we see that the launcher is calling the function com.red.alert.activities.Main. Since it’s a small application, lets start reading the code from there. Only a few lines in, we run across this interesting function.

    private void startService(Boolean considerDate, Boolean checkEmulator) {
        if (AIMain.shouldStart(getApplicationContext(), considerDate.booleanValue())) {
            Intent intent = new Intent(getApplicationContext(), AIService.class);
            intent.putExtra("considerDate", considerDate);
            startService(intent);
        }
    }

The AIMain class stood out to me here. Hovering over it, we see it comes from a separate package, com.company.allinclusive. As we dig in, we immediately see a string array called neededPermissions that includes the dangerous permissions we identified that are unique to the malicious app. If we run a search through all code for one of those permissions, like READ_SMS, we can confirm the only (unobfuscated) references are in this new package.

2023-10-16_21-08-43.png

The malware is configured check the date, and to collect data every 15 days.

public static int daysBetweenBackups = 15;
[...]

public void lambda$new$0$AIMain(boolean fetchAsYouCan, boolean considerDate) {
        TheData data;
        checkUnsuccessfulUploads();
        Date currentDate = new Date();
        if (considerDate) {
            Date lastFetch = Tools.getLastFetchDate(this.c);
            long daysBetween = TimeUnit.DAYS.convert(currentDate.getTime() - lastFetch.getTime(), TimeUnit.MILLISECONDS);
            if (daysBetween < daysBetweenBackups) {
                this.c.stopService(new Intent(this.c, AIService.class));
                return;
            }
        }

Fortunately for us, the code isn’t obfuscated so we can read the data collection code in the getData() function. It gathers phone information like IMEI, IMSI, SIM card serial number, all contacts, all text messages, entire call history, logged in accounts, and all installed applications. At this point, it is abundantly clear that this app is malicious.

It stages this data to a hidden directory named ./files/, compresses, then encrypts to another hidden folder ./zips/.

Once this is complete, it initializes a connection over HTTP or HTTPS with a hardcoded IP address of 23.254.228[.]135, the URI path of /file.php, and using port 80 or 443 respectively and exfiltrates the data over POST request.

IOCs

Artifact Value
MD5 410c6e3af93abde8a8c7801cb14da9e0
SHA256 5087a896360f5d99fbf4eb859c824d19eb6fa358387bf6c2c5e836f7927921c5
Exfil IP 23.254.228[.]135
APK Delivery URL hxxps://redalerts[.]me/app.apk