T1538 Cloud Service Dashboard — Attack Simulation

DC0038 collection page — Select the application event family required by the detection and document its native schema before normalization.

Providers and collection configuration

• Application audit logs: First-party service events and request/result fields; schema is application-specific.
• OpenTelemetry-compatible log pipelines: Transport and normalization of emitted records; do not create missing audit instrumentation.

• Enable the application audit category or instrument the owned lab application at the authorization/action boundary.
• Define a schema with timestamp, service, actor, object, action, result and correlation ID. Export structured records through an authenticated collector.
• Redact secrets and personal content, separate audit from debug logs, set retention and verify delivery during rotation/restart.

Required normalized fields: service, action, actor, record_count, result.

Illustrative collection event

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": "DC0038",
  "collector": "illustrative-lab-collector",
  "observation": {
    "service": "lab-portal",
    "action": "export_requested",
    "actor": "lab-reader",
    "record_count": 3,
    "result": "authorized"
  }
}

Visibility limits: Debug output is not necessarily a durable audit trail. Application developers must emit the relevant event; installing a log pipeline does not make an absent event exist.

DC0027 collection page — Take authorized metadata snapshots including resource ID, owner, region, encryption and policy summary; record observation time.

Providers and collection configuration

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

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

Required normalized fields: bucket, region, encryption_enabled, public_access.

Illustrative collection event

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": "DC0027",
  "collector": "illustrative-lab-collector",
  "observation": {
    "bucket": "lab-bucket",
    "region": "lab-region",
    "encryption_enabled": true,
    "public_access": false
  }
}

Visibility limits: Storage metadata, listing, object access and bucket administration are different operations. Do not equate a successful request with proven exfiltration or complete content visibility.

DC0067 collection page — Enable Audit Logon and collect successful session creation on the receiving host; join session/logon IDs rather than only account names.

Providers and collection configuration

• Windows Security auditing: Policy-dependent account, object, task and logon records on the host that performs the operation.

• Use a lab-only GPO under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Enable the specific subcategory named below.
• For object-level auditing, configure a narrow system access control list (SACL) on the test object in addition to policy. Do not audit an entire production directory by default.
• Forward Security events from the responsible host or controller; retain subject and target identities, object identifiers, result and original XML. Confirm effective policy with auditpol /get /category:*.

Required normalized fields: account, logon_id, logon_type, source_ip.

Illustrative collection event

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": "DC0067",
  "collector": "illustrative-lab-collector",
  "observation": {
    "account": "LAB\\analyst",
    "logon_id": "0x12345",
    "logon_type": 3,
    "source_ip": "192.0.2.10"
  }
}

Visibility limits: A policy checkbox alone does not guarantee an event. Host role, SACL, success/failure selection and audit policy precedence matter. Directory changes may arrive as multiple records.

DC0002 collection page — Collect successful and failed sign-ins, authentication method, application and conditional-access context; distinguish account validation from session creation.

Providers and collection configuration

• Microsoft Entra sign-in logs: Interactive, non-interactive and workload sign-in contexts, subject to tenant features and access.
• Cloud identity service audit: Issuer-side credential and administrative events where the service supports them.
• Application audit instrumentation: Application-side use of identities and sessions; design fields without raw tokens.

• Enable/export the required identity sign-in and audit categories from the lab tenant to a protected destination. Document license, role and retention requirements.
• Correlate issuance or administrative changes with later sign-ins using non-secret credential IDs, application IDs, user IDs and correlation IDs.
• Exclude passwords, bearer tokens, cookies and private keys. Record success, failure, authentication context and application result separately.

Required normalized fields: account, application, result, reason, source_ip.

Illustrative collection event

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": "DC0002",
  "collector": "illustrative-lab-collector",
  "observation": {
    "account": "analyst@example.test",
    "application": "lab-portal",
    "result": "failure",
    "reason": "invalid_credential",
    "source_ip": "192.0.2.10"
  }
}

Visibility limits: A token creation record is not evidence of token use; a sign-in is not a complete record of every resource access. Some provider-side data is unavailable to the customer.

MITRE detection strategy

No exact-tagged Sigma source rule was imported. This does not establish that the technique is undetectable; the MITRE guidance and collection requirements remain relevant.

• M1018 User Account Management

  Enforce the principle of least-privilege by limiting dashboard visibility to only the resources required. This may limit the discovery value of the dashboard in the event of a compromised account.