1200KM / telemetry
Malware Metadata — Detection Telemetry
Descriptive attributes of a suspicious software sample or malware analysis record.
Collection and providers
Ingest permitted analysis metadata with sample hash, tool/version, submission provenance and confidence; keep verdicts separate from observed facts.
- YARA: Static rule matches and matched strings on authorized files; not proof of execution or attribution.
- Authorized sample repositories / STIX analysis reports: Sample identity, provenance and analysis observations; access and retention are separately controlled.
Configuration
- Work offline with an authorized sample or benign fixture; record its SHA-256, origin and custody before analysis.
- For static matching, pin reviewed YARA rules/tool version and capture match IDs and offsets where needed. Treat untrusted rules and samples as untrusted input.
- Store sanitized findings separately from restricted sample bytes. Label static observations, verdicts and any independently obtained dynamic results distinctly.
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": "DC0003",
"collector": "illustrative-lab-collector",
"observation": {
"sample_sha256": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"file_type": "PE32",
"analysis_status": "static_only",
"verdict": "undetermined"
}
}Visibility and validation
A rule match is not a confirmed infection. Metadata is not payload content, and static analysis does not prove a behavior occurred on a victim. No samples are executed by this module.
- 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.
- T1587 · Develop Capabilities · Detection rules & anomalies
- T1587.001 · Malware · Detection rules & anomalies
- T1587.002 · Code Signing Certificates · Detection rules & anomalies
- T1588 · Obtain Capabilities · Detection rules & anomalies
- T1588.001 · Malware · Detection rules & anomalies
- T1588.002 · Tool · Detection rules & anomalies
- T1588.003 · Code Signing Certificates · 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.
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.