Uncovering Adversary Tradecraft With Windows Event Logs

Microsoft Windows uses Windows Event Logs extensively to store detailed logs of events generated by the operating system, services, and core Windows applications. Many third-party applications also use Windows Event Logs to store details of their internal events. Based on the logged events, certain user actions may also be identified. Windows event logs serve as a valuable source of digital evidence for forensic analysts investigating security incidents, system anomalies, or suspicious activities on Windows operating systems. These logs record a variety of events and activities that occur within the operating system, providing a detailed trail of information that can aid in understanding the timeline of events, identifying potential threats, and reconstructing the sequence of actions taken by users or attackers. Hence, analysis of Windows Event Logs is a critical skill required by a digital forensics investigator. While digital forensics products do provide a range of features to examine Windows Event Log entries, an investigator must understand the nature of these entries and the underlying mechanisms. This post explores these aspects in detail and presents several important Windows Logs areas that are relevant for a digital forensics investigator.

Each log file consists of a header record (given as an ELF_LOGFILE_HEADER structure) and a body. The body again consists of event records (EVENTLOGRECORD structures), the cursor record, and unused space. The body could form a ring buffer, where the cursor record will mark the border between the oldest and newest event records. Unused space could be empty, slack, or padding.

        
c
        

            
        
     
//ELF_LOGFILE_HEADER structure

typedef struct _EVENTLOGHEADER {
    ULONG HeaderSize;            // Size of the header structure, always 0x30
    ULONG Signature;             // Signature, always 0x654c664c ('eLfL' in ASCII)
    ULONG MajorVersion;          // Major version number, always set to 1
    ULONG MinorVersion;          // Minor version number, always set to 1
    ULONG StartOffset;           // Offset to the oldest record in the event log
    ULONG EndOffset;             // Offset to the EOF record in the event log
    ULONG CurrentRecordNumber;   // Number of the next record to be added
    ULONG OldestRecordNumber;    // Number of the oldest record in the event log
    ULONG MaxSize;               // Maximum size, in bytes, of the event log
    ULONG Flags;                 // Status flags of the event log
    ULONG Retention;             // Retention value of the file when created
    ULONG EndHeaderSize;         // Ending size of the header structure, always 0x30
} 

Whenever an event has to be written/created/updated, the ELF_LOGFILE_HEADER and the ELF_EOF_RECORD structures are written in the event log. Whenever an application needs to log (or is set in the registry to log an event), it calls the ReportEvent function, which adds an EVENTLOGRECORD structure taking the parameters from the system through the event logging service as shown in the image below.

The event records are organized in one of the following ways:

• Non-Wrapping - The oldest record is immediately after the event log header and new records are added after the last record that was added (before the ELF_EOF_RECORD). Non-wrapping can occur when the event log is created or when the event log is cleared. The event log continues to be non-wrapping until the event log size limit is reached. The event log size is limited by either the MaxSize configuration value (to be discussed presently) or the amount of system resources. When the event log size limit is reached, it might start wrapping. Wrapping is controlled by the Retention configuration value (to be discussed presently). The syntax is given below:

• 
          
  text
          
  
              
          
       
  HEADER                           (ELF_LOGFILE_HEADER) 
  EVENT RECORD 1            	 (EVENTLOGRECORD)
  EVENT RECORD 2             	 (EVENTLOGRECORD)
  •  
  •  
  •   
  EOF RECORD               (ELF_EOF_RECORD)   
  

• Wrapping - The records are organized as a circular buffer. As new records are added, the oldest records are replaced. The location of the oldest and newest records will vary.

• 
          
  text
          
  
              
          
       
  HEADER 				                (ELF_LOGFILE_HEADER)
  PART OF EVENT RECORD 300		        (EVENTLOGRECORD)
  EVENT RECORD 301 			        (EVENTLOGRECORD)
  •  
  •  
  • 
  EVENT RECORD 400 			       (EVENTLOGRECORD)
  EOF RECORD 			               (ELF_EOF_RECORD)                
  Wasted space 
  EVENT RECORD 102    			       (EVENTLOGRECORD)        
  EVENT RECORD 103    			       (EVENTLOGRECORD) 
  •  
  •  
  •
  EVENT RECORD 299 			        (EVENTLOGRECORD)
  PART OF EVENT RECORD 300  	                (EVENTLOGRECORD) 

• In the example above, the oldest record is no longer 1, but is 102 because the space for records 1 to 101 was overwritten. There is some space between the ELF_EOF_RECORD and the oldest record because the system will erase an integral number of records to free space for the newest record.

Windows event logs are tokenized and stored in binary form, so raw string searches will miss much of the information in theses files. Event logs prior to Vista were stored in the .evt format in the %systemroot%\System32\config directory. Starting with the Vista and Server 2008 product lines, significant changes to the event log structures, log types, and log locations were made. Modern Windows systems now store logs in the %SystemRoot%\System32\winevt\logs directory by default in the binary XML Windows Event Logging format, designated by the .evtx extension.  Additionally, the new log format (finally) allows logs to be sent to a remote log collector.  For remote logging, a remote system running the Windows Event Collector service subscribes to collection of logs produced by other systems. The types of logs to be collected can be specified at a granular level, and transport occurs over HTTPS on port 5986 using WinRM. Group Policies can be used to configure the remote logging facilities on each computer. 

It is important to note that the directories aforementioned are only the default locations. The administrator can designate other locations for individual logs within the following registry keys:

• HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application
• HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System
• HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security

• File (REG_EXPAND_SZ) - This specifies the path to the log file. The default value is %SystemRoot%\System32\Winevt\Logs\<LogName>.evtx
• MaxSize (REG_DWORD) - This defines the maximum log file size in bytes. Default sizes vary depending on the log type
• Retention (REG_DWORD) - This controls log retention behaviour. Possible values include:
• 0x0 (Overwrite as needed) - Oldest events are deleted when the log reaches its size limit.
• 0x1 (Do not overwrite events) - New events are not written when the log is full. When the maximum log size is reached, error messages are generated to indicate that the event log is full. The administrator must manually clear the logs.
• 0x2 (Overwrite events older than X days) - Works with the AutoBackupLogFiles setting.
• AutoBackupLogFiles (REG_DWORD) - If set to 1, the log file is automatically backed up before being overwritten.
• RetentionDays (REG_DWORD) - This is only available if Retention is set to 2. It specifies the number of days to retain event logs before overwriting them.

All versions of Windows maintain three “core” event logs: Application, System, and Security. Activities related to user programs and commercial off-the-shelf applications populate the Application log. Application events that are audited by Windows include any errors or information that an application wants to report. Host-based security tools such as antivirus and intrusion prevention systems often record events to this log. Windows authentication and security processes record events in the Security log. This log can include user logon and logoff attempts, account creation, changes to user privileges or credentials, changes to the audit policy, process execution, and file and directory access. Local or Group Policy settings can configure exactly which security events are captured and logged. The System event logs record events reported by a variety of core operating system components. Its contents can include Windows service events, changes to the system time, driver loads and unloads, and network configuration issues. Microsoft also added a second category of logs, Applications and Services (also known as Custom logs), that are used by individual installed applications or system components. These logs are also stored in EVTX files located within the directory %SYSTEMROOT%\System32\Winevt\Logs\. The Task Scheduler, Windows Firewall, AppLocker, Terminal Services, and User Access Control are a few examples of Windows features that can maintain their own logs (if enabled) under this category.

Although almost all event logging has the potential to be useful during an investigation, most of the questions we are looking to answer during a forensic investigation tend toward answers found in the Security log. The System and Application logs store information more useful for troubleshooting by system administrators. 

For security logs, all logs are not enabled by default. “Audit Policy” manages this. The Security log records an audit event whenever a given system or user action meets the criteria set forth by the audit policy in use. Audit policies are mostly centrally created by the system administrator or privileged users using the following utilities: auditpol, secpol.msc, or gpedit.msc. These settings are then stored in the PolAdEvt registry key located at HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdEvt. However, direct access requires SYSTEM-level privileges because the security hive is protected. Due to its nature, the Security log has more protections in place than the System and Application logs. With XP Service Pack 2, the API was deprecated for applications other than the Windows Security Service to trigger events in the Security Log. This ability is now held only by the Local Security Authority Subsystem Service (LSASS) because it is responsible for enforcing the security policy on the system. Additionally, only user accounts with administrator permissions can review, export, or clear the log.

Microsoft defines nine various categories of security events that can be audited in Windows^® environments. They are discussed in the table below:

Account Logon Events	Account Logon is the Microsoft term for authentication. Authentication (account logon) of domain accounts is performed by a domain controller within a Windows network. Account logon events will be logged by the system that performs the authentication (i.e the system who authorized logon). Account logon events are generated in the domain controller's Security log when a domain user account is authenticated on a domain controller. These events are separate from Logon events which are generated in the local Security log when a local user is authenticated on a local computer. Account logoff events are not tracked on the domain controller.
Account Management	Records changes  to user accounts, groups, and passwords. It logs creation, deletion, and modification of accounts.
Directory Service Access	Audits access to Active Directory® directory service object that has its own system access control list (SACL).
Logon Events	Monitors user logins, logoffs, and session reconnections in a local computer. It also tracks remote desktop logins and screen locks/unlocks. Logon is the term used to refer to an account gaining access to a resource. Local accounts (those that exist within a local SAM file rather than as a part of Active Directory) are authenticated by the local system where they exist.
Object Access	Audit the event of a user accessing an object that has its own system access control list (SACL) specified. Monitors access to files, folders, registry keys, and other objects. It includes auditing removable storage device usage.
Policy Change	Tracks modifications to security policies, such as user rights assignments, auditing policies, or trust policies.
Privilege Use	Audits the use of special privileges like SeDebugPrivilege (used by debuggers). This is useful in detecting privilege escalation attempts.
Process Tracking	Monitors process creation, termination, and token manipulation. This is useful for detecting malware and suspicious scripts.
System Events	Logs system startup, shutdown, and time changes. It includes security system events like LSASS crashes.

Event log analysis tools provide the ability to acquire, view, search, sort, and filter EVT and EVTX files since they are not intrinsically “human readable.” An event  log analysis tool like Windows Event Viewer or LogParser uses the OpenEventLog function to open the event log for an event source. Then the viewer application uses the ReadEventLog function to read event records from the log. The following diagram illustrates this process.

Event Log Analysis

The Windows event log is the most important source of evidence during digital forensic investigations of a Windows system because the log files connect certain events to a particular point in time. To the digital forensic inestigator, event logs is of enormous benefits as it provides a detailed step by step account of activities that occured in a system. By understanding and using event logs efficiently, incident handlers can detect malicious actors, reconstruct a vast amount of adversary activity, and identify impacted systems. In this section, we provide actionable information on using Windows event logs to reconstruct adversary activity within a network. We will provide so many event IDs and specific indicators that can be used to detect and respond to malicious actors. 

Builtin Windows Accounts

During DFIR investigations, the investigator is concerned with digital footprints attributable to a standard human user. It is important to state here that built-in local user accounts other than standard user account names can be encountered when reviewing event logs.  As a first step in learning about possible anomalous behavior related to built-in local user accounts, you should first know which built-in local user accounts exist on different Microsoft Windows operating system versions. You should know their default settings, purpose, group membership information, and so on.

• SYSTEM - This is the most privileged account in the Windows operating system. The SYSTEM account is used by the operating system and by services running under Windows. Many services and processes in the Windows operating system need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM account's user rights. It is an internal account that does not show up in User Manager and cannot be added to any groups. It is the most powerful account on the system hence any process running under its authority that was subverted by an attacker would give absolute access to that attacker.
• LOCAL SERVICE - The LOCAL SERVICE account is a predefined local account used by the service control manager. It has minimum privileges on the local computer and is used for services that do not require network access. Hence, it cannot authenticate with network resources and is relegated to using null sessions for network communications (uses anonymous tokens for network access). The LocalService account has the following privileges.
• SE_ASSIGNPRIMARYTOKEN_NAME (disabled)
• SE_AUDIT_NAME (disabled)
• SE_CHANGE_NOTIFY_NAME (enabled)
• SE_CREATE_GLOBAL_NAME (enabled)
• SE_IMPERSONATE_NAME (enabled)
• SE_INCREASE_QUOTA_NAME (disabled)
• SE_SHUTDOWN_NAME (disabled)
• SE_UNDOCK_NAME (disabled)
• Any privileges assigned to users and authenticated users
• NETWORK SERVICE - Similar to LOCAL SERVICE, but with slightly higher privileges, which allow it to impersonate standard computer accounts and authenticate over the network. It is assigned for processes or services that require network access. The NetworkService account has the following privileges.
• SE_ASSIGNPRIMARYTOKEN_NAME (disabled)
• SE_AUDIT_NAME (disabled)
• SE_CHANGE_NOTIFY_NAME (enabled)
• SE_CREATE_GLOBAL_NAME (enabled)
• SE_IMPERSONATE_NAME (enabled)
• SE_INCREASE_QUOTA_NAME (disabled)
• SE_SHUTDOWN_NAME (disabled)
• SE_UNDOCK_NAME (disabled)
• Any privileges assigned to users and authenticated users
• <Hostname>$ - When a computer joins an Active Directory domain, a corresponding account is created in AD with the name HOSTNAME$ (e.g., WIN10-PC$). The account provides the means for the computer to be authenticated to the domain and access network and domain resources such as Group policy updates, authentication delegation, etc.
• DVM and UMFD - Microsoft has provided almost no documentation on these built-in accounts. They are apparently related to the Desktop Windows Manager (DWM) and Usermode Font Driver (UMFD)  activities. When investigating 4624 successful logon events, it is vital that these accounts logons are whitelisted as this will considerably decrease the noise.
• ANONYMOUS LOGON - This account is the most often misunderstood. It was originally created as a means for Windows systems to communicate without requiring explicit credentials. In older or insecure systems, anonymous logons, or Null Sessions, can be used to enumerate account information, security policy, registry data, and network shares. These abilities have slowly been removed (by default) in newer versions of Windows starting with XP and 2003. That being said, the account is still commonly used by Windows networks to facilitate things like file and print sharing and maintaining the network browse list. If these services are present in your environment, there is a good chance that you will see Anonymous Logon usage. The key takeaway is to not automatically assume the system has been under some sort of enumeration attack. Further contextual information is usually needed to understand what an Anonymous Logon might mean.

Built-in account logons typically far outnumber those of normal users. These accounts can be very noisy in the log, even using different logon types, like 2, 3, and 5 (to be discussed presently). Since we are typically more interested in what humans are doing on the system, we can filter out many of these system accounts to better focus on actual user accounts. 

Investigating Logon Events

Tracking logon events is one of the more common uses for reviewing event logs. Knowing when a user account logged on to a system and subsequently logged off can provide helpful corroborating evidence along with other forensic artifacts found. If account credentials are suspected to be compromised, reviewing successful logons throughout your network can help track where the hacker has been. We will also see that remote logons are recorded and can provide excellent profiling information on how an authorized or unauthorized user is traversing the network and attempting to authenticate with resources.

In the context of tracking logons, the event IDs revealed in the table below are of particular interest.

Subcategory	Event ID	Notes
Logon	4624	An account was successfully logged on
	4625	An account failed to log on
	4626	User/Device claims information
	4648	A logon was attempted using explicit credentials
	4675	SIDs were filtered
Logoff	4634	An account was logged off
	4647	User initiated logoff
Special Logon	4672	Special privileges assigned to new logon
	4964	Special groups have been assigned to a new logon
Other Logon/Logoff Events	4649	A replay attack was detected
	4778	A session was reconnected to a Windows Station
	4779	A session was disconnected from a Windows Station
	4800	The workstation was locked
	4801	The workstation was unlocked
	4802	The screen saver was invoked
	4803	The screen saver was dismissed
	5378	The requested credentials delegation was disallowed by policy
	5632	A request was made to authenticate to a wireless network
	5633	A request was made to authenticate to a wired network

Table: Logon event IDs of interest

The most frequent is the 4624/4634 pair, which indicates a successful logon/logoff as well as the duration of the entire user session. Windows is not always consistent in recording logoff events (type 4634), therefore keep an eye out for 4647 events (user-initiated login for interactive sessions). 4625 events indicate logon failures and are frequently investigated for indications of brute-force attacks. In addition to the usual 4624 events, administrator-equivalent logons are logged using Event ID 4672.

When auditing account usage events, we focus on five fields of the event record as indicated in the image above. The Logged timestamp provides information on the date and time that the account logon occurred. The Computer reference tells us the hostname of the system that the event was recorded on. This can be very helpful when reviewing logs from multiple systems simultaneously to find logon patterns. The Event ID indicates what type of Logon/Logoff event occurred, and in this case, it is Event ID 4624, which is reserved for successful logons. The Account Name field tells us which account was successfully logged into. In this case, it was an Anonymous logon - This account is used for null session communications – in other words, for network communications – without the need to provide explicit credentials. There are multiple different ways that a logon can occur in a modern Windows system. It is not enough to just tell us that a user successfully logged into this system at a date and time. Equally important is the method used for authentication. This is where the Logon Type comes in handy. The table below shows the various event logon types. In this case, Logon Type 3 indicates that the logon was accomplished via the network.

Logon Type Codes
Code	Type	Description
2	Interactive	The user logged on from the console of the computer. This can be seen when a user logs on at the local keyboard or screen whether with a domain account or a local account from the computer s local SAM. To differentiate between logon with a local and domain account, check the domain or computer name preceding/after the account name in the event s description.
3	Network	This logon type is recorded when a user logged on over the network. A good example is connection to shared folders or printers. This represents a noninteractive logon, which does not cache the user's credentials in RAM or on disk.
4	Batch	This logon type is recorded when a batch job executes on a computer, typically using a task scheduler or similar mechanism.
5	Service	This logon type is recorded when a service starts and logs on to the system using its stored credentials. Service logons are typically performed by system services or background processes.
6	Proxy	Microsoft defines this as a proxy-type logon. We have yet to see this type of event in the wild, or any documentation explaining how it may be generated.
7	Unlock	This logon type is recorded when an unattended workstation with a password protected screen is unlocked. It indicates that a user has regained access to their previously locked session
8	NetworkCleartext	This indicates that a user logged on to the computer from over the network and the user's credentials was passed to the authentication package in cleartext format (Base64 encoded). This logon type is most commonly used in Internet Informational Services (IIS) basic authentications.
9	NewCredentials	This indicates that a user logged on with alternate credentials to perform some actions. The easiest way to create a new logon session with the NewCredentials logon type is to use runas /netonly /user: user_name application_name, where user_name is the name of the account for which a new session is established and application_name is the name of the application being run using new logon session. After the command is executed, a prompt appears that asks the user to type a password for user_name account.
10	RemoteInteractive	This indicates that the user logged on via Terminal Services, Remote Assistance, or Remote Desktop. This makes it easy to distinguish true console logons from a remote desktop session.
11	CacheInteractive	This indicates the user logged on with domain credentials that were validated using locally cached data rather than contacting the domain controller.

Although these are the most important elements, each recorded event contains additional information defining the event and providing valuable information regarding why that event was triggered.  The information available is as follows.

• Source - The application, service, or Microsoft system component that generated the event
• Level - The severity or importance assigned to the event in question. It helps in categorizing log entries based on their impact, making it easier to filter and analyze logs for troubleshooting, security monitoring, and system diagnostics. Common levels in Windows event logs include:
• Critical (Level 1) - This indicates a serious issue that has caused a system or application to crash. Immediate attention is required.
• Error (Level 2) - Represent significant problems such as application failures, driver errors, or hardware issues. These may affect functionality but may not crash the system.
• Warning (Level 3) - Highlights potential issues that might not be critical but could lead to problems if ignored. Examples include low disk space or high memory usage.
• Information (Level 4) - Logs standard operations and successful events, such as service start/stop, user logins, or application updates.
• Verbose (Level 5) - Provides detailed debugging information that can be useful for troubleshooting. It contains excessive logs beyond typical informational messages.
• Opcode - This describes what action or operation was being performed when the event was logged. It provides context about the nature of the event and can be useful for troubleshooting and forensic analysis. Common opcode values include:
• Info (0) - A general informational event, often used when no specific opcode applies.
• Start (1) - Indicates the beginning of an operation, such as process start.
• Stop (2) - Marks the completion of an operation, like a process termination.
• DC Start (3) - Data collection or diagnostic start.
• DC Stop (4) - Data collection or diagnostic stop.
• Extension (5) - Used for extended operations, often in more complex logging scenarios.
• Reply (6) - Represents a response to a previously logged request.
• User - This indicates which user account was associated with the event. This can be useful for security auditing, troubleshooting, and forensic analysis as it helps track which user performed an action or was affected by an event. Some events may display "N/A" in the User field if no user context applies (e.g., system-level events).
• Task Category -  This field provides additional context about the specific operation or activity associated with an event. It is primarily used to group related events within a particular event source, making it easier to understand the event's purpose. It is defined by the event source (e.g., a Windows service, application, or system component. It helps categorize events beyond the standard "Level" and "Opcode" fields. The meaning of a Task Category varies depending on the event source.
• Impersonation Level - This is a security concept that defines how a process or thread can act on behalf of another user after authentication. It allows a process to execute actions using another user's security context.  It may have one of the following values:
• Identification - The process knows the client's identity information (such as group membership, account name, and so on) and can perform access validation checks, but it cannot impersonate the client (act on behalf of a client). This type of impersonation is useful for access validation attempts, when there is no need to act as a client.
• Impersonation - The process can completely impersonate the client on the local machine and act on behalf of the client. This type of impersonation does not allow the process to impersonate a client outside of the system, as such connecting to other hosts on behalf of the client. This is commonly used in services, but it can allow privilege escalation if misused.
• Delegation - The process can completely impersonate the client on the local and remote machine. This type of impersonation is usually set up in Active Directory environments by using the Delegation tab for the computer or user object. If an adversary compromises an account with delegation privileges, they can impersonate that user on other systems (e.g., pass-the-hash or pass-the-ticket attacks). 
• Logon Process - Logon Process field in a Windows log provides a hint at how the user tried to access the system: at its console, through Server Message Block (SMB –for shared files), or the Common Internet File System (CIFS -network filesystem protocol used for providing shared access to files and printers) for shared-folder access, or through IIS. It shows the name of a Windows component that was invoked to perform a logon. Some logon processes are authentication-protocol specific as listed below:
• NtLmSsp - NTLM authentication (local or network logon).
• Negotiate - The system determines the best available authentication (e.g., NTLM, Kerberos).
• Kerberos - Kerberos is authentication, used in Active Directory environments.
• Schannel - Secure Channel, used for SSL/TLS-based authentication.
• Seclogo - Secondary Logon Service. Used by the Local Security Authority (LSA) for logons
• CredSSP - Credential Security Support Provider (used for RDP authentication)
• Advapi - Indicates logons using API calls such as LogonUser() (common in service accounts).
• IKE - Internet Key Exchange protocol process.
• PKU2U - User-2-User Public Key Cryptography.
• To differentiate types of logons using the Login Process field, you need to analyze it alongside the Logon Type field. The Logon Type tells you how the user logged in, while the Login Process indicates which authentication mechanis was used.

  Logon Type	Description	Common Logon Process Values	Example Scenarios
  2	Interactive	User32, Advapi	Physical logon at a workstation
  3	Network	NtLmSsp, Kerberos, Schannel, Negotiate	Accessing shared folders or printers
  4	Batch	Advapi	Scheduled tasks, batch scripts
  5	Service	Advapi	Services running as specific user accounts
  7	Unlock	User32	Unlocking an already logged-in session
  8	NetworkCleartext	Advapi, NtLmSsp	Authentication using plaintext credentials
  9	NewCredentials	Advapi	runas /netonly /user: user_name application_name command
  10	RemoteInteractive	CredSSP, Negotiate, Kerberos	Logging in via Remote Desktop Protocol
  11	CachedCredentials	MSV1_0, Advapi	Logging in without contacting a domain controller (e.g., offline login)

• If you see Logon Type 3 (Network logon) with Logon Process 'Advapi', it could indicate a service or script running with network access. If Logon Type 10 (Remote Desktop) uses 'NtLmSsp', it means NTLM authentication was used instead of Kerberos, which might be worth investigating in a domain environment. If a system typically logs in with Kerberos but suddenly logs in using NTLM, it could be indicative of a Man-in-the-Middle (MitM) attack forcing NTLM fallback. Logon Type 8 (NetworkCleartext) with 'NtLmSsp' could indicate a poorly configured system exposing passwords.
• General Description -  A text block where additional information specific to the event being logged is recorded Descriptions can excel at “saying nothing,” but can sometimes provide valuable information, including remote IP addresses, hostnames, etc.
• Details - An optional field containing additional raw data (or error codes) generated by the event.

It should be noted that a single event should not be examined in isolation. After gathering information from this 4624 event, we would review other events surrounding it, in addition to looking for a matching 4634 event, indicating that the user logged off from this session.

Examining Logon Sessions

When each account session logs in, it is assigned a unique Logon ID, a semi-unique identifier that persists for all events logged during a single user session until the system is rebooted. This value can be extremely useful for tracking user activity during a session. Examiners frequently assess how much time users spend on the system. This can be used to profile account activity, as part of an intrusion investigation, or even to detect timecard violations. The image below shows two events: a 4624 successful logon and a 4634 successful logoff. The Logon ID allows the examiner to connect the two events and  calculate the session length by measuring the time elapsed between the logon and logoff events. In this case, the session lasted for a second, starting at 9:19:16 AM and ending at 9:19:17 AM. Type 3 (Network) logons will typically disconnect shortly after a request is complete and do not indicate the actual amount of time that a user was engaged in any particular activity. Interactive logons (primarily type 2, but also types 10 and 11 where they exist) can provide a better sense of session duration, but Windows is not overly consistent in logging Event ID 4634 and may disconnect sessions due to inactivity well after a user stopped actively interacting with a session. 4647 user-initiated logoff events can also be used in place of 4634 events when they exist.  

Beyond tracking session duration, the Logon ID is instrumental in linking sessions to specific user privileges. The Event ID 4672 is logged when special privileges are assigned to a new logon session. It details the specific rights granted, such as administrative privileges, and includes the Logon ID. By correlating this event with the corresponding logon event (Event ID 4624) using the Logon ID, investigators can identify which sessions have elevated privileges. The Logon ID also facilitates detailed monitoring of user activity, including screen locking (Event ID 4800) and unlocking (Event ID 4801). Both events contain the Logon ID, enabling investigators to trace these specific actions within a user's session. 

Identifying Brute-Force Attacks

A review of the event log in the above image shows a large number of 4625 Events indicating high-frequency authentication failures. Multiple failed logins within a short period strongly indicate an automated bruteforce attack. If an account gets locked after several failed login attempts, it may confirm brute-force activity. Investigate who unlocked the account and if a successful login followed. If a successful login follows multiple failed attempts, it could indicate the adversary guessed the correct password. The following fields provide details about the failed logon attempt.

• Account For Which Logon Failed - This section gives detailed information about the account that attempted to log in. The Security ID field is always NULL SID (S-1-0-0) for all failed logon attempts. The reason for this is that information is not yet available at the time the 4625 event is generated, because the account is not yet authenticated.
• Failure Information - This section contains information on why the logon attempt failed.
• Failure Reason - This is the reason for the failure. It is a human-readable representation of the Status or Sub Status fields (if it exists).
• Status - The NTSTATUS code that explains why the logon attempt failed
• Sub Status - The NTSTATUS code that provides a more detailed reason for a failed logon attempt. It may contain some additional information for specific Status codes. It also may contain the same value as the Status field or 0x0, which means there is no additional information in the Sub Status field.

The table below contains information about possible values for the Failure Reason, Status, and Sub Status fields for the 4625 Event ID.

STATUS CODE	FAILURE REASON TEXT	EXPLANATION
0xC000005E	An error occurred during logon	There are currently no logon servers available to service the logon request.
0xC000006D	Unknown user name or bad password	The authentication failed due to incorrect credentials (username or password). See Sub Status field for additional information.
Start of Sub Statuses for 0xC000006D
0xC0000064	Unknown user name or bad password	The specified username is incorrect or does not exist.
0xC000006A	Unknown user name or bad password	The entered password is incorrect for the specified account.
0xc000019b	Domain SID inconsistent	Duplicate or incorrect SID was detected.
0xC0000133	An Error occurred during Logon	Clocks between DC and other computer too far out of sync
End of Sub Statuses for 0xC000006D
0xC000006E	User not allowed to logon at this computer	User not allowed to logon at this computer. See Sub Status for more details.
Start of Sub Statuses for 0xC000006E
0xC000006F	Account logon time restriction violation	User logon outside authorized hours
0xC0000070	User not allowed to logon at this computer	User logon from unauthorized workstation
0xC0000071	The specified account's password has expired	User logon with expired password
0xC0000072	Account currently disabled	User logon to account disabled by administrator
End of Sub Statuses for 0xC000006E
0xC00000DC	An Error occurred during Logon	Indicates the Sam Server was in the wrong state to perform the desired operation.
0xC000015B	The user has not been granted the requested logon type at this machine	The requested logon type (e.g., Interactive, Network) is not allowed for this account.
0xC000018C	An Error occurred during Logon	The trust relationship between the workstation and the domain failed.
0xC0000192	The NetLogon component is not active.	An attempt was made to logon, but the Netlogon service was not active.
0xC0000193	The specified user account has expired.	The user account has expired and cannot be used to log in
0xC0000224	The specified account's password has expired	User is required to change password at next logon.
0xC0000225	An Error occurred during Logon.	Evidently a bug in Windows and not a risk. .
0xC0000234	Account locked out.	The account has been locked out due to multiple failed logon attempts
0xC00002EE	An Error occurred during Logon	An error occurred during logon.
0xC0000413	An Error occurred during Logon	The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.
0x0	No errors	No Sub Status.

Tracking Administrator Account Activity

Attackers often attempt to escalate privileges after gaining initial access in order to gather credentials and move effectively through the network. When an administrator-equivalent account logs onto the system, an Event ID 4672 is recorded.  Note that the account technically does not have to be a full administrator—assignment of privileges like SeTakeOwnership, SeDebug, and SeImpersonate are all admin-equivalent and will trigger this event. 

By correlating successful logon (Event ID 4624), the special logon (Event ID 4672) with other security events listed below, analysts can establish potential lateral movement and privilege escalation attempts. When monitoring these events, you should whitelist built-in Windows accounts like SYSTEM to detect actual user activity. 

• 4720 - A new user account was created.
• 4722 - A user account was enabled
• 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
• 4755 - A security-enabled universal group was changed
• 4756 - A member was added to a security-enabled universal group

Tracking Remote Desktop Protocol Connections

Investigating lateral movement activities involving remote desktop protocol (RDP) is common when responding to an incident where nefarious activities have occurred within a network. Perhaps the quickest and easiest way to do that is to check the RDP connection security event logs on machines known to have been compromised for events with ID 4624 or 4625 and with a type 10 logon. However, that is not always a surefire way to detect if such activity has occurred. Different events capture details about the session that an examiner can piece together to paint a picture of the RDP session as a whole.

When piecing together evidence of RDP connections, two event IDs can provide significant value: Event ID 4778 indicates that an RDP session was reconnected, and Event ID 4779 indicates that a remote session was disconnected. These two event IDs in tandem can help us bookend RDP sessions, but note that they will not provide a historical view of every RDP connection. They are really designed to track session “reconnects” instead of brand-new RDP sessions and will only show a subset of RDP activity. However, this can be an advantage since RDP session reconnects are often recorded as Event ID 4624 Logon Type 7 events (typically assumed to be screen lock/unlock as opposed to the “standard” Type 10 RDP Logon Type). If an analyst is only focusing on EID 4624 Logon Type 10 RDP events, they could miss any session reconnects, but discover their existence via Event IDs 4778 and 4779 events. 

Another big advantage of Event IDs 4778 and 4779 is that they include the IP address AND the hostname of the system that established the connection (the hostname recorded in 4624 events is often some intermediary system and not the original client). We should also expect to see a near-simultaneous ID 4624 event (successful logon) because ID 4778 indicates only a successful remote session was reconnected, and ID 4624 indicates that the credentials provided were accepted. The same goes for ID 4779 and ID 4647 (successful logout) events. To further reinforce this idea of nearby events providing more context, we will often see on workstations an ID 4779 (session disconnected) event immediately before an ID 4778 (session connected) event. This is due to Windows workstations allowing only one interactive logon at a time. When an RDP connection is made to a system that currently has a user logged in to the console, the console session must be first disconnected. Not every 4778/4779 event will be due to RDP usage. Windows also uses this same event to record the changing of Windows stations due to the “Fast User Switching” feature and the session name will be “Console”.

Depending on how the RDP client is used (full logout or just closing the client), session reconnects and disconnects may not be present for every RDP access. Event ID 4624 (Logon Types 3, 7, and 10) is usually the most comprehensive view, and it is also worth cross-referencing with the Remote Desktop Services—RDPCoreTS and TerminalServices—RdpClient auxiliary logs located in the same folder as the other event logs. Event ID 131 within the RDPCoreTS log and event IDs 1024 and 1102 in the TerminalServices-RdpClient log record outbound RDP connections, including destination hostname and IP address. 

It is also very common today to see Logon Type 3 instead of Logon Type 10 as RDP Network Level Authentication (NLA) is on by default in most environments (NLA is a security mechanism that first authenticates an account on the network before establishing a connection with the RDP server). All this means you cannot simply rely upon filtering for EID 4624 Logon Type 10 events to discover all RDP activity on a system. This is an excellent example of using multiple events to paint the complete picture of an action taken on a machine. It is also important to understand that these events would only be logged only on the receiving system. The system that initiated the RDP connection will not have these events logged (we will need different entries like those from the TerminalServices-RDPClientlog to identify activity on the initiating system).

A wealth of information about local and remote logons can be determined from analyzing Logon Events in the Security log. But what if the log rolls over every 24–48 hours? If you are not archiving or centralizing logs, you might not have the proper window of log data to find the evidence you are looking for. Luckily, Windows systems post Vista/2008 now have a wealth of additional “custom” logs. These specialized logs tend to record a much smaller set of actions and hence can go back much further in time than your Security or even System and Application logs. For reasons not entirely clear, the remote desktop service maintains several different logs, often with duplicate information. As any incident responder will attest, having more information is always better than less! It is possible that one or more logs may be missing or have limited retention. The Security log often does not go back as far as we would like, so the additional “custom” logs provided by the RDP service can regularly help us fill in any gaps.

On the machine receiving the connection, additional RDP specific logs may be found. The %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational log may contain the IP address and logon user name of the originating computer in Event IDs 21, 22 or 25. Event ID 41 may also contain the logon user name. The %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational log may record Event ID 1149 that contains the initiating IP address and logon user name. Finally, the %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational log may record Event ID 131 containing the initiating IP address and logon user name.

On the system that initiates an RDP session, additional evidence may be available. This can be important when a compromised host is used as a jump off point for the attacker to connect to other systems. The %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices RDPClient%4Operational log records the systems to which the host-initiated connections using Event IDs 1024 and 1102. You may also find evidence of connections on the initiating system in the NTUSER.DAT\Software\Microsoft\Terminal Server Client\Server registry key. 

Additional information about RDP Sessions can be found in the %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices LocalSessionManager%4Operational log file. Event ID 21 in this log shows session logon events, both local and remote, including the IP from which the connection was made if remote. Event ID 24 in this log shows session disconnection, including the IP from which the connection was made if remote. For local logons, the Source Network Address field of the event description will read LOCAL rather than provide the remote IP.

SOURCE PC:
Security	4648
TerminalServices-RDPClient/Operational	1024, 1102

 

DESTINATION PC:
LOG ON:
Security	4624, 4625
TerminalServices-RemoteConnectionManager/Operational	1149
RemoteDesktopServices-RDPCoreTS /Operational	98, 131
TerminalServices-LocalSessionManager/Operational	21, 22, 25, 41
LOG OFF:
Security	4634, 4647
TerminalServices-LocalSessionManager/Operational	23, 24, 40

Investigating Authentication-Related Events

Account Logon is the Microsoft term for authentication. You may find it helpful to think of account logon events as authentication events and logon events (previously discussed) as records of actual logon activity. For authenticated access to be granted to a Windows resource, an authentication authority must verify that the credentials provided are valid, and then a system provides access to the desired resource. These two actions may be performed by the same system or by different systems. 

When a user attempts to log in with a domain account to a domain workstation, the authentication authority that confirms whether the provided credential is valid is the domain controller, but the system providing access to the desired resource is the client workstation. Account Logon events record this process and, in this case, would be stored on the domain controller that verified the credentials. Thus, a single user logon can lead to several different events being spread across the workstation (Logon Events 4624, 4634, etc.) and across the domain controller (Account Logon Events 4776, or 4768, 4769). The default protocol used within a Windows domain for authentication is Kerberos; however, an older protocol, NT LAN Manager (NTLM) may also be used during normal system activity. Similarly, if a local account is used to access a stand‐alone computer, that computer verifies that the authentication is valid and grants access to the desired resource. This results in both Logon Events and Account Logon Events being recorded in the workstation's event logs. In a domain environment, most organizations rely on domain accounts for most, if not all, authentication. For that reason, account logon events should occur primarily on the domain controllers. Account logon events appearing on clients or member servers indicate that a local account is being used on the system. Attackers will frequently create local accounts to provide backdoor access to a system that was compromised, so looking for authentication using local accounts in event logs across the enterprise may help identify malicious activity. 

Subcategory	Event ID	Notes
Windows Credential Validation	4774	An account was mapped for logon. I have not seen this event logged by Windows. I wager that it would be in conjunction with IIS's certificate mapping capability where users are authenticated via a client certificate which is then mapped to a Windows user account according to the mapping rules defined in IIS.
	4775	An account could not be mapped for logon. This event never occurs.
	4776	The domain controller attempted to validate the credentials for an account. This event is generated every time a credential validation occurs using NTLM. It shows successful and unsuccessful credential validation attempts.
	4777	The domain controller failed to validate the credentials for an account. Currently, this event does not generate. It is a defined event but it is never invoked by the Operating system. 4776 failure event is generated instead.
Kerberos Authentication Services	4768	A Kerberos authentication ticket (TGT) was requested
	4771	Kerberos pre-authentication failed
	4772	A Kerberos authentication ticket request failed
	4820	Kerberos Ticket-Granting-Ticket (TGT) was denied because the device does not meet the access control restrictions.
Kerberos Services Ticket Operations	4769	A Kerberos service ticket was requested
	4770	A Kerberos service ticket was renewed
	4773	A Kerberos service ticket request failed
Other Account Logon Operations	4782	The password hash of an account was accessed

Table: Account Logon event IDs of interest

For NTLM, both successful and failed events are recorded using Event ID 4776. It shows only the Computer Name (Source Workstation) from which the authentication attempt was performed. For example, if authentication is attempted from CLIENT-1 to SERVER-1 using a domain account, CLIENT-1 will be recorded in the Source Workstation field. Information about the destination computer (SERVER-1) is not present in this event. If a credential validation attempt fails, an Audit Failure event with Error Code parameter value not equal to "0x0" will be recorded. 

The Keywords field indicates whether the authentication attempt succeeded or failed. In the event of authentication failure, the error code in the event description provides additional details about the failure. The logon event ID 4625, Failed Logon, uses the same error codes as event ID 4776.

Error Code Description 0xC0000064 The username you typed does not exist. Bad username. 0xC000006A Account logon with misspelled or bad password. 0xC000006D - Generic logon failure. Some of the potential causes for this: An invalid username and/or password was used LAN Manager Authentication Level mismatch between the source and target computers. 0xC000006F Account logon outside authorized hours. 0xC0000070 Account logon from unauthorized workstation. 0xC0000071 Account logon with expired password. 0xC0000072 Account logon to account disabled by administrator. 0xC0000193 Account logon with expired account. 0xC0000224 Account logon with "Change Password at Next Logon" flagged. 0xC0000234 Account logon with account locked. 0xC0000371 The local account store does not contain secret material for the specified account. 0x0 No errors.

Error codes can provide a lot of information to the investigator regarding possible user actions. A series of failed 4776 events with Error Code 0xC000006A (the password is invalid) followed by an Error Code 0xC0000234 (the account is locked out) may be suggestive of a failed brute-force attack (or a user who has simply forgotten the account password). Similarly, a series of failed 4776 events followed by a successful 4776 event may indicate a successful brute-force attack. Authentication attempts from restricted workstations (error code 0xC0000070) could indicate intent to access resources off-limits to that user or large-scale network enumeration. The presence of Event ID 4776 on a domain-joined server or client endpoint is indicative of a user attempting to authenticate to a local account on that system and may in and of itself be cause for further investigation.

Tracking Pass-The-Hash Attacks

Pass-The-Hash is an attack technique that allows an attacker to start lateral movement in the network over NTLM protocol, without the need for the user password. Although NTLM authentication is an old authentication method and most of the authentications in the organizations today are based on Kerberos, some applications are still using it and according to Mcrosoft:

"NTLM authentication is still supported and must be used for Windows authentication with systems configured as a member of a workgroup. NTLM authentication is also used for local logon authentication on non-domain controllers. Kerberos version 5 authentication is the preferred authentication method for Active Directory environments, but a non-Microsoft or Microsoft application might still use NTLM."

As NTLM authentication is used legitimately across the network, it is crucial to look at both legitimate and illegitimate NTLM authentications. One of the triggers to use the NTLM protocol is when a client authenticates to a server using an IP address. This is the anchor that can be used to detect Pass-The-Hash attacks over the network – NTLM connections. NTLM connections can be identified by monitoring events ID 4624 (successful logon) with logon type 3 (Network logon) and NTLM authentication package NTLM (or by logon process name NtLmSsp) which indicates the use of NTLM protocol for the authentication.

In credentials theft and utilization of Pass-The-Hash, the malicious actor will have access to the stolen password hash only and use it to complete authentication to remote systems via tools such as Mimikatz and Metasploit. Because a pass‐the‐hash attack uses credentials stolen from another user account, looking for event IDs showing use of explicit credentials (Event ID 4648 or Event ID 4624 with logon type 9) may help confirm suspicions that pass‐the‐hash attacks are in use. If you suspect a system is being used for these types of attacks, you can also look for forensic artifacts of tools that could be used to execute a pass‐the‐hash attack on the host. Detecting pass‐the‐hash attacks can be challenging, and you will usually need multiple data points in order to confirm your suspicions. Often, unusual activity is detected from a specific account, and that account's activities are then scrutinized in more detail in order to detect these types of attacks.

Beginning with the Windows 2003 server, the default authentication protocol in a Windows Domain is Kerberos. Kerberos involves more steps than the NTLM protocol and creates more logs. The steps involved in Kerberos authentication are explained succinctly in the infographic below.

If authentication is successful (the TGT is successfully issued) the event ID 4768 as shown below is generated in the domain controller's security event log.

It is important to note that a 4768 event is AS_REQ monitoring event, not to a TGT ticket. The Keywords field indicates whether the authentication attempt was successful or failed. In the event of a failed authentication attempt, you will see an "Audit Failed" Keywords field with Result Code field not equal to "0x0". This event is not generated for Result Codes: 0x10 and 0x18, event ID 4771: "Kerberos pre-authentication failed" will be generated instead. The Result Code field contains the hexadecimal result code of the AS_REQ validation on the domain controller. For successful AS_REQ requests, when the TGT was issued, it will have a value of 0x0. Possible values for the Result Code are given in the table below.  

Code	Code Name	Description	Possible causes
0x0	KDC_ERR_NONE	No error	No errors were found.
0x1	KDC_ERR_NAME_EXP	Client's entry in KDC database has expired	No information.
0x2	KDC_ERR_SERVICE_EXP	Server's entry in KDC database has expired	No information.
0x3	KDC_ERR_BAD_PVNO	Requested Kerberos version number not supported	No information.
0x4	KDC_ERR_C_OLD_MAST_KVNO	Client's key encrypted in old master key	No information.
0x5	KDC_ERR_S_OLD_MAST_KVNO	Server's key encrypted in old master key	No information.
0x6	KDC_ERR_C_PRINCIPAL_UNKNOWN	Client not found in Kerberos database	The username doesn t exist.
0x7	KDC_ERR_S_PRINCIPAL_UNKNOWN	Server not found in Kerberos database	This error can occur if the domain controller cannot find the server s name in Active Directory. This error is similar to KDC_ERR_C_PRINCIPAL_UNKNOWN except that it occurs when the server name cannot be found.
0x8	KDC_ERR_PRINCIPAL_NOT_UNIQUE	Multiple principal entries in KDC database	This error occurs if duplicate principal names exist. Unique principal names are crucial for ensuring mutual authentication. Thus, duplicate principal names are strictly forbidden, even across multiple realms. Without unique principal names, the client has no way of ensuring that the server it is communicating with is the correct one.
0x9	KDC_ERR_NULL_KEY	The client or server has a null key (master key)	No master key was found for client or server. Usually it means that administrator should reset the password on the account.
0xA	KDC_ERR_CANNOT_POSTDATE	Ticket (TGT) not eligible for postdating	This error can occur if a client requests postdating of a Kerberos ticket. Postdating is the act of requesting that a ticket s start time be set into the future. It also can occur if there is a time difference between the client and the KDC.
0xB	KDC_ERR_NEVER_VALID	Requested start time is later than end time	There is a time difference between the KDC and the client.
0xC	KDC_ERR_POLICY	Requested start time is later than end time	This error is usually the result of logon restrictions in place on a user s account. For example workstation restriction, smart card authentication requirement or logon time restriction.
0xD	KDC_ERR_BADOPTION	KDC cannot accommodate requested option	Impending expiration of a TGT. The SPN to which the client is attempting to delegate credentials isn't in its Allowed-to-delegate-to list
0xE	KDC_ERR_ETYPE_NOTSUPP	KDC has no support for encryption type	This error generally occurs when the KDC or a client receives a packet that it cannot decrypt.
0xF	KDC_ERR_SUMTYPE_NOSUPP	KDC has no support for checksum type	The KDC, server, or client receives a packet for which it does not have a key of the appropriate encryption type. The result is that the computer is unable to decrypt the ticket.
0x10	KDC_ERR_PADATA_TYPE_NOSUPP	KDC has no support for PADATA type (pre-authentication data)	Smart card logon is being attempted and the proper certificate cannot be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted. It can also happen when a domain controller doesn't have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates). This error code cannot occur in event 4768. A Kerberos authentication ticket (TGT) was requested. It occurs in 4771. Kerberos pre-authentication failed event.
0x11	KDC_ERR_TRTYPE_NO_SUPP	KDC has no support for transited type	No information.
0x12	KDC_ERR_CLIENT_REVOKED	Client' s credentials have been revoked	This might be because of an explicit disabling or because of other restrictions in place on the account. For example: account disabled, expired, or locked out.
0x13	KDC_ERR_SERVICE_REVOKED	Credentials for server have been revoked	No information.
0x14	KDC_ERR_TGT_REVOKED	TGT has been revoked	Since the remote KDC may change its PKCROSS key while there are PKCROSS tickets still active, it SHOULD cache the old PKCROSS keys until the last issued PKCROSS ticket expires. Otherwise, the remote KDC will respond to a client with a KRB-ERROR message of type KDC_ERR_TGT_REVOKED. See RFC1510 for more details.
0x15	KDC_ERR_CLIENT_NOTYET	Client not yet valid try again later	No information.
0x16	KDC_ERR_SERVICE_NOTYET	Server not yet valid try again later	No information.
0x17	KDC_ERR_KEY_EXPIRED	Password has expired change password to reset	The user s password has expired.
0x18	KDC_ERR_PREAUTH_FAILED	Pre-authentication information was invalid	The wrong password was provided. This error code cannot occur in event 4768 "A Kerberos authentication ticket (TGT) was requested" . It occurs in 4771. Kerberos pre-authentication failed event.
0x19	KDC_ERR_PREAUTH_REQUIRED	Additional pre-authentication required	This error often occurs in UNIX interoperability scenarios. MIT-Kerberos clients do not request pre-authentication when they send a KRB_AS_REQ message. If pre-authentication is required (the default), Windows systems will send this error. Most MIT-Kerberos clients will respond to this error by giving the pre-authentication, in which case the error can be ignored, but some clients might not respond in this way.
0x1A	KDC_ERR_SERVER_NOMATCH	KDC does not know about the requested server	No information.
0x1D	KDC_ERR_SVC_UNAVAILABLE	KDC is unavailable	No information.
0x1F	KRB_AP_ERR_BAD_INTEGRITY	Integrity check on decrypted field failed	The authenticator was encrypted with something other than the session key. The result is that the client cannot decrypt the resulting message. The modification of the message could be the result of an attack or it could be because of network noise.
0x20	KRB_AP_ERR_TKT_EXPIRED	The ticket has expired	The smaller the value for the Maximum lifetime for user ticket Kerberos policy setting, the more likely it is that this error will occur. Because ticket renewal is automatic, you should not have to do anything if you get this message.
0x21	KRB_AP_ERR_TKT_NYV	The ticket is not yet valid	The ticket presented to the server isn't yet valid (in relationship to the server time). The most probable cause is that the clocks on the KDC and the client are not synchronized. If cross-realm Kerberos authentication is being attempted, then you should verify time synchronization between the KDC in the target realm and the KDC in the client realm, as well.
0x22	KRB_AP_ERR_REPEAT	The request is a replay	This error indicates that a specific authenticator showed up twice the KDC has detected that this session ticket duplicates one that it has already received.
0x23	KRB_AP_ERR_NOT_US	The ticket is not for us	The server has received a ticket that was meant for a different realm.
0x24	KRB_AP_ERR_BADMATCH	The ticket and authenticator do not match	The KRB_TGS_REQ is being sent to the wrong KDC. There is an account mismatch during protocol transition.
0x25	KRB_AP_ERR_SKEW	The clock skew is too great	This error is logged if a client computer sends a timestamp whose value differs from that of the server s timestamp by more than the number of minutes found in the Maximum tolerance for computer clock synchronization setting in Kerberos policy.
0x26	KRB_AP_ERR_BADADDR	Network address in network layer header doesn't match address inside ticket	Session tickets MAY include the addresses from which they are valid. This error can occur if the address of the computer sending the ticket is different from the valid address in the ticket. A possible cause of this could be an Internet Protocol (IP) address change. Another possible cause is when a ticket is passed through a proxy server or NAT. The client is unaware of the address scheme used by the proxy server, so unless the program caused the client to request a proxy server ticket with the proxy server's source address, the ticket could be invalid.
0x27	KRB_AP_ERR_BADVERSION	Protocol version numbers don't match (PVNO)	When an application receives a KRB_SAFE message, it verifies it. If any error occurs, an error code is reported for use by the application. The message is first checked by verifying that the protocol version and type fields match the current version and KRB_SAFE, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION. See RFC4120 for more details.
0x28	KRB_AP_ERR_MSG_TYPE	Message type is unsupported	This message is generated when target server finds that message format is wrong. This applies to KRB_AP_REQ, KRB_SAFE, KRB_PRIV and KRB_CRED messages. This error also generated if use of UDP protocol is being attempted with User-to-User authentication.
0x29	KRB_AP_ERR_MODIFIED	Message stream modified and checksum didn't match	The authentication data was encrypted with the wrong key for the intended server. The authentication data was modified in transit by a hardware or software error, or by an attacker. The client sent the authentication data to the wrong server because incorrect DNS data caused the client to send the request to the wrong server. The client sent the authentication data to the wrong server because DNS data was out-of-date on the client.
0x2A	KRB_AP_ERR_BADORDER	Message out of order (possible tampering)	This event generates for KRB_SAFE and KRB_PRIV messages if an incorrect sequence number is included, or if a sequence number is expected but not present. See RFC4120 for more details.
0x2C	KRB_AP_ERR_BADKEYVER	Specified version of key isn't available	This error might be generated on server side during receipt of invalid KRB_AP_REQ message. If the key version indicated by the Ticket in the KRB_AP_REQ isn't one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.
0x2D	KRB_AP_ERR_NOKEY	Service key not available	This error might be generated on server side during receipt of invalid KRB_AP_REQ message. Because it is possible for the server to be registered in multiple realms, with different keys in each, the realm field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to specify which secret key the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the proper key to decipher the ticket.
0x2E	KRB_AP_ERR_MUT_FAIL	Mutual authentication failed	No information.
0x2F	KRB_AP_ERR_BADDIRECTION	Incorrect message direction	No information.
0x30	KRB_AP_ERR_METHOD	Alternative authentication method required	According to RFC4120 this error message is obsolete.
0x31	KRB_AP_ERR_BADSEQ	Incorrect sequence number in message	No information.
0x32	KRB_AP_ERR_INAPP_CKSUM	Inappropriate type of checksum in message (checksum may be unsupported)	When KDC receives KRB_TGS_REQ message it decrypts it, and after that, the user-supplied checksum in the Authenticator MUST be verified against the contents of the request. The message MUST be rejected either if the checksums do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum isn't collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM).
0x33	KRB_AP_PATH_NOT_ACCEPTED	Desired path is unreachable	No information.
0x34	KRB_ERR_RESPONSE_TOO_BIG	Too much data	The size of a ticket is too large to be transmitted reliably via UDP. In a Windows environment, this message is purely informational. A computer running a Windows operating system will automatically try TCP if UDP fails.
0x3C	KRB_ERR_GENERIC	Generic error	Group membership has overloaded the PAC. Multiple recent password changes have not propagated. Crypto subsystem error caused by running out of memory. SPN too long. SPN has too many parts.
0x3D	KRB_ERR_FIELD_TOOLONG	Field is too long for this implementation	Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over the TCP stream is preceded by the length of the request as 4 octets in network byte order. The high bit of the length is reserved for future expansion and MUST currently be set to zero. If a KDC that does not understand how to interpret a set high bit of the length encoding receives a request with the high order bit of the length set, it MUST return a KRB-ERROR message with the error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
0x3E	KDC_ERR_CLIENT_NOT_TRUSTED	The client trust failed or isn't implemented	This typically happens when user s smart-card certificate is revoked or the root Certification Authority that issued the smart card certificate (in a chain) isn't trusted by the domain controller.
0x3F	KDC_ERR_KDC_NOT_TRUSTED	The KDC server trust failed or could not be verified	The trustedCertifiers field contains a list of certification authorities trusted by the client, in the case that the client does not possess the KDC's public key certificate. If the KDC has no certificate signed by any of the trustedCertifiers, then it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. See RFC1510 for more details.
0x40	KDC_ERR_INVALID_SIG	The signature is invalid	This error is related to PKINIT. If a PKI trust relationship exists, the KDC then verifies the client's signature on AuthPack (TGT request signature). If that fails, the KDC returns an error message of type KDC_ERR_INVALID_SIG.
0x41	KDC_ERR_KEY_TOO_WEAK	A higher encryption level is needed	If the clientPublicValue field is filled in, indicating that the client wishes to use Diffie-Hellman key agreement, then the KDC checks to see that the parameters satisfy its policy. If they do not (e.g., the prime size is insufficient for the expected encryption type), then the KDC sends back an error message of type KDC_ERR_KEY_TOO_WEAK.
0x42	KRB_AP_ERR_USER_TO_USER_REQUIRED	User-to-user authorization is required	In the case that the client application doesn't know that a service requires user-to-user authentication, and requests and receives a conventional KRB_AP_REP, the client will send the KRB_AP_REP request, and the server will respond with a KRB_ERROR token as described in RFC1964, with a msg-type of KRB_AP_ERR_USER_TO_USER_REQUIRED.
0x43	KRB_AP_ERR_NO_TGT	No TGT was presented or available	In user-to-user authentication, if the service does not possess a ticket-granting   ticket, it should return the error KRB_AP_ERR_NO_TGT.
0x44	KDC_ERR_WRONG_REALM	Incorrect domain or principal	Although this error rarely occurs, it occurs when a client presents a cross-realm TGT to a realm other than the one specified in the TGT. Typically, this results from incorrectly configured DNS.

There are differences between certain fields in the 4768 Audit Success and 4768 Audit Failure events, that the reader should be aware of:

• The User ID field in a 4768 Audit Failure event always has a value of S-1-0-0 (NULL SID)
• The Service ID field in a 4768 Audit Failure event always has a value of S-1-0-0 (NULL SID)
•  The Ticket Encryption Type field in a 4768 Audit Failure event always has a value of 0xFFFFFFFF.
• The Pre-Authentication Type field in a 4768 Audit Failure event always has a value of -

The 4768 Audit Failure event shown below has a Result Code value of 0x6, which means an authentication attempt using an invalid username.

The Event ID 4771 is generated for AS_REQ requests that fail with Result Code 0x10 (smart card authentication-related issues) or 0x18 (wrong or expired password).  For scenarios with different Result Codes (with exception of  0x0), a 4768 Audit Failure event is generated in the domain controller's security event log. If a 4771 event is generated, no 4768 Audit Failure event is generated.

Aside the Failure Code, most of the fields in Event ID 4771 have the same meaning with their corresponding Event ID 4768 counterparts. The list of 4771 event failure code hexadecimal values that can be encountered in your investigation are given in the table below:

Code	Code Name	Description	Possible causes
0x0	KDC_ERR_NONE	No error
0x1	KDC_ERR_NAME_EXP	Client's entry in database has expired
0x2	KDC_ERR_SERVICE_EXP	Server's entry in database has expired
0x3	KDC_ERR_BAD_PVNO	Requested protocol version number not supported
0x4	KDC_ERR_C_OLD_MAST_KVNO	Client's key encrypted in old master key
0x5	KDC_ERR_S_OLD_MAST_KVNO	Server's key encrypted in old master key
0x6	KDC_ERR_C_PRINCIPAL_UNKNOWN	Client not found in Kerberos database
0x7	KDC_ERR_S_PRINCIPAL_UNKNOWN	Server not found in Kerberos database
0x8	KDC_ERR_PRINCIPAL_NOT_UNIQUE	Multiple principal entries in database
0x9	KDC_ERR_NULL_KEY	The client or server has a null key
0xa	KDC_ERR_CANNOT_POSTDATE	Ticket not eligible for postdating
0xb	KDC_ERR_NEVER_VALID	Requested starttime is later than end time
0xc	KDC_ERR_POLICY	KDC policy rejects request
0xd	KDC_ERR_BADOPTION	KDC cannot accommodate requested option
0xe	KDC_ERR_ETYPE_NOSUPP	KDC has no support for encryption type
0xf	KDC_ERR_SUMTYPE_NOSUPP	KDC has no support for checksum type
0x10	KDC_ERR_PADATA_TYPE_NOSUPP	KDC has no support for PADATA type (pre-authentication data)	Smart card logon is being attempted and the proper certificate cannot be located. This problem can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted in order to get Domain Controller or Domain Controller Authentication certificates for the domain controller. It can also happen when a domain controller doesn't have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates).
0x11	KDC_ERR_TRTYPE_NOSUPP	KDC has no support for transited type
0x12	KDC_ERR_CLIENT_REVOKED	Clients credentials have been revoked
0x13	KDC_ERR_SERVICE_REVOKED	Credentials for server have been revoked
0x14	KDC_ERR_TGT_REVOKED	TGT has been revoked
0x15	KDC_ERR_CLIENT_NOTYET	Client not yet valid; try again later
0x16	KDC_ERR_SERVICE_NOTYET	Server not yet valid; try again later
0x17	KDC_ERR_KEY_EXPIRED	Password has expired change password to reset	The user's password has expired.
0x18	KDC_ERR_PREAUTH_FAILED	Pre-authentication information was invalid	The wrong password was provided.
0x19	KDC_ERR_PREAUTH_REQUIRED	Additional pre-authentication required
0x1a	KDC_ERR_SERVER_NOMATCH	Requested server and ticket don't match
0x1b	KDC_ERR_MUST_USE_USER2USER	Server principal valid for user2user only
0x1c	KDC_ERR_PATH_NOT_ACCEPTED	KDC Policy rejects transited path
0x1d	KDC_ERR_SVC_UNAVAILABLE	A service is not available
0x1f	KRB_AP_ERR_BAD_INTEGRITY	Integrity check on decrypted field failed
0x20	KRB_AP_ERR_TKT_EXPIRED	Ticket expired
0x21	KRB_AP_ERR_TKT_NYV	Ticket not yet valid
0x22	KRB_AP_ERR_REPEAT	Request is a replay
0x23	KRB_AP_ERR_NOT_US	The ticket isn't for us
0x24	KRB_AP_ERR_BADMATCH	Ticket and authenticator don't match
0x25	KRB_AP_ERR_SKEW	Clock skew too great
0x26	KRB_AP_ERR_BADADDR	Incorrect net address
0x27	KRB_AP_ERR_BADVERSION	Protocol version mismatch
0x28	KRB_AP_ERR_MSG_TYPE	Invalid msg type
0x29	KRB_AP_ERR_MODIFIED	Message stream modified
0x2a	KRB_AP_ERR_BADORDER	Message out of order
0x2c	KRB_AP_ERR_BADKEYVER	Specified version of key is not available
0x2d	KRB_AP_ERR_NOKEY	Service key not available
0x2e	KRB_AP_ERR_MUT_FAIL	Mutual authentication failed
0x2f	KRB_AP_ERR_BADDIRECTION	Incorrect message direction
0x30	KRB_AP_ERR_METHOD	Alternative authentication method required
0x31	KRB_AP_ERR_BADSEQ	Incorrect sequence number in message
0x32	KRB_AP_ERR_INAPP_CKSUM	Inappropriate type of checksum in message
0x33	KRB_AP_PATH_NOT_ACCEPTED	Policy rejects transited path
0x34	KRB_ERR_RESPONSE_TOO_BIG	Response too big for UDP; retry with TCP
0x3c	KRB_ERR_GENERIC	Generic error (description in e-text)
0x3d	KRB_ERR_FIELD_TOOLONG	Field is too long for this implementation
0x3e	KDC_ERROR_CLIENT_NOT_TRUSTED	Reserved for PKINIT
0x3f	KDC_ERROR_KDC_NOT_TRUSTED	Reserved for PKINIT
0x40	KDC_ERROR_INVALID_SIG	Reserved for PKINIT
0x41	KDC_ERR_KEY_TOO_WEAK	Reserved for PKINIT
0x42	KDC_ERR_CERTIFICATE_MISMATCH	Reserved for PKINIT
0x43	KRB_AP_ERR_NO_TGT	No TGT available to validate USER-TO-USER
0x44	KDC_ERR_WRONG_REALM	Reserved for future use
0x45	KRB_AP_ERR_USER_TO_USER_REQUIRED	Ticket must be for USER-TO-USER
0x46	KDC_ERR_CANT_VERIFY_CERTIFICATE	Reserved for PKINIT
0x47	KDC_ERR_INVALID_CERTIFICATE	Reserved for PKINIT
0x48	KDC_ERR_REVOKED_CERTIFICATE	Reserved for PKINIT
0x49	KDC_ERR_REVOCATION_STATUS_UNKNOWN	Reserved for PKINIT
0x4a	KDC_ERR_REVOCATION_STATUS_UNAVAILABLE	Reserved for PKINIT
0x4b	KDC_ERR_CLIENT_NAME_MISMATCH	Reserved for PKINIT
0x4c	KDC_ERR_KDC_NAME_MISMATCH	Reserved for PKINIT

Tracking Changes to Accounts and Security Settings

Several types of events within the Security log record changes to user accounts and security policies. Reviewing these events can help you determine whether an attacker has tampered with a system’s security settings:

• Account management events indicate whether a user account has been created, deleted, enabled, or disabled, as well as similar changes to account groups
• Policy change events capture changes to system security settings, including the audit policies that specify what is recorded in event logs.

Subcategory	Event ID	Notes
Application Group Management	4783	A basic application group was created
	4784	A basic application group was changed
	4785	A member was added to a basic application group
	4786	A member was removed from a basic application group
	4787	A non-member was added to a basic application group
	4788	A non-member was removed from a basic application group
	4789	A basic application group was deleted
	4790	An LDAP query group was created
	4791	A basic application group was changed
	4792	An LDAP query group was deleted
Computer Account Management	4741	A computer account was created
	4742	A computer account was changed
	4743	A computer account was deleted
Distribution Group Management	4744	A security-disabled local group was created
	4745	A security-disabled local group was changed
	4746	A member was added to a security-disabled local group
	4747	A member was removed from a security-disabled local group
	4748	A security-disabled local group was deleted
	4749	A security-disabled global group was created
	4750	A security-disabled global group was changed
	4751	A member was added to a security-disabled global group
	4752	A member was removed from a security-disabled global group
	4753	A security-disabled global group was deleted
	4759	A security-disabled universal group was created
	4760	A security-disabled universal group was changed
	4761	A member was added to a security-disabled universal group
	4762	A member was removed from a security-disabled universal group
	4763	A security-disabled universal group was deleted
Other Account Management Events	4739	Domain policy was changed
	4782	The Password Policy Checking API was called

Tracking Reconnaisance: Account and Group Enumeration

Windows 10 and Server 2016 added a new set of events designed to track enumeration of sensitive accounts and groups in the enterprise. 

• 4798 - A user’s local group membership was enumerated.
• 4799 - A security-enabled local group membership was enumerated.

Powerview and Bloodhound are tools employed by adversaries to enumerate privileged users and groups in an Active Directory environment. These events can be used to investigate  who is running what process to enumerate privileged users and groups. 

These events can be enabled by the System Administrator via Group Policy Advanced Auditing → Account Management, and are named “Audit Security Group Management” and “Audit User Account Management”. 

A large amount of normal account enumeration occurs in Windows, and hence these events will need to be filtered to be useful. Investigators should focus on sensitive groups, accounts that should not be used for enumeration activities, and unusual processes being used for the enumeration (PowerShell, WMI, or net use commands via cmd.exe). Performing a tuning process and whitelisting common processes like mmc.exe, services.exe, taskhostw.exe, explorer.exe, and VSSSVC.exe can greatly reduce the volume of events.

Tracking Lateral Movement: Network Share

Network shares are a common vector for both legitimate file sharing and malicious activities such as lateral movement and data exfiltration. Monitoring and analyzing Windows event logs can help detect unauthorized access, suspicious file operations, and potential threats.

The system Administrator can audit network share in the Group Policy Management Console by navigating to Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Object Access → Audit File Share.  If file share auditing is turned on, the following Event IDs will be logged in the Security Log:

Event ID	Description
5140	A network share object was accessed. The event entry provides the account name and source address of the account that accessed the object. Note that this entry will show that the share was accessed but not what files in the share were accessed. A large number of these events from a single account may be an indicator of an account being used to harvest or map data on the network.
5142	A network share object was added.
5143	A network share object was modified.
5144	A network share object was deleted.
5145	A network share object was checked to see whether client can be granted desired access. Failure is only logged if the permission is denied at the file share level. If permission is denied at the NTFS level, then no entry is recorded.

The 5140 event for the ADMIN$ connection should be correlated with the 5140 event for the IPC$ connection, if possible. IPC$ Share is often used first for authentication when an attacker attempts to connect remotely via SMB. If authentication succeeds, the attacker may then access ADMIN$ to execute remote commands, move files, and/or launch malware. A connection to an IPC$ share only achieves authentication and cannot be used to move files and the subsequent connection to the ADMIN$ share is what facilitates actual lateral movement. That being said, if you see an IPC$ share mapped by itself with user credentials it can still be indicative of some tool or process used to enumerate information and the source address could be worth looking into (assuming it is not legitimate administration activity).

One limitation of Event ID 5140 is that it does not include references to files accessed on a given share. To get this information, detailed file auditing should be enabled by the System Administrator in the Group Policy Management Console by navigating to Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Object Access → Audit Detailed File Share. This provides 5145 Events, which record individual item access. However, this level of auditing can be voluminous and hence should be used very tactically and likely enabled only for very sensitive systems. 

Tracking Lateral Movement: Scheduled Tasks

Threat Actors can leverage the built‐in Windows at and schtasks commands to both expand their influence and maintain persistence within a victim environment. The %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational log debuted in Windows 7 providing a custom log dedicated only to tracking scheduled tasks. As such, entries persist in this log much longer than they will in the Security log, making it a great place to find old attacker activity and tradecraft. Event IDs to look for in this log are given in the table below:

Event ID	Description
106	Scheduled Task Created
140	Scheduled Task Updated
141	Scheduled Task Deleted
200	Scheduled Task Executed
201	Scheduled Task Completed

Scheduled task logging in the Security log requires Object access auditing to be enabled and provides even more detailed information. Five events are used to record activity in the Security log:

Event ID	Description
4698	Scheduled Task Created
4699	Scheduled Task Deleted
4700	Scheduled Task Enabled
4701	Scheduled Task Disabled
4702	Scheduled Task Updated

It is important to understand that tasks can be scheduled remotely. This makes this artifact even more interesting, as it can be used by attackers for both persistence and lateral movement. Unfortunately, the task scheduler logs do not differentiate between local and remotely scheduled tasks. To find remote tasks, you must look for Type 3 (network) Logon authentication events (ID 4624) occurring very near the time of task creation. Automating triggers looking for this combination of events can pay dividends for analysts and hunt teams. 

Another high-fidelity alert to hunt for are deleted tasks. It is common for attackers to schedule tasks on a variety of systems and then clean up those tasks after execution. Deleted tasks are quite rare in most environments or are easy to filter for legitimate applications, leaving only the deleted evil tasks to be identified.