Presented by: Ashwin (Microsoft Azure MVP)
Android/AdDisplay.Ashas is a variant of adware that has been distributed through multiple apps in the Google Play Store.
Source:
MITRE ATT&CK® Matrix for Enterprise
Now, let's see the details around the series of events associated with this software in chronological order, and how we can work to mitigate or detect these threats.
Android/AdDisplay.Ashas has registered to receive the BOOT_COMPLETED broadcast intent to activate on device startup.
Adversaries may establish persistence using system mechanisms that trigger execution based on specific events. Mobile operating systems have means to subscribe to events such as receiving an SMS message, device boot completion, or other device activities.
An intent is a message passed between Android applications or system components. Applications can register to receive broadcast intents at runtime, which are system-wide intents delivered to each app when certain events happen on the device, such as network changes or the user unlocking the screen. Malicious applications can then trigger certain actions within the app based on which broadcast intent was received.
In addition to Android system intents, malicious applications can register for intents broadcasted by other applications. This allows the malware to respond based on actions in other applications. This behavior typically indicates a more intimate knowledge, or potentially the targeting of specific devices, users, or applications.
In Android 8 (API level 26), broadcast intent behavior was changed, limiting the implicit intents that applications can register for in the manifest. In most cases, applications that register through the manifest will no longer receive the broadcasts. Now, applications must register context-specific broadcast receivers while the user is actively using the app.
Use Recent OS Version
Android 8 introduced additional limitations on the implicit intents that an application can register for.
Application vetting services can detect which broadcast intents an application registers for and which permissions it requests.
Android/AdDisplay.Ashas has hidden the C2 server address using base-64 encoding.
Adversaries may attempt to make a payload or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the device or in transit. This is common behavior that can be used across different platforms and the network to evade defenses.
Payloads may be compressed, archived, or encrypted in order to avoid detection. These payloads may be used during Initial Access or later to mitigate detection. Portions of files can also be encoded to hide the plaintext strings that would otherwise help defenders with discovery. Payloads may also be split into separate, seemingly benign files that only reveal malicious functionality when reassembled.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Dynamic analysis, when used in application vetting, may in some cases be able to identify malicious code in obfuscated or encrypted form by detecting the code at execution time (after it is deobfuscated or decrypted). Some application vetting techniques apply reputation analysis of the application developer and can alert to potentially suspicious applications without actual examination of application code.
Android/AdDisplay.Ashas can hide its icon and create a shortcut based on the C2 server response.
A malicious application could suppress its icon from being displayed to the user in the application launcher. This hides the fact that it is installed, and can make it more difficult for the user to uninstall the application. Hiding the application's icon programmatically does not require any special permissions.
This behavior has been seen in the BankBot/Spy Banker family of malware.
Beginning in Android 10, changes were introduced to inhibit malicious applications’ ability to hide their icon. If an app is a system app, requests no permissions, or does not have a launcher activity, the application’s icon will be fully hidden. Further, if the device is fully managed or the application is in a work profile, the icon will be fully hidden. Otherwise, a synthesized activity is shown, which is a launcher icon that represents the app’s details page in the system settings. If the user clicks the synthesized activity in the launcher, they are taken to the application’s details page in the system settings.
Use Recent OS Version
Android 10 introduced changes to prevent malicious applications from fully suppressing their icon in the launcher.
User Guidance
Users should be shown what a synthetic activity looks like so they can scrutinize them in the future.
The user can examine the list of all installed applications, including those with a suppressed icon, in the device settings. If the user is redirected to the device settings when tapping an application’s icon, they should inspect the application to ensure it is genuine. Application vetting services could potentially detect the usage of APIs intended for suppressing the application’s icon.
Android/AdDisplay.Ashas can check that the device IP is not in the range of known Google IP addresses before triggering the payload and can delay payload deployment to avoid detection during testing and avoid association with unwanted ads.
Adversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behavior after checking for the presence of artifacts indicative of a virtual environment or sandbox. If the adversary detects a virtual environment, they may alter their malware’s behavior to disengage from the victim or conceal the core functions of the implant. They may also search for virtualization artifacts before dropping secondary or additional payloads.
Checks could include generic system properties such as host/domain name and samples of network traffic. Adversaries may also check the network adapters addresses, CPU core count, and available memory/drive size.
Hardware checks, such as the presence of motion sensors, could also be used to gather evidence that can be indicative a virtual environment. Adversaries may also query for specific readings from these devices.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Application vetting services could look for applications attempting to get android.os.SystemProperties or getprop with the runtime exec() commands. This could indicate some level of sandbox evasion, as Google recommends against using system properties within applications.
Android/AdDisplay.Ashas has checked to see how many apps are installed, and specifically if Facebook or FB Messenger are installed.
Adversaries may attempt to get a listing of applications that are installed on a device. Adversaries may use the information from Software Discovery during automated discovery to shape follow-on behaviors, including whether or not to fully infect the target and/or attempts specific actions.
Adversaries may attempt to enumerate applications for a variety of reasons, such as figuring out what security measures are present or to identify the presence of target applications.
Use Recent OS Version
Android 11 introduced privacy enhancements to package visibility, filtering results that are returned from the package manager. iOS 12 removed the private API that could previously be used to list installed applications on non-app store applications.
User Guidance
iOS users should be instructed to not download applications from unofficial sources, as applications distributed via the Apple App Store cannot list installed applications on a device.
Application vetting services could look for the Android permission android.permission.QUERY_ALL_PACKAGES, and apply extra scrutiny to applications that request it. On iOS, application vetting services could look for usage of the private API LSApplicationWorkspace and apply extra scrutiny to applications that employ it.
Android/AdDisplay.Ashas can collect information about the device including device type, OS version, language, free storage space, battery status, device root, and if developer mode is enabled.
Adversaries may attempt to get detailed information about a device’s operating system and hardware, including versions, patches, and architecture. Adversaries may use the information from System Information Discovery during automated discovery to shape follow-on behaviors, including whether or not to fully infects the target and/or attempts specific actions.
On Android, much of this information is programmatically accessible to applications through the android.os.Build class. iOS is much more restrictive with what information is visible to applications. Typically, applications will only be able to query the device model and which version of iOS it is running.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
System information discovery can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.
Android/AdDisplay.Ashas has communicated with the C2 server using HTTP.
Adversaries may communicate using application layer protocols associated with web protocols traffic to avoid detection/network filtering by blending in with existing traffic. Commands to remote mobile devices, and often the results of those commands, will be embedded within the protocol traffic between the mobile client and server.
Web protocols such as HTTP and HTTPS are used for web traffic as well as well as notification services native to mobile messaging services such as Google Cloud Messaging (GCM) and newly, Firebase Cloud Messaging (FCM), (GCM/FCM: two-way communication) and Apple Push Notification Service (APNS; one-way server-to-device). Such notification services leverage HTTP/S via the respective API and are commonly abused on Android and iOS respectively in order blend in with routine device traffic making it difficult for enterprises to inspect.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Abuse of standard application protocols can be difficult to detect as many legitimate mobile applications leverage such protocols for language-specific APIs. Enterprises may be better served focusing on detection at other stages of adversarial behavior.
Android/AdDisplay.Ashas can generate revenue by automatically displaying ads.
Adversaries may generate outbound traffic from devices. This is typically performed to manipulate external outcomes, such as to achieve carrier billing fraud or to manipulate app store rankings or ratings. Outbound traffic is typically generated as SMS messages or general web traffic, but may take other forms as well.
If done via SMS messages, Android apps must hold the SEND_SMS permission. Additionally, sending an SMS message requires user consent if the recipient is a premium number. Applications cannot send SMS messages on iOS
User Guidance
Users should be advised that applications generally do not require permission to send SMS messages.
On Android, users can review which applications can use premium SMS features in the "Special access" page within application settings. Application vetting services can detect when applications request the SEND_SMS permission, which should be infrequently used.
Copyright © 2022 AshwinPro