Detections

Defender correlates an app enumerating installed packages (PackageManager queries or shell 'pm list packages') with selective checks for high-value targets (banking/identity/security apps) and near-term persistence/egress of the inventory. Chain: capability to query apps → burst of enumeration calls or shell listing → optional foreground target detection → local inventory file → small POST to remote endpoint.

Defender correlates attempts to inventory installed apps via LaunchServices/URL-scheme probing or private APIs (e.g., LSApplicationWorkspace) with checks for high-value targets and quick persistence/egress. Chain: capability/attempt (URL scheme spray or LSWorkspace calls) → large scheme/app probe set → optional webview hits to brand domains → local inventory cache → small egress.

Defender correlates an app process performing a burst of OS/device attribute lookups (build, hardware, SDK level, system properties) with near-term execution branching (feature gating, module load, permission workflow changes) and/or immediate outbound communications, indicating environment evaluation used to shape follow-on actions.

Defender correlates an app querying device model and iOS version (often limited to UIDevice-visible attributes) with subsequent behavior divergence (capability gating, alternate code paths) and/or near-term outbound connections, suggesting device fingerprinting for decision-making rather than normal telemetry.

OLD: Application vetting services could look for `android.permission.READ_CALL_LOG` in an Android application’s manifest. Most applications do not need call log access, so extra scrutiny could be applied to those that request it. On Android, the user can manage which applications have permission to access the call log through the device settings screen, revoking the permission if necessary.

NEW: A defender observes an Android application requesting for `android.permission.READ_CALL_LOG`, which may also be listed in the application's manifest file.

Application vetting services could look for `android.permission.READ_CALL_LOG` in an Android application’s manifest. Most applications do not need call log access, so extra scrutiny could be applied to those that request it. On Android, the user can manage which applications have permission to access the call log through the device settings screen, revoking the permission if necessary.

Correlates (1) acquisition or presence of elevated control paths capable of forcing a lock state or blocking user interaction, (2) invocation of screen-locking or UI-denial behavior such as DevicePolicyManager lock operations, persistent overlays, accessibility-driven navigation interruption, or foreground lock-screen impersonation, and (3) immediate transition of the device into an unavailable or repeatedly re-locked state while the responsible application remains installed and active. The defender observes a causal chain where an application first gains the ability to control lock-related behavior, then forces or simulates lockout, and the device becomes unusable to the legitimate user.

The defender observes a newly enrolled or recently activated device presenting abnormal integrity, hardware-backed attestation, or firmware/build relationships at the management plane, followed by privileged or system-context access to protected resources or framework paths, and then outbound communication inconsistent with setup state, lock state, or recent user interaction. The causal sequence is strongest when the device has not yet reached a normal trusted posture but still exhibits system-level capability use or network activity.

The defender observes a device at activation, supervision, or enrollment time with unusual management-plane posture, inventory, or trust characteristics and then relies primarily on downstream network effects and device state inconsistencies rather than direct low-level process telemetry. On iOS, the most reliable sequence is supervision/attestation or inventory concern near first contact followed by network egress or protected-state behavior that is inconsistent with lock state, setup phase, or expected managed app activity.

Application vetting services could closely scrutinize applications that request Device Administrator permissions.

The user can view a list of device administrators and applications that have registered Accessibility services in device settings. Applications that register an Accessibility service or request device administrator permissions should be scrutinized further for malicious behavior. Application vetting services can look for applications that request permissions to Accessibility services or application overlay. Monitor for API calls that are related to GooglePlayServices.

The defender correlates app-driven shell-launch behavior with subsequent execution of Unix shell processes or shell-script activity under the same app context, especially when execution occurs from background state, without recent user interaction, or is followed by file-system, privilege-escalation, or network effects inconsistent with the app's declared role. The analytic prioritizes Android-observable control-plane effects: Runtime or ProcessBuilder invocation, spawn of sh/toybox/toolbox/su or equivalent shell process, script-file staging or redirected output, and post-execution network or local artifact creation.

The defender correlates managed-app process-launch or shell-like execution effects with subsequent file or network activity by the same app, then raises confidence when execution occurs in background context, without recent user interaction, or appears tied to command delivery or output exfiltration. Because direct Unix-shell observability is typically weaker on iOS and child processes remain constrained by the app sandbox, the analytic anchors on process-execution effects where available and then on lifecycle, file, and network side effects rather than assuming rich shell-parameter visibility in all environments.

On Android, the user can review which applications can use premium SMS features in the "Special access" page within application settings. Application vetting services can detect when applications request the `SEND_SMS` permission, which should be infrequently used.

On Android, the user can review which applications can use premium SMS features in the "Special access" page within application settings. Application vetting services can detect when applications request the `SEND_SMS` permission, which should be infrequently used.

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 defender correlates repeated or periodic app-attributed retrieval from a legitimate public web-service platform with runtime conditions showing that the retrieval is not aligned to normal foreground consumption, user interaction, or approved app role. The strongest Android evidence is a managed or installed app repeatedly issuing inbound-oriented GET, fetch, sync, or content-pull operations to social, collaboration, paste, code-hosting, cloud-storage, messaging, or generic HTTPS platforms while the app is backgrounded, while the device is locked, or without recent user interaction, and without a corresponding outbound writeback to that same service class during the operational window. The detection is strengthened when the retrieval is temporally adjacent to scheduled/background execution, local state changes, or later downstream effects that do not require the same public platform to receive output.

The defender correlates repeated retrieval-oriented communication from a supervised device or managed iOS app to a legitimate public web-service platform where the activity remains primarily inbound and does not produce corresponding writeback to that same service class during the operational window. The strongest iOS evidence is managed-app or device-attributed communication to collaboration, social, messaging, storage, or generic HTTPS platforms where inbound fetches or content pulls recur during background refresh, while the device is locked, or without recent user interaction, and no matching POST, upload, update, or message-send activity to that same public service class is observed. Because direct local runtime visibility is weaker than Android, the primary analytic is anchored on network directionality plus supervised managed-app and device-state context.

An application is granted or maintains notification listener access, observes notification content from other applications (including sensitive sources such as SMS/email/2FA apps), processes or stores notification payloads, and optionally suppresses or programmatically interacts with notifications (dismiss/action triggers) without corresponding foreground user interaction. Detection correlates special access permission state + notification event interception + application background state + downstream data use (local write or network transmission).

The defender correlates Android accessibility or UI-automation-capable behavior from an app identity with injected user-interface actions occurring on behalf of the user in another foreground application. The strongest Android evidence is accessibility-enabled or similarly privileged app behavior that triggers programmatic clicks, global actions, or text insertion into another app's active UI, especially when those actions occur without matching user touch interaction, while the injecting app is backgrounded or foreground-service-only, or when the target foreground app belongs to a sensitive category such as banking, payments, identity, communications, or enterprise access. The detection is strengthened when the injected input sequence is followed by target-app navigation, form submission, transaction progression, or network activity from the target context.

Monitor for pseudo-randomly generated domain names based on frequency analysis, Markov chains, entropy, proportion of dictionary words, ratio of vowels to other characters, and more.[1] Additionally, check if the suspicious domain has been recently registered, if it has been rarely visited, or if the domain had a spike in activity after being dormant.[2] Content delivery network (CDN) domains may trigger these detections due to the format of their domain names.

Monitor for pseudo-randomly generated domain names based on frequency analysis, Markov chains, entropy, proportion of dictionary words, ratio of vowels to other characters, and more.[1] Additionally, check if the suspicious domain has been recently registered, if it has been rarely visited, or if the domain had a spike in activity after being dormant.[2] Content delivery network (CDN) domains may trigger these detections due to the format of their domain names.

A defender correlates navigation to external web content in a browser or embedded WebView with immediate script-heavy or exploit-preparation network activity, followed by abnormal browser/WebView process behavior, suspicious file or download artifacts, or rapid post-visit capability shifts such as new package install attempts, overlay prompts, permission requests, or outbound command traffic inconsistent with normal browsing.

A defender correlates Safari or embedded web content navigation with short-lived but abnormal web session behavior such as staged redirects, environment fingerprinting, or exploit-preparation fetches, followed by browser/WebView instability, unusual file handling, profile/download prompts, or near-term changes in device or application behavior inconsistent with normal browsing.