Add Service Principal

Azure

Add Service Principal

service: Azure - Microsoft Entra ID

tactics:

Persistence

techniques:

T1136.003

tags:

Azure Microsoft Entra ID

Event

Creates a service principal representing an application in a tenant. An application can have service principals in multiple tenants. Resolve its appId, servicePrincipalType, and owning organization; application, managed-identity, and legacy service principals have different lifecycle characteristics.

Security Context

Unauthorized service-principal creation may establish a persistent cloud identity (T1136.003). Legitimate application onboarding and consent also create service principals. The object alone does not prove credentials exist, permissions were granted, or a workload authenticated.

Log Source

Microsoft Entra directory audit logs with activityDisplayName: Add service principal and category: ApplicationManagement. Check result/resultReason and correlate stable object IDs. The sample uses Microsoft Graph directoryAudit-style JSON; Azure Monitor AuditLogs exports use different field names and casing.

Key Fields

Field	Investigation value
targetResources[].id, modifiedProperties	Service-principal object ID, app identifier, type, and enabled state where recorded.
additionalDetails	Supplementary evidence only; undocumented values are not reliable proof of creation workflow.

What to Investigate

1. Confirm the recorded outcome and match the initiating identity, target, and timing to an approved change.
2. Resolve the service principal to the application, home tenant, publisher, and approved workload.
3. Inspect credentials/federation configuration, consent grants, app roles, and Azure role assignments independently.
4. Correlate workload sign-ins and resource activity. Do not infer home-tenant equality without tenant context.

Sample Event

Synthetic scenario. An Application-type service principal is created for Phoenix-Backup. Unverified provisioning-type details are omitted; this record does not establish its permissions or use.

Exact field presence, target ordering, modified-property names, and payload serialization remain unverified against captured logs. Treat these examples as illustrations, not guaranteed schemas or complete change histories.

{
  "id": "Directory_90000000-0000-4000-8000-000000000100_5A1B7_55009912",
  "category": "ApplicationManagement",
  "correlationId": "90000000-0000-4000-8000-000000000100",
  "result": "success",
  "resultReason": "",
  "activityDisplayName": "Add service principal",
  "activityDateTime": "2026-04-15T16:11:53.4419006Z",
  "loggedByService": "Core Directory",
  "operationType": "Add",
  "initiatedBy": {
    "app": null,
    "user": {
      "id": "30000000-0000-4000-8000-000000000001",
      "displayName": "Hermione Granger",
      "userPrincipalName": "hermione@fantasticlogs.cloud",
      "ipAddress": "198.51.100.42"
    }
  },
  "targetResources": [
    {
      "id": "40000000-0000-4000-8000-000000000010",
      "displayName": "Phoenix-Backup",
      "type": "ServicePrincipal",
      "userPrincipalName": null,
      "groupType": null,
      "modifiedProperties": [
        {
          "displayName": "AccountEnabled",
          "oldValue": "[]",
          "newValue": "[true]"
        },
        {
          "displayName": "AppPrincipalId",
          "oldValue": "[]",
          "newValue": "[\"40000000-0000-4000-8000-000000000001\"]"
        },
        {
          "displayName": "DisplayName",
          "oldValue": "[]",
          "newValue": "[\"Phoenix-Backup\"]"
        },
        {
          "displayName": "ServicePrincipalNames",
          "oldValue": "[]",
          "newValue": "[\"40000000-0000-4000-8000-000000000001\"]"
        },
        {
          "displayName": "ServicePrincipalType",
          "oldValue": "[]",
          "newValue": "[\"Application\"]"
        },
        {
          "displayName": "Included Updated Properties",
          "oldValue": null,
          "newValue": "\"AccountEnabled, AppPrincipalId, DisplayName, ServicePrincipalNames, ServicePrincipalType\""
        }
      ]
    }
  ],
  "additionalDetails": [
    {
      "key": "AppOwnerOrganizationId",
      "value": "10000000-0000-4000-8000-000000000001"
    },
    {
      "key": "User-Agent",
      "value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36"
    }
  ]
}

Sources

• Microsoft documentation
• Microsoft documentation
• Microsoft documentation
• Microsoft documentation
• MITRE ATT&CK T1136.003

MITRE ATT&CK Mapping

Tactics: Persistence

Techniques:

• T1136.003 — Cloud Account — Adversaries may create a cloud account to maintain access to victim systems. With a sufficient level of access, such accounts may be used to establish secondary credentialed access that does not require persistent remote access tools to be deployed on the system.

Related Events

shares T1136.003 — Cloud Account

Add Application Add User CreateAccount CreateUser Invite External User

same service (Azure - Microsoft Entra ID)

Add App Role Assignment To Service Principal Add Eligible Member To Role In Pim Completed Add Federated Identity Credential Add Member To Role Add Owner To Application Add Owner To Group Add Verified Domain Admin Registered Security Info +7 more

Documentation reviewed: September 30, 2026. Samples are synthetic illustrations, not captured production logs or lab-validated fixtures.