15.2 Incident Briefing: INC-2026-0325-004

Incident Briefing: INC-2026-0325-004

The alert

At 10:15 UTC on 25 March 2026, a Defender for Cloud Apps alert fires: Unusual OAuth application consent — high-risk permissions granted by multiple users. 12 Northgate Engineering users consented to an application called “Microsoft Security Update Tool” within a 4-hour window. The application requested: Mail.ReadWrite, Files.ReadWrite.All, and Contacts.Read.

What you know at this point

The application name “Microsoft Security Update Tool” is designed to look like a legitimate Microsoft application. It is not — Microsoft does not distribute security tools via OAuth consent prompts.

12 users consented between 06:00 and 10:00 UTC. The consent events originated from a phishing email sent at 05:45 containing a link that triggered the OAuth consent prompt. The email subject: “Mandatory Security Update Required — Action Needed Today.”

The application is registered in an external tenant (not Northgate’s tenant). The publisher is unverified. The application’s AppId does not appear in Microsoft’s known first-party application list.

What you do NOT know: Whether the application has already accessed the users’ data. How much data has been exfiltrated. Whether additional applications were consented.

Investigation priority: Determine what permissions were granted, whether the application has used those permissions to access data, and revoke the consent before more data is exfiltrated. Unlike BEC (where financial recovery drives urgency), consent phishing urgency is driven by data exposure — every hour the application retains access is an hour of data exfiltration.

Analysing the phishing email

Before investigating the OAuth consent itself, trace how users were directed to the consent prompt:

1
2
3
4
5
6
7
8

// Find the phishing email that triggered the consent campaign
EmailEvents
| where TimeGenerated between(datetime(2026-03-25T04:00:00Z) .. datetime(2026-03-25T11:00:00Z))
| where Subject has "Security Update" or Subject has "Mandatory"
| project TimeGenerated, SenderFromAddress, SenderMailFromAddress,
    RecipientEmailAddress, Subject, DeliveryAction,
    AuthenticationDetails, NetworkMessageId
| order by TimeGenerated asc

What to examine: The phishing email directs users to a URL that triggers the Microsoft consent prompt. The URL format is: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=[MALICIOUS-APP-ID]&scope=Mail.ReadWrite+Files.ReadWrite.All+Contacts.Read&response_type=code&redirect_uri=[ATTACKER-URL]. The consent prompt is a real Microsoft page — the user sees the Microsoft logo and the permission list. This is why consent phishing is effective: the user is interacting with a legitimate Microsoft authentication flow, not a fake login page.

Extract the URL from the email:

1
2
3
4
5
6
7

EmailUrlInfo
| where TimeGenerated between(datetime(2026-03-25T04:00:00Z) .. datetime(2026-03-25T11:00:00Z))
| where NetworkMessageId in (
    EmailEvents | where Subject has "Security Update" | project NetworkMessageId
)
| where Url has "oauth2" or Url has "authorize"
| project Url, UrlDomain

From the URL, extract: The client_id parameter (the malicious application’s AppId — use this throughout the investigation), the scope parameter (the permissions requested), and the redirect_uri (where the authorisation code is sent — the attacker’s infrastructure).

Initial scoping

Determine the full scope before deep-diving:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// How many users consented? Were there other applications?
AuditLogs
| where TimeGenerated between(datetime(2026-03-25T04:00:00Z) .. datetime(2026-03-25T12:00:00Z))
| where OperationName == "Consent to application"
| where Result == "success"
| extend AppName = tostring(TargetResources[0].displayName)
| extend ConsentUser = tostring(InitiatedBy.user.userPrincipalName)
| summarize UserCount = dcount(ConsentUser),
    Users = make_set(ConsentUser, 20)
    by AppName
| order by UserCount desc

If this returns multiple application names: the attacker registered multiple malicious applications — possibly with different permission sets targeting different user groups. Each application must be investigated and revoked separately.

Knowledge check

Assessing the phishing campaign delivery

Before investigating the application, determine how users were directed to the consent prompt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Find the phishing email that delivered the consent link
EmailEvents
| where TimeGenerated between(datetime(2026-03-25T04:00:00Z) .. datetime(2026-03-25T12:00:00Z))
| where RecipientEmailAddress in (
    AuditLogs
    | where OperationName == "Consent to application"
    | where tostring(TargetResources[0].displayName) == "Microsoft Security Update Tool"
    | extend ConsentUser = tostring(InitiatedBy.user.userPrincipalName)
    | distinct ConsentUser
)
| where Subject has_any ("security", "update", "mandatory", "action required")
| project TimeGenerated, SenderFromAddress, RecipientEmailAddress,
    Subject, DeliveryAction, DeliveryLocation
| order by TimeGenerated asc

What to examine: The sender domain (is it spoofed or a lookalike?), the subject line (urgency language typical of consent phishing), and the delivery verdict (did email protection flag it?). Cross-reference: did the same sender email non-consenting users? Those users received the phishing email but did not click — they may report it, providing additional investigation evidence.

Phishing email characteristics for consent phishing: Unlike credential phishing (which directs to a fake login page), consent phishing directs to a real Microsoft consent prompt. The URL in the email points to login.microsoftonline.com/common/oauth2/v2.0/authorize?... — a legitimate Microsoft URL. This is why URL-based detection is ineffective: the URL is genuine. The malicious element is the application the URL requests consent for, not the URL itself.