Response Metadata — Detection Telemetry

Metadata about an Internet-facing resource inferred from authorized scan responses, such as open ports, services and reported versions.

Collection and providers

Preserve target, observation time, scan method and response evidence; distinguish inferred service identity from an authenticated software inventory.

Nmap XML reports: Structured port/service observations from a separately authorized scan or existing report.
Zeek protocol observations: Passive corroboration for visible service responses; not equivalent to active scan coverage.

Configuration

Use an existing authorized scan report or an explicitly approved isolated target set. Record tool/version, scan options, time window and scope.
Preserve native XML and normalized host/port/protocol/service fields. Disable XML external-entity resolution in downstream parsers.
Keep inferred service names/versions and their confidence separate from authenticated inventory; retain response evidence when available.

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": "DC0106",
  "collector": "illustrative-lab-collector",
  "observation": {
    "target": "192.0.2.20",
    "port": 443,
    "transport": "tcp",
    "service": "https",
    "version": "not_identified",
    "observation_source": "authorized_lab_scan"
  }
}

Visibility and validation

A reported open port or banner is not a proven vulnerability. Filtered/no-response states can reflect routing or policy. The website performs no scans.

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

Network and protocol telemetry attack_component Nmap XML reports Zeek protocol observations

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.