IT Update – Windows Event Monitoring: Configuring Your Program

If you have combed through Windows event logs looking for suspicious activity, you know this needle in a haystack approach is not a very effective use of your time. Depending on the size of your environment, Windows can be recording gigabytes of log entries daily. So, how do you implement an effective, efficient network monitoring program that is also cost effective? Fortunately, there are many available tools and services that can help focus your efforts on high-risk areas. But before you consider a third-party tool for monitoring network events, let’s first make sure the important network events are being logged and retained for initial monitoring, as well as for forensics purposes if a potential breach is suspected.

Every event in your Windows network can be captured in the event log depending on the audit settings defined within your environment. By default, Windows does not log most events, so you must specify which event categories to record. Event audit settings can be defined within group policy by main categories (basic settings) or by more detailed event subcategories (advanced settings). It is important to understand that once you define even one advanced event setting, any defined basic settings are no longer in effect. Also, any categories or subcategories of events that are not specifically defined in your group policies will be assigned the Windows default setting, which is typically “no auditing.” To ensure the events you intend to record are in fact recorded in the logs, Snodgrass recommends using the advanced audit settings and defining every event subcategory. Even if you do not want to record certain categories of events, set those categories to “no auditing,” so your intentions are clearly documented. There is a balance to be struck to record the events that have value for monitoring or forensic investigation purposes and those that just use unnecessary disk space without providing much value. Microsoft provides some configuration suggestions ( depending on the security requirements of your organization, but even some of these recommendations may fall short in areas, such as Policy Change and Object Access, and/or forensically if a breach were to occur.

We recommend visiting, where you can view logging and monitoring resources and a security log encyclopedia that explains each event and its potential usefulness ( Your event audit policies should be set based upon the security needs of you network. It is also good governance to vet your planned event settings through your IT oversight committee. The following chart shows recommendations that can be used as a good starting point when configuring your event policy.

Audit Policy Category or Subcategory MS Stronger Recommendation Snodgrass


Success Failure Success Failure
Account Logon
Audit Credential Validation YES YES YES YES
Audit Kerberos Authentication Service YES YES YES YES
Audit Kerberos Service Ticket Operations YES YES YES YES
Audit Other Account Logon Events YES YES YES YES
Account Management
Audit Application Group Management YES YES
Audit Computer Account Management YES YES YES YES
Audit Distribution Group Management YES YES
Audit Other Account Management Events YES YES YES YES
Audit Security Group Management YES YES YES YES
Audit User Account Management YES YES YES YES
Detailed Tracking
Audit DPAPI Activity YES YES NO NO
Audit Process Creation YES YES YES YES
Audit Process Termination YES YES
Audit RPC Events YES YES
DS Access
Audit Detailed Directory Service Replication NO NO
Audit Directory Service Access DC* DC YES YES
Audit Directory Service Changes DC DC YES YES
Audit Directory Service Replication NO NO
Logon and Logoff
Audit Account Lockout YES NO YES YES
Audit IPsec Extended Mode NO NO
Audit IPsec Main Mode IF** IF NO NO
Audit IPsec Quick Mode NO NO
Audit Logoff YES NO YES YES
Audit Network Policy Server YES YES
Audit Other Logon/Logoff Events YES YES YES YES
Audit Special Logon YES YES YES YES
Object Access
Audit Application Generated YES YES
Audit Certification Services YES YES
Audit Detailed File Share YES YES
Audit File Share YES YES
Audit File System YES YES
Audit Filtering Platform Connection NO NO
Audit Filtering Platform Packet Drop NO NO
Audit Handle Manipulation NO NO
Audit Kernel Object YES YES
Audit Other Object Access Events YES YES
Audit Registry YES YES
Audit Removable Storage YES YES
Audit Central Access Policy Staging YES YES
Policy Change
Audit Audit Policy Change YES YES YES YES
Audit Authentication Policy Change YES YES YES YES
Audit Authorization Policy Change YES YES
Audit Filtering Platform Policy Change NO NO
Audit MPSSVC Rule-Level Policy Change YES NO NO
Audit Other Policy Change Events YES YES
Privilege Use
Audit Non-Sensitive Privilege Use NO NO
Audit Other Privilege Use Events NO NO
Audit Sensitive Privilege Use YES YES YES YES
Audit IPsec Driver YES YES NO NO
Audit Other System Events NO YES
Audit Security State Change YES YES YES YES
Audit Security System Extension YES YES YES YES
Audit System Integrity YES YES YES YES
* Setting of YES, YES applies only to a domain controller

**Enable if needed for a specific scenario, or if a role or feature for which auditing is desired is installed on the machine

Once you have defined the audit policies within your environment, you should periodically check to make sure events are recording in accordance with your intentions. From a command prompt, you can run the Auditpol command to list the effective policy for that computer. Since settings can differ among domain controllers, member servers, and workstations, the command should be run on a sample of these machines. The syntax is: auditpol /get /category:* >> C:\\auditpol.txt (or specify the output file and path of your choosing). For more information on the Auditpol command syntax, see the following article:

Another aspect of event monitoring to consider is log retention. You can retain the native logs from Windows or rely on a third-party security information and event management (SIEM) tool to pull and retain events from the native logs. If you do not have a SIEM tool, we recommend archiving the native logs and retaining the logs based upon your forensic and regulatory requirements for your organization.  For example, while GLBA does not specifically dictate a requirement for audit logs, it has a general six-year retention requirement. PCI DSS explicitly requires the retention of audit trail history for at least one year with at least three months of history being immediately available for analysis. Through Administrative Tools, you can set the Event Viewer retention properties for your logs. If you have a SIEM product that pulls events from the native logs, your settings should ensure events are not being overwritten before they are captured. Fortunately, most SIEM products pull events in real-time from the logs, but if you are unsure of the process, consult your SIEM tool vendor. If you are retaining the native logs, we recommend setting the log to archive rather than to overwrite, as seen in the setting below.


Now that you are recording the right events and retaining them per your retention requirements, you will need to determine which events are important for ongoing monitoring purposes. In addition to login and logout events, there are events that record changes to your security environment that should be monitored. Unexpected administrator level events, such as changes to accounts, groups, or policies should be included in your monitoring. There are numerous resources that provide guidance in this area. So, depending on your own monitoring requirements, these recommendations are a good starting point to use in defining your own event reporting requirements.

Microsoft provides the following guidance in this area:–events-to-monitor.

Also, recommends including the following events in your reviews:

4624/4625 – Logon locally where user is “Administrator”

4697 – A service was installed in the system

4704 – Authorization Policy Change assigned

4705 – Authorization Policy Change removed

4717 – System security access was granted to an account

4718 – System security access was removed from an account

4719 – Audit Policy change

4720 – A user account was created

4722 – A user account was enabled

4724 – An attempt was made to reset an account’s password

4725 – A user account was disabled

4726 – A user account was deleted

4731 – A security-enabled local group was created

4732 – A member was added to a security-enabled local group

4733 – A member was removed from a security-enabled local group

4734 – A security-enabled local group was deleted

4735 – A security-enabled local group was changed

4738 – A user account was changed

4739 – Other account management events

4740 – A user account was locked out

4767 – A user account was unlocked

4781 – The name of an account was changed

4798 – A user’s local group membership was enumerated

4799 – A security-enabled local group membership was enumerated

4946 – A change has been made to Windows Firewall exception list. A rule was added

4947 – A change has been made to Windows Firewall exception list. A rule was modified

4948 – A change has been made to Windows Firewall exception list. A rule was deleted

6416 – A new external device was recognized by the system

Once you have defined the events to review, you should establish a monitoring procedure that establishes the responsibility, frequency, and the method for the review. Depending on the volume of events you plan to review, you will need to decide on whether event reports or alerts will be used for the review. For a timely and consistent monitoring process, event alerts are the preferred approach. Since the recommended events include various administrator-level activities, the review should be performed by someone who does not have administrator responsibilities on the network. If this is not possible, a dual review should be established. If follow-up is needed on the events being reported, there should be a documented process for investigating and clearing possible unauthorized events. If unauthorized activities are identified through the review, you should have a documented incident response plan to follow.

A properly planned and configured security monitoring process is a critical component of your security program. The goal is to streamline the process to focus on the critical network events for early detection of suspicious activities. There are many other important security functions to perform without spending time hunting through event logs looking for that needle in the haystack.



Related Posts

IT Update – VMware Reemerging Risks

The importance of keeping up to date with patching on your company’s network systems and applications cannot be understated. This applies especially to any internet-facing

Compliance Update, First Quarter 2023

Changes to Home Mortgage Disclosure Act (HMDA)’s Closed-end Loan Reporting Threshold On September 23, 2022, the United States District Court for the District of Columbia