Introduction

In the first post of the top things that you might not be doing (yet) in Entra Conditional Access, we focused on basic but essential security controls that I recommend you checking out if you do not have them implemented already. In this second part, we’ll go over more advanced security controls within Conditional Access that, in my experience, are frequently overlooked in environments during security assessments. However, they can help you better safeguarding your identities.

Similar to my previous blog post, the list of controls provided here is not exhaustive. The relevance of each control may vary depending on your specific environment. Moreover, you should not rely on those only, but instead investigate whether they would bring any value in your environment. I also encourage you to check out other Conditional Access controls available to make sure your identities are correctly protected.

This article focusses on features that are available in Entra ID Premium P1 and P2 licenses. Therefore, if none of those licenses are available, check my previous blog post on how to protect identities in Entra ID Free: https://blog.nviso.eu/2023/05/02/enforce-zero-trust-in-microsoft-365-part-1-setting-the-basics/. Note that other licenses could also be required depending on the control.

Additionally, should you need any introduction to what Entra Conditional Access is and which security controls are available, feel free to have a look at this post: https://blog.nviso.eu/2023/05/24/enforce-zero-trust-in-microsoft-365-part-3-introduction-to-conditional-access/.

Finally, if you have missed part 1, feel free to check it out: https://blog.nviso.eu/2024/02/27/top-things-that-you-might-not-be-doing-yet-in-entra-conditional-access/.

Entra Conditional Access security controls

Make sure all Operating Systems are covered in your current Conditional Access design

License requirement: Entra ID Premium P1

When performing Entra Conditional Access assessments, we usually see policies to enforce controls on Windows, and sometimes Android and iOS devices. However, other platforms such as MacOS, Windows Phone, and Linux are sometimes forgotten. This can represent a significant gap in your overall security defense as access from those platforms is not restricted by default. You could use all the Conditional Access policy features, but if you do not include them, all your effort will be in vain.

Indeed, it is well known from attackers that “nonstandard” platforms are sometimes forgotten in Conditional Access. By trying to access your environment using them, they might be able to simply bypass your Conditional Access (CA) policies. It is therefore necessary to make sure that your security controls are applied across all operating systems.

The next points will shed some light on controls that you can implement to support all platforms.

Don’t be afraid of blocking access, but only in a considered and reasonable way

License requirement: Entra ID Premium P1

Based on our numerous assessments over the years, we have observed that ‘Block’ policies are typically not implemented in Conditional Access. While those policies can definitely have an adverse impact on your organization and end users, specific actions, device platforms, or client applications (see part 1), should be blocked.

For example, if you do not support Linux in your environment, why not simply block it? Moreover, if Linux is only required for some users, Conditional Access allows you to be very granular by targeting users, devices, locations, etc. Therefore, platforms can be blocked for most use cases, and you can still allow specific flows based on your requirements. This principle can be extended to (guest) user access to applications. Should guest users have access to all your applications? No? Then, block it. Such control effectively decreases the overall attack surface of your environment.

I highly recommend you giving a thought to ‘Block’ policies. Moreover, they could be extended to many other scenarios on top of the device platforms and (guest) user access to cloud apps.

Before moving on to the next point, I want to highlight that such policies can be very powerful. So powerful that they could lock you out of your own environment. To avoid that, please, always exclude emergency / break-the-glass accounts. In addition, never rollout Conditional Access policies in production before proper testing. The report-only policy mode can be of great help for that. Moreover, the What If tool is also a very good tool that you should be using to assess the correctness of your policies. Once the potential impact and the policy configuration have been carefully reviewed, gradually roll out policies by waves over a period of a few weeks with different pilot groups.

Use App Protection Policies to reduce the risk of mobile devices

License requirement: Entra ID Premium P1 and Microsoft Intune

If access from mobile devices, i.e., Android and iOS, is required for end user productivity for example, App Protection Policies (APPs) can help you preventing data loss on devices that you may not fully manage. Note that App Protection Policies are also now available for Windows devices but are still in preview at the time of writing (beginning of March 2024).

In short, App Protection Policies are a set of rules that ensures that data access through mobile apps is secure and managed appropriately, even on personal devices. APPs can enforce the use of Microsoft-managed applications, such as Microsoft apps, enforce data encryption, require authentication, restrict actions between managed and unmanaged applications, wipe the data from managed applications, etc.

For that purpose, the following Grant control can be configured:

Of course, to be effective, App Protection Policies should be created in Intune and assigned to users. Because of that, Microsoft Intune licenses are required for users in scope of that control.

Moreover, together with the Exchange Online and SharePoint Online app enforced restrictions capabilities, you can allow, restrict, or block access from third-party browsers on unmanaged devices.

Require Authentication Strengths instead of standard multi-factor authentication

License requirement: Entra ID Premium P1

Authentication Strength policies in Entra Identity Conditional Access enable administrators to mandate certain authentication methods, such as FIDO2 Security Keys, Windows Hello, Microsoft Authenticator, and passwordless authentication. Please note that the authentication methods available to users will be determined by either the new authentication method policies or the legacy MFA policy.

By configuring Authentication Strengths policies and integrating them in Conditional Access policies, you can further restrict (external) user access to sensitive applications or content in your organization. Built-in policies are also available by default:

One common use case for Authentication Strength policies is to ensure that user accounts with privileged access are protected by requiring phishing-resistant MFA authentication, thus restricting access to authorized users only. In Conditional Access, this goal can be achieved through multiple methods:

1. Secure Privileged Identity Management role activation with Conditional Access policies (see next point for more details);
2. Include privileged Entra ID roles in Conditional Access, by selecting directory roles in the policy assignments;
3. Integrate protected actions into Conditional Access policies to enforce step-up authentication when users perform specific privileged and high-impact actions (see next point for more details).

Other use cases include enforcing stricter authentication requirements when connecting from outside a trusted location, when a user is flagged with a risk in Identity Protection, or when accessing sensitive documents in SharePoint Online.

Finally, as mentioned above, external users (only those authenticating with Microsoft Entra ID, at the time of writing) can be required to satisfy Authentication Strengths policies. The behavior will depend on the status of the cross-tenant access settings, as explained in my previous blog post.

Use Authentication Context to protect specific actions and applications

License requirement: Entra ID Premium P1

Authentication Contexts in Conditional Access allow to extend the locations or actions covered by Conditional Access policies. Indeed, they can be associated with applications, SharePoint Online sites or documents, or even specific privileged and high impact actions in Entra ID.

Before diving into how they can be used, we will quickly go over how they can be created. Authentication Context is a feature of Microsoft Entra Conditional Access and can therefore be managed from the Conditional Access service. Before being able to use them, they need to be created and published to applications:

Once they have been created and published, we can use them in Conditional Access policies. Let’s take a closer look at the different scenarios described above:

1. Integrate Authentication Contexts in Sensitivity Labels to require step-up authentication or enforce restrictions when accessing sensitive content:

In this first example, the Super-Secret sensitivity label has been configured to require step-up authentication when accessing documents with that label assigned:

If we configure the below CA policy with the target resource set to the ‘Sensitive documents’ Authentication Context, users will have to satisfy the phishing-resistant MFA requirements, unless it has already been satisfied, when accessing documents labeled with the Super-Secret label:

• Integrate Authentication Context with Privileged Identity Management roles to enforce additional restrictions on role activation (PIM requires Entra Premium P2 licenses):

Role settings in Entra Privileged Identity Management can be changed to require Authentication Context on role activation. That way, administrators can ensure that high privileged roles are protected against abuse and only available to authorized users themselves:

When such control is configured in PIM, users will not be prompted to perform MFA twice if the specified MFA requirement has been previously met during the sign-in process. On the other hand, they will be prompted with MFA if it hasn’t been met before.

Similar to the previous point, the same principle applies to the creation of the Conditional Access policy. The custom PIM Authentication Context should be set as the target resource, and the conditions and access controls configured to meet your security requirements.

Important note: when changing the configuration of high privileged roles, which allow to modify the configuration of Microsoft Entra PIM, make sure you are not locking yourself out of the environment by having at least one active assignment configured.

• Integrate Entra ID Protected Actions with Conditional Access policies:

Finally, by integrating Entra Identity Protected Actions with Conditional Access, administrators can introduce an extra layer of security when users attempt specific actions, such as modifying Conditional Access policies. Once again, make sure you are not locking yourself out here.

With Protected Actions, you can require strong authentication, enforce a shorter session timeout or filter for specific devices. To create a Protected Action, administrators first need to create an Authentication Context, which will then be assigned to a set of actions in the ‘Entra ID Roles and administrators’-page:

In this example, the ‘Protected Actions’ Authentication Context has been linked to permissions that allow updating, creating, and deleting Entra Conditional Access policies.

Then, in a Conditional Access policy, set the target resource to the ‘Protection Actions’ Authentication Context and define the conditions as well as the access controls.

Once in effect, administrators will be required to meet the configured authentication requirements and/or conditions each time they attempt to modify Conditional Access policies:

Use Device Filters in Conditional Access policies conditions

License requirement: Entra ID Premium P1

Last but not least, the ‘Filter for devices’-condition in Entra Conditional Access is a powerful tool that can be used for multiple purposes. Indeed, by using this condition, it is possible to target specific devices based on their ID, name, Ownership, compliance or join state, model, operating system, custom attributes, etc.

Besides the common scenarios of using the device filter condition to target compliant, non-compliant, registered, or joined devices, it can be used to restrict or block access based on more advanced conditions. For instance, you might require that only devices with certain operating system versions, specific device IDs, or device names that follow a particular pattern are allowed to access specific applications. Custom attributes can also be useful for more granularity, if needed.

The following filter will target devices meeting the following criteria:

• The display name of the device should contain ‘ADM’;
• The device should be seen as compliant, in Microsoft Intune, for instance;
• The device state should be Microsoft Entra joined;
• And the ExtensionAttribute4 should contain ‘anyvalue’. Extension Attributes for Entra ID registered devices can be added and customized using the Microsoft Graph REST API.

More information about the different operators and properties can be found in the ‘Resources’-section below.

Bonus: Restrict authentication flows

License requirement: Entra ID Premium P1

The ability to restrict authentication flows in Microsoft Entra Conditional Access, which is still in preview, has been introduced end of February (when I was writing this blog post). I included it to make sure that you are aware of this new feature. However, I do not recommend implementing it in production before it is released in General Availability (at least without proper investigation and testing!).

This functionality has been introduced as a new condition in Microsoft Entra Conditional Access policies and allows to restrict device code flow and authentication transfer.

Firstly, the device code flow has been introduced to facilitate user sign-in on input-constrained devices, referred to as ‘device A.’ With this flow, users can authenticate on ‘device A’ by using a secondary device, referred to as ‘device B.’ They do this by visiting the URL: https://login.microsoftonline.com/common/oauth2/deviceauth. Once the user successfully signs in on ‘device B,’ ‘device A’ will receive the necessary access and refresh tokens.

The flow can be represented as follows:

However, this functionality has been, and still is, abused by attackers attempting to trick users into entering the device code and their credentials.

Therefore, Conditional Access policies could now be used to block device code flow, or restrict it to managed devices only. This measure helps ensure that phishing attempts are unlikely to succeed unless the attackers possess a managed device.

Moreover, device code flow authentication attempts are visible in the Entra ID Sign-in Logs:

Secondly, authentication transfer enables users to transfer their authenticated state from one device to another, for instance, by scanning a QR code with their mobile phone from a desktop application. This functionality allows to reduce the number of times users have to authenticate across the different platforms. However, by doing so, users aren’t required to perform MFA again on their mobile phone if they have already performed MFA on their laptop.

Like device code flow authentication, authentication transfer can be blocked using a Conditional Access policy. To do so, simply select ‘Authentication transfer’ under Transfer methods.

Finally, authentication transfer can also be detected in the Entra ID Sign-in logs. Indeed, ‘QR code’ is set as the authentication method in the authentication details.

Evaluate Conditional Access policies

License requirement: Entra ID Premium P1

As a final note, I wanted to highlight the What If tool in Entra Conditional Access. It allows administrators to understand the result of the CA policies in their environment. For that purpose, administrators can select target users, applications, any available conditions, etc., to make sure that existing CA policies have the expected behavior. It also helps troubleshooting the configuration by gaining visibility into the policies that apply to users under specific conditions. The What If tool can be accessed in Entra ID > Conditional Access > Policies:

Moreover, the DCToolbox PowerShell module, which is an amazing toolbox for various Microsoft 365 security tasks, developed by Daniel Chronlund, also allows you to evaluate your current Conditional Access policies for a specific scenario. For that purpose, you can use the Invoke-DCConditionalAccessSimulation function and the tool will fetch all existing CA policies and evaluates them against the scenario that you have provided as arguments. You can find the DCToolbox PowerShell module on GitHub here: https://github.com/DanielChronlund/DCToolbox.

I highly recommend using one of these tools to evaluate your newly created or existing Conditional Access policies. Also note that proper testing and validation with different pilot phases and progressive rollouts is essential to avoid impacting end users when creating new policies.

Finally, as a general best practice, Conditional Access policies, and potential exceptions, should be properly documented. For that purpose, the DCToolbox tool allows you to export the current configuration of your Conditional Access policies in an Excel file, for example.

Conclusion

In this second blog post about Entra Conditional Access settings and configurations, we went over important principles that might help you increase the overall security posture of your environment. As for the first part, the settings and configuration items that I have highlighted could be considered when designing or reviewing your Entra Conditional Access implementation. This list is non-exhaustive and has been made based on my experience reviewing and implementing Conditional Access policies in different environments. Also, it is important to rigorously evaluate any policies before rolling them out in production and to make sure that other controls have also been properly configured in your cloud environment. Conditional Access policies are a great way to safeguard your identities and critical resources, but are not the only layer of defense that you should be relying on.

At NVISO, we have built an expertise reviewing cloud environments and have designed and implemented Entra Conditional Access on numerous occasions. If you want to know more about how we can help you in the journey of building or strengthening your Conditional Access setup, among others, feel free to connect on LinkedIn or visit our website at https://www.nviso.eu.

Resources

You can contact me on LinkedIn should you have any questions or remarks. My contact details can be found below.

Additionally, if you want to get a deeper understanding of some of the topics discussed in the blog post, all the resources that I have used can be found below:

• Conditional Access: Block access: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-block-access  
• Common Conditional Access policy: Require approved client apps or app protection policy: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-approved-app-or-app-protection
• App Protection Policies overview: https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy
• App Protection Policy settings for Windows: https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy-settings-windows
• Manage authentication methods for Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage
• What are protected actions in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/protected-actions-overview
• Add, test, or remove protected actions in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/protected-actions-add
• Conditional Access: Filter for devices: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices

About the author

Introduction

In this blog post, we will go over the most recurring (and critical) findings that we discovered when auditing the Active Directory environment of different companies, explain why these configurations can be dangerous, how they can be abused by attackers and how they can be mitigated or remediated.

First, let’s start with a small introduction on what Active Directory is.
Active Directory (AD) is a service that allows organizations to manage users, computers and other resources within a network. It centralizes authentication and authorization mechanisms for Windows devices and applications, making it easier for administrators to control access to network resources, enforce security policies, manage device configuration, etc.

Setting up an AD environment can be simple as it can be difficult depending on the organization’s size and requirements. In any case, AD comes with default settings and configurations that can be considered as dangerous and that may not comply with the security policies of your company. Administrators should be aware of these default configurations and take action to secure their environment by implementing best practices and security measures that align with their organization’s needs and risk appetite.

However, it may be difficult to identify these insecure configurations as they are not always well known to administrators. Moreover, new vulnerabilities may be identified later, as in the case of Active Directory Certificate Services (ADCS) where default templates can be abused to escalate privileges.

In the past two years, we reviewed AD environments of about 40 companies. When reviewing these environments, we noticed that some findings were quite recurrent. Some of these misconfigurations (or default settings) can have a significant impact on the security posture of a company and allow attackers to gain access to privileged accounts or to compromise the entire domain.

Let’s look at the 6 most common misconfigurations that could be abused by attackers to gain access to other systems or to compromise the environment.

Misconfigurations

Administrator accounts are allowed for delegation

In Active Directory, accounts can be delegated by default. This means that an application can act on behalf of a user (Kerberos delegation), impersonate a user anywhere within the forest (unconstrained delegation), or only impersonate the user to a specific service on a specific computer (constrained delegation).

If a delegation has been configured and if an attacker has access to the delegated system or account, they could try to impersonate an administrator account and move laterally or compromise the domain.

We found that, in almost all organizations audited, there was at least one privileged account for which the “This account is sensitive and cannot be delegated” setting was not enabled.

To abuse this default configuration, we first need to enumerate delegations. This can be done by using the Active-Directory PowerShell module:

Get-ADUser -LdapFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216)(msDS-AllowedToDelegateTo=*))"

Thanks to the above command, we know that a constrained delegation has been configured on the IIS account. We can now check the other properties of the IIS account:

Get-ADUser iis -Properties msDS-AllowedToDelegateTo

In this case, we can see that a constrained delegation has been configured on the IIS account to access the CIFS service of the WinServ-2022 server (Figure 2).

If we try to access the server using our low-privileged account, Bob, we get an error (Figure 3). This is expected because our account is not allowed to access this server.

As the IIS account is a service account, we can try to kerberoast the IIS account using Rubeus, for example (Figure 4). A kerberoast attack is a technique that attempts to retrieve the hash of an Active Directory account that has a Service Principal Name (also known as a service account). Note that in this example, we use the “rc4opsec” argument to only kerberoast service account that supports RC4 encryption, which is the default setting (we will go more in details in the “AES encryption not enforced on service accounts” section).

In this case, we were able to get the hash of the IIS account and crack the password using “John the Ripper”, which is “Password123”.

After generating the AES256 representation of the password, we can now use Rubeus to request an HTTP ticket to impersonate the domain administrator and gain access to the WinServ-2022 system. In this example, the HTTP ticket will allow us to run command on the WinServ-2022 server:

As mentioned before, we are allowed to impersonate the Administrator account because the “This account is sensitive and cannot be delegated” setting is not enforced by default.

After requesting and injecting the ticket that is used to impersonate the Administrator account in memory, we can access WinServ-2022 with the Administrator account:

This demonstrates that by compromising a poorly configured service account, any user can gain access to another system with domain administrator privileges. This could have been avoided by enabling the “This account is sensitive and cannot be delegated” setting on privileged accounts (e.g., Domain Admins, etc.), because the Administrator credentials would not be forwarded to another computer for authentication purposes.

The following dsquery command can be used to identify any user where the setting is not enabled:

dsquery * DC=LAB,DC=LOCAL -filter "(&(objectclass=user)(objectcategory=person)(!useraccountcontrol:1.2.840.113556.1.4.803:=1048576))"

In this example, if this setting was enabled, the attacker would not have been able to gain access to WinServ-2022 as Administrator:

Another option is to add the accounts to the Protected Users group. The Protected Users is a group introduced in Windows Server 2012 R2. The goal of this group is to protect administrators against credential theft by not caching credentials in insecure ways. Adding accounts to this group will not only prevent any type of Kerberos delegations, but will also prevent:

• CredSSO and Wdigest from being used;
• NTLM authentication;
• Kerberos from using RC4 or DES keys;
• Renewal of TGT beyond a 4-hour lifetime.

Microsoft recommends adding a few users to this group first to avoid blocking all administrators in case of a problem. However, it is useless to add computers and service accounts to this group because credentials will always be present on the host machine.

Note that after adding administrators to this group, some organizations have experienced difficulties connecting to servers using RDP (Remote Desktop Protocol). This is because only the Fully Qualified Domain Name (FQDN) is supported when connecting to servers via RDP when the user has been added to the Protected Users group. In fact, when using an IP address to connect to a server with RDP, NTLM authentication is used instead of Kerberos. However, when the FQDN is used, Kerberos authentication will be used.

AES encryption not enforced on service accounts

When a user requests access to a service in Active Directory, a service ticket is created. This service ticket is encrypted using a specific encryption type and sent to the user. The user can then present this encrypted ticket to the server to access the service. There are different encryption types available, such as DES, RC4 and AES. The encryption type is defined by the msDS-SupportedEncryptionTypes attribute. By default, the attribute is not set and the domain controller will encrypt the ticket with RC4 to ensure compatibility. This could allow an attacker to perform a kerberoasting attack, as previously demonstrated.

This means that if AES encryption is not enabled on service accounts and RC4 is not specifically disabled, an attacker could try to request a Kerberos ticket for a specific SPN (Service Principal Name, which is used to associate a service to a specific account) and brute force its password. Then, if someone can retrieve the cleartext password, they will be able to impersonate the account and access all systems/assets to which the service account has access.

If weak encryption types are allowed, an attacker can try to kerberoast a service account without generating too much suspicious activity in the logs, and gain access to other systems within the environment as described above in the “Administrator accounts are allowed for delegation” section.

To identify the value of the msDS-SupportedEncryptionTypes attribute for all service accounts, the following dsquery command can be used:

dsquery * "DC=lab,DC=local" -filter "(&(objectcategory=user)(servicePrincipalName=*))" -attr msDS-SupportedEncryptionTypes samaccountname distinguishedName -limit 0 | FIND /i /v "KRBTGT" | SORT

It is important to note that if the value is blank or equal to 0, it will be interpreted as RC4_HMAC_MD5.

The msDS-SupportedEncryptionTypes attribute on service accounts should be modified to only allow AES instead of legacy protocols such as RC4 or DES. However, for backward compatibility or to validate everything is functional, the value of the attribute can be set to 28. This means that RC4, AES-128, and AES-256 will be allowed. Note that all clients should support AES encryption if systems are not running Windows 2000, Windows XP or Windows Server 2003.

Finally, after making sure everything is working as expected, the value can be modified to 24 to only allow AES-128 and AES-256, as shown on the following screenshot (Figure 11), or to 16 to only allow AES-256.

Alternatively, you can edit the options of the account and check the following boxes (Figure 12). This will update the msDS-SupportedEncryptionTypes attribute.

If the attribute was set to 16 (meaning that only AES-256 is supported), we would not have been able to kerberoast the IIS account using the rc4opsec argument, as shown in Figure 13.

Moreover, if the rc4opsec argument is not used and the service account only allows AES encryption types, a 4769 event will be generated on the domain controller with the encryption type used (Figure 14). In this case, the encryption type is 0x12 (DES_CBC_MD5 and AES 256) which is not expected as the attribute is set to 0x10 (only AES-256).

A Blue team can use these events to identify kerberoasting activities on service accounts.

Finally, deprecated and insecure encryption types can be disabled via a GPO, as follows:

If an attacker tries to request an RC4 ticket for an account where only AES encryption types are allowed, the kerberoast attack will fail:

Note that the /usetgtdeleg parameter is used to request RC4 ticket for AES accounts.

Print spooler is enabled on Domain Controllers

According to Microsoft, the print spooler is an executable that manages the printing process by retrieving the location of the correct printer driver, loading the driver, scheduling the print job, etc.

In the past few years, the print spooler service has been affected by several zero-day vulnerabilities (such as PrintNightmare) allowing low privileged users to escalate their privilege, as the service is running with system level privileges. Many exploits are available, but we will not focus on these vulnerabilities.

The print spooler service can also be abused to gain access to the key of the kingdom, the hash of the KRBTGT account. By gaining access to the hash of this account, attackers will be able to forge Golden Tickets, meaning that they will gain almost unlimited access to the Active Directory domain (domain controllers, devices, files, etc.). An attacker can also perform a Skeleton Key attack to create persistence in the domain, as an example. This malware will inject itself inside the LSASS process and create a master password that will work for any account in the domain.

Indeed, when an unconstrained delegation has been configured on a server and when the print spooler service is running on at least one domain controller, it is possible to get the credentials of the domain controller where the service is running.

During our audits, we identified that more than 25% of organizations had configured unconstrained delegation on one or multiple machine accounts. In addition, the print spooler service was running on at least one domain controller in 75% of organizations.

Let’s see how an attacker could abuse these dangerous configurations.

First, we must find where an unconstrained delegation has been configured. This can be done using the Get-DomainComputer command from PowerView as follows:

Note that unconstrained delegation is enabled by default and required on domain controllers. In this example, WIN-7I6M16HF63I is the Domain Controller (DC).

We have already compromised the WinServ-2022 server where an unconstrained delegation has been configured. Moreover, the print spooler service is running by default on domain controllers. All the conditions are met to try to retrieve the hash of the KRBTGT account, so let’s give it a try!

We can use Rubeus on WinServ-2022 to extract all Ticket Granting Tickets (TGTs) and display any newly captured TGTs:

On our low privilege machine, we can use MS-RPRN, as an example, to force the domain controller to connect to WinServ-2022.

As expected, we captured a new TGT (Figure 20). The response from the DC contains the domain controller’s computer account Kerberos ticket.

We can now import this TGT to impersonate the DC:

Once the ticket has been imported, we can perform a DCSync attack using SharpKatz to get the KRBTGT hash.

We now have the hash of the KRBTGT account (Figure 22), which means that we successfully compromised the domain.

Thanks to the print spooler service running by default on DCs, we were able to trigger the service and make it authenticate to the WinServ-2022 service.

To mitigate this vulnerability, Microsoft recommends disabling the print spooler service on all domain controllers as a security best practice.

One way to identify domain controllers where the print spooler service is running is by using PingCastle, as shown in Figure 23. In this case, only the spooler module was executed and we can see that the service is active on the DC.

As mentioned above, the recommendation is to disable the print spooler service on domain controllers. This can be done using a GPO that will disable the service:

If the print spooler service was disabled, an attacker would not have been able to force the domain controller to connect to WinServ-2022.

Users can create machine accounts

First of all, let’s define what a machine account in Active Directory is. A machine account (or computer account) is an Active Directory object that represents a computer or a device connected to the domain. Like user accounts, machine accounts have different attributes that store information about the device, can be a member of security groups, can have Group Policies applied, etc.

By default, in Active Directory, everyone can create up to 10 machine accounts in the domain. This is due to the ms-DS-MachineAccountQuota attribute. According to the Microsoft documentation, this attribute is “the number of computer accounts that a user is allowed to create in the domain”.

This setting is defined in the Default Domain Controllers Policy.

Moreover, the current value of ms-DS-MachineAccountQuota can be found using this PowerShell command:

Get-ADObject ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota

In this example, the Default Domain Controller Policy Group Policy Object (GPO) and the attribute have not been modified and Authenticated users can create up to 10 computer accounts (Figure 26 and Figure 27).

To create a new machine account, the PowerMad module, written by Kevin Robertson, can be used as follows:

As expected, after creating 10 machine accounts, the user will no longer be able to create new machine accounts:

There is no attribute indicating the number of accounts already created by one specific user. However, the mS-DS-CreatorSID attribute of computer objects is used to determine how many computer accounts have been created by a specific user.

This information can be retrieved by using the Get-MachineAccountCreator command from the PowerMad module:

It is also possible to check who created a specific machine account by using the Active Directory PowerShell module:

Get-ADComputer MyComputer -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}

The user who created the machine account will be granted write access to different attributes such as msDS-AllowedToActOnBehalfOfOtherIdentity, ServicePrincipalNames, DnsHostName, and so on.

Tools like KrbRelayUp leverage this default setting to escalate privileges to NT\SYSTEM on a local system. An attacker can also change the msDS-AllowedToActOnBehalfOfOtherIdentity to abuse Resource-Based Constrained Delegation, for example.

If a Public Key Infrastructure (PKI) is present in the domain, an attacker can take advantage of the default Machine certificate template to perform a DCSync attack and dump hashes of all users and computers. Let’s take a look at how an attacker can proceed to retrieve the hashes.

After creating a new machine account, an attacker can modify the ServicePrincipalNames and the DnsHostName attributes. First, we remove the service principal names containing the initial DnsHostName and then we set the DnsHostname attribute to the domain controller FQDN, as follows:

After that, an attacker can request a certificate for the machine account using the Machine template and they will get a certificate for the domain controller. This will allow the attacker to retrieve the NT hash of the domain controller machine account.

The hash can then be used to perform a DCSync attack:

By creating a new computer object, editing its properties and abusing the default Machine template, we were able to dump the hashes of all users. The hashes can then be used to perform a “Pass-the-Hash” attack and move laterally to other systems.

This could have been avoided if some mitigation measures had been put in place.

First, computer objects created using the PowerMad tool will be stored in the Computers container as opposed to other computer objects created by IT administrators. Indeed, they should be put in specific OUs as Group Policies can’t be applied on the container. This can be used to identify any objects created by malicious users.

Moreover, it is recommended to create a new group (or a new account) that will be granted the required permissions to create new machine accounts. This way, only members of this group will be allowed to create new computer objects and malicious users will not be able to perform the attack.

This can be done by modifying the Default Domain Controller Policy. To do so, go to Computer configuration > Policies > Windows Settings > Security Settings > User Right Assignment > Add workstations to domain: Remove the ‘Authenticated Users’ group and add the new group or account previously created.

Authenticated users will no longer be able to create new machine accounts, as shown in Figure 36.

Unchanged GPOs are not reprocessed on Domain Controllers

All domain joined systems refresh and apply applicable group policies at specific intervals.

For security policy settings (https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/security-policy-settings), the Group Policy engine works differently and these settings are automatically re-applied every 16 hours even if the GPO has not been changed.

However, by default, most GPO settings are only applied when they are new or when they have been changed since the last time the client requested them. This could allow an attacker to modify a registry key that is normally managed through a GPO to disable specific security measures, for example.

In the following example, a company enforces the Windows Defender Real-Time Protection through a GPO:

If a user tries to download malicious files, Windows Defender will immediately quarantine the files:

If a user can modify the Windows Defender Real-Time Protection registry key, they will be able to download and run malicious tools on the system. In this case, by setting the value to 1, the user disables the Real-Time Protection feature:

As expected, the Real-Time Protection is now disabled and the user can download malicious files:

To mitigate this vulnerability, it is recommended to ensure that registry and security policy settings defined in GPOs are always enforced and re-applied on systems even if the GPO has not changed. This way, any unauthorized changes made locally will be overridden after 5 minutes to 16 hours.

In the Default Domain Controller policy, under Computer Configuration > Administrative Templates > System > Group Policy, configure the following two settings as follows:

1. Configure security policy processing:
   • Process even if the Group Policy objects have not changed: Enabled
   • Do not apply during periodic background processing: Disabled
2. Configure registry policy processing:
   • Process even if the Group Policy objects have not changed: Enabled
   • Do not apply during periodic background processing: Disabled

The following settings can also be re-applied even if they have not been changed:

• Internet Explorer Maintenance
• IP Security
• Recovery Policy
• Wireless Policy
• Disk Quota
• Scripts
• Folder Redirection
• Software Installation
• Wired Policy

Moreover, enabling auditing for registry operations can help your organization identify suspicious changes.

To audit registry key modification, the “Audit object access” policy needs to be enabled using a GPO (Figure 41).

After that, auditing also needs to be enabled on the registry keys that you want to monitor (Figure 42).

In this case, each time the value of a registry key under Windows Defender is modified, an event will be generated in the Event Viewer and can be used by the Blue team to identify suspicious activities.

Modification to registry keys can now be detected by looking at different event IDs (4656, 4657, 4660 and 4663).

In our example, we can see that the value of the DisableRealTimeMonitoring registry key was changed to 1 instead of 0:

Password policy and least privilege

This section includes recommendations related to the password policy of service accounts and the KRBTGT account.

The recommendations included in this section should be adapted to your company policy, specific use cases and risk tolerance.

Service accounts

During the audits, we noticed that most of the time, there is no password policy for service accounts, allowing administrators to set weak passwords that can be easily brute forced. In a few cases, the password for service accounts was even included in their description.

As shown in the “Administrator accounts are allowed for delegation” section, we cracked the IIS account password because weak passwords are allowed as there is no password policy enforced for service accounts. This could have been prevented by configuring a proper password policy.

For example, Microsoft recommends using passwords of at least 25 characters for service accounts and implementing a process for changing them regularly. Moreover, it is also recommended to use a dedicated Organizational Unit to manage this kind of accounts, making it easier to administrators to manage security settings applied to these accounts.

Finally, we also noticed that some organizations tend to use personal administrator accounts as service accounts. This means that if someone achieves to compromise a service account used by an administrator, they will have all privileges associated to this account. As a best practice, service accounts should only be granted the permissions they need.

KRBTGT account

The KRBTGT account is a default account that exists in all Active Directory domains. Its main purpose is to act as the Key Distribution Center (KDC) service account, which handles all Kerberos requests in the domain. As mentioned above, if an attacker achieves to compromise this account, they will be able to forge Golden Tickets and gain access to domain resources.

We noticed that many organizations do not change the KRBTGT password on a regular basis. Based on 25 audits, we found that the KRBTGT password is changed every 1855 days on average, and two organizations did not change the password for more than 5500 days, that’s over 15 years!

This means that an attacker, who was able to compromise the KRBTGT hash and has not been detected yet, can maintain his access for 5 years on average (if they have not created a backdoor yet).

It is recommended to change the password of the KRBTGT account regularly, for example every 6 months or every year.

Note that the password must be changed twice because the password history value for this account is set to 2. This means that the two most recent passwords will be valid for all already existing tickets. Before changing the password for the second time, best practices recommend waiting at least 24 hours to avoid invalidating existing Kerberos tickets and requiring everyone and everything (computers, servers, service accounts, etc.) to re-authenticate.

However, if you suspect that the KRBTGT account has been compromised by an attacker, the password should also be reset. This will prevent anyone who has access to its hash from generating Golden Tickets, for example.

It is important to keep in mind that changing the KRBTGT password will not ensure the security of your organization. If someone managed to get its hash once, they will probably be able to compromise it a second time if no other security measures are implemented.

Conclusion

In this blog post, we went over the most common misconfigurations and default settings discovered when doing Active Directory assessments of different environments. These configurations can have a significant impact on the security of your organization and allow attackers to gain access to the key of your kingdom.

Therefore, it is important to know your environment. Moreover, there should be a security baseline which should always be followed and reviewed regularly.

• Is this configuration still required?
• Is there any potential risk, any new vulnerabilities associated to this service?
• Is there a more secure approach?

These are some of the questions IT administrators must repeatedly ask themselves to maintain a certain security posture.

Moreover, some tools allow you to perform automatic auditing of your AD environment and identify settings that could put your organization at risk:

• PingCastle: It scans your environment to identify security vulnerabilities and weaknesses. It includes checks for stale objects (legacy protocols, never expiring password, etc.), privileges accounts (Kerberoastable admin accounts, delegations, etc.) and anomalies (print spooler, ADCS, audit policy, etc.).
• BloodHound: It allows you to visualize Active Directory attack paths. It can be used to identify potential security vulnerabilities that could be exploited by an attacker with Domain Users privileges to elevate their privileges to Domain Admins, as an example.
• Testimo: It is a PowerShell Module created by EvotecIT that helps you identify security issues as well as other operational issues. It can also generate HTML reports showing the commands executed, their output, a description and links to external resources.

While PingCastle and Testimo are more defender oriented, BloodHound is more attacker oriented.

In addition to performing regular scans, IT administrators should always keep an eye on newly discovered vulnerabilities, as a configuration that is considered safe can be the cause of a disaster a few years later. Indeed, it is important to note that no tool can guarantee complete security for your AD environment.

NVISO can help you identify and remediate vulnerabilities and weaknesses in your environment by performing an adversary emulation assessment which simulate real-world threats, as an example. These assessments will help you improve your security posture and protect your organization from potential threats.

To learn more about how we can help you, feel free to reach out or to check our website.

This blog post is the third blog post of a series dedicated to Zero Trust security in Microsoft 365.

In the first two blog posts, we set the basics by going over the free features of Azure AD that can be implemented in an organization that starts its Zero Trust journey in Microsoft 365. We went over the Security Defaults, the per-user MFA settings and some Azure AD settings that allowed us to improve our default security posture when we create a Microsoft 365 environment.

Previous blog posts:

• Enforce Zero Trust in Microsoft 365 – Part 1: Setting the basics;
• Enforce Zero Trust in Microsoft 365 – Part 2: Protect against external users and applications.

Introduction

In this blog post, we will see what Azure AD Conditional Access is, how it can be used to further improve security and introduce its integration capabilities with other services.

As a reminder, our organization has just started with Microsoft 365. However, we have decided to go for Microsoft 365 for our production environment. Therefore, we want to have a look at a more advanced feature, Azure AD Conditional Access policies. This feature requires an Azure AD Premium P1 license which comes as a standalone license or which is also included in some Microsoft 365 licenses (Microsoft 365 E3/A3/G3/F1/F3, Enterprise Mobility & Security E3, Microsoft 365 Business Premium, and higher licenses). Note that one license should be assigned to each user in scope of any Conditional Access policies.

Azure AD Conditional Access allows to take identity-driven signals to make decisions and enforce policies. They can be seen as if-then statements. For instance, if a user wants to access SharePoint Online, which is a Microsoft cloud application that can be integrated in such policies, the user, more specifically, the user’s request, is required to meet specific requirements, defined in those policies. Let’s now see what the capabilities of those policies are.

Conditional Access

This part will be more theoretical to make sure everyone has the basics. Therefore, if you are already familiar to Azure AD Conditional Access Policies, you can directly jump to the next section for the implementation where we go over some prerequisites and important actions that need to be done to avoid troubles when setting up those policies based on our hands-on experience.

Conditional Access signals

As we have seen, signals will be considered to make a decision. It is possible to configure the following signals:

• User, group membership or workload identities (also known as service principals or managed identities in Azure): It is possible to target or exclude specific users, groups, or workload identities from a Conditional Access policy;
• Cloud apps or actions: Specific cloud applications such as Office 365, the Microsoft Azure Management, Microsoft Teams applications, etc. can be targeted by a policy. Moreover, specific user actions like registering security information (registering to MFA or Self-Service Password Reset) or joining devices can be included as well. Finally, authentication context can also be included. Authentication contexts are a bit different as they can be used to protect specific sensitive resources accessed by users or user actions in the environment. We will discuss authentication contexts in details in later blog post;
• Conditions: With an Azure AD Premium P1 license, specific conditions can be set. This includes:
  • The device platforms: Android, iPhone, Windows Phone, Windows, macOS and Linux;
  • The locations: Conditional Access works with Named Locations which can include country/countries or IP address(es) that can be seen as trusted or untrusted;
  • The client apps: client apps which support modern authentication: Browser and Mobile apps and desktop clients; and legacy authentication clients: Exchange ActiveSync clients and other clients;
  • Filter for devices: allows to target or exclude devices based on their attributes such as compliance status in the device management solution, if the device is managed in Microsoft Endpoint Manager or on-premises, or registered in Azure AD, as well as custom attributes that have been set on devices;
  • Note that these conditions need to be all matched for the policy to apply. If a condition such as the location is excluded and match an attempt to access an application, the policy will not apply. Finally, if multiple policies matched, they will all apply, and access controls will be combined (the most restrictive action will be applied in case of conflicts).

Conditional Access access controls

Then, we have the access controls which are divided into two main categories, the “grant” and the “session” controls. These access controls define the “then do this” part of the Conditional Access policy (if all conditions have matched as mentioned previously). They can be used to allow or block access, require MFA, require the device to be compliant or managed as well as other more specific controls.

Grant controls

• Block access: if all conditions have matched, then block access;
• Grant access: if all conditions have matched, then grant access and optionally apply one or more of the following controls:
  • No controls are checked: Single-Factor Authentication is allowed, and no other access controls are required;
  • Require Multi-Factor Authentications;
  • Require authentication strength: allows to specify which authentication method is required for accessing the application;
  • Require device to be marked as compliant: this control requires devices to be compliant in Intune. If the device is not compliant, the user will be prompted to make the device compliant;
  • Require Hybrid Azure AD joined devices: this control requires devices to be hybrid Azure AD joined meaning that devices must be joined from an on-premises Active Directory. This should be used if devices are properly managed on-premises with Group Policy Objects or Microsoft Endpoint Configuration Manager, formerly SCCM, for example;
  • Require approved client apps: approved client apps are defined by Microsoft and represent applications that supports modern authentication;
  • Require app protection policy: app protection policies can be configured in Microsoft Intune as part of Mobile Application Management. This control does not require mobile devices to be enrolled in Intune and therefore work with bring-your-own-device (BYOD) scenarios;
  • Require password change;
  • For multiple controls (when multiple of the aforementioned controls are selected):
    • Require all the selected controls;
    • Require one of the selected controls.

Session controls

• Use app enforced restrictions: app enforced restrictions require Azure AD to pass device information to the selected cloud app to know if a connection is from a compliant or domain-joined device to adapt the user experience. This control only works with Office 365, SharePoint Online and Exchange Online. We will see later how this control can be used;
• Use Conditional Access App Control: this is the topic of a later blog post, but it allows to enforce specific controls for different cloud apps with Microsoft Defender for Cloud Apps;
• Sign-in frequency: this control defines how often users are required to sign in again every (x hours or days). The default period is 90 days;
• Persistent browser session: when a persistent session is allowed, users remain signed in even after closing and reopening their browser window;
• Customize continuous access evaluation: continuous access evaluation (CAE) allows access tokens to be revoked based on specific critical events in near real time. This control can be used to disable CAE. Indeed, CAE is enabled by default in most cases (CAE migration);
• Disable resilience defaults: when enabled, which is the case by default, this setting allows to extend access to existing session while enforcing Conditional Access policies. If the policy can’t be evaluated, access is determined by resilience settings. On the other hand, if disabled, access is denied once the session expires;
• Require token protection for sign-in sessions: this new capability has been designed to reduce attacks using token theft (stealing a token, hijacking or replay attack) by creating a cryptographically secure tie between the token and the device it is issued to. At the time of writing, token protection is in preview and only supports desktop applications accessing Exchange Online and SharePoint Online on Windows devices. Other scenarios will be blocked. More information can be found here.

Conditional Access implementation

Before getting started with the implementation of Conditional Access policies, there are a few important considerations. Indeed, the following points might determine if our Zero Trust journey is a success or a failure in certain circumstances.

Per-user MFA settings

If you decided to go for the per-user MFA settings during the first blog post, you might consider the following:

• As mentioned before, Conditional Access policies can be used to enforce a sign-in frequency. However, this can also be achieved using the ‘remember multi-authentication’ setting. If both settings are configured, the sign-in frequency enforced on end users will be a mix of both configuration and will therefore lead to prompting users unexpectedly;
• If trusted IPs, which require an Azure AD Premium P1 license, have been configured in the per-user MFA settings, they will conflict with named locations in Azure AD Conditional Access. Named locations allow you to define locations based on countries or IP address ranges that can then be used to allow or block access in policies. Besides that, if possible, named locations should be used because they allow more fine-grained configurations as they do not automatically apply to all users and in all scenarios;
• Finally, before enforcing MFA with Conditional Access policies, all users should have their MFA status set to disabled.

Security Defaults

Moreover, if you opted for the Security Defaults, it needs to be disabled as they can’t be used together.

How and where to start?

Now that we have some concepts about Conditional Access and some considerations for the implementation, we can start with planning the implementation of our policies. First, we need to ensure that we know what we want to achieve and what the current situation is. In our case, we first want to enforce MFA for all users to prevent brute force and protect against simple phishing attacks.

However, there might be some user accounts used as services accounts in our environment, such as the on-premises directory synchronization account for hybrid deployments, which can’t perform multi-factor authentication. Therefore, we recommend identifying these accounts and excluding them from the Conditional Access policy. However, because MFA would not be enforced on these accounts, they are inherently less secure and prone to brute force attacks. For that purpose, Named Locations could be used to only allow these service accounts to login from a defined trusted location such as the on-premises network (this now requires an additional license for each workload identity that you want to protect: Microsoft Entra Workload Identities license). Except for the directory synchronization account, we do not recommend the use of user accounts as service accounts. Other solutions are provided by Microsoft to manage applications in Azure in a more secure way.

Our first policy could be configured as follows (note that using a naming convention for Conditional Access policies is a best practice as it eases management):

1. Assign the policy to all users (which includes all tenant members as well as external users) and exclude service accounts (emergency/break-the-glass accounts might also need to be excluded):

2. Enforce the policy for all cloud applications:

3. Require MFA and enforce a sign-in frequency of 7 days:

4. Configure the policy in report-only first

We always recommend configuring Conditional Access policies in report-only mode before enabling them. The report-only feature will generate logs the same way as if the policies were enabled. This will allow us to assess any potential impact on service accounts, on users, etc. After a few weeks, if no impact has been discovered, the policy can be switched to ‘On’. Note that there might be some cases where you may want to shorten or even skip this validation period.

These logs can be easily access in the ‘Insights and reporting‘ panel in Conditional Access:

Conclusion

In this third blog post, we learned about Conditional Access policies by going over a quick introduction on Conditional Access signals and access controls. Then, we went over some implementation considerations to make sure our Zero Trust journey is a success by preventing unexpected behaviors and any impact on end users. Finally, we implemented our very first Conditional Access policy to require Multi-Factor Authentication on all users except on selected service accounts (which is not the best approach as explained above).

If you are interested to know how NVISO can help you planning your Conditional Access policies deployment and/or support you during the implementation, feel free to reach out or to check our website.

In my next blog post, we will see which policies can be created to enforce additional access controls without requiring user devices to be managed in Intune to further protect our environment.

About the author

In the first blog post of this series, we have seen how strong authentication, i.e., Multi-Factor Authentication (MFA), could be enforced for users using a free Azure Active Directory subscription within the Microsoft 365 environment.

In this blog post, we will continue to harden the configuration of our Azure AD tenant to enforce Zero Trust security without any license requirement. Specifically, we will see how our organization can protect against external users and prevent malicious applications from accessing our tenant.

Previous blog post:

• Enforce Zero Trust in Microsoft 365 – Part 1: Setting the basics

Settings hardening

Because some default settings in Azure Active Directory are not secure and might introduce security issues within our organization, I wanted to quickly go over them and see how they could be used by malicious actors.

Guest users

We haven’t discussed guest users for now. It is because access control for guest users can’t be enforced using an Azure AD free license. However, guest users might be the entry door for attackers to access our Microsoft 365 environment. Indeed, by compromising a user in a partner’s environment, adversaries will directly gain access to our environment because of this implicit trust relationship that is automatically setup when inviting guest users. Therefore, we can either assume that guest users are correctly protected in their home tenant (we will see in a later blog post that even if guest users have the appropriate security controls enforced in their home tenant, these security controls might not be enforced in certain circumstances to access our tenant (i.e., the resource tenant)), or restrict or disable guest user invitations. In any case, the way guest users will be managed is an important consideration for our Zero Trust approach. In our case, we will not simply block guest user invites because we think that collaboration with external parties is an important aspect for our business and will be required. Therefore, we want to take a proactive approach to this problem by setting a solid foundation before it is too late.

First, we want to ensure that no one in the organization, except authorized users, can invite guest users. Indeed, by default, all users in our organization, including guest users, can invite other guest users. This could represent a serious weakness in our Zero Trust approach. Therefore, we will only allow users assigned to specific administrator roles to invite guest users (this includes the Global Administrators, User Administrators and Guest Inviters roles).

Guest invite restrictions are configured in Azure AD. For that purpose, go to the Azure Portal > Azure Active Directory > Users > User Settings > Manage external collaboration settings under External users. Choosing the most restrictive option disables the ability to invite guest users.

Moreover, because our organization works with defined partners, users should only be able to collaborate with them. We can therefore further restrict invitations by specifying domains in the collaboration restrictions settings:

For those restrictions, a reliant process is required to clearly define who can manage guest users and external domains, especially if you regularly collaborate with different partners.

By default, guest users have extensive permissions. If an attacker takes over a guest account, the information to which the guest user has access, may be used for advanced attacks on our company. For this reason, we want to restrict them as much as possible. It might not be required for guest users to be able to enumerate resources in our Azure Active Directory tenant. This could allow adversaries, that compromised a guest user, to gain information on users within our tenant such as viewing our employees for sending (consent) phishing emails to gain initial access or viewing other partners to deceive them by impersonating our company or an employee. Therefore, we want to limit guest users permissions.

With these restrictions implemented for guest users, we have already decreased the potential impact that a compromised guest user could have in our environment. However, remember that with the current configuration, specific access controls, such as strong authentication for guest users, are not enforced to access our tenant. This means that a compromised guest user might still be used to access our environment.

External applications

In Azure Active Directory, applications can be integrated into Azure Active Directory to make them accessible to user. There are many types of applications that can be made accessible through Azure AD such as cloud applications, also known as pre-integrated applications, like Office 365, the Azure Portal, Salesforce, etc., custom applications, and on-premises applications.

Users can consent to applications to allow these applications to access organization data or a protected resource in the tenant on their behalf. Indeed, applications can request API permissions so that they can work properly. These API permissions include accessing a user’s profile, a user’s mailbox content, sending emails, etc. This can also be seen as an entry door for adversaries to gain access to information in our environment. For example, attackers could trick an employee by sending a consent link (consent phishing) to an employee for a malicious application. If the user consents, attackers would have the permissions the user has consented to. Even worse, an administrator might consent to an application for the entire organization. This means that a malicious application could potentially gain access to all directory objects.

Let’s abuse it!

If user consent is allowed in our Azure AD tenant, adversaries could send consent grant phishing to employees. Let’s see how this could be done.

First, because adversaries could access our Azure AD tenant because guest invitation restrictions were initially not configured, they could gather a list of our employees as well as their email address. Then, they used this list to create a phishing campaign for a Microsoft Advertising Certification study guide.

Because one employee was very eager to try out this new limited edition guide, they clicked the link and signed in with their credentials.

Unfortunately, the employee had administrative permission in our tenant and could therefore grant consent on behalf of the entire organization. Everyone should benefit from this free offer, right?… Not really, no. Indeed, as shown in the above screenshot the application, which is not verified, requires a lot of access such as sending and viewing emails, read and write access to mailbox settings, and read access to notes, files, etc.

Once the user clicks, adversaries can retrieve information about the user as well as from the organization. Additionally, they can access the user’s mailbox, OneDrive files and notes.

For this demonstration, I used 365-Stealer from AlteredSecurity to setup the phishing page and to access users in the directory:

How to protect ourselves against consent grant phishing?

There are no bullet proof solutions to protect users from phishing, unless you disable the ability for users to receive emails and messages globally, which is very far from ideal. Indeed, even with Office 365 threat policies, such as anti-phishing policies, and user awareness, malicious actors are always finding new ways of bypassing these polices and tricking users. However, what we can do is disabling the ability to consent for applications in Azure AD.

To restrict user consent for applications, it is possible to disable or restrict applications and permissions that user can consent to. Unless it is required, it is highly recommended to disable user consent. This will be done for our organization tenant to prevent consent grant attacks.

This setting can be configured in Azure Portal > Azure Active Directory > Users > User settings > Manage how end users launch and view their applications under Enterprise applications > Consent and permissions.

Besides blocking this functionality, it is also possible to only allow users to consent for permissions classified as low impact. Microsoft provides the ability to define our own classification model for application permissions, ranging from low to high as show below. In that case, administrators can select the Allow user consent for apps from verified publishers, for selected permissions (Recommended) setting in the user consent settings page:

Conclusion

In this blog post, we went over different settings in Azure AD that can be restricted to prevent malicious users from being added to our tenant. Moreover, we have seen how application consent settings can be abused through consent grant phishing and how we can protect against it.

I have selected these settings among others because we usually see that they are not restricted in most environments during our security assessments. However, configuring only these settings is not enough to protect your environment against malicious and unauthorized actions. If you would like to know more about how NVISO can help you securing your environment, feel free to reach out or to check our website.

In the next blog post, we will go over Azure AD Conditional Access policies, see how they can be used to further increase the security posture of our environment and implement our Zero Trust security approach.

About the author

This first blog post is part of a series of blog posts related to the implementation of Zero Trust approach in Microsoft 365. This series will first cover the basics and then deep dive into the different features such as Azure Active Directory (Azure AD) Conditional Access policies, Microsoft Defender for Cloud Apps policies, Information Protection and Microsoft Endpoint Manager, to only cite a few.

In this first part, we will go over the basics that can be implemented in a Microsoft 365 environment to get started with Zero Trust. For the purpose of the blog post, we will assume that our organization decided to migrate to the cloud. We just started investigating what are the quick wins that can be easily implemented, what are the features that will need to be configured to ensure security of identities and data, and what the more advanced features that could be used to meet specific use cases would be.

Of course, the journey to implement Zero Trust is not an easy one. Some important decisions will need to be made to ensure the relevant features are being used and correctly configured according to your business, compliance, and governance requirements without impacting user productivity. Therefore, the goal of this series of blog posts is to introduce you possible approaches to Zero Trust security in Microsoft 365.

Introduction

However, before starting we need to set the scene by quickly going over some principles.

First, what is a Zero Trust security approach? Well, this security model says that you should never trust anyone and that each request should be verified regardless of where the request originates or what the accessed resource is. In other words, this model will assume that each request comes from an uncontrolled or compromised network. Microsoft provides this nice illustration to represent the primary elements that contribute to Zero Trust in a Microsoft 365 environment:

We will go over these components as part of this blog post series.

You may wonder why I have decided to discuss Zero Trust in Microsoft 365. Because I think it is one of the most, if not the most, important aspects of a cloud environment. Indeed, with cloud environments, identities are considered as the new perimeter as these identities can be used to access Internet-facing administrative portals and applications from any Internet-connected device. 

Furthermore, even when security controls are enforced, it does not mean that the environment is secure. There were many attacks these past few months/years that allowed attackers to bypass security controls through social engineering, and phishing attacks, for example. Therefore, the goal is more to reduce the potential impact of a security breach on the environment than to prevent attacks from succeeding.

Finally, let’s go over some Microsoft 365 principles. When an organization signs up for a subscription of Microsoft 365, an Azure AD tenant is created as part of the underlying services. For data residency requirements, Microsoft lets you choose the logical region where you want to deploy your instance of Azure AD. This region will determine the location of the data center where your data will be stored. Moreover, Microsoft 365 uses Azure AD to manage user identities. Azure AD offers the possibility to integrate with an on-premises Active Directory Domains Services (AD DS) but also to manage integrated applications. Therefore, you should/must/have to understand that most of the work to set up a Zero Trust approach will be done in Azure AD.

Let’s get started!

Our organization just bought a paid Microsoft 365 subscription which comes with a free subscription to Microsoft Azure AD. The free Azure AD subscription includes some basic features that will allow us to get started with our journey. Let’s go over them!

Security Defaults

The first capability is the Azure AD Security Defaults. The Security Defaults are a great first step to improve the security posture by enforcing specific access controls:

• Unified Multi-Factor Authentication (MFA) registration: All users in the tenant must register to MFA. With Security Defaults, users can only register for Azure AD Multi-Factory Authentication by using the Microsoft Authenticator app using a push notification. Note that once registered, users will have the possibility to use a verification code (Global Administrator will also have the possibility to register for phone call or SMS as second factor). Another important note is that disabling MFA methods may lead to locking users out of the tenant, including the administrator that configured the setting, if Security Defaults are being used;
• Protection of administrators: Because users that have privileged access have increased access to an environment, users that have been assigned to specific administrator roles are required to perform MFA each time they sign in;
• Protection of users: All users in the tenant are required to perform MFA whenever necessary. This is decided by Azure AD based on different factors such as location, device, and role. Note that this does not apply to the Azure AD Connect synchronization account in case of a hybrid deployment;
• Block the use of Legacy Authentication Protocols: Legacy authentication protocols refer to protocols that do not support Multi-Factor Authentication. Therefore, even if a policy is configured to require MFA, users will be allowed to bypass MFA if such protocols are used. In Microsoft 365, legacy authentication is made from clients that don’t use modern authentication such as Office versions prior to Office 2013 a mail protocols such as IMAP, SMTP, or POP3;
• Protection of privileged actions: Users that access the Azure Portal, Azure PowerShell or Azure CLI must complete MFA.

These features already allow to increase the security posture by enforcing strong authentication. Therefore, they can be considered a first step for our organization that just started to use Microsoft 365 and is still researching/evaluating/ the different possibilities.

If we want to enable Security Defaults, we go to the Azure Portal > Active Azure Directory > Properties > Manage Security Defaults:

However, there are important deployment considerations to be respected before enabling Security Defaults. Indeed, it is a best practice to have emergency accounts. These accounts are usually assigned the Global Administrator role, the most privileged role in Azure AD/Microsoft 365 and are created to enable access to the environment when normal administrator accounts can’t be used. This could be the case if Azure AD MFA experiences outages. Because of the purpose of such accounts, these users should either be protected with a very strong first authentication method (e.g., strong password stored in secure location such as a physical vault that can only be accessed by a limited set of people under specific circumstances) or use a different second authentication factor than other administrators (e.g., if Azure AD MFA is used for administrator accounts used regularly, a third party MFA provider, such as hardware tokens, can be used). But here is the problem: this is not possible when using Security Defaults.

Per-user MFA settings

Note that the per-user MFA settings, also known as legacy multifactor authentication, will be deprecated on September 30^th, 2024.

The second capability with an Azure AD free license is the per-user MFA settings. These settings can be used to require Multi-Factor Authentication for specific users each time they sign in. However, some exceptions are possible by turning on the ‘Remember MFA on trusted devices’. Note that when enabled this setting will allow users to mark their own personal or shared devices as trusted. This is possible, because this setting does not rely on any device management solution. Users will only be asked to reauthenticate every few days or weeks when selecting this option. The interval depends on the configuration.

We usually do not recommend using the ‘Remember MFA on trusted devices’ setting unless you do not want to use Security Defaults and do not have Azure AD Premium licenses. Indeed, this setting allows any user to trust any device, including shared and personal devices, for the specified number of days (between one and 365 days). However, these settings can be configured in the https://account.activedirectory.windowsazure.com portal.

In the user settings, MFA can be enabled for each individual user.

Then, in the service settings, we can allow users to create app passwords for legacy applications that do not support MFA, select authentication methods that are available for all users, and allow or not users to remember Multi-Factor Authentication on trusted devices for a given period of time. Note that the trusted IP addresses feature requires an additional license (Azure AD Premium P1) that we do not have for the moment.

Sum-up

These two features are quite different but allow us to achieve the same goal, to enforce strong authentication, i.e., MFA, for all or some users.

For our organization we will choose the Security Defaults for multiple reasons:

• The per-user MFA settings can become unmanageable quickly. This is especially true for growingorganization.With more people and a complex environment, exceptions will be required, and it will become difficult to keep track of the configuration and keep a good baseline. Security Defaults, respectively,allow to enforce a standard baseline for all users;
• By using per user MFA users will be prompted for MFA every time they sign in.. This badly affects user experience and productivity might be impacted;
• Security Defaults blocks legacy authentication protocols that might be used to bypass MFA in some cases. This prevents identities, including administrators, from being targeted by brute force or password spraying attacks and help mitigating the risk of successful phishing attacks to a certain extent;
• Multi-Factor Authentication registration is enforced with Security Defaults for all users meaning that all users will be capable of doing MFA if required.

By going that way we need to consider that exclusions are not possible. Therefore, emergency accounts or user accounts used as service accounts (which it is not recommended to have as they are inherently less secure than managed identities or service principals) might be blocked. Nevertheless, as we are just evaluating the Microsoft 365 products, we can accept that the environment and cloud applications are unavailable for a few hours without any major impact on business processes. However, this might be an crucial point in the future.

Finally, it is important to note that these two features do not allow to configure more granular controls as we will see later in this series.

Conclusion

In this first blog post, we have seen different possibilities to enforce access restrictions that can be implemented when an organization just starts its journey in Microsoft 365:

• Per-user MFA settings: Allow to enforce MFA for specific users but can become quickly unmanageable and does not provide granular controls;
• Security Defaults: Allow to enforce a strong authentication mechanism and to block legacy authentication protocols that may allow users to bypass MFA. This solution is recommended over the per-user MFA settings. However, note that MFA might not be required in most cases which is not ideal.

In brief, we can see that both solutions have limitations and will not be suitable for most organizations. Indeed, there are still many aspects, such as restricting access based on specific conditions, that are not covered by these capabilities. We will go over additional key features as well as our recommendations for the implementation of a Zero Trust approach in Microsoft 365 in future blog posts.

In the next blog post, we will see how we can protect our environment against external users and applications.

About the author