Windows Security Event Logs – What to Monitor?

The following is a table of event codes that I’ve found to be extremely valuable to log and monitor in an environment. Some trend more towards general environment health and activity monitoring, however they all have a foothold in security value as well. As always, your environment’s needs and requirements will be different depending on a multitude of other factors such as compliance and log retention, and these should be taken into consideration when choosing what to log – and for how long. The logging volume of these event codes will also depend on the size of your environment, so this should also be considered. 

Event Code 
Description 
Why collect? 
1102 
Audit log cleared 
A common strategy for attackers once in an environment is to cover their tracks. While some attackers are sophisticated and will use equally sophisticated – and manual – methods to accomplish this, many attackers will just blast the Windows audit log away. 
1104 
Security log is now full 
For this event and 1108, we want to make sure we’re collecting security logs at all times. A cessation in logging can cause a major headache for investigations, compliance, etc –  most importantly, you can’t know what you don’t see. 
1108 
Event logging service error 
See above, though this one is less common. 
4624 
Account successfully logged on 
Monitor this event code in tandem with 4625 – all the failed authentications in the world will mean nothing if you don’t know if it was ever successful or not. 
4625 
Account failed to log on 
A bread and butter security event to monitor, this lets you detect all sorts of potentially malicious behavior as brute force attacks are some of the most common out there. 
4648 
A logon was attempted using explicit credentials 
This is good to track for monitoring where credentials are being used explicitly. It doesn’t necessarily indicate a security risk, however it’s good to keep an eye on where these are coming from. 
4672 
Special privileges assigned to new logon 
This event is a bit confusing in its name – it’s not denoting that a logon has been given special privileges, more that an account that has special privileges has logged on – so you’ll see this in tandem with 4624 events. This should be monitored to detect rogue superuser accounts or over-privileged accounts. 
4698 
Scheduled task created 
Attackers and malicious programs will frequently create scheduled tasks to provide them persistence within an environment. By monitoring this event along with 4700 you can watch for suspicious or unknown scheduled tasks being created.  
4700 
Scheduled task enabled 
See 4698 
4720 
User account created 
This is more of an environment tracking event code, however attackers will sometimes create accounts for them to utilize and pivot from if they’ve gained an amount of access. These should be tracked both to detect that activity and to just generally see what’s going on in your environment. 
4723 
An attempt was made to change the password of an account 
Due to how Windows logs, this event probably doesn’t mean what you think it does. It detects a user attempting to change their own password, not that of another account – most times you’ll see this will be when a user is failing to change their password due to the new password not meeting the password policy. As such you may want to monitor this only for accounts that should never be having their password changed. 
4725 
User account disabled 
More of an environment review event code as the disabling of an account is usually not what attackers are aiming to do. However it can help to detect anomalous activity that should be investigated. 
4727 
Group created (global) 
This along with other group creations should be monitored mostly for environment review, however attackers will sometimes create groups to pivot from or to give multiple accounts footholds should one of them be taken down. 
4728 
User added to global group 
See 4727 
4731 
Group created (local) 
See 4727 
4732 
User added to local group 
See 4727 
4740 
Account locked out 
This is a valuable event code to monitor for privileged accounts as it gives us a good indicator that someone may be trying to gain access to it. This code can also indicate when there’s a misconfigured password that may be locking an account out, which we want to avoid as well. Also, your guess is as good as mine as to why this is located in the middle of the group change events.  
4754 
Group created (universal) 
See 4727 
4756 
User added to universal group 
See 4727 
4767 
User account unlocked 
See 4727 
4768 
Kerberos authentication ticket was requested 
Kerberos authentication event codes should be monitored in the same way 4625 and 4624 authentication events are. These Kerberos event codes will tend to give you a clearer picture on the entire logon attempt process, including at what point in the process the logon failed – pre-authentication or post. 
4771 
Kerberos preauthentication failed 
This event code should be logged and treated similarly to 4625 events, as they represent the other “half” of authentication failures. Windows has different rules for when a 4625 vs a 4771 is logged, and it represents a much more in depth authentication discussion. For our purposes here, know that 4771s will be loud (think cached passwords) but that they can be refined down by keying off their result code field. 
4776 
The domain controller attempted to validate the credentials for an account 
Bit of a misnomer on this one – this event will fire from workstations and servers in the same way it’d fire from a domain controller. This is also the event code you’ll see if something is authenticated via NTLM rather than Kerberos, so it’s also important to include in your authentication logging 
4780 
The ACL was set on accounts which are members of administrators groups 
Equal parts environment review and security risk, we want to investigate these to see why the ACL was changed for these accounts and to ensure it was both intentional and permitted.  
4782 
The password hash of an account was accessed 
Monitor these as hash accesses should be planned, and unplanned hash accesses may represent a security risk or malicious activity 
4798 
A user’s local group membership was enumerated 
For this and 4799, a group’s membership being checked can be a sign of suspicious behavior, as many attackers – once gaining access to an account – will aim to check how valuable their accessed account is. We want to monitor this behavior and note the process name that’s calling this action, as some are expected to be doing this while others are not (mmc.exe vs cain.exe) 
4799 
A security-enabled local group membership was enumerated 
See 4798 

Valuable, but Expensive 

These are Windows event codes that can be prohibitively expensive to log, as they can generate hundreds of events in a short period of time. However they provide a great level of insight into an environment, so if disk space – or log ingestion into a SIEM – allows for these to be collected, I encourage them to be logged.  

Event Code
Description
Why?
4657 
A registry value was changed 
A loud event code, this is still very valuable to detect suspicious registry value changes, as another common foothold for persistence is for attackers to alter or add a registry key. There are some key areas in the Windows registry that these footholds would be placed to be most effective – startup registry keys “run” and “run once” – so you can narrow your scope to just these registry paths if needed. See section below, “4657 Registry Keys to Monitor” 
4688 
New process was created 
This will allow you to see any and all new processes that are run in the environment. If that sounds incredibly noisy, it is – however it provides an amazing insight into an endpoint. Additionally you can enable it to include process command line arguments, which allows for endpoint visibility not usually seen without a paid-for tool. If your disk space – or license if ingesting into a SIEM platform – allows for this event code with command line to be ingested, I do suggest it, however it is extremely loud. 
4697 
An attempt was made to install a service 
This event code would be very loud to monitor across all areas, so we want to ensure it’s monitored on critical or otherwise sensitive systems. Service installations should be planned and there are services that attackers would want to install on a high value system. The service type field should be monitored to determine the access level of this new service, while the service start type field should be monitored for how the service is set to run. 

4657 Registry Keys to Monitor 

Below are some very solid registry keys to monitor, all of which cover the persistence methods discussed above. Rather than log all registry changes, instead focus on these locations to best detect suspicious registry behavior. Credit goes to Mitre ATT&CK for these, I’ve pulled out the paths below – https://attack.mitre.org/techniques/T1547/001/ 

Run at startup keys: 

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce 
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run 
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce 

Startup folder items:  

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders 
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders 
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders 
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders 

Automatic service startups: 

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce 
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce 
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices 
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices  

Policy-driven startup programs: 

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run 
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run 

User Logon Program Launch – within “load” value: 

  • HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows  

Autocheck launch – within BootExecute value 

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager 
    • This last one is interesting as it’s the path of the automatic disk checking service Microsoft employs upon abnormal shutdowns. Since it’s an automatic function, attackers realized they can adjust this value to also add that same automatic run functionality to their program/process for persistence. It’s pretty cool!  

And there you have it! While not a comprehensive end-all-be-all list, these are the Windows event codes I recommend to a customer looking for a “base-line coverage” of security logging. We didn’t cover Application or System logs as they’re out of scope for this specific article, but I may review those in a future posting. For now, happy logging! 

Originally posted by Merys R, Security Engineer at CRITICALSTART, on LinkedIn.


You may also be interested in…

Stay Connected on Today’s Cyber Threat Landscape

  • Hidden
  • Hidden
  • Hidden
  • Hidden
  • Hidden
  • Hidden
  • Hidden
  • Hidden
©2020 CRITICALSTART. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
©2021 CRITICALSTART. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.