The following Entra ID vulnerabilities require a Premium License. If the organization has a free license, Assessment results for these Discoveries will return as Inconclusive.
Entra ID guest user accounts that are inactive
Entra ID Privileged accounts that are not secured by multi-factor authentication (MFA)
The following table describes the vulnerabilities identified in the pre-defined Entra Discovery for Credential Access.
|
|
NOTE: Credential Access techniques are deployed by adversaries on systems and networks to steal usernames and credentials for re-use. |
| Vulnerability Template | Vulnerability | Risk | What to find |
|---|---|---|---|
| Entra ID tenant on-premises Password hash synchronization |
Name: Password hash synchronization with on-premises Active Directory is not enabled Default scope: N/A
NOTE: If no Active Directory collection is available, an Inconclusive message is returned.
|
Microsoft Entra Connect synchronizes a hash of the user's passwords from on-premises Active Directory to Entra ID. Password hash sync enables users to sign in to a service by using the same password that is used to sign in to the on-premises Active Directory instance. Password hash sync allows Identity Protection to detect compromised credentials by comparing password hashes with passwords known to be compromised. Remediation: In Microsoft Entra Connect, the Password Hash Synchronization setting can be enabled on the User Sign-in page. |
Entra ID tenants in scope that have on-premises Active Directory Password hash synchronization disabled |
| Entra ID user account multi-factor authentication status |
Name: Entra ID Privileged accounts that are not secured by multi-factor authentication (MFA)
Default scope: All Privileged users |
Accounts that are assigned administrative rights are targeted by attackers. Requiring multi-factor authentication (MFA) on those accounts is an easy way to reduce the risk of those accounts being compromised. Remediation: Administrator accounts identified may be a member of a Privileged or non-Privileged administrator role. Investigate each administrator to determine why they are not using multi-factor authentication (MFA). If a large number of administrators are not using MFA, MFA may need to be enforced using Security Defaults or Conditional Access policies. |
Entra ID user accounts in scope that have multi-factor authentication not registered |
| Entra ID tenant administrator SSPR status |
Name: Administrators are not enabled for self service password recovery Default scope: Entra ID tenant(s)
|
By default, administrator accounts are enabled for self-service password reset (SSPR), and a strong default two-gate password reset policy is enforced. Remediation: SSPR for administrator accounts can be re-enabled using the Update-MgPolicyAuthorizationPolicy PowerShell cmdlet. The -AllowedToUseSspr:$true|$false parameter enables SSPR for administrators. Policy changes to enable or disable SSPR for administrator accounts can take up to 60 minutes to take effect. |
Entra ID tenants in scope that have an administrator service password reset (SSPR) disabled |
| Entra ID Conditional Access policy “Exchange ActiveSync clients” and “Other clients” access control |
Name: Entra ID Conditional Access policies do not block legacy authentication for all users Default scope: All users
|
Applications using legacy methods to authenticate with Microsoft Entra ID and access organization data are not considered secure. Protocols such as POP3, IMAP4, and SMTP have been replaced by modern authentication, which uses Multifactor Authentication (MFA). Remediation: Organizations with Microsoft Entra ID P1 or P2 licenses should use Conditional Access policies to block legacy authentication. Organizations with Microsoft Entra ID Free tier should enable Microsoft Entra Security Defaults to block legacy authentication.
NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:
|
Entra ID user accounts in scope that do not have the client apps “Exchange ActiveSync clients” and “Other clients” access control set to block in an assigned Conditional Access policy |
| Entra ID Conditional Access policy sign-in risk | Name:
Entra ID Conditional Access polices do not protect all users from risky sign-ins Default scope: All users |
A risky sign-in represents the probability that an authentication request is not authorized by the identity owner. Based on the risk level high, medium and low, a policy can be configured to block access or force multifactor authentication. Microsoft recommends that multifactor authentication is forced on Medium or above risky sign-ins. Remediation: Requires a Microsoft Entra ID P2 license. Enable a Conditional Access policy for the tenant that has “Users” set to include “All users” and exclude emergency access or break-glass accounts.
NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:
|
Entra ID user accounts in scope that do not have sign-in risk levels set to high, medium in an assigned Conditional Access policy |
| Entra ID Conditional Access user risk policy |
Name: Entra ID Conditional Access polices do not protect all users from high user risk Default scope: All users |
User risk indicates the likelihood a user's identity has been compromised and is calculated based on the user risk detections that are associated with a user's identity. Based on a risk-level of high, medium, low a policy can be configured to block access or require a secure password change using multifactor authentication. Microsoft's recommendation is to require a secure password change for users with high risk. Remediation: Requires a Microsoft Entra ID P2 license. Enable a Conditional Access policy for the tenant that has “Users” set to include “All users” and exclude emergency access or break-glass accounts. In “Target resources”, “Cloud apps” set to include “All cloud apps”. In “Access controls” “Grant”, set “Grant access” to “Require multifactor authentication” and “Require password change”. In "Session", set "Sign-in frequency” to “Every time”. In Conditions, select “User risk”, set “Configure” to Yes. Under “Configure user risk levels needed for policy to be enforced”, select the “High” option. NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:
|
Entra ID user accounts in scope that do not have user risk levels set to high in an assigned Conditional Access policy |
| Entra ID Conditional Access policy mfa status |
Name: Entra ID Conditional Access policies do not protect all privileged users with multi-factor authentication (MFA) Default scope: Privileged users
|
Administrators have increased access to the environment. Due to the power accounts with privileged roles have, they should be treated with special care. One common method to improve the protection of privileged accounts is to require a stronger form of account verification for sign-in, like requiring multifactor authentication. Remediation: Improve protection by requiring multi-factor authentication (MFA) for the listed directory roles. The conditional access policy is not required if a conditional access policy that requires MFA has been created for all users. Enable a Conditional Access policy for the tenant that has “Users or workload identities” set to include the directory roles:
“Target resources” set to "All cloud apps", “Access controls” set to “Grant access, Require multi-factor authentication” Organizations with Security Defaults enabled will enforce MFA for privileged roles without requiring a Conditional Access policy.
|
Entra ID user accounts in scope that do not have require multi-factor authentication enabled in an assigned Conditional Access policy |
| Entra ID Conditional Access token protection |
Name: Entra ID Conditional Access policies do not require token protection for sign-in sessions for users Default scope: All users
|
Token protection attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When a token is stolen, by hijacking or replay, it can be used to impersonate the victim until the token expires or is revoked. Token theft is considered a relatively rare event but can inflict significant damage. Token protection creates a cryptographically secure tie between the token and the device (client secret) it is issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device. Remediation: Requires a Microsoft Entra ID P2 license. Token protection is only supported with some Windows devices and a limited set of applications. Review the requirements and known limitations to confirm if token protection is appropriate for users in the organization. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection The setting to require token protection is located in “Session”, “Require token protection for sign-in sessions”. |
Entra ID user accounts in scope that do not have token protection for sign-in sessions enabled in an assigned Conditional Access policy |
The following table describes the vulnerabilities identified in the pre-defined Entra Discovery for Discovery.
|
|
NOTE: Discovery techniques are used by adversaries to avoid detection. Evasion techniques include hiding malicious code within trusted processes and folders, encrypting or obfuscating adversary code, or disabling security software. |
| Vulnerability Template | Vulnerability | Risk | What to find |
|---|---|---|---|
| User password last changed |
Name: Entra ID privileged role members whose passwords have not changed recently Default Scope: All Users
|
While it is not necessary to require mandatory periodic password resets, organizations should be aware of the password age of users that are members of Microsoft Entra built-in privileged roles. Remediation: Ensure that privileged role members have update their password to satisfy the organization’s password policy. |
Users that are members of privileged roles that have not updated their password within last 90 days NOTE: The number of days is editable. |
The following table describes the vulnerabilities identified in the pre-defined Entra Discovery for Initial Access.
|
|
NOTE: Initial Access techniques are used by adversaries to obtain a foothold within a network, such as targeted spear-phishing, exploiting vulnerabilities or configuration weaknesses in public-facing systems. |
| Vulnerability Template | Vulnerability | Risk | What to find |
|---|---|---|---|
| Entra ID tenant security defaults status | Name:
Security defaults are enabled
Default scope: N/A |
Enabling security defaults is recommended for organizations that are using the free tier of Microsoft Entra ID licensing and want to increase their security posture. Organizations with premium Entra ID licensing should use Conditional Access polices for more granular control to achieve a higher security posture. Remediation If the organization is using the free tier of Microsoft Entra ID licensing, continue using security defaults. If the organization is using Microsoft Entra ID P1 or P2 licenses, continue using security defaults while the deployment of Conditional Access policies is planned. When security defaults are disabled, organizations should immediately enable Conditional Access policies to protect the organization. These policies should include at least those policies in the secure foundations category of Conditional Access templates. Organizations with Microsoft Entra ID P2 licenses that include Microsoft Entra ID Protection can expand on this list to include user and sign in risk-based policies to further strengthen the posture. |
Entra ID tenants in scope that have security defaults enabled |
| Entra ID Guest account last used |
Name: Entra ID guest user accounts that are inactive Default scope: All users |
When external partners no longer access your tenant, the guest accounts may become stale and vulnerable to attack. Remediation: Review inactive guest users, block them from signing in, and delete them from the directory. |
Entra ID user accounts in scope that were last used more than 90 days ago NOTE: The number of days is editable.
|
| Entra ID Microsoft Authenticator number matching and additional contexts status |
Name: Entra ID Microsoft Authenticator policy does not require geographic location and application name contexts for all users Default scope: All users |
Microsoft has added features for strong multifactor authentication (MFA to help reduce MFA fatigue attacks and accidental MFA approvals. Remediation: In Authentication methods, enforce the use of Microsoft Authenticator passwordless push notifications with show geographic location context and show application name context. |
Entra ID user accounts in scope that do not have the Microsoft Authenticator policy assigned with geographic location and application name enabled |
| Entra ID users synchronized from Active Directory status |
Synchronized Active Directory user is assigned an Entra ID privileged role Default scope: All users
NOTE: If no Active Directory collection is available, an Inconclusive message is returned. |
Active Directory is considered less secure than Entra ID. By assigning an Entra ID Privileged role to a synchronized on-premises Active Directory user, attackers have a clear pathway to take over Entra ID if Active Directory is compromised. Remediation: Microsoft recommends using cloud-only accounts for Microsoft Entra ID privileged roles. Remove synchronized Active Directory user accounts from direct and indirect membership of privileged roles. Active Directory users that require privileged access to Entra ID should be provided with a separate cloud-only Entra ID account. |
Entra ID users in scope that are synchronized Active Directory users |
| Entra ID User consent for applications setting |
Name: Entra ID users are allowed to consent for all applications Default scope: All tenants selected at the time an Assessment is created
|
Before an application can access an organization's data, a user must grant the application permissions. Different permissions allow different levels of access. By default, all users are allowed to consent to applications for permissions that don't require administrator consent. To reduce the risk of malicious applications being granted access to the organization’s data by users, it is recommended that users can only consent to applications that have been published by a verified publisher. Remediation: Sign in to the Microsoft Entra admin center as a Global Administrator. Browse to Identity | Applications | Enterprise applications | Consent and permissions | User consent settings. Under User consent for applications, select “Allow user consent for apps from verified publishers, for selected permissions”. Alternatively, if appropriate, “Do not allow user consent” can be selected. |
Entra ID tenants in scope that have “User consent for applications” set to allow user consent for apps |
| Entra ID Conditional Access Continuous Access Evaluation strictly enforce location |
Name: Entra ID Conditional Access policies do not protect all users with strictly enforce location for Continuous Access Evaluation Default scope: All users
|
Strictly enforce location is an enforcement mode for Continuous Access Evaluation that is configured in Conditional Access policies. This mode provides protection by immediately stopping access if the IP address detected by the resource provider isn't allowed by Conditional Access policy. This option is the highest security setting for Continuous Access Evaluation. Remediation: Implementing strictly enforce location for Continuous Access Evaluation requires that administrators understand the routing of authentication and access requests in their network environment. Policies like this one should be tested with a subset of users and applied cautiously. The setting to strictly enforce location for Continuous Access Evaluation is located in “Session”, “Customize continuous access evaluation”, “Strictly enforce location policies”. |
Entra ID user accounts in scope that do not have Continuous Access Evaluation strictly enforce location enabled in an assigned Conditional Access policy |
| Entra ID Conditional Access policy mfa status |
Name: Entra ID Conditional Access policies do not protect all non-privileged users with multi-factor authentication (MFA) Default scope: All except Privileged users
|
Attackers frequently target end users. After attackers gain entry, additional access to privileged information can be requested for the exposed account. Attackers can also download other data such as the entire directory to do a phishing attack on the organization. Remediation: Improve protection by requiring multi-factor authentication (MFA) for all users. Enable a Conditional Access policy for the tenant that has: “Users” set to include “All users” and exclude emergency access or break-glass accounts. In “Target resources”, “Cloud apps” set to include “All cloud apps”. In “Access controls” “Grant”, set “Grant access” to “Require multifactor authentication” Organizations with Security Defaults enabled will enforce MFA for all users in some situations (based on factors such as location, device, role, and task) without requiring a Conditional Access policy. NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:
|
Entra ID user accounts in scope that do not have require multi-factor authentication enabled in an assigned Conditional Access policy |
| Entra ID tenant on-premises synchronization time |
Name: Synchronization with on-premises Active Directory is delayed Scope: All tenants selected at the time an Assessment is created
NOTE: If no Active Directory collection is available, an Inconclusive message is returned. |
Delays in synchronization with on-premises Active Directory can be due to misconfiguration or issues with the Microsoft Entra Connect server. Remediation: Login to Microsoft Entra Connect Health and review any potential sync errors. |
Entra ID tenants in scope that have not synchronized with on-premises Active Directory in 12 hours. |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Termini di utilizzo Privacy Cookie Preference Center
