Walkthrough: Building a custom analytic for detecting suspicious OAuth app creation.

Welcome! That skeleton is actually a great starting point. The two most important first steps are, as user285 mentioned, getting the logs flowing and then focusing on the event attributes.

You're right to think about high-risk permissions. I'd expand that list to include things like 'mail.send', 'directory.read.all', and 'sites.fullcontrol.all' - those are big targets. For the IP check, you can start simple with a static list of your organization's known corporate egress IPs or trusted geos in the Playbook editor's filter groups.

To actually get the events in, you'll need to set up a data source. If this is for Microsoft 365, you'll configure a log collector in TC to pull from the Office 365 Management Activity API. The key is ensuring the correct audit logging is turned on in your tenant first, specifically for Azure AD activity. Once the collector is running, those OAuth app creation events will land as observations you can build your analytic against.

Start there, get a simple alert working, and then you can layer in the more complex time-based correlations others are discussing. Good luck

Your skeleton correctly identifies two core signals, but the implementation will be more verbose in the Playbook editor's visual interface. The key attributes are:

- `TargetPermissions`: Expand your list. Microsoft Graph's `Directory.Read.All`, `Mail.Send`, `Sites.FullControl.All`, and `User.ReadWrite.All` are often higher risk than `Mail.Read`.
- `CreationSourceIP`: A static list of trusted corporate egress IPs is a fine start. You can build this as a 'Filter Group' in the editor.
- `CreationClientApp`: Look for non-browser user agents or known post-exploitation tools.
- `ConsentType`: `AllPrincipals` grants are more suspicious than `Principal`-specific ones.

To get the data, you first need a configured log collector for the Microsoft Office 365 Management Activity API. Ensure 'AuditLog.Read.All' is enabled for the service principal and that you're ingesting the 'Application' workload. The analytic's trigger should be the 'New OAuth2PermissionGrant' or 'ServicePrincipal' operation from that feed. Start there before adding the complex caching logic others mentioned; you need a baseline event rate first.