1200KM / telemetry
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.
{
"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
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.
- T1583 · Acquire Infrastructure · Detection rules & anomalies
- T1583.003 · Virtual Private Server · Detection rules & anomalies
- T1583.004 · Server · Detection rules & anomalies
- T1584 · Compromise Infrastructure · Detection rules & anomalies
- T1584.003 · Virtual Private Server · Detection rules & anomalies
- T1584.004 · Server · Detection rules & anomalies
- T1665 · Hide Infrastructure · 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.