Palantir Windows Event Forwarding for Incident Detection

What Windows Event Forwarding Solves for Security Teams

Palantir windows-event-forwarding addresses a specific gap in Windows environments: security-relevant events are generated locally, but the organization needs a centralized copy for detection, investigation, and response. The README says the project was built around Palantir's internal WEF pipeline for collecting logs with forensic and security value from Microsoft Windows hosts. Its intended users are organizations that operate Windows workstations or servers and want a practical foundation for centralized Windows event collection.

The repository is not a SIEM, an alerting engine, or a complete incident response platform. Its role is closer to a collection design kit. Once events are collected and indexed, the README says alerting and detection strategies can be built from high-fidelity signals such as log deletion, as well as deviations from expected activity, including unusual service account access, access to sensitive filesystem or registry locations, and malware persistence indicators.

That distinction matters for adoption. A team can use the repository to move Windows logs toward a collector, but it still needs somewhere to index those events, rules or analytics to interpret them, and an operational process for responding to alerts. The repository supplies reusable pieces for the collection stage rather than the complete detection chain.

WEF Push and Pull Collection Architecture

Windows Event Forwarding uses native Windows components to send event logs to one or more centralized Windows Event Collector, or WEC, servers. According to the README, events can move through either a push or pull mechanism. The exact configuration for those modes is not documented in the repository excerpt, so an adopter must consult the relevant Windows documentation or the associated configuration files before deciding how traffic will flow.

The data path is conceptually straightforward. A Windows host produces event log entries, a subscription decides which events are submitted, and a WEC server receives them. Event channels on the collector act as queues for storing entries. The events can then be indexed and used by detection and response systems. The README also describes optional PowerShell transcription logging as a collector-side target, which broadens collection beyond ordinary event records when that configuration is required.

WEF is agent-free at the forwarding layer because it relies on components integrated into the operating system. The README states that it works with workstation and server Windows builds. It also documents mutual authentication and encryption through Kerberos in a domain, with TLS available for additional authentication or for machines that are not domain joined. Those transport and identity decisions belong in the deployment design rather than being hidden in the subscription XML.

Subscriptions, Event Channels, and Group Policy Assets

The repository layout reflects the main design decisions in a WEF deployment. The `wef-subscriptions/` directory contains subscriptions that select events, define where they are stored, and control cadence and batch size. Subscription XML supports a subset of XPath. That syntax can filter event IDs, suppress noisy records, batch events, and adjust delivery speed, but it is not the full XPath language.

The `windows-event-channels/` directory contains event channel definitions. These are queues on the collector, so they provide a server-side destination for forwarded entries. The exact channel manifests and subscription files are part of the repository contents, but the README excerpt does not document every file-level setting or provide a one-command deployment procedure. Reviewing those files is therefore necessary before copying them into a production environment.

The `group-policy-objects/` directory contains recommendations for auditing, event collection, forwarding, and related Windows configuration. This is the part most directly tied to fleet rollout. The README's sequence places auditing GPO deployment before collector configuration and subscription loading. That order reflects a dependency: the source hosts need to generate the relevant audit records before a subscription can collect them.

The repository also includes `AutorunsToWinEventLog/`, a script that uses existing WEF infrastructure and Sysinternals' Autoruns to collect persistence and auto-start artifacts. It is useful for adding that category of evidence to the pipeline, but its presence does not mean that the repository automatically indexes or alerts on those artifacts.

Lab-First Setup and First Collection

The README does not provide package installation commands, version requirements, or a complete PowerShell deployment script. It directs users to download the repository and review its contents. For a first real use, follow the documented sequence in a lab environment before applying anything to production.

Begin by downloading the repository and reviewing the subscriptions, event channels, GPO recommendations, and Autoruns script. The README recommends a lab deployment, which is particularly important because GPO changes can alter auditing and collection behavior across multiple Windows systems.

Next, deploy the auditing GPOs to the fleet so that security-critical events are generated. Configure one or more Windows Event Collector servers and apply the associated GPOs. If PowerShell transcription logging is needed, configure the WEC server for that purpose as an optional step. Then deploy the Windows event channels to the WEC servers and load one or more WEF subscriptions.

The first useful result should be an event appearing in the intended collector channel. After that, confirm that the event carries the expected identity, timestamp, and subscription context before sending it onward for indexing or detection. The README's final instruction is simply to start collecting data and hunting for threats. It does not document a health check command, expected event count, rollback procedure, or validation query.

Operational Limits and Detection Trade-offs

The main limitation is scope. This repository does not document a full production deployment, and its README explicitly treats the contents as building blocks for evaluation and deployment. A team that lacks Windows Event Collector expertise may find that the XML, GPOs, channels, transport security, and downstream indexing require substantial integration work.

Subscription design also creates a trade-off. Filtering out noisy events can reduce collection overhead, while forwarding too much can increase storage and processing pressure. The README states that subscriptions control cadence and batch size, but it does not provide capacity figures, retention recommendations, or a sizing method. Those limits depend on the event mix and the downstream system, which this repository does not specify.

The agent-free description should not be interpreted as zero maintenance. WEC servers, Group Policy, certificates or Kerberos configuration, event channel manifests, and subscription XML still require administration. The README also does not describe behavior for disconnected hosts, duplicate delivery, collector outages, replay, or retention failure. Those cases need validation in the lab.

For incident detection, centralized collection is only the input side. The repository does not state that it creates alerts, prioritizes incidents, preserves case evidence, or provides response actions. Teams expecting an out-of-the-box detection service will not find those capabilities in the listed contents.

WEF Compared with Windows Event Log Collection

A relevant alternative is collecting Windows event logs through a conventional SIEM or log-management agent. The practical difference is architectural. WEF uses Windows-native forwarding and WEF subscriptions to move selected events toward Windows Event Collector infrastructure. A conventional SIEM agent usually collects logs from endpoints and sends them to the SIEM using its own agent, transport, parsing, and retention model.

This repository does not compare those alternatives or claim that one is preferable for every environment. Based on the documented design, WEF is a sensible fit for organizations that want to use native Windows collection, control event selection through subscription XML, and place Windows Event Collector servers in the path. It can also support non-domain-joined machines through the TLS option described by the README.

A SIEM-oriented collection approach may be easier when the organization already has an agent-based pipeline, standardized log normalization, and a single destination for multiple source types. WEF-based deployment can require more Windows-specific planning around GPOs, WEC servers, channels, authentication, and subscription maintenance. The choice should therefore follow the existing logging architecture and the skills available to operate it, rather than the repository's label alone.

Maintenance, Releases, and License Review

The repository is not archived, and its last push was on 2026-10-02. That date indicates recent repository activity, but the project has no GitHub releases, so there is no release history to use as an upgrade or compatibility signal. The README does not document a version matrix for supported Windows builds, a deprecation policy, or a formal upgrade procedure. An adopter should treat subscription and manifest changes as configuration changes that require review and lab validation.

The repository metadata describes the license as Other, with a custom license that GitHub cannot classify, and points to `LICENSE.md`. The README text presents an MIT License notice and includes the MIT permission and warranty language. Because those signals are not identical, the actual `LICENSE.md` should be reviewed before redistribution or deployment. This article does not provide legal advice. The practical software question is whether the files and documentation may be copied, modified, and distributed under the terms in the repository's license file.

Upgrade cost is likely to include reviewing changed XML subscriptions, event channel manifests, GPO recommendations, and the Autoruns script. The README specifically says contributors should not include the compiled `CustomEventChannels.man` DLL in a pull request, and that maintainers will compile the updated manifest into a DLL after merge. That contributor instruction does not define a consumer upgrade process, so it should not be treated as one.

Editorial conclusion

Adopt this repository as a starting point for Windows security teams that already understand WEF, Windows Event Collector, Group Policy, and XML subscriptions. Do not treat it as a finished monitoring product or deploy its configurations without a lab and a review of the repository's LICENSE.md. Verify event coverage, collector topology, authentication choices, and license terms first; the last recorded push was on 2026-10-02, and the repository has no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. palantir/windows-event-forwarding on GitHub
3. README