Threat definitions

If a threat actor gains control of a root CA trusted by Azure AD, they can impersonate any user without knowing their password. Configuring Certificate-Based Authentication and impersonating a Global Admin doesn't require Global Admin rights. The threat actor might use this technique to elevate their privileges without being noticed.

Apps that request risky permissions present a threat to Azure AD tenants. Threat actors can use such apps to gain prolonged, covert access to sensitive information such as contacts, emails, mailbox settings, user directories, and files. With write permissions, a threat actor can modify the environment and cause damage or establish persistence. Microsoft describes the consent grant attack in the following steps:

• An attacker registers an app with an OAuth 2.0 provider, such as Azure AD.
• The app is configured to appear legitimate, often by using the name of a popular product in the same ecosystem.
• The attacker obtains a link from users using various techniques, such as email-based phishing or compromising a non-malicious website.
• The user selects the link and sees an authentic consent prompt requesting permission to access data.
• If the user selects 'Accept', the app is granted permissions to access sensitive data.
• The app receives an authorization code, which it redeems for an access token and potentially a refresh token. The access token enables the app to make API calls on behalf of the user.
• If the user accepts, the attacker gains access to the user's emails, files, forwarding rules, contacts, notes, profile, and other sensitive data and resources.

A service principal is an identity that is used by applications or services to access resources in Azure Active Directory. Service principals are created with specific permissions, such as the 'AppRoleAssignment.ReadWrite.All' permission, which allows the service principal to manage role assignments in Azure AD.

This can include promoting itself or other service principals to members of privileged roles, such as administrators or owners. This means that a threat actor who has gained access to a previously created service principal with the 'AppRoleAssignment.ReadWrite.All' permission could use it to persist in the environment and elevate their privileges when needed.

The default value for the ms-DS-MachineAccountQuota attribute is set to 10 in Active Directory, allowing any user to create up to 10 computer accounts associated with their account. While this is a legitimate usage scenario, attackers can exploit this attribute if a compromised user doesn't have 10 actual devices associated with their account. Attackers can create fake computer accounts in Active Directory that are not associated with any real device but can perform authentication requests.

Organizations can reduce the risk of attacks by setting the ms-DS-MachineAccountQuota attribute to 0. This prevents non-admin users from adding new devices to the domain, making it more difficult for attackers to leverage the attribute for their attacks. Attackers would then have to choose more complex methods to acquire a suitable resource for their attacks.

The krbtgt account password in an Active Directory environment is a critical component of the Kerberos authentication protocol, which authenticates users and services. Failing to change the krbtgt password regularly poses significant risks, as an attacker who gains access to it can carry out a range of attacks on the AD infrastructure, including:

• Golden ticket attacks: An attacker who obtains the KRBGTG password can generate a forged Kerberos ticket called a "golden ticket," which grants unrestricted access to any resource in the AD environment. This allows the attacker to impersonate any user or service in the domain and carry out any action they wish.
• Pass-the-hash attacks: The KRBGTG password is used to derive the hash values of other AD account passwords. An attacker who gains access to the KRBGTG password can use it to perform "pass-the-hash" attacks, where they use the hash values of other user passwords to authenticate and access resources in the domain.
• Persistence: An attacker who gains access to the KRBGTG password can use it to create persistent backdoors into the AD environment, making it easier for them to maintain access and carry out further attacks in the future.

To minimize the risk of compromise and ensure the security of the AD infrastructure, it is crucial to change the KRBGTG password regularly.

Unconstrained Kerberos delegation is a mechanism in which a user's credentials are sent to a service to allow the service to access resources on behalf of the user. For this mechanism to work, the service account in Active Directory must be marked as trusted for delegation.

Many modern web applications use unconstrained delegation to delegate the credentials of authenticated users to other services in the Active Directory, such as an SMTP server, file server, database server, or another web server. This allows the application account to delegate credentials to any service it contacts, making it an unconstrained delegation.

• If a threat actor compromises the application, they can use it to act on behalf of other users. For example, if a domain admin is logged in, the site can create a ticket to other services, acting as the domain admin. This allows the site to make changes to the enterprise admin group or acquire the hash of the KRBTGT account. Additionally, the site could download a file.

An account with Kerberos pre-authentication disabled is vulnerable to password-guessing attacks. The Key Distribution Center (KDC) is a component of the domain controller that performs two essential functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). By default, the KDC requires all accounts to use pre-authentication, which is a security feature that protects against password-guessing attacks.

When pre-authentication is enabled, a time stamp is encrypted using the user's password hash as an encryption key. If the KDC can decrypt the timestamp using the user's password hash, it knows that the request is not a replay of a previous request. However, when pre-authentication is disabled, a malicious actor can send a dummy request for authentication, and the KDC will return an encrypted TGT that can be brute-forced offline.

It is crucial to enable pre-authentication on all users. If pre-authentication is disabled, consider reducing the permissions of accounts with disabled pre-authentication. While Kerberos pre-authentication can prevent an active attacker, it does not prevent a passive attacker from sniffing the client's encrypted timestamp message to the KDC. To mitigate this problem, users should use lengthy passwords, and a good password rotation policy should be implemented in the domain to make offline brute-forcing infeasible or increasingly difficult. For more information about Kerberos pre-authentication, refer to this resource: https://social.technet.microsoft.com/wiki/contents/articles/23559.kerberos-pre-authentication-why-it-should-not-be-disabled.aspx

• A redirect URI, also known as a reply URL, is the location where the authorization server sends the user after the app has been authorized and granted an authorization code or access token. It's essential to register the correct redirect URI during the app registration process because the authorization server sends the code or token to this location.
• If an App Service is deleted, but the redirect URI is not deleted from the Azure AD app registration, a threat actor can discover the dangling URI and register the App Service instance. After registering the new App Service instance, the threat actor can obtain user session authorization tokens. This can lead to unauthorized access to sensitive data and resources.

To prevent this type of attack, ensure that you remove unused redirect URIs from Azure AD app registration after deleting the corresponding App Service. Additionally, periodically review app registrations and remove any unused or dangling redirect URIs to reduce the risk of unauthorized access to sensitive data and resources.

An Active Directory object that has privileged SIDs in its sIDHistory attribute could indicate the activities of a threat actor. Security Identifier (SID) is a unique identifier that Active Directory uses to identify objects as security principals in security descriptors and access tokens. Typically, the SID History attribute is only populated with SIDs during migrations. However, threat actors can use a technique called SID History injection to add privileged SIDs to regular accounts and escalate privileges.

For example, adding the Enterprise Admin SID to the SID History of a regular user allows the user account to be elevated to an effective Domain Admin in all domains in the forest. Detecting privileged SIDs in the sIDHistory attribute can help identify potential security breaches and limit the impact of any privilege escalation attacks. Regularly monitoring and auditing the use of privileged SIDs is essential to maintaining the security of Active Directory.

An account of a regular user that is not registered with MFA or uses insecure authentication methods lacks sufficient protection against modern threats. According to a report by Microsoft, multi-factor authentication can block more than 99.9% of account hacking attempts. Multi-factor authentication is a security process that prompts users for an additional form of identification, such as a code on their cellphone or a fingerprint scan, during the sign-in process.

Using only a password to authenticate a user is risky because a malicious actor can easily gain access if they guess a weak password or find it exposed elsewhere. However, requiring a second form of authentication increases security because, in most cases, a malicious actor cannot bypass this additional challenge. By enabling multi-factor authentication, organizations can significantly improve their security posture and protect against various forms of attacks, such as phishing, brute force, and credential stuffing.

Apps with risky permissions can pose a significant threat to your Azure AD tenant. Threat actors can exploit such apps to gain long-term access to sensitive data and resources, such as contacts, mail, notes, mailbox settings, user directory, and files. One of the attack techniques that threat actors use is the consent grant attack.

In this attack, an attacker registers an app with an OAuth 2.0 provider, such as Azure AD. The app is configured in a way that makes it seem legitimate, often using the name of a popular product available in the same ecosystem. The attacker then gets a link directly from users, which may be done through conventional email-based phishing, compromising a non-malicious website, or other techniques.

If the user clicks on the link, they are shown an authentic consent prompt asking them to grant the malicious app permissions to sensitive data. If the user accepts, the app receives an authorization code, which it redeems for an access token, and potentially a refresh token. The access token can be used to make API calls on behalf of the user.

If the user grants the app permissions, the attacker can gain access to the user's sensitive data and resources, such as mails, forwarding rules, files, contacts, notes, profile, and more. To mitigate the risk of such attacks, organizations should regularly review and monitor their Azure AD apps and permissions, educate users about the risks of granting permissions to unknown apps, and enforce the principle of least privilege to limit access to sensitive data and resources.