Complete technique description
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.[SWB Exodus March 2019]
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.
Official technique definition · Open in the interactive matrix
Parent and sub-techniques
Related pages are navigation context. Their tools, rules and lab results are not automatically inherited.
Detection telemetry and configuration
These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.
Application Permission · source-mapped
DC0114 collection page — Compare manifest declarations with runtime granted state using authorized package inspection and own-app permission checks.
Providers and collection configuration
- Android logcat: Permitted logs from a consented test device/emulator; output depends on build, permissions and instrumentation.
- Android dumpsys: Point-in-time service/package state on an authorized development device.
- Instrumented test application: Own-app permission, API and state callbacks; not universal visibility into other apps.
- Use a disposable emulator or owned development device with approved debugging. Record OS/API level, app version and instrumentation privileges.
- Collect only relevant logcat buffers/tags and service snapshots; add explicit own-app instrumentation for events absent from OS logs.
- Forward sanitized logs and compare before/after state. Remove test data and revoke debugging access after the lab session.
Required normalized fields: package, permission, declared, granted.
adb shell dumpsys package test.example.lab
Read-only snapshot on a consented debug device. Replace the example package with your owned test app. Output and access vary by Android build; this is not a permission-request event stream.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0114",
"collector": "illustrative-lab-collector",
"observation": {
"package": "test.example.lab",
"permission": "android.permission.CAMERA",
"declared": true,
"granted": false
}
}
Visibility limits: Android tooling does not imply iOS coverage. Standard mobile apps cannot observe all other apps or protected OS internals; MDM status is not full API, filesystem or content telemetry.
Application State · source-mapped
DC0123 collection page — Instrument the owned app lifecycle and corroborate permitted service snapshots; distinguish app events from inferred gateway activity.
Providers and collection configuration
- Android logcat: Permitted logs from a consented test device/emulator; output depends on build, permissions and instrumentation.
- Android dumpsys: Point-in-time service/package state on an authorized development device.
- Instrumented test application: Own-app permission, API and state callbacks; not universal visibility into other apps.
- Use a disposable emulator or owned development device with approved debugging. Record OS/API level, app version and instrumentation privileges.
- Collect only relevant logcat buffers/tags and service snapshots; add explicit own-app instrumentation for events absent from OS logs.
- Forward sanitized logs and compare before/after state. Remove test data and revoke debugging access after the lab session.
Required normalized fields: package, state_before, state_after, source.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0123",
"collector": "illustrative-lab-collector",
"observation": {
"package": "test.example.lab",
"state_before": "background",
"state_after": "foreground",
"source": "own_app_callback"
}
}
Visibility limits: Android tooling does not imply iOS coverage. Standard mobile apps cannot observe all other apps or protected OS internals; MDM status is not full API, filesystem or content telemetry.
OS API Execution · source-mapped
DC0021 collection page — Use an approved EDR trace or instrument the owned lab process at selected APIs. Define API name, caller, sanitized arguments and return status.
Providers and collection configuration
- Enable the application audit category or instrument the owned lab application at the authorization/action boundary.
- Define a schema with timestamp, service, actor, object, action, result and correlation ID. Export structured records through an authenticated collector.
- Redact secrets and personal content, separate audit from debug logs, set retention and verify delivery during rotation/restart.
Required normalized fields: process_id, api, path, result.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0021",
"collector": "illustrative-lab-collector",
"observation": {
"process_id": 4200,
"api": "CreateFileW",
"path": "C:\\Lab\\demo.txt",
"result": "success"
}
}
Visibility limits: Debug output is not necessarily a durable audit trail. Application developers must emit the relevant event; installing a log pipeline does not make an absent event exist.
Simulation design and documented procedures
Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.
Use owned test devices or emulators, disposable app accounts and test data. Verify platform/version instrumentation; desktop test procedures do not establish mobile coverage.
No compatible Atomic procedure is present in this pinned evidence set. Technical feasibility has not been ruled out. A custom procedure must define the behavior, target, collection point, success observable and rollback before execution.
Technique-specific experiment contract
- Choose one procedure implementing T1627 Execution Guardrails; identify the observable behavior in the source definition, not just its tactic.
- Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
- Enable the collection sources above and verify a benign baseline reaches the detector.
- Run only the approved isolated scenario; capture native events and an independent behavior observable.
- Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.