The workstation events you want to be logging in Splunk

Last Updated on September 15, 2016 by Dave Farquhar

Every once in a while the NSA or another government agency releases a whitepaper with a lot of really good security advice. This paper on spotting adversaries with Windows event logs is a fantastic example. It’s vendor-neutral, just talking about Windows logs and how to set up event forwarding, so you can use the advice with any log aggregation system or SEIM. I just happen to use and recommend Splunk. But whatever you use, these are the workstation events you want to be logging.

I want to call your attention to a couple of items in the paper. Most breaches begin on workstations, and this paper has the cure.

Section 4.2 is absolutely critical. If an application like Acrobat Reader or Flash crashes, you ought to know about it. So I recommend setting up a Splunk alert that goes something like this:

EventCode=(1000 OR 1001) AND (flash OR acroread OR acrobat OR winword OR excel OR powerpnt OR wmplayer OR java)

You might consider adding Chrome, Internet Explorer and Firefox to that list, but it will be noisy because browsers crash all the time.

What you really want to watch for is a crash followed immediately by other events–spawned processes, network access, stuff like that.

I suggested we set up alerts so that we know when any of our likely spear-phishing targets experience a crash. The CEO is more likely to get spear phished than a business analyst. The consequences will be higher too, at least if you have a well-segmented network.

Section 2.3 shows how to set up event forwarding with Winrm, which you’ll probably want to do. Your desktop team probably won’t want the Splunk forwarder running on every workstation; pulling logs with Winrm is an easier solution to implement. Then you only need a Splunk forwarder on the server that’s running Winrm. Even though the source will show the name of your forwarding server, the original source is still in the logs so Splunk can see them.