1200KM / telemetry
Cloud Service Metadata — Detection Telemetry
Cloud service inventory and current configuration.
Collection and providers
Export service configuration with resource ID, region, status and enabled logging features using least-privileged read access.
- AWS CloudTrail: Management-plane API activity; supported resource/data events require separate selectors.
- Azure Monitor Activity Log: Azure resource control-plane operations; resource data-plane logs are separate.
- Google Cloud Audit Logs: Admin Activity and other categories; configure Data Access where required.
Configuration
- In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
- Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
- Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.
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": "DC0070",
"collector": "illustrative-lab-collector",
"observation": {
"resource_id": "lab-service-1",
"service": "lab-audit-service",
"enabled": true,
"retention_days": 30
}
}Visibility and validation
AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.
- 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.
- T1114.003 · Email Forwarding Rule · Detection rules & anomalies
- T1213.002 · Sharepoint · Detection rules & anomalies
- T1213.003 · Code Repositories · Detection rules & anomalies
- T1213.006 · Databases · Detection rules & anomalies
- T1499.003 · Application Exhaustion Flood · Detection rules & anomalies
- T1552 · Unsecured Credentials · Detection rules & anomalies
- T1552.005 · Cloud Instance Metadata API · Detection rules & anomalies
- T1578 · Modify Cloud Compute Infrastructure · Detection rules & anomalies
- T1677 · Poisoned Pipeline Execution · Detection rules & anomalies
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.