DEV Community

Anoymask
Anoymask

Posted on

Mantax Otax: Mobile Malware Combining Encryption, Monitoring, and Device Sabotage

#security #threatintel

1. Overview

2. Summary in One Sentence

Analyzed by Zimperium, Mantax Otax is a malicious APK for Android. It uses features like Accessibility permissions to collect screens and messages, and performs widespread file encryption on older Android versions. Based on the language and victim files, it is assessed to target Indonesia.

3. Attack Flow

Mantax Otax: Mobile Malware Combining Encryption, Surveillance, and Device Harassment

  • Places the malicious APK on an external file-sharing service. Zimperium suggests distribution paths that entice manual installation using sharing links or messages.
  • Prompts for device administrator, sensitive permissions, and Accessibility permissions.
  • Retrieves the C2 command server connection domain from information on GitHub and registers the device. The initial version uses Firebase, while v2 uses WebSockets to receive commands.
  • Collects and exfiltrates SMS, OTPs, PINs, communication content, screens, location, and photos.
  • Encrypts accessible files using victim-specific AES keys obtained from the C2 and demands a ransom via a chat interface using Firebase. Zimperium describes extensive encryption on Android 9 and earlier, along with a narrower file-encryption scope under the tested conditions on Android 10 and later.
  • Version 2 adds interference with screen operations and intimidation through audio and images.

4. Attacker Position and Execution Location

  • A remote attacker capable of delivering malicious APK links to victims and tricking them into installing the app and granting Accessibility permissions.

5. Visibility for Victims and Administrators

Victims

  • May notice permission requests such as device administrator and Accessibility, full-screen chat interfaces, .enc files, image ransom notifications, and interference with screen or audio.

Administrators

  • Inference: Depending on the collection capabilities of Mobile Device Management (MDM) or Mobile Threat Defense (MTD), suspicious APKs, enabled accessibility features, and related communications may be visible. Not all permission operations or communication destinations are necessarily recorded by default.

6. Success and Failure Conditions

Success Conditions

  • The user installs and executes the external APK.
  • Obtains necessary permissions and accessibility permissions for targeted functions such as information gathering and screen control.
  • Remote control and external transmission require communication to the C2 and destinations used by those features. Firebase, WebSockets, and Catbox are not strictly required for every single feature.

Failure Conditions and Risk Reduction

  • On managed devices, restrict apps to approved distribution paths and enable protection features like Play Protect.
  • Limit accessibility permissions and device administrator privileges to trusted apps required for business.
  • Update to supported operating systems and control communication to attacker C2s and other endpoints. Simply meeting the Android 10 or higher condition does not prevent the theft of screens, SMS, and other data.

7. What Happens Upon Success

  • Theft of SMS, OTPs, PINs, messages, location, screens, and photos
  • Encryption of accessible user files and ransom demands. Analysis indicates a higher impact scope on Android 9 and earlier
  • Device disruption via screen locks and massive pop-ups

8. Observable Logs

Inference: Based on published attack behavior, logs useful for investigation and their collection conditions are organized below.

Email

  • If the distribution link arrived via email, preserve that email. When sent via messaging apps, it may not appear in internal email logs.

Proxy / SWG / DNS

  • Connection destinations, timestamps, and transfer volumes for GitHub, Firebase, Catbox, and C2 when passing through monitored communication paths. Connections to these legitimate services alone are not sufficient to confirm maliciousness.

Endpoint / EDR

  • App lists, APK installation sources, device administrator and accessibility settings, encrypted .enc files, and ransom notices identifiable via MDM/MTD or device investigations. MediaProjection is a screen capture API, and whether historical usage records can be obtained depends on collection capabilities.

Identity / IdP

  • Authentication from unusual devices or sources for business accounts used on the target device. The capability to steal OTPs and the successful unauthorized use of a specific account must be verified separately.

SaaS / Cloud

  • Check for abnormal access within your organization's SaaS. Internal records of Firebase operated by the attacker cannot be retrieved from your organization's audit logs.

Network

  • Duration and transfer volume of HTTPS and WebSocket connections. Metadata from encrypted communications alone cannot identify whether the transmitted content is a screen or an SMS.

9. Attack Success Determination

  • Malware Behavior Confirmed in Sample Analysis: Zimperium demonstrated behaviors such as permission requests, C2 registration, encryption, and screen capture during sample analysis. They also verified negotiation records and infected device data from the Firebase side. A distinction is made between the capabilities identified in the analysis and the range of functions actually executed and information stolen for each victim. Negotiation records alone do not confirm successful theft of individual information or ransom payments.

10. Investigation Playbook

Inference: The following are investigation procedures to follow if a similar attack is suspected within your organization.

Starting Point

  • Start with suspicious APKs, unfamiliar accessibility permissions, disrupted screen operations, .enc files, and ransom demands.

Initial Verification

  • Record distribution links and messages, installation times, APK package names and hashes, OS versions, and granted permissions. Use a separate trusted device to contact users.

Endpoint

  • Check device administrator and accessibility settings, suspicious apps, encrypted files, and signs of screen capture. Obtainable information depends on MDM/MTD capabilities and device status.

Identity / Cloud

  • Identify business accounts used on the device and review sign-ins and data access from the suspected time of infection onward.

Follow-up Investigation

  • Correlate APK and permission settings on the device chronologically with communications consistent with C2 registration and file transmission. Investigate other users who received the same distribution link or APK.

Containment

  • Restrict communications from suspicious devices via MDM or network controls, and revoke business account sessions. After preserving necessary evidence, follow administrative procedures to determine whether to remove the app, factory reset or re-register the device, and change potentially compromised credentials from a secure device.

Assessment

  • Record APK receipt and installation, permission grants and execution, file encryption, data exfiltration, and account abuse as separate stages. Do not apply the full list of sample capabilities to the impact scope of all victims.

11. Defense and Detection Ideas

Inference: The following are proposed detections and countermeasures based on publicly available information. Do not judge maliciousness based on a single match alone; cross-reference with normal business operations.

Single Event

  • Identify the granting of accessibility or device administrator privileges to suspicious apps, mass .enc conversion of user files, or ransom screens.

Timeline Correlation

  • Correlate external APK installation, permission grants, C2 connections, file modifications or continuous exfiltration, and subsequent abnormal business account authentication by device, user, and time.

Hunting

  • Search not only for APK hashes, but also installation sources, package information, dangerous permission combinations, and related communications. Do not rely solely on the use of GitHub, Firebase, and Catbox as evidence of maliciousness.

Log Gaps

  • Verify the recording scope of MDM/MTD regarding apps, permissions, and communications. Visibility into personal apps and data on BYOD devices, as well as traffic over cellular networks, may be limited. Supplement investigations with user reports and IdP records.

Priority Countermeasures

  • On managed devices, restrict apps to approved distribution paths and enable protection features like Play Protect.
  • Limit accessibility permissions and device administrator privileges to trusted apps required for business.
  • Update to supported operating systems and control communication to attacker C2s and other endpoints. Simply meeting the Android 10 or higher condition does not prevent the theft of screens, SMS, and other data.

12. Facts / Inference / Hypothesis

Facts

  • Zimperium identified APKs hosted on external file-sharing services and suggested distribution paths involving manual installation via sharing links or messages.
  • The APK requests device administrator privileges, permissions for SMS, contacts, audio, and images, and finally Accessibility permissions.
  • The analyzed sample retrieves the C2 connection domain from GitHub and registers the device ID, location, mobile carrier, and Android version via HTTPS. The initial version uses Firebase, while v2 uses WebSockets to receive commands.
  • The analyzed sample retrieves victim-specific AES keys from the C2, encrypts files, deletes the originals, and replaces them with .enc files. Zimperium explains that shared storage is broadly scanned on Android 9 and earlier, while scoped storage narrows the target under analysis conditions on Android 10 and later. For general Android apps, target SDKs and permitted access methods also play a role.
  • Uses Accessibility to retrieve WhatsApp and Telegram content, and steals SMS OTPs, lock screen PINs, notifications, history, and location data.
  • Captures still images, videos, and live screens via MediaProjection. It features still images and MP4 videos sent to Catbox with URLs returned to the attacker, alongside live streaming that sends compressed and encoded screen frames. Version 2 also includes screen locks, repetitive dialogs, full-screen videos, image pop-ups, and text-to-speech.

Inference

  • Observable logs, investigation playbooks, and defense/detection ideas are proposals based on behaviors demonstrated in sample analysis. Device permissions, communications, and business account logs are cross-referenced, but it is not presumed that all functions operated for every victim.

Hypothesis

No additional hypotheses. Unconfirmed items are noted in "Unknowns and Additional Investigations."

13. MITRE ATT&CK Mapping

Inference: Mapping based on published behaviors.

  • T1660 Phishing (Confidence: medium): Corresponds to the distribution path suggested by Zimperium, enticing manual APK installation via messages or phishing.
  • T1453 Abuse Accessibility Features (Confidence: high): Uses Accessibility to capture screens, messages, and perform operations.
  • T1513 Screen Capture (Confidence: high): Captures screens using MediaProjection.
  • T1471 Data Encrypted for Impact (Confidence: high): Mobile ATT&CK technique corresponding to file encryption on Android.

14. Unknowns and Additional Investigations

  • Overall infection scale, actual scope of theft and encryption per victim, and ransom payment status.
  • Confirmed attribution of the attacker and distribution scale of v1 and v2.

15. Impact on SOCs and Organizations

For BYOD and corporate Android devices, administrators must verify OS versions, external APK installation paths, and accessibility permission statuses. Even if encryptible files are restricted, SMS and screen collection can still succeed through separate permissions and features. It is important for SOCs to correlate device management and mobile threat defense records, IdP data, and monitorable communication logs to separately investigate device anomalies and unauthorized business account usage.

16. Summary by Target Audience

  • SOC: Correlates unofficial APKs, accessibility grants, Firebase/Catbox/unknown C2 communications, and subsequent abnormal authentications.
  • Administrators: Prohibit unofficial apps and centrally manage Play Protect, OS updates, and device administrator/accessibility permissions.
  • Users: Do not install APKs from outside Google Play and do not grant unexplained device administrator, accessibility, or screen sharing permissions.

Top comments (0)