1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / telemetry

Process Creation — Detection Telemetry

Creation of a process with executable, command line, parent and security context.

Collection and providers

Collect Sysmon ProcessCreate (1); preserve ProcessGuid and parent identifiers. Security 4688 is an alternative with separate audit/command-line settings.

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.

Configuration

  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.
<EventFiltering>
  <ProcessCreate onmatch="include">
    <Image condition="is">C:\Windows\System32\whoami.exe</Image>
  </ProcessCreate>
</EventFiltering>

This fragment only selects the named process. It is not a complete production policy. Inspect the installed schema with sysmon64 -s; preserve existing rules, then apply the reviewed complete configuration with sysmon64 -c <configuration-file>.

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": "DC0032",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "image": "C:\\Windows\\System32\\whoami.exe",
    "parent_image": "C:\\Windows\\System32\\cmd.exe",
    "command_line": "whoami",
    "user": "LAB\\analyst"
  }
}

Visibility and validation

Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

  • 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

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.

Connected anomaly research

Curated research views reached through an exact source technique, a catalog model, or a reviewed collection reference. These are navigation associations, not claims of detector effectiveness or sensor equivalence.

Telemetry contracts · Maintained query examples · Validation and blind spots

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.