Microsoft WinRM Data in Graylog

If you’re running Windows in your environment, WinRM is one of the most valuable, and most abused channels in your infrastructure. Graylog provides a purpose-built way to make those logs immediately actionable. The Microsoft WinRM Content Pack, available with an Illuminate license and Graylog Enterprise or Graylog Security, delivers ready-to-use parsing rules, streams, GIM categorization, and a dashboard so you can turn raw WinRM operational events into structured, searchable security intelligence.

What is Microsoft WinRM?

Windows Remote Management (WinRM) is Microsoft’s implementation of the WS-Management protocol, a SOAP-based protocol that enables remote administration of Windows systems. It’s the backbone of PowerShell remoting, Invoke-Command, Windows Remote Shell, and a wide range of administrative tools.

Because WinRM is a legitimate, built-in Windows service, it’s also a favored technique for attackers performing lateral movement after establishing an initial foothold. Tools like Evil-WinRM are purpose-built to exploit it. Logging WinRM operational events gives your security team clear visibility into both legitimate administrative activity and potential abuse.

What This Pack Does

The Microsoft WinRM Content Pack is purpose-built for environments running Windows Server 2012 R2 or later (and Windows 10 or later) using NXLog or Winlogbeat for log delivery. Once installed, it automatically parses the Microsoft-Windows-WinRM/Operational event log channel into Graylog schema-compatible fields. Graylog Pipeline rules normalize WinRM operation names to canonical event action verbs, enriches WSMan error codes with human-readable descriptions, and maps events to the Graylog Information Model (GIM).

Getting Logs into Graylog

Step 1 — Configure a Graylog Input

Create either a GELF TCP/UDP input (for NXLog) or a Beats input (for Winlogbeat) in your Graylog instance. Note the port for use in your agent configuration.

Step 2 — Configure NXLog (Option A)

Configure NXLog to read the WinRM Operational channel and forward via GELF:

<Input eventlog>
    Module      im_msvistalog
    PollInterval 1
    SavePos     False
    ReadFromLast True
    <QueryXML>
        <QueryList>
            <Query Id='1'>
                <Select Path='Microsoft-Windows-WinRM/Operational'>*</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

<Output gelf_out>
    # Change to om_tcp if your Graylog input is configured for GELF TCP
    Module      om_udp
    Host        <your-graylog-server>
    Port        12201
    # Instructs the module to package data using the xm_gelf extension
    OutputType  GELF_UDP
</Output>

<Route winrm_to_gelf>
    Path        winrm_logs => gelf_out
</Route>

Step 3 — Configure Winlogbeat (Option B)

Add the WinRM Operational channel to your Winlogbeat configuration and point the output at your Graylog Beats input:

winlogbeat.event_logs:
– name: Microsoft-Windows-WinRM/Operational

output.logstash:
hosts: [“your-graylog-server:5044”]

Step 4 — Install and Activate the Content Pack

In Graylog, navigate to Enterprise → Illuminate, locate the Microsoft WinRM Processing Pack, Spotlight, and activate it. The stream and index set are created automatically. No additional rules are needed.

Events Processed by This Pack

The content pack processes events from the Microsoft-Windows-WinRM/Operational channel across five key categories:

• Session lifecycle (Event IDs 6, 80, 91): outbound session creation, request dispatch, and inbound session reception — with network direction tagging (inbound/outbound).
• Operation events (132, 142, 143, 172, 774, 775, 1025, 1048, 1840, 1843, 2049): WSMan operation success, failure, response handling, and protocol diagnostics.
• Authentication events (161, 164, 169, 1291, 1295): user and machine authentication failures and successful credential validation.
• Authorization events (192, 1536): post-authentication access decisions.
• Service lifecycle events (208, 210, 213, 215, 224): WinRM service start, stop, security and plugin errors, and configuration changes.

GIM Categorization

All events are mapped to the Graylog Information Model, enabling consistent correlation with other data sources across your environment:

Why Log WinRM Events?

Collecting WinRM operational logs gives you more than a record of remote sessions — it directly supports security detection, incident response, and compliance audit use cases.

Security Monitoring

• Detect lateral movement via WinRM from compromised hosts
• Identify repeated authentication failures indicating brute-force or credential stuffing
• Spot unusual outbound session creation from unexpected source systems
• Flag Evil-WinRM or similar post-exploitation tool patterns

Threat Hunting

• Search for Invoke operations (Event 132) from non-admin accounts
• Correlate session events with authentication logs to trace attacker paths
• Identify WinRM sessions originating from workstations rather than jump servers

Incident Response

• Reconstruct the timeline of remote sessions during an investigation
• Identify which systems an attacker touched via WinRM after initial access
• Review authorization events to determine what access was granted

Compliance & Audit

• Maintain an immutable record of remote access to critical Windows systems
• Demonstrate access controls are working as required by PCI DSS, HIPAA, or SOC 2
• Log WinRM service configuration changes for change management audits

Graylog Enterprise and Security

With Graylog Enterprise and Security, your team gains structured visibility into one of the most commonly exploited lateral movement channels in Windows environments. The WinRM Content Pack turns raw operational event logs into searchable, correlated, GIM-tagged data that flows directly into your threat detection, alerting, and investigation workflows. For full details on the fields extracted by this pack, see the Illuminate documentation.