Event Forwarding and How to Configure it For the Security Monitoring Management Pack
Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
One of the features that was built into the Security Monitoring Management Pack was the ability to discover and then monitor the contents of the Forwarded Events logs for suspicious activity. The reality for most external attacks is that the breach usually occurs at the user tier through some sort of phishing attack. Attackers will then move throughout the user environment until they are able to obtain credentials that allow them to gain access to the data tier or even worse, the identity tier. The unfortunate reality of this is that stopping an attack at the user tier is very difficult to do. No matter how much training people receive about opening suspicious email, we know that 10-20% of end users will open the email anyways, compromising their system.
With the release of Server 2008, Microsoft added the ability to configure desktops to forward events, but as a practical matter, monitoring event logs from hundreds, if not thousands, of desktops can be a bit tedious. As such, it seemed like a good idea to configure SCOM to do this. I would note that in large environments, multiple collectors is a good idea, for simple reason that SCOM can only process so much log data at a time. I’m not sure what the exact number is, but I suspect that one of the big reasons for ACS being a separate add on for SCOM has something to do with this little problem.
I won’t bore you with the details of configuring event forwarders. That’s fairly straight forward, and if you’re not sure, visit the links below. I will however recommend that the following tier0 events be forwarded:
- Desktop security logs
- System Log event ID 104
- Windows PowerShell Log – there is one rule targeted here (Powersploit monitoring)
- Applocker/Exe and DLL log – event 8003
That’s the generic level. I would note that doing just what I’m collecting will likely mean this will need to be revisited at some point. I’ll make an attempt to keep this page up to date with any changes, but if you’re not already forwarding something, then any new rules targeting those logs won’t work.
I would also note that since desktop environments are difficult to manage, I’m sticking mainly with rules that target credible threats. An alert generated by a forwarded event won’t necessarily mean your environment is compromised, but it does likely mean that the desktop in question has been, and should be rebuilt.
Finally, if you want to create your own rules, they will not work if you are using the SCOM console. You will need to add the <AllowProxying> tag in the XML set to true.
The following events are presently being monitored:
- 800 – PowerShell Operational Log – will generate an alert if the commercially available copy of PowerSploit is in use.
- 4624 – Security Log – Generates alerts for potential credential swaps.
- 4688 – Security Log – Generates alerts for certain types of anomalous process creation behavior.
- 1102 – Security Log – Generates alerts for clearing the security log.
- 4964 – Security Log – Generates alerts if a member of a special group (which you must configure) signs on to a desktop.
- 7045 – Security Log – There are two rules here. A disabled rule that alerts for any new service created on the desktop, and an active rule that alerts to services that are associated with known threat vectors (PSexec, WCEService, Winexe).
- 4632 and 4633 – Security Log (creation and deletion of local user accounts).
- 104 – System Log – Generates an alert for clearing the system log.
The following I hope to add in future releases:
- 4720 – Security Log (for local admin changes)
- 11707 – Application log (software install, will be disabled by default).
Info on Windows Event Forwarding.
Wiki on Windows Event Forwarding.
Technorati Tags: Windows Event Collector,Event Forwarder,SCOM,Security monitoring,configure