Provider-side audit (if lawfully available) — Detection Telemetry

Collection and providers

Document legal/account-owner access and provider coverage before ingestion. Preserve original IDs, timestamps and disclosure limits; do not seek unauthorized access.

• Authorized provider/account-owner audit exports: Available only with the provider or account owner’s lawful access and supported export.
• CloudTrail in an owned lab account: A concrete lab-side example; it does not grant access to adversary-controlled accounts.

Configuration

• Establish the authorized account, record owner and export mechanism before collection. Without access, mark this input unavailable rather than simulating defender visibility.
• Preserve source event IDs, account/resource IDs, original timestamps and the authorized disclosure/export record.
• Document which events the provider actually exposes and compare delivered records to the request scope. Keep lab-side actions separate from victim-side evidence.

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": "proposed-provider-side-audit-if-lawfully-available",
  "collector": "illustrative-lab-collector",
  "observation": {
    "provider_record_id": "lab-disclosure-1",
    "access_basis": "authorized_test_account_export",
    "action": "account_created",
    "victim_network_observation": false
  }
}

Visibility and validation

Customer-accessible audit APIs do not expose arbitrary third-party accounts. A synthetic provider event cannot establish access, attribution or detection coverage in a real investigation.

• 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 event categories