Inactive applications don’t have highly privileged built-in roles

Overview

Attackers might exploit valid but inactive applications that still have elevated privileges. These applications can be used to gain initial access without raising alarm because they’re legitimate applications. From there, attackers can use the application privileges to plan or execute other attacks. Attackers might also maintain access by manipulating the inactive application, such as by adding credentials. This persistence ensures that even if their primary access method is detected, they can regain access later.

Remediation

• Disable inactive privileged service principals
• Investigate if the application has legitimate use cases. If so, analyze if a OAuth2 permission is a better fit
• If service principal doesn’t have legitimate use cases, delete it

Run it

The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:

Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn

Leave out -SkipBuiltIn to run Maester’s own checks in the same run.

About this check

Severity	High
Effort to fix	Low
Impact on users	Low
Pillar	Identity
Category	Application management
Product	Entra ID
Feature	Roles and administrators
Area	Privileged access
ATT&CK	T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials
Licence	P1
Tenant	Workforce, External

Product, feature, area and ATT&CK are Maester’s: the assessment does not record them, so Maester keeps them in the pack’s taxonomy.json.

A Microsoft check, part of the Zero Trust Assessment pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, MIT licence.