At the time of writing, the malware has managed to remain entirely undetected on VirusTotal, demonstrating that the techniques used to allow it to remain under the radar have been successful. Similar malware, such as GigabudRat and Vultur, which also exploit similar techniques such as keylogging and screen capturing, achieve notable anti-evasion results during their attack stages

How MMRat is used in bank fraud

1. The MMRat attack sequence:
2. The victim downloads and installs MMRat.
3. The victim grants MMRat the necessary permissions.
4. MMRat starts to communicate with the remote server and sends a large amount of data that includes device status, personal data, and keylogging data.
5. When the target device isn’t being used, the threat actor can wake up the device remotely, unlock the screen, and perform bank fraud. Concurrently, the threat actor can also initiate screen capturing for server-side visualization of the device screen.
6. In the final step, MMRat uninstalls itself, removing all traces of the malware from the system.

Analysis of MMRat

As previously mentioned, MMRat is capable of capturing user input, screen content and remotely controlling the devices of its victims. It relies heavily on Android Accessibility service and MediaProjection API to function properly.

Impersonation and persistence routine

To avoid suspicion, MMRat often masquerades as an official government or dating app, then presents a phishing website to victims upon being launched. Subsequently, it registers a receiver that can receive system events, including the ability to detect when the system switches on and off, and reboots, among others. Upon the receipt of these events, the malware launches a 1×1-sized pixel activity to ensure its persistence.

Network communication with remote server

Upon initiating the Accessibility service, MMRat establishes a connection with an attacker-controlled server. Notably, MMRat employs different ports on a single server for different functions:

The C&C protocol, in particular, is unique due to its customization based on Netty (a network application framework) and the previously-mentioned Protobuf, complete with well-designed message structures.

For C&C communication, the threat actor uses an overarching structure to represent all message types and the “oneof” keyword to represent different data types. We have meticulously reconstructed the major Protobuf schemas utilized in the C&C communication, as shown in Figure 3.

The “PackType” is an enum structure that can be used to represent C&C commands, while the “pack” field contains detailed data corresponding to different C&C commands.

Table 2 shows the defined C&C commands used by the malware and their corresponding descriptions. Since it involves bidirectional communication, we have divided the C&C commands into server commands and client commands. Server commands are sent to client, while client commands are sent to the server.

Table 2. MMRat C&C commands and their descriptions

Collection of device status and personal information

MMRat collects a wide range of device status and personal data, including network data, screen data, battery data, installed apps, and contact lists.

• Network data includes information such as signal strength and network type.
• Screen data includes information on whether the screen is locked, the app currently in use, and the activity that is currently displayed on the screen.
• Battery data provides information about the device’s battery status.
• Contacts includes the user’s contact list.
• Installed apps includes apps installed on the device.

To collect this data in a timely manner, MMRat schedules a timer task that executes every second while also using a counter that resets every 60 seconds to determine when different tasks are executed.

MMRat specifically targets the victim’s contact and installed app list for collection. We believe the goal of the threat actor is to uncover personal information to ensure the victim fits a specific profile. For instance, the victim may have contacts that meet certain geographical criteria or have a specific app installed. This information can then be used for further malicious activities.

Automatic permission approval

Once Accessibility permission is granted, MMRat can abuse it to grant itself other permissions and modify settings. For example, in the previous data collection phase, MMRat can automatically grant itself the READ_CONTACTS permission to collect contact data.

The code snippet in Figure 4 shows how MMRat can automatically obtain permissions. It achieves this by launching the system dialog and automatically approving incoming permission requests. The automatic approval function is implemented by finding an “ok” or related keyword on the screen and using Accessibility to simulate clicking. This means that MMRat can bypass user intervention and grant itself the necessary permissions to perform its malicious activities.

Actions and capturing user inputs

MMRat abuses the Accessibility service to capture user input and actions via keylogging. This data could be used to obtain the victim’s credentials and record the victim’s actions for later replay on the device.

Unlike other keylogging malware that focus on specific scenarios, such as logging keys only when the victim is using bank apps, MMRat logs every action operated by users and uploads them to the server via the C&C channel. It appears that the threat actor behind MMRat wants to collect a large amount of action logs from the victim to determine the malware’s next steps.

Each log is a LogInfo structure, serialized via Protobuf.

message LogInfo {

        string packageName = 1; 
        string className = 2;
        string content = 3;

}

In addition to conventional keylogging, the malware has a particular interest in the lock screen pattern. If it detects that the user is unlocking the device, the malware collects the pattern value and uploads it to the server through its C&C channel. This allows the threat actor to gain access to the victim’s device even when it is locked.

Capturing screen content

MMRat can capture real-time screen content of the victim’s device and stream the content to a remote server. To capture the screen content, the malware relies primarily on the MediaProjection API to record the victim’s screen. However, we also found that the malware uses another method to acquire screen content and bypass FLAG_SECURE protection, referred to as “user terminal state” by the malware.

Based on our observations, we believe the screen content capturing capability is used in conjunction with remote control functions so the threat actor can view the device’s live status while performing bank fraud. Rather than capturing credentials, we found that the malware will constantly check for commands and will stop screen content streaming if no commands are received within 30 seconds.

Android MediaProjection API

To conveniently use the MediaProjection API and stream video data to the remote server, MMRat abuses an open-source framework called rtmp-rtsp-stream-client-java. This allows it to record the screen and stream real-time video data to a remote server via Real Time Streaming Protocol (RTSP). Upon receiving the MEDIA_STREAM command, MMRat can record two types of data – screen and camera data, according to the issued configuration.

For example, when recording screen data, MMRat launches an activity called DisplayActivity. This activity requests recording permission by calling createScreenCaptureIntent, which triggers a system dialog popup to grant permissions. As previously mentioned, the system dialog is automatically approved via auto-clicking.

Once the recording request is approved, MMRat begins recording the screen and streams the data to the C&C server by calling the API startStream provided by the open-source framework repository.

User terminal state

The so-called “user terminal state” approach to capturing screen content is quite different from the method that employs MediaProjection API. As the name suggests, MMRat doesn’t record the screen as a video. Instead, it abuses the Accessibility service to recursively dump all child nodes in windows every second and upload the dumped data via the C&C channel. Consequently, the result only includes text information without a graphical user interface, therefore resembling a “terminal”.

Although the approach is somewhat crude and requires additional work from the threat actor on the server side to reconstruct the data, it effectively collects the desired information for remote inspection and control (for example, node info for clicking and inputting). Since this approach does not rely on the MediaProjection API, it can bypass the protection of FLAG_SECURE, a flag that can be added to window parameters to prevent screenshots and screen recordings.

Moreover, the use of Protobuf and customized protocols based on Netty enhances performance. This is particularly beneficial when transferring large amounts of screen data in a timely manner, providing the threat actor with an effect similar to a video stream.

Remote controlling

The MMRat malware abuses the Accessibility service to remotely control the victim’s device, performing actions such as gestures, unlocking screens, and inputting text, among others. This can be used by threat actors — in conjunction with stolen credentials — to perform bank fraud.

As outlined in the “How MMRat performs bank fraud” section, we believe that even before executing its remote access routine, MMRat executes several preliminary steps for user evasion:

1. Wakeup: The malware leverages the Accessibility service to simulate a double-click on the screen to wake the device.
2. Unlock screen: The malware uses previously-stolen unlock patterns to unlock the screen.

Finally, MMRat can control the device remotely while the victims are not actively using their phones.

Hiding tracks

The MMRat malware possesses the capability to delete itself upon receiving the C&C command UNINSTALL_APP. This behavior usually takes place after the execution of bank fraud, making it more difficult to trace its activities.

Conclusion and recommendation

MMRat is a potent Android banking trojan that poses a considerable threat to mobile users, particularly in Southeast Asia. Its key capabilities, which includ keylogging, screen recording, and remote control access, enables it to execute bank fraud effectively and efficiently.

To protect against this malware, users are advised to:

1. Only download apps from official sources. MMRat is often downloaded from phishing websites posing as official app stores. Always use trusted platforms such as Google Play Store or Apple App Store.
2. Regularly update device software. Updates often include security enhancements that protect against new threats like MMRat.
3. Be cautious of granting accessibility permissions. MMRat exploits Android’s Accessibility service to carry out its malicious activities. Always scrutinize the permissions requested by apps.
4. Install a reputable security solution on your device. This can help detect and remove threats before they can cause harm.
5. Be vigilant with your personal and banking information. MMRat’s goal is to commit bank fraud, so be cautious about the information you share online and the data you provide to your personal apps.

Trend is part of Google’s App Defense Alliance (ADA), which enhances user security by detecting malicious apps prior to their release on the Google Play store. As part of this alliance, Trend, in partnership with Google, helps protect users from malicious actors, keeping the world safer for exchanging digital information.

Indicators of Compromise

The complete indicators of compromise for this entry can be found here.