The Hunt-to-Detection Pipeline: Worked End-to-End

Why OAuth consent is the right technique for this example

This worked example uses OAuth abuse because it exercises every Hunt Cycle step in ways that simpler techniques do not. Its hypothesis draws on real threat intelligence. The scope must cross two separate log tables (AuditLogs for consent events and AADServicePrincipalSignInLogs for post-consent application behavior), forcing multi-table collection. Analysis requires enrichment across all five dimensions because a consent event alone is not malicious; the enrichment is what separates a user installing Grammarly from a user granting Mail.ReadWrite to a phishing application. And the conversion step produces two distinct detection rules: one for illicit consent and one for device code flow, demonstrating how a single hunt can close multiple detection gaps simultaneously.

OAuth consent phishing also reflects a technique class that has accelerated sharply. Microsoft's own managed consent policy, enabled by default in July 2025, blocks user consent to unverified third-party applications accessing files and sites. But managed consent does not cover all permission scopes, and the device code flow bypasses the consent screen entirely. EvilTokens, a phishing-as-a-service platform first documented in February 2026, commoditized device code phishing into an accessible service that compromised over 340 organizations in its first five weeks. Techniques that have been operationalized at this scale are exactly the techniques that hunting programs should target first.

Figure TH1.8 — Complete Hunt Cycle. Six steps, five queries, one compromise found, two detection rules deployed. Two OAuth technique gaps move from unmonitored to automated detection in a single campaign.

Step 1 — Hypothesize

Tom formulates the hypothesis using the four properties from Section 1.1. The threat intelligence source is specific: Microsoft's advisory on Storm-2372's device code phishing campaigns, which describes a technique where attackers send phishing messages disguised as Teams meeting invitations. The victim enters a short alphanumeric code at microsoft.com/devicelogin, authenticates normally including MFA, and unknowingly grants the attacker a refresh token with delegated permissions to the victim's mailbox, OneDrive, and calendar.

Both techniques must be testable against NE's telemetry. Device code flow authentication appears in SigninLogs with AuthenticationProtocol == "deviceCode". Consent grant events appear in AuditLogs with OperationName == "Consent to application". Both tables are ingested into NE's Sentinel workspace.

Tom scores the hypothesis using the three-dimension model from Section 1.1. Relevance is high: OAuth abuse bypasses MFA and persists beyond password resets, and NE has no detection coverage. Data availability is high: both required tables are ingested with 90-day retention. Severity is high: a successful consent phishing attack grants persistent mailbox access without triggering credential alerts. Score: 27 (9×3). This hypothesis goes to the top of the backlog.

Step 2 — Scope

Tom defines the four scoping dimensions from Section 1.2.

Data sources. AuditLogs for consent events. SigninLogs for device code flow authentication. AADServicePrincipalSignInLogs for post-consent application behavior. Three tables, each covering a different phase of the attack chain: initial access (device code or consent phish), persistence establishment (consent grant), and post-compromise activity (application sign-ins).

Time window. Ninety days. Consent phishing creates persistent access because the malicious application retains its permissions until an administrator explicitly revokes them. A 30-day window would miss consent grants that occurred two months ago but are still actively exfiltrating data. Tom checks retention and confirms all three tables have 90-day data.

Population. Full tenant. Consent phishing targets any user, not just privileged accounts. A marketing coordinator who consents to a malicious application that requests Mail.ReadWrite has just given the attacker full access to their mailbox, which may contain sensitive contracts, financial documents, or credentials shared via email. Restricting the population to administrators would miss the most common attack path.

Success criteria. Positive finding: an unrecognized application with high-privilege delegated permissions consented to by a non-IT user, or device code flow authentication from an unmanaged device by a user who does not operate IoT or conference room equipment. Negative finding: full tenant examined across 90 days, no unrecognized high-privilege user-consented applications found, no anomalous device code flow usage identified.

Step 3 — Collect

Tom follows the iterative query funnel from Section 1.3: orientation, indicator, refinement, enrichment, pivot.

Query 1: Orientation. How many consent events exist in the 90-day window?

// Q1: Orientation - consent event volume across 90 days
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == "Consent to application"
| where Result == "success"
| summarize
    TotalConsents = count(),
    UniqueApps = dcount(tostring(TargetResources[0].displayName)),
    UniqueUsers = dcount(tostring(InitiatedBy.user.userPrincipalName))

Result: 347 consent events, 42 unique applications, 189 unique users. This is expected volume for an 810-person organization, and most consents are legitimate productivity tools. This orientation query establishes the baseline and confirms the data source is populated.

Query 2: Indicator. Filter to high-privilege delegated permissions. Consent phishing targets permissions that provide mailbox access, file access, or the ability to send email on behalf of the user.

// Q2: Indicator - consent events with high-privilege permissions
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == "Consent to application"
| where Result == "success"
| extend AppName = tostring(TargetResources[0].displayName)
| extend ConsentedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend Permissions = tostring(TargetResources[0].modifiedProperties)
| where Permissions has_any (
    "Mail.ReadWrite", "Files.ReadWrite.All",
    "Mail.Send", "Directory.ReadWrite.All")
| project TimeGenerated, ConsentedBy, AppName, Permissions

Result: 12 consent events with high-privilege permissions. One filter narrows 347 results to 12, a 97% reduction. This is the indicator query pattern from Section 1.3: move from volume to signal with one targeted condition.

Query 3: Refinement. Exclude known IT and admin users. IT staff regularly consent to applications as part of their administrative duties. Consent phishing targets non-admin users who should not be granting high-privilege application permissions.

Tom filters out the IT department distribution list members and the three named admin accounts. Result: 4 consent events from non-IT users.

Query 4: Enrichment. Tom examines each of the 4 applications individually:

1. Grammarly. Recognized productivity tool, verified publisher. Legitimate.
2. Adobe Acrobat. Recognized, verified publisher. Legitimate.
3. Zoom. Recognized, verified publisher. Legitimate.
4. "DocuHelper Pro". Not recognized. No verified publisher. Consented by l.chen@northgateeng.com on 2026-02-15. Permissions: Mail.ReadWrite, Files.ReadWrite.All.

Three of four results are known legitimate applications. One is unrecognized. Enrichment separates the signal from the false positives without removing any data from the result set. Tom evaluates each record individually rather than filtering programmatically.

Query 5: Pivot. What has "DocuHelper Pro" done since l.chen granted consent?

AADServicePrincipalSignInLogs query results for "DocuHelper Pro":
SignInCount:     847
UniqueIPs:       3
IPAddresses:     ["104.223.x.x", "185.220.x.x", "103.152.x.x"]
FirstSeen:       2026-02-15T11:02:34Z  (38 minutes after consent)
LastSeen:        2026-03-30T04:17:22Z  (still active)
IP Geolocation:
  104.223.x.x  → US residential proxy (LUMINATI network)
  185.220.x.x  → Netherlands VPS provider
  103.152.x.x  → Singapore VPS provider
Sign-in pattern: continuous 24/7, avg 19.7 sign-ins/day
                 No weekday/weekend variation
                 Not human-driven

Query 5 transforms the investigation. A consent event alone is ambiguous. Users consent to legitimate applications every day. But 847 automated sign-ins from three proxy and VPS IP addresses, running continuously 24/7 with no human variation pattern, from an application with no verified publisher, using Mail.ReadWrite permissions on a marketing coordinator's account? That is not a productivity tool.

Step 4 — Analyze

Tom applies the five enrichment dimensions from Section 1.4 to "DocuHelper Pro."

User context. L.chen is a marketing coordinator. Her role involves external communications, content management, and campaign analytics. She has no legitimate reason to install a third-party application requesting Mail.ReadWrite and Files.ReadWrite.All that is not on NE's approved software list. Her manager confirms she did not request any new application access in February.

Temporal. The consent occurred on 2026-02-15 at 10:23 UTC. Tom checks EmailEvents and finds a message from an external sender delivered at 09:45 UTC on the same day containing a link described as a "document review portal." The 38-minute gap between delivery and consent is consistent with a social engineering attack where the user reads the email, clicks the link, reviews the application permission request, and clicks "Accept." The first service principal sign-in occurs at 11:02 UTC, 39 minutes after consent. Automation began immediately.

Geographic. L.chen's normal sign-in locations are London (office) and Reading (home). The application's sign-ins originate from three countries on residential proxy and VPS infrastructure, none matching l.chen's location pattern. The US IP resolves to a LUMINATI residential proxy network address, which is infrastructure commonly associated with credential abuse and account takeover operations.

Behavioral. The 847 sign-ins over 43 days show a continuous, automated access pattern with no weekday/weekend variation. Legitimate productivity applications show usage correlated with the user's working hours. An application signing in 19.7 times per day on a 24/7 schedule is reading email and files programmatically.

Infrastructure. The application has no verified publisher in Microsoft's app gallery. The application ID does not appear in any known software inventory. Tom queries MicrosoftGraphActivityLogs (if available) or checks the application registration in Entra to examine what API calls the application has made. If the application's Graph API calls target mail folders, message content, or file downloads, the data exfiltration path is confirmed.

Step 5 — Conclude

Outcome: Confirmed. "DocuHelper Pro" is a malicious application that has been reading l.chen's email and accessing her OneDrive files for 43 days via consented Mail.ReadWrite and Files.ReadWrite.All permissions, following a consent phishing attack delivered via email.

Tom prepares the warm handoff escalation package from Section 1.5. The finding is active. The application is still signing in and accessing data. This requires immediate containment, not a scheduled handoff.

Escalation package contents. The compromise summary: l.chen's account compromised via OAuth consent phishing, 43-day dwell time, active data access. Evidence inventory: consent event timestamp (AuditLogs), phishing email (EmailEvents), 847 service principal sign-ins (AADServicePrincipalSignInLogs), IP geolocation to proxy infrastructure. Recommended containment: revoke application consent via Entra Admin Center or PowerShell (Remove-MgServicePrincipal), revoke l.chen's active sessions, reset password, review all email received and sent during the 43-day window for signs of BEC activity or data exfiltration, check for mail forwarding rules or delegated access grants created after the consent date.

What the hunt found that no detection rule could. Before this hunt, NE had zero visibility into OAuth consent abuse. The application would have continued accessing l.chen's mailbox indefinitely because consent-based access does not expire, does not require re-authentication, and survives password resets. The only events that would have surfaced this compromise were the consent event itself, buried in 347 other consent events, and the service principal sign-ins, which do not trigger standard identity alerts. Without proactive hunting, this compromise would have persisted until the attacker achieved their objective or until a separate, unrelated investigation happened to discover it.

Step 6 — Convert

Five queries work. Now those queries become permanent detection rules, following the conversion workflow from Section 1.6.

Tom creates two rules from this hunt, because the investigation revealed two distinct detection gaps.

Rule 1: Illicit OAuth consent from non-admin users. The Q2 indicator query (high-privilege consent events), with exclusions for the three known legitimate applications identified during Q4 enrichment, becomes a scheduled analytics rule. Frequency: every 4 hours with a 6-hour lookback. The known-app allowlist (Grammarly, Adobe Acrobat, Zoom) is maintained in a Sentinel watchlist rather than hardcoded in the query, so new legitimate applications can be added without modifying the rule. Entity mapping: Account (ConsentedBy), Application (AppName). Severity: Medium. A single consent event is an indicator, not a confirmed compromise. The SOC analyst who triages this alert runs the Q5 pivot query against AADServicePrincipalSignInLogs to determine whether the application's post-consent behavior is malicious.

Rule 2: Device code flow authentication from unmanaged devices. Although this specific hunt found the compromise through the consent path rather than the device code path, Tom also builds a detection rule for the device code flow gap that the hypothesis identified. The query filters SigninLogs for AuthenticationProtocol == "deviceCode" where the device is unmanaged (empty DeviceDetail.deviceId) and the user is not on the known IoT/conference room service account list. Frequency: every hour with a 2-hour lookback. Severity: Medium. This rule closes the second detection gap identified in the hypothesis.

Both rules deploy in report-only mode for 14 days. Tom reviews the alert output daily during the first week, adds any legitimate applications or service accounts to the respective allowlists, and promotes both rules to production after the tuning period confirms acceptable false positive rates.

The complete hunt record

The hunt documentation standard from Section 1.7 produces the artifact that captures the entire investigation. Tom writes the record before closing the hunt.

What one hunt produced

Four hours of analyst time. One compromise identified and contained. Forty-three days of undetected mailbox access terminated. Two permanent detection rules deployed. The consent phishing technique and the device code flow technique both move from unmonitored to automated detection in a single campaign.

This is the compounding return on hunting investment. Each hunt that discovers a technique creates a permanent detection capability. The next time an attacker attempts consent phishing or device code abuse against NE, a scheduled rule fires automatically. No analyst needs to hunt for it again. The technique is closed.

Compound returns accelerate as the program matures. A team running biweekly hunts produces roughly 24 campaigns per year. If half confirm a finding and produce a detection rule, the organization adds 12 new detection capabilities annually. After two years, 24 techniques that were invisible are now automated. The detection library grows from the team's own environment, tuned to the organization's data, built from real findings rather than theoretical threat models.