15.5 Revocation and Cleanup

Revocation and Cleanup

Required role: Application Administrator or Cloud Application Administrator.

Action 1: Remove the malicious application from the tenant

Option A: Delete the enterprise application (affects all users).

Navigate to Entra ID → Enterprise Applications → search for the application by name or AppId → Properties → Delete.

Blast radius: All consents to this application are revoked for all users. The application can no longer access any data in the tenant. If any legitimate user was using this application for a legitimate purpose: they lose access. Tenant-wide for this application.

Rollback: The application can be restored from soft-delete within 30 days (Entra ID → Deleted applications).

Option B: Remove individual user consents (if some consents are legitimate).

Navigate to Entra ID → Enterprise Applications → [App] → Users and groups → remove the specific users who were phished.

Blast radius: Only the removed users’ consents are revoked. Other users retain their consent. Per-user for this application.

For this incident: use Option A. “Microsoft Security Update Tool” is entirely malicious — no legitimate users should have consented. Delete the enterprise application.

Action 2: Verify removal

1
2
3
4
5

// Verify: no further sign-ins from the malicious application
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(2h)
| where AppId == "MALICIOUS-APP-ID"
| project TimeGenerated, IPAddress, ResourceDisplayName, ResultType

Expected: Zero rows, or rows with ResultType indicating failure (the application’s tokens are invalidated after enterprise application deletion).

1
2
3
4
5
6
7
8

// Verify: the consent grant no longer exists
AuditLogs
| where TimeGenerated > ago(2h)
| where OperationName has "Remove app role assignment"
    or OperationName has "Remove delegated permission grant"
    or OperationName has "Remove service principal"
| where TargetResources[0].displayName == "Microsoft Security Update Tool"
| project TimeGenerated, OperationName

Action 3: Block the application proactively

Prevent the application from being re-consented if the phishing campaign is still active:

1
2
3

// PowerShell — block the application by AppId
// New-AzureADServicePrincipal -AppId "MALICIOUS-APP-ID" -AccountEnabled $false
// Or use Entra ID → Enterprise Applications → [App] → Properties → Enabled for users to sign-in → No

Blast radius: The application cannot be consented by any user in the tenant. No impact on other applications. Per-application.

Action 4: Notify affected users

Send a communication (via a channel other than email if mailbox integrity is uncertain) to the 12 affected users: “Your account was targeted by a consent phishing attack. A malicious application was granted access to your email and files. The application has been removed. As a precaution: review your recent email for any suspicious activity, check your sent folder for emails you did not send, and report any unusual activity to IT immediately.”

Compliance mapping: NIST CSF RS.CO-2 (Information shared with stakeholders). ISO 27001 A.5.26 (Response to incidents).

Subsection artifact: The revocation procedure with verification queries. This is the revocation section of your OAuth investigation playbook.

Knowledge check

Post-revocation monitoring

After deleting the enterprise application, monitor for:

Re-consent attempts. If the phishing campaign is still active, additional users may click the consent link. The consent will fail (the application is deleted), but the attempt is logged:

1
2
3
4
5
6
7
8

// Monitor for consent attempts to the deleted application
AuditLogs
| where TimeGenerated > ago(48h)
| where OperationName == "Consent to application"
| where Result == "failure"
| where tostring(TargetResources[0].id) == "MALICIOUS-APP-ID"
| extend AttemptUser = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, AttemptUser

Each failed consent attempt identifies a user who clicked the phishing link — they were targeted and should receive awareness communication, even though the consent failed.

Application re-registration. A sophisticated attacker may register a new application with a different AppId but similar name and permissions. Monitor:

1
2
3
4
5
6
7
8

// New application registrations in the last 48 hours
AuditLogs
| where TimeGenerated > ago(48h)
| where OperationName == "Add application"
| extend AppName = tostring(TargetResources[0].displayName)
| where AppName has_any ("security", "update", "microsoft", "office", "document")
| project TimeGenerated, AppName,
    RegisteredBy = tostring(InitiatedBy.user.userPrincipalName)

New applications with names similar to the deleted malicious application warrant immediate investigation. If registered from an external tenant: block the new AppId proactively.