1200KM / telemetry
Cloud Storage Creation — Detection Telemetry
Creation of a cloud storage resource such as a bucket or container.
Collection and providers
Collect bucket/container creation APIs and resulting resource state. An object upload is not equivalent to provisioning the storage resource.
- 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": "DC0024",
"collector": "illustrative-lab-collector",
"observation": {
"action": "create_bucket",
"bucket": "lab-bucket",
"region": "lab-region",
"actor": "lab-admin"
}
}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.
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.