Windows Server Auditing Configuration
File access auditing requires configuration at two levels - audit policy and SACL on specific folders.
A. Audit Policy (GPO or Local Security Policy):
Navigate to: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Object Access
Enable the following policies:
- Audit File System - Success & Failure
- Audit Handle Manipulation - Success & Failure (optional, provides better context)
IMPORTANT: Don't enable "Audit Removable Storage" unless needed - it generates additional 4663 events that clutter your logs.
B. SACL (System Access Control List) on folders/files:
On each SMB share you want to monitor:
- Folder Properties → Security → Advanced → Auditing → Add
- Principal: select appropriate group (e.g., "Everyone" for full audit)
- Type: All or Success/Failure as needed
- Applies to: "This folder, subfolders and files"
- Permissions - select operations to track:
- Write data (create/modify)
- Delete
- Delete subfolders and files
- Read data - WARNING: generates huge amounts of events, use very carefully only on critical directories
From experience, I recommend starting without Read data and checking your event volume first, then potentially adding it to selected folders.
Key Event IDs:
- 4656 - handle to an object was requested
- 4663 - an attempt was made to access an object (main event)
- 4660 - an object was deleted
- 4658 - handle to an object was closed
2. Forwarding Logs to Energy Logserver
Energy Logserver offers two methods - I recommend Winlogbeat as simpler and more universal.
Method A: Winlogbeat (recommended)
- In Energy Logserver GUI → Integrations tab
- Select "Microsoft Windows Systems" integration
- Use "One Click" - automatically installs:
- Event processing pipelines
- Ready-made dashboards
- Preconfigured agent
- Basic Winlogbeat configuration (
C:\Program Files\Winlogbeat\winlogbeat.yml):
yaml
winlogbeat.event_logs:
- name: Security
event_id: 4656, 4658, 4660, 4663
ignore_older: 72h
output.logstash:
hosts: ["your-els-server:5044"]
Filtering event_id at the agent level significantly reduces unnecessary traffic.
Method B: Windows Event Collector (WEC) - agentless
If agent installation isn't possible, ELS supports Windows Event Forwarding via WinRM. Details in ELS documentation under "Event Collector" section.
3. Parsers and Alert Rules
After deploying the "Microsoft Windows Systems" integration, you get:
Ready-made pipelines - automatically parse events into fields:
user.name - who performed the operationfile.path - full path to the fileevent.action - operation typewinlog.event_id - event ID
Sample alert rules - you can create in the Alert module:
- Access frequency to sensitive directories
- Mass file deletion (e.g., >50 in 5 minutes)
- File access outside business hours
- File operations by unusual processes
4. Correlation with Specific SMB Shares
Capabilities: Event 4663 contains the Object Name field with full path, e.g., \\SERVER\Share\folder\file.txt. In dashboards, you can filter and aggregate by this path.
Limitations: Windows doesn't directly log SMB share names - you must rely on parsing the path from the Object Name field. For local paths (e.g., C:\Shares\...) you need a share → local path mapping.
If you really need automatic share name extraction, you can add a custom filter in Logstash, but in most cases filtering by path prefix directly in the dashboard is sufficient.
