Logging is a Discipline, Not a Switch

Practical Guidance on Logging, Auditing, Monitoring, and Alerting in Active Directory 

Across the Active Directory (AD) assessments we run, logging and auditing gaps come up again and again. This is  usually because logging is treated as a switch to flip rather than something to tune and maintain. Logging crosses multiple teams and nobody owns the question of whether the data being collected would actually catch an intrusion. 

This blog walks through a successful logging program in the order it should be built. 

1. Configure the logs so they can hold what you collect. 
2. Configure what gets collected. 
3. Define what you are trying to detect. 
4. Test whether you can detect it. 

Step One: Log Behavior and Size 

Before touching audit policy, make sure the logs themselves can hold the volume you are about to generate. These settings live in Group Policy: Computer Configuration > Administrative Templates. 

Set Control Event Log behavior when the log file reaches its maximum size on all domain controllers to Disabled for the Application, Security, Setup, and System logs. Disabled means the log rolls and keeps collecting new events once it hits maximum size. This is already the default behavior. In most cases you'll be enforcing it consistently rather than changing it. 

Next, raise the maximum log file size from the 20MB default. CIS recommends the following as a minimum, but per Microsoft's event log recommendations, all modern operating systems support much larger sizes. 

Once these are in place, watch how long logs are actually retained on a domain controller before they begin to roll. There is no universally correct number of hours or days. What matters is that the window is long enough for your environment and for whatever ingests the logs downstream. If your collector goes offline for a maintenance window, the on-box log needs to outlast it. Raise these recommended sizes as appropriate for your environment. 

Step Two: Advanced Audit Policy 

Configure domain controllers to use Advanced Audit Policy, not the nine legacy audit categories, by setting the following configuration to Enabled:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings 

Next, configure the individual subcategories under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration. 

Roll these changes out slowly. Logging configuration is a balance. Turn on too much at once and you can balloon log volume to the point where events are overwritten before your collector ingests them, leaving you worse off than before. Note: Log settings and size changes may require domain controller restart before taking effect. 

The table below lists the TrustedSec recommendations alongside the CIS Benchmark (as of Windows Server 2025 v2.1.0). They do not agree everywhere, and that is the point. For full coverage, blend the two. Also account for any specific requirements from the platform ingesting these logs, since some products depend on subcategories neither column flags as essential. 

For further reading: Microsoft's Advanced security audit policy settings reference and Planning and deploying advanced security audit policies; the Audit Policy Recommendations guidance; and ManageEngine's walkthrough of configuring these subcategories manually, which is a useful step-by-step approach regardless of which platform you use. For anticipating event volume before enabling something, Splunk's data-driven analysis of audit policy is worth the read. 

Once native auditing is tuned and stable, Sysmon is the next reasonable step. It fills gaps native logging leaves open (process hashes, network connections by process, image loads, named pipes), but only after you have the fundamentals under control, and only with a tuned configuration. Our Sysmon Community Guide covers the configuration in depth. 

Step Three: Know What You are Trying to Detect 

Not knowing where to begin or where to go next is a very common question. The following 10 detection goals target common adversary behavior. Some of these you may already have. Others are genuinely hard or just too costly. 

1. Authentication patterns. Watch login activity for behavior that suggests someone is trying to break in rather than legitimately log in. Password spraying, impossible travel, and unusual administrative behavior (User and Entity Behavior Analytics - UEBA) all live here. 
2. Privileged account use and membership changes. Track every administrator logon and every change to admin groups. Attackers escalate to admin as fast as they can and then use those rights to spread. Watch AD group membership additions, local Administrator additions, and admin logons originating from non-admin workstations. 
3. Process execution. Record what runs on each host and the command line used. Attackers frequently abuse legitimate built-in Windows binaries rather than dropping obvious malware. They call it Living off the Land (LOTL). The LOLBAS project catalogs the binaries worth watching. 
4. PowerShell logging. PowerShell is on every Windows machine and is among the most abused tools post-compromise. Script block logging shows you exactly what commands ran, including obfuscated ones. Watch for AMSI bypass attempts and Invoke-Expression / IEX patterns. The NSA's Keeping PowerShell: Security Measures to Use and Embrace is the definitive guide. 
5. DNS query logging. Every Internet connection starts with a DNS lookup, so DNS logs reveal where systems are phoning home, including to attacker infrastructure. An internal server suddenly resolving a domain registered three days ago in a country you don't do business with is a strong C2 or exfiltration indicator. 
6. Firewall egress logging. Most organizations log inbound traffic thoroughly and outbound barely at all, which is exactly backwards for detecting theft. Stolen data and malware callbacks travel outbound. A database server uploading several gigabytes to an unfamiliar file-sharing service at midnight should be an alert. 
7. Domain controller and identity telemetry. Domain controllers hold every account and credential in the environment and are the primary target after initial access. Several well-documented attacks against them leave distinctive log signatures: Kerberoasting, AS-REP Roasting, and DCSync among them. Microsoft's best practices for securing Active Directory is a good companion here. 
8. Email gateway telemetry. Email remains a common entry point. Monitor spam volumes, URL click-through, attachment types, and whether outsiders are spoofing your domain. Publishing SPF, DKIM, and DMARC records is the industry-standard defense. A spike in ‘report phish’ submissions about the same message means a campaign is in progress right now. 
9. Web proxy and browsing logs. Both initial infection and data theft commonly ride ordinary-looking web traffic. Watch for executable and script downloads, and for large uploads to personal cloud storage. 
10. Security tool evasion signals. Once attackers have administrative access, one of their first moves is to blind you: stopping or uninstalling EDR agents, clearing event logs, and creating services or scheduled tasks for persistence. These events should be among your highest-fidelity alert. 

Step Four: Find the Gaps, Then Rehearse

Collecting data and writing detections are different activities, and the gap between them is where most programs stall. Map each of the 10 goals above to the tools you already own. You will usually find three buckets: goals you cover well, goals where the data exists but nobody has written an alert, and goals where you have no telemetry at all. Prioritize the middle bucket. It's the cheapest ground to gain. 

Then, run a Tabletop Exercise. Pick a realistic scenario, walk it through your environment step by step, and ask at each stage: would we see this, who would get the alert, and what would they do next? A detection nobody knows how to act on is not a detection. The tabletop is usually where that becomes obvious, and it is far better to discover it in a conference room than a 2AM wake-up call. 

Conclusion: Achieve Discipline

Establishing a solid logging process can be difficult and at times may be cost-prohibitive. The effort doesn’t require perfection but does require discipline. Following the above steps helps move you closer to your goal. No matter your current security posture, there is a lesson to be learned by better understanding your logging process. Maybe you’re missing hours of logs due to log size constraints, or perhaps you lack visibility due to clicking Failure instead of Success. If the groundwork is solid, it’s likely you could add a whole new detection category or could improve the fidelity of your alarms. And if you happen to have made it this deep into the article, thinking you’ve done it all… Congratulations, now go update those runbooks, schedule a tabletop, or reach out to us to schedule your next engagement. TrustedSec offers a number of services around Incident Response, Purple Team efforts, Runbook creation, and more. If you're in need of assistance on this, please get in touch with us.