All risky workload identity sign ins are triaged

Overview

Threat actors increasingly target workload identities (applications, service principals, and managed identities) because they lack human factors and often use long-lived credentials. A compromise often looks like the following path:

1. Credential abuse or key theft.
2. Non-interactive sign-ins to cloud resources.
3. Lateral movement via app permissions.
4. Persistence through new secrets or role assignments.

Microsoft Entra ID Protection continuously generates risky workload identity detections and flags sign-in events with risk state and detail. Risky workload identity sign-ins that aren’t triaged (confirmed compromised, dismissed, or marked safe), detection fatigue, and a large alert backlog can be challenging for IT admins to manage. This heavy workload can let repeated malicious access, privilege escalation, and token replay to continue to go unnoticed. To make the workload manageable, address risky workload identity sign-ins in two parts:

• Close the loop: Triage sign-ins and record an authoritative decision on each risky event.
• Drive containment: Disable the service principal, rotate credentials, or revoke sessions.

Remediation

• Investigate risky workload identities and perform appropriate remediation
• Dismiss workload identity risks when determined to be false positives
• Confirm compromised workload identities when risks are validated

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	High
Impact on users	Low
Pillar	Identity
Category	Access control
Product	Entra ID
Feature	Identity Protection
Area	Applications and workload identities
ATT&CK	T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials
Licence	P2
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.