1200KM / telemetry
Cloud Storage Deletion — Detection Telemetry
Deletion of cloud storage infrastructure such as a bucket or container.
Collection and providers
Collect bucket/container administrative deletion and final resource state. Object-delete events may be supporting context but are not the same infrastructure operation.
- AWS CloudTrail for S3: Bucket control-plane events and explicitly selected object data events.
- Google Cloud Audit Logs: Cloud Storage access requires the relevant audit category and permissions.
- Azure storage resource logs: Use resource-specific data-plane diagnostics; Activity Log alone does not describe blob reads.
Configuration
- Choose only the lab buckets/containers and prefixes. Enable read/write data-event collection when object access is needed; management events alone are insufficient.
- Keep administrative changes separately from object reads/writes. Set a cost budget and retention limit before enabling high-volume data logging.
- Preserve object version/key, requesting identity, action, source address, result and request ID. Verify the collector actually receives one benign read and one benign write.
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": "DC0022",
"collector": "illustrative-lab-collector",
"observation": {
"action": "delete_bucket",
"bucket": "lab-bucket",
"actor": "lab-admin",
"result": "success"
}
}Visibility and validation
Storage metadata, listing, object access and bucket administration are different operations. Do not equate a successful request with proven exfiltration or complete content visibility.
- 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.
Attack tools through shared TTPs
These are two-hop navigation links through explicitly associated techniques, not independent tool-to-sensor assertions.
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.