1200KM / telemetry
Protected Configuration — Detection Telemetry
State or changes affecting security-sensitive device configuration.
Collection and providers
Use approved device-management/research-build interfaces to snapshot the specific protected setting; document privileges and unsupported fields.
- 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.
Configuration
- 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.
Synthetic event example
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": "DC0115",
"collector": "illustrative-lab-collector",
"observation": {
"device_id": "android-lab-1",
"setting": "usb_debugging_enabled",
"before": false,
"after": true
}
}Visibility and validation
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.
- Record the lab scope, collector version, effective configuration and expected source fields before testing.
- Use an approved benign action or read-only snapshot appropriate to this type. For destructive, privileged or physical effects, use a reviewed fixture or existing authorized evidence instead of causing the effect.
- Verify the native source record locally and at the collector; compare timestamps, identity, object, action/result and the type-specific fields listed below. Save a redacted real capture separately from the synthetic example.
- Check a normal baseline and collector-loss case. Fixture parsing proves parser behavior only; it does not prove sensor coverage or malicious-behavior detection.
Primary sources
Connected ecosystem references
Linked tags
Related simulations and detection workspaces
Each workspace retains its own logsource and platform requirements. A technique-level association is not a per-rule sensor mapping.
- T1458 · Replication Through Removable Media · Detection rules & anomalies
- T1461 · Lockscreen Bypass · Detection rules & anomalies
- T1464 · Network Denial of Service · Detection rules & anomalies
- T1471 · Data Encrypted for Impact · Detection rules & anomalies
- T1474 · Supply Chain Compromise · Detection rules & anomalies
- T1474.001 · Compromise Software Dependencies and Development Tools · Detection rules & anomalies
- T1638 · Adversary-in-the-Middle · Detection rules & anomalies
Attack tools through shared TTPs
These are two-hop navigation links through explicitly associated techniques, not independent tool-to-sensor assertions.
Pinned research references. No browser attack runner, live simulation result or validated detector is asserted. Source mappings and validation limits are preserved. ATT&CK / Atomic provenance · Detection provenance.