In digital forensics and incident response, auditing account usage through Windows Security event logs is one of the most foundational and widely used analytical techniques. Correlating successful logon and logoff events with other artifacts—such as process creation (4688), file/registry modifications, network connections, and prefetch artifacts—establishes robust temporal and behavioral timelines of user (or intruder) activity on a system.
Auditing Logon Events
Reviewing successful logons across an enterprise environment is particularly valuable when credential compromise is suspected, enabling investigators to map lateral movement, identify accessed resources, and reconstruct the attacker’s footprint. Remote interactive and network logons (Logon Types 2, 3, 7, 10, etc.) yield critical profiling data on traversal paths, authentication attempts, and anomalous access patterns.
With the introduction of Windows Server 2008 and Vista, Microsoft consolidated the previously fragmented logon event schema—Windows XP/2003 utilized approximately two dozen distinct Event IDs (primarily within the 528–552 range)—into a more streamlined set. The predominant pair is 4624 (An account was successfully logged on) and 4634 (An account was logged off), which together delineate the full duration of a user session. However, 4634 events are not generated with perfect consistency, particularly in cases of abrupt termination, crashes, or certain non-interactive sessions; analysts should therefore also examine 4647 (User-initiated logoff) for interactive and remote interactive logons.
Event ID 4625 documents failed logon attempts and is indispensable for identifying brute-force, password-spraying, or credential-guessing campaigns. When explicit credentials are supplied (distinct from the currently logged-on context), 4648 is recorded—commonly observed during runas executions, elevation of privileges, or applications launched under alternate administrative accounts. Event ID 4672 (Special privileges assigned to new logon) frequently accompanies 4624 in administrative sessions, signaling the assignment of elevated tokens. Account lifecycle events include 4720 (A user account was created) and 4726 (A user account was deleted).
These Event IDs are generated under both Success and Failure audit subcategories within the Logon/Logoff and Account Management policy areas, providing strong justification for enabling comprehensive auditing. It is important to note that sophisticated remote exploits—such as those leveraging remote code execution, service manipulation, or injected backdoors—may circumvent standard logon APIs entirely, resulting in the absence of 4624 events. Nevertheless, true “fileless” or purely memory-resident remote access remains comparatively rare in practice. Most real-world compromise scenarios involving lateral movement, tool deployment, or persistence still require administrative context or credential usage, thereby generating detectable logging artifacts that, when properly aggregated and analyzed, significantly aid attribution and timeline reconstruction.
When conducting forensic analysis of account usage, examiners should prioritize five primary fields within the event record. Initial context derives from the header/footer information: the TimeCreated (timestamp) establishes the precise date and time of the logon activity, forming the foundation for timeline reconstruction. The Computer field identifies the hostname of the system that generated the event—critical when aggregating and correlating logs from multiple hosts to detect lateral movement patterns or usage patterns. The Event ID categorizes the activity; here, 4624 denotes a successful logon. For comprehensive Event ID references and detailed field interpretations, consult authoritative sources such as the Ultimate Windows Security Encyclopedia.
Deeper insights reside in the Event Description (detailed XML data). The Target Account Name (or New Logon → Account Name) identifies the specific account authenticated—in this example, “user01”. The Logon Type field, while sometimes overlooked, is critical to accurate reconstruction of account activity, as modern Windows authentication supports numerous distinct logon vectors. Establishing merely that an account authenticated successfully at 12:06:29 PM on 3/18/2019 is insufficient for forensic purposes; the examiner must also determine the authentication vector—interactive console access, network-based authentication (e.g., via SMB), or Remote Desktop Protocol—to accurately reconstruct attacker techniques, tools, and procedures (TTPs). Here, Logon Type 9 indicates a NewCredentials logon, characteristic of processes invoked under alternate credentials without terminating the originating session (e.g., via RunAs /netonly).
Forensic best practice dictates that no single event should be analyzed in isolation. Following extraction of details from a 4624 record, investigators must examine temporally proximate events, correlated Logon IDs / Logon GUIDs, matching 4634 (account logged off) or 4647 (user-initiated logoff) entries, and associated artifacts (e.g., 4672 privilege assignments, process creations, and network connections) to fully delineate session boundaries and activity.
While the previously highlighted fields form the core of account usage analysis, every Security event record contains supplementary metadata that further contextualizes the activity and supports deeper forensic attribution. These elements are fully accessible via the Event Properties dialog in Event Viewer (detailed view) and are natively stored in a well-formed XML structure. This enables efficient parsing, automated extraction, and correlation at scale using tools such as PowerShell (Get-WinEvent), XML querying, or enterprise SIEM/log management platforms. The available fields include:
- Logged (TimeCreated): The timestamp denoting when the event was generated, recorded in the local system time of the generating host. For multi-system timelines, conversion to UTC and normalization are essential.
- Level: Indicates the event classification (typically Information, Warning, Error, or Critical) and, in some contexts, implies operational severity or audit outcome.
- User: Identifies the security principal (account) that triggered or is directly associated with the event. In Security logs, this often reflects the Subject or Target account context.
- Computer: The hostname of the system on which the event was recorded. This field is indispensable during enterprise log aggregation for identifying logon patterns, lateral movement, and source/destination relationships across disparate systems.
- Source: The originating application, service, or Microsoft component responsible for logging the event (e.g., Microsoft-Windows-Security-Auditing).
- Task Category: The high-level categorization of the event, governed by the configured audit policy. In Security logs, this aligns with categories such as Logon/Logoff, Account Management, or Object Access.
- Event ID: A unique numeric identifier assigned to specific system behaviors. When paired with a reliable reference (e.g., Ultimate Windows Security Encyclopedia), this serves as one of the most actionable indicators for rapid triage and threat hunting.
- General Description: A templated textual summary of the event, often populated with dynamic details such as account names, remote IP addresses, workstation names, process information, or authentication packages. While generic descriptions can occasionally lack depth, they may on occasion yield evidentiary value—including remote IP addresses, hostnames, and related indicators critical for reconstructing attacker actions.
- Details (XML / EventData): Contains the full raw, structured payload—including all EventData fields, binary data, or error codes. This section provides the highest fidelity for forensic analysis and scripting.
Collectively, these elements transform isolated log entries into interconnected evidentiary threads, enabling precise timeline construction, behavioral profiling, and correlation with host-based artifacts in comprehensive digital forensic examinations.
Logon Type Codes
Properly contextualized, logon events furnish granular, actionable intelligence regarding the precise nature and vector of account authentication. Beyond basic attributes such as timestamp, target username, hostname, and success/failure status, examiners can extract dispositive details regarding the Logon Type, which reveals the underlying access mechanism. This field appears within the structured EventData section of 4624 (and cognate) events and is indispensable for distinguishing legitimate activity from adversary tradecraft.
Logon Type analysis enables investigators to differentiate “hands-on-keyboard” console access from remote network-mediated sessions (e.g., SMB file share access, RPC invocation, or PsExec-style lateral movement); Remote Desktop Protocol (RDP) connections; batch/service-driven operations; and credential delegation scenarios. It further enables differentiation between interactive user sessions and non-interactive system processes such as scheduled tasks or service startups—facilitating accurate attribution, timeline reconstruction, and identification of anomalous authentication patterns indicative of compromise. The standard Logon Type codes (as recorded in Windows Security events) are as follows:
- 2 – Interactive: Console-based logon via local keyboard, mouse, or virtual console (inclusive of certain KVM or hypervisor console sessions).
- 3 – Network: Network-mediated authentication, commonly associated with SMB share mapping, RPC calls, or RDP sessions in which Network Level Authentication (NLA) is enforced (the initial NLA handshake is logged as Type 3 prior to session establishment).
- 4 – Batch: Non-interactive execution of batch processes (e.g., Scheduled Task invocation).
- 5 – Service: Authentication initiated by the Service Control Manager incident to service startup (typically non-interactive).
- 7 – Unlock: Workstation screen unlock or resumption of an existing session.
- 8 – NetworkCleartext: Network authentication in which credentials are transmitted in cleartext (uncommon in contemporary environments; may signal legacy protocol usage, IIS Basic Authentication, or a protocol-downgrade condition warranting further scrutiny).
- 9 – NewCredentials: Explicit credential delegation, typically invoked via
runas /netonlyor analogous mechanisms that clone the existing token for local session use while presenting alternate credentials to outbound network resources. - 10 – RemoteInteractive: Remote desktop logon via RDP, Terminal Services, or functional equivalent (absent NLA enforcement in certain configurations).
- 11 – CachedInteractive: Logon via cached domain credentials when the domain controller is unreachable (frequently observed on mobile endpoints or in disconnected/offline states).
- 12 – CachedRemoteInteractive: Cached-credential variant of remote interactive authentication
- 13 – CachedUnlock: Cached-credential variant of workstation unlock.
Accurate mapping and contextual interpretation of Logon Type—considered in conjunction with correlating fields such as Source Network Address, Authentication Package, and Process Name—substantially enhances the evidentiary value of 4624 events and enables higher-fidelity reconstruction of adversary behavior during the course of an investigation.
Each authenticated session is assigned a unique Logon ID at the moment of successful authentication (Event ID 4624). This hexadecimal identifier functions as a critical correlation key for reconstructing user activity within a discrete session. Forensic examiners routinely leverage Logon ID values to establish session duration—whether for profiling legitimate account usage, quantifying dwell time during intrusion investigations, or supporting internal inquiries such as timekeeping discrepancies.
By pairing a 4624 (successful logon) with its terminating 4647 (user-initiated logoff)—or, absent that, a 4634 (system-initiated logoff) event that shares the identical Logon ID, analysts can precisely calculate the temporal span of the session. In the illustrated example below, authentication occurred at 13:11:38 and the subsequent user-initiated logoff at 08:12:10 the following day, yielding an approximate session duration of 19 hours.
Session-duration analysis is most probative for interactive logon types (2, 10, 11, and 12). Non-interactive types—such as Network (Type 3) and Service (Type 5)—typically generate short-lived sessions and are poor proxies for actual user presence. For instance, opening a file from a remote share produces a brief Type 3 logon/logoff pair even while the document remains open; subsequent save operations may spawn additional discrete Type 3 sessions.
Beyond duration calculation, the Logon ID enables linkage of ancillary events within the same session, including privilege assignment (4672), process creation and termination, object access auditing, and screen lock/unlock activity (recorded both as Type 7 4624/4634 pairs and as dedicated 4800/4801 events). Windows 10 and later introduced the Linked Logon ID field, which associates the current session with any related authentication context. Administrative logons commonly generate dual sessions (one elevated, one standard-privilege); non-elevated sessions typically display a zeroed Linked Logon ID.
Examiners should also note Microsoft (cloud) accounts may appear under two interchangeable identifiers—the online alias and a local account name—requiring dual filtering during analysis. These identities are increasingly prevalent on modern Windows endpoints and map online addresses (e.g., fred.rocba@outlook.com) to a corresponding local-style account name (e.g., fredr as seen in the paired 4647 event). Because Windows event records may reference either representation interchangeably, investigators must account for both forms when constructing filters or correlation queries. Corresponding Event IDs on Windows XP/2003 platforms include 528 (successful logon), 538 (logoff), and 551 (user-initiated logoff).
Auditing Brute-Force Attacks
Event log analysis also serves as a primary means of detecting and characterizing authentication-based attacks. In the above figure, examination of the Security log reveals a high volume of 4625 events (An account failed to log on), the modern successor to legacy XP/2003 Event ID 529. Detailed review of the event properties demonstrates that the failures span numerous distinct account names, occur exclusively via network authentication (Logon Type 3), and are generated within seconds of one another. The extreme request rate—exceeding 5,250 attempts per hour and ultimately totaling millions of failed logons—is characteristic of automated tooling rather than interactive human activity. Although Logon Type 3 is most frequently associated with SMB/CIFS network resource access, the same type is also generated by Remote Desktop Protocol (RDP) sessions when Network Level Authentication (NLA) is enabled. Given the observed volume, targeting patterns, and failure codes, the activity depicted here is consistent with an automated RDP password-spray or brute-force campaign.
Beginning with Windows Server 2003, both the source hostname and IP address are recorded within the event, providing valuable dual-source attribution. In this case, the hostname values appear to rotate while the originating IP address remains largely static (although concurrent attacks from multiple unrelated sources, or botnet-driven IP rotation, are also commonly observed).
The Status and Sub Status failure codes supply critical diagnostic context for each denied request. Code 0xC0000064 indicates an unknown or non-existent user account, whereas C000006A indicates a valid account (e.g., ADMINISTRATOR) targeted with an incorrect password. Microsoft has published the full set of status codes, which can be found here.
Built-in Accounts
When examining Windows Security event logs, investigators frequently encounter account names that do not correspond to conventional end-user account identities. By architectural design, every executing process or service under the Windows security subsystem must execute under a security principal possessing defined privileges. Because a substantial subset of Windows processes initialize prior to interactive user authentication (i.e., during boot sequencing) or execute as background maintenance tasks absent explicit user invocation, the operating system provisions a taxonomy of built-in service accounts to furnish differentiated security contexts.
- SYSTEM: Prior to Windows Server 2003, this was the principal account for non-interactive system activity. Its near-omnipotent privilege set posed significant risk exposure since compromise of any SYSTEM-context process yielded an attacker full system authority. Under the Trustworthy Computing Initiative, Microsoft subsequently introduced constrained accounts aligned with least-privilege principles.
- LOCAL SERVICE: A minimally privileged account comparable to a standard user account. Services assigned to this context cannot authenticate to network resources and are restricted to null-session communications.
- NETWORK SERVICE: Functionally similar to LOCAL SERVICE but with elevated permission to impersonate the computer account for network authentication, assigned to services requiring outbound network access.
- Computer Accounts (hostname$): Every domain-joined host is provisioned a machine account (denoted by a trailing "$"). This account authenticates the machine itself to Active Directory and is used when the system accesses domain or network resources.
- DWM- and UMFD-related Accounts: These built-in accounts (associated with the Desktop Window Manager and User-Mode Font Driver, respectively) have limited public documentation. They appear with increasing frequency in modern Windows logs and are related to graphical and font-rendering subsystems.
- ANONYMOUS LOGON: Frequently misunderstood. Originally designed to permit inter-system communication without explicit credentials (null sessions), it historically allowed enumeration of accounts, shares, registry keys, and security policy. Subsequent Windows versions (beginning with XP/2003) have progressively restricted these capabilities by default. Nevertheless, Anonymous Logon continues to appear legitimately in support of file and print sharing, network browse-list maintenance, and certain legacy protocols. Observation of this account should not, by itself, be interpreted as evidence of reconnaissance; additional contextual analysis is required.
Built-in and service-account activity typically generates far higher volumes of logon events than interactive user sessions and may utilize multiple Logon Types (including 2, 3, and 5). Because forensic analysis is ordinarily focused on human-driven activity, systematic filtering of these system accounts is a standard practice that reduces noise and improves visibility into genuine user behavior.
Auditing Priviledged Account Activity
Surveillance of privileged-account telemetry constitutes a high-yield vector for anomaly detection during incident response engagements. At some inflection point within the intrusion lifecycle, the threat actor must necessarily escalate to an administrative-equivalent security context to facilitate credential harvesting operations and effectuate lateral movement across the enterprise attack surface. Consequently, rigorous auditing of these accounts represents a critical detection chokepoint capable of surfacing even sophisticated, evasive adversaries.
When a security principal possessing administrator-equivalent privileges successfully authenticates, Windows generates Event ID 4672 (“Special privileges assigned to new logon”) within the Security event log, the modern successor to legacy XP/2003 Event ID 576. Notably, full local-administrator group membership is not a strict prerequisite for this event's generation; the assignment of any single high-impact privilege—such as SeTakeOwnershipPrivilege, SeDebugPrivilege, or SeImpersonatePrivilege—constitutes admin-equivalent capability sufficient to trigger the "special logon" designation.
In the figure above, an Event ID 4624 (successful logon) is observed in immediate temporal adjacency to an Event ID 4672, confirming that the account rsydow-a received administrator-equivalent privileges. The temporal pairing of these two Event IDs constitutes the evidentiary standard required to substantiate privileged-account logon activity (alternatively, residual privilege assignments may be validated through examination of the local SAM database or Active Directory attributes, provided the account still exists).
This event is especially significant on systems where administrative logons are infrequent, serving as a high-fidelity indicator of potentially unauthorized elevated access. It is also valuable for identifying highly privileged service accounts—supporting account auditing, credential-rotation planning, and detection of compromised service accounts. Scheduled tasks configured to run with administrative or “highest available” privileges will likewise generate 4672 events.
As with most high-value Event IDs, 4672 activity is accompanied by substantial background noise. Local SYSTEM account operations and domain machine-account authentications routinely produce these records in Active Directory environments. Effective analysis therefore requires systematic filtering of known legitimate privileged contexts to isolate anomalous or unexpected elevated sessions.
Auditing Account Creation Artifacts
Upon attaining administrator-equivalent privileges, a threat actor may readily provision supplementary security principals. Local administrators can create local accounts, while Domain Admins (or equivalently privileged principals) can provision domain accounts of nearly any type. Although comparatively less prevalent in contemporary intrusion methodology owing to the ascendancy of pass-the-hash and Kerberos ticket-based attack vectors, rogue-account provisioning remains a viable technique for auditing evasion and the establishment of dormant "sleeper" accounts reserved for contingency access during remediation efforts.
Fortuitously, detection of account-provisioning activity is readily achievable through rigorous auditing of account-management event telemetry. Event ID 4720 (the modern successor to legacy XP/2003 Event ID 624) is logged upon account creation, yielding timestamp, host, authorizing principal, and account attribute metadata—this event ID applies uniformly to both local and domain-scoped account creations. In the figure below, a local account named “root” was created under the credentials of the account “rsydow-a”.
A solitary event ID 4720 does not disclose the privilege level of the newly created account, however, correlation with a contemporaneous Event ID 4732 (“A member was added to a security-enabled local group”) reveals the target group—e.g., "Administrators"—to which the account was elevated. Parallel group-membership events for global and universal groups provide equivalent insight in domain environments. Complementary Account Management Event IDs of high forensic value include:
- 4722 – A user account was enabled
- 4724 – An attempt was made to reset an account’s password
- 4728 – A member was added to a security-enabled global group
- 4732 – A member was added to a security-enabled local group
- 4735 – A security-enabled local group was changed
- 4738 – A user account was changed
- 4756 – A member was added to a security-enabled universal group
Auditing RDP Activity
Beyond the canonical logon event ID taxonomy, a discrete subset of specialized event identifiers provides targeted visibility into Remote Desktop Protocol (RDP) activity. Given RDP's pervasive deployment across enterprise infrastructures, it correspondingly constitutes an attractive vector for adversarial exploitation. The rationale is self-evident: deployment of sophisticated backdoor implants becomes largely superfluous when compromised Domain Administrator credentials afford unfettered remote access across the entirety of the Active Directory forest (a risk theoretically mitigable via Group Policy restriction, though such hardening is inconsistently implemented in practice).
When reconstructing an evidentiary timeline of RDP connection activity, two event identifiers yield substantial forensic value: Event ID 4778, denoting RDP session reconnection, and Event ID 4779, denoting remote session disconnection (the modern successor to legacy XP/2003 Event IDs 682 and 683, respectively). When examined in tandem, these events help delimit RDP session boundaries. However, the analyst must recognize that this event pair does not furnish an exhaustive historical record of every RDP connection instantiated. Their design intent centers on capturing session reconnection events rather than de novo session establishment, and thus they represent only a partial slice of overall RDP activity. This limitation nonetheless confers an analytical advantage: RDP session reconnects are frequently logged as Event ID 4624 Logon Type 7 (conventionally attributed to workstation lock/unlock cycles rather than the "canonical" Type 10 RDP logon classification). An analyst whose triage methodology is confined exclusively to EID 4624 Logon Type 10 events risks overlooking session-reconnect activity entirely — activity that becomes discoverable through correlation with EID 4778/4779.
A further analytical benefit of Event IDs 4778 and 4779 lies in their inclusion of both the source IP address and hostname of the connecting client—information that is frequently more accurate than the hostname recorded in accompanying 4624 events, which may reflect an intermediary system rather than the originating endpoint. Corroborating this correlation, a near-contemporaneous Event ID 4624 (successful logon) should be anticipated, since 4778 confirms only that a remote session reconnection succeeded, while 4624 confirms that the supplied credentials were validated. An analogous relationship exists between Event ID 4779 and Event ID 4647 (or 4634) logoff event.
Reinforcing this principle of contextual event clustering, workstation logs will frequently exhibit an Event ID 4779 (session disconnection) immediately preceding an Event ID 4778 (session reconnection)—a consequence of the single-interactive-session architectural constraint on Windows workstations. When an RDP connection targets a system with an active console session, that console session must first be disconnected to accommodate the incoming remote session. The analyst should further note that not every 4778/4779 pairing is attributable to RDP usage per se; Windows also leverages this event pair to record Windows-station transitions arising from the "Fast User Switching" feature, in which case the session name field will register as "Console".
Depending on client-side termination behavior (formal logout versus mere client-window closure), reconnect/disconnect event pairs may not manifest for every RDP access instance. 4624 events spanning Logon Types 3, 7, and 10 consequently remain the most comprehensive view of RDP-related authentication and should be cross-referenced with the auxiliary event logs Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational and Microsoft-Windows-TerminalServices-RdpClient/Operational, co-located within the standard event log directory structure. Event ID 131 within the RDPCoreTS log, alongside Event IDs 1024 and 1102 within the TerminalServices-RdpClient log, records outbound RDP connection attempts, inclusive of destination hostname and IP address metadata.
This example illustrates a successful Remote Desktop Protocol (RDP) session reconnection to an existing, unterminated session. Examination of the tabular rendering of the Security Event Log reveals a dense cluster of correlated activity occurring within seconds. The successful logon event (4624) records authentication of the account rsydow under Logon Type 7—a code typically associated with system lock/unlock operations. This attribution is corroborated by the immediately preceding EID 4801 event (“The workstation was unlocked”), which explicitly confirms a "system unlock" condition.
Notably, however, preceding the logon event is a session reconnection event (EID 4778) attributed to the identical user principal (rsydow). This event proves evidentially critical, as it furnishes the terminal contextual element required to reconstruct the complete activity pattern. The session-name field associated with the EID 4778 event registers as "RDP-Tcp#19" — a strong forensic indicator of an underlying RDP connection. The reconstructed sequence indicates that an unterminated, orphaned RDP session belonging to rsydow persisted on the host system. Upon the user's subsequent re-authentication via the RDP protocol, this dormant session was simply reattached to that existing session rather than freshly instantiated. Consequently, this activity was logged under Logon Type 7 rather than the anticipated Logon Type 10 (the canonical RDP logon classification). It bears noting that Logon Type 3 has likewise become a commonly observed substitute for Logon Type 10 in contemporary environments, owing to the default enablement of RDP Network Level Authentication (NLA)—a security control that mandates network-layer credential validation prior to RDP server session establishment.
The practical implication is unambiguous: an analyst cannot rely exclusively on filtering for EID 4624 Logon Type 10 events to achieve comprehensive detection of RDP activity on a given host. This example thus serves as a compelling demonstration of the evidentiary value derived from multi-event correlation in reconstructing a complete activity narrative. It further bears emphasis that these event artifacts are logged exclusively on the receiving (destination) system—the originating system will not generate corresponding entries, necessitating recourse to alternative artifacts, such as the TerminalServices-RDPClient log, to establish activity on the initiating endpoint.
It further warrants observation that, within this example, the Logon ID field fails to correlate between the EID 4624 and its corresponding EID 4778 event. This discrepancy arises because 4778/4779 session reconnect/disconnect events inherit the Logon ID of the earliest non-terminated interactive session attributable to that same user principal—typically the interactive session initiated after that account's most recent EID 4647 (user-initiated logoff) event. In this case, an earlier session predates the observed activity, accounting for the Logon ID mismatch.
Fortunately, Windows systems beginning with Vista/Server 2008 incorporate a rich set of supplementary "custom" (Applications and Services) event logs. These specialized log channels characteristically capture a narrower, more granular scope of discrete actions and, consequently, exhibit substantially extended retention horizons relative to the Security, System, or Application logs. For reasons not fully elucidated in available documentation, the Remote Desktop Services architecture maintains multiple such discrete log channels, frequently containing redundant or overlapping evidentiary information. As any seasoned incident responder will attest, evidentiary redundancy is invariably preferable to evidentiary scarcity—the possibility that one or more log sources may be absent, corrupted, or subject to abbreviated retention policies underscores the forensic value of cross-referencing multiple artifacts. Given that the Security log frequently fails to retain sufficient historical depth, the supplementary "custom" logs furnished by the RDP subsystem routinely serve to close these evidentiary gaps.
While a considerable degree of informational redundancy exists across these auxiliary logs, the Microsoft-Windows-TerminalServices-RDPClient/Operational log constitutes a notable exception of outsized forensic significance. Critically, this log's telemetry is recorded on the source (initiating) system rather than the destination and documents outbound RDP connection attempts, including destination hostnames and IP addresses. This is a departure from the conventional Windows logging paradigm, wherein event artifacts are characteristically generated at the destination of an activity rather than its point of origin. Such source-side visibility is uncommon in Windows auditing, which predominantly records activity at the destination. This atypical vantage point renders the log invaluable for reconstructing lateral movement trajectories—specifically, enumerating every downstream system to which an adversary pivoted from the host in question. Owing to this distinctive evidentiary property, the RDPClient/Operational log has rapidly become a preferred artifact within the incident response community. The SANS "Hunt Evil" poster provides a well-curated enumeration of the pertinent event IDs warranting analytical attention within this log.
Auditing Account Logon Events
A persistent source of confusion in Windows audit policy design and event log analysis is the distinction between Logon Events and Account Logon Events—a conflation attributable in large part to Microsoft's suboptimal nomenclature choices. Logon Events record authentication and session activity that occurs on the system being accessed (the destination host). These events (most notably 4624, 4634, 4647, and related IDs) are therefore written to the local Security log of that endpoint. Account Logon Events, by contrast, document the third-party validation of credentials presented during the authentication process.
Within a Windows domain topology, the great majority of user accounts are domain accounts whose authoritative credential store resides on domain controllers rather than on the local workstation. Consequently, before a domain user can successfully log on to a workstation, the domain controller must validate the supplied username and password (or ticket) using either the NTLM or Kerberos authentication protocol. The resulting Account Logon Events are recorded on the domain controller that performed the validation. A single interactive logon can therefore generate multiple related records distributed across systems: Logon Events (4624, 4634, etc.) on the workstation and Account Logon Events (primarily 4776 for NTLM, or 4768/4769/4771 for Kerberos, the modern successor to legacy XP/2003 event IDs 672, 673, 675, and 680) on the domain controller.
One crucial exception to this bifurcated model warrants attention: where authentication proceeds via a local account—a security principal provisioned exclusively on the workstation itself and outside any domain namespace—the workstation itself performs the final credential validation autonomously via the local SAM database, and both Logon Events and Account Logon Events will consequently be co-located within that workstation's local Security event logs. Given the comparative rarity of local-account authentication within enterprise domain environments, this pattern constitutes a noteworthy forensic artifact, potentially indicative of rogue or unauthorized accounts provisioned on the local system.
As two discrete authentication protocols exist, the corresponding Event ID taxonomy bifurcates accordingly:
- NTLM-mediated authentication: Both successful and failed authentications are recorded under Event ID 4776.
- Kerberos authentication: Generates several protocol-specific Event IDs, the most frequently encountered being 4768 (successful Ticket-Granting Ticket request), 4771 (failed pre-authentication), and 4769 (successful service-ticket request, commonly associated with access to resources such as file shares).
Effective with the Windows Server 2003 release, Kerberos supplanted NTLM as the default authentication protocol within a Windows Domain topology, functioning as the standard mechanism on all Windows versions postdating Windows 2000. Relative to NTLM's streamlined three-way handshake, Kerberos employs a more elaborate multi-stage exchange, generating a correspondingly richer set of Account Logon Events.
Protocol Mechanics: The authenticating principal first submits credentials to an authentication server (typically a domain controller) for verification; upon successful validation, a Ticket Granting Ticket (TGT) is issued with a defined validity period, functioning as a portable credential enabling subsequent authentication against other domain controllers without repeated credential resubmission. Resource-specific access—e.g., to a file server—necessitates a discrete "Service Ticket" request.
Failure of Kerberos pre-authentication results in the generation of Event ID 4771 (the modern successor to legacy XP/2003 Event ID 675) on the authenticating domain controller. In addition to standard fields—timestamp, hostname, client IP address, and supplied username—the event includes a hexadecimal Error Code that identifies the precise cause of the failure. More than forty distinct codes are defined; the most frequently encountered in forensic examinations include:
- 0x6 – Invalid/nonexistent account. May also arise from Active Directory replication latency.
- 0x7 – Requested server not found. Likewise potentially attributable to replication issues.
- 0xC – Policy-based logon restriction (logon hours, workstation restrictions, or other Group Policy constraints).
- 0x12 – Account locked out, disabled, or expired.
- 0x17 – Password has expired.
- 0x18 – Pre-authentication information was invalid (incorrect password).
- 0x25 – Clock skew between the client and the Key Distribution Center exceeds the maximum allowable tolerance (Kerberos relies on synchronized time to enforce ticket lifetimes).
Although Kerberos is the default authentication protocol in modern Windows domain environments, NTLM authentication continues to occur under specific conditions. Local account logons, for example, are typically validated via NTLM and recorded on the host itself. Additionally, many pass-the-hash techniques rely exclusively on NTLM authentication mechanics, rendering systematic monitoring of NTLM authentication events a high-value detection surface. Such authentication activity is captured under Event ID 4776 (“The computer attempted to validate the credentials for an account”), the modern successor to legacy XP/2003 Event ID 680.
When a 4776 event records a failure, an associated error (status) code is generated and embedded within the Event Description field. These codes supply precise diagnostic context regarding the reason authentication was denied and can yield significant investigative insight, often illuminating probable adversarial or user-initiated conduct. For instance, repeated account lockout codes may indicate password-guessing activity (or overly stringent organizational password policy enforcement), while attempts originating from restricted workstations (status 0xC0000070) may be indicative of an adversary's attempt to access resources outside the scope of legitimate user authorization or may reflect broader network enumeration activity. The same status code taxonomy is employed by Event ID 4625 (failed logon). Selected high-value status codes include:
- 0xC0000064 – User name does not exist
- 0xC000006A – Incorrect password (user name is valid)
- 0xC000006F – Account logon time restriction violation
- 0xC0000070 – Account not permitted to log on from this computer
- 0xC0000071 – Password has expired
- 0xC0000072 – Account is disabled
- 0xC0000193 – Account has expired
- 0xC0000234 – Account is locked out
Privileged Local Account Abuse – (Pass the Hash)
Leveraging the distinctions between Account Logon and Logon Events, the following scenario demonstrates the relative ease with which a potential rogue local account can be identified through targeted event log analysis. Predicated on the reasonable operational assumption that local accounts — particularly those possessing privileged scope — are not routinely used for authentication within a properly governed enterprise environment, the presence of such authentication events should register as a statistical outlier warranting further scrutiny.
In the above example, filtering the Security log for Event ID 4776 (NTLM credential validation) surfaces a successful authentication recorded at 18:34:17 on 6/2/2021 on the host base-wkstn-09. Examination of the event details reveals an Audit Success classification, with the authenticating account designated "root." Critically, because this EID 4776 event was recorded on a non-domain-controller endpoint, this constitutes strong evidentiary support that "root" constitutes a local security principal provisioned on base-wkstn-09 rather than a domain account. Further examination of the EID 4776 event properties identifies the originating workstation as BASE-RD-10 — presumptively a separate host within the environment. Collectively, these artifacts establish remote authentication to base-wkstn-09 using a local account credential.
Subsequent correlation with temporally adjacent events yields additional context. An Event ID 4624 was logged contemporaneously with the 4776 event; a review of the 4624 record confirms a Logon Type 3 (network) authentication for the same "root" account originating from BASE-RD-10. Type 3 logons are characteristic of network resource access such as SMB share mapping and are also the primary vehicle for many pass-the-hash attacks (a technique reliant on the NTLM authentication protocol, which correspondingly constrains its operational scope to SMB-based actions—share mounting, remote code execution via PsExec, and analogous lateral-movement primitives). While most contemporary Windows deployments are hardened to block pass-the-hash activity involving local administrator accounts by default, certain environments either fail to enforce this control or remain exposed to adversarial modification of the LocalAccountTokenFilterPolicy registry value via a trivial one-line command, thereby re-enabling this attack surface.
cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /fIn this instance, the authentication ultimately failed to achieve resource access, as evidenced by a subsequent failed 5140 event documenting an unsuccessful attempt to mount the administrative C$ share. This scenario illustrates a critical analytical nuance: while EID 4776 registered as a success event (confirming valid credential authentication), correlated nearby events reveal a failure condition governing resource access (e.g., the failed EID 5140 share-mapping event). This underscores a foundational principle of event log forensics—contextual analysis of temporally adjacent events is indispensable to accurate reconstruction of adversarial activity.
Tracking Reconnaissance Activity: Account and Group Enumeration
Windows 10 and Windows Server 2016 introduced a dedicated set of Security events specifically engineered to track enumeration activity targeting sensitive accounts and privileged security groups within the enterprise namespace. While account and group enumeration has long constituted a foundational phase within the adversarial attack lifecycle, the introduction of this dedicated event category is almost certainly attributable to the proliferation of tooling capable of executing such reconnaissance at scale. PowerView—a constituent module of the PowerSploit and Empire post-exploitation frameworks—comprises a suite of cmdlets purpose-built for Active Directory and domain enumeration. DeathStar extends this capability further, autonomously traversing the network topology to identify sensitive accounts, high-privilege security groups, and the locations where corresponding credential material currently resides across the network. This reconnaissance data is then leveraged to automate credential dumping and lateral movement operations, rendering Domain Admin compromise achievable within a matter of minutes.
Prior to the introduction of this event category, no explicit evidentiary mechanism existed within native event logging to capture enumeration activity. The favorable corollary is that detection of malicious activity via these events typically occurs at a comparatively early juncture within the attack lifecycle, affording defenders a materially compressed adversarial dwell time. Threat mitigation at this early stage is generally far less costly and operationally complex than remediation efforts undertaken during later attack-chain phases.
These auditing capabilities are enabled via Group Policy under Advanced Auditing → Account Management, specifically the "Audit Security Group Management" and "Audit User Account Management" subcategories. Because a substantial volume of legitimate account and group enumeration occurs during normal system operation, effective use of these events requires disciplined filtering and tuning. Analysts should prioritize:
- Enumeration activity targeting sensitive/privileged groups.
- Enumeration activity performed by accounts that have no legitimate business reason to conduct enumeration
- Enumeration conducted via anomalous process vectors (e.g., PowerShell, WMI, or net use commands invoked through cmd.exe).
A systematic tuning and allow-listing process—commonly excluding high-volume legitimate processes such as mmc.exe, services.exe, taskhostw.exe, explorer.exe, and VSSSVC.exe—can substantially reduce event volume and improve signal-to-noise ratio during triage.
This artifact's evidentiary value of the above example stems from several converging indicators:
- Anomalous enumeration vector: PowerShell-driven group membership queries are comparatively rare in legitimate baseline activity, and this technique is characteristic of offensive tradecraft frameworks such as PowerView and DeathStar, which routinely fingerprint users and groups during reconnaissance phases.
- Target group sensitivity: The queried group—Administrators—elevates the significance of the event, since enumeration of privileged local groups is a common precursor to privilege escalation or lateral movement attempts.
- Scope of enumeration (local vs. domain): The presence of a workstation name (rather than a domain qualifier) in the account/domain field indicates this enumeration occurred against a local SAM database rather than Active Directory. Analogous logging occurs for Kerberos-based and AD-wide enumeration activity, corresponding to Event ID 4799 (A security-enabled local group membership was enumerated).
- Subject account attribution: The identity performing the enumeration is a critical pivot point—analysts can triage by filtering for accounts that have no legitimate business reason to enumerate privileged group membership (e.g., standard user accounts querying Administrators), which often surfaces reconnaissance activity consistent with AD attack methodologies.
Post a Comment