Entra ID Service Principal with Unusual Source ASN

Identifies Entra ID service principal sign-ins where the workload identity and source autonomous system number (ASN) together have not appeared in recent history. Attackers who obtain application secrets or tokens often authenticate from unfamiliar hosting providers, residential or VPN egress, or networks outside normal automation footprints, which can precede data access, lateral movement, or ransomware activity in the tenant. The detection emphasizes first-seen network context for non-interactive workload identities.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/03/10"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/04/10"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies Entra ID service principal sign-ins where the workload identity and source autonomous system number (ASN)
 11together have not appeared in recent history. Attackers who obtain application secrets or tokens often authenticate
 12from unfamiliar hosting providers, residential or VPN egress, or networks outside normal automation footprints, which
 13can precede data access, lateral movement, or ransomware activity in the tenant. The detection emphasizes first-seen
 14network context for non-interactive workload identities.
 15"""
 16false_positives = [
 17    """
 18    New deployments, DR sites, IP rotation, or first-time CI/CD expansion can produce a genuinely new
 19    (service principal, ASN) pair without malicious intent. Baseline expected apps and approve new network paths.
 20    """,
 21    """
 22    Geo-IP and ASN enrichment updates can occasionally shift how a stable egress is labeled, creating a one-time
 23    \"new\" tuple.
 24    """,
 25    """
 26    Shared or reused service principal secrets across teams may register as new paths when first used from another site.
 27    """,
 28]
 29from = "now-65m"
 30index = ["filebeat-*", "logs-azure.signinlogs-*"]
 31interval = "1h"
 32language = "kuery"
 33license = "Elastic License v2"
 34name = "Entra ID Service Principal with Unusual Source ASN"
 35note = """## Triage and analysis
 36
 37### Investigating Entra ID Service Principal with Unusual Source ASN
 38
 39This rule matches successful **ServicePrincipalSignInLogs** events where `azure.signinlogs.properties.service_principal_id`
 40and `source.as.number` together have not appeared in the rule history window. It is a first-seen network path signal for
 41the workload identity, not proof of compromise by itself.
 42
 43#### Possible investigation steps
 44
 45- Confirm the event is **ServicePrincipalSignInLogs** with a successful outcome and review `azure.signinlogs.properties.status.error_code` on the source document if needed.
 46- Identify the application using `azure.signinlogs.properties.app_display_name`, `azure.signinlogs.properties.app_id`, and `azure.signinlogs.properties.service_principal_id`. In Entra ID, review the enterprise application or app registration (first-party, partner, or internal automation).
 47- Review `source.ip`, `source.as.organization.name`, `source.as.number`, and `source.geo.*` against the owning team’s expected regions, cloud subscriptions, and CI/CD or automation footprint.
 48- Compare `@timestamp` to maintenance windows, releases, and planned infrastructure changes.
 49- Where possible, enrich `source.ip` with internal CMDB, cloud asset inventory, or threat intelligence (residential or low-reputation ASNs warrant more scrutiny than a known cloud provider already used by this app).
 50- In Entra sign-in logs, pivot on the same `service_principal_id` or `app_id` and review prior successful sign-ins for typical ASNs and egress patterns; a one-off path may be a new pipeline or stolen credentials used from a new host.
 51- Review Entra audit logs for recent changes to this application: client secrets, certificates, federated credentials, owners, API permissions, or app role assignments, especially shortly before the alert.
 52- Query Azure Activity, Microsoft Graph, or workload-specific logs after the sign-in time using `azure.signinlogs.properties.correlation_id` or `session_id` when present to see what resources the identity accessed (subscriptions, Key Vault, mail, privileged roles).
 53- Search for related alerts in the same time window involving the same `app_id` or `source.ip` (for example OAuth abuse, consent, Arc or Kubernetes access, or directory role changes).
 54- Note that the rule query excludes Microsoft-labeled `source.as.organization.name` values; high-value investigations should also review raw sign-in data for suspicious activity that only appears under those labels.
 55
 56### False positive analysis
 57
 58- New regions, subscriptions, GitHub Actions or Azure DevOps pools, DR exercises, or vendor migrations can produce a legitimate first-seen ASN for the service principal. Validate with the owner and document expected paths before excluding.
 59- Amazon- and Google-labeled ASNs are in scope by design; adversaries may egress through AWS or GCP. Expect more noise from legitimate automation in those clouds and prefer allowlisting reviewed `app_id` or automation accounts over disabling the rule.
 60- GeoIP or ASN enrichment updates can occasionally produce a one-time new tuple; compare to historical events for the same IP if available.
 61
 62### Response and remediation
 63
 64- If the path is unexpected and risky audit activity preceded the sign-in, treat as a potential credential incident: rotate application secrets and certificates, revoke sessions or tokens as applicable, and review Conditional Access and workload identity policies for the application.
 65- Review and reduce API permissions, OAuth scopes, and directory or subscription roles granted to the application; remove unused access.
 66- Document approved automation and network baselines so repeat first-seen ASN alerts can be triaged faster.
 67"""
 68references = [
 69    "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
 70    "https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identities",
 71    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
 72    "https://www.wiz.io/blog/lateral-movement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis",
 73]
 74risk_score = 47
 75rule_id = "db97a2aa-3ba5-4fa5-b8b9-bf42284edb5f"
 76severity = "medium"
 77tags = [
 78    "Domain: Cloud",
 79    "Domain: Identity",
 80    "Data Source: Azure",
 81    "Data Source: Microsoft Entra ID",
 82    "Data Source: Microsoft Entra ID Sign-In Logs",
 83    "Use Case: Identity and Access Audit",
 84    "Use Case: Threat Detection",
 85    "Tactic: Initial Access",
 86    "Resources: Investigation Guide",
 87]
 88timestamp_override = "event.ingested"
 89type = "new_terms"
 90
 91query = '''
 92data_stream.dataset:azure.signinlogs
 93    and azure.signinlogs.category:ServicePrincipalSignInLogs
 94    and azure.signinlogs.properties.status.error_code:0
 95    and azure.signinlogs.properties.service_principal_id:*
 96    and source.as.number:*
 97    and not source.as.organization.name:(*MICROSOFT* or *Microsoft*)
 98    and not azure.signinlogs.properties.app_owner_tenant_id:(72f988bf-86f1-41af-91ab-2d7cd011db47 or f8cdef31-a31e-4b4a-93e4-5f571e91255a)
 99'''
100
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104
105[[rule.threat.technique]]
106id = "T1078"
107name = "Valid Accounts"
108reference = "https://attack.mitre.org/techniques/T1078/"
109
110[[rule.threat.technique.subtechnique]]
111id = "T1078.004"
112name = "Cloud Accounts"
113reference = "https://attack.mitre.org/techniques/T1078/004/"
114
115[rule.threat.tactic]
116id = "TA0001"
117name = "Initial Access"
118reference = "https://attack.mitre.org/tactics/TA0001/"
119
120[[rule.threat]]
121framework = "MITRE ATT&CK"
122
123[[rule.threat.technique]]
124id = "T1078"
125name = "Valid Accounts"
126reference = "https://attack.mitre.org/techniques/T1078/"
127
128[[rule.threat.technique.subtechnique]]
129id = "T1078.004"
130name = "Cloud Accounts"
131reference = "https://attack.mitre.org/techniques/T1078/004/"
132
133[rule.threat.tactic]
134id = "TA0005"
135name = "Defense Evasion"
136reference = "https://attack.mitre.org/tactics/TA0005/"
137[rule.investigation_fields]
138field_names = [
139    "@timestamp",
140    "message",
141    "event.reason",
142    "source.ip",
143    "source.geo.country_name",
144    "source.geo.country_iso_code",
145    "user.name",
146    "azure.signinlogs.properties.service_principal_id",
147    "azure.signinlogs.properties.app_display_name",
148    "azure.signinlogs.properties.app_id",
149    "source.as.number",
150    "source.as.organization.name",
151    "azure.signinlogs.properties.resource_display_name",
152    "azure.signinlogs.properties.correlation_id",
153    "azure.signinlogs.properties.session_id",
154]
155
156[rule.new_terms]
157field = "new_terms_fields"
158value = [
159    "azure.signinlogs.properties.service_principal_id",
160    "source.as.number",
161]
162[[rule.new_terms.history_window_start]]
163field = "history_window_start"
164value = "now-10d"

Triage and analysis

Investigating Entra ID Service Principal with Unusual Source ASN

This rule matches successful ServicePrincipalSignInLogs events where azure.signinlogs.properties.service_principal_id and source.as.number together have not appeared in the rule history window. It is a first-seen network path signal for the workload identity, not proof of compromise by itself.

Possible investigation steps

  • Confirm the event is ServicePrincipalSignInLogs with a successful outcome and review azure.signinlogs.properties.status.error_code on the source document if needed.
  • Identify the application using azure.signinlogs.properties.app_display_name, azure.signinlogs.properties.app_id, and azure.signinlogs.properties.service_principal_id. In Entra ID, review the enterprise application or app registration (first-party, partner, or internal automation).
  • Review source.ip, source.as.organization.name, source.as.number, and source.geo.* against the owning team’s expected regions, cloud subscriptions, and CI/CD or automation footprint.
  • Compare @timestamp to maintenance windows, releases, and planned infrastructure changes.
  • Where possible, enrich source.ip with internal CMDB, cloud asset inventory, or threat intelligence (residential or low-reputation ASNs warrant more scrutiny than a known cloud provider already used by this app).
  • In Entra sign-in logs, pivot on the same service_principal_id or app_id and review prior successful sign-ins for typical ASNs and egress patterns; a one-off path may be a new pipeline or stolen credentials used from a new host.
  • Review Entra audit logs for recent changes to this application: client secrets, certificates, federated credentials, owners, API permissions, or app role assignments, especially shortly before the alert.
  • Query Azure Activity, Microsoft Graph, or workload-specific logs after the sign-in time using azure.signinlogs.properties.correlation_id or session_id when present to see what resources the identity accessed (subscriptions, Key Vault, mail, privileged roles).
  • Search for related alerts in the same time window involving the same app_id or source.ip (for example OAuth abuse, consent, Arc or Kubernetes access, or directory role changes).
  • Note that the rule query excludes Microsoft-labeled source.as.organization.name values; high-value investigations should also review raw sign-in data for suspicious activity that only appears under those labels.

False positive analysis

  • New regions, subscriptions, GitHub Actions or Azure DevOps pools, DR exercises, or vendor migrations can produce a legitimate first-seen ASN for the service principal. Validate with the owner and document expected paths before excluding.
  • Amazon- and Google-labeled ASNs are in scope by design; adversaries may egress through AWS or GCP. Expect more noise from legitimate automation in those clouds and prefer allowlisting reviewed app_id or automation accounts over disabling the rule.
  • GeoIP or ASN enrichment updates can occasionally produce a one-time new tuple; compare to historical events for the same IP if available.

Response and remediation

  • If the path is unexpected and risky audit activity preceded the sign-in, treat as a potential credential incident: rotate application secrets and certificates, revoke sessions or tokens as applicable, and review Conditional Access and workload identity policies for the application.
  • Review and reduce API permissions, OAuth scopes, and directory or subscription roles granted to the application; remove unused access.
  • Document approved automation and network baselines so repeat first-seen ASN alerts can be triaged faster.

References

Related rules

to-top