Presented by: Ashwin (Microsoft Azure MVP)
Asacub is a banking trojan that attempts to steal money from victims’ bank accounts. It attempts to do this by initiating a wire transfer via SMS message from compromised devices.
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.
Asacub has implemented functions in native code.
Adversaries may use Android’s Native Development Kit (NDK) to write native functions that can achieve execution of binaries or functions. Like system calls on a traditional desktop operating system, native code achieves execution on a lower level than normal Android SDK calls.
The NDK allows developers to write native code in C or C++ that is compiled directly to machine code, avoiding all intermediate languages and steps in compilation that higher level languages, like Java, typically have. The Java Native Interface (JNI) is the component that allows Java functions in the Android app to call functions in a native library.
Adversaries may also choose to use native functions to execute malicious code since native actions are typically much more difficult to analyze than standard, non-native behaviors.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
This is abuse of standard OS-level APIs and are therefore typically undetectable to the end user.
Asacub can request device administrator permissions.
Adversaries may abuse Android’s device administration API to obtain a higher degree of control over the device. By abusing the API, adversaries can perform several nefarious actions, such as resetting the device’s password for Endpoint Denial of Service, factory resetting the device for File Deletion and to delete any traces of the malware, disabling all the device’s cameras, or to make it more difficult to uninstall the app.
Device administrators must be approved by the user at runtime, with a system popup showing which actions have been requested by the app. In conjunction with other techniques, such as Input Injection, an app can programmatically grant itself administrator permissions without any user input.
Use Recent OS Version
Changes were introduced in Android 7 to make abuse of device administrator permissions more difficult.
User Guidance
Users should scrutinize every device administration permission request. If the request is not expected or the user does not recognize the application, the application should be uninstalled immediately.
Users are prompted for approval when an application requests device administrator permissions. Users can see which applications are registered as device administrators in the device settings. Application vetting services can check for the string BIND_DEVICE_ADMIN in the application’s manifest. This indicates it can prompt the user for device administrator permissions.
Asacub has stored encrypted strings in the APK file.
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.
Asacub has implemented functions in native code.
Adversaries may use Android’s Native Development Kit (NDK) to write native functions that can achieve execution of binaries or functions. Like system calls on a traditional desktop operating system, native code achieves execution on a lower level than normal Android SDK calls.
The NDK allows developers to write native code in C or C++ that is compiled directly to machine code, avoiding all intermediate languages and steps in compilation that higher level languages, like Java, typically have. The Java Native Interface (JNI) is the component that allows Java functions in the Android app to call functions in a native library.
Adversaries may also choose to use native functions to execute malicious code since native actions are typically much more difficult to analyze than standard, non-native behaviors.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
This is abuse of standard OS-level APIs and are therefore typically undetectable to the end user.
Asacub can collect various pieces of device network configuration information, such as mobile network operator.
Adversaries may look for details about the network configuration and settings, such as IP and/or MAC addresses, of operating systems they access or through information discovery of remote systems.
On Android, details of onboard network interfaces are accessible to apps through the java.net.NetworkInterface class. Previously, the Android TelephonyManager class could be used to gather telephony-related device identifiers, information such as the IMSI, IMEI, and phone number. However, starting with Android 10, only preloaded, carrier, the default SMS, or device and profile owner applications can access the telephony-related device identifiers.
On iOS, gathering network configuration information is not possible without root access.
Adversaries may use the information from System Network Configuration Discovery during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next.
Use Recent OS Version
Android 10 introduced changes that prevent normal applications from accessing sensitive device identifiers.
Application vetting services could look for usage of the READ_PRIVILEGED_PHONE_STATE Android permission. This could indicate that non-system apps are attempting to access information that they do not have access to.
Asacub can collect various pieces of device information, including device model and OS 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.
Asacub has encrypted C2 communications using Base64-encoded RC4.
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.
Asacub can collect 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.
Asacub can collect SMS messages as they are received.
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.
Asacub has communicated with the C2 using HTTP POST requests.
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.
Asacub can send SMS messages from compromised devices.
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.
Copyright © 2022 AshwinPro