Hello.
In this setup and configuration demo of Winlogbeat,
we will start by validating the installation and look at how it
relates to the rest of the Elastic cluster.
Then,
we'll take a brief look at an example configuration file so we
have an idea of the options available to us.
Then, when we're ready to modify the Winlogbeat configuration,
I have a readymade template you can use as a starting point for your deployment.
Finally, after completing these tasks,
I'll show you how to start the Winlogbeat service.
The software version of the Elastic components in your
environment should generally be the same across the stack
to avoid compatibility issues.
This virtual machine is one of several Windows 10 workstations
in the Globomantics enterprise environment where I've already
installed version 8 of Winlogbeat.
The Elasticsearch cluster where all of the logs will be
received and stored also uses version 8.
I want to remind you that this is an intermediate‑level course,
so I'm going to make some assumptions,
the first of which is that you can download and install
Windows software like Winlogbeat.
We will spend most of our time focusing on the setup and configuration process.
The Winlogbeat configuration files are located under the ProgramData directory.
Notice there is a reference file and an example config file.
Let's take a quick look at the winlogbeat.example.yml file and
go over some of the configuration options.
Now, I won't be able to cover every feature in this short course; however,
resources will be provided at the end.
The event logs section specifies which logs we want to ship
from the endpoint to our output destination.
The minimum configuration you need is the name of the log or log channel.
There are additional modifiers that affect how the selected logs are processed.
For instance,
the event_id field allows you to filter only the specific events
you want to be sent to your output source.
You can also add metadata tags or ignore old log events.
The lines that do not have modifiers will send all the available event IDs.
For those of you that have Windows Event Forwarding in your environment,
you can install Winlogbeat on each of the Windows Event Collectors and
ensure this section has the forwarded events configured.
Winlogbeat has a default template that controls index lifecycle management,
the number of shards, and field mappings.
The default template is recommended for most deployments; however,
if you need to make adjustments, you can make them here.
The Kibana dashboards for Winlogbeat are not loaded by default,
but you can enable that feature here if you want them loaded.
The setup configuration options only need to be run once,
and I recommend using a separate Elasticsearch user
account with elevated privileges.
Another consideration is that you will have to disable index template
loading if you're not sending logs directly to Elasticsearch.
This section controls where the logs are sent when events are generated.
The most resilient deployment for an enterprise environment is to use
a log broker such as Kafka or Logstash and then have the broker send
the logs to the Elasticsearch cluster.
However, you can ship directly to Elasticsearch.
Now,
each endpoint will have the credentials necessary to
interact directly with the Elasticsearch API.
You must scope the API or user account permissions.
Keep in mind that a compromised endpoint with an API key or username/password
with excessive permissions could provide an adversary with the ability to add
and remove data from your Elasticsearch cluster.
When we look at the operational configuration file,
I'll talk more about these concerns.
The last section of this configuration will allow you to add
metadata information to all your event logs,
such as MAC address, hostname, operating system.
If you have a cloud‑based system,
it will also enrich your event data with the cloud
provider's details about the endpoint.
I've put together a Winlogbeat configuration that can
serve as a great starting point.
I aggregated event log sources and event IDs from the
NSA's Spotting the Adversary whitepaper,
Microsoft's Windows Event IDs to Monitor,
and what's known as the Sexy Six Event IDs.
Since this course is focused on Winlogbeat,
I did not include Sysmon event logs because that requires
additional software installation and configuration.
The configuration file is located on my GitHub,
but I've included a copy with the course resources if you want to follow along.
So once it's downloaded,
we need to extract and copy it over to the Winlogbeat configuration directory
and open it up in a preferred editor as an administrator.
Okay, here we are.
It might be tempting to remove the event IDs and
configure each log source to send all logs,
but that's not optimal.
You will be generating a lot of logs that may not have
much value for threat detection.
Additionally, the fear of missing incidents leads organizations to,
as they say, log all the things,
which generates large volumes of events and alerts that
have led to analysis and alert fatigue.
Nevertheless,
this configuration is a great place to start and build upon
using your organizational requirements.
We will be making changes in this section of the configuration file.
I'll start with the metadata tag.
There's already a list containing endpoint and HR.
Let's change HR to Globomantics.
If this were a domain controller,
I would change the endpoint tag to dc or any other
descriptive tag that would be helpful.
Next, I'll update the domain name for Kibana and Elasticsearch.
Then, I'll use the winlogbeat setup command to manually load the dashboards,
index templates, and ingest pipelines.
To do that, we must connect directly to Kibana and the Elasticsearch cluster.
Remember, if you're using TLS, and you should be,
you will need to ensure that the Elasticsearch cluster's certificate authority
certificate is installed in the Windows Certificate Store.
Yet another detail to keep in mind is that for
whichever output system you choose, Kafka,
Logstash, directly to Elasticsearch,
the certificate validation could fail if the hostname or IP
address you use is not referenced in the common name field of
the respective TLS certificate.
Now,
you may have noticed that there are no plaintext passwords
or API credentials visible in this file.
Instead,
the best practice is to use the Winlogbeat keystore to secure our credentials.
The command to create the keystore is winlogbeat keystore create.
Then,
we need to use the winlogbeat keystore add command for each
variable name used in our config file.
Winlogbeat keystore list displays which variables have been created.
Remember,
you must run the keystore commands with the same user that you
will use to start the Winlogbeat service.
Okay,
now that we have the Winlogbeat configuration modified for our
environment and the keystore variables created,
it's time to run the winlogbeat setup command.
This command only needs to be run once on one of your endpoints.
I created the Beats admin user account and API key using the Kibana web UI
and I scoped the permissions. Once setup is complete,
I will comment out the credential information for the Beats admin user and
enable the API key. The best practice guidance is to create a unique API per
endpoint, especially if you do not use a keystore variable or scope the
permissions to the functionality necessary.
Now, before we start the Winlogbeat service,
we can double check the configuration using the winlogbeat test config
command. Nice! Looks like we're good to go and all that's left is to
enter the command Start‑Service winlogbeat. Make sure you're in a
PowerShell session or it won't work.
That's it.
We now have a Winlogbeat agent running on our Windows workstation,
shipping a scoped set of event logs to our elasticsearch cluster.
See you in the next clip.