| ID | Name |
|---|---|
| T1627.001 | Geofencing |
Adversaries may use execution guardrails to constrain execution or actions based on adversary supplied and environment specific conditions that are expected to be present on the target. Guardrails ensure that a payload only executes against an intended target and reduces collateral damage from an adversary’s campaign. Values an adversary can provide about a target system or environment to use as guardrails may include environment information such as location.[1]
Guardrails can be used to prevent exposure of capabilities in environments that are not intended to be compromised or operated within. This use of guardrails is distinct from typical System Checks. While use of System Checks may involve checking for known sandbox values and continuing with execution only if there is no match, the use of guardrails will involve checking for an expected target-specific value and only continuing with execution if there is such a match.
| ID | Name | Description |
|---|---|---|
| S1215 | Binary Validator |
Binary Validator has checked if the device is jailbroken.[2] |
| S9005 | DocSwap |
DocSwap has checked if the victim has accessed the malicious URL from a PC. If so, DocSwap redirected the victim to scan the malicious QR code using a mobile device.[3] |
| ID | Mitigation | Description |
|---|---|---|
| M1006 | Use Recent OS Version |
New OS releases frequently contain additional limitations or controls around device location access. |
| M1011 | User Guidance |
Users should be advised to be extra scrutinous of applications that request location or sensitive phone information permissions, and to deny any permissions requests for applications they do not recognize. |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0653 | Detection of Execution Guardrails | AN1737 |
For Android, detect Execution Guardrails from documented management, network, or vetting evidence; treat state queries as periodic observations rather than real-time events. Correlate Application Permission via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]; Application State via Android Enterprise / EMM [Managed package inventory/status and package metadata]; OS API Execution via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: App performs burst of environmental check APIs (Build properties, TelephonyManager IMSI, PackageManager security-tool query) at cold launch before user interaction — multi-category environment fingerprint is the guardrail setup]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |
| AN1738 |
For iOS, detect Execution Guardrails from documented management, network, or vetting evidence; treat state queries as periodic observations rather than real-time events. Correlate Application Permission via Application Vetting [Code-signing entitlements and Info.plist privacy usage-description keys]; Application State via Apple MDM [InstalledApplicationList / ManagedApplicationList]; OS API Execution via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: App performs UIDevice model + iOS version + enrollment state checks at cold launch before user interaction — device fingerprinting guardrail setup]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |