Center for Threat-Informed Defense

Version 14.1 15.0

Techniques : Mobile ATT&CK Changelog

Added Techniques

Description

Adversaries may check for Internet connectivity on compromised systems. This may be performed during automated discovery and can be accomplished in numerous ways such as using adb shell netstat for Android.[1]

Adversaries may use the results and responses from these requests to determine if the mobile devices are capable of communicating with adversary-owned C2 servers before attempting to connect to them. The results may also be used to identify routes, redirectors, and proxy servers.

References:

  1. Pulimet. (2017, September 11). AdbCommands. Retrieved December 14, 2023.

Description

Adversaries may search for information about Wi-Fi networks, such as network names and passwords, on compromised systems. Adversaries may use Wi-Fi information as part of Discovery or Credential Access activity to support both ongoing and future campaigns.

Description

Adversaries may use SSL Pinning to protect the C2 traffic from being intercepted and analyzed.

SSL Pinning is a technique commonly utilized by legitimate websites to ensure that encrypted communications are only allowed with a pre-defined certificate. If another certificate is presented, it could indicate device compromise, traffic interception, or another upstream issue. While benign usages are common, it is also possible for adversaries to abuse this technology to protect malicious C2 traffic.

In normal, not pinned SSL validation, when a client connects to a server using HTTPS, it typically checks whether the server’s SSL/TLS certificate is signed by a trusted Certificate Authority (CA) in the device’s trust store. If the certificate is valid and signed by a trusted CA, the connection is established. However, with SSL Pinning , the client is configured to trust a specific SSL/TLS certificate or public key, rather than relying on the device’s trust store. This means that even if the server’s certificate is signed by a trusted CA, the client will only establish the connection of the certificate or key is pinned.

There are two types of SSL Pinning :

  1. Certificate Pinning: The client stores a copy of the server’s certificate and compares it with the certificate received during the SSL handshake. If the certificates match, then the client proceeds with the connection. This approach also works with self-signed certificates.

  2. Public Key Pinning: Instead of pinning the entire certificate, the client pins just the public key extracted from the certificate. This is often more flexible, as it allows the server to renew its certificate without having to update the pinned certificate or breaking the SSL connection.

Description

Adversaries may attempt to hide multimedia files from the user. By doing so, adversaries may conceal captured files, such as pictures, videos and/or screenshots, then later exfiltrate those files.

Specific to Android devices, if the .nomedia file is present in a folder, multimedia files in that folder will not be visible to the user in the Gallery application. Additionally, other applications are asked not to scan the folder with the .nomedia file, effectively making the folder appear invisible to the user.

This technique is often used by stalkerware and spyware applications.

Description

Adversaries may exploit software vulnerabilities to gain initial access to a mobile device.

This can be accomplished in a variety of ways. Vulnerabilities may be present in applications, services, the underlying operating system, or in the kernel itself. Several well-known mobile device exploits exist, including FORCEDENTRY, StageFright, and BlueBorne. Further, some exploits may be possible to exploit without any user interaction (zero-click), making them particularly dangerous. Mobile operating system vendors are typically very quick to patch such critical bugs, ensuring only a small window where they can be exploited.

Modified Techniques

Modified Description View changes side-by-side
Adversaries may look for details about the network configuration and settings, such as IP and/or MAC addresses, of operating systems devices they access or through information discovery of remote systems. Adversaries may use the information from [System Network Configuration Discovery](https://attack.mitre.org/techniques/T1422) during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next. On Android, details of onboard network interfaces are accessible to apps through the `java.net.NetworkInterface` class.(Citation: NetworkInterface) 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.(Citation: TelephonyManager) On iOS, gathering network configuration information is not possible without root access. Adversaries may use the information from [System Network Configuration Discovery](https://attack.mitre.org/techniques/T1422) during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next.
Details
Values Changed
FIELD OLD VALUE NEW VALUE
modified 2023-03-20 18:50:32.697000+00:00 2024-02-20 23:35:22.949000+00:00
description 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.(Citation: NetworkInterface) 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.(Citation: TelephonyManager) On iOS, gathering network configuration information is not possible without root access. Adversaries may use the information from [System Network Configuration Discovery](https://attack.mitre.org/techniques/T1422) during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next. Adversaries may look for details about the network configuration and settings, such as IP and/or MAC addresses, of devices they access or through information discovery of remote systems. Adversaries may use the information from [System Network Configuration Discovery](https://attack.mitre.org/techniques/T1422) during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next. On Android, details of onboard network interfaces are accessible to apps through the `java.net.NetworkInterface` class.(Citation: NetworkInterface) 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.(Citation: TelephonyManager) On iOS, gathering network configuration information is not possible without root access. Adversaries may use the information from [System Network Configuration Discovery](https://attack.mitre.org/techniques/T1422) during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next.
x_mitre_attack_spec_version 3.1.0 3.2.0
x_mitre_version 2.3 2.4

Description

Adversaries can steal user application access tokens as a means of acquiring credentials to access remote systems and resources. This can occur through social engineering or URI hijacking and typically requires user action to grant access, such as through a system “Open With” dialogue.

Application access tokens are used to make authorized API requests on behalf of a user and are commonly used as a way to access resources in cloud-based applications and software-as-a-service (SaaS).[1] OAuth is one commonly implemented framework used to issue tokens to users for access to systems. An application desiring access to cloud-based services or protected APIs can gain entry through OAuth 2.0 using a variety of authorization protocols. An example of a commonly-used sequence is Microsoft's Authorization Code Grant flow.[2][3] An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested without requiring user credentials.

References:

  1. Auth0. (n.d.). Why You Should Always Use Access Tokens to Secure APIs. Retrieved September 12, 2019.
  2. Microsoft. (n.d.). Retrieved September 12, 2019.
  3. Microsoft. (n.d.). Microsoft identity platform and OAuth 2.0 authorization code flow. Retrieved September 12, 2019.
Details
Values Changed
FIELD OLD VALUE NEW VALUE
modified 2023-03-20 18:53:52.292000+00:00 2023-12-26 19:17:13.294000+00:00
x_mitre_attack_spec_version 3.1.0 3.2.0
x_mitre_version 1.1 1.2

Modified Description View changes side-by-side
Adversaries may attempt to position themselves between two or more networked devices to support follow-on behaviors such as [Transmitted Data Manipulation](https://attack.mitre.org/techniques/T1565/002) or [Endpoint Denial of Service](https://attack.mitre.org/techniques/T1642). [Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1638) can be achieved through several mechanisms, such as mechanisms. For example, a malicious application registering may register itself as a VPN client. By doing this, the adversary can client, effectively redirect redirecting device traffic to wherever they want. However, registering adversary-owned resources. Registering as a VPN client requires user consent on both Android and iOS. Additionally, on iOS, the application requires iOS; additionally, a special entitlement that must be granted by Apple. Apple is needed for iOS devices. Alternatively, if an a malicious application is able to escalate privileges, it can potentially with escalation privileges may utilize those privileges to gain access to network traffic. Specific to Android devices, adversary-in-the-disk is a type of AiTM attack where adversaries monitor and manipulate data that is exchanged between applications and external storage.(Citation: mitd_kaspersky)(Citation: mitd_checkpoint)(Citation: mitd_checkpoint_research) To accomplish this, a malicious application firsts requests for access to multimedia files on the device (`READ_EXTERNAL STORAGE` and `WRITE_EXTERNAL_STORAGE`), then the application reads data on the device and/or writes malware to the device. Though the request for access is common, when used maliciously, adversaries may access files and other sensitive data due to abusing the permission. Multiple applications were shown to be vulnerable against this attack; however, scrutiny of permissions and input validations may mitigate this attack. Outside of a mobile device, adversaries may be able to capture traffic by employing a rogue base station or Wi-Fi access point. These devices will allow adversaries to capture network traffic after it has left the device, while it is flowing to its destination. On a local network, enterprise techniques could be used, such as DNS redirection [ARP Cache Poisoning](https://attack.mitre.org/techniques/T1557/002) or DNS poisoning. [DHCP Spoofing](https://attack.mitre.org/techniques/T1557/003). If applications properly encrypt their network traffic, sensitive data may not be accessible an adversary, to adversaries, depending on the point of capture. For example, properly implementing Apple’s Application Transport Security (ATS) and Android’s Network Security Configuration (NSC) may prevent sensitive data leaks.(Citation: NSC_Android)
Details
Values Changed
FIELD OLD VALUE NEW VALUE
modified 2023-03-15 16:39:32.207000+00:00 2024-02-07 18:10:46.887000+00:00
description Adversaries may attempt to position themselves between two or more networked devices to support follow-on behaviors such as [Transmitted Data Manipulation](https://attack.mitre.org/techniques/T1565/002) or [Endpoint Denial of Service](https://attack.mitre.org/techniques/T1642). [Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1638) can be achieved through several mechanisms, such as a malicious application registering itself as a VPN client. By doing this, the adversary can effectively redirect device traffic to wherever they want. However, registering as a VPN client requires user consent on both Android and iOS. Additionally, on iOS, the application requires a special entitlement that must be granted by Apple. Alternatively, if an application is able to escalate privileges, it can potentially utilize those privileges to gain access to network traffic. Outside of a mobile device, adversaries may be able to capture traffic by employing a rogue base station or Wi-Fi access point. These devices will allow adversaries to capture network traffic after it has left the device, while it is flowing to its destination. On a local network, enterprise techniques could be used, such as DNS redirection or DNS poisoning. If applications properly encrypt their network traffic, sensitive data may not be accessible an adversary, depending on the point of capture. Adversaries may attempt to position themselves between two or more networked devices to support follow-on behaviors such as [Transmitted Data Manipulation](https://attack.mitre.org/techniques/T1565/002) or [Endpoint Denial of Service](https://attack.mitre.org/techniques/T1642). [Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1638) can be achieved through several mechanisms. For example, a malicious application may register itself as a VPN client, effectively redirecting device traffic to adversary-owned resources. Registering as a VPN client requires user consent on both Android and iOS; additionally, a special entitlement granted by Apple is needed for iOS devices. Alternatively, a malicious application with escalation privileges may utilize those privileges to gain access to network traffic. Specific to Android devices, adversary-in-the-disk is a type of AiTM attack where adversaries monitor and manipulate data that is exchanged between applications and external storage.(Citation: mitd_kaspersky)(Citation: mitd_checkpoint)(Citation: mitd_checkpoint_research) To accomplish this, a malicious application firsts requests for access to multimedia files on the device (`READ_EXTERNAL STORAGE` and `WRITE_EXTERNAL_STORAGE`), then the application reads data on the device and/or writes malware to the device. Though the request for access is common, when used maliciously, adversaries may access files and other sensitive data due to abusing the permission. Multiple applications were shown to be vulnerable against this attack; however, scrutiny of permissions and input validations may mitigate this attack. Outside of a mobile device, adversaries may be able to capture traffic by employing a rogue base station or Wi-Fi access point. These devices will allow adversaries to capture network traffic after it has left the device, while it is flowing to its destination. On a local network, enterprise techniques could be used, such as [ARP Cache Poisoning](https://attack.mitre.org/techniques/T1557/002) or [DHCP Spoofing](https://attack.mitre.org/techniques/T1557/003). If applications properly encrypt their network traffic, sensitive data may not be accessible to adversaries, depending on the point of capture. For example, properly implementing Apple’s Application Transport Security (ATS) and Android’s Network Security Configuration (NSC) may prevent sensitive data leaks.(Citation: NSC_Android)
x_mitre_attack_spec_version 3.1.0 3.2.0
x_mitre_version 2.1 2.2
Iterable Item Added
FIELD OLD VALUE NEW VALUE
external_references {'source_name': 'mitd_checkpoint', 'description': 'Check Point Research Team. (2018, August 12). Man-in-the-Disk: A New Attack Surface for Android Apps. Retrieved October 31, 2023.', 'url': 'https://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/'}
external_references {'source_name': 'mitd_kaspersky', 'description': 'Drozhzhin, A. (2018, August 27). Man-in-the-Disk: A new and dangerous way to hack Android. Retrieved October 31, 2023.', 'url': 'https://usa.kaspersky.com/blog/man-in-the-disk/16089/'}
external_references {'source_name': 'NSC_Android', 'description': 'Lee, A., Ramirez, T. (2018, August 15). A Security Analyst’s Guide to Network Security Configuration in Android P . Retrieved February 7, 2024.', 'url': 'https://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/'}
external_references {'source_name': 'mitd_checkpoint_research', 'description': 'Makkaveev, S. (2018, August 12). Man-in-the-Disk: Android Apps Exposed via External Storage. Retrieved October 31, 2023.', 'url': 'https://research.checkpoint.com/androids-man-in-the-disk/'}