Entra ID Service Principal Federated Credential Authentication by Unusual Client

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/02/09"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/02/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when a service principal authenticates using a federated identity credential for the first time in the
 11historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity
 12provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries
 13may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time
 14federated credential usage for a service principal warrants investigation to determine if the external identity provider
 15is legitimate.
 16"""
 17false_positives = [
 18    """
 19    New CI/CD pipeline deployments using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule when
 20    federated authentication is first used. Validate the issuer URL against approved identity providers.
 21    """,
 22    """
 23    Application migrations or reconfigurations that switch from certificate/secret authentication to federated
 24    credentials will appear as new behavior. Confirm with application owners.
 25    """,
 26    """New workload identity federation configurations for legitimate automation will trigger on first use.
 27    """
 28]
 29from = "now-9m"
 30index = ["logs-azure.signinlogs-*"]
 31language = "kuery"
 32license = "Elastic License v2"
 33name = "Entra ID Service Principal Federated Credential Authentication by Unusual Client"
 34note = """## Triage and analysis
 35
 36### Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client
 37
 38If 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
 39compromised application for the first time.
 40
 41### Possible investigation steps
 42
 43- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`.
 44- Critical: Check the application's federated credential configuration in Entra ID:
 45  - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)?
 46  - When was the federated credential added? Was it recent?
 47  - Who added the federated credential?
 48- Review the `service_principal_credential_thumbprint` - does it match expected certificates?
 49- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure?
 50- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`.
 51- Correlate with Graph Activity logs to see what API calls were made with this token.
 52- Use the `correlation_id` to find related sign-in and activity events.
 53- Review audit logs for recent changes to this application's federated credentials.
 54
 55### False positive analysis
 56
 57- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use.
 58- New application deployments with workload identity federation are expected to show as new behavior.
 59- Validate the issuer URL against approved identity providers before dismissing.
 60- Create baseline of applications expected to use federated credentials.
 61
 62### Response and remediation
 63
 64- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration.
 65- Review the external IdP issuer URL configured on the application - is it legitimate?
 66- If BYOIDP is confirmed:
 67    - Remove the malicious federated credential immediately.
 68    - Revoke active sessions and tokens for the affected service principal.
 69    - Audit what actions were performed using the compromised identity.
 70    - Investigate how the federated credential was added (compromised admin account)."""
 71references = [
 72    "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/",
 73    "https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation",
 74    "https://github.com/dirkjanm/ROADtools",
 75]
 76risk_score = 47
 77rule_id = "616b8d00-05f8-11f1-8f33-f661ea17fbce"
 78setup = """#### Required Microsoft Entra ID Sign-In Logs
 79To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
 80"""
 81severity = "medium"
 82tags = [
 83    "Domain: Cloud",
 84    "Domain: Identity",
 85    "Data Source: Azure",
 86    "Data Source: Microsoft Entra ID",
 87    "Data Source: Microsoft Entra ID Sign-In Logs",
 88    "Use Case: Identity and Access Audit",
 89    "Tactic: Initial Access",
 90    "Tactic: Defense Evasion",
 91    "Tactic: Persistence",
 92    "Resources: Investigation Guide",
 93]
 94timestamp_override = "event.ingested"
 95type = "new_terms"
 96
 97query = '''
 98event.dataset: "azure.signinlogs"
 99    and azure.signinlogs.category: "ServicePrincipalSignInLogs"
100    and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential"
101    and azure.signinlogs.result_signature: "SUCCESS"
102    and azure.signinlogs.properties.app_id: *
103    and not azure.signinlogs.properties.app_owner_tenant_id: (
104        "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or
105        "72f988bf-86f1-41af-91ab-2d7cd011db47"
106    )
107'''
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1078"
113name = "Valid Accounts"
114reference = "https://attack.mitre.org/techniques/T1078/"
115[[rule.threat.technique.subtechnique]]
116id = "T1078.004"
117name = "Cloud Accounts"
118reference = "https://attack.mitre.org/techniques/T1078/004/"
119
120
121
122[rule.threat.tactic]
123id = "TA0001"
124name = "Initial Access"
125reference = "https://attack.mitre.org/tactics/TA0001/"
126
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129[[rule.threat.technique]]
130id = "T1550"
131name = "Use Alternate Authentication Material"
132reference = "https://attack.mitre.org/techniques/T1550/"
133[[rule.threat.technique.subtechnique]]
134id = "T1550.001"
135name = "Application Access Token"
136reference = "https://attack.mitre.org/techniques/T1550/001/"
137
138
139
140[rule.threat.tactic]
141id = "TA0005"
142name = "Defense Evasion"
143reference = "https://attack.mitre.org/tactics/TA0005/"
144
145[rule.investigation_fields]
146field_names = [
147    "azure.signinlogs.properties.service_principal_name",
148    "azure.signinlogs.properties.service_principal_id",
149    "azure.signinlogs.properties.app_id",
150    "azure.signinlogs.properties.app_display_name",
151    "azure.signinlogs.properties.app_owner_tenant_id",
152    "azure.signinlogs.properties.client_credential_type",
153    "azure.signinlogs.properties.service_principal_credential_thumbprint",
154    "azure.signinlogs.caller_ip_address",
155    "azure.signinlogs.properties.resource_display_name",
156    "azure.signinlogs.properties.unique_token_identifier",
157    "azure.correlation_id",
158    "azure.signinlogs.properties.session_id",
159    "source.geo.country_name",
160    "source.geo.city_name",
161]
162
163[rule.new_terms]
164field = "new_terms_fields"
165value = ["azure.signinlogs.properties.app_id"]
166[[rule.new_terms.history_window_start]]
167field = "history_window_start"
168value = "now-5d"

Triage and analysis

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_id and app_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_id to 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).

References

Related rules

to-top