Chatee ahora con Soporte
Chat con el soporte

Security Guardian Current - User Guide

Introducing Quest Security Guardian Using the Dashboard Tier Zero Objects Privileged Objects Assessments Findings Security Settings Appendix - Security Guardian Indicator Details

Discovery for Privilege Escalation Vulnerabilities

Vulnerability Template Vulnerability Risk What to find
 

Name:

Computer accounts with non-default Primary Group IDs Default scope: All computers

Computer accounts whose Primary Group IDs have been modified may have elevated privileges which are difficult to see and therefore easier to exploit within detection.

Remediation:

  • The Primary Group ID should be reset to its default value. The default primary group for computer accounts is:

  • "Domain Computers" (515)

  • for domain controller accounts, "Domain Controllers" (516)

  • for read-only domain controllers, "Read-only Domain Controllers" (521).

Accounts in scope that have a “Primary Group” that is not Domain Computers or Domain Controllers or Read-Only Domain Controllers
Users Service Principal Name status

Name:

Tier Zero user accounts with Service Principal Names

Default scope:

Tier Zero users

Tier Zero user accounts with Service Principal Names (SPNs) defined are exposed to Kerberos-based authentication attacks, enabling an adversary to escalate their privileges within the directory.

Remediation:

To resolve vulnerability, remove the Service Principal Name from the user object, if possible. If the Service Principal Name cannot be removed, enforce a very strong password on the user object which contains 32 characters with upper case, lower case, numeral, and special characters.

User accounts in scope that have “Service Principal Name” not empty
Number of Tier Zero user accounts

Name:

Abnormally large number of Tier Zero user accounts in the domain

Default scope:

N/A

The number of Tier Zero accounts in a domain should be limited and closely monitored. An abnormally high number of Tier Zero accounts could indicate loose permissioning or group nesting which should be addressed. Tier Zero user accounts are being evaluated for this vulnerability.

Remediation:

To resolve vulnerability, identify accounts that should not have Tier Zero user credentials and remove those credentials. Resolve any group nesting issues.

Total number of Tier Zero user accounts within a domain is more than 20
Account SID History status

Name: Tier Zero user accounts with SID History populated

Default scope: Tier Zero users

If a user account's sIDHistory attribute is populated, then the account has all the privileges that belong to the SID History as well. Tier Zero user accounts with SID History are particularly concerning as they may have more privilege than is visible and likely indicates an adversary has compromised the account and established a backdoor for persistence.

Remediation:

To resolve vulnerability, remove the references in SID History if the user no longer requires the permissions assigned to the security groups listed. If the permissions are required, add the permission or group membership directly to the user object.

Accounts in scope that have SID History not empty

Name:

Tier Zero groups with SID History populated

Default scope: Tier Zero groups

If a group's sIDHistory attribute is populated, the group members have the privileges that belong to the SID History as well. Tier Zero groups with SID History are particularly concerning as they may have more privilege than is visible and likely indicates an adversary has compromised the account and established a backdoor for persistence.

Remediation:

To resolve vulnerability, remove the references in sIDHistory if the group no longer requires the permissions assigned to the security groups listed. If the permissions are required, add the permission or group membership directly to the group object.

Account SID History local SID status

Name:

User accounts with SID from local domain in their SID History

Default scope:

All users

If a user account's sIDHistory attribute is populated, the account has all the privileges that belong to the SID History as well. While user accounts that were previously migrated may have a SID History from an external domain, the presence of a SID from the same domain is an indication an adversary has compromised the account and granted themselves more privilege than is immediately visible.

Remediation:

To resolve vulnerability, immediately remove the local SID from the compromised user's sIDHistory attribute and investigate who modified the attribute and when.

Accounts in scope that have SID from local domain in their SID History

Name:

Groups with SID from local domain in their SID History

Default scope:

All groups

If a group account's sIDHistory attribute is populated, the group members have all the privileges that belong to the SID History as well. While group accounts that were previously migrated may have a SID History from an external domain, the presence of a SID History from the same domain is an indication an adversary has compromised the account and granted themselves more privilege than is immediately visible.

Remediation:

To resolve vulnerability, immediately remove the local SID from the compromised group's sIDHistory attribute and investigate who modified the attribute and when.

User account status

Name:

Tier Zero user account is disabled

Default scope:

Tier Zero users

 

The number of Tier Zero accounts in a domain should be limited and closely monitored. A Tier Zero account that is disabled but still contains privileges through Tier Zero group membership can be compromised by an adversary and used to elevate privileges.

Remediation:

Remove Tier Zero group membership from user accounts that are disabled.

Users in scope that are disabled
Group Members Count

Name:

Default Active Directory groups which should not be in use contain members

Default scope:

Account Operators

Backup Operators

Cryptographic Operators

Hyper-V Administrators

Network Configuration Operators

Print Operators

Remote Desktop Users

Replicator

Server Operators

Default Active Directory groups have elevated privileges and indirect control over vital aspects of Active Directory. These groups should typically have no members, so the presence of any memberships is a possible sign of an adversary using the group to elevate their privileges.

Remediation:

Remove the members within default Active Directory groups:

  • Account Operators
    (S-1-5-32-548)

  • Backup Operators
    (S-1-5-32-551)

  • Cryptographic Operators
    (S-1-5-32-569)

  • Hyper-V Administrators*
    (S-1-5-32-578)

  • Network Configuration Operators
    (S-1-5-32-556)

  • Print Operators
    (S-1-5-32-550)

  • Remote Desktop Users
    (S-1-5-32-555)

  • Replicator
    (S-1-5-32-552)

  • Server Operators
    (S-1-5-32-549)

* NOTE: The Hyper-V Administrators group may have members If a Hyper-V environment is used.

Groups in scope that have more than 0 members

NOTE: The operator and number of days are editable.

Schema Admins Group Member Count

Name:

Schema Admins group contains members

Default scope:

N/A

Schema Admins group has elevated privileges and indirect control over vital aspects of Active Directory. This group should typically have no members, so the presence of any memberships is a possible sign of an adversary using the group to elevate their privileges.

Remediation:

Remove the members within Schema Admins.

Schema Admins group has more than 0 members

 

NOTE: The operator and number of days are editable.

Non-members of protected groups adminCount attribute value

Name:

Ordinary user accounts with hidden privileges (SDProp)

Default scope:

All users

Microsoft uses the adminCount attribute to indicate an object has had its ACL modified by the system to be more secure as it was a member of one of the administrative groups. An adversary who has breached the directory may try to remain undetected by removing accounts they leveraged to escalate their privileges, and the admincount attribute is evidence of that cover-up. Protected groups include:

  • Account Operators
    (S-1-5-32-548)
  • Administrators
    (S-1-5-32-544)
  • Backup Operators
    (S-1-5-32-551)
  • Cert Publishers
    (S-1-5-21-<domain>-517)
  • Domain Admins
    (S-1-5-21-<domain>-512 )
  • Domain Controllers
    (S-1-5-21-<domain>-516 )
  • Enterprise Admins
    (S-1-5-21-<root_domain>-519)
  • Read-only Domain Controllers
    (only since Windows Server 2008)
    (S-1-5-21-<domain>-521)
  • Replicator
    (S-1-5-32-552)
  • Schema Admins
    (S-1-5-21-<root_domain>-518 )
  • Server Operators
    (S-1-5-32-549)

Remediation:

Investigate accounts that are not members of the protected groups whose adminCount attribute is set to 1 to determine if the user account was recently removed from a protected group and that action was expected. The adminCount attribute should then be manually set back to 0 in the Attribute Editor tab of the user object.

User objects in scope that are not members of protected groups and have adminCount attribute set to 1
Verify group membership of DnsAdmins group

Name:

DnsAdmins group contains members

Default scope:

All users

DNS is an appealing target for adversaries as it can be used to redirect domain queries or launch a denial of service. Members of the DnsAdmins group which are not highly Tier Zero Active Directory administrators are suspicious and increase the attack surface.

Remediation:

Review the members of the DnsAdmins group, determine if any members are not highly Tier Zero Active Directory administrators, and remove them if appropriate.

DnsAdmins group has more than 0 members
Anonymous Logon and Everyone groups are members of Pre-Windows 2000 Compatible Access group

Name:

Anonymous Logon and Everyone groups are members of the Pre-Windows 2000 Compatible Access group

Default scope:

N/A

The default permissions on many AD objects are set to allow access to the Pre-Windows 2000 Compatible Access group. If wide-open groups such as Everyone (S-1-1-0) or Anonymous Logon (S-1-5-7) are members of the Pre-Windows 2000 Compatible Access group, it creates exposure for an adversary to escalate their privileges.

Remediation:

Remove wide open groups Everyone (S-1-1-0) and Anonymous Logon (S-1-5-7) from the Pre-Windows 2000 Compatible Access group (S-1-5-32-554).

 

Pre-Windows 2000 Compatible Access group contains Anonymous Logon and Everyone groups
Tier Zero user account ownership

Name:

Tier Zero users owned by non-Tier Zero accounts

Default scope: N/A

The owner of an object can take control over the object and have all of its permissions. A non-Tier Zero user having ownership over a Tier Zero account can be evidence of tampering and represents an abusable attack path for an adversary.

Remediation:

Remove the non-Tier Zero user ownership on the Tier Zero user account and investigate who modified the owner and when.

Tier Zero user accounts that are owned by a non-Tier Zero account
Tier Zero computer account ownership

Name:

Tier Zero computer is owned by a non-Tier Zero account

Default scope:

N/A

 

Remediation:

Update the owner of the Domain Controller to the Domain Admins group or update other Tier Zero computers to Tier Zero owners.

Tier Zero computer accounts that are owned by a non-Tier Zero account
Account password last changed

Name:

Tier Zero computer accounts that have not cycled their password recently

Default scope:

Tier Zero computers

Tier Zero computers such as domain controllers will change their computer account password periodically (30 days by default). Domain controllers that have older password could be offline and susceptible to having password hashes stolen or used to introduce nefarious changes to the directory.

Remediation:

The reason that prevents servers from changing their password should be investigated. Verify if the computer is offline. If online, check the values of the following registry entries:

  • HKLM\System\CurrentControlSet\
    Services\Netlogon\Parameters\
    DisablePasswordChange must be 0 or not exist

  • HKLM\System\CurrentControlSet
    \Services\Netlogon\Parameters
    \MaximumPasswordAge should be 30

If these values are incorrect, they should be reset to the default values and ensure that they are not set by a GPO.

Accounts in scope that have not updated its password within last 30 days.

 

NOTE: The number of days is editable.

Group Policy "Recovery console: Allow automatic administrative logon" setting

Name:

Tier Zero Group Policy allows Recovery mode to be not password-protected

Default scope:

Tier Zero Group Policies

An unprotected Recovery Mode allows an adversary with physical access to a domain controller the ability to gain access to the Active Directory database.

Remediation:

Configure the "Recovery console: Allow automatic administrative logon" setting located in “Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Security Options” section of the Group Policy to “disabled”

Group Policy objects in scope "Recovery console: Allow automatic administrative logon" is enabled
Tier Zero computer Group Policy "Allow log on” settings

Name:

Non-Tier Zero accounts are able to log onto Tier Zero computers

Default scope: All except Tier Zero users, groups and computers

If a non-Tier Zero user is able to log onto a Tier Zero computer, such as a Domain Controller, locally or by remote session, they can execute code or obtain a copy of all password hashes.

Remediation:

Prevent non-Tier Zero users from logging into Tier Zero computers by removing the "Allow log on locally" and "Allow log on through Remote Desktop Services" rights for any non-Tier Zero group. These settings are located in Computer configuration - Policies - Windows Settings - Security Settings - Local Policies - User Rights Assignment.

Accounts in scope added to Allow log on locally or Allow log on through Remote Desktop Services in Tier Zero Group Policy
Non-Tier Zero Group Policy "Deny log on” for Domain Admin status

Name:

Domain Admins can log into computers with non-Tier Zero Group Policy

Default scope:

All except Tier Zero Group Policies

When a Tier Zero account logs into a non-Tier Zero computer, their password hash remains in memory and can be harvested by an adversary. If Group Policies do not prevent Domain Admin logons to lower tiers, Tier Zero credentials could be exposed.

Remediation:

Restrict logons to all non-Tier Zero computers for Domain Admins by configuring the "Deny log on locally" and "Deny logon through Remote Desktop Services" in the Group Policy. These settings are located in Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - User Rights Assignment.

Group Policies in scope that do not have Domain Admins group added to the Deny log on locally or Deny log on through Remote Desktop Services setting

DNS zone dynamic updates status

NOTE: For vulnerabilities that use this template, the hybrid agent service account must be a member of the Domain Admins group.

Name:

DNS zone configuration allows anonymous record updates

Default scope:

N/A

Dynamic DNS records are created by DNS clients or systems on behalf of DNS clients (Example: DHCP servers). On Microsoft DNS servers, there are three possible configurations for dynamic updates: "None", "Nonsecure and secure", "Secure only". The "Nonsecure and secure" setting allows dynamic updates to be accepted without checking if the source of updates is trusted or not. DNS zones configured to allow anonymous record updates can be exploited by adversaries to receive incoming queries and harvest credentials.

Remediation:

If enabling dynamic updates is required for an organization, it is highly recommended to use “Secure only” dynamic updates option which ensures dynamic updates are accepted only from trusted sources. This option is available only if your primary DNS zone is hosted on a domain controller and is an AD-integrated DNS zone.

DNS zone dynamic updates set to Nonsecure and secure
Computer Resource-Based Constrained Delegation status

Name:

Tier Zero computer can be compromised through Resource-Based Constrained Delegation

Default scope:

Tier Zero computers

If Kerberos Resource-Based Constrained Delegation (RBCD) is enabled on a Tier Zero computer such as a domain controller, an adversary can leverage this to elevate from a system under their control to a Tier Zero computer and take effective control over the entire domain.

Remediation:

To resolve vulnerability, in the impacted computer’s Delegation tab, select “Do not trust this computer for delegation”.

The following PowerShell command can be used to verify the account that has Resource-Based Constrained Delegation against the impacted computer account (Note: The “Identity” portion of the command will need to be updated to reflect the display name of the computer account being checked):

Get-ADComputer -Identity <computer>
-Properties PrincipalsAllowedToDelegateToAccount

Computer accounts in scope that have Resource-Based Constrained Delegation configured

Name:

Non-Tier Zero computer can be compromised through Resource-Based Constrained Delegation

Default scope:

All except Tier Zero computers

If Kerberos Resource-Based Constrained Delegation (RBCD) is enabled on a computer, an adversary can leverage this to elevate from a system under their control to another system it has delegation.

Remediation:

To resolve vulnerability, in the impacted computer’s Delegation tab, select “Do not trust this computer for delegation”.

The following PowerShell command can be used to verify the account that has Resource-Based Constrained Delegation against the impacted computer account (Note: The “Identity <computer>” portion of the command will need to be updated to reflect the display name of the computer account being checked):

Get-ADComputer -Identity <computer> -Properties PrincipalsAllowedToDelegateToAccount

Domain Write Group Policy Object link delegation

Name:

Non-Tier Zero accounts can link GPOs to the domain

Default scope:

All except Tier Zero users and groups

 

 

Group Policies are an effective attack path as they can be used to weaken directory-wide security or deploy payloads. If an adversary gains the ability to link a Group Policy Object (GPO) at the domain level they can effectively take over the entire domain.

Remediation:

These delegations should be removed for any non-Tier Zero account unless there is a compelling reason for their existence.

Domain has the “Write gPLink” set to Allow for any accounts in scope
Domain promote a computer to a domain controller delegation

Name:

Non-Tier Zero accounts that can promote a computer to a domain controller

Default scope:

All except Tier Zero users and groups

 

The "Add/remove replica in domain" permission on the domain coupled with the SERVER_TRUST_ACCOUNT attribute in userAccountControl can allow an adversary to promote any computer they reach to a domain controller. This would allow them to move laterally across the directory and take advantage of DC-based attacks to harvest credentials.

Remediation:

The "Add/remove replica in domain" delegation should be removed from any non-Tier Zero account unless there is a compelling reason for its existence.

Domain has “Add/remove replica in domain” set to Allow for any account in scope
Active Directory Site Write gPLink delegation

Name:

Non-Tier Zero accounts can link Group Policy Objects to an Active Directory site

Default scope:

All except Tier Zero users and groups

 

Group Policies are an effective attack path as they can be used to weaken directory-wide security or deploy payloads. If an adversary gains the ability to link a Group Policy Object (GPO) to an Active Directory site, they can directly control all objects it contains.

Remediation:

These delegations should be removed unless there is a compelling reason for their existence.

Active Directory Site has “Write gPLink” set to Allow for any accounts in scope
Domain Controller OU Write gPLink delegation

Name:

Non-Tier Zero accounts can link Group Policy Objects to Domain Controller OU

Default scope:

All except Tier Zero users and groups

 

 

Group Policies are an effective attack path as they can be used to weaken directory-wide security or deploy payloads. If an adversary gains the ability to link a Group Policy Object (GPO) to the Domain Controller OU they can directly control the domain controllers.

Remediation:

These delegations should be removed unless there is a compelling reason for their existence.

Domain Controllers OU has “Write gPLink” set to Allow for any accounts in scope
Computer account group membership status

Name:

Tier Zero groups that have computer accounts as members

Default scope:

Tier Zero groups

 

If a computer account is a member of a Tier Zero group, an adversary who compromises the computer will also elevate their privileges to the Tier Zero group the computer belongs to.

Vulnerable objects will not be returned when any computer is a member of Cert Publishers or when a DC or RODC is a member of Domain Controllers, Enterprise Domain Controllers, Read-only Domain Controllers, or Enterprise Read-only Domain Controllers.

Remediation:

Review computer account Tier Zero group membership to determine if the computer should be a member of the Tier Zero group. If not required, remove the account from the group.

 

 

Groups in scope that have computer accounts as members
KRBTGT account resource-based constrained delegation status

Name:

KRBTGT accounts with Resource-Based Constrained Delegation

Default scope:

N/A

Any delegations against the KRBTGT accounts are highly suspicious. If an adversary gains control over the KRBTGT account, they can use this to take control over the entire directory.

Remediation:

To resolve vulnerability, in the KRBTGT account’s Account tab, check “Account is sensitive and cannot be delegated.” The following PowerShell command can be used to verify the account that has Resource-Based Constrained Delegation against the KRBTGT account (Note: The “Identity KRBTGT” portion of the command will need to be updated to reflect the name of the KRBTGT account being checked): Get-ADuser -Identity KRBTGT -Properties PrincipalsAllowedToDelegateToAccount

KRBTGT accounts that have Resource-Based Constrained Delegation configured
Domain trust configured insecure status

Name:

Domain trust configured insecurely

Default scope:

Dependent on the domain(s) selected when an Assessment is created. If a selected domain does not have a trust relationship, it will not be assessed for the vulnerability.

Trusts that have insecure settings are exposed to Kerberos-based authentication vulnerabilities or reduced protection against imposter identities.

  • A domain trust is considered insecure if it has the trustAttribute TRUST_ATTRIBUTE_CROSS_ORGANIZATION_ENABLE_
    TGT_DELEGATION (0x00000800) bit enabled.

  • A domain trust is considered insecure if it has the trustAttribute TRUST_ATTRIBUTE_PIM_TRUST (0x00000400) bit set.

Remediation:

  • Evaluate if EnableTgtDelegation is required and, if not, disable it on your domain trust.

  • Evaluate if EnablePIMTrust is required and, if not, disable it on your domain PAM trust.

Domain trust in scope has EnableTgtDelegation or EnablePIMTrust configured in the trustAttribute
Active Directory group existence in domain Name:

Suspicious ESX Admins group detected in domain

Default scope:

ESX Admins

Microsoft has identified vulnerability CVE-2024-37085 where ESXi hypervisors can be exploited by several ransomware operators to obtain full administrative permissions on domain-joined ESXi hypervisors. A threat actor can create a group named “ESX Admins” in the domain and add users to it, which will grant full administrative access on the ESXi hypervisor. “ESX Admins” group is not a built-in group in Active Directory and does not exist by default. ESXi hypervisors do not validate that the group exists when the server is joined to a domain but considers any members of a group with this name as having full administrative access, even if the group did not originally exist. The membership in the group is determined by group name and not by security identifier (SID).

Remediation

Ensure the latest security updates released by VMware are installed on all domain-joined ESXi hypervisors. If installing software updates is not possible, perform the following to reduce the risk:

Validate the group “ESX Admins” exists in the domain and is hardened.

Manually deny access by this group by changing settings in the ESXi hypervisor. If full admin access for the Active Directory ESX admins group is not desired, disable this behavior using the advanced host setting: ‘Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd’.

Change the admin group to a different group in the ESXi hypervisor.

Active Directory group in scope is detected
Account ability to specify a certificate subjectAltName (SAN) in a certificate request

Name:

Non-Tier Zero account can use a misconfigured certificate template to impersonate any user

Default scope:

All except Tier Zero users and groups

 

Certificate template settings determine the characteristics for the derived certificates and the parameters required for a certificate request. A certificate template is considered “misconfigured” if the combination of settings defined can expose an organization to an attacker. A certificate template that meets the following criteria will allow a non-Tier Zero attacker to request a certificate that can be used to authenticate to the domain as a Tier Zero user: Subject Name set to “Supply in the request”, “CA certificate manager approval” is not required, “Authorized signatures” is not required, Extended Key Usage (EKU) facilitates authentication, non-Tier Zero account can enroll (or can grant themselves permission to enroll) in a certificate.

Remediation:

Configure the certificate template Subject Name setting to “Build from this Active Directory information” and set the Issuance Requirements to require “CA certificate manager approval”. In addition, ensure non-Tier Zero accounts do not have Enroll or Full Control permissions granted on the certificate template. It is also recommended that the certificates issued by the certificate authority be reviewed to confirm if the identified non-Tier zero account requested a certificate using the misconfigured certificate template and what Subject Name is used in the request.

Accounts in scope can request a certificate that allows the subjectAltName (SAN) to be specified
Account ability to request an overly permissive certificate with privileged EKU

Name:

Non-Tier Zero account can request an overly permissive certificate with privileged EKU (ESC2)

Default scope:

All except Tier Zero users and groups

Certificate template settings determine the characteristics for the derived certificates and the parameters required for a certificate request. A certificate template is considered “overly permissive” if the combination of settings defined can expose an organization to an attacker. A certificate template that has either no Extended Key Usage (EKU) defined or has the EKU “Any Purpose” is considered privileged.

Remediation:

Ensure non-Tier Zero accounts do not have Enroll or Full Control permissions granted on the certificate template. It is also recommended to enforce extra security such as like adding Manager approval and signing requirements, if possible.

Accounts in scope can request a certificate that has either no EKU defined or has the “Any Purpose” EKU

Discovery for Reconnaissance Vulnerabilities

The following table describes the vulnerabilities identified in the pre-defined Active Directory Discovery for Reconnaissance.

Vulnerability Template Vulnerability Risk What to find
Domain Functional level

Name:

Domain with obsolete domain functional level

Default scope:

N/A

Active Directory domains configured for a legacy functional level (Windows Server 2012 or earlier) lack the most recent security feature to secure the environment.

Remediation:

Raise the functional level of a domain to upgrade the features that are available within the domain. The domain controller is required to run on the Windows Server version that is compatible with the functional level. Note: If you have multiple domain controllers, make sure the oldest Windows Server version used is compatible with the functional level.

Domain functional level Windows Server 2012 or earlier

Pre-Defined Entra ID Discoveries

Quest Security Guardian comes with the following pre-defined Discoveries for Entra ID vulnerabilities.

NOTE: "System" displays in the Created By field of the Discoveries list when a Discovery type is pre-defined.

Discovery Type Description
Entra ID Credential Access Techniques deployed by adversaries on systems and networks to steal usernames and credentials for re-use.
Entra ID Discovery Techniques used by adversaries to obtain information about systems and networks that they are looking to exploit or use for their tactical advantage.
Entra ID Initial Access Techniques used by adversaries to obtain a foothold within a network, such as targeted spear-phishing, exploiting vulnerabilities or configuration weaknesses in public-facing systems.
Entra ID Persistence Techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access.
Entra ID Privilege Escalation Techniques used by adversaries to gain higher-level privileges on a system, such as local administrator or root.

Assessments that Require a Premium License

The following Entra ID Discoveries require a Premium License. If the organization has a free license, results 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)

 

 

 

 

Discovery for Entra ID Credential Access Vulnerabilities

The following table describes the vulnerabilities identified in the pre-defined Entra Discovery for Credential Access.

 

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:

  • Emergency access or break-glass accounts (to prevent tenant-wide account lockout),

  • Service accounts and service principals (non-interactive accounts normally used by back-end services which cannot programmatically complete MFA).

 

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.

  • In “Target resources”, “Cloud apps” set to include "All cloud apps”.

  • In “Access controls” “Grant”, set “Grant access” to “Require multi-factor authentication”.

  • In "Session", set "Sign-in frequency” to “Every time”.

  • In Conditions, select “Sign-in risk”, set “Configure” to Yes.

  • Under “Select the sign-in risk level this policy will apply to”, select “High” and “Medium” options.

NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:

  • Emergency access or break-glass accounts (to prevent tenant-wide account lockout).

  • Service accounts and service principals (non-interactive accounts normally used by back-end services which cannot programmatically complete MFA).

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:

  • Emergency access or break-glass accounts (to prevent tenant-wide account lockout),

  • Service accounts and service principals (non-interactive accounts normally used by back-end services which cannot programmatically complete MFA).

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:

  • Global Administrator

  • Application Administrator

  • Authentication Administrator

  • Billing Administrator

  • Cloud Application Administrator

  • Conditional Access Administrator

  • Exchange Administrator

  • Helpdesk Administrator

  • Password Administrator

  • Privileged Authentication Administrator

  • Privileged Role Administrator

  • Security Administrator

  • SharePoint Administrator

  • User Administrator

“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
Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación