T1627: Execution Guardrails
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.
Analyst context for executives and security teams
Execution Guardrails matter because mobile malware may be designed to run only when a device matches an intended target condition, such as location or other environment-specific values. For leaders, this means a clean sandbox run or a non-triggering test device may not prove the threat is harmless; the risk is missed behavior until the app is analyzed under conditions closer to the targeted environment.
Executive priority
Prioritize this as a mobile detection and incident-response readiness issue for Android and iOS. The business question is whether the organization can prove what mobile telemetry it collects, how it tests suspicious apps under realistic conditions, and whether mobile OS currency and user guidance are enforceable across the fleet. This also supports audit evidence for mobile governance, especially OS version management and risky permission behavior such as location access.
Technical view
ATT&CK provides no official detection text for T1627, but the relationship to DET0653 indicates a detection strategy exists. SOC and IR teams should validate whether mobile analysis workflows can identify payloads that check for expected target-specific values before continuing execution. Testing should include varied device profiles, installed application sets, phone/account attributes where lawfully available, OS versions, and location states, because the technique is distinct from generic sandbox evasion: the malicious logic may require a positive target match rather than simply avoiding known sandbox indicators.
Likely telemetry
- Mobile device management or mobile security inventory for Android and iOS devices, installed apps, and OS versions
- Application permission events or configuration evidence, especially location services where applicable to geofencing behavior
- Mobile app behavioral analysis results showing collection or comparison of device, environment, application inventory, phone number, or location-related values when available
- Network telemetry from mobile devices or controlled analysis environments that can show delayed or conditional communication after a guardrail condition is met
- Incident response acquisition data from the affected mobile device sufficient to compare observed behavior across different environmental conditions
Detection direction
- Validate whether DET0653-aligned logic is implemented in mobile malware analysis and managed detection workflows rather than relying only on default sandbox execution results.
- Tune analysis to look for conditional execution paths tied to target-specific values, including location as reflected by the Geofencing sub-technique T1627.001.
- Use relationship context carefully: Binary Validator is noted for collecting device information before later implant deployment, and DocSwap is associated with this technique, but local detections should be based on observed mobile behavior and telemetry, not names alone.
- Account for false negatives when test devices lack the expected environmental condition; absence of malicious behavior in one environment is not sufficient evidence of benignness.
Mitigation priorities
- Maintain recent Android and iOS versions across the mobile fleet, aligning with M1006, because newer mobile OS releases include patches and security architecture improvements.
- Apply M1011 user guidance: train users to avoid risky mobile behaviors and to make informed choices about sensitive permissions such as location access when relevant.
- Use mobile governance processes to document OS version compliance, app review outcomes, and permission guidance as evidence for security and audit readiness.
- For suspected cases, sequence response around preservation and analysis of the device environment, not only the app binary, because the trigger condition may be environmental.
Analyst notes and limits
The key defensive value is recognizing that guardrails can hide capability exposure during analysis. The supplied relationships show this technique has a geofencing sub-technique and is used by listed mobile software examples on iOS and Android, but those relationships should be treated as context for detection engineering and triage rather than proof of exposure in any environment.
MITRE provides no official detection text and no ATT&CK tactic for this object. Telemetry and control recommendations therefore depend on local mobile management, mobile security tooling, legal constraints on device data collection, and the ability to reproduce target-specific conditions during analysis.
Execution Guardrails
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.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1627.001 | Geofencing Sub-technique | Geofencing subtechnique of this object. |
Groups, software, and campaigns
S1215: Binary Validator
Binary Validator is a Mach-O binary file used during Operation Triangulation.[1] Binary Validator first collects information about the device, such as the device's phone number and a list of installed applications, before the deployment of the TriangleDB implant. After the actions are completed and the data is collected, Binary Validator encrypts and sends the data to the C2 server, and in turn, the C2 server sends the TriangleDB implant.
S9005: DocSwap
DocSwap is an Android malware first identified in 2025, and attributed to Kimsuky. DocSwap’s name is a combination of its Korean name “문서열람 인증 앱” (Document Viewing Authentication App) and a phishing page masquerading as CoinSwap at the C2 address. Based on DocSwap’s name and Korean-language strings, DocSwap potentially targets mobile device users in South Korea. Several variants of DocSwap exist; one of the latest samples indicates that the adversary added a native decryption function that decrypts an internal APK.[1][2]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | b38436a13156… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
SWB Exodus March 2019
Security Without Borders. (2019, March 29). Exodus: New Android Spyware Made in Italy. Retrieved November 17, 2024.
Open source URL -
[2]
mitre-attack T1627Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.