Entra ID Service Principal Federated Credential Authentication by Unusual Client
Description
Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate.
Query · kuery
data_stream.dataset: "azure.signinlogs"
and azure.signinlogs.category: "ServicePrincipalSignInLogs"
and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential"
and azure.signinlogs.result_signature: "SUCCESS"
and azure.signinlogs.properties.app_id: *
and not azure.signinlogs.properties.app_owner_tenant_id: (
"f8cdef31-a31e-4b4a-93e4-5f571e91255a" or
"72f988bf-86f1-41af-91ab-2d7cd011db47"
)
Investigation fields
Pivot points the source recommends for triage.
azure.signinlogs.properties.service_principal_nameazure.signinlogs.properties.service_principal_idazure.signinlogs.properties.app_idazure.signinlogs.properties.app_display_nameazure.signinlogs.properties.app_owner_tenant_idazure.signinlogs.properties.client_credential_typeazure.signinlogs.properties.service_principal_credential_thumbprintazure.signinlogs.caller_ip_addressazure.signinlogs.properties.resource_display_nameazure.signinlogs.properties.unique_token_identifierazure.correlation_idazure.signinlogs.properties.session_idsource.geo.country_namesource.geo.city_name
Implementation guide
To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
Known false positives
- New CI/CD pipeline deployments using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule when federated authentication is first used. Validate the issuer URL against approved identity providers.
- Application migrations or reconfigurations that switch from certificate/secret authentication to federated credentials will appear as new behavior. Confirm with application owners.
- New workload identity federation configurations for legitimate automation will trigger on first use.
Analyst notes
Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client
If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the compromised application for the first time.
Possible investigation steps
- Identify the service principal using
azure.signinlogs.properties.app_idandapp_display_name. - Critical: Check the application's federated credential configuration in Entra ID:
- What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)?
- When was the federated credential added? Was it recent?
- Who added the federated credential?
- Review the
service_principal_credential_thumbprint- does it match expected certificates? - Investigate the source IP (
azure.signinlogs.caller_ip_address) - is it from expected CI/CD infrastructure? - Check what resources were accessed after authentication using
azure.signinlogs.properties.resource_display_name. - Correlate with Graph Activity logs to see what API calls were made with this token.
- Use the
correlation_idto find related sign-in and activity events. - Review audit logs for recent changes to this application's federated credentials.
False positive analysis
- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use.
- New application deployments with workload identity federation are expected to show as new behavior.
- Validate the issuer URL against approved identity providers before dismissing.
- Create baseline of applications expected to use federated credentials.
Response and remediation
- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration.
- Review the external IdP issuer URL configured on the application - is it legitimate?
- If BYOIDP is confirmed:
- Remove the malicious federated credential immediately.
- Revoke active sessions and tokens for the affected service principal.
- Audit what actions were performed using the compromised identity.
- Investigate how the federated credential was added (compromised admin account).