Presented by: Ashwin (Microsoft Azure MVP)
Anubis is Android malware that was originally used for cyber espionage, and has been retooled as a banking trojan.
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.
Anubis can download attacker-specified APK files.
Adversaries may download and execute dynamic code not included in the original application package after installation. This technique is primarily used to evade static analysis checks and pre-publication scans in official app stores. In some cases, more advanced dynamic or behavioral analysis techniques could detect this behavior. However, in conjunction with Execution Guardrails techniques, detecting malicious code downloaded after installation could be difficult.
On Android, dynamic code could include native code, Dalvik code, or JavaScript code that utilizes Android WebView’s JavascriptInterface capability.
On iOS, dynamic code could be downloaded and executed through 3rd party libraries such as JSPatch.
Use Recent OS Version
Applications that target Android API level 29 or higher cannot execute native code stored in the application's internal data storage directory, limiting the ability of applications to download and execute native code at runtime.
Existing network infrastructure may detect network calls to known malicious domains or the transfer of malicious payloads over the network. Mobile security products may provide URL inspection services that could determine if a domain being visited is malicious. Application vetting services could look for indications that the application downloads and executes new code at runtime (e.g., on Android, use of DexClassLoader, System.load, or the WebView JavaScriptInterface capability; on iOS, use of JSPatch or similar capabilities). Unfortunately, this is only a partial mitigation, as additional scrutiny would still need to be applied to applications that use these techniques. These techniques are often used without malicious intent, and applications may employ other techniques to hide their use of these techniques.
Anubis can modify administrator settings and disable Play Protect.
Adversaries may disable security tools to avoid potential detection of their tools and activities. This can take the form of disabling security software, modifying SELinux configuration, or other methods to interfere with security tools scanning or reporting information. This is typically done by abusing device administrator permissions or using system exploits to gain root access to the device to modify protected system files.
Deploy Compromised Device Detection Method
Mobile security software can typically detect if a device has been rooted or jailbroken and can inform the user, who can then take appropriate action.
Security Updates
Security updates frequently contain patches to vulnerabilities that can be exploited for root access.
System Partition Integrity
System partition integrity mechanisms, such as Verified Boot, can detect the unauthorized modification of system files.
User Guidance
Users should be taught the dangers of rooting or jailbreaking their device.
Users can view a list of active device administrators in the device settings.
Anubis has used motion sensor data to attempt to determine if it is running in an emulator.
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.
Anubis has a keylogger that works in every application installed on the device.
Adversaries may log user keystrokes to intercept credentials or other information from the user as the user types them.
Some methods of keylogging include:
Enterprise Policy
When using Samsung Knox, third-party keyboards must be explicitly added to an allow list in order to be available to the end-user.
User Guidance
Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as keyboard registration or accessibility service access.
On Android, users can view and manage which applications have third-party keyboard access through the device settings in System -> Languages & input -> Virtual keyboard. On iOS, users can view and manage which applications have third-party keyboard access through the device settings in General -> Keyboard.
Application vetting services can look for applications requesting the android.permission.BIND_ACCESSIBILITY_SERVICE permission in a service declaration. On Android, users can view and manage which applications can use accessibility services through the device settings in Accessibility. The exact device settings menu locations may vary between operating system versions.
Anubis can create overlays to capture user credentials for targeted applications.
Adversaries may mimic common operating system GUI components to prompt users for sensitive information with a seemingly legitimate prompt. The operating system and installed applications often have legitimate needs to prompt the user for sensitive information such as account credentials, bank account information, or Personally Identifiable Information (PII). Compared to traditional PCs, the constrained display size of mobile devices may impair the ability to provide users with contextual information, making users more susceptible to this technique’s use.
There are several approaches adversaries may use to mimic this functionality. Adversaries may impersonate the identity of a legitimate application (e.g. use the same application name and/or icon) and, when installed on the device, may prompt the user for sensitive information. Adversaries may also send fake device notifications to the user that may trigger the display of an input prompt when clicked.
Additionally, adversaries may display a prompt on top of a running, legitimate application to trick users into entering sensitive information into a malicious application rather than the legitimate application. Typically, adversaries need to know when the targeted application and the individual activity within the targeted application is running in the foreground to display the prompt at the proper time. Adversaries can abuse Android’s accessibility features to determine which application is currently in the foreground. Two known approaches to displaying a prompt include:
Enterprise Policy
An EMM/MDM can use the Android DevicePolicyManager.setPermittedAccessibilityServices method to set an explicit list of applications that are allowed to use Android's accessibility features.
Use Recent OS Version
The HIDE_OVERLAY_WINDOWS permission was introduced in Android 12 allowing apps to hide overlay windows of type TYPE_APPLICATION_OVERLAY drawn by other apps with the SYSTEM_ALERT_WINDOW permission, preventing other applications from creating overlay windows on top of the current application.
Android users can view and manage which applications hold the SYSTEM_ALERT_WINDOW permission through the device settings in Apps & notifications -> Special app access -> Display over other apps (the exact menu location may vary between Android versions).
Application vetting services can look for applications requesting the android.permission.SYSTEM_ALERT_WINDOW permission in the list of permissions in the app manifest.
Anubis can collect a list of installed applications to compare to a list of targeted applications.
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.
Anubis can collect a list of running processes.
Adversaries may attempt to get information about running processes on a device. Information obtained could be used to gain an understanding of common software/applications running on devices within a network. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.
Recent Android security enhancements have made it more difficult to obtain a list of running processes. On Android 7 and later, there is no way for an application to obtain the process list without abusing elevated privileges. This is due to the Android kernel utilizing the hidepid mount feature. Prior to Android 7, applications could utilize the ps command or examine the /proc directory on the device.
In iOS, applications have previously been able to use the sysctl command to obtain a list of running processes. This functionality has been removed in later iOS versions.
Attestation
Attestation can typically detect rooted devices. For MDM-enrolled devices, action can be taken if a device fails an attestation check.
Use Recent OS Version
Android 7 and later iOS versions introduced changes that prevent applications from performing Process Discovery without elevated privileges.
Mobile security products can typically detect rooted devices, which is an indication that Process Discovery is possible. Application vetting could potentially detect when applications attempt to abuse root access or root the system itself. Further, application vetting services could look for attempted usage of legacy process discovery mechanisms, such as the usage of ps or inspection of the /proc directory.
Anubis can collect the device’s ID.
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.
Anubis can retrieve the device’s GPS location.
Adversaries may track a device’s physical location through use of standard operating system APIs via malicious or exploited applications on the compromised device.
On Android, applications holding the ACCESS_COAURSE_LOCATION or ACCESS_FINE_LOCATION permissions provide access to the device’s physical location. On Android 10 and up, declaration of the ACCESS_BACKGROUND_LOCATION permission in an application’s manifest will allow applications to request location access even when the application is running in the background. Some adversaries have utilized integration of Baidu map services to retrieve geographical location once the location access permissions had been obtained.
On iOS, applications must include the NSLocationWhenInUseUsageDescription, NSLocationAlwaysAndWhenInUseUsageDescription, and/or NSLocationAlwaysUsageDescription keys in their Info.plist file depending on the extent of requested access to location information. On iOS 8.0 and up, applications call requestWhenInUseAuthorization() to request access to location information when the application is in use or requestAlwaysAuthorization() to request access to location information regardless of whether the application is in use. With elevated privileges, an adversary may be able to access location data without explicit user consent with the com.apple.locationd.preauthorized entitlement key.
Enterprise Policy
If devices are enrolled using Apple User Enrollment or using a profile owner enrollment mode for Android, device controls prevent the enterprise from accessing the device’s physical location. This is typically used for a Bring Your Own Device (BYOD) deployment.
Interconnection Filtering
Filtering requests by checking request origin information may provide some defense against spurious operators.
Use Recent OS Version
On Android 11 and up, users are not prompted with the option to select "Allow all the time" and must navigate to the settings page to manually select this option. On iOS 14 and up, users can select whether to provide Precise Location for each installed application.
User Guidance
Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as access to location information. Users should also protect their account credentials and enable multi-factor authentication options when available.
Android applications requesting the ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, or ACCESS_BACKGROUND_LOCATION permissions and iOS applications including the NSLocationWhenInUseUsageDescription, NSLocationAlwaysAndWhenInUseUsageDescription, and/or NSLocationAlwaysUsageDescription keys in their Info.plist file could be scrutinized during the application vetting process.
In both Android (6.0 and up) and iOS, users can view which applications have the permission to access the device location through the device settings screen and revoke permissions as necessary.
Anubis has a keylogger that works in every application installed on the device.
Adversaries may log user keystrokes to intercept credentials or other information from the user as the user types them.
Some methods of keylogging include:
Enterprise Policy
When using Samsung Knox, third-party keyboards must be explicitly added to an allow list in order to be available to the end-user.
User Guidance
Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as keyboard registration or accessibility service access.
On Android, users can view and manage which applications have third-party keyboard access through the device settings in System -> Languages & input -> Virtual keyboard. On iOS, users can view and manage which applications have third-party keyboard access through the device settings in General -> Keyboard.
Application vetting services can look for applications requesting the android.permission.BIND_ACCESSIBILITY_SERVICE permission in a service declaration. On Android, users can view and manage which applications can use accessibility services through the device settings in Accessibility. The exact device settings menu locations may vary between operating system versions.
Anubis can create overlays to capture user credentials for targeted applications.
Adversaries may mimic common operating system GUI components to prompt users for sensitive information with a seemingly legitimate prompt. The operating system and installed applications often have legitimate needs to prompt the user for sensitive information such as account credentials, bank account information, or Personally Identifiable Information (PII). Compared to traditional PCs, the constrained display size of mobile devices may impair the ability to provide users with contextual information, making users more susceptible to this technique’s use.
There are several approaches adversaries may use to mimic this functionality. Adversaries may impersonate the identity of a legitimate application (e.g. use the same application name and/or icon) and, when installed on the device, may prompt the user for sensitive information. Adversaries may also send fake device notifications to the user that may trigger the display of an input prompt when clicked.
Additionally, adversaries may display a prompt on top of a running, legitimate application to trick users into entering sensitive information into a malicious application rather than the legitimate application. Typically, adversaries need to know when the targeted application and the individual activity within the targeted application is running in the foreground to display the prompt at the proper time. Adversaries can abuse Android’s accessibility features to determine which application is currently in the foreground. Two known approaches to displaying a prompt include:
Enterprise Policy
An EMM/MDM can use the Android DevicePolicyManager.setPermittedAccessibilityServices method to set an explicit list of applications that are allowed to use Android's accessibility features.
Use Recent OS Version
The HIDE_OVERLAY_WINDOWS permission was introduced in Android 12 allowing apps to hide overlay windows of type TYPE_APPLICATION_OVERLAY drawn by other apps with the SYSTEM_ALERT_WINDOW permission, preventing other applications from creating overlay windows on top of the current application.
Android users can view and manage which applications hold the SYSTEM_ALERT_WINDOW permission through the device settings in Apps & notifications -> Special app access -> Display over other apps (the exact menu location may vary between Android versions).
Application vetting services can look for applications requesting the android.permission.SYSTEM_ALERT_WINDOW permission in the list of permissions in the app manifest.
Anubis can record phone calls and audio.
Adversaries may capture audio to collect information by leveraging standard operating system APIs of a mobile device. Examples of audio information adversaries may target include user conversations, surroundings, phone calls, or other sensitive information.
Android and iOS, by default, require that applications request device microphone access from the user.
On Android devices, applications must hold the RECORD_AUDIO permission to access the microphone or the CAPTURE_AUDIO_OUTPUT permission to access audio output. Because Android does not allow third-party applications to hold the CAPTURE_AUDIO_OUTPUT permission by default, only privileged applications, such as those distributed by Google or the device vendor, can access audio output. However, adversaries may be able to gain this access after successfully elevating their privileges. With the CAPTURE_AUDIO_OUTPUT permission, adversaries may pass the MediaRecorder.AudioSource.VOICE_CALL constant to MediaRecorder.setAudioOutput, allowing capture of both voice call uplink and downlink.
On iOS devices, applications must include the NSMicrophoneUsageDescription key in their Info.plist file to access the microphone.
Use Recent OS Version
Android 9 and above restricts access to microphone, camera, and other sensors from background applications.
User Guidance
Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as access to microphone or audio output.
In iOS 14 and up, an orange dot (or orange square if the Differentiate Without Color setting is enabled) appears in the status bar when the microphone is being used by an application. However, there have been demonstrations indicating it may still be possible to access the microphone in the background without triggering this visual indicator by abusing features that natively access the microphone or camera but do not trigger the visual indicators.
In Android 12 and up, a green dot appears in the status bar when the microphone is being used by an application.
Android applications using the RECORD_AUDIO permission and iOS applications using RequestRecordPermission should be carefully reviewed and monitored. If the CAPTURE_AUDIO_OUTPUT permission is found in a third-party Android application, the application should be heavily scrutinized.
In both Android (6.0 and up) and iOS, users can review which applications have the permission to access the microphone through the device settings screen and revoke permissions as necessary.
Anubis can retrieve the device’s GPS location.
Adversaries may track a device’s physical location through use of standard operating system APIs via malicious or exploited applications on the compromised device.
On Android, applications holding the ACCESS_COAURSE_LOCATION or ACCESS_FINE_LOCATION permissions provide access to the device’s physical location. On Android 10 and up, declaration of the ACCESS_BACKGROUND_LOCATION permission in an application’s manifest will allow applications to request location access even when the application is running in the background. Some adversaries have utilized integration of Baidu map services to retrieve geographical location once the location access permissions had been obtained.
On iOS, applications must include the NSLocationWhenInUseUsageDescription, NSLocationAlwaysAndWhenInUseUsageDescription, and/or NSLocationAlwaysUsageDescription keys in their Info.plist file depending on the extent of requested access to location information. On iOS 8.0 and up, applications call requestWhenInUseAuthorization() to request access to location information when the application is in use or requestAlwaysAuthorization() to request access to location information regardless of whether the application is in use. With elevated privileges, an adversary may be able to access location data without explicit user consent with the com.apple.locationd.preauthorized entitlement key.
Enterprise Policy
If devices are enrolled using Apple User Enrollment or using a profile owner enrollment mode for Android, device controls prevent the enterprise from accessing the device’s physical location. This is typically used for a Bring Your Own Device (BYOD) deployment.
Interconnection Filtering
Filtering requests by checking request origin information may provide some defense against spurious operators.
Use Recent OS Version
On Android 11 and up, users are not prompted with the option to select "Allow all the time" and must navigate to the settings page to manually select this option. On iOS 14 and up, users can select whether to provide Precise Location for each installed application.
User Guidance
Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as access to location information. Users should also protect their account credentials and enable multi-factor authentication options when available.
Android applications requesting the ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, or ACCESS_BACKGROUND_LOCATION permissions and iOS applications including the NSLocationWhenInUseUsageDescription, NSLocationAlwaysAndWhenInUseUsageDescription, and/or NSLocationAlwaysUsageDescription keys in their Info.plist file could be scrutinized during the application vetting process.
In both Android (6.0 and up) and iOS, users can view which applications have the permission to access the device location through the device settings screen and revoke permissions as necessary.
Anubis can take screenshots.
Adversaries may use screen capture to collect additional information about a target device, such as applications running in the foreground, user data, credentials, or other sensitive information. Applications running in the background can capture screenshots or videos of another application running in the foreground by using the Android MediaProjectionManager (generally requires the device user to grant consent). Background applications can also use Android accessibility services to capture screen contents being displayed by a foreground application. An adversary with root access or Android Debug Bridge (adb) access could call the Android screencap or screenrecord commands.
Application Developer Guidance
Application developers can apply the FLAG_SECURE property to sensitive screens within their apps to make it more difficult for the screen contents to be captured.
Enterprise Policy
Enterprise policies should block access to the Android Debug Bridge (ADB) by preventing users from enabling USB debugging on Android devices unless specifically needed (e.g., if the device is used for application development). An EMM/MDM can use the Android DevicePolicyManager.setPermittedAccessibilityServices method to set an explicit list of applications that are allowed to use Android's accessibility features.
User Guidance
Users should be advised not to grant consent for screen captures to occur unless expected. Users should avoid enabling USB debugging (Android Debug Bridge) unless explicitly required.
The user can view a list of apps with accessibility service privileges in the device settings. Application vetting services can look for the use of the Android MediaProjectionManager class, applying extra scrutiny to applications that use the class.
Anubis exfiltrates data encrypted (with RC4) by its ransomware module.
Adversaries may compress and/or encrypt data that is collected prior to exfiltration. Compressing data can help to obfuscate its contents and minimize use of network resources. Encryption can be used to hide information that is being exfiltrated from detection or make exfiltration less conspicuous upon inspection by a defender.
Both compression and encryption are done prior to exfiltration, and can be performed using a utility, programming library, or custom algorithm.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Many encryption mechanisms are built into standard application-accessible APIs and are therefore undetectable to the end user.
Anubis can exfiltrate files encrypted with the ransomware module from the device and can modify external storage.
Adversaries may search local system sources, such as file systems or local databases, to find files of interest and sensitive data prior to exfiltration.
Access to local system data, which includes information stored by the operating system, often requires escalated privileges. Examples of local system data include authentication tokens, the device keyboard cache, Wi-Fi passwords, and photos. On Android, adversaries may also attempt to access files from external storage which may require additional storage-related permissions.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Accessing data from the local system can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.
Anubis can make phone calls.
Adversaries may make, forward, or block phone calls without user authorization. This could be used for adversary goals such as audio surveillance, blocking or forwarding calls from the device owner, or C2 communication.
Several permissions may be used to programmatically control phone calls, including:
When granted some of these permissions, an application can make a phone call without opening the dialer first. However, if an application desires to simply redirect the user to the dialer with a phone number filled in, it can launch an Intent using Intent.ACTION_DIAL, which requires no specific permissions. This then requires the user to explicitly initiate the call or use some form of Input Injection to programmatically initiate it.
User Guidance
Users should be encouraged to be very careful with what applications they grant phone call-based permissions to. Further, users should not change their default call handler to applications they do not recognize.
Users can view their default phone app in device settings. Users can review available call logs for irregularities, such as missing or unrecognized calls.
Anubis can steal the device’s contact list.
Adversaries may utilize standard operating system APIs to gather contact list data. On Android, this can be accomplished using the Contacts Content Provider. On iOS, this can be accomplished using the Contacts framework.
If the device has been jailbroken or rooted, an adversary may be able to access the Contact List without the user’s knowledge or approval.
User Guidance
Contact list access is an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their contact list.
On both Android and iOS, the user can manage which applications have permission to access the contact list through the device settings screen, revoking the permission if necessary. Application vetting services could look for android.permission.READ_CONTACTS in an Android application’s manifest, or NSContactsUsageDescription in an iOS application’s Info.plist file. Most applications do not need contact list access, so extra scrutiny could be applied to those that request it.
Anubis can retrieve the C2 address from Twitter and Telegram.
Adversaries may use an existing, legitimate external Web service to host information that points to additional command and control (C2) infrastructure. Adversaries may post content, known as a dead drop resolver, on Web services with embedded (and often obfuscated/encoded) domains or IP addresses. Once infected, victims will reach out to and be redirected by these resolvers.
Popular websites and social media, acting as a mechanism for C2, may give a significant amount of cover. This is due to the likelihood that hosts within a network are already communicating with them prior to a compromise. Using common services, such as those offered by Google or Twitter, makes it easier for adversaries to hide in expected noise. Web service providers commonly use SSL/TLS encryption, giving adversaries an added level of protection.
Use of a dead drop resolver may also protect back-end C2 infrastructure from discovery through malware binary analysis, or enable operational resiliency (since this infrastructure may be dynamically changed).
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 may provide a list of connections made or received by an application, or a list of domains contacted by the application.
Anubis can make phone calls.
Adversaries may make, forward, or block phone calls without user authorization. This could be used for adversary goals such as audio surveillance, blocking or forwarding calls from the device owner, or C2 communication.
Several permissions may be used to programmatically control phone calls, including:
When granted some of these permissions, an application can make a phone call without opening the dialer first. However, if an application desires to simply redirect the user to the dialer with a phone number filled in, it can launch an Intent using Intent.ACTION_DIAL, which requires no specific permissions. This then requires the user to explicitly initiate the call or use some form of Input Injection to programmatically initiate it.
User Guidance
Users should be encouraged to be very careful with what applications they grant phone call-based permissions to. Further, users should not change their default call handler to applications they do not recognize.
Users can view their default phone app in device settings. Users can review available call logs for irregularities, such as missing or unrecognized calls.
Anubis can use its ransomware module to encrypt device data and hold it for ransom.
An adversary may encrypt files stored on a mobile device to prevent the user from accessing them. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key (ransomware) or to render data permanently inaccessible in cases where the key is not saved or transmitted.
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 may be able to detect if an application attempts to encrypt files, although this may be benign behavior.
Anubis can send, receive, and delete SMS messages.
Adversaries may delete, alter, or send SMS messages without user authorization. This could be used to hide C2 SMS messages, spread malware, or various external effects.
This can be accomplished by requesting the RECEIVE_SMS or SEND_SMS permissions depending on what the malware is attempting to do. If the app is set as the default SMS handler on the device, the SMS_DELIVER broadcast intent can be registered, which allows the app to write to the SMS content provider. The content provider directly modifies the messaging database on the device, which could allow malicious applications with this ability to insert, modify, or delete arbitrary messages on the device.
User Guidance
Users should be encouraged to be very careful with what applications they grant SMS access to. Further, users should not change their default SMS handler to applications they do not recognize.
Users can view the default SMS handler in system settings.
Anubis can make phone calls.
Adversaries may make, forward, or block phone calls without user authorization. This could be used for adversary goals such as audio surveillance, blocking or forwarding calls from the device owner, or C2 communication.
Several permissions may be used to programmatically control phone calls, including:
When granted some of these permissions, an application can make a phone call without opening the dialer first. However, if an application desires to simply redirect the user to the dialer with a phone number filled in, it can launch an Intent using Intent.ACTION_DIAL, which requires no specific permissions. This then requires the user to explicitly initiate the call or use some form of Input Injection to programmatically initiate it.
User Guidance
Users should be encouraged to be very careful with what applications they grant phone call-based permissions to. Further, users should not change their default call handler to applications they do not recognize.
Users can view their default phone app in device settings. Users can review available call logs for irregularities, such as missing or unrecognized calls.
Copyright © 2022 AshwinPro