Full Report
I was recently on a mobile assessment where you could only register one profile on the app, per device. To use another account you had to first deactivate the profile and then register a new one. I wasn’t sure whether that would invalidate the original token especially since my goal was to test authorisation issues against the backend. Sure, I could have tested whether the token was invalidated or not, which later I found out it wasn’t. But there were other restrictions within this environment which made me look for a different approach.
Analysis Summary
# Tool/Technique: Utilizing Android Multi-User Functionality via ADB and Frida
## Overview
This summarizes techniques observed during a mobile security assessment focused on bypassing application limitations (specifically, one profile per device registration). The core approach leverages built-in Android multi-user features, managed via the Android Debug Bridge (`adb`) and dynamic instrumentation framework Frida, to run multiple instances of the target application under different user contexts on a single physical device.
## Technical Details
- Type: Technique (Leveraging inherent OS feature)
- Platform: Android
- Capabilities: User account creation/management, application installation specific to a user ID, dynamic instrumentation across user contexts.
- First Seen: The article describes observations related to established Android features, with Frida support for this feature being added around July 2020 (Frida 12.11 release).
## MITRE ATT&CK Mapping
Since this relies on leveraging legitimate operating system features for circumventing application controls, the primary mappings relate to discovery and defense evasion through system configuration.
- **TA0005 - Defense Evasion**
- **T1080 - Taint Checking Bypass** (By isolating activity into separate user profiles, the analyst attempts to bypass application restrictions that might monitor activity within a single user context.)
- **TA0007 - Discovery**
- **T1082 - System Information Discovery** (Using `adb shell dumpsys user` to enumerate user state.)
## Functionality
### Core Capabilities
- **User Creation and Management:** Creating new user accounts on the Android device using `adb shell pm create-user [username]` and removing them with `adb shell pm remove-user [user id]`.
- **Configuration Override:** Temporarily increasing the maximum user limit via root access using `setprop fw.max_users` and `setprop fw.show_multiuserui 1`.
- **User-Specific Application Installation:** Installing the target application (APK) under a specific user context using `adb install --user [user id] [path to .apk]`.
- **Context Switching:** Changing the active user session via the device's power menu or notification bar icon, allowing separate application instances to run concurrently or switch between them.
### Advanced Features
- **Frida Instrumentation Across Users:** Using Frida version 12.11+ to attach to and instrument processes running under a specific user ID using the `--aux="uid=(int)[user id]"` flag (e.g., `frida -U --aux="uid=(int)11" -f za.co.mobile.app`). This enables dynamic analysis on the secondary user profiles.
- **Advanced System State Dumping:** Retrieving detailed runtime information about all users using `adb shell dumpsys user`.
## Indicators of Compromise
As this technique describes a blue-team/pentesting approach leveraging standard OS tools and features, there are no typical malware IoCs. Instead, indicators would be related to the execution of these privileged commands:
- File Hashes: N/A (Utilizes standard OS binaries)
- File Names: N/A
- Registry Keys: N/A (Device runtime properties modified via `setprop`)
- Network Indicators: N/A
- Behavioral Indicators:
- Execution of `adb shell pm create-user` or `adb shell pm remove-user` from an attached host system.
- Modification of system properties (`fw.max_users`, `fw.show_multiuserui`) via `su` or a root shell.
- Observation of high privileges required (root/Magisk) to enable multi-user limits.
- Use of Frida with the `--aux` flag specifying a non-primary user ID (`uid=(int)X`).
## Associated Threat Actors
This methodology is primarily associated with ethical hackers, mobile security testers, or potentially sophisticated threat actors looking to bypass single-session restrictions or manage multiple accounts on one device without detection mechanisms tied to a single user profile. No specific APT groups are explicitly linked to this technique in the article.
## Detection Methods
Detection relies on monitoring system-level activities:
- Signature-based detection: N/A
- Behavioral detection: Monitoring the execution of privileged `adb` commands related to user management (`pm create-user`, `setprop`), especially if executed frequently or from unusual contexts.
- YARA rules if available: N/A
## Mitigation Strategies
- **Prevention Measures:**
- Disable USB debugging (ADB access) when the device is not under strict organizational control.
- Implement enterprise device management (MDM) policies that restrict the ability to create new user profiles.
- For sensitive applications, ensure that server-side session management is robust and **not** solely dependent on token validity after a profile deactivation/switch (as the tokens were found to persist in this scenario).
- **Hardening Recommendations:**
- Restrict root access or the ability to elevate privileges (`su`) on user devices.
- Configure application logic to tie authentication tokens or session states explicitly to the logged-in user ID managed by the application, rather than relying on OS-level separation alone if security demands it.
## Related Tools/Techniques
- **Android Debug Bridge (ADB):** The primary tool used for system interaction.
- **Frida:** Used for dynamic binary instrumentation integrated with multi-user awareness.
- **Magisk/SuperSU:** Tools used to gain root access necessary for overriding user limits (`fw.max_users`).