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_USERSoftwareMicrosoftWindowsCurrentVersionRun
- HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnce
- HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun
- HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce
Startup folder items:
- HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders
- HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders
- HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionExplorerShell Folders
- HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionExplorerUser Shell Folders
Automatic service startups:
- HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServicesOnce
- HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunServicesOnce
- HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServices
- HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunServices
Policy-driven startup programs:
- HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerRun
- HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerRun
User Logon Program Launch – within “load” value:
- HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows
Autocheck launch – within BootExecute value
- HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession 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.
*** This is a Security Bloggers Network syndicated blog from Blog – Critical Start authored by Jason Bessonette. Read the original post at: https://www.criticalstart.com/windows-security-event-logs-what-to-monitor/
