Detections

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.

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.

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.

Defender correlates an application’s location authorization level (When-In-Use vs Always) and entitlement posture with observed location sensor activity that occurs without proximate user interaction, including background updates, followed by periodic outbound network sessions aligned to location update timing—suggesting covert or policy-violating location tracking.

Defender correlates an app preparing to phish (gaining overlay/notification/accessibility capability) with precise foreground targeting (reading activity in front via accessibility/focus) and then presenting a look-alike UI (overlay window or activity-on-top) immediately before local storage or small-burst egress of entered data. Chain: capability/permission → target app in foreground detected → overlay/activity-on-top or fake notification tap → local prompt input write → near-term network egress.

Defender correlates a look-alike prompt inside an app (e.g., faux Apple ID password view, webview of brand login) with timing against scene/foreground activation, optional push notification bait, then local form cache writes and/or small egress. Chain: scene activation around sensitive UI → suspicious prompt creation (UIKit events without expected auth controller) or webview navigated to look-alike domain → local cache write → near-term egress

Defender correlates an app's opaque media ingress (download/IPC) with high-entropy or anomalous edits to image/audio/video files in app-writable storage (e.g., bursts of bitmap/codec operations, EXIF/IPTC/XMP mutation, suspicious container growth), followed by decoding/extraction behavior (new non-media artifact derived from the edited media) and optional exfiltration/sharing of the stego media. Focus is on: (1) opaque media arrival → (2) rapid metadata or pixel-domain mutations with atypical size/entropy deltas → (3a) decoded payload creation or dynamic load from decoded path, and/or (3b) upload/share of the modified media within a tight window.

An application with access to broad file scopes or sensitive storage areas becomes active, performs abnormal burst file reads and writes across many user or shared-storage locations, transforms file content or extensions at scale in a short window, and causes rapid file inaccessibility, rewrite, or replacement inconsistent with normal sync, backup, media processing, or document-editing behavior. The defender correlates capability state, app lifecycle, framework use, bulk file-write effects, and optional network communications to distinguish encrypt-for-impact behavior from benign bulk file operations.

OLD: Application vetting services could look for `android.permission.READ_CONTACTS` in an Android application’s manifest, or `NSContactsUsageDescription` in an iOS application’s `Info.plist` file. Most applications do not need contact list 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 the contact list through the device settings screen, revoking the permission if necessary.

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

Application vetting services could look for `android.permission.READ_CONTACTS` in an Android application’s manifest, or `NSContactsUsageDescription` in an iOS application’s `Info.plist` file. Most applications do not need contact list 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 the contact list through the device settings screen, revoking the permission if necessary.

Defender observes an app enumerating installed security/management controls (AV/EDR/MDM/VPN/Play Protect) via PackageManager, DevicePolicyManager, AppOps, and Settings queries or shell ‘pm list’ usage, optionally probing Accessibility/Device Admin state. Enumeration is followed by local inventory artifact creation and/or small egress. Chain: capability to query → burst of security-focused checks (packages/permissions/policies) → optional foreground targeting → artifact write → quick POST.

Defender correlates app attempts to enumerate or infer security/management tooling (ManagedConfiguration/MDM presence, VPN/NEFilter config, AV/EDR app presence via LaunchServices or URL-scheme probing, private APIs) with local inventory persistence and egress. Chain: probe (MDM/NE/VPN/AV presence) → burst of LS/canOpenURL/ManagedConfiguration calls → inventory cache write → small POST.

The user can view permissions granted to an application in device settings. Application vetting services typically flag permissions requested by an application, which can be reviewed by an administrator. Certain dangerous permissions, such as `RECEIVE_SMS`, could receive additional scrutiny.

The user can view permissions granted to an application in device settings. Application vetting services typically flag permissions requested by an application, which can be reviewed by an administrator. Certain dangerous permissions, such as `RECEIVE_SMS`, could receive additional scrutiny.

Defender observes an app (package/UID) issuing high-rate directory or content-index enumerations against external/shared storage or other apps’ Documents/Media providers (logcat:ContentResolver, logcat:StorageAccessFramework), followed within a short window by bulk READ handles or stat/list calls over many distinct paths (logcat:FileIO). Activity occurs without foreground UI or exceeds typical per-app baseline, indicating automated file/dir discovery rather than user-driven browsing. Correlate on package/UID/profile and time proximity.

Defender observes an app (bundle/process) performing large-scope directory listings or metadata reads via FileProvider/NSFileManager against user-visible containers (Files app locations, iCloud/On-My-iPhone) or external providers, with rapid traversal across many folders while the app is backgrounded or without corresponding UI activity (unifiedlogs:FileProvider, unifiedlogs:FileIO). Optional signals include Photo library or document picker bulk enumeration absent recent user gesture. Correlate on bundle/process/profile and path volume within a bounded window.

Applications could be vetted for their use of the clipboard manager APIs with extra scrutiny given to application that make use of them.

Mobile security products may provide URL inspection services that could determine if a domain being visited is malicious. Enterprises may be able to detect anomalous traffic originating from mobile devices, which could indicate compromise.

Mobile security products may provide URL inspection services that could determine if a domain being visited is malicious. Enterprises may be able to detect anomalous traffic originating from mobile devices, which could indicate compromise.

A defender observes an application establishing application-layer network sessions (e.g., HTTP(S), WebSocket, DNS, SMTP/IMAP) with destinations and request patterns that deviate from the enterprise baseline for that app category, especially when sessions occur during background execution or while the device is locked and exhibit beacon-like periodicity, anomalous SNI/Host patterns, or suspicious request/response size symmetry consistent with command polling and tasking over legitimate-looking protocols.

A defender observes an application generating application-layer communications that blend with normal traffic (HTTP(S), WebSocket, DNS, mail protocols) but show deviations from enterprise baselines for that bundle ID—such as persistent background network sessions, regular low-volume polling intervals, anomalous SNI/Host destinations, uncommon DNS patterns, or uniform request/response sizing—suggesting command and control over legitimate-looking protocols without relying on tool signatures.

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

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