OAuth2 app security is the new battleground for Microsoft 365 admins. While some MVPs and ISVs warn of an apocalyptic wave of malware apps, the reality is that often the biggest risk is not malicious intent, but simple administrative disinterest. You don't need expensive third-party tools to stay in control, but a deep understanding of what "lives" in your tenant is essential.
The Anatomy of Risk: Permissions & Service Principals
The core problem lies in the lack of transparency of Entra ID. It lacks a native inventory that prominently highlights critical permissions such as Mail.Read, Files.Read.All , or Sites.Manage.All prominently. These permissions are the crown jewels for attackers to exfiltrate data unnoticed – as the "Midnight Blizzard" attack in March 2024 painfully demonstrated.
Each multi-tenant app that integrates with your tenant creates a Service Principal. This acts as the local representation of the app and defines what the app is allowed to do in your area. The risk: Once approved, access remains until it is explicitly revoked.
Hunting for "Traitorware" and Shadow IT
Studies by Huntress Labs (Matt Kiely) show that about 10% of all tenants host so-called "traitorware" apps. These are apps that appear legitimate but collect far-reaching permissions in the background. A simple PowerShell script based on the Microsoft Graph SDK can serve as a highly efficient "hunter" here.
Your script should specifically look for the following patterns:
- Naming: Apps with "test", "demo" or pure special characters in the name.
- User Reference: Apps named after users (often a sign of manual, insecure registrations).
- Suspicious Reply URLs: Redirect URLs that indicate known phishing campaigns (such as ProofPoint MACT 1445).
- Credentials: Expired or overly valid client secrets and certificates.
Analysis Script: Identify Service Principals
To determine the origin of an app, the cmdlet Find-MgTenantRelationshipTenantInformationByTenantId. This will resolve the cryptic AppOwnerTenantId into a readable name.
# Abrufen aller Service Principals inkl. SignIn-Aktivität
$ServicePrincipals = Get-MgServicePrincipal -All -Property "displayName", "appId", "signInAudience", "appOwnerTenantId", "signInActivity"
foreach ($sp in $ServicePrincipals) {
# Besitzer-Tenant auflösen
$OwnerInfo = Find-MgTenantRelationshipTenantInformationByTenantId -TenantId $sp.AppOwnerTenantId
# Ausgabe der Identität
[PSCustomObject]@{
DisplayName = $sp.DisplayName
Owner = $OwnerInfo.DisplayName
LastSignIn = $sp.SignInActivity.LastSuccessfulSignInDateTime
IsVerified = $sp.VerifiedPublisher.DisplayName -ne $null
}
}Find inactive apps
Many Service Principals are "corpses" from old test phases or relocated Microsoft services (e.g., old Secure Score apps). There are two ways to identify inactive apps:
- Entra ID Sign-in Logs: Offers 30 days of history, but requires Entra P1 licenses and is computationally intensive.
- servicePrincipalSignInActivity object: This graph object directly provides the timestamp of the last successful login. This is the fastest way to find apps that haven't been active in months.
Governance Strategy: Document and Mark
A technical scan is only half the battle. You have to secure the knowledge in the team. Microsoft offers the possibility to attach administrative notes to service principals.
Use these fields consistently to record:
- Who requested the app?
- What business purpose does it serve?
- When was the last review carried out?
Conclusion and safety rating
Managing OAuth2 applications is not a one-time task, but an ongoing process. The biggest risk is not the technically sophisticated malware, but the creeping accumulation of permissions ("permission creep") and the forgetting of apps that were once created for legitimate purposes.
The identification of apps from other tenants such as PRDTRS01 or trustportal shows that even Microsoft does not always clean up cleanly. Here you have to take over the "city cleaning" as an administrator. A monthly automated report, ideally as an Azure Automation Runbook, that sends you a CSV list of all apps with Mail.Read or AppRoleAssignment.ReadWrite.All their last login, is more effective than any expensive security dashboard.
Protections such as RBAC for Applications for mailbox access should be standard. Treat app identities with the same strictness as privileged user accounts. This is the only way to prevent a forgotten "test" app from becoming a gateway for the next big exfiltration attack.
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.