Windows security event log monitoring with Graylog: what the integration does
A security or IT team that needs Windows logons, process creation and account changes searchable in Graylog should plan on Winlogbeat or NXLog, deployed and managed through Graylog Sidecar, with events parsed by the Illuminate Windows Security content pack. The content pack requires a Graylog Illuminate license, so that license is a decision to settle before collection design starts. Winlogbeat 8.x sends events to a Beats input, while NXLog sends them to a GELF input. Both paths end in the same content pack, but the choice changes how the collector is configured, how the input is defined in Graylog and which fields the parsing rules expect to find.
The pack categorizes events by their Windows event IDs, including 4624 for successful logon, 4625 for failed logon, 4688 for process creation, 4720 for user account created and 1102 for audit log cleared. Those IDs are the starting point for searches, dashboards and alert conditions, so the integration only works as intended when the Windows audit policy on each host actually generates them. Audit policy, the size of the Security event log and the forwarding path are the host-side decisions that determine whether the data arriving in Graylog is complete. Confirm the Windows Server version and the audit subcategories you need with your Windows administrators before you commit to a collector.
Graylog Sidecar bundles Filebeat and Winlogbeat for Windows and can also manage an existing NXLog or Sysmon installation, so the same configuration model covers both paths. Sidecar is the layer that pushes collector configuration from Graylog, which means the API token scope, the Beats or GELF input and the network path from each host must be designed together. Ask your Graylog administrators which inputs your license allows, and verify that each Windows host can reach the input port before you roll out to the domain.
What the Windows event log build needs before work starts
Most delays in a Windows security log build come from prerequisites checked too late: the Graylog version and license, the collector and its token, the audit policy on each host, and the network path to the input. Work through these cards before choosing a collector or building the pipeline, so the first parsed 4624 event is a planned result rather than a surprise.
Graylog version and Illuminate license
The Illuminate Windows Security content pack needs a Graylog Illuminate license, which is separate from the Graylog Open install. Confirm your Graylog release line and that the content pack version matches it, since the current documentation covers Graylog 7.2. Ask your Graylog contact in writing whether the license covers the pack you plan to deploy, and record that decision before the build starts.
Winlogbeat 8.x on each host
The content pack supports Winlogbeat 8.x through a Beats input. Pin the Winlogbeat version in your collector configuration rather than accepting whatever the installer offers, and check it against the content pack documentation before rollout. Decide whether Sidecar will bundle and manage Winlogbeat or whether an existing Winlogbeat install will be adopted, because that choice changes the upgrade process for every Windows host.
Sidecar and API token per environment
Graylog Sidecar bundles Winlogbeat on Windows and pushes collector configurations from Graylog. Create a separate Sidecar API token for each environment, such as production and test, so a leaked token in one does not expose the other. Store the tokens in your secrets tool, not in deployment scripts, and plan how they rotate when staff who installed Sidecar leave.
Audit policy settings on each host
Winlogbeat only forwards the events Windows writes, so the audit policy must produce them. Logon, process creation and account management events are controlled by Advanced Audit Policy settings, and process creation also needs command line capture if you want it in the event data. Confirm these settings through Group Policy on every host class, including domain controllers, and document the baseline your security team approved.
Windows and domain controller versions
Confirm the Windows Server version on every host and domain controller, because the log schema and audit options differ between releases. Windows Server 2025 became available on November 1, 2024, with mainstream support ending November 14, 2029. Windows Server 2022 mainstream support ended on October 14, 2026, with extended support ending October 15, 2031. Check your own inventory against the Microsoft lifecycle pages and plan upgrades that fall outside your support windows.
Network path from hosts to the input
Each Windows host needs a route to the Beats or GELF input on the Graylog nodes, and the input port must be open from the domain controllers and member servers that send logs. Map the path through host firewalls, segmentation and any load balancer before deployment. Domain controllers generate the most events, so confirm their traffic can reach the input without saturating the link or the message journal.
How to configure Winlogbeat or NXLog through Sidecar
This sequence takes Windows security events from audit policy on the host to searchable 4624 and 4688 messages in Graylog, using Sidecar to manage the collector from one place. Each step ends with a check so the team can confirm the path works before adding more hosts.
Create the Beats or GELF input
In Graylog, an administrator creates the input that will receive Windows events. Use a Beats input if you plan to run Winlogbeat, or a GELF input if you plan to run NXLog, because the Illuminate Windows Security content pack supports Winlogbeat 8.x through Beats and NXLog through GELF. Set the listening port, bind address and any TLS settings your network policy requires, then start the input. The step is done when the input shows as running under System, Inputs with no errors in the node log.
Install Sidecar on Windows hosts
A Windows administrator installs Graylog Sidecar on each host that will send security events, using an API token created for the environment that this host belongs to. Sidecar must reach the Graylog web interface and the input port over the network, so confirm the firewall rules between the host and Graylog before installing. The step is done when the host appears under Systems, Sidecars in the Graylog web interface with a recent heartbeat.
Choose Winlogbeat or NXLog as the collector
In Graylog, the team creates a Sidecar configuration for the collector it selected. Winlogbeat is bundled with Sidecar on Windows and pairs with a Beats input. NXLog is an existing collector that Sidecar can manage, and it pairs with a GELF input. Pick one collector per configuration so the input type, the port and the collector settings match. The step is done when the configuration is saved and lists the collector type and the input it targets.
Push the configuration from Graylog
The administrator assigns the configuration to the Sidecar group for the Windows hosts and applies it from the Graylog web interface. Sidecar fetches the configuration, writes the collector files and starts the service on each host. Check the Sidecar status on the host and in the Graylog interface to confirm the collector reports as running. The step is done when each host shows the configuration as applied and the collector service is running.
Enable the Windows audit policies
A Windows administrator enables the audit subcategories that produce the events the content pack expects, including logon, process creation and account management. Process creation events such as 4688 also need command line auditing enabled if the team wants the command line captured. Apply the policy through Group Policy for domain-joined hosts and confirm the result on a test host with the auditpol query. The step is done when the audit settings are in effect on the host and a test logon produces a Security log entry on that machine.
Confirm the Beats prefix settings
Check the Beats prefix or field naming settings in the Winlogbeat or input configuration so the fields match what the Illuminate Windows Security content pack parses. Compare the prefix against the content pack documentation before relying on it, and record the value in the change ticket so later configuration changes do not break parsing. The step is done when a sample event shows the expected field names in the Graylog message view.
Confirm events arrive with a search
Run a search in Graylog for the event IDs the team needs, such as a search returning 4624 successful logon events or 4688 process creation events from the test host. Confirm the messages carry the host name, event ID and parsed fields. If the search returns no results, check the input status, the Sidecar heartbeat, the audit policy on the host and the index set the stream writes to. The step is done when the expected events appear for the test host and the fields display as parsed.
How Sidecar, the Beats input and the content pack fit together
The path from a Windows event to a parsed Graylog message has four hops, and each one has a setting that can break the next. Winlogbeat reads the Security channel on the host, Graylog Sidecar starts and supervises Winlogbeat and pushes its configuration from Graylog, a Beats input on a Graylog node receives the events, and streams and processing pipelines route them to the Illuminate Windows Security content pack, which parses fields such as those behind event 4624 (successful logon) and 4688 (process creation). If any hop changes field names or drops the expected structure, the content pack still ingests the messages but the categorized views and dashboards go quiet. Field naming is the step most often misconfigured.
The Beats input has a prefix setting that determines how Winlogbeat's fields arrive in Graylog. Winlogbeat emits nested fields such as winlog.event_id and winlog.event_data, and the Beats input can add a prefix to the flattened names. Confirm in the Illuminate Windows Security content pack documentation which field names its extractors and lookups expect, then set the Beats input prefix and the Winlogbeat output so they produce those names. Do not rename fields in a pipeline rule to make a mismatch disappear without recording why, because the same rule will then have to survive every content pack update and Winlogbeat version change.
Sidecar is the control point for the collector side of this path. Its configuration for Winlogbeat is a template that names the event channels, the Beats output target and any processors, and Sidecar applies it on each host. A change to the prefix, the output or the channel list should be made once in the Graylog interface and rolled out to the collector group, not edited on individual hosts, so that the host and the input stay in step. Before you go live, confirm that the Winlogbeat version bundled or deployed through Sidecar is one the content pack supports, which the content pack documentation states as Winlogbeat 8.x, and test one host end to end: generate a logon, find the message in the search, and check that the parsed fields appear.
Which Windows event IDs the content pack categorizes
This table maps the Windows event IDs that the Illuminate Windows Security content pack categorizes to the activity each one records and the detection use it supports. Read it as a starting point for deciding which events to collect and alert on, then confirm the complete category list in the pack documentation for your installed version.
| Event ID | Activity recorded | Category the pack assigns | Detection use |
|---|---|---|---|
| 4624 | Successful logon | Successful logon category | Baseline normal sign-in patterns, spot logons at unusual hours or from unexpected hosts, and trace lateral movement. |
| 4625 | Failed logon | Failed logon category | Detect password guessing, spraying and brute-force attempts by counting failures per account or source over a time window. |
| 4688 | Process creation | Process creation category | Find suspicious executables, living-off-the-land tools and unexpected parent-child process chains. Command-line auditing must be enabled on the source hosts to be useful. |
| 4720 | User account created | Account creation category | Flag new local or domain accounts that were not part of an approved change, a common step in persistence. |
| 1102 | Audit log cleared | Audit log cleared category | Alert on attempts to erase the security log, which often accompany intrusion activity. Treat any occurrence as high priority for review. |
| Pack scope | Categories beyond the five IDs listed here | Confirm in pack documentation | Check the full category list and field mappings for the Winlogbeat and NXLog paths before writing alerts against them. |
Securing Windows log collection in Graylog
Windows security logs often include account names, group changes and privileged activity, so the path that carries them needs the same care as the logs themselves. The cards below cover the controls that connect the collector, the transport, the Sidecar management plane and the audit trail, and each one names what to confirm in your own environment before go-live.
Choose transport encryption for Beats and GELF
Winlogbeat sends events to a Beats input, and NXLog sends them to a GELF input, so the transport choice depends on which collector your team runs. Decide whether TLS is enabled on each input and whether certificates are issued from your internal certificate authority. Confirm that every hop from the Windows host to the Graylog input is encrypted, and that the collector trusts the Graylog certificate chain before you enable it in production.
Issue least-privilege Sidecar tokens per environment
Sidecar authenticates to Graylog with an API token, and a single token shared across production, test and lab hosts makes revocation disruptive. Create one token per environment or per collector group so that a compromised host can be cut off without touching the others. Confirm who may create and rotate these tokens in your Graylog administration, and record the owner of each token in your change system.
Limit which hosts can reach the input
A Beats or GELF input listens on a network port, so any host that can route to it can attempt to send events. Restrict inbound access to the input port to the Windows subnets or domain controller ranges that should send logs, using host firewalls, network access lists or both. Also confirm whether the Graylog input supports an allow list in your version, and treat any gap as a compensating control to document.
Protect the Sidecar configuration on hosts
Sidecar writes collector configuration files to the Windows host, and those files can contain the Graylog endpoint and collector settings. Limit write access to the Sidecar and collector directories to administrators and the service account, and check that the service runs under an account that is not a general user. Review the file permissions after each Sidecar upgrade, because installers can reset them.
Alert on audit log clearing events
Event 1102 records that the Security audit log was cleared, and attackers often clear logs after activity to hide their tracks. Forward 1102 from every domain controller and member server, and set an event definition that notifies the security team when it appears. Confirm that the audit policy on each host logs this event, and test the alert by clearing the log in a lab host before relying on it.
Keep an audit trail for collector changes
Changes to Winlogbeat, NXLog or Sidecar settings can silently stop events from reaching Graylog, which creates a gap that looks like a quiet host. Record who changed each collector configuration in Graylog, and compare event volume per host against a baseline so that a sudden drop is noticed. Ask your Graylog administrators how they review configuration history and who is notified when a collector goes silent.
How Active Directory changes the Windows log design
Active Directory Domain Services stores users, computers and other objects, and it replicates that directory data to every domain controller in a domain. Logons, Kerberos and NTLM activity, and account changes for the whole domain are therefore recorded on the controllers that process them. A gap on one controller leaves a blind spot in the domain, so the collector rollout starts here.
- Authentication volume. Controllers handle logons for the whole domain, so event volume and parsing load are usually higher than on a single member server. Measure it on a test controller before you widen the rollout.
- Collector on each controller. Each controller records its own events, so deploy Winlogbeat through Graylog Sidecar to every controller in the domain.
- Account and privilege events. Route events such as 4720 user account created and 1102 audit log cleared into a protected stream early, so they are visible to the security team from the start.
- Change control. Confirm with the directory team who may change audit settings on controllers, and record each change with its owner and date.
Check that every domain controller appears in Graylog and that a test account creation produces a 4720 event within the time your team expects.
Group Policy is the Active Directory mechanism for managing Windows desktops and servers, so audit policy and collector settings for domain-joined member servers and workstations are usually set there. One policy change can reach many hosts through the organizational unit structure. That makes the policy owner, and the way links are scoped, a central part of the log design.
- One source of audit policy. Define the audit settings in a Group Policy object, link it to the right organizational units and check the effective result on sample hosts.
- Staged rollout. Pilot the collector on one organizational unit, then widen the link once parsing and event volume look right in Graylog.
- Role-based grouping. File, application and print servers generate logons and process creation at different rates, so review each group separately before setting thresholds.
- Collector management. Use Graylog Sidecar to push Winlogbeat configuration from Graylog, or to manage an existing NXLog or Sysmon installation on the same hosts.
- Domain join state. Confirm each host's join state in inventory before assuming it receives domain policy, since a host outside the expected organizational unit may not.
Ask the Windows team which policies apply to each organizational unit and whether a test host shows the audit settings you expect.
Microsoft describes Microsoft Entra ID as the cloud identity service that evolved from Active Directory, and existing organizations commonly sync identities to it with Microsoft Entra Connect. A device joined to Entra ID is managed differently from a domain-joined server, so the on-premises audit design may not reach it in the same way. Treat these devices as a separate collection design rather than an extension of the domain plan.
- Sign-in data is a separate source. Entra ID sign-in and audit logs are covered on other pages, so do not assume the Windows security log records cloud sign-ins.
- Management path. Confirm how each device is managed and who can push collector software to it, since that determines whether Sidecar can reach it.
- Hybrid devices. Devices that are both domain-joined and Entra ID registered may receive two sets of settings, so test which one controls audit configuration.
- Roaming connectivity. Laptops that leave the corporate network need a planned path to Graylog or a forwarding option, which you should confirm against your network design.
- Identity sync state. Verify the state of Entra Connect synchronization before matching account names in Windows events against cloud identities.
Ask the identity team which devices are joined to Entra ID, which are hybrid joined and how each group receives its collector.
A standalone host in a workgroup is not a member of an Active Directory domain, so there is no domain Group Policy to set audit policy or deliver a collector. Each machine must be configured on its own or through a tool your team runs separately. This group is the most likely to drift from the intended baseline, so the design needs a documented standard and a way to check it.
- Local audit settings. Configure audit policy on each host, record the baseline and review it on a schedule, because no domain policy will correct drift.
- Collector installation. Install Graylog Sidecar with Winlogbeat or NXLog on each host and register it with the API token for its environment.
- Inventory. Keep a current list of workgroup hosts, since a host that never reports to Graylog is easy to miss.
- Network paths. Each host needs a network path to the Graylog inputs, so confirm firewall rules for each host or network segment before installation.
- Build process. Decide how new workgroup machines receive the baseline before they go into service.
Check that each workgroup host appears in Graylog under its own source name and that a test logon produces a 4624 event.
Why Windows events do not appear or parse in Graylog
This table lists the failures that most often stop Windows security events from reaching Graylog or from parsing into fields. Each row gives the likely cause and the fix to check first, so you can work through the path from the Windows host to the stream. Start at the top row, because audit policy problems block events before any collector sees them.
| Symptom or failure | Likely cause | Fix to check |
|---|---|---|
| No 4624, 4625 or 4688 events at all | Audit policy is not enabled for logon, account management or process creation on the host | Enable the relevant Advanced Audit Policy subcategories, and confirm process creation auditing and command-line capture are on before testing |
| Sidecar host never appears in Graylog | Sidecar was not enrolled, or the API token in the Sidecar configuration does not match the token for this environment | Create a token for the environment, reinstall or reconfigure Sidecar with that token, and confirm the host shows as registered in the Sidecar view |
| Collector is running but nothing arrives | A firewall or network path blocks the Beats port (for Winlogbeat) or the GELF port (for NXLog) between the host and the Graylog input | Test the TCP connection from the Windows host to the input port, then open the path in host and network firewalls |
| Input receives data but events are dropped or unreadable | Winlogbeat is outside the 8.x line that the Illuminate Windows Security content pack supports | Check the installed Winlogbeat version and align it to a supported 8.x release through Sidecar configuration |
| NXLog events arrive as raw text or fail to parse | The NXLog output does not match the GELF format the Graylog GELF input expects, such as field names or JSON structure | Compare the NXLog output module with the GELF input, correct the format, and test with one host before rolling out |
| Pack content and parsing rules are missing | The Graylog Illuminate license is not installed, so the Windows Security content pack cannot be used | Confirm the Illuminate license is active on the cluster, then reinstall or apply the content pack from the Illuminate section |
| Events arrive but fields are not mapped to the pack | The Beats prefix setting on the input does not match the prefix the content pack expects | Compare the input's Beats prefix with the pack documentation, correct it, and restart the input so new messages use the new prefix |
Questions buyers ask about Windows event log monitoring with Graylog
What does it cost to monitor Windows security events in Graylog?
The cost has three parts: the Graylog software, the Illuminate license for the Windows Security content pack, and the internal or partner time to build it. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, per the Graylog pricing page, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. The content pack itself needs a Graylog Illuminate license, so confirm its price with Graylog. Ask any quote to separate one-time build work from recurring support and upgrades, and to state which data volume it assumes.
Does the Illuminate Windows Security content pack need a paid Graylog license?
Yes. The Illuminate Windows Security content pack needs a Graylog Illuminate license, so it is not part of Graylog Open. The pack supports Winlogbeat 8.x through a Beats input, or NXLog through a GELF input, with both collectors deployed by Graylog Sidecar. Without the license you can still build a collection path and write your own parsing and searches on Graylog Open, but you will not get the prepackaged categorization. Confirm current Illuminate terms with Graylog before you commit to a design that depends on it.
Can we run Windows security event monitoring on Graylog Open alone?
You can collect and search Windows security events on Graylog Open, since it provides Beats inputs, GELF inputs, streams, pipelines, searches and dashboards. What changes without a paid edition is the prepackaged content. Graylog Enterprise adds a correlation engine and 24/7 support, and Graylog Security adds SIEM features such as risk scoring, anomaly detection, investigations and prebuilt threat detection content. Graylog Open also supports Active Directory and LDAP authentication, while Okta, generic OpenID Connect and SAML single sign-on need Enterprise. Decide which of these your team needs before choosing the edition.
How long does a Windows event log build take?
Duration depends mainly on the number of hosts, how many event policies you must define, and how quickly approvals arrive. Installing Sidecar, Winlogbeat or NXLog on a small test group is short compared with rolling out across domain controllers, member servers and workstations, each of which needs its own audit policy and collector configuration. Policy work is often the longest step, because you must decide which events to keep, such as 4624 successful logon, 4625 failed logon, 4688 process creation, 4720 user account created and 1102 audit log cleared, and how much volume they add. Ask for a schedule that breaks the work into phases by host group, and treat any single duration as provisional until the host list and policy decisions are final.
What access and information do we need to provide for this work?
Plan to provide a host list, the domain structure, an account that can apply audit policy changes such as domain administrator rights or delegated Group Policy rights, and a named owner for approvals. Network approvals are also needed so each host can reach the Graylog Beats or GELF input and the Sidecar management endpoint. Share which Windows Server versions you run, since Windows Server 2022 mainstream support ended on October 14, 2026 and Windows Server 2025 is the current release. Agree on who may change Group Policy and who signs off on new collector configurations before the build starts.
Should Windows security logs go through Winlogbeat or NXLog?
Both work with the Illuminate content pack, and the choice depends on your existing tooling and parsing needs. Winlogbeat is bundled with Graylog Sidecar and sends to a Beats input, with the content pack supporting Winlogbeat 8.x. NXLog sends to a GELF input and is useful if your team already runs it or needs its routing options. Sidecar can also manage an existing NXLog or Sysmon installation. Pick one per host group to keep configuration simple, and test field names against the content pack before rolling out.
Does the Windows event log work need a directory service change?
The collection itself does not require changing your directory, since Active Directory Domain Services already logs security events on domain controllers and domain-joined servers. What the work needs is consistent audit policy, applied through Group Policy to the right hosts, so the events you want exist in the first place. Linux systems are outside this path unless you configure them separately, for example through FreeIPA trusts. Confirm your audit policy design and Group Policy scope before changing collectors.
Where to confirm the content pack and collector details
Before you build parsing or alerts on Windows events, read the Illuminate Windows Security content pack documentation and treat it as the reference for which event IDs the pack categorizes and how its fields are named. Confirm with Graylog that the pack version you plan to install matches the Graylog release you run, and that your account includes the Graylog Illuminate license the pack requires. Ask Graylog which Winlogbeat versions the pack supports for your path, because the documented support is for Winlogbeat 8.x through a Beats input, and an NXLog path uses a GELF input instead. Record the answers in your scope document so the collector version on each host is chosen against a written support statement.
The Graylog Sidecar documentation is the next read for how collectors are installed, enrolled and configured from Graylog. Check which Sidecar release works with your Graylog server version, and confirm that the Winlogbeat and Filebeat versions it bundles on Windows are the ones your pack expects. Also confirm how Sidecar manages an existing NXLog or Sysmon installation, because a team that already runs one of these agents needs to know whether Sidecar will replace its configuration, manage it alongside, or leave it alone. Those choices decide who edits the collector configuration after go-live.
Keep the confirmation list short and specific: the Graylog version, the content pack version, the Illuminate license status, the Winlogbeat or NXLog version per host group, and the Sidecar release. Ask for the answers in writing and date them, since the documentation selector and the supported versions can change between Graylog releases. If a value in your environment differs from what the documentation describes, stop and resolve it before the first host is enrolled, because changing the collector or the input type after events have been indexed makes field mapping and search history harder to reconcile.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure. For Windows security event monitoring, we start from the event categories your security team needs to see, then build the collection path, parsing and alerting around them.
How we scope
- Engagements are fixed-scope, with the Windows event categories, domain controllers and servers in scope agreed in writing before work starts.
- The written scope names the collector choice, either Winlogbeat or NXLog through Sidecar, and the Graylog edition and content pack licenses it depends on.
- We confirm which domains, forests and Windows Server versions feed the platform, and which event IDs your detections and retention rules require.
How we build
- We configure Sidecar collector configurations, Beats or GELF inputs, prefix settings and streams for Windows security events in your Graylog environment.
- We test parsing of logon, failed logon, process creation and account change events against sample events from your own domain controllers and member servers.
- We set index retention and event definitions for the detections agreed in scope, and verify network paths from each Windows host to the Graylog inputs.
How we hand over
- You receive documentation of the collector configuration, input settings, stream rules, index sets and the event definitions built during the engagement.
- Runbooks cover adding a new Windows host to Sidecar, changing a collector configuration and verifying that events are arriving and parsed.
- Knowledge transfer sessions walk your operations team through troubleshooting missing events, journal pressure and the audit policy settings that feed the logs.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the platform is live.
- Retainers can cover Graylog version upgrades, content pack updates and changes to Windows audit policy as your domain estate grows.
- We recommend confirming licensing, supported Winlogbeat and Windows versions and retention periods with your Graylog and Microsoft contacts before scheduling.
