Correlates (1) an application obtaining or maintaining elevated control mechanisms capable of resisting removal (device administrator, accessibility control, managed-owner posture), (2) user navigation into uninstall or application-management flows, and (3) immediate UI redirection, back-navigation injection, modal dismissal, or failed uninstall completion followed by continued app presence. Defender observes a causal chain where a removal attempt is actively disrupted and the target application remains installed.

The defender correlates SMS-relevant permission state or default SMS handler role with subsequent unauthorized SMS send, receive interception, message database modification, deletion, or concealment behavior by an application outside expected messaging workflows. The analytic prioritizes Android-observable control-plane effects: SENDSMS or RECEIVESMS capability, default SMS handler change or exercise of SMS_DELIVER semantics, direct interaction with the SMS content provider or messaging database, and SMS activity occurring from background or locked-device state without recent user interaction.

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.

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.

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.

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.

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.

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.

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.

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.

References:

1. Android Developers. (2024, September 24). Webviews – Unsafe URI Loading. Retrieved March 2, 2026.
2. W. Denniss and J. Bradley. (2017, October). IETF RFC 8252: OAuth 2.0 for Native Apps. Retrieved November 30, 2018.
3. Android. (n.d.). Handling App Links. Retrieved December 21, 2016.

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]

References:

1. W. Denniss and J. Bradley. (2017, October). IETF RFC 8252: OAuth 2.0 for Native Apps. Retrieved November 30, 2018.
2. SecureAuth. (2025). Build an iOS App Using OAuth 2.0 and PKCE. Retrieved March 2, 2026.

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.

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.

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.

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.

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.

From the defender view: a sandboxed process receives/creates a high-entropy Mach-O/bundle or encrypted segment, performs in-memory decrypt/unpack (mmap/mprotect RW→RX or RWX), optionally drops a transient image in app-writable dirs, then loads it through dyld/dlopen or spawns it. We correlate: (1) opaque blob write/arrival → (2) kernel memory protection changes → (3) dyld/dlopen from app-writable path or posix_spawn of a recently created image → (4) (optional) code-sign evaluation anomalies for the new image.

From the defender view: a sandboxed app handles a high-entropy executable blob, performs rapid decode/decrypt in memory (often with RW→RX or execmem friction), optionally emits a transient .dex/.so into app-writable paths, then immediately loads/executes it (DexClassLoader/dlopen) or spawns a helper. We correlate: (1) opaque blob write/arrival → (2) decode/unpack or memory protection change → (3) new code artifact or byte[] class definition → (4) dynamic load/exec within a tight window.

A lock-state transition telemetry, special access or privileged interaction capability, security-sensitive framework use, and immediate downstream activity while the user-interaction context is weak or inconsistent. This yields stronger coverage on Android than iOS.

Defender correlates an iOS-specific reduced-confidence chain where a supervised or managed device transitions from locked or inactive state to interactive or application-active state with weak evidence of expected user authentication, often accompanied by abnormal protected posture change, trust-state change, unexpected app wake, sensor use, or immediate downstream communication. Because direct visibility into lockscreen bypass mechanics on iOS is limited, the analytic prioritizes strong device-state effects and post-unlock behavior rather than pretending to observe the exact bypass method.

The defender correlates application TLS trust customization activity with subsequent outbound encrypted sessions that bypass enterprise interception visibility or fail only under enterprise inspection conditions. The analytic looks for an app establishing its own certificate or public-key trust logic, then initiating HTTPS sessions to destinations not aligned with approved app behavior, especially from background state or without recent user interaction. Higher-confidence observations come from Android runtime/framework telemetry showing custom trust manager, certificate validation override, or pin validation logic immediately preceding network connection attempts, combined with network evidence of failed-inspection patterns or opaque direct TLS sessions.

The defender correlates supervised-device application posture and background execution context with network-side evidence that an app rejects enterprise inspection or performs certificate/public-key-bound trust behavior during TLS establishment. Because direct app-level pin-validation observability is weaker on iOS, the analytic is anchored primarily to network control-plane effects: repeated TLS handshake rejection under enterprise inspection, destination-specific inspection bypass patterns, or persistent opaque app-to-endpoint encrypted sessions inconsistent with baseline app behavior. Additional confidence comes from managed app identity, background execution context, and supervised device policy state.

The defender correlates application registration for system event triggers (e.g., broadcast receivers, WorkManager, JobScheduler, SMS/BOOT events) with subsequent execution of application code immediately following the triggering event, without direct user interaction. Confidence increases when execution occurs in background or locked state, is tied to sensitive triggers (SMS received, boot completed, connectivity change), and produces follow-on file or network activity inconsistent with the application’s expected role.

Correlates (1) acquisition of foreground or background location permission sufficient for continuous geolocation evaluation, (2) repeated location checks or registration of geofence monitoring in background or low-interaction states, and (3) transition into sensitive behavior only after the device enters, exits, or remains within a qualifying geographic region. The defender observes a causal chain where an application suppresses malicious or higher-risk behavior until a location-derived condition is satisfied, then initiates follow-on actions such as network communication, background processing, or protected resource access.

Correlates (1) application possession and use of location authorization sufficient for ongoing geographic evaluation, (2) repeated location or region-monitoring behavior with limited visible feature activation outside target area, and (3) abrupt onset of network communication, background execution, or feature activation only after a qualifying location context is reached. Because direct visibility into every geofence callback is often weaker on iOS, the defender relies more heavily on the combination of location authorization state, repeated location access, app state transition, and downstream behavior that begins after region alignment.

The defender correlates anomalous application package replacement, update, or executable-content drift with subsequent execution under the trusted application's identity, especially when package metadata, signing lineage, install source, file integrity, or native/DEX component characteristics change without a corresponding trusted distribution path. The analytic prioritizes Android-observable control-plane effects: package install/update events, package hash or code-section drift, signer mismatch or lineage break, unexpected app process behavior after replacement, and optional near-term network or sensor activity inconsistent with the legitimate application's baseline.

An application performs repeated symmetric cryptographic operations (e.g., AES/RC4) on collected or staged data using locally accessible or reusable keys, followed by structured outbound communication. Detection correlates symmetric crypto API invocation + key reuse patterns + data staging + background execution context + network transmission, especially when inconsistent with expected application functionality.

Indirect evidence of symmetric cryptographic channel usage inferred through repeated structured encrypted network transmissions and background processing patterns, where direct observation of symmetric crypto operations is limited. Detection correlates application background execution + consistent encrypted payload patterns + app entitlement posture to identify misuse of symmetric encryption for command and control.

Detects indirect evidence of host-side indicator removal by correlating (1) local artifact creation or compromise-state-relevant activity, (2) later disappearance, alteration, or reporting loss for those artifacts or state indicators, and (3) continued application or device activity under reduced visibility. Because iOS provides weaker direct visibility into some Android-style artifact and jailbreak-indicator manipulation patterns, the defender relies more on app-private artifact lifecycle changes, managed posture shifts, and continued runtime or network activity after expected evidence disappears.

Correlates (1) application activity that creates, modifies, or accesses local artifacts relevant to detection or device compromise state, (2) subsequent deletion, alteration, renaming, relocation, or visibility suppression of those artifacts, including files, application presence, media, or root-compromise indicators, and (3) continued application execution, reduced telemetry quality, or outbound activity after the artifact state changes. The defender observes a causal chain where host-side evidence is first manipulated and expected visibility or reporting degrades while the initiating application remains active.

Correlates (1) application access to device- or environment-specific attributes used to validate target conditions, (2) suppression of sensitive behavior until those attributes match an expected value, and (3) immediate transition into protected actions such as sensor use, file access, or network communication only after the condition is satisfied. The defender observes a causal chain where an app repeatedly evaluates device state or environment context and withholds execution until a target-specific match occurs.

Detects conditional execution by correlating (1) application access to constrained environment signals such as location, locale, network context, device state, or user interaction timing, (2) prolonged inactivity or feature suppression despite available permissions, and (3) abrupt initiation of higher-risk behavior only when the expected target context is present. Because direct observation of some runtime decision logic is weaker on iOS, the defender relies more heavily on lifecycle, sensor, and downstream network effects following target-condition alignment.

Correlates anomalous modifications to boot-time or logon-time initialization artifacts (for example, init.rc, vendor init scripts, appprocess or shell hijacks, and malicious BOOTCOMPLETED BroadcastReceivers) with subsequent unauthorized script execution after boot. From the defender’s perspective this appears as integrity or attestation failures on the system partition, unexpected writes to protected init paths, new apps registering for boot events, and privileged processes invoking scripts or binaries from non-standard locations shortly after the device boots.

Correlates unauthorized alterations to launchd configuration (LaunchDaemons/LaunchAgents plists), background execution entitlements, or sideloaded app containers with suspicious auto-start behavior during device boot or user unlock. From the defender’s view this shows up as new or modified plist files in launchd directories, launchd starting binaries from non-Apple or non-AppStore locations, and apps with unexpected background modes that remain active immediately after boot/unlock.

The defender correlates app-driven shell or command execution setup with subsequent process creation, command invocation, or script-driven follow-on behavior under the same app context, especially when command execution occurs from background state, without recent user interaction, or immediately after payload retrieval or local staging. The analytic prioritizes Android-observable control-plane effects: Java Runtime or similar command-execution method use, shell or sh-like process creation, command parameter visibility where available, and immediate file or network effects produced by the interpreter.

The defender correlates managed-app runtime behavior indicative of command or shell invocation with subsequent spawned process or shell-like execution effects, then raises confidence when the resulting activity produces local artifacts or network communication outside expected user context. Because direct shell-process visibility can be weaker on iOS in many enterprise deployments, the analytic anchors first on process-creation or lower-level OS API effects where mobile telemetry can observe them, then on lifecycle context and post-execution network or file behavior. Confidence is strongest when the same app shows command invocation followed by process execution and immediate follow-on effects.

Defender observes an OAuth/OIDC redirect (ACTIONVIEW) resolved to a non-allowlisted handler package (logcat:IntentResolver), followed within a short window by that same package accessing token material via AccountManager/Keystore or reading application token caches under /data/data//(sharedprefs|databases) (logcat:AccountManager, logcat:Keystore, logcat:FileIO). Correlate on package/UID/profile and time proximity to indicate token acquisition.

A defender correlates a sudden carrier identity/service state change (SIM/line identifier change or unexpected loss of cellular service) with near-term device messaging/telephony disruption and a concurrent shift in authentication traffic patterns—such as a spike in SMS-based verification flows or account recovery activity from the same user’s identities—indicating the user’s number may have been transferred to a different SIM/device (SIM swap impact).

A defender correlates an unexpected change in cellular subscription state (eSIM/SIM profile change, carrier/operator change, or sudden persistent loss of cellular service) with near-term disruption signals and a rapid increase in authentication-related network activity consistent with SMS verification or account recovery flows, suggesting the user’s number has been ported to an adversary-controlled SIM/device (SIM swap impact).

Defender correlates an app acquiring input-capture capability (AccessibilityService enablement or default IME set) with high-frequency text-change/IME commit callbacks sourced from other packages, followed by local keylog persistence and/or small, immediate network egress. Chain: capability/permission → intercept (accessibility ‘TYPEVIEWTEXT_CHANGED’ or IME commitText/onStartInput bursts) → persist to container → near-term egress.

Defender correlates a custom keyboard extension activation (optionally with TCC ‘Full Access’) or abnormal UI text-entry interception with local keylog persistence and/or small egress. Chain: capability/consent (keyboard Full Access/TCC) → intercept (keyboard commit events or repeated secure text entry edits) → persist to container → near-term egress.

Defender observes anomalous signaling network queries targeting subscriber information associated with a device, including unexpected routing requests, location information exchanges, or node-origin inconsistencies indicative of SS7 signaling abuse. ^[1] The CSRIC also suggests threat information sharing between telecommunications industry members.

References:

1. Communications Security, Reliability, Interoperability Council (CSRIC). (2017, March). Working Group 10 Legacy Systems Risk Reductions Final Report. Retrieved May 24, 2017.

Defender observes anomalous signaling interactions involving subscriber identity or location resolution events associated with a device, including abnormal routing requests, unexpected location information exchanges, or signaling node inconsistencies indicative of SS7 abuse. ^[1] The CSRIC also suggests threat information sharing between telecommunications industry members.

References:

1. Communications Security, Reliability, Interoperability Council (CSRIC). (2017, March). Working Group 10 Legacy Systems Risk Reductions Final Report. Retrieved May 24, 2017.

Defender observes a mobile device initiating abnormal or exploit-like network interactions with internal or remote services, followed by process-level instability, privilege boundary shifts, or unexpected execution behaviors indicative of service exploitation outcomes.

Defender observes a mobile device engaging remote or internal services with traffic characteristics inconsistent with normal application behavior, followed by execution anomalies, application instability, or security context deviations consistent with exploitation effects.

From the defender’s perspective, this strategy correlates signals that a previously unprivileged Android app or process has gained higher privileges through exploitation rather than normal OS or MDM flows. Observable behaviors include: (1) unprivileged app processes issuing sensitive syscalls or accessing privileged device interfaces, (2) bursts of SELinux denials followed by an unexpected domain or permission change, (3) creation of new processes running with system or root UID whose lineage traces back to an app sandbox path, and (4) crashes or abnormal restarts of privileged system services followed shortly by a new connection or binder interaction from the same low-privileged app. The focus is on unusual privilege transitions, anomalous process ancestry, and OS security policy violations, not on specific exploit binaries or CVE signatures.

Correlates app sandbox escape attempts via unsigned binary execution, mmap memory permission changes (RWX), and sandbox profile violations. Detection chain includes app leveraging JIT/JSC to execute shellcode or triggering kernel exploit via crafted IOKit or Mach port abuse.

An application generates, imports, or accesses asymmetric keypairs (e.g., RSA/ECC), uses a public key to encrypt outbound data or establish encrypted sessions, and transmits resulting ciphertext in structured communication patterns. Detection correlates keypair lifecycle activity + asymmetric crypto API usage + data transformation + background execution context + network transmission, especially when inconsistent with expected application functionality.

Indirect evidence of asymmetric cryptographic channel usage inferred through key exchange-like network patterns and application background execution behavior, where direct observation of keypair operations is limited. Detection correlates app entitlement posture + background execution + asymmetric handshake patterns + subsequent encrypted communication.

The defender correlates Android screen-capture-capable behavior from an app identity with runtime context showing that foreground content from another app is being captured outside expected user-driven workflows. The strongest Android evidence is MediaProjection-like capture initiation, accessibility-assisted observation of foreground UI content, or privileged screencap or screenrecord behavior, followed by screenshot or video artifact creation, buffer growth, or outbound transfer. The detection is strengthened when the capturing app is backgrounded, operates as a foreground service without clear user-driven recording intent, captures while another sensitive app is foregrounded, runs with accessibility or elevated access inconsistent with its role, or performs capture without recent user interaction.

The defender correlates recent access to locally collected or protected data with subsequent compression, packaging, or encryption behavior inside the same app context, followed by creation of archive-like or high-entropy output and optional near-term network transmission. The analytic prioritizes Android runtime and storage effects: application data access or sensor-derived collection, compression/encryption framework use, archive/blob creation in app-accessible storage, and background or device-locked execution inconsistent with the app’s declared function.

The defender correlates managed-app data access and lifecycle context with indirect evidence of packaging or encryption prior to outbound transfer. Because direct archive/compression visibility is generally weaker on iOS, the analytic anchors on app lifecycle state, file/output effects observable by mobile EDR where available, managed app role via MDM, and downstream network uploads that closely follow creation of new large or high-entropy local artifacts. Confidence is lower when only network effects are available.

The defender correlates outbound communication from an application or service to legitimate external web platforms with mobile runtime context showing that the communication is inconsistent with the app's approved role, expected destinations, user interaction pattern, or device state. The strongest Android evidence is a managed or installed app communicating with cloud storage, social, messaging, code-hosting, or generic HTTPS web-service infrastructure shortly after background activation, protected-resource use, or local staging activity, especially when the device is locked, user interaction is absent, or the app's historical network baseline does not include that service class.

The defender correlates communication to legitimate external web-service platforms with supervised managed-app context and device-state information showing that the traffic is inconsistent with the app's expected role, background-refresh profile, or user interaction timing. On iOS, the strongest reliable evidence is network telemetry tied to a managed app or device plus app state and supervision context, especially when traffic to social, collaboration, cloud-storage, or generic HTTPS platforms occurs shortly after background activity, while the device is locked, or without expected user-driven foreground execution. Direct low-level framework visibility is weaker than Android, so primary analytic confidence should be anchored to supervised app context plus network behavior rather than assumed host-level proof.

A defender observes an application holding microphone capture capability transitioning into active microphone resource usage through Android audio APIs (e.g., MediaRecorder or AudioRecord), followed by sustained capture while the application is backgrounded or the device is locked, and subsequent outbound network traffic suggesting potential audio exfiltration or streaming.

A defender observes an application with declared microphone capability initiating microphone resource use through iOS audio frameworks, potentially during background execution or shortly after a silent wake event, followed by sustained audio capture and outbound encrypted traffic suggesting audio streaming or upload activity.

OLD: Application vetting services could look for android.permission.READ_CALENDAR or android.permission.WRITE_CALENDAR in an Android application’s manifest, or NSCalendarsUsageDescription in an iOS application’s Info.plist file. Most applications do not need calendar access, so extra scrutiny could be applied to those that request it. On both Android and iOS, the user can manage which applications have permission to access calendar information through the device settings screen, revoke the permission if necessary.

NEW: A defender observes an Android application requesting for android.permission.READ_CALENDAR or android.permission.WRITE_CALENDAR, which may also be listed in the application’s Manifest.

Defender correlates an application gaining/retaining fine or background location capability with subsequent location sensor sessions that occur while the app is backgrounded or the device is locked, followed by repeated location reads at a periodic cadence and near-term outbound connections to domains not typical for fleet navigation/MDM services, indicating covert location tracking.