## Overview This project was developed for the **Dependability and Secure Systems** course at the University of Pisa (A.Y. 2024–2025), supervised by Prof. Maurizio Palmieri. The goal was to identify and characterise the malicious payload inside three Android APK samples belonging to the same malware family, through anti-malware scanning, static analysis, and dynamic emulation, followed by a cross-version comparative study. The three samples — internally labelled **cwbus**, **gjbus**, and **jjbus** — are regional variants of the same trojanised bus-information application targeting South Korean cities (Changwon, Gwangju, Jeonju respectively). They were publicly documented by McAfee Mobile Research as the **Malbus** family. ## Analysed Samples

Chapter	Internal label	APK version	SHA-256 (prefix)
1	cwbus	`Malbus_v1.0.3.apk`	`3252fbce…`
2	gjbus	`Malbus_v3.3.7.apk`	`19162b06…`
3	jjbus	`Malbus_v3.6.5.apk`	`bed3e665…`

All three samples share the package name `a.privacy.MalBuslmh` and are signed by the same certificate (`CN=Myoung-Hun Lee`, SHA-1/RSA v1 scheme), making them vulnerable to the **Janus attack** on Android 5.0–8.0. ## The Malbus Family The Malbus family was first documented by McAfee Mobile Research in 2019. The malicious apps were distributed on the Google Play Store, masquerading as legitimate public-transport applications. Once installed, they executed a multi-stage infection chain: 1. The user downloads the apparently legitimate bus app from Google Play 2. The app contacts a **Malware Distribution Server** to request an additional payload 3. The payload is delivered and installed as a fake plug-in 4. A second download delivers and executes the core trojan 5. The infected device establishes bidirectional communication with a **C2 server** 6. A separate **Upload Server** receives files exfiltrated from the device ## Analysis Methodology Each APK was analysed through the following pipeline: 1. **VirusTotal** — multi-engine antimalware scan (75+ AV engines), permission inspection, contacted domains and behaviour tab 2. **Static Analysis** — manual review of decompiled Java classes (`MainActivity`, `BaseMainActivity`, `EnvConstant`, `BusApiWeb`, `AppInfoActivity`, `AndroidManifest.xml`) via JD-GUI / Java Decompiler 3. **MobSF** — automated mobile security framework scan: certificate analysis, high/medium/low severity findings, risk scoring, privacy tracker detection 4. **Genymotion** — dynamic analysis in a virtual Android device with runtime observation ## Anti-Malware Analysis All three samples were flagged as malicious with a consistent threat label of `trojan.andr/apkdownloader`. The Tencent engine correctly identified each sample by its package name.

Sample	Detections	Reputation
cwbus (v1.0.3)	40 / 75	−1
gjbus (v3.3.7)	40 / 75	−2
jjbus (v3.6.5)	38 / 75	0

Dominant engine category: **trojan** (17–18 engines) across all three samples. Notably, **Microsoft Defender**, **McAfee**, and **Malwarebytes** failed to detect any of the three samples, highlighting a significant coverage gap for this family. ## Static Analysis ### Shared Architecture The static analysis revealed an identical internal architecture across all three APKs. Core classes are present and functionally equivalent in every variant, differing only in regional bus endpoint URLs and package names. Key structural elements common to all three: - Loading of a native library via `System.loadLibrary("Audio3.0")` in `BaseMainActivity` - Native methods `startUpdate()` and `updateApplication()`, consistent with dropper logic - Remote environment loading via `getEnvironmentProperties(...)`, allowing runtime behaviour modification without an APK update - Hardcoded advertising and analytics keys in `EnvConstant` (AdMob, AdLib, Facebook, Google Analytics `UA-56668425-6`) - Unencrypted HTTP in `BusApiWeb`, exposing data to man-in-the-middle interception - A cosmetic `AppInfoActivity` displaying a legitimate regional bus URL to disguise the app's true nature ### MobSF High-Severity Findings Findings present in **all three variants**: - Janus vulnerability (SHA-1 v1 signing) - Debug configuration enabled - Task Hijacking / StrandHogg - SharedPreferences world-readable/writable - Privacy trackers (8+ detected) Findings exclusive to **jjbus (v3.6.5)**: - Insecure RNG and weak MD5 cryptographic primitive - `libAudio3.0.so` compiled without stack canary or fortify function protections - Logging of sensitive information (elevated to HIGH severity) - StrandHogg 2.0 - MobSF risk score: **38/100 — Grade C, HIGH RISK** ## Comparative Analysis ### Evasion Capabilities Across Versions

Capability	cwbus v1.0.3	gjbus v3.3.7	jjbus v3.6.5
Obfuscation + Java Reflection	✓	✓	✓
VM / emulator detection	—	✓	✓
CPU name check (sandbox detection)	—	✓	✓
Process name manipulation	—	✓	✓
`libAudio3.0.so` without stack canary	—	—	✓
StrandHogg 2.0	—	—	✓
Crashlytics SDK integration	—	—	✓

### YARA Rule Match All three samples matched the `IcedID` structural YARA rule from the CAPEv2 repository (author: `kevoreilly/threathive`). Although IcedID is historically associated with a Windows banking trojan, the matched rule targets dropper and loader architectures — reinforcing that Malbus was deliberately engineered with an advanced payload-delivery architecture. ## Conclusions The three APKs are confirmed as regional variants of the same mature, deliberately maintained malware family. In all core dimensions — certificate signing, dropper architecture, remote configuration, advertising SDK integration, and core MobSF findings — they are functionally identical. The evolution from v1.0.3 to v3.3.7/v3.6.5 shows a progressive hardening of evasion capabilities, and a measurable expansion of the attack surface in v3.6.5 with an unprotected native library.