“How the heck am I supposed to forward logs without using the thing that forwards logs?”

I didn’t want to fight InfoSec. I wanted to work around it — securely and scalably.

What I Needed

• RDP logins (4624 / LogonType 10)
• Software installs (1033)
• Windows updates (Setup logs)
• IIS failures and warnings

What Didn’t Work

• Default WEF over WinRM (5985/5986) — blocked
• Pull model — not feasible in our environment
• Installing agents — not approved for this use case

The Solution That Worked

I configured a custom WinRM listener on port 4123, scoped strictly to allow Event Forwarding — and nothing else.

• No PSRemoting
• No management capabilities
• Only client-initiated log pushing to the collector

What I Did (High-Level)

Firewall

• Opened port 4123 only to the collector
• Restricted to known VLANs/subnets

On the Collector

• Enabled Event Collector service
• Created a WinRM listener on port 4123
• Configured source-initiated subscriptions

On the Clients

• Enabled WinRM via GPO only on port 4123
• Set the SubscriptionManager registry key
• Added NETWORK SERVICE to Event Log Readers

Why It Worked

• No agents
• Domain-authenticated traffic only (Kerberos)
• Scales without risk of remoting abuse

Want to Try It?

Here’s the full Microsoft guide on WEF if you want to explore deeper.

Final Thoughts

This solution helped us achieve visibility into login activity, updates, and app crashes — all without compromising the security perimeter.

Sometimes the best way to work within the policy is to reshape the pathway — not break it.