Review: Enzoic for Active Directory

Seemingly every day news drops that a popular site with millions of users had been breached and its user database leaked online. Almost without fail, attackers try to use those leaked user credentials on other sites, making password stuffing one of the most common attacks today.

Users often use the same username/email and password combination for multiple accounts and, unfortunately, enterprise accounts are no exception. Attackers can, therefore, successfully use leaked credentials to access specific company resources.

For example: An attacker wants to target CompanyX and sees that 30 users that work in CompanyX also had their account credentials leaked following a recent breach (let’s say Zynga). Trying to enter those credentials into the company’s SharePoint, Exchange, VPN, and various web portals to see if they might gain access is a no-brainer for them.

This common occurrence has resulted in the launch of several commercial and free solutions that try to mitigate this specific risk. One of them is Enzoic for Active Directory.

About Enzoic for Active Directory and this review

“Enzoic for AD is a tool that integrates into Active Directory and enforces additional password rules to prevent users from using compromised credentials,” the product’s page says.

“Unlike products that only check passwords after they are saved, thus requiring subsequent reset by the user, Enzoic validates the password at the time it is being selected. Passwords are then continuously monitored to detect if they become compromised – with automated remediation and alerts. It helps organizations with NIST Password Guideline compliance in Active Directory.”

We tested the Enzoic for AD solution and this review will focus on the following main points:

1. Setup experience – The solution’s install process and setup process.
2. A cursory overview of the privacy implications of the solution – Since the solution has to query Enzoic’s cloud to verify if a password is contained in a breached set, we decided to check what is actually sent to the cloud.
3. Usefulness and coverage – The effectiveness of the solution when tested against multiple breached credentials lists.
4. Final thoughts and impressions.

Setup experience

The installer for Enzoic for AD is available in both EXE and MSI file format. The software is a plugin for Microsoft Active Directory, which needs to be installed on all AD servers in your organization to achieve coverage.

The installation process begins with a standard Windows install:

Enzoic for Active Directory needs to be configured. Which Users, Groups, Containers should be covered by its functionality to check for compromised password? Will the entire AD be covered? (For this test, we left the default “All Users in Active Directory” option.)

After confirming coverage, monitoring options can be configured. The options are:

1. Reject common passwords found in cracking dictionaries (or not).
2. Check passwords during password resets (or not).
3. Use fuzzy password matching (or not).

In the next step we needed to select the remediation action. The solution allows for the following options:

1. User must change password on next login.
2. User must change password on next login (delayed).
3. Disable account.
4. Disable account (Delayed).
5. Notify only (via email to the user and to a number of other accounts). E-mail is sent by Enzoic (through Amazon SES) and you cannot configure a specific email server to use.

Installation and configuration are simple and easy even for a beginner. After-setup configuration capabilities are also very easy to understand and to tweak.

They include the same options offered at setup-time, plus two additional ones. One allowed adding a custom password dictionary, which can include a word or parts of words that should not appear in a password (e.g., the name of your business). Another setting allowed password blocking based on similarity, according to a configurable distance value that defines how closely a new password can match a previous password.

After a quick mandatory server restart, we proceeded to test the usability of the application.

A cursory overview of the privacy implications of the solution

“Trust but verify,” says an old proverb, so we decided to inject a CA certificate into our AD server, to be able to sniff the communications between our AD server and Enzoic’s servers to see what actually gets shared with Enzoic. We entered a very common password (administrator) and tried to verify it:

As you can see, that password was rejected, but let’s see what was shared on the wire:

In the request you can see that the application takes the input string “administrator” and hashes that value with MD5, SHA1 and SHA256 hashes and sends the first 40 bits of each hash to Enzoic’s cloud, which responds with the possible candidates to check. This is similar to the k-anonymity algorithm used by HaveIBeenPwned’s API service, which shares only the starting 20 bits of SHA1 hash output.

We did not actually try to reverse engineer the application, since this was a cursory review just to make sure that the actual passwords are not being sent to Enzoic’s cloud.

We also left our domain controller (DC) connected to the internet for 48 hours to see what kind of data (if any) is being sent to Enzoic. We found that the app shares some telemetry with the Enzoic cloud, namely the number of matches of breached passwords in the organization and number of users, probably for licensing purposes:

Usefulness and coverage

Next, we wanted to see how Enzoic for AD handles leaked passwords, so we covered a few scenarios that might be interesting to our readers:

• Verifying if the application correctly detects passwords from common wordlists used by attackers.
• Verifying if the application correctly detects passwords from common large-scale breaches (LinkedIn, RockYou).
• Verifying if the application correctly detects passwords from very recent leaks (Zynga).

We decided to take a random sample from SecLists, the LinkedIn and RockYou leaks, and even fully random passwords that were a part of a breached set (e.g., *23P%GWtUPST2jQ&auUB7j542) were correctly identified. We also ran a random sample of passwords from other leaks (e.g., the Hak5 leak) and they were also correctly detected.

One thing that interested us was whether Enzoic for AD could detect passwords from recent leaks. (Un)fortunately, a week before this test the full user database from game company Zynga was leaked on the internet, so we decided to test Enzoic for AD with the newly available leaked passwords.

We sampled passwords randomly but also tried to find unique passwords that were contained in the Zynga breach but not in the sets we used previously. We found a couple of such passwords, and they were successfully detected as breached passwords by Enzoic for AD. Good job!

Looking to the future

We couldn’t test the breached password notification option, since that would require us to actually have users who are a part of an actual breach that is about to occur, which cannot be easily simulated.

Looking forward to the future, there are a few things that could be changed, but are in no way a deal-breaker from our perspective.

The first one is the sharing of three types of hashes and 40 bits of data per hash. We could argue this is excessive since the reference implementation for k-anonymity only shares 20 bits of a single hash.

Enzoic tells us that they chose that length of partial hash as a good balance between anonymity and performance. Keeping the number of candidate hashes returned to a more reasonable number and thus reducing latency for the call is an important concern, since many of their customers are very sensitive to latency.

They view the additional data sent as of minimal risk (keep in mind no usernames are shared and none of these requests are logged on their end). That said, they do have it on their roadmap to make the partial hash match length configurable in the future – with the trade-off that some users might have longer latencies when attempting a password change if this length is significantly reduced.

Secondly, when the user gets notified that a breached password was found, the notification could also contain the information in which breached set that password was found. This would be interesting to both users and security personnel in an organization. We are aware that this information cannot be shared with the user through the standard Windows interface, but it can be sent via email or stored in event logs.

Final verdict

Enzoic for Active Directory is a first-rate solution for ensuring that your users don’t select passwords that were part of a breach. Its coverage of leaked lists is very good, since any list we could legally obtain was correctly flagged by it. Installation is simple and configuration and maintenance are no hassle.

One excellent aspect of this tool is that even someone who is marginally acquainted with Active Directory and has zero experience with Enzoic’s solution can install and make the solution work out of the box. Definitely a 10/10 for user experience.