Presented by: Ashwin (Microsoft Azure MVP)
Android/Chuli.A is Android malware that was delivered to activist groups via a spearphishing email with an attachment.
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/Chuli.A gathered system information including phone number, OS version, phone model, and SDK version.
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/Chuli.A stole geo-location data.
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.
Android/Chuli.A stole geo-location data.
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.
Android/Chuli.A stole call logs.
Adversaries may utilize standard operating system APIs to gather call log data. On Android, this can be accomplished using the Call Log Content Provider. iOS provides no standard API to access the call log.
If the device has been jailbroken or rooted, an adversary may be able to access the Call Log without the user’s knowledge or approval.
User Guidance
Call Log access an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their call logs.
On Android, the user can manage which applications have permission to access the call log through the device settings screen, revoking the permission if necessary. Application vetting services could look for android.permission.READ_CALL_LOG in an Android application’s manifest. Most applications do not need call log access, so extra scrutiny could be applied to those that request it.
Android/Chuli.A stole contact list data stored both on the the phone and the SIM card.
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.
Android/Chuli.A stole SMS message content.
Adversaries may utilize standard operating system APIs to gather SMS messages. On Android, this can be accomplished using the SMS Content Provider. iOS provides no standard API to access SMS messages.
If the device has been jailbroken or rooted, an adversary may be able to access SMS Messages without the user’s knowledge or approval.
User Guidance
Access to SMS messages is an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their SMS messages.
On Android, the user can manage which applications have permission to access SMS messages through the device settings screen, revoking the permission if necessary. Application vetting services could look for android.permission.READ_SMS in an Android application’s manifest. Most applications do not need access to SMS messages, so extra scrutiny could be applied to those that request it.
Android/Chuli.A used HTTP uploads to a URL as a command and control mechanism.
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/Chuli.A used SMS to receive command and control messages.
Adversaries may communicate with compromised devices using out of band data streams. This could be done for a variety of reasons, including evading network traffic monitoring, as a backup method of command and control, or for data exfiltration if the device is not connected to any Internet-providing networks (i.e. cellular or Wi-Fi). Several out of band data streams exist, such as SMS messages, NFC, and Bluetooth.
On Android, applications can read push notifications to capture content from SMS messages, or other out of band data streams. This requires that the user manually grant notification access to the application via the settings menu. However, the application could launch an Intent to take the user directly there.
On iOS, there is no way to programmatically read push notifications.
User Guidance
Users should be instructed to not grant applications unexpected or unnecessary permissions.
If a user sees a notification with text they do not recognize, they should review their list of installed applications.
Copyright © 2022 AshwinPro