1200KM / telemetry
System Notifications — Detection Telemetry
Operating-system notifications about device state, application actions or security events.
Collection and providers
Use consented system debugging or supported notification monitoring; collect metadata rather than notification contents unless explicitly approved.
- 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": "DC0117",
"collector": "illustrative-lab-collector",
"observation": {
"device_id": "android-lab-1",
"notification_type": "usb_connection",
"source": "system",
"content_collected": false
}
}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.
- T1414 · Clipboard Data · Detection rules & anomalies
- T1635 · Steal Application Access Token · Detection rules & anomalies
- T1635.001 · URI Hijacking · Detection rules & anomalies
- T1644 · Out of Band Data · Detection rules & anomalies
- T1655 · Masquerading · Detection rules & anomalies
- T1655.001 · Match Legitimate Name or Location · Detection rules & anomalies
- T1676 · Linked Devices · Detection rules & anomalies
Attack tools through shared TTPs
These are two-hop navigation links through explicitly associated techniques, not independent tool-to-sensor assertions.
No reviewed association in this snapshot.
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.