Online, offline, and cached logon: What does signing in mean when the DC is unavailable?

1. Core mechanism

Online password-based domain logon uses DC validation. Successful Kerberos obtains tickets; when Kerberos fails, NTLM pass-through can be used subject to the applicable conditions. “DC-validated” and “Kerberos ticket issued” are therefore different claims. During offline logon, when the DC is unreachable, LSA compares the entered password with the locally stored cached domain credential (verifier); if they match, Windows grants desktop access. The verifier is produced by a one-way transformation and cannot recover the password. CachedLogonsCount controls the cache scope (HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon, REG_SZ, 0–50; the default is 25 on Windows Server 2008 and 10 on other versions; credential type affects how many cache entries each user consumes). A successful offline logon does not provide access to network resources that require DC verification.

Interfaces and specifications

• Cached domain credential (verifier): a local, encrypted, one-way value used only to verify offline logon; it cannot recover the password.
• CachedLogonsCount: the cache limit is 0–50 entries; 0 disables caching. The default is 25 on Windows Server 2008 and 10 on other versions; credential type affects how many entries each user consumes. In the password-user example, a new user can replace the oldest cached entry once the limit is reached.
• Access token: the SID set created after successful logon; offline logon also creates a token, but that token does not represent current DC verification.
• Kerberos ticket cache: existing TGT and service tickets; When DC is missing, new tickets cannot be obtained, but existing tickets in lifetime can be used.
• Evidence surface: 4624 with LogonType 11 (CachedInteractive) in the target Security channel; this indicates that the DC was not contacted. New resource access produces separate evidence.

Online and offline logon

Online password-based domain logon uses DC validation. Successful Kerberos obtains tickets; when Kerberos fails, NTLM pass-through can be used subject to the applicable conditions. “DC-validated” and “Kerberos ticket issued” are therefore different claims. If the DC is unreachable and a suitable cache entry exists, local cached validation can be used. This path issues no new TGT and does not query the current domain account.

When caching is disabled or the user has never been cached, Windows instead displays: "The system cannot log you on now because the domain <DOMAIN> is not available." Offline logon therefore depends on both an existing cache entry and the CachedLogonsCount setting.

What is a cached verifier not?

The cached verifier is not the password; it is a one-way transformation that cannot be reversed. During offline logon, LSA transforms the entered password in the same way and compares the result with the stored verifier.

The critical point is that the local cached verifier is not updated when the password changes in the cloud or domain. The user can therefore continue to log on offline with the old password until the cache is refreshed. A successful cached logon does not show that the account reflects current domain status.

Mixing four separate caches

The statement “I logged on while the DC was unavailable” can conceal several mechanisms. The cached verifier is used for offline logon verification. The current access token identifies an already-created session. Existing Kerberos tickets may have been issued earlier and remain valid for their lifetime. Remote-session caches, such as an open SMB session, are separate.

These four mechanisms are created at different times and have different lifetimes. Observing one does not establish that another is valid; for example, a successful cached logon does not prove that a valid TGT exists.

Artifact: What does LogonType 11 say

The synthetic 4624 instance carries LogonType 11 (CachedInteractive): the user logged on with locally stored domain credentials, and the domain controller was not contacted for authentication.

This record does not prove that the password is current or that the account is active. It also does not show that a resource requiring DC verification was accessed. New domain-validated access produces separate evidence.

State and data flow

1. The user attempts interactive logon with a domain account while the DC is unreachable.
2. LSA compares the entered password with the local cached verifier (one-way comparison).
3. A match creates a local access token; with Audit Logon Success, the target can record 4624 / LogonType 11.
4. Network resources that require DC authentication cannot be accessed; new Kerberos ticket cannot be imported.
5. Resources that do not require DC and existing tickets in lifetime can be accessed.
6. Once the DC is reachable, a successful online logon can refresh the cached verifier. This update does not automatically refresh an old token, ticket or remote session.

2. Exploitation

Broken trust assumption

Broken assumption: "If an offline (cached) logon succeeds, the account is still active and the password is current." The cached verifier does not reflect current domain policy or credential status. Even after a password change in the domain or cloud, the old password may continue to work offline until the local verifier is refreshed; a disabled account may also log on offline until the DC is contacted.

Technical prerequisites

• A device joined to the domain, with a cached verifier for a user who has logged on interactively at least once.
• CachedLogonsCount > 0, meaning that caching is enabled.
• DC is unreachable (network outage, isolated device, intentional isolation).
• For the cache-verification scenario, console or physical access to the device, or access to its file system.

Exploitation mechanism

The cached verifier exists independently of current domain state. After a password change in the cloud or domain, offline logon can continue to accept the old password because the local verifier is not immediately updated. Decisions such as disablement or lockout are evaluated by the DC, so they are not applied immediately while the DC is inaccessible. The verifier is also stored in encrypted form in the registry; someone with file-system access to the device could attempt offline brute-force guessing and may reveal the password if a guess matches. Cached logon itself creates a local desktop session and does not automatically grant access to network resources that require DC verification. Using a recovered password online is a separate authentication attempt that depends on current domain state. This lesson teaches the security mechanism; the product does not extract real passwords or verifiers.

Cache is not current status

The cached verifier is a snapshot of the last successful verification. Later password changes, disablement, or removal of domain access are not reflected immediately in that cache.

Therefore, observing that an offline logon succeeded does not prove that the account is currently valid. A definitive decision requires the current state at the DC.

Limit of influence

A successful cached logon grants local desktop access. Resources requiring DC verification (shares/services requesting new Kerberos tickets) will not be accessible.

Offline brute-force against the cached verifier, on the other hand, requires access to the device file system and is not a direct password disclosure since the verifier is kept encrypted; control is directed towards protecting the disk and privileged account caches.

3. Defense & Detection

Telemetry scope

• Telemetry occurs on the target computer where the session was created; The channel is Security.
• Within the Audit Logon subcategory, Success supports 4624 records carrying LogonType 11 (CachedInteractive).
• Because the DC is not contacted during cached logon, a corresponding DC-side Kerberos event (for example, 4768 or 4769) is not expected; this artifact contains only the cached-logon record on the target.

Events and relevant fields

• 4624 / LogonType 11: logon using a credential stored locally; the DC was not contacted for verification.
• 4624 / TargetUserName and TargetDomainName: although the domain appears as the principal, this record does not prove online verification by the DC.
• 4624 / AuthenticationPackageName: the package name used; in a cached-logon context, it does not show that an online ticket was obtained.
• 4624 / TargetLogonId: session identifier used to correlate related events on the same host.
• Evidence for a separate flow: a target-side 4624 with LogonType 3 records the network logon; if Audit Detailed File Share is enabled, a server-side 5145 records a share-level access check. A DC-side 4769 records the TGS request/result and does not by itself prove successful resource access.

Logon exists, but there is no DC verification

LogonType 11 means “logon with a locally cached credential, without communication with the DC.” There is therefore no corresponding Kerberos event to expect on the DC; its absence is normal.

The review must distinguish cached logon from online logon. The absence of DC-side evidence is not an alert in this case; it is a direct consequence of the mechanism.

New resource access is separate evidence

Separate events occur when the user accesses a resource that requires DC authentication (LogonType 3 4624 on the target or 4769 on DC).

This distinction prevents the error “the user logged on, so they accessed every resource.” Domain-resource access after cached logon must be evaluated using separate evidence.

Detection logic · XPath

*[System[(EventID=4624)] and EventData[Data[@Name='LogonType']='11']]

Query assumptions

• This is an unexecuted candidate filter for Windows Event Log XML fields; it is not a SIEM query or a multi-host correlation.
• LogonType 11 indicates local cached verification only; The absence of a corresponding authentication record in DC is normal and does not mean that the resource is not accessed.
• The result should be classified by examining TargetUserSid, TargetDomainName and Computer together; Access requiring DC must be sought in separate events.
• The fixture parser has not been run; no result on an actual Windows dataset is claimed.

False positives

• Laptop/mobile users normally log on cached (LogonType 11) when off the network; This alone is not bad faith.
• A pre-VPN state or temporary DC unavailability can also produce a legitimate cached logon; this behavior belongs in the benign baseline.
• Negative example: a single record of LogonType 11 does not indicate that the password is current or that the account remains active.

Hardening

• Inventory business requirements and set an appropriate CachedLogonsCount limit; 0 disables caching entirely and blocks offline logon while the DC is unreachable. Evaluate that trade-off against how the devices are used.
• Encrypt device disks (e.g. BitLocker) so that it is difficult to access the cache through physical access to the file system.
• Limit caching of privileged accounts on shared/untrusted devices; Reduce the offline footprint of these accounts.
• Credential Guard isolates supported NTLM hashes, Kerberos TGTs and domain credential material at runtime; it does not protect Kerberos service tickets. The registry cached logon verifier is separate storage/scope. Evaluate CachedLogonsCount, disk encryption, physical access and privileged-account cache exposure for that verifier; do not treat Credential Guard as verifier-at-rest protection.
• After the change, verify offline-logon behavior and cache refresh in a controlled lab; this validation has not yet been performed.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4624</EventID><Version>2</Version><Channel>Security</Channel><Computer>WS10.outreason.example</Computer></System>
  <EventData><Data Name="SubjectUserSid">S-1-5-18</Data><Data Name="TargetUserSid">S-1-5-21-3623811015-3361044348-30300820-1124</Data><Data Name="TargetUserName">tunahan</Data><Data Name="TargetDomainName">OUTREASON</Data><Data Name="TargetLogonId">0xb14d7</Data><Data Name="LogonType">11</Data><Data Name="LogonProcessName">User32</Data><Data Name="AuthenticationPackageName">Negotiate</Data><Data Name="WorkstationName">WS10</Data><Data Name="IpAddress">-</Data><Data Name="KeyLength">0</Data></EventData>
</Event>

Two reality checks

Assumption: If your cached (offline) logon is successful, the account is active and the password is up to date.

In fact: The cached verifier does not reflect current domain status. Even after a password change in the domain or cloud, the old password may work offline until the local verifier is refreshed; a disabled account may also log on offline until the DC is contacted. LogonType 11 indicates local verification only.

Assumption: If I can log on while the DC is unavailable, I can also access domain resources.

In fact: Cached logon only gives local desktop access. Network resources that require DC verification cannot be accessed (new Kerberos tickets cannot be obtained). Only resources that do not require DC and existing tickets in the lifetime can be used.

Sources

• Microsoft · Cached domain logon information (KB172931)
  Summary and More information: cached-logon messages, the distinction between resources that do and do not require a DC, CachedLogonsCount registry location/type/range, and the verifier not being updated after a password change. The current Policy CSP supplies the numeric default for the Windows Server 2008 exception.
• Microsoft · Interactive logon: Number of previous logons to cache (in case domain controller is not available)
  Reference, Possible values, Vulnerability, and Countermeasure: eviction in the password-user example when the limit is reached, the file-system/brute-force risk, Windows encryption and registry protection, and the effect of value 0. Default values lists 10 on versions other than Windows Server 2008.
• Microsoft · Policy CSP - LocalPoliciesSecurityOptions
  InteractiveLogon_NumberOfPreviousLogonsToCache: maximum 50 entries, credential-dependent entry use, and default values (Windows Server 2008: 25; all other versions: 10).
• Microsoft · Passwords technical overview
  Cached credentials: verifier is computed from the NT hash and user name using MD4; one-way function definition is documented above.
• Microsoft · 4624(S) An account was successfully logged on
  Logon types table: Type 11 CachedInteractive definition ("domain controller wasn't contacted to verify the credentials") and Field Descriptions.
• Microsoft · Kerberos authentication overview
  Introduction: TGT/service-ticket model, ticket issuance by the DC (KDC), and use of existing tickets within their lifetime.
• Microsoft · 5145(S, F) A network share object was checked to see whether client can be granted desired access
  Event Description and Important note: share-level access checks, with the failure-event limitation when access is denied at the NTFS level.
• Microsoft · Access tokens
  Access-token overview: after successful authentication at logon, Windows produces an access token that identifies the user/process security context.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Event Description: generated when a KDC receives a TGS request; event records request result, not target-service acceptance.