Detections

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.

Application vetting services may detect when an application requests permissions after an application update. Application vetting services may look for indications that the application’s update includes malicious code at runtime. Application vetting services may be able to list domains and/or IP addresses that applications communicate with.

Application vetting services may detect when an application requests permissions after an application update. Application vetting services may look for indications that the application’s update includes malicious code at runtime. Application vetting services may be able to list domains and/or IP addresses that applications communicate with.

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, app_process or shell hijacks, and malicious BOOT_COMPLETED 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 (ACTION_VIEW) 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//(shared_prefs|databases) (logcat:AccountManager, logcat:Keystore, logcat:FileIO). Correlate on package/UID/profile and time proximity to indicate token acquisition.

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] On Android, users may be presented with a popup to select the appropriate application to open a URI in. If the user sees an application they do not recognize, they can remove it.

On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.

On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.