Detection strategies and analytics from ATT&CK where present.
Results are validated against normalized ATT&CK source records when available; sample records are used only in development or empty-data environments.
Defender observes anomalous authentication or session activity targeting remote device management services followed by device-tracking queries, device-state requests, or remote actions inconsistent with established user-device relationships or operational patterns.
The defender correlates call-control capability or telecom role state with subsequent unauthorized call initiation, answer, block, redirect, or concealment behavior by an application outside expected telephony workflows. The analytic prioritizes Android-observable control-plane effects: dangerous or role-gated call-control permissions, default dialer or ConnectionService-related role changes, telecom framework invocation for call placement or handling, write activity against call-log records, and call-control activity occurring from background or locked-device context without recent user interaction.
A legitimate-seeming application or update is installed through an expected or previously trusted path, but shortly after first run or update the application exhibits new runtime behavior, sensor use, file staging, or network communications inconsistent with its historical baseline, documented role, or prior version. The defender specifically looks for behaviors commonly introduced by compromised third-party libraries or manipulated build tooling, such as unexpected background service activation, first-seen framework use, new permissions exercised, novel network destinations, or dropped local artifacts not aligned to the app's expected function.
A legitimate-seeming app or update arrives through an expected or trusted distribution path, but the delivered application begins showing new entitlement exercise, background activity, framework use, sensor access, or network behavior inconsistent with its prior baseline or documented role. Because direct inspection of compromised dependencies or developer tooling is weaker on iOS, the defender emphasizes supervised-device app inventory, post-update behavior drift, new first-run or background patterns, and downstream communications that suggest compromised embedded libraries or manipulated build outputs.
Defender observes an app gaining input-observation capability (AccessibilityService enablement, default IME set, draw-over-apps permission), then creating an intercept surface (overlay window, accessibility event stream consumption or IME keystroke callbacks), followed by persistence (local keylog/clipboard dump) and/or small, frequent network egress. Chain: capability/permission → listener/overlay activation → bursty input read events → local write → near-term exfil.
Defender observes an app enabling or using input-capture surfaces (custom keyboard extension with Full Access, abnormal UI text entry interception, pasteboard polling adjacent to login screens), then persisting and/or exfiltrating captured input. Chain: capability/consent (TCC for keyboard Full Access or input privacy domains) → intercept behavior (keyboard extension active, repeated text field ‘editingChanged’/secure entry focus, background pasteboard reads) → local write → near-term egress.
The defender correlates app-attributed outbound sessions where protocol indicators such as TLS handshake, HTTP method and header patterns, DNS semantics, or other application-layer characteristics are observed over a destination port outside the approved baseline for that protocol and app role. The strongest Android evidence is repeated or persistent app-attributed traffic using HTTPS-, HTTP-, DNS-, WebSocket-, or other recognizable application behavior over uncommon destination ports, especially when the app is backgrounded, while the device is locked, without recent user interaction, or when the app is unmanaged or not approved for that protocol-to-port pairing.
The defender correlates managed-app or supervised-device outbound sessions where protocol indicators such as TLS handshake, HTTP semantics, or other application-layer behaviors are observed over destination ports outside the approved baseline for that protocol and bundle role. The strongest iOS evidence is network telemetry showing repeated or persistent sessions using recognizable application protocols over uncommon ports, particularly during background refresh, while the device is locked, or without recent user interaction. Because direct local runtime attribution is weaker than Android, the primary iOS analytic should be anchored on network protocol-versus-port mismatch plus supervised managed-app context and device-state enrichment.
The defender correlates creation or registration of deferred, repeating, or constraint-based background work with later task execution in the same app context, especially when the task executes without recent user interaction, from background state, or with follow-on file, sensor, or network behavior inconsistent with the app's declared role. The analytic prioritizes Android-observable control-plane effects: WorkManager enqueue operations, JobScheduler or AlarmManager scheduling, later wake or execution of the scheduled work, and post-trigger activity such as network sessions, local staging, or sensor access.
The defender correlates creation of background scheduler activity with later execution of repeating or deferred work by the same managed app, then raises confidence when the triggered activity produces network, local-write, or other app behavior that occurs outside expected user context. Because iOS exposes weaker direct scheduling observability in many enterprise environments, the analytic anchors first on managed app posture and lifecycle-to-network or lifecycle-to-file effects, with NSBackgroundActivityScheduler-related behavior treated as strongest when runtime telemetry can observe background scheduler usage or execution callbacks.
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.
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.
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.
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.
Mobile security products can use attestation to detect compromised devices.
Mobile security products can use attestation to detect compromised devices.
Correlates (1) application registration or activation of broadcast receivers tied to system or app-generated intents, (2) event-triggered execution while the application is not in the foreground, and (3) immediate follow-on actions such as network communication or data access. The defender observes a causal chain where an external event (e.g., BOOT_COMPLETED, SMS_RECEIVED, USER_PRESENT, CONNECTIVITY_CHANGE) triggers application execution that bypasses normal user-driven lifecycle expectations, followed by background processing or outbound activity.
Application vetting services could detect applications trying to modify files in protected parts of the operating system. Verified Boot can detect unauthorized modifications to the system partition.[1] Android’s SafetyNet API provides remote attestation capabilities, which could potentially be used to identify and respond to compromised devices. Samsung Knox provides a similar remote attestation capability on supported Samsung devices.
Application vetting services could detect applications trying to modify files in protected parts of the operating system. Verified Boot can detect unauthorized modifications to the system partition.[1] Android’s SafetyNet API provides remote attestation capabilities, which could potentially be used to identify and respond to compromised devices. Samsung Knox provides a similar remote attestation capability on supported Samsung devices.
The defender correlates newly granted or recently exercised storage- or privilege-relevant access with burst reads of local files, local databases, or protected records from operating-system or external-storage locations, especially when the reads are inconsistent with app role, occur in background or locked-device context, or are followed by temporary data staging or network transmission. The analytic emphasizes Android-specific observables such as external storage access, app-private database reads where visible to the sensor, and repeated enumeration/read activity against local paths associated with media, tokens, caches, or exported application data.
The defender correlates supervised-device app posture and lifecycle context with repeated local file or local-database access effects, especially when a managed app reads browser, messaging, keychain-adjacent, or application-container data outside its expected role and then stages or uploads the result. Because direct low-level local system access visibility is weaker on iOS, the primary analytic is effect-based: managed app identity, file/database access where visible to the mobile sensor, background execution context, and near-term outbound communication.
Correlates (1) suppression or disablement of launcher-visible application components or effective reduction of user-facing launcher presence, (2) persistence of installed application state after icon suppression, and (3) continued runtime activity such as background execution, framework use, sensor access, or network communication after the icon becomes unavailable or is replaced by reduced-discoverability launcher behavior. The defender observes a causal chain where an app removes or reduces its launcher visibility while remaining operational and continuing meaningful activity.
Unexpected behavior from an application could be an indicator of masquerading. Application vetting services may potentially determine if an application contains suspicious code and/or metadata.
Unexpected behavior from an application could be an indicator of masquerading. Application vetting services may potentially determine if an application contains suspicious code and/or metadata.
The OS may show a notification to the user that the Signal or WhatsApp account has been linked to a new device.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.
