This walkthrough is a fictionalised composite based on documented consent-phishing techniques and official response guidance. It is not a client incident, and the sample timeline and evidence are representative rather than actual records.

TL;DR

A user can complete MFA and still approve a malicious application. In a consent-phishing attack, the application receives delegated permissions that may allow it to access Microsoft 365 data as the user. The response therefore has to investigate the application and its grants—not only reset a password.

The core evidence chain is:

application → publisher and identifiers → delegated permissions → consent record → affected users → accessed data → revocation → verification

The scenario: a familiar prompt, the wrong application

Meridian Partners is a fictional 120-person Australian professional-services firm using Microsoft 365 and Microsoft Entra ID.

A finance employee receives a link presented as a document-review request. The link opens a Microsoft consent experience for an application named “SharePoint Sync Manager.” The user signs in, completes the required authentication, and approves delegated access requested by the application.

The presence of a legitimate Microsoft sign-in or consent page does not establish that the application is trustworthy. MFA helps protect the authentication event; it does not decide whether the requested application permissions are appropriate.

Representative timeline

  • Day 0: The user approves the application and its delegated permissions.
  • Days 1–5: The application uses its grant to access mailbox data permitted by the approved scopes.
  • Day 6: A payment thread is used to prepare a fraudulent change-of-bank-details message.
  • Day 7: The customer independently verifies the change by phone, and the finance team escalates the event before processing the payment.

The avoided transfer is fictional. The useful question is what evidence the response team would need if the same permission path appeared in a real tenant.

Stage 1: detect and preserve the signal

The first signal is the customer’s verification call. The incident lead preserves the message and records the reported payment change, sender details, timestamps, recipients, and affected business process.

The technical investigation starts with several evidence sources. Availability and retention depend on tenant configuration and licensing.

Review the enterprise application, service principal, publisher information, application identifiers, requested permissions, consent type, consenting identity, and consent timestamp. Determine whether the grant is delegated to particular users or applies more broadly.

Do not assume that deleting a phishing email removes the application’s access. Existing grants have to be identified and revoked separately.

Entra sign-in and audit data

Review available sign-in and audit records for the application, affected users, service principal, consent activity, permission changes, and relevant administrative actions. Preserve the original exports and document the query boundaries used.

A foreign or hosting-provider IP may increase concern, but location alone is not proof of compromise. Compare the activity with the organisation’s normal users, devices, applications, and operating locations.

Microsoft 365 audit and mailbox evidence

Where available, review mailbox audit events, message trace, inbox rules, forwarding settings, delegates, sent items, deleted items, and access to relevant messages or attachments. Record what the available logs can and cannot establish.

The evidence may show that an application had permission to read mail without proving that every message was accessed. Keep permission, observed activity, and inferred impact as separate findings.

Stage 2: scope the grant and business impact

The response team asks five questions.

  1. What is the application? Record its name, application ID, service-principal object ID, publisher status, owners, credentials, and tenant presence.
  2. What was granted? Record the delegated or application permissions, who consented, and whether consent was user-specific or tenant-wide.
  3. Who and what are affected? Identify consenting users, shared mailboxes, delegated access, connected services, and data reachable through the granted scopes.
  4. What activity occurred? Separate confirmed audit events from possible activity allowed by the permissions.
  5. What business process is exposed? Identify payment, customer, legal, privacy, contractual, and reporting decisions that depend on the affected information.

The organisation may classify the event as high priority because it involves active mailbox access and an attempted payment diversion. That severity label belongs to the organisation’s own incident framework; it should not be attributed to a universal ACSC “P1” scale.

Containment should preserve evidence while closing the specific access route.

  • Disable or remove the malicious enterprise application when appropriate.
  • Revoke the relevant delegated or application permission grants.
  • Revoke affected user sessions and refresh tokens when account or session compromise is suspected.
  • Block sign-in and reset credentials when evidence supports identity compromise; a password reset alone does not revoke an application grant.
  • Remove malicious forwarding, inbox rules, delegates, or persistence discovered during the investigation.
  • Restrict future user consent and route appropriate requests through an admin-consent workflow.
  • Preserve application, identity, audit, mailbox, and message evidence with collection times and reviewer notes.

Changing user-consent settings affects future requests. The response still has to find and remove existing illicit grants.

If money was transferred or payment details were changed, ACSC guidance advises contacting the financial institution immediately and reporting the incident through ReportCyber. Recovery is time-sensitive and is not guaranteed.

Stage 4: eradicate and recover

Over the next review cycle, the team:

  • searches for other suspicious applications, grants, credentials, and consenting users
  • confirms whether the application or actor accessed additional mailboxes or services
  • reviews application owners, publisher information, permission need, and consent scope
  • verifies that revoked grants no longer provide the tested access path
  • validates mailbox rules, forwarding, delegates, and payment-authorisation records
  • updates affected customers and other stakeholders according to legal, contractual, insurance, and incident-response advice
  • records assumptions, unresolved questions, and remediation owners

Credential rotation should be scoped to evidence. Rotating every service credential in a tenant can create disruption without closing the actual consent grant; failing to rotate a credential shown to be exposed leaves a known path open.

Stage 5: examine the control failure

The fictional review identifies three connected gaps.

The tenant allowed users to approve permissions that the organisation had not classified as acceptable. Microsoft recommends controlling user consent, including limiting it to verified publishers and selected permissions where that model fits the organisation.

2. Existing grants were not routinely reviewed

The organisation had no repeatable inventory of enterprise applications, permissions, consent type, owners, use, exceptions, and review decisions. A setting change would reduce future exposure but would not reveal every existing grant.

3. The incident playbook focused on passwords

The initial checklist covered password resets, MFA re-registration, and inbox rules. It did not require responders to identify the service principal, enumerate consent grants, revoke application permissions, and verify loss of access.

Where Conditional Access fits—and where it does not

Conditional Access can reduce identity and token risk through policies based on users, applications, devices, locations, authentication strength, sign-in risk, and supported session controls. Continuous access evaluation can shorten the time between certain critical events or policy changes and enforcement for supported services.

Those controls do not replace application-consent governance. A tenant still needs to decide who may grant which permissions, review existing grants, investigate suspicious applications, and revoke illicit consent.

Avoid promising that one Conditional Access policy “blocks OAuth attacks.” The result depends on the resource, client, grant flow, token, application support, policy scope, licensing, and attacker path.

Three evidence-led controls

Define which users may consent, which permissions are considered low risk, whether verified publishers are required, and when an admin-consent workflow applies. Record exceptions and review existing grants separately.

2. Maintain an application-grant register

For material applications, retain the application identifiers, publisher, owners, permission scopes, consent type, affected users, business purpose, last activity, reviewer, exceptions, and next review date. Use available audit and security tooling to surface new or changed grants.

Test whether the team can identify a suspicious application, preserve evidence, scope users and data, revoke the correct grants, invalidate relevant sessions, verify containment, and coordinate payment-fraud or notification decisions.

The exercise should record what the available logs proved, what they could not prove, and which licensing or retention gaps affected the conclusion.

FAQ

Not necessarily. The useful starting point is the identity, application, consent, audit, mailbox, and business-process evidence already available to the organisation. Microsoft security products can add detection and investigation capabilities, but feature availability, retention, and licensing vary. Verify the tenant rather than relying on a generic product claim.

Start with three checks:

  1. Review the tenant’s user-consent settings and admin-consent workflow.
  2. Inventory existing enterprise applications and permission grants, prioritising high-impact permissions and unclear ownership.
  3. Test whether the incident playbook explicitly revokes application grants and verifies containment.

No general answer is reliable. Coverage depends on the policy wording, event, controls, notifications, exclusions, and evidence. Contact the broker or insurer and obtain legal advice for the organisation’s circumstances.

The payoff

The important lesson is not that every unfamiliar OAuth application is malicious or that MFA has failed. It is that authentication, consent, permission, token, and data-access evidence answer different questions.

A credible response can state:

  • what application and grant existed
  • who approved it and what it allowed
  • what activity the records confirmed
  • what remained uncertain
  • which access paths were revoked
  • how containment was verified
  • what changed to reduce recurrence

That is stronger than either “MFA was enabled” or “we deleted the app.”

If you want an Australia-first review of Microsoft 365 consent settings, existing application grants, and incident-response evidence, book an Aiden assurance consultation.

References