Cloud Storage Access — Detection Telemetry

Collection and providers

Explicitly select relevant object-read data events; keep principal, key, request ID and result without object contents.

• 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.

[
  {
    "Name": "LabObjectReads",
    "FieldSelectors": [
      {
        "Field": "eventCategory",
        "Equals": [
          "Data"
        ]
      },
      {
        "Field": "resources.type",
        "Equals": [
          "AWS::S3::Object"
        ]
      },
      {
        "Field": "resources.ARN",
        "StartsWith": [
          "arn:aws:s3:::lab-bucket/demo/"
        ]
      },
      {
        "Field": "readOnly",
        "Equals": [
          "true"
        ]
      }
    ]
  }
]

Replace the placeholder with an owned lab bucket/prefix. Review costs and merge with required selectors; applying selectors can replace an existing selection. This does not enable management-event retention or object-write coverage.

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": "DC0025",
  "collector": "illustrative-lab-collector",
  "observation": {
    "action": "get_object",
    "bucket": "lab-bucket",
    "key": "demo.txt",
    "actor": "lab-reader",
    "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

• AWS CloudTrail data-event selectors
• AWS CloudTrail event categories
• Google Cloud Audit Logs
• Azure Blob Storage resource logging