Add Quark malware analysis report for Exodus

[pulorsok]

Exodus Malware Family Analysis Report

This report analyses the Exodus malware family using Quark's rule classification. Exodus is Android surveillanceware written by the Italian firm eSurv and documented by Security Without Borders in 2019. It was delivered through decoy apps posing as mobile-operator service tools, and installs in two stages: a first stage that registers the device with the operator's server, and a surveillance implant downloaded afterwards. The three samples analysed here are the first stage. This run added a new rule (#279), which flags reading the device IMEI and the subscriber IMSI in the same method; it is demonstrated in the T1422 section below. Check here for the rule details.

Quark's rule classification flagged 3 of 3 Exodus samples as high-risk in this experiment (detection rate 100%). Benign-cohort false-positive rate was not measured here. See tested APKs below.

Identified Well-Known Threats

This section uses MITRE ATT&CK Mobile as its reference taxonomy, anchored to the S0405 Exodus software entry. Of the 19 techniques documented for the family, Quark's static bytecode analysis confirms the 3 listed below; see the coverage-gap notes at the end of this section for the other 16.

MITRE Technique	Real-world manifestation
T1418 Software Discovery	Listing the installed applications to check whether a given package is present on the device
T1422 System Network Configuration Discovery	Collecting the device IMEI and the subscriber IMSI and sending them to the operator's server
T1636.002 Call Log	Reading the device's call-log provider

All behavior maps below were rendered from sample 4f6146956b50ae3a6e80a1c1f771dba848ba677064eb0e166df5804ac2766898.apk (package operatore.italia, posing as an Italian operator's contact-sync app) — chosen as the representative sample whose detected behaviors most fully cover the documented profile of Exodus. The other 2 family samples were used to compute the detection-rate figure above.

Each section below corresponds to one technique from the table above. Within each section we first quote the MITRE definition, then show the Quark behavior map extracted from the representative sample's bytecode, then walk through the call sequence and list the underlying rules.

1. T1418 Software Discovery

T1418 Software Discovery — attack.mitre.org

MITRE definition (T1418): Adversaries may attempt to get a listing of applications that are installed on a device.

Llib/operatore/core/a;a walks the full getInstalledApplications list and compares each package name against the one it is looking for. Its caller uses that answer to decide whether to start the registration routine.

Behaviors detected by Quark:

• Enumerate installed applications (Error on GitHub actions Windows VM #264)

2. T1422 System Network Configuration Discovery

T1422 System Network Configuration Discovery — attack.mitre.org

MITRE definition (T1422): Adversaries may look for details about the network configuration and settings, such as IP and/or MAC addresses, of devices they access or through information discovery of remote systems. On Android, details of onboard network interfaces are accessible to apps through the java.net.NetworkInterface class. Previously, the Android TelephonyManager class could be used to gather telephony-related device identifiers, information such as the IMSI, IMEI, and phone number.

Llib/operatore/core/b;c reads the device IMEI and the subscriber IMSI in one method, along with the network operator name. This is the method that registers the device with the server, and the new rule added by this run fires on the IMEI-and-IMSI pair.

Behaviors detected by Quark:

• Get the IMSI and network operator name (Unable to get function involved in a 60% confident rule #117)
• Collect device IMEI and subscriber IMSI identifiers (Different JSON formats cause Jadx and APKLab to fail to read Quark report #279)

3. T1636.002 Call Log

T1636.002 Call Log — attack.mitre.org

MITRE definition (T1636.002): Adversaries may utilize standard operating system APIs to gather call log data. On Android, this can be accomplished using the Call Log Content Provider. iOS provides no standard API to access the call log.

Loperatore/italia/ProgressActivity$2;a queries the call-log content provider while the decoy "optimisation" screen runs. It takes the number of rows from the cursor; the call records themselves are not read out here.

Behaviors detected by Quark:

• Query data from URI (SMS, CALLLOGS) (Welcome gwalstat #11)

Coverage-gap notes

The 16 MITRE techniques documented for Exodus that this report does NOT demonstrate, grouped by the reason Quark could not confirm them on these samples:

The behaviour belongs to the second stage, which these samples only download (10) — T1421 System Network Connections Discovery, T1422.001 Internet Connection Discovery, T1429 Audio Capture, T1430 Location Tracking, T1512 Video Capture, T1513 Screen Capture, T1532 Archive Collected Data, T1636.001 Calendar Entries, T1636.003 Contact List and T1636.004 SMS Messages. Rules for location, screen capture, calendar reads, SMS reads and network-state checks do fire in these APKs, but every one of them lands in the bundled AndroidX support or logback libraries, and none of those methods is reachable from Exodus's own code. The location hit is AppCompat's TwilightManager deciding whether to apply the night theme; the SMS-and-call-log hit is a support-library helper that reads a column from whatever content URI it is handed. Neither result reaches Exodus.

Quark reached Exodus's own code, but the primitive is not this technique (3) — T1404 Exploitation for Privilege Escalation, T1409 Stored Application Data and T1533 Data from Local System. The only Runtime.exec calls in Exodus's own code run chmod 700 over the files it has just unpacked, which makes the downloaded payload executable rather than exploiting anything. The file reads that matched T1409 and T1533 come from that same routine — Exodus reading back its own downloaded payload, not other applications' data. Quark reports all of it under one name, Llib/operatore/core/f;a, because three different methods in that class are called a.

The behaviour is real, but no rule covers the API it uses (3) — T1407 Download New Code at Runtime, T1437.001 Web Protocols and T1509 Non-Standard Port. Exodus downloads its second stage and talks to its server through OkHttp; the pool's HTTP rules match HttpURLConnection and Apache HttpClient, and none match OkHttp. This run did generate a candidate rule for the step that follows the download (Context.getFilesDir paired with Runtime.exec), but it trained to a negative score — it also fires on benign apps — so it was not added. For T1509 there is nothing non-standard to find: the server is reached over HTTPS on port 443.

List of Tested APKs

The table below lists the APKs we tested.

index	sha256
1	0F5F1409B1EBBEE4AA837D20479732E11399D37F05B47B5359DC53A4001314E5
2	26FEF238028EE4B5B8DA631C77BFB44ADA3D5DB8129C45DEA5DF6A51C9EA5F55
3	4F6146956B50AE3A6E80A1C1F771DBA848BA677064EB0E166DF5804AC2766898

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.28%. Comparing base (6adba4c) to head (33527b8).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #976   +/-   ##
=======================================
  Coverage   81.28%   81.28%           
=======================================
  Files          84       84           
  Lines        7923     7923           
=======================================
  Hits         6440     6440           
  Misses       1483     1483           

Flag	Coverage Δ
unittests	81.28% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[haeter525]

LGTM.