Windows Server 2025
Entra ID-Joined Endpoints
Complete Forensic Artifact Reference

This document is structured as a practitioner reference rather than a tutorial. Each section covers a distinct artifact family in the Server 2025 / Entra ID forensic landscape. Within each section you will find: what the artifact is, where it lives (registry keys, filesystem paths, process-resident locations), what it records at field-level detail, how to collect it with command syntax, event IDs to target, and investigative scenarios where the artifact changes the outcome. All paths and registry keys were verified against Server 2025 (Build 26100) as of March 2025.

Section 1 — The Shifted Forensic Landscape

What Changes When You Move From AD to Entra ID

Traditional Windows Server forensics is built around assumptions stable since Windows 2000: a domain controller to image, Kerberos tickets backed by a local KDC, credentials in NTDS.dit, group policy telemetry pointing to SYSVOL, and the security boundary at the on-premises network perimeter.

Every one of those assumptions breaks on an Entra ID-joined Server 2025 instance. The investigation does not get simpler — it gets bifurcated. Some evidence lives on the server in forms with no traditional equivalent. Other evidence lives in Microsoft's cloud infrastructure and requires Entra audit log collection via the Graph API or a legal preservation request. The analyst who applies a traditional investigation methodology to an Entra-joined server will miss significant evidence classes entirely.

The Evidence Bifurcation Problem

What Disappears Compared to Traditional AD Forensics

Section 2 — Device Join & Identity Artifacts

The Join Record

When a Windows Server 2025 instance joins Entra ID, the join process writes artifacts across multiple locations: the registry, the certificate store, and a device-specific key container. These artifacts collectively constitute the device's identity proof and establish which tenant the device belongs to, when it joined, and whether it has ever belonged to a different tenant.

Device Certificates — The Cryptographic Identity

dsregcmd — The Join Status Diagnostic

# Standard join status — AzureAdJoined, DeviceId, TenantId, JoinType
dsregcmd /status

# Full debug output including PRT status, token state, and NGC key list
dsregcmd /status /debug

# Dump detailed device info including certificate thumbprints and key container paths
dsregcmd /status /verbose

# List all enrolled credentials (useful for WHFB investigation)
dsregcmd /listAdAccounts

# Force a re-join status check and log the result
dsregcmd /refreshprt

Join History Event IDs

Section 3 — Primary Refresh Tokens & WAM

What the Primary Refresh Token Is

The Primary Refresh Token (PRT) is the master credential for an Entra ID-joined device. It functions as the equivalent of a Kerberos TGT in the cloud identity model: a long-lived token (typically 14 days, renewable) that the device uses to silently obtain short-lived access tokens for individual cloud resources without prompting the user to re-authenticate.

Understanding the PRT is fundamental to Entra ID forensics because it is the credential that an attacker steals, forges, or replays in the most significant cloud identity attacks. It is stored in a way that differs fundamentally from every credential artifact a traditional Windows forensics analyst is trained to look for.

How the PRT Is Stored — CloudAP in LSASS

The PRT is not stored in the registry, not stored on disk in a plaintext file, and not in Windows Credential Manager in an accessible form. It is held in memory within the LSASS process, managed by a Security Support Provider (SSP) called CloudAP (Cloud Authentication Provider). CloudAP is a plugin to the Windows LSA that handles all Entra ID authentication flows.

The in-memory PRT blob is protected by a session key derived from the device's TPM (on TPM-equipped servers) or by DPAPI (on non-TPM systems). On TPM-backed systems, the PRT cannot be exported without the TPM's cooperation. On systems without TPM, the protection falls back to DPAPI, which is significantly weaker.

WAM — Web Account Manager Token Broker

The Web Account Manager (WAM) brokers OAuth 2.0 token requests for applications. Every time an application needs an access token for a cloud resource, it requests through WAM rather than directly from Entra. WAM caches the resulting tokens and refresh tokens, creating an artifact store that is the cloud equivalent of the traditional Kerberos ticket cache.

Detecting PRT Theft and Token Replay

Key Event IDs — Authentication & Credential Events

Collection Commands — PRT and WAM Artifacts

# Dump WAM token cache registry keys (run as SYSTEM or elevated user)
reg export "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD\Storage" wam_tokens.reg

# Copy TokenBroker cache files (DPAPI-encrypted)
robocopy "%LOCALAPPDATA%\Microsoft\TokenBroker\Cache" C:\Triage\WAM /E /COPYALL

# Copy CloudAP cache for system account (requires SYSTEM privileges)
robocopy "%SystemRoot%\System32\config\systemprofile\AppData\Local\Microsoft\Windows\CloudAPCache" C:\Triage\CloudAP /E /COPYALL

# Check current PRT status live
dsregcmd /status | findstr /i "PRT"

# AAD Operational log — export authentication events
wevtutil epl "Microsoft-Windows-AAD/Operational" C:\Triage\AAD_Operational.evtx

# User Device Registration log
wevtutil epl "Microsoft-Windows-User Device Registration/Admin" C:\Triage\UDR_Admin.evtx

Section 4 — Entra Kerberos: Cloud-Issued Tickets

Entra Kerberos (formerly Azure AD Kerberos) allows Entra ID to issue Kerberos tickets for on-premises resources — primarily for passwordless authentication scenarios and for accessing on-premises file shares from Entra-joined devices without requiring a line of sight to an on-premises DC. A special Read-Only Domain Controller (RODC) account is created in the on-premises AD forest, and Entra ID uses its keys to issue Kerberos TGTs.

Distinguishing Entra Kerberos Tickets

Traditional Kerberos TGT:
  Realm  = CONTOSO.COM  (your AD domain realm)
  Issuer = CN=CONTOSO-DC01,OU=Domain Controllers,DC=contoso,DC=com
  SPN    = krbtgt/CONTOSO.COM

Entra Kerberos TGT:
  Realm  = CONTOSO.COM  (same realm)
  Issuer = CN=AzureADKerberos,OU=Domain Controllers,DC=contoso,DC=com
  SPN    = krbtgt/CONTOSO.COM
  PAC    = Contains additional Entra-specific claims

Key distinction: The issuer CN is 'AzureADKerberos' rather than a DC hostname.
On a pure Entra-joined server, ALL Kerberos tickets should have this issuer.
Any ticket with a real DC as issuer indicates on-prem DC connectivity occurred.

Examining the Ticket Cache

# List all Kerberos tickets in the current logon session
klist

# List tickets for all logon sessions (requires elevation)
klist sessions
klist -li <LogonId> tickets

# PowerShell: enumerate tickets with full detail including issuer
[System.Security.Principal.WindowsIdentity]::GetCurrent() | Select-Object *

# Rubeus: dump ticket details from memory (document if used in investigation)
Rubeus.exe triage       # list all tickets without dumping
Rubeus.exe dump /nowrap # dump for analysis

Entra Kerberos Event IDs

Section 5 — Conditional Access Enforcement Artifacts

Conditional Access (CA) policies are evaluated and enforced by Entra ID in the cloud — the server itself does not make CA decisions. However, Server 2025 logs the results of CA evaluations in a dedicated event log channel distinct from the traditional Security log. This log records which policies were evaluated, the outcome, and whether any fallbacks or exclusions were applied.

Critical Conditional Access Event IDs

Correlating Server-Side CA Events with Entra Sign-In Logs

The correlation ID present in Event 1006 links server-side CA events with Entra cloud-side sign-in logs. This GUID is consistent across the entire authentication flow — from the initial token request on the server, through Entra evaluation, to the sign-in log entry in the cloud.

# Extract correlation IDs from AAD Operational log for cross-referencing
Get-WinEvent -LogName 'Microsoft-Windows-AAD/Operational' -MaxEvents 500 |
  Where-Object { $_.Id -eq 1006 } |
  ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
      Time          = $_.TimeCreated
      CorrelationId = $xml.Event.EventData.Data |
                      Where-Object {$_.Name -eq 'correlationId'} | Select -Exp '#text'
      Resource      = $xml.Event.EventData.Data |
                      Where-Object {$_.Name -eq 'resource'} | Select -Exp '#text'
      Result        = $xml.Event.EventData.Data |
                      Where-Object {$_.Name -eq 'errorCode'} | Select -Exp '#text'
    }
  } | Export-Csv C:\Triage\CA_Events.csv -NoTypeInformation

Detecting Legacy Authentication Abuse

Legacy authentication protocols — Basic Auth, NTLM to cloud resources, older OAuth flows, SMTP AUTH, IMAP — cannot satisfy MFA challenges and cannot be protected by most Conditional Access policies. On Server 2025, legacy authentication use is traceable through several converging artifacts:

• Event 1064 in AAD Operational — direct record of legacy auth protocol use, with application ID and specific legacy protocol
• Authentication Package = NTLM in Event 4624 — network logons using NTLM to a cloud resource. On a modern Entra-joined server, NTLM to cloud services should be absent
• Absence of MFA claim in WAM token cache — access tokens obtained via legacy auth lack the MFA authentication method claim (amr claim value 'mfa'). Visible in decoded JWT tokens extracted from the WAM cache
• User-Agent strings in Entra sign-in logs — legacy clients identify themselves with older user agent strings. Entra flags these as 'Legacy Authentication Client' in the client app field

Section 6 — Azure Arc: The Second Identity Layer

Azure Arc is Microsoft's hybrid management platform that allows Azure management plane operations — policy assignment, monitoring, patch management, extension installation — to reach on-premises servers. An Arc-enrolled server has its own managed identity in Azure (separate from the Entra device identity) and runs a persistent agent (himds.exe and gc_service.exe) that maintains a live authenticated connection to Azure Resource Manager.

Arc Agent Identity Artifacts

Arc as a Persistence and Lateral Movement Vector

An attacker with Azure RBAC permissions on the Arc resource (Contributor, Owner, or 'Azure Connected Machine Resource Administrator') can execute arbitrary code on the server via Arc extensions without any authentication to the server's operating system.

Arc Investigation Commands

# Check Arc agent status and connection state
azcmagent show

# List all installed Arc extensions
azcmagent extension list

# Export Arc agent logs for the last 72 hours
azcmagent logs --output C:\Triage\arc_logs.zip

# Check which processes are making IMDS calls
netstat -ano | findstr :40342

# Collect extension execution logs
robocopy "C:\Packages\Plugins" C:\Triage\ArcExtensions /E /COPYALL

# Collect Arc agent config for tenant/subscription verification
copy "C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json" C:\Triage\

Section 7 — Cloud LAPS: The Credential That Rotated

Server 2025 introduces Cloud LAPS (Windows LAPS with Azure AD), where the rotating local admin password is stored in Entra ID rather than on-premises AD. Traditional LAPS passwords were readable from a DC's NTDS.dit or LDAP. Cloud LAPS passwords are readable from the Entra portal or via Microsoft Graph API — and the record of who retrieved the password exists only in the Entra audit log, not on the server.

Cloud LAPS Artifacts on the Server

# Microsoft Graph — retrieve LAPS password read audit events for a specific device
GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits
  ?$filter=activityDisplayName eq 'Get local administrator password'
  and targetResources/any(t: t/displayName eq '<ComputerName>')
  &$orderby=activityDateTime desc

# PowerShell equivalent using the Az module
Get-AzureADAuditDirectoryLogs -Filter "activityDisplayName eq 'Get local administrator password'" |
  Where-Object { $_.TargetResources.DisplayName -eq '<ComputerName>' }

LAPS Event IDs

Section 8 — Intune & MDM Compliance

When Server 2025 is enrolled in Intune, the MDM stack operates through Windows' built-in MDM client (DMClient) using the OMA-DM protocol. Configuration is delivered as CSP payloads rather than GPOs, creating a fundamentally different artifact landscape.

MDM Enrollment and Policy Artifacts

MDM Collection Commands

# Generate a full MDM diagnostic report (run elevated)
mdmdiagnosticstool.exe -area deviceenrollment;deviceprovisioning;tpm -zip C:\Triage\MDMDiag.zip

# Export current policy state from PolicyManager registry
reg export "HKLM\SOFTWARE\Microsoft\PolicyManager" C:\Triage\PolicyManager.reg

# View sync log for compliance history
Get-ChildItem "$env:LOCALAPPDATA\Temp\MDMDiagnostics" | Sort LastWriteTime | Select -Last 5

# Check enrollment details
Get-Item "HKLM:\SOFTWARE\Microsoft\Enrollments\*" | Get-ItemProperty

MDM Event IDs

Section 9 — New and Changed Event IDs in Server 2025

Authentication & Identity Events

Entra-Specific Log Channels — Full Reference

The following event log channels are specific to Entra ID functionality and are not present on standalone or traditional domain-joined servers. All require explicit collection — they are not forwarded by default SIEM agents:

Section 10 — Persistence Mechanisms Specific to Entra-Joined Servers

Cloud-Plane Persistence — Evidence Only in Azure/Entra

Traditional Windows Server persistence (startup folders, Run keys, scheduled tasks, services, WMI subscriptions) remains fully applicable. What changes is the addition of cloud-plane persistence mechanisms that have no equivalent in on-premises environments and that leave no trace on the server itself.

Server-Local Persistence — What's New on Server 2025

• WinGet package manager persistence — Server 2025 includes WinGet natively. Malicious packages installable via WinGet with no UI. Logged in AppXDeployment-Server\Operational. Enumerate via winget list
• WSL2 persistence on Server 2025 — WSL2 available on Server 2025. Linux-side persistence (cron jobs, .bashrc, systemd units) leaves no trace in Windows event log. Distribution data at %LOCALAPPDATA%\Packages\<DistroName>\LocalState\ext4.vhdx — requires Linux filesystem tools to examine
• Dev Home / Dev Drive persistence — Dev Drive (ReFS-formatted) can host code executing at logon. Not scanned by some AV configurations by default due to performance trust settings
• DPAPI backup to Entra — Server 2025 supports cloud-backed DPAPI master key storage in Entra. An attacker with Entra admin access can decrypt all DPAPI-protected material offline. Evidence: HKLM\...\CloudDomainJoin\JoinInfo\<DeviceID>\DPAPICloudBackupEnabled = 1

Section 11 — Triage Collection Checklist

# PRT status and token state
dsregcmd /status /debug > C:\Triage\dsregcmd.txt

# Running process list with full paths
Get-Process | Select Name,Id,Path,StartTime | Export-Csv C:\Triage\processes.csv

# Network connections with owning PIDs
netstat -anob > C:\Triage\netstat.txt

# Kerberos ticket cache (all sessions)
klist sessions > C:\Triage\klist_sessions.txt
klist tgt >> C:\Triage\klist_sessions.txt

# Loaded drivers
driverquery /v /fo csv > C:\Triage\drivers.csv

# Arc agent status
azcmagent show > C:\Triage\arc_status.txt
azcmagent extension list >> C:\Triage\arc_status.txt

# LAPS password expiry (NOT the password itself)
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\LAPS\State > C:\Triage\laps_state.txt

$logs = @(
  'Security',
  'System',
  'Application',
  'Microsoft-Windows-AAD/Operational',
  'Microsoft-Windows-User Device Registration/Admin',
  'Microsoft-Windows-LAPS/Operational',
  'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin',
  'Microsoft-Windows-CertificateServicesClient-Lifecycle-User/Operational',
  'Microsoft-Windows-TaskScheduler/Operational',
  'Microsoft-Windows-WinRM/Operational',
  'Microsoft-Windows-PowerShell/Operational',
  'Microsoft-Windows-Sysmon/Operational'
)
foreach ($log in $logs) {
  $safe = $log -replace '[/\\]','_'
  wevtutil epl $log "C:\Triage\Logs\$safe.evtx" 2>$null
}

$hives = @{
  'SYSTEM'   = 'C:\Windows\System32\config\SYSTEM'
  'SOFTWARE' = 'C:\Windows\System32\config\SOFTWARE'
  'SECURITY' = 'C:\Windows\System32\config\SECURITY'
  'SAM'      = 'C:\Windows\System32\config\SAM'
}
foreach ($h in $hives.GetEnumerator()) {
  Copy-Item $h.Value "C:\Triage\Hives\$($h.Key)" -Force
}
# Per-user NTUSER.DAT hives
Get-ChildItem C:\Users | ForEach-Object {
  Copy-Item "$($_.FullName)\NTUSER.DAT" "C:\Triage\Hives\NTUSER_$($_.Name).DAT" -Force 2>$null
}

# CloudAP cache (system account — requires SYSTEM privileges)
robocopy "$env:SystemRoot\System32\config\systemprofile\AppData\Local\Microsoft\Windows\CloudAPCache" C:\Triage\CloudAP /E /COPYALL

# WAM token broker cache
robocopy "$env:LOCALAPPDATA\Microsoft\TokenBroker\Cache" C:\Triage\WAM /E /COPYALL

# Device certificates — export thumbprints and subjects
Get-ChildItem Cert:\LocalMachine\My | Select Subject,Thumbprint,NotBefore,NotAfter |
  Export-Csv C:\Triage\certs_localmachine.csv

# Arc agent identity artifacts
robocopy "C:\ProgramData\AzureConnectedMachineAgent" C:\Triage\ArcAgent /E /COPYALL

# Full MDM diagnostic report
mdmdiagnosticstool.exe -area deviceenrollment;deviceprovisioning;tpm -zip C:\Triage\MDMDiag.zip

# PolicyManager registry export
reg export "HKLM\SOFTWARE\Microsoft\PolicyManager" C:\Triage\PolicyManager.reg

# Intune enrollment details
reg export "HKLM\SOFTWARE\Microsoft\Enrollments" C:\Triage\Enrollments.reg

# LAPS state
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\LAPS" C:\Triage\LAPS.reg

Closing Notes

The artifacts documented here will evolve rapidly as Microsoft develops the Server 2025 platform. Several features — DPAPI cloud backup, Entra Kerberos for all resources, CAE broad support — are in active development and their artifact footprints will change across future Feature Updates. Treat this document as a baseline, validate paths and event IDs against the specific build under investigation, and build institutional memory as new artifacts are discovered in casework.

References

1. Microsoft Learn — Entra ID Joined Devices Overview
2. Microsoft — Primary Refresh Token documentation
3. Microsoft — Windows LAPS (Cloud) documentation
4. Dirk-jan Mollema — AADInternals and Entra ID attack research
5. Dr. Nestori Syynimaa — PRT research and token theft methodology
6. Microsoft Incident Response — Identity playbooks
7. CISA Advisory AA23-347A — Cloud Identity Threat Landscape
8. Lee Holmes — Windows PowerShell security and AMSI integration documentation
9. Azure Arc — Azure Arc documentation
10. SANS FOR508 — Advanced Incident Response covering Azure/Entra identity forensics module