DeviceLogonEvents & IdentityLogonEvents

 1. Which events will appear in DeviceLogonEvents vs IdentityLogonEvents?

 DeviceLogonEvents
- What it captures: This table contains information about user logons and authentication events that occur on devices. These are typically events tied to the local device context, such as a user logging into a workstation or server via interactive logon, remote desktop (RDP), or network authentication.
- Source: The data comes from the endpoint itself (e.g., a Windows device onboarded to Microsoft Defender for Endpoint). It reflects authentication activities processed by the device's security event logs or Defender for Endpoint sensors.
- Examples of events:
  - Interactive logons (e.g., typing credentials at the login screen).
  - RemoteInteractive logons (e.g., RDP sessions).
  - Network logons (e.g., accessing a shared resource).
  - Batch or service logons (e.g., scheduled tasks or services).

 IdentityLogonEvents
- What it captures: This table contains authentication events tied to identity systems, specifically those recorded by on-premises Active Directory (via Microsoft Defender for Identity) and Microsoft online services (via Microsoft Defender for Cloud Apps). It focuses on domain-level or cloud authentication activities.
- Source: The data is sourced from Domain Controllers (for on-premises AD) and Microsoft Entra ID (formerly Azure AD) or other cloud services monitored by Defender for Cloud Apps.
- Examples of events:
  - Domain logons validated by a Domain Controller (e.g., Kerberos or NTLM authentications).
  - Interactive sign-ins to Microsoft online services (e.g., Microsoft 365).
  - Legacy protocol authentications (e.g., ActiveSync).
- Limitations: Non-interactive logons (e.g., system-initiated) may not appear here and are instead tracked in Microsoft Entra audit logs.

 Key Differences
- Scope:
  - DeviceLogonEvents: Device-centric (local logon activity on the endpoint).
  - IdentityLogonEvents: Identity-centric (authentication against AD or cloud identity services).
- Data Source:
  - DeviceLogonEvents: Defender for Endpoint sensor on the device.
  - IdentityLogonEvents: Defender for Identity (on-prem AD) or Defender for Cloud Apps (cloud).
2. Are there events that will appear in DeviceLogonEvents and not in IdentityLogonEvents, or vice versa?

Yes, there are events unique to each table due to their differing scopes:

 Events in DeviceLogonEvents but not in IdentityLogonEvents
- Local account logons: If a user logs into a device using a local (non-domain) account, this event is captured in DeviceLogonEvents because it happens on the device itself, but it won’t appear in IdentityLogonEvents since it doesn’t involve AD or cloud identity authentication.
- Service or Batch logons on a device: Logons tied to local services or scheduled tasks running under a local or domain account may appear in DeviceLogonEvents if they occur on the endpoint, but they might not be reflected in IdentityLogonEvents unless they trigger a domain authentication.
- Logons on non-domain-joined devices: If a device isn’t part of a domain or monitored by Defender for Identity/Cloud Apps, its logon events will only appear in DeviceLogonEvents.

 Events in IdentityLogonEvents but not in DeviceLogonEvents
- Cloud-only authentications: Interactive sign-ins to Microsoft 365 or other cloud services (e.g., via Microsoft Entra ID) will appear in IdentityLogonEvents but not in DeviceLogonEvents unless the device itself is onboarded to Defender for Endpoint and logs the corresponding local event.
- Domain Controller authentications without device context: Failed or successful domain logons validated by a DC (e.g., Kerberos ticket requests) may appear in IdentityLogonEvents without a corresponding DeviceLogonEvents entry if the device isn’t onboarded to Defender for Endpoint.
- Legacy protocol authentications: Events like ActiveSync logins tracked by Defender for Cloud Apps will appear in IdentityLogonEvents but not in DeviceLogonEvents.

 Overlap
- Events like a domain user logging into a domain-joined device via RDP could appear in both tables:
  - In DeviceLogonEvents as a RemoteInteractive logon on the device.
  - In IdentityLogonEvents as a domain authentication validated by the DC.
3. Are these tables based on Windows logon events? If yes, what is the mapping?

Yes, both tables are indirectly based on Windows logon events, but they aggregate and enrich this data through Microsoft Defender components rather than directly mirroring raw Windows Security event logs.

 Windows Logon Events Background
Windows logs authentication events in the Security event log, with key Event IDs like:
- 4624: Successful logon.
- 4625: Failed logon.
- 4672: Special logon (e.g., privilege assignment).
- 4634/4647: Logoff events.

These events include a Logon Type field (e.g., 2 for Interactive, 3 for Network, 10 for RemoteInteractive) that categorizes the logon.

 Mapping to DeviceLogonEvents
- Source: Derived from Security event logs (e.g., Event ID 4624, 4625) on the device, enriched by Defender for Endpoint telemetry.
- LogonType Column: Maps directly to Windows logon types:
  - Interactive (2): Local console logon.
  - Network (3): Accessing a resource over the network.
  - RemoteInteractive (10): RDP or similar.
  - Service (5), Batch (4), etc., for system accounts or tasks.
- ActionType Column: Adds context like LogonSuccess or LogonFailed, aligning with 4624 or 4625.
- Enrichment: Includes device-specific fields (e.g., DeviceName, InitiatingProcessCommandLine) not present in raw Windows logs.

 Mapping to IdentityLogonEvents
- Source: Derived from Domain Controller logs (e.g., Event ID 4624, 4625) via Defender for Identity, or cloud logs via Defender for Cloud Apps.
- LogonType Column: Also maps to Windows logon types where applicable (e.g., Interactive, Network), but may include cloud-specific types like OAuth or ActiveSync.
- ActionType Column: Reflects authentication outcomes (e.g., LogonSuccess, LogonFailed), with additional identity context.
- Enrichment: Adds AD-specific fields (e.g., AccountUpn, Protocol) or cloud metadata not in raw device logs.

 Key Mapping Notes
- Windows logs are the foundation, but Defender processes and filters them. For example:
  - DeviceLogonEvents might not capture all network logons if they don’t trigger a significant endpoint event.
  - IdentityLogonEvents might miss local device logons not validated by a DC or cloud service.
- The tables don’t replicate raw Event IDs directly; they abstract and categorize the data for hunting purposes.
4. On DeviceLogonEvents, when does the UPN appear in the event?

The User Principal Name (UPN) in DeviceLogonEvents can appear in different fields (AccountName, AdditionalFields, or not at all), and its presence depends on the logon context and how the event is processed. Here’s why:

 Possible UPN Locations
1. AccountName Column:
   - The UPN (e.g., email address removed for privacy reasons) may appear here if the logon explicitly provides it and Defender for Endpoint normalizes it as the primary account identifier.
   - This happens more often with domain accounts where the UPN is readily available and preferred over the SAM account name (e.g., DOMAIN\user).
   - Example: A domain user logs in via RDP, and AccountName shows email address removed for privacy reasons.

2. AdditionalFields Column:
   - The UPN might be nested in this JSON blob (e.g., under a key like AccountUpn) if it’s supplementary data not used as the primary identifier.
   - This occurs when the logon event prioritizes the SAM account name in AccountName, but the UPN is still captured (e.g., from Kerberos or cloud sync metadata).
   - Example: AdditionalFields contains {"AccountUpn": "email address removed for privacy reasons"}.

3. Not Present at All:
   - The UPN may be absent if:
     - The logon uses a local account (no domain context, so no UPN exists).
     - The event lacks sufficient identity metadata (e.g., a service logon with minimal details).
     - The UPN isn’t provided by the authentication protocol or isn’t resolved by Defender for Endpoint.
   - In these cases, AccountName might show a SAM account name (e.g., DOMAIN\user) or even a "weird" username (see below).

 Why "Weird Usernames" Appear in AccountName?
- System Accounts: Names like DWM-1, UMFD-0, or NT AUTHORITY\SYSTEM can appear for system-initiated logons (e.g., Desktop Window Manager or User Mode Font Driver processes). These aren’t tied to a UPN.
- Truncated/Unexpected Formats: If the authentication data is incomplete or uses an older format (e.g., NetBIOS-style DOMAIN\user), it might not resolve to a UPN.
- Service Contexts: Service or batch logons might use identifiers tied to the process rather than a user (e.g., a machine account like DEVICE$).

 When Does UPN Appear?
- Domain Logons: UPN is more likely for domain accounts, especially with modern authentication (e.g., Kerberos, RDP with domain creds).
- Cloud Integration: If the device syncs with Microsoft Entra ID, the UPN might be enriched from cloud identity data.
- Protocol Dependency: Protocols like Kerberos often provide UPNs, while NTLM might default to SAM names unless enriched.

 Inconsistencies Explained
- The variability stems from how Defender for Endpoint processes raw logon data:
  - It prioritizes what’s available in the event (SAM vs. UPN).
  - It may enrich data post-collection (e.g., pulling UPN from AD or cloud sync), but this isn’t guaranteed for every event.
  - Local or system logons lack UPNs by design.