Detections

Exfiltration Over C2 Channel can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.

Exfiltration Over C2 Channel can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.

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.

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.

The defender correlates an app-attributed request to a legitimate public web platform with a subsequent outbound connection to a newly derived or previously unseen destination within a short time window. The behavior is strengthened when the initial request retrieves structured or encoded content followed by a pivot to a different domain or IP that was not previously contacted by the app, especially when occurring without user interaction, in background state, or immediately after app initialization or scheduled execution. This sequence reflects resolver retrieval followed by dynamic C2 resolution.

The defender correlates a supervised-device or managed-app request to a legitimate web platform with a subsequent connection to a newly derived destination that is not part of the expected service interaction. Because iOS has weaker app-level telemetry, the strongest signal is a network-level sequence where a request to a known public platform is immediately followed by a connection to a different domain or IP, particularly when the device is locked, no recent user interaction occurred, and the bundle is not expected to interact with such downstream infrastructure.

From the defender’s view: an app retrieves opaque code (DEX/SO/JAR/JS) over the network or IPC, writes it into an app-writable path, optionally performs verification-bypass behaviors (reflection, addJavascriptInterface exposure, or execmem friction), and then loads/executes that code via DexClassLoader/PathClassLoader, dlopen, or WebView bridge invocation within a short window. The analytic correlates Network Content → File Creation/Modification → OS API Execution (loader/syscall/SELinux friction) → Module Load (DexClassLoader/dlopen) and, for WebView paths, Application Log signals of JavaScript interface attachment.

From the defender’s view: a sandboxed app retrieves code-like content (JS/Mach-O/bundles), writes it to container tmp/Caches, performs memory permission changes (RW→RX/RWX) or directly loads via dyld/dlopen from writable paths, sometimes preceded by 3rd-party hotpatch frameworks (e.g., JSPatch-like behavior) or script engine evaluation. The analytic correlates Network Content → File Creation → OS API Execution (memory permission change) → Module Load (dyld/dlopen) and/or Process Access (codesign validation touches), with optional scripting engine events.

On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.

On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.

On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.

On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.

Defender observes an application establishing recurrent HTTPS or FCM-based communication sessions exhibiting structured cadence, asymmetric request/response sizes, or persistent low-volume polling inconsistent with declared application functionality, potentially embedding command data within web protocol traffic.

Defender observes an application establishing recurrent HTTPS or APNS-related communications exhibiting structured cadence, abnormal session persistence, or notification-triggered network bursts inconsistent with user interaction patterns or declared application behavior.

Defender correlates an app escalating file visibility (permissions/flags, legacy storage modes) with enumeration of other apps’ storage or exported ContentProviders, followed by bulk reads/copies from target paths (including shared/external storage) and optional archive/encode then share/upload. Sequence: storage capability/permission gain → target discovery (provider queries, directory listing) → high-volume cross-app data reads from writable/shared paths → archive/encode → exfil/share within a short window.

Defender correlates attempts to access other apps’ data via shared containers (App Groups), Photos/Files providers, pasteboard abuse, or jailbroken cross-container reads, followed by aggregation/packaging and optional exfil/share. Sequence: capability/consent (TCC/entitlements) → target discovery (AppGroup/Photos/Files enumeration, URL schemes) → bulk read from shared/foreign container or provider → package/encode → exfil/share.

Application vetting services could look for misuse of dynamic libraries.

Application vetting services could look for misuse of dynamic libraries.

Mobile security products can potentially detect rogue Wi-Fi access points if the adversary is attempting to decrypt traffic using an untrusted SSL certificate. Application vetting services should look for applications that request VPN access. These applications should be heavily scrutinized since VPN functionality is not very common. On both Android and iOS, the user must grant consent to an application to act as a VPN. Both platforms also provide visual context to the user in the top status bar when a VPN connection is active. The user can see registered VPN services in the device settings.

Mobile security products can potentially detect rogue Wi-Fi access points if the adversary is attempting to decrypt traffic using an untrusted SSL certificate. Application vetting services should look for applications that request VPN access. These applications should be heavily scrutinized since VPN functionality is not very common. On both Android and iOS, the user must grant consent to an application to act as a VPN. Both platforms also provide visual context to the user in the top status bar when a VPN connection is active. The user can see registered VPN services in the device settings.

Remote access software typically requires many privileged permissions, such as accessibility services or device administrator.

Remote access software typically requires many privileged permissions, such as accessibility services or device administrator.

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.

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.

When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents. Defenders should validate the entirety of the URI. For example, the URI's scheme should be `https` and the URI's host should be on a list of trusted hosts.[1]

Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice.[2][3]

On Android, users may be presented with a popup to select the appropriate application to open the URI in. If the user sees an application they do not recognize, they can remove it.

When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents.

Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice.[1][2]

On Android, the user can review which applications have Device Administrator access in the device settings and revoke permission where appropriate. Application vetting services can detect and closely scrutinize applications that utilize Device Administrator access.