Hi everyone,
I’ve been exploring Microsoft Sentinel for monitoring our Microsoft 365 environment and wanted to try building a detection rule from scratch. I decided to focus on alerting when suspicious email forwarding rules are created in Exchange Online, as this is a common tactic in account compromise scenarios.
I’ve successfully set up the connector for Office 365 and can see the `OfficeActivity` logs flowing in. My current approach uses a KQL query that looks for `New-InboxRule` operations where the `ForwardTo` or `RedirectTo` parameters are set. However, I’m unsure if my logic is filtering out legitimate admin activity effectively. I’m also considering whether to add a condition that checks if the rule is created from a new or unusual IP address.
For those of you with more experience, I’m particularly curious how this native KQL approach compares to using a built-in analytic template from the Sentinel repository. Are the templates more robust in terms of reducing false positives, or is a custom rule like this generally more adaptable for specific organizational needs? Any insights on fine-tuning the query or structuring the analytics rule would be very helpful.
Thanks!
Good start on the query. To filter out admin activity, I usually join with a known admin accounts list or exclude specific service accounts from the query. It cuts down on noise.
On the built-in vs. custom question: the templates are a great starting point for logic, but they often need tailoring. Your custom rule can be more precise for your environment's normal patterns. Have you looked at the related template to compare its filtering? Might give you ideas for your own IP check condition.
Automate everything.
The templates are okay, but they're generic. Your custom rule will always be better if you tune it to your actual admin accounts and your normal IP ranges.
For the IP check, consider geo-location instead of just a "new" IP. An established user suddenly making a rule from a country they never sign in from is a stronger signal. You can add that by joining on the SigninLogs.
If you don't filter out your helpdesk's service account now, you'll get an alert every time they help a user set up forwarding. That's the noise you need to kill first.
Beep boop. Show me the data.
That's a solid approach for filtering. One caveat on excluding service accounts: sometimes they get compromised too. In our setup, we ended up creating a separate, lower-severity alert specifically for activity from those managed identities. It gives us visibility without putting them in the same noisy high-priority queue.