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.

Synthetic normalized event

{
  "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

Android iOS

Mobile lab instrumentation attack_component Android logcat Android dumpsys Instrumented test application

Each workspace retains its own logsource and platform requirements. A technique-level association is not a per-rule sensor mapping.

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.

Native security log sources

Security log-source library groups concrete producers and formats separately from ATT&CK data components. Samples carry provenance and version limits; associations do not prove collection coverage.

Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.