A malicious application has consent in the tenant

The cloud persistence that outlives every response most teams run. A consent grant is not a session and not a credential, so revoking sessions, resetting the password and re-enrolling MFA all leave it untouched.

Trigger. An unrecognised enterprise application, a consent grant nobody remembers approving, or mail access that survived a password reset.

The first 70 minutes1 of 5 expire

01 02 03 04 05

035 min70

01
Export the grant before removing it
by 10 minexpires
Record the application id, the delegated and application permissions it holds, who consented, when, and every sign-in attributed to the service principal. This is the scope answer; it does not exist once the object is gone.
02
Revoke the grant, then the refresh tokens it issued
by 25 min
In that order, and both. Removing the consent stops new tokens; it does not invalidate tokens already issued, which remain valid for their lifetime. Revoking the user sign-in sessions is a separate action from removing the application.

Tell somebody

Legal and privacy, if mail or file permissions were held: this is access to content, not just to an account
The identity team, on whether user consent should remain enabled
Anyone whose mailbox the application could read, which is usually more people than consented

Drawn from

The documents these steps come from, so you can check one rather than take it on trust.

The evidence

What each source proves, and what it does not.

logon events

Collect it in one go

A read-only script that gathers most of the above in volatility order, with a hash manifest.

Triage collection

Make it yours

Replace the escalation list with real names, and the timings with what your change process actually allows. A playbook that assumes an authority you do not have will stall at the step that needed it.

Export the grant before removing it

Revoke the grant, then the refresh tokens it issued