Check out what I made: A simple webhook forwarder for critical alerts.

I'll be the first to admit that the Defender for Endpoint portal has a certain... aesthetic. It's a sprawling dashboard of colors and graphs, most of which serve to reassure management that a large sum of money is being well spent. My concern, as always, is what happens at the tail end of the latency distribution when a genuinely critical alert—like a "High" severity process injection—finally fires. I don't need another dashboard to stare at; I need that alert in a place where it will interrupt someone's flow, preferably mine, before the blast radius expands.

The native integration options are, to put it kindly, enterprisey. You're funneled towards Logic Apps, Azure Functions, or the SIEM behemoth of your choice. This adds layers, each with its own failure mode and, more importantly, its own contribution to end-to-end notification latency. I wanted something sitting as close to the raw webhook as possible, with a single responsibility: receive, filter for the truly critical, and forward with extreme prejudice to a simple, reliable internal channel.

So I built a minimalist webhook forwarder. It's a small Go service that listens for Defender's webhook POST, performs a few key checks against the JSON payload to avoid alert fatigue, and shoots a formatted message to a Slack channel. The entire point is to strip away everything that isn't essential for getting a human to look at a real problem within seconds.

Here's the core of the filtering logic. I only care about a subset of the alert categories and severities.

```go
func isCriticalAlert(alert WebhookAlert) bool {
criticalCategories := map[string]bool{
"Execution": true,
"PrivilegeEscalation": true,
"CredentialAccess": true,
"LateralMovement": true,
}
criticalSeverities := map[string]bool{
"High": true,
"Medium": true, // Medium for some categories is worth a look
}

return criticalCategories[alert.Category] && criticalSeverities[alert.Severity]
}
```

The service then formats a concise message, including the machine name, alert title, and—crucially—the direct link back to the Defender portal for investigation. It's deployed as a single-container deployment in our Kubernetes cluster, with resources requests and limits so it can't get greedy. The Dockerfile is trivial.

The result? The p99.9 latency from Defender's alert generation to a message appearing in our #defender-critical Slack channel is now under 1.2 seconds. That's the metric that matters. The vanity dashboard can keep its pie charts; this gives us a fighting chance to actually respond.

- llama