Detections

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.

An app or app update arrives through an expected delivery path or presents as a known legitimate package identity, but its post-install or post-update behavior materially changes in ways inconsistent with its historical role. The defender correlates package identity and install/update context, newly expanded capability state, changed runtime framework use, new sensor or storage behaviors, and new network destinations shortly after installation or update to identify likely supply-chain compromise rather than ordinary malicious sideloading or unrelated post-compromise activity.

A managed or supervised app, app update, or enterprise-distributed build retains a legitimate-seeming identity but exhibits post-delivery behavior inconsistent with its expected role, prior version, or distribution context. Because iOS exposes less direct visibility into bundled dependency tampering or component-level supply-chain insertion, the defender prioritizes supervised app inventory, signing/provisioning trust posture, entitlement and behavior drift after update, new sensor/resource use, and new downstream network effects soon after install or version change.

Network traffic analysis may reveal processes communicating with malicious domains.

Network traffic analysis may reveal processes communicating with malicious domains.

Correlates (1) activation of Device Administrator privileges by an application, (2) absence or mismatch of legitimate user interaction during the approval flow, and (3) immediate execution of administrator-level control actions (e.g., password reset, device lock, policy enforcement, prevention of uninstall). The defender observes a causal chain where an application transitions into a privileged device control role and rapidly exercises those capabilities outside expected user-driven patterns.

Application vetting services can check for the string `BIND_DEVICE_ADMIN` in the application’s manifest.

The defender correlates proxy-capable network setup or socket-handling behavior with subsequent bidirectional traffic relaying through the same device and app context, especially when inbound client sessions are followed by outbound connections to unrelated remote destinations or when the device sustains multiplexed traffic patterns inconsistent with normal mobile app workflows. The analytic prioritizes Android-observable effects: proxy or raw-socket setup, app background execution, inbound-to-outbound traffic bridging, and sustained relayed flows to multiple destinations without recent user interaction.

Application vetting services could look for misuse of dynamic libraries.

Application vetting services could look for misuse of dynamic libraries.

Application vetting services may be able to detect known privilege escalation exploits contained within applications, as well as searching application packages for strings that correlate to known password store locations. Mobile security products can potentially detect jailbroken devices.

Defender observes an app (package/UID) repeatedly retrieving network interface configuration attributes (local IP/MAC/interface names, active network capabilities, link properties, proxy/DNS settings, or carrier identifiers when permitted) in a short time window, without corresponding user network-management activity. The pattern is characterized by OS API execution for interface/config reads combined with background state, permission/role context (e.g., device owner/profile owner/carrier/default-SMS), and optional follow-on connectivity tests (gateway/DNS/proxy reachability). Correlate across API execution + app state + (optional) local probe to identify automated network configuration discovery rather than routine connectivity checks.

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.

OLD: Monitor for API calls that are related to the AccountManager API on Android and Keychain services on iOS. Application vetting services may look for `MANAGE_ACCOUNTS` in an Android application’s manifest. Most applications do not need access to accounts, so extra scrutiny may be applied to those that request it.

NEW: A defender observes an Android application invoking the AccountManager API.

Monitor for API calls that are related to the AccountManager API on Android and Keychain services on iOS. Application vetting services may look for `MANAGE_ACCOUNTS` in an Android application’s manifest. Most applications do not need access to accounts, so extra scrutiny may be applied to those that request it.

Defender observes an app (package/UID) repeatedly querying device networking context APIs (Wi-Fi scan results/current SSID/BSSID, Bluetooth device discovery, or cellular tower lists) at a rate or timing inconsistent with the app’s normal UX, often while backgrounded. Correlate API calls with permission usage (fine location, nearby devices/Bluetooth) and concurrent connectivity probes (DNS lookups/ARP/port reachability) to distinguish automated discovery from user-initiated settings checks. The detection is based on observed API execution + permission use + rate/sequence, not the specific API method name.

The defender correlates foreground service start or promotion activity with persistent-notification presentation, long-lived application execution, and continued access to while-in-use sensors or network activity outside expected user-driven context. The analytic looks for an application invoking foreground service APIs, sustaining a foreground state longer than expected for its declared role, and retaining camera, microphone, location, or other sensor access while the device is locked, the app lacks recent interaction, or the notification identity/function does not match the application’s behavior.

Correlates (1) application access to or staging of local files likely to be of operational, evidentiary, or user value, (2) deletion of those files or wipe-like destructive actions through ordinary storage access, administrative controls, or privileged/rooted paths, and (3) continued app or device activity after deletion, including cleanup, concealment, or outbound transfer. The defender observes a causal chain where files are first accessed or prepared, then removed, and device-side behavior continues after evidence or data is gone.

Defender correlates an Android-specific causal chain where device connectivity degrades or oscillates across one or more radios, applications lose or repeatedly reattempt network access, and the radio or network failure pattern is inconsistent with ordinary mobility, coverage transition, or user-initiated airplane mode behavior. The defender correlates radio state, connectivity framework behavior, application state, network session failures, and location/network-provider degradation to distinguish network denial effects from routine weak-signal conditions.

Defender correlates an iOS-specific reduced-confidence chain where a managed or supervised device remains active but experiences abrupt loss of network-dependent functionality, repeated session failure, or sustained communication inability without matching configuration changes or ordinary user action. Because direct radio-layer and RF-cause visibility is weaker on iOS, the defender emphasizes device posture, application wake or foreground behavior during service loss, protected network-policy stability, and downstream failure patterns observed in VPN or proxy telemetry.

Correlates (1) changes to application visibility or user-facing presence such as launcher component disablement, icon suppression, or reduced discoverability, (2) continued application execution or privileged framework activity after that visibility reduction, and (3) follow-on behavior such as background network communication, sensor access, or persistence-related state transitions. The defender observes a causal chain where an application becomes less visible to the user while retaining or increasing operational activity.

An application performs explicit cryptographic operations (e.g., symmetric/asymmetric encryption routines) on locally collected or generated data, followed by structured outbound network communication that does not align with expected application behavior, particularly when occurring in the background or without user interaction. Detection correlates crypto API usage + data staging + application state + network transmission patterns.

Indirect evidence of application-layer encrypted channel usage inferred through anomalous background processing and network transmission patterns following application activity, where encryption operations are not directly observable. Detection correlates background execution + network behavior + application entitlement posture to identify misuse of encrypted communication channels.

Correlates (1) application interaction with elevation control mechanisms (e.g., Accessibility Service, Device Admin, overlay permissions, package installer flows), (2) rapid transition to elevated capability state without expected user interaction patterns, and (3) immediate privileged actions such as sensor access, UI manipulation, or background persistence. The defender observes a causal chain where an application gains elevated privileges through abuse of system-controlled consent flows and subsequently performs actions inconsistent with normal user-driven authorization.

From the defender view: an app registers a clipboard listener or calls ClipboardManager getters; the app is (a) foreground, (b) the default IME, or (c) abusing legacy paths. Shortly after each clipboard change, the app reads the primary clip repeatedly, optionally persists content (local file/DB) and/or exfiltrates it. We correlate: listener/clip-access → privilege/foreground confirmation → bursty reads → local write and/or network egress within a tight window.

From the defender view: an app accesses UIPasteboard contents, sometimes repeatedly, including in background or immediately after another app copies sensitive text. iOS 14+ shows user notifications when pasting cross-app; unified logs reflect pasteboard access, notification, and optional subsequent persistence/exfil. We correlate: pasteboard access → optional cross-app notification → local write (cache/DB) and/or network egress within a short window.