Leaked credentials for Workload identities
Azure AD Identity Protection [user identities]
Compromised credentials (e.g. via phishing mail(s) or website compromise via hacking like SQL injection, see example below) that are available publicly (e.g. on the dark web or other public resources) are gathered and verified by Microsoft against the actual Azure AD credentials.
If the username and the password hash is a match (requires Azure AD Connect password hash sync), an High risk alert is raised in Azure AD Identity Protection called Leaked Credentials.
If the User risk policy is configured: All users with user risk High and the access control Require password change.
The user is forced to change the password (and to verify their identity via multi factor authentication). The alert is automatically closed since the password hash changed for the Azure AD user which was compromised.
The current scope of leaked credentials is (was) User credentials.
Azure AD Identity Protection [workload identities]
Workload identities is the category of:
- App Registrations (Applications)
- Enterprise Applications (Service Principals)
- Managed Identities
An App Registration is an application object (definition of the application) in the source Azure AD. Enterprise application is an instances of application in the (source and/or target) Azure AD.
A new feature / detection is leaked credentials for workload identities which gathers information from the dark web, paste (bin) sites and public GitHub (current preview) repositories.
If an object (Application) ID & Secret is found, an alert is raised.
Disclaimer: Microsoft triggered a backfill for the ‘old’ data (a procedure only required once) and all new (delta) detections are triggered upon Commit (detection can take some time, often within 24 hours from my own experience).
Example
Let’s create an App registration where we use the following information
- Application ID
- Tenant ID
- Secret
And let’s create a public Github repo with our Azure credentials like the Application ID (unique identifier) and App Secret (password).
Detection
If workload identity credentials are detected, the alert is presented in the following two sections:
Risky workload identities
The risky workload identities section provides an overview of all detected risks from the category workload identities.
Risk detections -> Workload identity detections
The risk detections sections provides an overview of all User detections and Workload identities detections.
The workload identities (offline) detections types are:
- Azure AD Threat Intelligence
- Leaked credentials
- Suspicious sign-ins
- Unusual addition of credentials to an OAuth app
See Holistic compromised identity signals from Microsoft — Microsoft Tech Community for more information on the other detections.
By selecting the leaked credentials alert, the details are presented
By selecting ‘Click here for more details’ the (public) location of the discovered credentials are shown.
Graph API
The riskyServicePrincipals detection can also be used via the Graph API Explorer (use the beta endpoint at the time of writing and an account with required IdentityRiskyServicePrincipal.Read.All permissions).
Conditional Access Policy for workload identities
Previously, Azure AD Identity Protection only supported user policies (user risk & sign-in risk). Now, with Azure AD Conditional Access a policy can be created to block access for single-tenant service principals with a high-risk state.
This will automatically prevent access if the service principal is compromised.
Leaked credentials is one of my favorite detections on users, which is now extended to workload identities (service principals)to provide more coverage and a safer world at the end.
