Huntress is working alongside other security researchers to investigate suspicious Microsoft Entra ID sign-ins in which a threat actor uses valid, pre-existing application credentials to authenticate as a service principal and request access tokens for cloud resources.

In This Article

Overview
Are You Affected?
What Huntress Is Doing
Recommended Next Steps
How to Get Help

Overview

Huntress, working with other security researchers, is investigating malicious sign-ins targeting Microsoft Entra ID across multiple organizations and managed service providers.

In this activity, a threat actor uses valid, pre-existing application credentials, such as a client secret, to sign in directly as a service principal. A service principal is an application identity rather than a user identity. After authentication, the threat actor can request access tokens for cloud resources.

Huntress has notified directly affected partners, disabled impacted applications where possible, and continues to monitor and investigate the activity.

Are You Affected?

Review your Microsoft Entra environment for the following indicators:

• Review service principal sign-in logs for sign-ins from unfamiliar IP addresses or hosting providers.

• Look for non-interactive, application-only sign-ins that your workflows would not normally generate.

• Check whether registered applications obtained unexpected tokens for Azure Resource Manager, Azure Key Vault, or Microsoft Graph.

• Inventory your app registrations for client secrets or certificates that you didn't create.

Treat unexpected activity as potentially unauthorized until you complete your review. If you identify suspicious activity, follow the containment steps in Recommended Next Steps.

What Huntress Is Doing

Huntress is:

• Investigating this activity with other security researchers and sharing intelligence.

• Notifying partners when affected applications are identified in their tenants.

• Disabling impacted applications where Huntress can do so.

• Continuing to monitor for related activity and update guidance as the investigation develops.

Recommended Next Steps

1. Contain the affected application. Disable the affected application and remove all secrets and certificates from its registration. Review the registration for federated credentials or other credentials you didn't create. Issue new credentials only after you confirm that the application is legitimate and its configuration is secure.

2. Review activity and access logs. Review Azure Activity Logs and Key Vault logs for the relevant application to determine what, if anything, was accessed. Preserve relevant evidence in accordance with your incident response plan.

3. Rotate related credentials. Rotate credentials stored in the same code, configuration, or repositories as the exposed secret. Also review any downstream credentials that the affected application could access.

4. Apply workload-identity protections. Apply Conditional Access policies that cover workload identities where your licensing allows. User-scoped Conditional Access policies may not cover sign-ins by service principals.

5. Engage your incident response plan. If you confirm unexpected access, follow your incident response process and assess whether notification, legal, or privacy review is required.

How to Get Help

For more in-depth technical details and indicators, review Todyl's public article on this campaign.

If you have questions or believe you are affected, contact Huntress Support. Huntress is here to help.