After every security incident, the first question is: “Where and when did the attacker get in?” In many companies that question is never answered; either nothing was logged, or it was logged but the small log file overwrote events from just a few days earlier. Security logs are both an early-detection tool and the evidence for post-incident investigation.
Which Logs Matter Most?
You do not need to collect everything from day one. These sources provide the most value:
- Domain controllers: Logins, account lockouts, new account creation and changes to admin groups
- Firewall and VPN: VPN connections, logins to the management panel and denied traffic
- Mail server and webmail: Failed logins and logins from unusual locations
- Backup and virtualization consoles: Backup deletions, configuration changes and admin logins
- Antivirus or EDR: All alerts
Key Windows Events
A few event IDs in the Windows Security log that are worth monitoring:
4625: Failed login; many in a short time means a password-guessing attack.4624: Successful login; especially admin account logins at unusual hours.4740: A user account was locked out.4720: A new user account was created.4728,4732and4756: A member was added to a security group, for example Domain Admins.1102: The Security log was cleared; this almost always needs investigation.
Step 1: Enable Logging Properly
- Configure the Advanced Audit Policy with Group Policy for domain controllers and servers so that logon events, account management and policy changes are recorded.
- Increase the size of the Security log file; the default size on busy servers, such as domain controllers, may only hold events for a short period.
- Synchronize the clocks of all systems and devices with NTP. Logs whose clocks are a few minutes apart are very hard to correlate.
Step 2: Centralize Your Logs
A log that stays on the system itself can be deleted when that system is hacked, and reviewing ten separate systems simply does not happen in practice. Send logs to a central server:
- Network equipment and firewalls usually send logs via
syslog. - Logs from Windows computers and servers can be centralized with Windows Event Forwarding or a log collection agent.
- Open-source tools such as Wazuh or Graylog are a good starting point for small and mid-sized companies; they both collect logs and let you define alerts.
Restrict access to the log server so that even regular admins cannot delete logs, and set the retention period based on your company’s needs and the legal requirements of your industry.
Step 3: Alerts and Regular Review
Collecting logs without looking at them is useless. Set up immediate alerts for a few critical events: a member added to admin groups, a log being cleared, mass failed logins and backup deletion. Go through the rest in a short weekly review.
Start with a few precise alerts. Dozens of unimportant alerts a day cause every alert, including the real one, to be ignored.
Checklist
- An audit policy is enabled on domain controllers and servers.
- Log sizes are enough to retain several weeks of events.
- All system clocks are synchronized with NTP.
- Logs are collected on a central, protected server.
- Alerts are defined for critical events.
- The weekly log review has a designated owner.
ITPlus724 engineers can set up centralized log collection and key alerts for your network and servers so signs of an attack are spotted sooner.