The logs already exist; reading them is the problem
Most breaches in an Active Directory environment are plainly visible in the logs when reviewed afterwards. The account the attacker created, the group membership they added, the suspicious process they ran — all recorded. The problem is not missing records but that nobody is looking, and that the default audit policy never produces the critical events in the first place.
This article follows a practical order: enable the right audit policy, know which Event IDs matter, deepen visibility with Sysmon, then automate detection with Sigma rules.
Step 0: is audit policy actually on?
- Command-line auditing: without it, event 4688 (process created) gives the process name but not the arguments — and the arguments are where the detection value lives.
- PowerShell ScriptBlock logging: without it, the contents of encoded PowerShell commands stay invisible.
Policy is set with auditpol. A practical detail: on Turkish-language Windows installations the category names are localised, so scripts written against English names fail. Configuration must be done by GUID rather than by category name.
Critical Event IDs and what they mean
Logon events
- 4624 — successful logon. The Logon Type field is critical: Type 3 (network), Type 10 (RDP), Type 4 (batch), Type 5 (service). A Type 10 at an unexpected hour stands out.
- 4625 — failed logon. Noise on its own; many in a short window signal brute force.
- 4740 / 4767 — account locked out / unlocked. Repeated lockouts mean either a stale saved password or an attack.
Account and group management
- 4720 — user account created, the classic persistence step.
- 4722–4726 — account enabled, password changed, disabled, deleted.
- 4732 / 4756 — member added to a security-enabled local or universal group. An account being added to Domain Admins shows up here and should always be investigated.
Processes and services
- 4688 — process created, with arguments when command-line auditing is on.
- 4697 and 7045 — new service installed, a common persistence and lateral movement technique. An unexpected service installation is a high-priority signal.
Directory and policy changes
- 5136 / 5141 — directory object modified / deleted.
- 1102 — audit log cleared. Almost never legitimate; warrants immediate investigation on its own.
Kerberos
- 4768 / 4769 / 4771 — TGT requested, service ticket requested, pre-authentication failed.
- A burst of 4769 requests, especially with weak encryption, suggests Kerberoasting; a pile-up of 4771 can indicate password spraying.
Sysmon: the layer standard logging misses
Built-in Windows auditing records a lot but never sees some techniques. Microsoft Sysinternals' Sysmon fills that gap, adding visibility into process injection, credential dumping and lsass.exe memory access, Office applications spawning PowerShell or cmd as a child process (a classic phishing chain step with almost no legitimate use), WMI persistence, and per-process network connections and DNS queries.
Sysmon's value is in its configuration. Installed with an empty default config it produces either too little or unusably much. A curated XML configuration should filter noise while catching the techniques above.
Sigma: a common language for detection rules
You have the logs — but what do you look for? Writing every detection from scratch is wasted duplication. Sigma is an open standard expressing detection rules in platform-independent YAML. A rule says "in this log source, if these fields hold these values, this is technique X", and can be converted to a Splunk query, Elastic DSL or another engine. Thousands of community-maintained rules exist.
Hayabusa (Yamato Security) runs these rules quickly against EVTX files or live event logs and reports findings by severity.
MITRE ATT&CK mapping
Sigma rules are tagged with MITRE ATT&CK tactics and techniques, which puts findings in a framework: instead of "suspicious PowerShell" you get "T1059.001 — Command and Scripting Interpreter: PowerShell". That mapping also enables coverage analysis — which techniques can you detect, and where are the blind spots? Directing security spend at those gaps beats adding tools at random.
Anomaly detection: when rules are not enough
- Out-of-hours logon: an account that only ever works office hours signing in at 03:00.
- Brute force correlation: combining 4625 and 4771 within a time window.
- Sensitive group changes: membership changes in Domain Admins or Enterprise Admins.
- Admin password reset: an unexpected reset on a privileged account.
- Bulk file deletion: an early signal of ransomware or data destruction.
Process signature analysis
An effective and commonly skipped control: verifying the Authenticode signature and SHA-256 hash of running processes. An invalid signature on a known system binary such as svchost.exe, or a hash that differs from the expected value, indicates a tampered binary and is a high-priority alert.
Not forgetting Linux
In mixed environments, Linux servers need monitoring too. Meaningful journald categories include SSH authentication and logon events, invalid user attempts, sudo usage, package manager operations (an unexpected install stands out), systemd unit failures, OOM killer events and segfaults.
Hardening and reversibility
Monitoring detects; hardening shrinks the attack surface. Typical AD hardening steps: disabling stale accounts, removing the PASSWD_NOTREQD flag, tightening password policy, enabling the AD Recycle Bin, LDAP diagnostic logging and requiring NLA for RDP.
The critical principle: every hardening step must be reversible. Backing up the current state to CSV before a change and generating an automatic rollback script gives you a fast way back if hardening breaks production. A hardening project without a rollback plan gets abandoned entirely at the first problem.
Marta Threat Notification System (MartaSecurity)
MartaSecurity, developed in house at Marta Teknoloji, automates every step in this article as a multi-tenant endpoint security observation platform.
The agent runs as a Windows service or a Linux systemd unit. It configures audit policy automatically via GUID-based auditpol (compatible with Turkish-language Windows) and enables PowerShell ScriptBlock and command-line auditing. It downloads Sysmon and feeds it a curated configuration, installs Hayabusa and runs 4,000+ Sigma rules plus 170 built-in rules against live event logs every 30 minutes, tagging findings with MITRE ATT&CK tactics and techniques.
It monitors every Event ID described above in real time, performs anomaly detection, produces process signature analysis and diffs, and scans journald categories on Linux. The hardening module generates a BEFORE.csv backup and a ROLLBACK.ps1 script for every action. Alerts and daily reports go out over SMTP, while the central server presents all agent data in one panel built on Go, PostgreSQL and Caddy. The MSP structure lets one server serve many customers with isolated alert and policy views.
Contact us for an audit policy assessment and blind-spot analysis of your Active Directory environment.