T0859 Valid Accounts — 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.

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.

DC0088 collection page — Collect supported session inventory and correlate session IDs with authentication, logon and logoff events.

Providers and collection configuration

• osquery: Scheduled host-state queries; supported tables and privileges vary by OS. Select a table that actually exposes the required object.
• Linux Audit plus inventory snapshots: Events explain changes; snapshots describe state at collection time.

• Define the inventory query, allowed host set, interval and least-privileged reader. Store a stable asset ID, observation time and collector version.
• Keep successive snapshots and calculate additions, removals and changed attributes. Pair state changes with audit events when available.
• Export collector health and missed-poll counts so a missing snapshot is not misclassified as a missing asset.

Required normalized fields: session_id, account, host, session_type.

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": "DC0088",
  "collector": "illustrative-lab-collector",
  "observation": {
    "session_id": "lab-session-1",
    "account": "LAB\\analyst",
    "host": "lab-host-1",
    "session_type": "interactive"
  }
}

Visibility limits: Snapshots miss short-lived objects and do not identify who caused a change. A generic inventory agent is not guaranteed to expose firmware or kernel-level details.

DC0082 collection page — Enable scoped Sysmon NetworkConnect (3), disabled by default, or a platform-equivalent process-aware network sensor.

Providers and collection configuration

• Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
• Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
• Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.

• On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
• Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
• For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, destination_ip, destination_port, protocol, initiated.

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": "DC0082",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "destination_ip": "198.51.100.20",
    "destination_port": 443,
    "protocol": "tcp",
    "initiated": true
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

DC0085 collection page — Scope approved packet capture/protocol content collection to the lab flow; retain capture provenance and truncation indicators.

Providers and collection configuration

• Zeek: Connection and protocol metadata from traffic visible to the sensor.
• Suricata EVE: Configured flow, alert, DNS, HTTP, TLS and protocol records.

• Use an authorized lab TAP/SPAN, virtual mirror or gateway interface. Define which traffic crosses it; avoid assuming visibility into every segment.
• Enable the required Zeek analyzers or Suricata EVE event types. Export logs with sensor identity, clock synchronization and flow correlation identifiers.
• Monitor capture loss, truncation and exporter sampling. Capture payload only with approval and restrictive retention; encryption normally prevents plaintext inspection.

Required normalized fields: flow_id, protocol, method, path, payload_excerpt.

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": "DC0085",
  "collector": "illustrative-lab-collector",
  "observation": {
    "flow_id": "lab-flow-1",
    "protocol": "http",
    "method": "GET",
    "path": "/lab-check",
    "payload_excerpt": "LAB_TELEMETRY_CHECK"
  }
}

Visibility limits: Flows are not packet payloads. NAT, asymmetric routes, encryption, missing mirrors and sampling can hide attribution or content. A destination connection alone does not prove malicious intent.

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.

• S0089 BlackEnergy — malware.

  BlackEnergy utilizes valid user and administrator credentials, in addition to creating new administrator accounts to maintain presence. [Booz Allen Hamilton]
  

  Exact relationship: relationship--ee2fdebd-1587-4e53-a7d7-c15fcc88879d
• S1045 INCONTROLLER — malware.

  INCONTROLLER can brute force password-based authentication to Schneider PLCs over the CODESYS protocol (UDP port 1740).[CISA-AA22-103A]

  INCONTROLLER can perform brute force guessing of passwords to OPC UA servers using a predefined list of passwords.[CISA-AA22-103A][Wylie-22]

  Exact relationship: relationship--6681bc38-0b55-4714-b690-c609956b40bf

• M0801 Access Management

  Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.
  

• M0913 Application Developer Guidance

  Ensure that applications and devices do not store sensitive data or credentials insecurely (e.g., plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage). [CISA June 2013]
  

• M0915 Active Directory Configuration

  Consider configuration and use of a network-wide authentication service such as Active Directory, LDAP, or RADIUS capabilities which can be found in ICS devices. [Keith Stouffer May 2015] [Schweitzer Engineering Laboratories August 2015]
  

• M0918 User Account Management

  Ensure users and user groups have appropriate permissions for their roles through Identity and Access Management (IAM) controls. Implement strict IAM controls to prevent access to systems except for the applications, users, and services that require access. Implement user accounts for each individual for enforcement and non-repudiation of actions.
  

• M0926 Privileged Account Management

  Audit domain and local accounts and their permission levels routinely to look for situations that could allow an adversary to gain system wide access with stolen privileged account credentials. [Microsoft May 2017] [Microsoft August 2018]These audits should also identify if default accounts have been enabled, or if new local accounts are created that have not be authorized. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers. [Microsoft February 2019]
  

• M0927 Password Policies

  Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment. [CISA June 2013]
  

• M0932 Multi-factor Authentication

  Integrating multi-factor authentication (MFA) as part of organizational policy can greatly reduce the risk of an adversary gaining access to valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information. MFA can also be used to restrict access to cloud resources and APIs.
  

• M0936 Account Use Policies

  Configure features related to account use like login attempt lockouts, specific login times, and password strength requirements as examples. Consider these features as they relate to assets which may impact safety and availability. [Keith Stouffer May 2015]
  

• M0937 Filter Network Traffic

  Consider using IP allowlisting along with user account management to ensure that data access is restricted not only to valid users but only from expected IP ranges to mitigate the use of stolen credentials to access data.
  

• M0947 Audit

  Routinely audit source code, application configuration files, open repositories, and public cloud storage for insecure use and storage of credentials.