Gathering Windows, PowerShell and Sysmon Events with Winlogbeat – ELK 7 – Windows Server 2016 (Part II)

In part I of this series, Installing ELK 7 (Elasticsearch, Logstash and Kibana) on Windows Server 2016, I covered the following:

  • Installing and configuring Elasticsearch, Logstash, and Kibana as Windows services
  • Installing and configuring Winlogbeat to forward logs from the ELK server into ELK
  • Installing and configuring Curator as a scheduled task (optional)

Now, in this post I am going to cover these items:

  • Installing and configuring Winlogbeat on Windows 2016 client server
  • Installing and configuring Sysmon on Windows 2016 client server
  • Configuring Winlogbeat to forward Windows, PowerShell, & Sysmon Events

Installing Winlogbeat

Winlogbeat is going to be the “agent” that gets installed on each Windows server/client that will forward logs from the host to the ELK instance. If you have ever worked with Splunk, Winlogbeat is similar in nature to the Universal Forwarder.

  1. Download the Winlogbeat package for Windows in .zip format:
  2. Unzip the package to its permanent home, I will be using C:\ProgramData\Elastic\Winlogbeat:

  3. Edit the winlogbeat.yml configuration file, commenting out the Elasticsearch output and uncommenting the Logstash section setting the host to the IP of the ELK server:
    #================================ Outputs =====================================
    # Configure what output to use when sending the data collected by the beat.
    #-------------------------- Elasticsearch output ------------------------------
      # Array of hosts to connect to.
      # hosts: ["localhost:9200"]
      # Optional protocol and basic auth credentials.
      #protocol: "https"
      #username: "elastic"
      #password: "changeme"
    #----------------------------- Logstash output --------------------------------
      # The Logstash hosts
      hosts: [""]
  4. Install Winlogbeat as a service with the PowerShell install script:
    PS C:\ProgramData\Elastic\winlogbeat-7.0.0-windows-x86_64> powershell.exe -ExecutionPolicy Bypass ".\install-service-winlogbeat.ps1"

  5. Make sure the service is started.

Installing Sysmon

Sysmon is a great tool from Sysinternals that can provide some very useful information, the kind of data that would often require an EDR solution. This includes process creation events, command line activity, network connections, and much more. All of this information is logged into the Windows Event Logs, which means Winlogbeat can be used to pickup these logs and send them over to the ELK stack for analysis.

  1. Download Sysmon.
  2. Sysmon needs a configuration file to define what exactly to log, now this is a bit of a balancing act between value vs volume, but I think SwiftOnSecurity’s config file is a great place to start and will log high value events.

    You can find the config file here:
    SwiftOnSecurity – Sysmon-Config

  3. Extract both Sysmon and the configuration file, and then copy both files to their permanent home. I am going to use C:\Program Files\Sysmon:

  4. The following command will install Sysmon with the configuration file:
    PS C:\Program Files\Sysmon> .\sysmon64.exe -accepteula -i sysmonconfig-export.xml

  5. The Sysmon Events are logged to Event Viewer > Applications and Services Logs > Microsoft > Windows > Sysmon:

PowerShell Logs

I’m not going to go into a whole lot of detail around the PowerShell logs themselves but what is important to note here are the two group policy items that needed to enable the logging and then the location of the logs. I am only going to talk about module and script block logging here, not transcription as those logs get logged to flat files and not the Event Viewer.

Group Policies that need Enabled:

  • Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell
    • Turn on Module Logging: Enabled
    • Turn on PowerShell Script Block Logging: Enabled

PowerShell logs are located in two different locations in the Event Viewer, with the more valuable module and script block logs being a little more buried and often over looked because of this.

PowerShell Log Locations:

  • Event Viewer > Application and Services Logs > Microsoft > Windows PowerShell
  • Event Viewer > Application and Services Logs > Microsoft > Windows > PowerShell > Operational

Updating the Winlogbeat Configuration

With the additional logging enabled, the Winlogbeat configuration file needs updated with the additional log locations, and then after a simple service restart the logs will be off to the ELK server.

  1. Open the winlogbeat.yml configuration file.
  2. Add the additional log names under the winlogbeat.event_logs section:
    #======================= Winlogbeat specific options ==========================
    # event_logs specifies a list of event logs to monitor as well as any
    # accompanying options. The YAML data type of event_logs is a list of
    # dictionaries.
    # The supported keys are name (required), tags, fields, fields_under_root,
    # forwarded, ignore_older, level, event_id, provider, and include_xml. Please
    # visit the documentation for the complete details of each option.
      - name: Application
        ignore_older: 72h
      - name: Security
      - name: System
      - name: Windows PowerShell
      - name: Microsoft-Windows-Sysmon/Operational
      - name: Microsoft-Windows-PowerShell/Operational
  3. Open services.msc and restart the winlogbeat service.

    And the logs start flowing in:

And that’s it for configuring a client, as you can see it is a pretty straight forward process and only requires a few steps once all the packages are downloaded and the configuration files are created. This means installation process can be easily repeated on additional hosts as needed, or even better – scripted out and pushed via GPO or SCCM to enable logging from all of the hosts in the environment.

That’s where I am going to wrap this post. We now have an ELK Stack up and running and collecting not only the Windows Application, Security, System Events but also the Sysmon and PowerShell Events from a remote Windows client. I hope you enjoyed this series and found it useful in some way! Thanks for reading!

Comments are closed.