Duo Authentication integrates with Microsoft Windows and Active Directory (AD) to support multi-factor authentication (MFA) for both remote desktop and local logons. This helps secure workstations against compromised credentials by requiring users to fulfil MFA requirements in order to logon to computers. Client-side configuration settings help support a wide range of use-cases and can be configured for offline access in the event of Internet or Duo API connectivity issues. Duo client-side configurations, service settings, and agent deployments can be configured either manually on endpoints, or by using AD group policy objects (GPOs). Duo authentication policies allow for fine-grained control over MFA requirements and MFA flows. A background on how Duo authentication works on a Windows computer or in an AD environment will help understand the abuses and misconfigurations.

Duo Authentication in Windows and AD

Duo integrates with Microsoft Windows via a software agent (Duo Authentication for Windows Logon) that must be installed on endpoints. Duo can then enforce MFA when a user logs into Windows either locally or using the remote desktop protocol (RDP), or when a user account control (UAC) elevation is required. Duo does not enforce MFA on endpoints for other services and logon methods such as when using PowerShell, scheduled tasks, SMB, WMI, PsExec, or WinRM.   Additionally, at the time of this writeup, Duo MFA integration when using Restricted Admin Mode RDP is not supported.

When a computer has Duo installed and configured to enforce MFA (either using a local Duo agent installation or deployment via GPO), the login flow for a user is as follows.

• A user enters their credentials (local or domain account) to the computer via the local login prompt or via the RDP client. If their credentials are determined to be valid, a Duo authentication prompt window appears while the computer remains locked. This prompt presents the user with a drop-down menu to select one of their Duo enrolled devices such as a phone, tablet, or security key device.
• Depending on the device type selected there are various authentication methods that can be used to fulfill the MFA requirements. This may include:
  • Sending a “Push” notification to a mobile device with the Duo App
  • Sending a “Passcode” via calling a phone number or sending an SMS message
  • Entering a “Passcode” from the Duo app installed on a mobile device
  • HOTP (HMAC-Based One-Time Password) /TOTP (Time-based One-Time Password) from a security key.
• For the computer to verify that the MFA requirements have been successfully met, the Duo software will perform API queries to a cloud-based API URL associated with a Duo tenant. To perform this API request, the software agent on the Windows device requires that API keys are configured.
• If the Duo software agent is not able to reach the cloud-based API, there are configuration settings which can be enforced that can either bypass MFA, or require that MFA must be required to authenticate.

Figure 2 shows an authentication flow diagram explaining how Duo is integrated to the logon process.

Looking Under the hood.

Interactive Install

When installing Duo Authentication on Windows computers, the API hostname, integration key (IKey) and secret key values (SKey) for a specified (unique) Duo instance and RDP application need to be configured. This allows the Duo application agent to communicate with the correct API hostname and apply the appropriate policies. Figure 3 and Figure 4 show how these values are configured during an interactive installation process. An outbound HTTP proxy can also be configured if a computer does not have direct outbound Internet access in an environment.

The API hostname, IKey, SKey and integration options are stored in the computer’s registry. The integration options can be updated to change how Duo behaves on computers, such as allowing FailOpen (more on this later), automatically sending push notifications, or only protecting RDP logons (and not local logons). For local installations of the Duo agent, the following registry path is used to house the configured settings:

HKLM\SOFTWARE\Duo Security\DuoCredProv

Figure 5 shows some of the integration settings that can be applied.  Of importance is the setting “Bypass Duo authentication when offline (FailOpen)”. This setting allows computers to be accessed without fulfilling MFA requirements in the event that there are Internet or connectivity issues that prevent the computer from contacting the cloud-based Duo API hostname.

The default registry keys associated with the settings noted in Figure 5. These settings can be modified by any user with local administrator privileges.

Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\FailOpen
Default Value: 1

Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\AutoPush
Default Value: 1

Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\RdpOnly
Default Value: 0

Group Policy Deployment and Configuration

GPO configurations can be used to remotely install software (including the Duo Authentication agent) on Windows computers in an AD environment. GPOs can be customized to target defined settings and software package installations for users, groups, and computers (including computer objects housed within specific Organization Units (OUs)).

For Duo authentication agent installations using GPOs, Duo recommends creating two (2) GPOs.

• One GPO that will install and deploy the Duo authentication agent
• One GPO that will configure the defined integration settings - including the API hostname, integration key and secret key.

The configuration instructions use the name “Duo Windows Logon” as the GPO name for the integration settings. Duo provides policy templates for configuring the aforementioned GPOs. When hunting for misconfigurations, consider searching for GPOs named based upon Duo’s default (recommended) templates. Duo provides the Group Policy MSI installers, template files and documentation in the following article “Duo Authentication for Windows Logon (RDP) – Active Directory Group Policy”.

Configuring the Duo authentication application using GPOs creates additional registry keys on computers where the policies have been applied:

HKLM\Software\Policies\Duo Security\DuoCredProv

The GPO that is used for deploying the Duo Authentication application to computers must reference the location of the MSI installation package for Duo and an MST transform file (used to transform or customize the content of an MSI package). It is recommended to stage the MSI and MST files on a network file share so that only computer accounts in the environment can access the required installation files. Since the MST file will contain the API hostname, IKey and SKey values to allow for configuration, it is recommended to prevent any authenticated user account the ability to access these files.

Security Considerations

When Duo is installed interactively Duo will restrict permissions of the registry so that only accounts with local administrative rights will be assigned permissions to read the SKey, IKey or other Duo-specific configuration settings from the registry. GPOs can be used to apply similar hardening measures to registry keys to prevent unwanted reading of their values. According to Duo’s documentation (Figure 7), the secret key is sensitive and must be treated like sensitive credentials. It should not be shared with unauthorized individuals.

By default, a newly created GPO (stored in a binary format in the SYSVOL SMB share on Domain Controllers) is readable to any authenticated user within a domain. To harden GPOs to restrict the ability for an authenticated user to read sensitive configuration data related to the Duo Authentication configuration options, the default Read permissions assigned to the  “Authenticated Users” security group can be be removed from the GPO (using the Delegation tab).  For the GPO that contains the IKey, SKey, API hostname and integration settings, read permissions can be set for either the “Domain Computers” security group, or for a security group that contains the target computer objects where the Duo Authentication agent would be deployed.   

Group Policy files are stored in a binary format in the SYSVOL SMB share on Domain Controllers. Policy files are not and cannot be encrypted. Following Duo’s recommendations will mean the GPO is not readable by low privileged domain users. Microsoft recommends to not store sensitive information in group policy configurations. The SYSVOL share must be accessible for computers to retrieve GPO settings.

The GPO used for deploying the Duo Application software does not necessarily need to be restricted - as the GPO configuration itself does not contain sensitive information. This policy contains the location of the MSI install package and MST transform file, which is likely a network SMB file share.  The network share or location of the MST transform file must be protected and not readable to authenticated users as the transform file contains the IKey, SKey and API hostname, and is sensitive.

Duo’s Auth API

The Auth API is a low-level REST API that the Duo Authentication application uses for enforcing MFA requirements. The SKey, IKey and API hostname are specifically used to enforce and validate MFA requirements defined by an organization. The API is also used to instruct the Duo agent to send either the “PUSH” notification, passcode via SMS message, or a phone call to the user – and will also be used to validate the response. The Auth API can also be used to determine if a user is enrolled in Duo - and can list a user’s MFA authentication methods and devices for enrolled users.

The Duo Authentication application does not support the “inline self-service” enrollment for new users. Users must already exist in Duo to use Duo Authentication on a Windows endpoint. A partially enrolled user is a user that exists in Duo, but does not have any MFA authentication methods associated. If a user is partially enrolled and is attempting to logon to a Windows device that has the Duo Authentication application installed and configured, the Auth API will respond with the user’s enrollment URL so the user can enroll a MFA authentication method such as a phone, mobile app, or TOTP/HOTP security key.

Common Misconfigurations

From both front-line engagements and research, Mandiant has observed common misconfigurations that can lead to unintended MFA bypasses when the Duo Authentication application is present on Windows endpoints.

Active Directory Misconfigurations

#1) GPO Permissions
As mentioned previously, by default, GPOs are readable to any authenticated user account within a domain.  Therefore it is recommended to not store sensitive information within GPO configurations. As the GPO deployment and configuration process for the Duo Authentication application requires that the API hostname, IKey and SKey parameters be included within the GPO, if read-only access to this GPO is not restricted, any domain user could access the GPO configuration file from the SYSVOL directory and obtain the API keys and API hostname (Figure 8).

#2) MSI Misconfigurations
To automate the Duo Authentication application deployment process, Duo provides an MSI package installer file and provides instructions on how to create an MST transform file using the  Microsoft Orca table editor. As mentioned previously, the MST transform file contains the IKey, SKey and API hostname - and is used during the install process to populate the registry values. Duo’s instructions indicate that admins should NOT save the changes to the MSI file itself when creating the transform file.

Despite this advice, the MSI files for installing the Duo Authentication application often contain the IKey, SKey and API hostname. Figure 9 contains an example of a misconfigured MSI file that contains the sensitive Duo configuration parameters.

The MSI files used by Duo are named as follows and Duo documentation says they cannot be changed without causing issues to deployment through GPOs.

• DuoWindowsLogon64.msi
• DuoWindowsLogon32.msi

Software installation and configuration files can often end up scattered across environments and are often housed on file shares that are accessible to a large scope of accounts.  This can expand the scope of unintended access to sensitive data (in this case – Duo API keys and the API hostname).

#3) Unsecured MST files
If the MST transform file was created properly and the MSI file did not contain sensitive data, a threat actor may be able to obtain the MST file if it is not properly secured. Duo’s instructions for securing the MST file are as follows:

“The share with the MST file should not be readable by unprivileged user accounts to prevent exposure of the Duo secret key.”

Based upon common observances, the MST file is often placed on an unsecured file share. For GPO deployments, the MST and MSI file are commonly placed into the “Scripts” directory on the SYSVOL SMB file share, or within another central software repository file share that has overly permissive access. If obtained, the MST file contents can be read using Orca or hex dumping tools (Figure 11).

#4) Insecure Group Policy Registry Keys
To prevent against unprivileged users from accessing the registry keys that contain the SKey, Ikey, and API hostname, Duo has provided specific instructions for hardening the registry keys when GPOs are leveraged to install the Duo Authentication application.  When Duo is invoked at logon, it will secure the registry keys each time it runs. If the recommended hardening is not applied, when a group policy update occurs, the registry keys will not be protected until a user completes a logon requirement where Duo is invoked. This creates a scenario where after a Group Policy update, low privileged users could potentially read and access the registry keys that contain the sensitive configuration information.

Figure 12 shows the default permissions for registry keys associated with a software deployment via a GPO. The “ALL APPLICATION PACKAGES” and “Users” group can read the keys by default (Figure 12). Figure 13 shows the inability for a low privileged user to read the registry keys after they have been hardened. This configuration option does not apply when the Duo Authentication application is installed locally, as the installation process automatically secures the registry keys. The GPO registry keys of interest are located within the following registry path:

HKLM\SOFTWARE\Policies\Duo Security\DuoCredProv

Retrieving the API Key from a Local Computer

#1) Non-Administrative or Non-System privileges
If a threat actor gains access to a computer protected by the Duo Authentication application, even as a low privileged user, extracting the API keys may be possible.

As discussed in the previous section, “Insecure Group Policy Registry Keys”, if the registry key permissions have not been hardened, any user may be able to read and obtain the configuration values.

HKLM\SOFTWARE\Policies\Duo Security\DuoCredProv

Searching the local file system for the Duo Logon MSI packages can also provide access to the API key, especially if the MSI package was modified incorrectly and contain the key. The MST transform file (or a text file that references the API key) may be present on the file system. Searching the file contents on disk for the API host, IKey or SKey may also result in identifying the key. The following formats are used for each respective value:

#2) Local administrative or System privileges
If a threat actor gains local administrative or System level privileges on an endpoint configured with the Duo Authentication application, the registry keys that contain the API host, IKey or SKey contents can be accessed - as the information is stored in plaintext within the registry.

Bypassing Duo Authentication for Windows Logon

The first attack is a bypass for Duo Authentication when the “FailOpen” setting is enabled. Credit for this bypass comes from this blog post, by n00py, Bypassing Duo Two-Factor Authentication. As discussed earlier, Duo can be configured to bypass MFA and allow access to a computer in the event there is a disruption to accessing the Internet or the Duo service.

This will cause a timeout and trigger the FailOpen policy, allowing access without fulfilling MFA requirements. To simulate a disruption for accessing the Duo Auth API (triggering the FailOpen), the API hostname (or if configured, the proxy hostname or IP) must be obtained. This can be obtained through any of the previous misconfigurations discussed throughout the article. The local hosts file can then be modified to reference the loopback address for resolving the FQDN of the API hostname  Figure 14 shows a modified hosts file that will result in an MFA “bypass” using a FailOpen policy.

If the “FailOpen” setting is not enabled and an attacker has access through a service not protected by Duo, there are multiple paths to potentially bypass MFA. Reading the documentation and having some creativity will help with bypassing MFA.  The Duo RDP guide discusses how some of the settings work. If a Group Policy is used to configure settings, you will need to modify the policy related registry keys.

Examples of potential settings that can be modified to bypass MFA requirements:

• If disabled, enable the “FailOpen” setting for the Duo Authentication application by setting the registry value to “1”. 
  • Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\FailOpen
• If interactive logon access is available through a virtual machine console, enable “RdpOnly” to disable MFA on local logons by setting the registry value to “1”.
  • Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\RdpOnly
• Enable “UAC Elevation Protection” and enable “Protect User elevation only” - as this disables MFA for local and RDP sessions by setting the registry value to “1”. Setting the registry value to “2” enables UAC elevation protection in addition to local logons. More information is available here.
  • Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\ElevationProtectionMode
• If configured, modify the proxy host or port to cause a timeout in reaching the Duo Auth API service.
• Replace the Duo API host name with an arbitrary value within the registry.
  • Registry Key: HKLM\SOFTWARE\Duo Security\DuoCredProv\Host

If the computer is hardened and all local services and re-configuration methods are locked down, if the FailOpen setting is enabled, a network-based “availability’ attack could prevent Duo from communicating with the Duo API hostname or if configured, proxy.

One technique for a network-based attack was covered in n00py’s blog, ARP spoofing.  This would require the attacker to be suitably positioned on the network. See the blog for further details.

Depending on the scenario, some additional creativity may allow for bypass techniques. Here are some scenarios to consider:

• If the target computer is a virtual machine and the attacker has access to the management platform for the virtual machines, additional methods for bypassing Duo MFA could include: 
  • If the RDPOnly was enabled, simply logging in locally through the virtual machine console will not require MFA.
  • If the local virtual network interfaces can be disabled or disconnected, this will disrupt connectivity to the Duo Auth API service, and potentially allow for an MFA bypass if FailOpen is enabled.
  • Modifying IP addresses, gateways, routes, or MAC address to disrupt connectivity to the Duo API Auth service.
  • Configuring a firewall - restricting outbound internet access to the Duo Auth API service.
  • Restarting Windows into Safe Mode, as this disables the Duo Authentication application service.
• With physical access to the target computer, additional methods for bypassing Duo MFA could include:
  • If the RDPOnly was enabled, simply logging in locally through the virtual machine console will not require MFA.
  • Unplugging the ethernet connection or disrupting the Wi-Fi connectivity, therefore preventing access to the Duo Auth API service.

Restarting Windows into Safe Mode, as this disables the Duo Authentication application service.

Additionally, depending on the configured Duo policies, it is possible that simply having the right set of credentials could allow for bypassing MFA. Examples include:

• Local administrative accounts may not be enrolled in Duo or may not be configured to be protected by the Duo Authentication application.
• Duo can be configured to allow specific users or groups to logon in “offline” mode - bypassing MFA.
• Duo policies can be configured to allow users who are not enrolled in Duo to bypass MFA. This is recommended by Duo when testing new deployments in order to allow a pilot group of users to perform testing. It is possible that some organizations will leave the policy in this configuration to prevent business disruptions.

Leveraging the Auth API

Now that the various ways to recover the API hostname and keys have been covered let’s examine how to make use of these keys. The Duo Auth API Documentation is available here.

Enumerating User Enrollment Status

As part of the Duo Auth IP service, the preauth endpoint determines where a user is authorized to log in from, and if the user is allowed, it returns a list of available authentication methods. This endpoint is very interesting to an attacker. The endpoint takes a single argument, a username or user ID. There are additional parameters that can be useful in various attack scenarios.

In the logon flow discussed at the start of this article, the Duo Authentication application performs this API call after the primary factor of authentication, Windows credentials, are validated by either the local endpoint or local identity provider (commonly Active Directory). The computer queries the API and obtains the available authentication factors in order to populate the drop down menu on the Duo prompt screen - and present the defined authentication methods. Figure 15 shows a query to the auth API for a user (duol) that is enrolled in Duo and can logon. The authorized devices associated with the user are returned.  In this case, the user had one Android mobile device configured with the Duo mobile app. The supported capabilities of this device are PUSH notifications, SMS passcodes and mobile OTPs codes from the Duo mobile app.

This preauth endpoint behaves in an interesting way when we try to logon to Windows with a user who is partially enrolled in Duo or if the “New User” policy is set to “Require enrollment”. As a reminder, a partially enrolled user is a user that has been created in Duo but has no authentication methods configured. Figure 16 shows the message displayed when attempting to logon to a computer protected by Duo with a partially enrolled user.  An error stating the user is not enrolled is displayed and logon access is denied. The Duo Authentication application installed on a Windows endpoint does not support inline enrollment.  Another enrollment method must be used for a user to enroll such as a Duo protected VPN, web application or enrollment link sent via email by an administrator. If inline enrollment was supported,  this would be the stage where the user is presented with a way to add an authentication method (usually by scanning a QR code or visiting a link).

Attacking Users

When the preauth API endpoint is queried for a partially enrolled user, or the New User policy is set to “require enrollment” and the user does not exist, the API’s response will contain the enrollment URL. Figure 17 shows the API response for a partially enrolled user, containing the enrollment URL. By copying the enrollment URL and pasting it into a browser, an attacker can now add our own authentication method to the partially enrolled user’s account.

Note: The enrollment URL may be expired depending on the length of time since the user was created in Duo and other factors.

The attacker, if they have credentials for the account, can now authenticate as the user, leveraging the newly registered MFA method to complete the MFA authentication process.

The preauth API endpoint also provides a means for an attacker with a valid API key to enumerate the enrollment status of Duo users and identify accounts with the “Require enrollment” option (where attacker-controlled MFA authentication criteria can be associated with valid accounts). This attack path becomes much more viable when a list of users is known, such as targeting a list of users from Active Directory.

What about users who do not exist in Duo, known as unenrolled users? We just saw that if the “New User” policy is set to “Require enrollment” we can enroll a partially-enrolled user and add an authentication method. Let’s take a look at unenrolled users and various policy configurations.

As mentioned earlier, Duo policies can be configured to allow users who do not exist in Duo to logon to computers. Policies can also be configured to deny users the ability to logon if they do not exist in Duo. This allows the preauth endpoint to be used to enumerate users who may be allowed to logon without fulfilling MFA requirements. If a user is allowed to logon, the result value will contain “allow” and the status message will say “Allowing unknown user”. This indicates the New User policy is set to “Allow access without 2FA” and allows users that do not exist in Duo to logon. If the Duo policies are configured to not allow logon to unknown user, the result value will be “deny” and the status message will vary based on other policy configuration details. Figure 19 and Figure 20 show the API query responses for policies allowing unknown users and denying unknown users respectively.

In summary with the preauth endpoint and a list of users, an attacker can enumerate the enrollment status for valid users. For partially enrolled users and if the “New User” policy is set to “Require enrollment”, an enrollment URL can be obtained which may allow the attacker to enroll in MFA with their own device. The user accounts you can enroll in MFA become high value targets for AD attacks, password based attacks, and social engineering. The impacts of the described attacks can become widespread in larger environments.

There are additional enumeration techniques with the preauth API endpoint, however the use cases are limited and typically reserved for highly targeted attacks. Fine-grained policies in Duo and group policies in AD means that different users, groups, and computers could effectively have different MFA policies and requirements. These additional techniques involve allowing logons only from specific IP addresses, from specific devices and if the device can be “remembered” to bypass MFA on trusted devices for a time specified in the policy.

Causing Panic with the Auth API

The Auth API is the API that Windows computers use to communicate with Duo to send passcodes, push notifications, calls and more. Being able to query the API can also lead to situations that can cause panic - such as sending a large frequency of push, SMS, or phone calls to distributed devices in an organization. If a large number of users receives unsolicited passcodes or pushes from Duo, the users may believe that their passwords have been compromised. Imagine a scenario where all personnel including executives and IT staff receive Duo notifications and think their credentials have been compromised. This API is also used to validate passcodes such as from a mobile app or bypass codes.

Theoretically you could attempt to spray passcodes across users or brute force passcodes, however you would hit the lockout limits well before this attack would become feasible. By default, Duo locks out Duo users if there are 10 failed logon attempts. Locked users are not re-activated by default. The policies that determine the lockout measures can be changed and may be more or less restrictive in individual implementations. A malicious actor could potentially lockout a large number of users in an organization and prevent them from using MFA.

Non-Windows and AD Considerations

In addition to Windows computers, Duo uses the Auth API described in this blog for integration with other applications and services. Some examples include Confluence, Jira, WordPress sites, MacOS, Linux hosts, OpenVPN, Citrix, and Splunk. The API host, IKey, and SKey configurations can exist in other applications and locations outside of just Windows-based endpoints and GPO configuration settings. Other location examples include:

• Linux PAM Auth:
  • /etc/duo/pam_duo.conf
  • /etc/security/pam_duo.conf
• Confluence and Jira:
  • $CONFLUENCE_DIR/confluence/WEB-INF/web.xml
  • $JIRA_DIR/atlassian-jira/WEB-INF/web.xml
  • Confluence and Jira are by default in: /opt/atlassian/<jira|confluence>
• MacOS:
  • /private/var/root/Library/Preferences/com.duosecurity.maclogon.plist
• OpenVPN:
  • /etc/openvpn/openvpn.conf
  • /etc/openvpn/server.conf
    • plugin /opt/duo/duo_openvpn.so IKEY SKEY HOST
• Generic Web Integrations (for custom apps):
  • https://duo.com/docs/duoweb

Recommendations

Duo provides the following guidelines for additional hardening:

• Guide for Changing the New User Policy Setting
• Guide for Protection Duo Application Credentials

Through the research conducted by Mandiant and reviewing of the Duo documentation, we recommend considering the following controls and processes when implementing Duo:

• Restrict local administrative access on computers with the Duo Authentication application installed. Anyone with local administrative or system-level permissions can retrieve the API key and configuration information from the local registry.  Most of the potential bypass methods rely upon the ability to access Duo API configuration information (URL / key) or modify endpoints – which requires local administrative permissions.
• Configure Offline Access methods over FailOpen offline mode (which can be bypassed – as described within this blog).  Offline access will allow for a user to logon to a Windows endpoint securely even when the endpoint cannot connect to Duo’s cloud API service. Methods for MFA enforcement for offline access include either Duo Mobile on iOS / Android or a U2F security key.  For additional information, reference https://duo.com/docs/rdp#offline-access.
• Enforce unique credentials that require strong MFA methods for accessing the Duo Admin Panel.
• Test and verify the configuration of Duo policies to avoid unintended bypasses and misconfigurations.
• Within Duo’s “New User Policy”, leverage the “Deny access” setting over the “Allow access without 2FA” setting.  While the “Require enrollment” setting can prevent MFA bypasses, it can also allow attackers that have obtained API keys to enroll either unenrolled or partially enrolled users with attacker-controlled MFA devices.
• The “Enforce 2FA” setting in the “Authentication Policy” is the only option that protects computers. “Bypass” allows all users to bypass MFA and “Deny access” denies all access regardless of MFA fulfillment.
• Review pending enrollments in the Duo Admin Panel – and either revoke or manually enroll users that are still in a pending or open state.
• Regularly audit Duo to ensure all users are enrolled, do not have MFA bypass conditions associated, and that all configured policies meet requirements.
• For computers that require different MFA authentication settings and requirements, leverage GPO configurations to target enforcement based upon an endpoint’s security requirements.  This can allow for sensitive systems to have stricter controls – as compared to other systems within a managed environment. 
• Do not place the API Host, SKey or IKey parameters into the installation MSI. Create the transform MST file and place it in a secure network location that only target computers can access.  Authenticated users should not be granted “read” access to the file share.
• Regularly scan GPOs and  file shares for potentially exposed Duo configuration keys and parameters. 
• Ensure any GPOs that define Duo configuration settings are not readable to any authenticated domain user.  Only the target computer accounts should have the ability to read the GPO settings.  Edit permissions for GPOs that include Duo configuration parameters should be restricted to only designated privileged accounts within the domain.
• Ensure the registry keys associated with Duo configuration and deployment GPOs are hardened against low privileged access.  For additional information, reference https://duo.com/docs/winlogon-gpo.
• In the event there were to be a suspected compromise of the secret keys associated with an organization’s Duo tenant, remediation playbooks should include resetting the secret key within Duo Admin panel – and reconfiguring in-scope devices and applications to utilize the newly constituted key. 
• For high security environments, consider stricter Duo policies that can be configured to require additional checks for MFA compliance - including:
  • User location
  • Device Health
  • Operating System
  • Browsers
  • Browser plugins
  • Authorized Networks
  • Authentication Methods
  • Mobile Device security

Conclusion

Enforcing MFA is essential to protecting identities, assets, applications, and data. To effectively understand an organization’s attack surface, potential misconfigurations and bypass methods associated with MFA the technologies must be examined. By doing this, organizations can align proper defenses and guardrails to ensure that MFA enforcement technologies are secured and hardened.