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.

Merys R

Security Engineer at Critical Start

You may also be interested in…

Stay Connected on Today’s Cyber Threat Landscape

Windows Security Event Logs – What to Monitor?

Valuable, but Expensive

4657 Registry Keys to Monitor

You may also be interested in…

RELATED RESOURCES

RESOURCE CATEGORIES