Web Credential Creation — Detection Telemetry

Collection and providers

Collect issuer/admin audit for credential creation with non-secret key or credential ID, owner and expiry; never record the secret value.

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

Configuration

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

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": "DC0006",
  "collector": "illustrative-lab-collector",
  "observation": {
    "application_id": "lab-app",
    "credential_id": "key-lab-1",
    "action": "issue",
    "expires_at": "2026-09-28T12:00:00Z"
  }
}

Visibility and validation

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.

• 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

• Microsoft Entra sign-in logs
• AWS CloudTrail event categories
• OpenTelemetry log data model