Hunting Threats Across Entra ID and Purview with PowerShell

If you’ve ever had to handle an escalation on a Friday afternoon, you know the drill: you are jumping between the Entra ID portal and Microsoft Purview audit searches, trying to figure out what a compromised account touched while management asks for an update every ten minutes.

Clicking through portals during an active security incident simply doesn't scale. While vendor marketing loves to talk about "unified single-pane-of-glass dashboards," those of us actually running cloud environments know that customized automation scripts are what actually save your weekend.

Here is a practical look at how to hook PowerShell into Microsoft Graph and Purview to automate high-risk identity detection and data impact assessments before an incident turns into a full breach.

1. Catching Suspicious Entra ID Activity (Beyond Simple Failures)

Moving away from the legacy AzureAD and MSOnline modules wasn't painless, but the Microsoft.Graph SDK gives us direct access to the raw sign-in and audit APIs.

Instead of just looking for failed passwords, we want to look for specific high-confidence risk signals—like a legacy authentication protocol bypassing Conditional Access, or a spike in failed logins immediately followed by a success from the same IP (credential stuffing).

Here is a lean script pattern for pulling risky sign-in patterns from the last 24 hours:

TIP: Watch out for Graph API throttling (HTTP 429 Too Many Requests) when pulling large volumes of logs. In production scripts, always wrap your API calls in a retry loop with exponential backoff.

2. Moving Away from Search-UnifiedAuditLog Pain

If you’ve ever tried running Search-UnifiedAuditLog across a multi-thousand user tenant during an investigation, you already know the pain: session timeouts, missed events, and severe throttling.

Microsoft has been pushing the Microsoft Purview Audit Search Graph API for asynchronous searches, and it is significantly better for automation:

1. Submit the Job: You send an asynchronous POST request to create an audit search job defining your date range, target user, and operations (e.g., FileAccessed, FileDownloaded).

2. Poll Status: The script periodically polls the job status instead of holding an open synchronous connection that drops.

3. Retrieve Results: Once completed, you page through the results without fighting PowerShell console timeouts.

If a high-risk user is flagged in Entra ID, your runbook should immediately kick off a Purview audit job targeting that specific UserPrincipalName to pull all file interactions over the prior 48 hours.

3. Building an Automated Response Workflow

Automation shouldn't immediately delete accounts without human review, but it should handle containment and evidence gathering instantly.

A battle-tested incident workflow looks like this:

• [ Anomaly Detected ]

• [ Revoke User Sessions ] ──► (Revoke-MgUserSignInSession)

• [ Kick off Purview Audit ] ──► (Query Graph API for accessed files)

• [ Generate SOC Report ] ──► (Post summary to Teams / SIEM / Ticket)

Quick Session Revocation Snippet: When an account shows confirmed compromised credentials, do not wait for manual intervention to force a token refresh:

Real-World Gotchas to Avoid

• Service Principal Permissions: Don't give your automation App Registration Directory.ReadWrite.All if it only needs AuditLog.Read.All. Stick strictly to least privilege.

• Audit Retention: Remember that standard Audit logs in Purview are retained for 180 days by default. Don't design scripts expecting 2-year-old logs to be available out of the box.

• Time Drift: Always normalize your timestamps to UTC (.ToString("yyyy-MM-ddTHH:mm:ssZ")) across both Entra and Purview queries, or you will end up missing logs during cross-timezone investigations.