We are pleased to announce the immediate availability of the Gravwell Sysmon kit. This kit is designed to get you started quickly with Sysmon data and demonstrate the art of the possible. This post will cover the basic contents of the kit and then we will perform a quick investigation of a process that probably shouldn't be running on a corporate machine.
If your enterprise is using Office 365, your users are generating log entries every time they log in, upload files to OneDrive, send an email--the logging is pretty extensive! You can analyze these log events in the O365 console, but wouldn't it be nice to pull them into Gravwell and correlate with other data sources? Thanks to the new Office 365 ingester, you can.
This post uses the xml parser module to evaluate windows logs. We have since released the winlog module, which you can reference here: https://docs.gravwell.io/docs/#!search/winlog/winlog.md
We are going to dive into Windows and show how to get logs flowing into Gravwell in under 5 minutes with the WinEvent ingester. Using the Windows queries we will audit login behavior, RDP usage, some Windows Defender, and identify when Bob from accounting is copying sensitive financial data to external storage devices. Also, Taylor Swift is involved; don't panic, just stay with me.
This Gravwell post is all about the wild world of Windows Event logging and analytics. Both Unix and Windows provide standardized central logging facilities; however, the structure and format of the stored logs are dramatically different. Syslog and most other logging systems with roots in Unix approach logging as an unstructured stream: a log entry is a string of text, no more, no less (we are going to ignore journald and its binary madness). Windows, however, logs all events in fully-formed XML and the logging system is integrated into the operating system itself. We should also note that logging in Windows is... less than ideal. If you are coming from the Unix world, throw out all your assumptions; things are different here.