Send Windows Event Logs to Sophos XDR and SIEM

Microsoft Windows Event Log can be sent through a supported forwarder in Snare-over-syslog format to a Sophos XDR Data Collector. This is a separate path alongside the Sophos Endpoint agent: neither a local Windows event ID nor a green endpoint status proves that an event was ingested through this integration.

The procedure is to deploy the collector, define Windows events and audit requirements, point the correctly formatted forwarder at UDP/514, and verify a defined event in Sophos.

Confirm scope and licensing before deployment

Depending on the events actually forwarded, the integration can ingest authentication, account/group changes, processes, Defender malware findings, administrative changes, directory audits and other security events. Documented schemas are auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt and netflow.

The SIEM licensing requirement concerns netflow telemetry, such as Windows Filtering Platform connection events including 5156. It does not make every other listed Windows event SIEM-only. Your XDR/MDR tenant must nevertheless have the required integration and source entitlements. SIEM scope and the integration guide explain that check.

Prepare the collector, forwarder and data protection

You need a working XDR Data Collector, an approved network path from the Windows sources, and forwarding software that outputs Snare-over-syslog. Sophos lists examples including Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows and NXLog Community Edition. This does not mean they share identical fields, licences or configuration files.

The collector runbook covers resources, DNS, time synchronization and uplinks. Here, allow inbound UDP/514 only from the intended Windows source networks. UDP does not acknowledge each message; a successful network or port test therefore cannot replace event evidence.

Before configuration, record the source computers or domain controllers, required event IDs, existing audit settings, responsible team and previous logging path. Events can contain usernames, resource paths or process arguments. Collect only approved content and do not copy raw logs or credentials into publicly accessible tickets.

Configure Windows forwarding

1. In the correct Sophos tenant, identify the deployed collector under Security Operations > Integrations > Data Collectors. Use the IP reachable from the Windows sources, rather than a regional Sophos upload address or another appliance’s IP.
2. Deploy the chosen forwarder on an approved pilot computer following its product instructions. Back up existing configuration and identify other outputs before changing a shared file.
3. Explicitly configure Snare-over-syslog. Sophos requires this format; arbitrary JSON, CEF or Windows Event XML is not a confirmed substitute for this path.
4. Set the actual collector IP and UDP port 514 as the receiver. The selected event channels or filters must include the events needed.
5. Output source timestamps in UTC and verify Windows time synchronization. The local Event Viewer display alone does not establish which time zone the forwarder sends.
6. Activate the configuration and check the forwarder for local errors. Complete the event comparison below before enrolling more computers.

For NXLog CE, download the configuration template nxlog_wel.txt supplied by Sophos. It is a starting point for the documented Snare format, not an unchecked replacement for every existing NXLog configuration. Collector target, event selection and existing outputs must fit the environment.

The currently linked template sets define PORT 601 and, in the MSWINEVENTLOGOUT block, uses Module om_tcp; it is therefore not suitable unchanged for the UDP/514 path described here. For this path:

1. In define XDR A.B.C.D, replace only the placeholder A.B.C.D with the actual collector IP; retain define XDR.
2. Set the port line to define PORT 514.
3. In the MSWINEVENTLOGOUT output block, comment out Module om_tcp and enable the existing Module om_udp line. Keep only one output module enabled in this block; preserve other existing outputs separately.

Then check syntax and event delivery in the pilot. Sophos provides best-effort assistance; advanced forwarder problems belong with the relevant vendor.

Process command line for event 4688

Some detections need fields that Windows does not log by default. To include the command line alongside process creation in event 4688, Sophos identifies this Windows policy:

Administrative Templates > System > Audit Process Creation > Include command line in process creation events

Enable it only for the approved scope after considering its contents. Command lines may contain sensitive values. The setting replaces neither the required creation of process audit events nor the forwarder’s event 4688 filter.

For verification, start an approved harmless process without secrets in its arguments. First confirm the expected command line in the Windows event 4688, then compare the corresponding normalized process event in Sophos. If the field is absent at the source, the collector cannot reconstruct it.

Prove ingestion with a source event

An approved login using a dedicated test account is suitable for an initial test. Windows event 4624 or 4625 can establish successful or failed authentication; deliberately causing a failure must not trigger account lockout. Use only an event actually produced within the chosen audit and forwarding scope.

1. Record event ID, computer, user, outcome and time in the Windows source log. Include only sanitized values in the test record.
2. Confirm that the forwarder outputs that category without local format, permission or connection errors.
3. In the correct Sophos tenant, check the source’s data flow, then its record in the expected schema. Compare source computer, timestamp, user and result with the Windows evidence. Expect auth for a login and process for event 4688.
4. Repeat for other required categories. A login does not prove ingestion of Defender findings, directory audits or netflow.
5. Compare fresh records over an appropriate observation period and record scope, owner and next review as part of acceptance.

The event need not trigger a detection or MDR case. Successful ingestion today also proves neither historical completeness nor retention entitlement for all data. Separate licensing and retention checks still apply.

Investigate missing fields and gaps

No Windows event: Check audit settings, the selected channel and actual source activity first. Without a source event, nothing can be forwarded.

Source event exists, nothing found in Sophos: Compare forwarder filters, Snare-over-syslog format, UTC timestamps, collector IP and UDP/514 connectivity. Then inspect collector state and data flow for the corresponding period. Do not add a second forwarder to the same stream as a precaution.

Event exists, required field missing: Compare the field in the Windows original, forwarder output and normalized record. For process arguments, check event 4688 and the approved command-line policy. Do not substitute an invented default value.

Only netflow missing: Check Windows Filtering Platform events, forwarder selection and SIEM entitlement separately. A working login path does not prove this additional scope.

Roll back the pilot or hand over operations

For rollback, stop only the newly configured output or pilot filter and restore the saved forwarder configuration in a controlled manner. Preserve other outputs and shared collectors. Revert an audit policy only after comparing the documented original state and obtaining approval; other security or evidence requirements may also depend on it.

Then verify that the previous required logging path works and no unintended duplicate ingestion exists. Stopping forwarding does not restore lost UDP events or establish deletion of telemetry already sent. In ongoing operation, the named team remains responsible for source scope, time synchronization, data flow, template changes and forwarder updates.