DC0067: Logon Session Creation

The successful establishment of a new user session following a successful authentication attempt. This typically signifies that a user has provided valid credentials or authentication tokens, and the system has initiated a session associated with that user account. This data is crucial for tracking authentication events and identifying potential unauthorized access. Examples:

- Windows Systems - Event ID: 4624 - Logon Type: 2 (Interactive) or 10 (Remote Interactive via RDP). - Account Name: JohnDoe - Source Network Address: 192.168.1.100 - Authentication Package: NTLM - Linux Systems - /var/log/utmp or /var/log/wtmp: - Log format: login user [tty] from [source_ip] - User: jane - IP: 10.0.0.5 - Timestamp: 2024-12-28 08:30:00 - macOS Systems - /var/log/asl.log or unified logging framework: - Log: com.apple.securityd: Authentication succeeded for user 'admin' - Cloud Environments - Azure Sign-In Logs: - Activity: Sign-in successful - Client App: Browser - Location: Unknown (Country: X) - Google Workspace - Activity: Login - Event Type: successful_login - Source IP: 203.0.113.55

EnterpriseDC0067Data ComponentObject v2.0 Modified Nov 12, 2025, 22:03 UTC (UTC+00:00)

Logon Session Creation is the evidence that a user session actually started after authentication succeeded. For leaders, this matters because many security decisions hinge not only on whether credentials were accepted, but whether access was established, from where, and under which account. It is a core audit and incident-response signal for validating account use, remote access, cloud access, and potential unauthorized access.

Executive priority

Treat this data component as foundational identity and access evidence. Security leaders should ask whether successful session creation is collected consistently across endpoints, servers, cloud services, and business-critical identity platforms. Gaps here weaken incident timelines, access reviews, compliance evidence, and the ability to distinguish routine user activity from suspicious access using valid credentials or tokens.

Technical view

SOC and IR teams should validate that successful session creation records include enough context to support investigation: account name, source address, timestamp, authentication method or package where available, logon type or client application where available, and the target system or service. The ATT&CK object provides examples such as Windows Event ID 4624, Linux utmp/wtmp records, macOS security or unified logs, Azure sign-in logs, and Google Workspace successful_login events. No ATT&CK detection logic or related techniques were supplied, so detection engineering should focus on coverage validation, normalization, and correlation with local identity, endpoint, network, and cloud access patterns.

Likely telemetry

Successful authentication/session creation logs
Windows logon events such as Event ID 4624 where available
Linux utmp/wtmp login records where available
macOS authentication or unified logging records where available
Cloud sign-in logs such as Azure successful sign-ins where available

Detection direction

Confirm that successful session creation events are collected from systems and services that matter to business operations and privileged access.
Normalize account, source address, timestamp, logon type, authentication method, client application, and target fields so events can be correlated across environments.
Tune analytics against expected user, administrator, service account, remote access, and cloud access patterns to reduce false positives from normal work locations and scheduled operations.
Look for blind spots where authentication succeeds but session creation is not logged, not retained, or not forwarded to the SOC.
Because no official ATT&CK detection text or relationships were supplied, avoid assuming specific adversary behaviors; use this component as supporting evidence in broader identity and access investigations.

Mitigation priorities

Prioritize reliable logging and retention for successful session creation across identity providers, endpoints, servers, and cloud services in scope.
Ensure privileged and remote interactive sessions receive higher retention and monitoring priority because they are often important to incident reconstruction.
Align log collection with compliance and audit requirements so access evidence can be produced during reviews or investigations.
Validate time synchronization and field normalization to support accurate incident timelines.
Review access control, authentication policy, and session management separately; this data component provides visibility, not a mitigation by itself.

Analyst notes and limits

This object is a data component, not a technique. Its value is evidentiary: it helps prove that an authenticated session was established and supplies context for access monitoring, investigations, and audit readiness. The examples span Windows, Linux, macOS, Azure, and Google Workspace logs, but the platforms field itself is not specified.

Official detection guidance and relationship context were not supplied. Local environment architecture, identity providers, logging configuration, retention, and normalization quality determine how useful this data component will be in practice.

Official MITRE ATT&CK definition

Logon Session Creation

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 2.0
Created: Oct 20, 2021, 15:05 UTC (UTC+00:00)
Modified: Nov 12, 2025, 22:03 UTC (UTC+00:00)
Raw hash: a3c872e4ec822530...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	Nov 12, 2025, 22:03 UTC (UTC+00:00)	Current bundle	`a3c872e4ec82…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
mitre-attack DC0067
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use