I’m setting up a process to link phishing alerts from Microsoft 365 Defender to our Sentinel workspace. The goal is to find devices that might be compromised after a user clicks a link.
I can get the alerts in, but I’m unsure about the best way to correlate them with network logs (like firewall or proxy) to pinpoint the specific internal host. What KQL queries or analytics rules have you found most effective for this? Also, how do you handle the time delay between the click and the potential malicious outbound connection?
The time delay is the killer, and everyone's shiny KQL queries fall apart because of it. You'll see a click at 10:05, but the beacon might not call home for hours, or even days, if it's a sleeper. Correlating on exact timestamps is useless.
You're better off building a timeline per user device after a high-confidence phish. Forget real-time joins. Suck in all network traffic for that internal IP for the next 72 hours and look for anomalies, like new domains or odd ports, instead of trying to match a specific alert. It's noisy, but less likely to miss the slow burn.
Also, hope your proxy logs actually capture the internal source IP reliably. Half the time they don't, and you're chasing NAT garbage.
It's not secure, it's just not exploited yet.
Exactly, and this is where vendor lock-in starts to bite. Your entire process is now dependent on Microsoft's telemetry and timelines matching your network gear's logs, which were never designed to work together. You're trying to build a coherent picture from data sources that are fundamentally misaligned because each vendor has their own silo.
You mention the 72-hour window. That's a huge volume of data to retain and process in Sentinel, and the costs are astronomical. Most teams will shrink that window to save money, which means they'll miss the sleeper beacons you mentioned. The 'solution' creates its own failure point through sheer expense.
And let's talk about the proxy logs. If they don't capture the internal IP reliably, you haven't just got a technical hurdle, you've got a failed security investment. You paid for a SIEM to correlate data that doesn't exist. The real problem isn't writing the KQL, it's that the foundation is rotten.
Skeptic by default
The timestamp problem is real. We solved it by shifting from alert matching to creating a dynamic watchlist. When a high-confidence phish clicks, we add the user's device (via its internal IP) to a Sentinel watchlist for the next 7 days. All our network log analytics rules then reference that list.
So our KQL doesn't look for a specific event. It just checks if any outbound traffic from a watchlisted IP hits a newly observed domain or a known-bad port. It catches the slow calls.
But like user1052 said, it's only as good as your logs. We had to fix our proxy configs to log the true source IP, not just the NAT gateway, before this even started to work.
K8s enthusiast
Your watchlist approach is clever, but you've just swapped one dependency for another. Now your entire detection model hinges on the accuracy and consistency of that internal IP mapping in M365 Defender's alerts.
If Defender tags the wrong endpoint or grabs an IP from a VPN session that's since changed, you're feeding garbage into a seven-day monitoring window. That's a lot of noise for your analysts to sift through, possibly diluting focus from real threats.
And the cost factor from user760's point isn't solved, it's just shifted. You're still retaining and querying 7 days of network traffic for every watchlisted IP. That might be fine for a few alerts a week, but scale it up and you're right back in that astronomical cost conversation, just with a different query structure.