Mobile malware analysis for the BBC

This is a version of our report referenced in the Helping a mobile malware fraud victim blog post, with all sensitive information removed.

Summary

One malicious application was identified on the device, and evidence identified during the examination strong suggests (though this cannot be confirmed with absolute certainty) that it is directly related to the incident at hand.

The application was named PDF AI: Add-On. The data extracted from the device suggests that this application was not installed on the device through the Google Play Store, but rather through an alternative method that cannot be definitively identified. This is discussed later in thePropagation section.

The application deceives the user into granting seemingly innocuous accessibility permissions in order to establish the level of access necessary in order to effectively compromise the target device and maintain persistence.

With these permissions, the application is capable of preventing a standard user from removing it by inhibiting simple actions such as powering the phone off, viewing application permissions, or accessing any menus or resources whereby a user could uninstall applications or alter permissions. In addition, the accessibility services enable the application to do the following:

• Record and snoop on user input and activity
• Grant itself further permissions
• Prevent the device from powering off or closing the application
• Automatically relaunch the application upon powering the device on

Further analysis of the additional permissions that this application was granted show that it was able to conduct a number of further actions, which include sending SMS messages, removal of other applications, and various permissions that allow the application to gather further data about the target device.

The application could therefore have been able to covertly gather data while the owner of the device went about their day-to-day usage, harvesting critical information that could feasibly include credentials and bank details.

Analysis

**Malicious application identification **Android applications each have an associated package name. The package name of an Android application uniquely identifies the application on a device, in the Google Play Store, and in supported third-party Android stores.

The PDF AI: Add-On application was positively identified by extracting a list of installed package names from the device and running a lookup of those packages. The application’s package name was noted ascom.sljnofppc.tcrpyvpaw. It did not appear in the Google Play Store, nor could any direct references to this package otherwise be found when conducting further research.

The application package name is significant as it is used to refer to a given application within the operating system, by other applications, and other system artefacts.

**Root cause **The precise root cause of the application’s installation could not be definitively determined. Some evidence was identified, however, that provides some insight into the likely method through which the application was installed.

Data extracted from the Package Manager database on the device provided the following information:

The Installation Time indicates when the application was installed on the device.

The Installer Package records the name of the package that facilitated the installation of the application. The Google Play Store package name, for example, iscom.android.vending, meaning that if any application is installed from the Google Play Store, the recorded Installer Package will reflect this. All other applications on the victim’s device showed the Google Play Store package as the installer package with the exception of the malicious application.

The installer package name seen here as com.google.android.packageinstaller is used when an application package has been installed on the device through the Android Package Installer facility rather than from the Google Play Store (or indeed any other application repository). Android package (APK) files can be downloaded from alternative sources and installed manually on an Android device.

When this method of installation is used, the Installer Package is recorded as com.google.android.packageinstaller. This, paired with thePackage Source, is therefore indicative that the user has run an installer (whether knowingly or not) for the application at the recorded time, resulting in the malware being installed.

In order to test this, the application was installed by copying the APK of the malicious app from the victim’s device onto a clean laboratory test device. The file was opened on the test device, which resulted in the option to install the application using the Android Package Installer. Upon successful installation, logs extracted from the test device showed the same com.google.android.packageinstaller package as the Installer Package associated.

It was not possible to positively identify the APK or any other installation source file on the device at the time of analysis.

**Application behaviour **In order to observe the initial setup and behaviours of the application, the application’s APK was extracted from the device and installed on a test device.

Upon installation, the application icon was visible on the test device as shown below:

Once opened, the application presents a spoofed menu screen that functions purely to redirect the user to the device’s Accessibility setting page, where the user is required to allow the application permission to use Accessibility features:

Once these permissions are granted, the application will remain running as a hidden process. This means that while the user can still see the application on their home screen and menus, any attempts to open it will be unsuccessful.

It is from this point on that the application also employs the aforementioned methods of persistence through preventing access to any areas on the device that might be used by a standard user to attempt to power off the device, discover more about the application, alter any of its assigned permissions, or remove it.

**Application Capabilities **This section will detail the various permissions and capabilities the malicious application was noted to have received on the device at the time of analysis.

**Permissions **Permissions are a means of controlling what data (if any) a given application can access on a device. Application should only require permissions to access data that is directly relevant to, and required for, the operation of the application’s intended functions.

The malicious application can request a significant number of permissions that would allow it to perform a wide variety of functions and access sensitive data. These include:

• Read, write, send, and receive SMS/MMS messages
• Read and remove installed applications
• Read phone status (includes things like registered accounts, phone number, call status)
• Prevent phone sleep and power off (wake lock)
• Ignore battery optimisation
• Use biometrics

Android requires certain permissions (known as runtime permissions) that could allow applications to gain access to confidential user data to prompt the user before they can be used. The following runtime permissions had been requested at installation, but had not been granted during use:

• Read, send, and receive SMS/MSS messages
• Read phone status

Therefore, it is believed that the application could not effectively interact with SMS/MMS messages on the device in order to read their content or to send messages, nor could it read more detailed information about the device and registered accounts. With the aforementioned accessibility permissions however, it is possible that the application could effectively grant itself necessary permissions when the relevant prompts appear on-screen.

The majority of the application’s capabilities come from its permissions as an accessibility application. Accessibility applications are designed to make an Android device more usable and hold special privileges that normal applications cannot request, allowing the application to read text in any application’s activities; view keystrokes and touches; and enter keystrokes and touches. In theory, password fields are protected from Accessibility applications, but there are possible workarounds, especially if a target application has created their own password field.

Reconnaissance and data gathering

As indicated in the accessibility features that the application requests, once these permissions are granted the application is able to read and record data displayed on the device’s screen as well as the user’s input.

In addition to reading the user’s activity, the accessibility features also provide permissions for performing gestures and replacing touch interaction; this effectively means that the application can interact with on-screen menus and interfaces, which allow it to grant itself additional permissions.

When the application was run on a laboratory handset, shortly after the malicious app was first run and the requisite accessibility permissions were granted, a dialog box appeared on-screen for a very brief time that prompted the user to deny or allow the application to always run in the background. Further analysis of available logs showed that the application allowed this option automatically.

In addition, evidence was also identified on the laboratory handset that suggests that the application may have interacted with data in relation to a number of applications, including:

• Google Chrome
• Android Wi-Fi Hotspot
• Google Docs
• Google Mobile Services

This is potentially indicative of further efforts by the malware to gather additional data contained in these applications. It was not possible to determine whether the application had conducted similar activity on the victim’s device.

Though limited data could be extracted from the application itself on the victim’s device, what data was available provide some further insights into the application’s nature.

In particular, a configuration file was identified that contained references to several hundred banking application package names. Of particular note is that most of these contained no further data with the exception of entries for Barclays and Revolut, as seen below.

The data present in relation to Barclays was significant as it was found to be HTML code that presents the following page:

The page itself does not appear to have any built-in functionality to read any user input. It is theorised that the application would present the user with the above spoofed page and instead record any subsequent input through the accessibility permissions it requires. This information could later be used to gain access to the victim’s account as data such as a mother’s maiden name is a common security question used to verify a user’s identity.

Persistence

Persistence refers to a malicious process or application’s ability to remain present and running on a target system despite attempts (whether indirect or deliberate) to remove or kill them.

The application was noted to have been granted the following permissions in this regard:

**Ignore battery optimisation **This would enable the application to continue to run even if specific battery optimisation (i.e. power saving modes) features would normally disable the application. As an example, certain battery optimisation features may prevent applications from continuing to run their normal background processes in order to conserve power. Disabling this would allow the malicious application to continue to run at full capacity regardless of any such optimisation being enabled.

**Run at startup **The application is automatically run when the phone is powered on. This is in place to ensure the application continues to run even if the user manages to power the device down (such as through a hard reset or running down the battery).

**Wake lock **This permission allows the application from preventing the device from sleeping, likely in an attempt to prevent the interruption of any activity by the user putting the device to sleep.

**Identify and delete packages **The application can request a list of currently installed packages/applications and can also remove them. This is likely a functionality intended to allow the application to identify potentially valuable targets such as banking applications, or to remove other applications that might interfere with its processes.

**Appear on top of other apps **This feature can be used to interfere with normal interaction with other apps by forcing them to minimise. It may also be used to facilitate ‘tapjacking’. Tapjacking is a technique used by malicious applications obscure on-screen objects like security control pop-ups (such permission granting options) with an overlay designed to trick the user into tapping where the overlay covers the ‘accept’ button, thereby accepting options unintentionally.

**Propagation **At present, little is known about how the malware is spread. The use of SMS messages and other messaging services and applications is a well-established method commonly used by malicious applications to propagate; oftentimes, such an application will seek to use permissions granted to send, receive, read, and write messages in order to send malicious links and content to others in the compromised device’s address book.

At the time of analysis, no evidence was identified to suggest that any such activity had been conducted. It should be noted, however, that the application was found to have the capacity to request such permissions. As such, it is recommended that the owner requests billing records from their network service provider in order to determine whether any SMS or MMS messages were sent in the time after which the application is known to have been installed. If the malicious application was able to send any messages and subsequently delete them, billing records will still contain a record of the date/time of sending and the recipients’ phone numbers.

It should be noted, however, that billing records will not contain any information relating to third party instant messaging applications such as Facebook Messenger or WhatsApp.

As detailed previously, the malicious application only appeared to have been granted one permission in relation to SMS messages:

**Write SMS **This permission allows the application to create SMS messages; this is, however, distinct from other related permissions that were not granted. Therefore, the application would not have been able to read message content or send messages.

Malicious mobile applications are known to be propagated through a variety of different methods, such as using permissions to create and send SMS messages to send messages containing malicious links or attachments to other contacts within the device’s address book.

Additional findings

Analysis of data extracted from the application installed on the victim’s device also revealed an IP address of 91.215.85.55. This IP resolves to a location in Russia, and is noted to be known to a small number of security vendors as being malicious in nature.

Further analysis of this IP traced it back to a GitLab repository hosting a file named 1.apk. The screenshot below was taken on the 26th of October 2023:

We reported this repository to Gitlab on the 26th October 2023, it was blocked the same day.

While it is unlikely that this is the source of the malicious application observed during this investigation, the 1.apk file is known by a significant number of security vendors to be malicious and is directly referenced as a banking trojan.

Conclusion

PTP assess with high confidence that the malicious application PDF AI: Add-On is linked to or responsible for the fraudulent activity reported by the owner of this device.

The timeline of events from the initial installation of the application to the reported fraud, along with the established capabilities of the application, support this conclusion; no other malicious applications were identified on the device at the time of analysis.

The post Mobile malware analysis for the BBC first appeared on Pen Test Partners.