Lesson 02 — Microsoft Entra ID Attacks

Welcome

Microsoft Entra ID is the identity platform behind many Microsoft cloud services and enterprise applications.

In Azure environments, identity is often the primary security boundary.

An attacker may not need to exploit a vulnerable server if they can compromise:

• A user account
• A privileged administrator
• A service principal
• An enterprise application
• A managed identity
• An exposed application credential
• An insecure authentication flow

For this reason, Microsoft Entra ID is one of the most important areas assessed during an Azure penetration testing engagement.

This lesson focuses on understanding the Entra ID attack surface, identifying risky identity relationships, and recognising how identity compromise can lead to access across Azure resources and Microsoft cloud services.

Learning Objectives

By the end of this lesson, you will be able to:

• Explain the purpose of Microsoft Entra ID.
• Distinguish between Entra ID and traditional Active Directory.
• Identify important Entra ID identity objects.
• Understand users, groups, applications, service principals, and managed identities.
• Identify common Entra ID attack surfaces.
• Explain how authentication weaknesses create cloud risk.
• Recognise risky application and delegated permissions.
• Understand identity-based privilege escalation paths.
• Perform authorised, non-destructive identity enumeration.
• Document Entra ID findings using professional evidence standards.

Mission Context

You are continuing the authorised Azure penetration test for CloudNova Technologies.

The customer uses Microsoft Entra ID for:

• Employee identities
• Administrator access
• Microsoft 365 authentication
• Azure Portal access
• Enterprise applications
• Software-as-a-Service integrations
• Service principals
• Managed identities
• Conditional Access
• Multifactor authentication

The organisation has several business units, external contractors, automated applications, and privileged administrators.

Your objective is to identify identity weaknesses that could allow an attacker to:

• Compromise a user
• Abuse an application identity
• Escalate privileges
• Bypass expected access restrictions
• Access Azure resources
• Move between cloud services
• Establish persistent access

All activities must remain within the authorised Rules of Engagement.

What Is Microsoft Entra ID?

Microsoft Entra ID is Microsoft’s cloud-based identity and access management service.

It provides:

• User authentication
• Application authentication
• Single sign-on
• Multifactor authentication
• Conditional Access
• Identity governance
• Device identity
• Privileged role management
• Access to Azure and Microsoft cloud services

Microsoft Entra ID was previously known as Azure Active Directory.

It is closely connected to Azure, but it is not the same as an Azure subscription.

A single Entra tenant may provide identities for multiple:

• Azure subscriptions
• Microsoft 365 services
• Enterprise applications
• SaaS platforms
• Internal applications

Entra ID and Traditional Active Directory

Microsoft Entra ID and traditional Active Directory serve related purposes but use different architectures.

Area	Traditional Active Directory	Microsoft Entra ID
Primary environment	On-premises	Cloud
Core protocols	Kerberos, LDAP, NTLM	OAuth 2.0, OpenID Connect, SAML
Main objects	Users, groups, computers	Users, groups, applications, service principals, devices
Administration	Domain and forest model	Tenant model
Resource access	Domain resources	Cloud applications and Azure resources
Authentication focus	Domain sign-in	Cloud and application sign-in

Many enterprises operate hybrid identity environments where on-premises Active Directory synchronises with Microsoft Entra ID.

This creates additional attack-path considerations.

Microsoft Entra ID Tenant

An Entra tenant is a dedicated identity directory for an organisation.

A tenant contains objects such as:

• Users
• Groups
• Devices
• Administrative roles
• Application registrations
• Enterprise applications
• Service principals
• Conditional Access policies

The tenant acts as the trust boundary for identity administration.

Understanding which tenant is in scope is essential before beginning an assessment.

Important Identity Objects

Users

Users represent human identities.

Examples include:

• Employees
• Administrators
• Contractors
• Guest users
• Service accounts

Security risks may include:

• Weak authentication
• Missing multifactor authentication
• Excessive privileges
• Dormant accounts
• Shared accounts
• Weak guest governance

Groups

Groups simplify access management by assigning permissions to multiple users.

Groups may provide access to:

• Applications
• Azure resources
• Administrative functions
• Collaboration platforms

Risk increases when:

• Privileged groups contain unnecessary members
• Group ownership is poorly controlled
• Nested group relationships are not reviewed
• Users can add themselves or others to sensitive groups

Administrative Roles

Entra administrative roles provide permissions over tenant-level identity functions.

Examples include:

• Global Administrator
• Privileged Role Administrator
• Application Administrator
• Cloud Application Administrator
• User Administrator
• Security Administrator
• Authentication Administrator

These roles are different from Azure RBAC roles.

Entra roles control identity and directory functions, while Azure RBAC roles control Azure resources.

Application Registrations

An application registration defines an application identity within the tenant.

It may include:

• Application ID
• Redirect URIs
• API permissions
• Certificates
• Client secrets
• Authentication settings

Poorly configured applications can expose high-value access paths.

Enterprise Applications

An enterprise application is the tenant-specific representation of an application.

It is usually associated with a service principal.

Enterprise applications may provide:

• Single sign-on
• User assignments
• API access
• Application permissions
• Federation with third-party services

Service Principals

A service principal represents an application or automated identity inside a tenant.

Service principals are commonly used by:

• Automation
• CI/CD pipelines
• Infrastructure-as-code platforms
• Monitoring systems
• Internal applications

Security risks include:

• Long-lived client secrets
• Excessive API permissions
• Unused credentials
• Broad Azure RBAC assignments
• Insecure ownership
• Poor credential rotation

Managed Identities

Managed identities allow Azure resources to authenticate without storing traditional credentials in code.

Types include:

• System-assigned managed identity
• User-assigned managed identity

Managed identities reduce secret-management risk, but excessive permissions can still create serious attack paths.

For example:

Compromised virtual machine
        ↓
Access to managed identity
        ↓
Token obtained for Azure service
        ↓
Access to storage or Key Vault
        ↓
Sensitive data exposure

Entra ID Authentication

Microsoft Entra ID supports several authentication methods, including:

• Passwords
• Multifactor authentication
• Passwordless authentication
• Security keys
• Microsoft Authenticator
• Certificate-based authentication
• Federated authentication

An assessment should evaluate whether authentication controls match the sensitivity of the identities and resources being protected.

Common Authentication Risks

Potential weaknesses include:

• Privileged accounts without multifactor authentication
• Weak or legacy authentication methods
• Excessive reliance on passwords
• Incomplete Conditional Access coverage
• Insecure recovery methods
• Poor guest-user controls
• Unmonitored risky sign-ins
• Weak service-account governance

Testing authentication controls must remain non-destructive and must follow the engagement scope.

Conditional Access

Conditional Access evaluates sign-in conditions before allowing access.

Policies may consider:

• User or group
• Application
• Device state
• Geographic location
• Sign-in risk
• Authentication strength
• Network location

Common assessment questions include:

• Are privileged users covered?
• Are legacy protocols blocked?
• Are guest users controlled?
• Are sensitive applications protected?
• Are emergency access accounts handled correctly?
• Are policy exclusions justified?

A policy may exist but still fail to provide complete coverage due to exclusions or misconfiguration.

Multifactor Authentication

Multifactor authentication reduces the risk of password-only compromise.

However, testers should also assess:

• Which users are excluded
• Whether administrators are protected
• Whether legacy authentication remains enabled
• Whether weak authentication methods are accepted
• Whether registration and recovery processes are secure

The objective is to evaluate control coverage, not to disrupt user access.

Guest Users

Entra ID supports business-to-business collaboration through guest identities.

Guest users can introduce risk when:

• Access is not time-limited
• Sponsorship is unclear
• Old accounts remain active
• Guests belong to privileged groups
• External collaboration settings are too permissive
• Access reviews are not performed

Guest identities should be treated as part of the organisation’s attack surface.

Application Permissions

Applications may receive two major categories of Microsoft Graph permissions.

Delegated Permissions

Delegated permissions are used when an application acts on behalf of a signed-in user.

Effective access depends on:

• The application’s permission
• The signed-in user’s permission

Application Permissions

Application permissions allow an application to act without a signed-in user.

These permissions can be highly sensitive because they may provide tenant-wide access.

Examples of high-impact permission areas include:

• Reading users
• Reading groups
• Reading mail
• Managing applications
• Managing directory objects
• Accessing files
• Modifying identities

Application permissions should be carefully reviewed during an assessment.

Consent and Permission Risk

Applications may receive permission through:

• User consent
• Administrator consent
• Pre-authorised integration
• Enterprise application assignment

Potential risks include:

• Excessive permissions
• Unverified applications
• Unnecessary tenant-wide consent
• Poor consent governance
• Old applications with active credentials
• Applications owned by former employees

Consent abuse can provide an attacker with persistent access even after a user changes their password.

Service Principal Credentials

Service principals may authenticate using:

• Client secrets
• Certificates
• Federated credentials

Assessment considerations include:

• Credential age
• Expiration date
• Rotation process
• Number of active credentials
• Storage location
• Application ownership
• Associated permissions
• Sign-in activity

Long-lived or unused credentials increase the risk of unnoticed compromise.

Identity Enumeration

Authorised identity enumeration helps the tester understand relationships between users, groups, roles, and applications.

Common enumeration targets include:

• Tenant information
• Current user identity
• Group memberships
• Administrative role assignments
• Application registrations
• Enterprise applications
• Service principals
• Managed identities
• Guest accounts
• Authentication methods
• Sign-in logs, where authorised

Enumeration should use approved accounts and read-only access wherever possible.

Safe Azure CLI Identity Checks

The following examples are intended for authorised lab or assessment environments.

Confirm the currently authenticated identity:

az account show

Display accessible subscriptions:

az account list --output table

Display tenant information associated with the current context:

az account tenant list

Display details for the currently signed-in user where permissions allow:

az ad signed-in-user show

List groups visible to the authorised identity:

az ad group list --output table

List application registrations visible to the authorised identity:

az ad app list --output table

List service principals visible to the authorised identity:

az ad sp list --output table

Results depend on the assigned permissions and tenant configuration.

Do not attempt to bypass access controls to retrieve unavailable directory information.

Microsoft Graph

Microsoft Graph provides API access to Microsoft cloud identity and service data.

It can be used during authorised assessments to review:

• Users
• Groups
• Applications
• Service principals
• Directory roles
• Devices
• Sign-in activity
• Permission grants

Microsoft Graph permissions must be explicitly authorised.

A successful API response does not automatically mean that every returned object is within the engagement scope.

Entra ID Attack Surface Mapping

A professional attack-surface map should record relationships between:

Users
  ↓
Groups
  ↓
Administrative roles
  ↓
Applications
  ↓
Service principals
  ↓
Azure RBAC assignments
  ↓
Azure resources

This relationship mapping helps identify high-value attack paths.

For example:

Standard user
        ↓
Owner of application registration
        ↓
Ability to add application credential
        ↓
Authentication as service principal
        ↓
Contributor role on subscription
        ↓
Control of Azure resources

The tester should validate each relationship carefully before assigning risk.

Common Entra ID Attack Paths

Compromised Privileged User

Compromised administrator
        ↓
Tenant-level administrative access
        ↓
Application or user modification
        ↓
Expanded cloud access

Application Ownership Abuse

Application owner
        ↓
Ability to modify application credentials
        ↓
Authentication as application
        ↓
Use of assigned API or Azure permissions

Excessive Service Principal Permissions

Exposed service principal credential
        ↓
Application authentication
        ↓
Access to Microsoft Graph or Azure resources
        ↓
Data access or resource modification

Guest Account Exposure

Compromised external identity
        ↓
Access to enterprise application
        ↓
Membership in sensitive group
        ↓
Unauthorised business data access

Hybrid Identity Compromise

Compromised on-premises identity
        ↓
Synchronised Entra identity
        ↓
Cloud application access
        ↓
Azure resource access

Privileged Identity Management

Microsoft Entra Privileged Identity Management can provide:

• Eligible role assignments
• Time-limited activation
• Approval workflows
• Multifactor authentication requirements
• Access reviews
• Audit history

Assessment questions include:

• Are privileged roles permanently active?
• Are approvals required?
• Are activation durations reasonable?
• Is multifactor authentication enforced?
• Are role activations monitored?
• Are emergency access accounts governed?

Poor Privileged Identity Management configuration can weaken the intended just-in-time access model.

Identity Protection and Sign-In Risk

Microsoft Entra ID may identify:

• Risky users
• Risky sign-ins
• Unfamiliar locations
• Unusual travel
• Leaked credentials
• Suspicious authentication behaviour

An offensive security assessment should determine whether:

• Risk detections are monitored
• Automated responses exist
• High-risk sign-ins trigger controls
• Security teams investigate identity alerts
• Logging retention supports investigation

Logging and Evidence

Useful identity evidence may include:

• User object ID
• Group object ID
• Application ID
• Service principal object ID
• Tenant ID
• Administrative role assignment
• API permission
• Consent grant
• Credential expiration
• Sign-in timestamp
• Conditional Access result
• Risk status

Avoid storing:

• Passwords
• Access tokens
• Client secrets
• Session cookies
• Sensitive personal information

unless explicitly authorised and required for evidence.

Sensitive material must be protected and redacted in student portfolios.

Risk Rating Considerations

The severity of an Entra ID finding depends on:

• Identity privilege
• Permission scope
• Credential exposure
• Ease of exploitation
• Authentication controls
• Available monitoring
• Number of affected users
• Accessible data
• Potential business impact

For example, an old service principal credential may be low risk if the application has no useful permissions, but critical if it can administer the tenant or access sensitive information.

Remediation Principles

Common identity-security recommendations include:

• Enforce strong multifactor authentication.
• Remove unnecessary privileged roles.
• Use Privileged Identity Management.
• Review guest access regularly.
• Restrict user consent.
• Review application permissions.
• Rotate application credentials.
• Prefer certificates or federated credentials over long-lived secrets.
• Remove unused applications and service principals.
• Monitor risky sign-ins.
• Apply Conditional Access consistently.
• Perform regular access reviews.
• Use least privilege for Azure RBAC and Microsoft Graph.

Evidence and Portfolio Outcome

Create an Entra ID Attack Surface Assessment containing:

Tenant Overview

• Tenant identifier
• Authorised test account
• Accessible subscriptions
• Identity sources
• Hybrid identity status, where known

Identity Inventory

• Users
• Guest users
• Groups
• Administrative roles
• Applications
• Service principals
• Managed identities

Security Observations

• Multifactor authentication coverage
• Conditional Access coverage
• Privileged-role usage
• Guest-account governance
• Application-permission risks
• Credential-management risks

Attack-Path Diagram

Document one safe, hypothetical identity attack path.

Example:

User
  ↓
Application owner
  ↓
Service principal
  ↓
Azure role assignment
  ↓
Storage account

Recommendations

Provide prioritised remediation guidance.

Key Takeaways

• Microsoft Entra ID is a central security boundary in Azure.
• Entra roles and Azure RBAC roles serve different purposes.
• Applications and service principals can hold powerful permissions.
• Managed identities remove stored credentials but still require least privilege.
• Conditional Access and multifactor authentication must provide complete coverage.
• Guest users and unused applications increase the identity attack surface.
• Identity attacks often involve relationships rather than isolated vulnerabilities.
• Authorised enumeration should be read-only, controlled, and well documented.

Knowledge Check

1. What is Microsoft Entra ID?
2. How does Entra ID differ from traditional Active Directory?
3. What is the difference between an application registration and a service principal?
4. What is the difference between delegated and application permissions?
5. Why can application permissions be high risk?
6. What is the security purpose of Conditional Access?
7. How can a managed identity become part of an attack path?
8. Why should guest users be regularly reviewed?
9. What is the difference between an Entra administrative role and an Azure RBAC role?
10. Why should identity findings be evaluated as connected attack paths?

Next Lesson

➡️ Lesson 03 — Azure RBAC Exploitation

In the next lesson, you will examine Azure role definitions, role assignments, scopes, custom roles, and the ways excessive permissions can create authorised privilege-escalation paths across Azure resources.