Windows Event Collector and Event ID Monitoring

Vol2Log Update: Just a quick update on vol2log, I've added additional functionality to the PSList output which will add an additional field to compare the process name to the correctly spelled process name. With this functionality, you should be able to quickly identify commonly miss-spelled processes by filtering the 'TypicalService' field. I also added some functionality to shipping the DLLList output to add the name of the parent process for each DLL. As this project grows, I intend to expand the analysis to include checking the location of each DLL loaded. I'm also in the process of expanding the 'Getsids' output to analyze if a typical Windows process is running under the correct user account. There were also a few minor changes to the flow of the application but that is all the updates for vol2log at the moment, now on to the reason for this post.

Post Begins here: There are a lot of Windows Event Collector configurations floating around out there, some of them work, some of them don't. I had someone ask the other day if I could send them one to use, and I decided I would share one which I have tested this on multiple occasions. There is information in that repository on how to load this configuration as well. In addition to the configuration, I've included below what type of suspicious information you can identify with each Id to help others build out their SIEMs. If you are not interested or do not utilize certain monitoring Ids, you can either delete/comment out the section of the configuration file if you do not care to log that type of event. Some of these are obvious, some of them require additional processing once it is sent to your SIEM of choice, but perhaps it will give all of you additional ideas of what to do with these events. Some of these can also be a bit noisy, so depending on your environment take that into consideration. Also, if you are not familiar with WEC, this is a great resource, Monitoring What Matters, for additional information on getting the WEC environment set up.

Here is a link for the my WEC XML configuration, and here is a quick reference list in reference to the ID of the WEC in the configuration:

  • #1
    • New/Modified Scheduled tasks - Helps identify persistence.
  • #2
    • Monitors changes in the status of a service - I have seen instances where this can get a bit noisy, but there are ways to filter certain processes out.
  • #3
    • Monitors new services being installed on a system - This is unfortunately quite loud as well but can be very beneficial when you need to go back in time to look for anomalies.
  • #4 - My favorite! (Quick Edit: Wanted to link the best Sysmon config as well, Sysmon Config, Swiftonsecurity has done an amazing job on this configuration.)
    • Monitor and verify when a user clicks on a link from an email. Bonus points if you can extract the URL from the CommandLine field and perform a lookup for known malware.
    • Monitor processes like PowerShell, Wscript, Rundll32, etc.. being spawned from Excel, Word, Adobe, or whatever application may be new delivery method for Malware.
    • Network connections initiated from any application to assist with pinpointing the malicious application. These include telnet, ssh, Java applications, etc...
    • Any registry edits, which can be indicative of persistence, as well as a useful utility for recording registry changes that your IT team may have made.
    • Any instances of time-stomping.
    • Sysmon stopping/starting.
    • New file creation/modifications.
    • There are many others...
  • #5
    • Cleared Event Log.
  • #6
    • New/Deleted Domain & Local User Accounts and Computers - Useful for auditing and documentation purposes.
  • #7
    • New/Deleted Domain & Local Security Groups created.
  • #8
    • Added/Removed objects from Domain & Local Security Groups.
  • #9
    • Applications that were executed and blocked from Software Restriction Policies.
  • #10
    • New/Deleted Virtual Hard Drives (Applies to Hyper-V).
  • #11
    • New/Deleted Virtual Machine (Applies to Hyper-V).
  • #12
    • Enabled/Disabled User accounts.
  • #13
    • User account successfully logged on. This Event ID can be enhanced depending on the logon type. Here is a great reference to help identify those logon types, as well as a great reference for anything Windows Security related. Depending on what you're wanting to monitor here are a few additional ideas:
      • Domain Admins Remote Desktop Sessions (Logon Type 10).
      • Specific accounts accessing Shares(Logon Type 3).
      • Domain Admin accounts interactively logging on to workstations (Logon Type 2).
  • #14
    • Account logon failed. Depending on your SIEM, you should be able to set thresholds on the number of failures which can help identify attempted Brute Force attempts. Occasionally there are instances when attempting to install an application or updating a driver, that a number of failed logons will be generated by whichever account is attempting to perform the installation.
  • #15
    • It's useful to monitor attempted password changes for historical purposes.
  • #16
    • Occasionally users will pass different credentials when running a program as a different user which will generate this event.
  • #17
    • User account locked out. Normally generated by a set number of failed logon attempts that is normally defined through Group Policy.
  • #18
    • PowerShell ScriptBlock auditing will need to be enabled for these events, but you will be able to identify anytime a script is executed as well as the contents of the script that was executed. If you haven't spent a lot of time with securing your PowerShell infrastructure, I highly recommend reading this article, probably one of the best guides out there when it comes to securing PowerShell (PowerShell Security at Enterprise Customers).
  • #19
    • This event can assist in identifying workstations rebooting in an abnormal manner. This can not only assist you with identifying malicious activity but also when things may be going South on a workstation.
  • #20
    • For those of you using Cylance, this event will send Cylance activity to your SIEM.
  • #21
    • Windows Firewall Stopping/Starting as well as blocking incoming network connections.

That is all I have for now. If any of you have any issues with the linked XML file, please let me know, as well as any issues with vol2log!

SW