Microsoft 365 Accounts, Users, Groups and Roles

Forensic Identity Principle

Never assume all accounts are human users. In modern cloud intrusions, threat actors actively target service principals, shared mailboxes, and guest invitations. Distinguishing the precise archetype of a security principal is mandatory to determine its authentication capabilities and blast radius.

Concept

In Microsoft 365 and Microsoft Entra ID, security and authorization are enforced across a rich taxonomy of principals, containers, and role assignments.

An incident responder must clearly differentiate between:

• Human Identities: Member accounts, guest users, synchronized on-premises identities, and emergency break-glass accounts.
• Service & Application Identities: Service accounts, App Registrations, Enterprise Applications (Service Principals), and Managed Identities.
• Group Containers: Security Groups, Microsoft 365 Unified Groups, Mail-enabled Security Groups, and Dynamic Membership Groups.
• Authorization Models: Entra ID Directory Roles, Workload-specific Role-Based Access Control (Exchange RBAC, Purview RBAC), and Privileged Identity Management (PIM) activations.

+---------------------------------------------------------------------------------------------------+
|                                 MICROSOFT 365 IDENTITY TAXONOMY                                   |
|                                                                                                   |
|   +------------------------------------+             +------------------------------------+       |
|   |         HUMAN IDENTITIES           |             |        WORKLOAD IDENTITIES         |       |
|   |   Member (Internal Full Rights)    |             |   App Registration (Definition)    |       |
|   |   Guest (B2B External #EXT#)       |             |   Service Principal (Local Instance|       |
|   |   Shared Mailbox (Disabled Auth)   |             |   Managed Identity (Azure Service) |       |
|   +-----------------+------------------+             +-----------------+------------------+       |
|                     |                                                  |                          |
|                     +------------------------+-------------------------+                          |
|                                              |                                                    |
|                                              v                                                    |
|   +-------------------------------------------------------------------------------------------+   |
|   |                                  CONTAINERS (GROUPS)                                      |   |
|   |   Security Groups (Access/CA) | Microsoft 365 Groups (Mailbox + SharePoint + Teams)       |   |
|   |   Assigned Membership (Static)| Dynamic Membership (Rule-based: user.department -eq "IT") |   |
|   +------------------------------------------+------------------------------------------------+   |
|                                              |                                                    |
|                                              v                                                    |
|   +-------------------------------------------------------------------------------------------+   |
|   |                                  AUTHORIZATION MODELS                                     |   |
|   |   Entra Directory Roles (Global Admin, Security Reader, Application Administrator)        |   |
|   |   Privileged Identity Management (PIM: Eligible vs Active / Timed Activations)            |   |
|   |   Workload RBAC (Exchange Organization Management, Purview Compliance Administrator)      |   |
|   +-------------------------------------------------------------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

---

Why It Matters in DFIR

Failing to grasp the nuances of M365 identity archetypes leads directly to investigative blind spots:

• Shared Mailbox Abuse: Shared mailboxes do not require a paid license and should have their direct interactive login disabled (AccountEnabled: False). If an attacker enables interactive login or assigns a password, they obtain a stealthy, unmonitored mailbox for Business Email Compromise (Fiche 49: BEC).
• Workload Identity Concealment: Threat actors frequently establish persistence by creating or compromising an Enterprise Application (Service Principal). Service principals do not undergo Multi-Factor Authentication (MFA), bypass Conditional Access policies that lack workload identity scopes, and operate invisibly to standard endpoint EDR (Fiche 29: OAuth Persistence).
• Dynamic Group Privilege Creep: If an organization uses dynamic groups to grant administrative access or SharePoint confidential permissions, an attacker with low-level user write access can simply change an attribute (e.g., set department = "Global IT") to automatically inherit elevated permissions.
• PIM Activation Evasion: Auditors often review permanent role assignments and declare a tenant secure. Attackers who compromise accounts with PIM Eligibility activate roles on-demand for 1-hour intervals, evading basic static posture reviews.

---

How It Works

1. User Types: Member vs Guest

• Member (UserType: Member): Standard employee identity. By default, members have broad directory read permissions: they can enumerate all other users, security groups, tenant configurations, and registered applications.
• Guest (UserType: Guest): External collaborator invited via Entra B2B. Identified by an altered UPN containing #EXT# (e.g., partner_external.com#EXT#@company.onmicrosoft.com). By default, guests have restricted directory permissions and can only view their own user profile and memberships.

2. Workload Identities: App Registrations vs Service Principals

• App Registration: The global architectural blueprint of an application. It defines permission scopes (Delegated vs Application) and redirect URIs.
• Enterprise Application (Service Principal): The concrete security token and local instance of an application within the tenant. It holds the cryptographic credentials (certificates, client secrets) and actual role assignments.
• Managed Identity: A special type of Service Principal managed automatically by Azure, used by Azure VMs, functions, or containers to authenticate to Entra ID without human-managed secrets.

3. Group Classifications

• Security Groups: Used to assign access to resources (SharePoint, Azure subscriptions) and to scope Conditional Access policies.
• Microsoft 365 Groups (formerly Unified Groups): Collaboration hubs that simultaneously provision:
  • An Exchange shared mailbox and calendar.
  • A SharePoint Online team site collection.
  • A Microsoft Teams channel (if team-enabled).
• Dynamic Membership Groups: Members are not manually assigned; instead, Entra ID evaluates attribute queries (e.g., (user.jobTitle -eq "SysAdmin") and (user.accountEnabled -eq true)).

4. Entra ID Directory Roles vs Workload RBAC

• Directory Roles (Tenant-Wide): Entra-level privileges (e.g., Global Administrator, Application Administrator, Privileged Role Administrator).
• Workload RBAC:
  • Exchange Online RBAC: Roles like Organization Management, Compliance Management, View-Only Recipients. These permissions exist inside Exchange Online and are separate from Entra directory roles.
  • Purview Roles: Compliance-specific roles (e.g., Audit Reader, eDiscovery Manager) administered in Purview or via unified compliance groups.
• Privileged Identity Management (PIM):
  • Permanent Assignment: Account always possesses the role.
  • Eligible Assignment: Account is authorized to request elevation for a time-bound window (e.g., 2 to 8 hours), requiring an MFA challenge, business justification, and optional approval.

---

What Is Possible

During forensic investigations, analyzing identity structures allows you to:

• Trace Privilege Escalation Pathways: Map which directory roles an identity held permanently or activated via PIM (Fiche 31: Entra Roles).
• Identify Rogue Credentials: Detect new client secrets or certificates added to service principals to create backdoor API access.
• Audit Group Manipulation: Reconstruct exactly when an account was added to an administrative group, by whom, and whether dynamic rules were manipulated.
• Inspect External Sharing: Trace which external guest accounts were invited, accepted, and what SharePoint resources were shared with them (Fiche 34: SharePoint).

---

What Is Not Possible

• No Recovery of Deleted Guest Invites Beyond 30 Days: Once an object is hard-deleted from the Entra ID Recycle Bin (after 30 days of soft-deletion), its historic metadata cannot be queried natively.
• No Direct Reversal of Delegated API Actions: When a compromised user grants consent to a rogue OAuth app with delegated permissions, actions taken by the app appear in workload logs under the user’s identity, making it impossible to separate user actions from application actions without correlating AppId in the audit event.

---

Prerequisites & Necessary Conditions

To audit identities, groups, and roles across a tenant:

• Required Roles: Global Reader (for full directory read) or Security Reader + Directory Readers (Fiche 05: Global Reader).
• PowerShell Tooling: Modern Microsoft.Graph module (specifically Microsoft.Graph.Users, Microsoft.Graph.Groups, Microsoft.Graph.Identity.Governance).

---

Artifacts and Evidence Sources

Event / Object	Evidence Source	Key Forensic Attributes
Account Creation	Entra Directory Audit (Add user)	InitiatedBy, TargetResources.UserPrincipalName, TargetResources.Id
Role Assignment	Entra Directory Audit (Add member to role)	RoleDefinitionId, TargetResources, InitiatedBy
PIM Activation	Entra Directory Audit (Add eligible member to role / Add member to role completed (PIM))	Justification, TicketNumber, Duration, InitiatedBy
App Credential Injection	Entra Directory Audit (Update application - Certificates and secrets management)	AppId, KeyDescription, KeyType, KeyIdentifier
Group Membership Change	Entra Directory Audit (Add member to group)	TargetResources.Group, TargetResources.Member, InitiatedBy
Service Principal Sign-In	Entra Sign-In Logs (servicePrincipalSignIns)	ServicePrincipalId, AppId, IpAddress, ResourceDisplayName

---

Investigation Methodology

1. Enumerate High-Privilege Account Assignments: Identify all accounts holding permanent or eligible administrative roles using PowerShell:

   Get-MgDirectoryRole | ForEach-Object {
     $role = $_
     Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | Select-Object @{N="Role";E={$role.DisplayName}}, Id, AdditionalProperties
   }

2. Audit PIM Activations: Query directory audits for PIM elevation events over the incident window:

   Get-MgAuditLogDirectoryAudit -Filter "category eq 'RoleManagement' and activityDisplayName eq 'Add member to role completed (PIM activation)'" `
     -All | Select-Object ActivityDateTime, InitiatedBy, TargetResources, AdditionalDetails

3. Inspect Application Secrets and Certificates: Identify newly generated client secrets or certificate uploads that could represent backdoors:

   Get-MgAuditLogDirectoryAudit -Filter "category eq 'ApplicationManagement' and activityDisplayName eq 'Update application - Certificates and secrets management'" `
     -All | Select-Object ActivityDateTime, InitiatedBy, TargetResources

4. Verify Shared Mailbox Configuration: Audit all shared mailboxes to ensure their direct interactive login remains disabled:

   Get-MgUser -Filter "assignedLicenses/$count eq 0" -ConsistencyLevel eventual `
     | Select-Object UserPrincipalName, AccountEnabled, SignInActivity

5. Examine Guest Identities and Invitations: List recently invited guests and check for external invitations issued from compromised accounts:

   Get-MgUser -Filter "userType eq 'Guest'" -All | Select-Object UserPrincipalName, Mail, ExternalUserState, CreatedDateTime

---

Practical Example / Case Walkthrough

Scenario: The Dormant Service Principal Backdoor

Following the containment of a compromised Global Administrator account, the client changed all user passwords and revoked session tokens. Two weeks later, executive emails were exfiltrated again without any user sign-in activity recorded in the Entra interactive sign-in logs.

Forensic Investigation:

1. Investigating Workload Identities: The analyst examined the ServicePrincipal sign-in stream and discovered automated daily logins by an enterprise application named "Backup_Reporting_Utility".
2. Reviewing Directory Audit History: Auditing application management actions revealed that during the initial intrusion, the compromised Global Admin executed:
   • Add service principal
   • Add app role assignment to service principal: Granted Mail.ReadWrite as an Application Permission (not Delegated).
   • Update application - Certificates and secrets: Injected a 2-year RSA public key certificate owned by the threat actor.
3. Conclusion: While the client reset all human passwords, the attacker’s Service Principal remained active. Because it used Application Permissions, it queried Microsoft Graph directly via client-credentials grant (/oauth2/v2.0/token) to harvest mailboxes without requiring any user session or MFA challenge (Fiche 51: OAuth Compromise).

---

Common Pitfalls and Traps

Pitfall	Operational Reality	Forensic Consequence
Assuming MFA protects Service Principals	Service principals authenticate via certificates or client secrets; they cannot perform interactive MFA.	Overlooking compromised application credentials because “MFA is enforced on all tenant users.”
Confusing App Registrations with Enterprise Apps	An App Registration is merely a template; deleting it does not automatically invalidate existing Service Principal tokens in other tenants.	Leaving an active backdoor service principal running in the tenant.
Ignoring Dynamic Group Rules	Attackers alter user attributes (title, department) to automatically slip into dynamic groups.	Missing unauthorized access to SharePoint sites restricted to specific groups.

---

Key Takeaways

1. Identity is multi-faceted: Human users, guest collaborators, shared mailboxes, and automated service principals coexist on the same identity plane.
2. Workload identities are prime persistence targets: Service principals bypass interactive MFA and can hold sweeping tenant-wide application permissions.
3. PIM history must be actively audited: Check PIM activation logs (Add member to role completed (PIM)) rather than relying solely on static role member lists.
4. Shared mailboxes must have disabled accounts: Direct login on shared mailboxes must be strictly prohibited (AccountEnabled: False).

---

Feature State in 2026

Recent Changes

• Workload Identity Protection: Microsoft Entra Workload ID provides conditional access policies, risk detection, and access reviews specifically tailored for Service Principals and Managed Identities.
• Entra PIM for Groups: PIM can now govern eligible membership in security groups and M365 groups, not just directory roles.

Deprecated Features

• Legacy Azure AD PowerShell cmdlets (Get-AzureADUser, Add-AzureADDirectoryRoleMember) are permanently decommissioned.
• Use exclusively Get-MgUser, New-MgDirectoryRoleMember from the Microsoft.Graph SDK.

---

References

• Microsoft Learn: User and Guest Account Types in Microsoft Entra ID
• Microsoft Learn: Applications and Service Principals in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra Built-in Roles and Least Privilege
• Microsoft Learn: Audit Logs in Microsoft Entra ID