Add App Role Assignment To Service Principal

Azure

Add App Role Assignment To Service Principal

service: Azure - Microsoft Entra ID

tactics:

Privilege Escalation Persistence

techniques:

T1098.003

tags:

Azure Microsoft Entra ID

Event

Creates an app-role assignment linking a client principalId to a resource service principal’s resourceId and appRoleId. For API permissions granted to a service principal, this represents application permission rather than delegated user consent. Resolve all three IDs and the resource’s role definition.

Security Context

Unauthorized app-role grants can expand workload privileges (T1098.003). The sample’s Microsoft Graph RoleManagement.ReadWrite.Directory application permission is highly privileged and permits directory RBAC management without a signed-in user. Authentication, a suitable token, and successful API calls are still separate evidence.

Log Source

Microsoft Entra directory audit logs with activityDisplayName: Add app role assignment to 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	Recipient and role details as available; do not confuse client appId with service-principal object ID.
AppRole.Id, AppRole.Value	Resolve the role against the resource service principal; verify the grant object’s resourceId independently.

What to Investigate

1. Confirm the recorded outcome and match the initiating identity, target, and timing to an approved change.
2. Verify the granting identity’s authorization and the approved workload requirement.
3. Resolve recipient, resource service principal, and app role; compare all existing assignments and credentials.
4. Correlate workload sign-ins and directory-role changes. A grant is not evidence that any role assignment was subsequently created.

Sample Event

Synthetic scenario. The example names Graph application permission RoleManagement.ReadWrite.Directory with its documented ID. The resource service-principal ID is absent from this illustrative audit payload and must be resolved from the assignment; no subsequent privilege use is shown.

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-000001100100_7C3D8_44528916",
  "category": "ApplicationManagement",
  "correlationId": "90000000-0000-4000-8000-000001100100",
  "result": "success",
  "resultReason": "",
  "activityDisplayName": "Add app role assignment to service principal",
  "activityDateTime": "2026-04-15T17:48:14.6720581Z",
  "loggedByService": "Core Directory",
  "operationType": "Assign",
  "initiatedBy": {
    "app": null,
    "user": {
      "id": "30000000-0000-4000-8000-001010011010",
      "displayName": "Draco Malfoy",
      "userPrincipalName": "draco@fantasticlogs.cloud",
      "ipAddress": "203.0.113.66"
    }
  },
  "targetResources": [
    {
      "id": "40000000-0000-4000-8000-001010011011",
      "displayName": "BoggartImpersonator",
      "type": "ServicePrincipal",
      "userPrincipalName": null,
      "groupType": null,
      "modifiedProperties": [
        {
          "displayName": "AppRole.DisplayName",
          "oldValue": "[]",
          "newValue": "[\"RoleManagement.ReadWrite.Directory\"]"
        },
        {
          "displayName": "AppRole.Id",
          "oldValue": "[]",
          "newValue": "[\"9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8\"]"
        },
        {
          "displayName": "AppRole.Value",
          "oldValue": "[]",
          "newValue": "[\"RoleManagement.ReadWrite.Directory\"]"
        },
        {
          "displayName": "Included Updated Properties",
          "oldValue": null,
          "newValue": "\"AppRole.DisplayName, AppRole.Id, AppRole.Value\""
        }
      ]
    }
  ],
  "additionalDetails": [
    {
      "key": "User-Agent",
      "value": "python/3.11.6 (Linux-5.15.0-1052-aws-x86_64-with-glibc2.35) AZURECLI/2.56.0 (DEB)"
    }
  ]
}

Sources

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

MITRE ATT&CK Mapping

Tactics: Privilege Escalation Persistence

Techniques:

• T1098.003 — Additional Cloud Roles — An adversary may add additional roles or permissions to an adversary-controlled cloud account to maintain persistent access to a tenant. For example, adversaries may update IAM policies in cloud-based environments or add a new global administrator in Office 365 environments. With sufficient permi...

Related Events

shares T1098.003 — Additional Cloud Roles

Add Eligible Member To Role In Pim Completed Add Member To Role Add Role Definition (Azure RBAC) add-iam-policy-binding compute.disks.setIamPolicy CreateRole CreateServiceLinkedRole google.iam.admin.v1.SetIAMPolicy +5 more

same service (Azure - Microsoft Entra ID)

Add Application Add Federated Identity Credential Add Owner To Application Add Owner To Group Add Service Principal Add User Add Verified Domain Admin Registered Security Info +8 more

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