Product showcase: Specops Password Auditor

They are often the target of many attackers who search for them like gold. Some can be easily found, while others can be more difficult to come by. However, inevitably, they can certainly be the weakest link in the security for your entire organization. What is this highly desirable, often stolen, and targeted resource? Passwords. Specifically, Active Directory passwords.

Most enterprise organizations use Microsoft Active Directory (AD) as their centralized identity and access management solution. The standard AD username and password provide users access to any number of systems, including email, file shares, windows desktops, terminal servers, SharePoint, and many other systems integrated with Active Directory.

End-users often use dangerous, easy to remember passwords for their user accounts, even with Active Directory password policies in place. Finding risky passwords in your environment is more important than you might think. Why is that? How can password security in your organization be bolstered?

Why finding risky passwords is important

Ransomware attacks and data breaches are continuously making news headlines. There is often a common thread among data breach events or ransomware attacks – stolen or weak credentials. Take note of the following:

  • Kaspersky – “The vast majority of data breaches are caused by stolen or weak credentials. If malicious criminals have your username and password combination, they have an open door into your network.”
  • Verizon 2020 DBIR – “Over 80% of breaches within Hacking involve Brute force or the Use of lost or stolen credentials.”
  • Infosecurity Magazine – “A year ago, researchers found that 2.2 billion leaked records, known as Collection 1-5…With this treasure trove, hackers can simply test email and password combinations on different sites, hoping that a user has reused one. This popular technique is known as credential stuffing and is the culprit of many recent data breaches.”

Cybercriminals are after your organization’s passwords. Why are passwords such a target? Put simply, stealing credentials is the path of least resistance into your environment. If an attacker has your username and password combination, they have a “wide open door” to your network and business-critical systems. These may include email, websites, bank accounts, and other PII sources. Even worse, if an attacker can get their hands on administrator credentials, they have the “keys to the kingdom” and can do anything they want.

Attackers use any number of techniques to get their hands on stolen credentials. These may include brute force attacks, password spraying, and also, using databases of leaked passwords. Leaked passwords that result from prior data breaches are also known as pwned passwords.

Passwords are hashed in Active Directory and cannot be read, even by administrators. So, how can you effectively find weak, reused, and even breached passwords in your environment?

Built-in tools are not enough

There is no built-in functionality in Active Directory that natively allows you to check for reused or breached passwords. The only real built-in tool in Active Directory that administrators have at their disposal is Active Directory password policy. Password policies are part of an Active Directory Group Policy Object, and they define the required characteristics for passwords. These characteristics may include uppercase, lowercase, numbers, special characters, and minimum characters. While this helps prevent weak password usage, certain passwords are still easily guessed with letter and number substitutions. Additionally, most organizations enable the minimums for password length and complexity.

Below is an example of a default, unconfigured Active Directory password policy.

Specops Password Auditor

Active Directory password policy

Specops Password Auditor: Bolstering Active Directory password security

Native tools are not enough to protect your environment from weak, reused, and breached credentials. Hackers are quick to capitalize on these types of passwords used to have easy access to your business-critical data. Specops Password Auditor, a free tool, provides an automated tool to proactively scan and find weak, reused, and breached passwords in use in your Active Directory environment. The best part – it makes this process extremely easy.

After installation, define the domain, scan root, and the domain controller you would like to use for the scan process.

Specops Password Auditor

Defining the domain, scan root, and domain controller

The Password Auditor will:

  • Search Active Directory users
  • Read password policies
  • Check for breached passwords
  • Reads user details
  • Check password policy usage
  • Read custom password expiration

Specops Password Auditor

Running the Specops Password Auditor scan

  • Blank passwords
  • Breached passwords
  • Identical passwords
  • Admin accounts
  • Stale admin accounts
  • Password not required
  • Password never expires
  • Expiring passwords
  • Expired Passwords
  • Password policies
  • Password policy usage
  • Password policy compliance

It scans various Active Directory user account attributes, including:

  • pwdLastSet
  • userAccountControl
  • lastLogonTimestamp

After Password Auditor scans the environment, it presents you with an easy-to-read dashboard. The dashboard quickly displays relevant password information. Critical points of interest are noted with the red “bubble tips” with the number of findings for the particular password risk.

Specops Password Auditor

Scan results displaying password risks in the environment

When you click the password finding details, you will see the specific list of user accounts with the password risk displayed. Additionally, Specops Password Auditor shows the location, last logon, and associated password policy of the particular user account.

Specops Password Auditor

Displaying Active Directory user accounts with known breached passwords

Specops Password Auditor allows you to easily handoff official reports to management, internal or external auditors, and others with the Get PDF Report function.

Specops Password Auditor

Generating the Password Auditor report

The Specops Password Auditor executive summary report allows quickly handing over information to business stakeholders in the environment. The report contains concise, easy-to-read information regarding the password audit and risk level.

Specops Password Auditor

The overview page of the Password Auditor report

Conclusion

Cybercriminals are capitalizing on weak, reused, and breached passwords in Active Directory environments. By stealing credentials, attackers gain easy access to business-critical data and systems. There are no native tools found in Active Directory to find reused or breached passwords.

Using Specops Password Auditor allows quickly gaining visibility to weak, reused, and breached passwords in the environment and auditing many other important AD components such as password policies. You can also generate and provide a concise and easy-to-read executive summary report to provide to business stakeholders and auditors.

Learn more about Specops Password Auditor here.

Review: Specops Password Policy

Specops Password Policy is a powerful tool for overcoming the limitations of the default password policies present in Microsoft Active Directory environments. To be fair, Microsoft did revise and upgrade the default password policy and introduced additional, granular fine-tuning options over the years, but for some enterprise environments that’s still not enough, so Specops Password Policy to the rescue!

Installation

For the purpose of this review, the installation was done on a server containing all necessary services: Specops Sentinel – a password filter that is installed on all domain controllers, and Specops Password Policy admin tools. Keep in mind that this can be split onto different servers if needed. If you purchased Breached Password Protection, you’ll need to install Specops Arbiter as well.

The setup process is smooth, and you can expect to be up and running within the hour. As you can see from the image below, the standard requirements are modest and should not be a problem for any enterprise environment that requires such a solution.

Specops Password Policy review

Figure 1. Specops Password Policy minimum requirements

Password policy templates

When you start with Specops Password Policy Domain Administration, you’ll notice four predefined password policy templates you can choose from:

Specops Password Policy review

Figure 2. Specops Password Policy Domain Administration including default templates

These templates are convenient for a fast setup but, naturally, you can take them to another level by customizing them. If you’re working in an environment that needs to meet specific regulatory standards, the provided templates can be a lifesaver. Even if you can’t or don’t want to use these policies, you can use them as a base to strengthen your policy or create a policy compatible with your environment.

Let’s create a new, blank policy to see what the process looks like. Creating one will take you to the Group Policy editor:

Specops Password Policy review

Figure 3. Specops Password Policy inside the Group Policy editor

If you find it familiar, it’s because it is the same environment where you would change your default password policy inside Active Directory. The one key difference here is that Specops Password Policy applies password settings to the user part of group policy rather than computer. This makes more sense as it’s the users that generally set bad passwords rather than machines.

After testing the options and thinking how this would fit into my network, I have to commend Specops for not unnecessarily complicating things and choosing to go with a workflow most system administrators are familiar with.

Passphrases

When I opened Specops Password Policy inside the Group Policy editor, I was pleasantly surprised to see that it supports the use of passphrases. More importantly, it also offers assistance for handling them (something that Active Directory does not). You can use regular expressions so that you can define what a passphrase means to your organization i.e. 3 words, with at least 6 characters in each word, no words should be repeated, and no patterns should be used 111111 222222 etc.

Specops Password Policy review

Figure 4, 5. Passphrase support and password options

The General Settings menu offers familiar settings for anyone that’s used to working with the Group Policy Editor in an Active Directory environment. A neat addition here is the “client message” option, which allows you to create a custom message to be shown on the Active Directory logon screen in case the password policy requirements are not met.

Specops Password Policy review

Figure 6. General Settings with options and client message notification

Password options

The Password Expiration tab offers a wealth of options, including the maximum password age, password expiration notifications, and so on. A key feature here is the length-based password aging rule. This means that the longer the password the longer the user gets to keep it. It can be real incentive to encourage users to move to passphrases.

Specops Password Policy review

Figure 7. Options for password expiration rules and password expiration notifications

The Password Rules menu brings additional password rules granularity which should allow for virtually any password policy scenario. Worth noting is that the use of dictionaries with forbidden words is possible either by creating a custom dictionary or downloading dictionaries provided by Specops.

Specops Password Policy review

Figure 8. Regulating password rules requirements in one place

Specops Password Policy review

Figure 9. Additional protection from users trying to subvert the password policy

Breached Password Protection

A great set of options are found under Breached Password Protection. In a nutshell, it allows the system to compare an Active Directory password to a list of known breached passwords. As might be expected, passwords are hashed in the process.

If a password is discovered in the breached password list, the action triggers the delivery of notifications/alerts.

Specops Password Policy review

Figure 10. Breached Password Protection Complete API

Specops Password Policy review

Figure 11. Breached Password Protection Express List

With the API, Specops Password Policy supports both email and SMS notifications. When using the Express List (a downloadable passwords list) you can use only email notifications.

I realize there’s a narrow application for it, but I would like to see support for custom SMS gateways in future versions, as large enterprises might find this useful. Specops Software tells me that since there’s no extra cost involved for using the SMS notification feature they’ve never been asked to provide a custom SMS platform.

What’s new?

The latest version of Specops Password Policy comes with several powerful new features, Powershell CMDlets and a security scanner.

Leaked password scanning

While Powershell support is nothing new to Specops Password Policy, the latest version brings us powerful new CMDlets:

  • Get-SppPasswordExpiration and Get-PasswordPolicyAffectingUser are user-related CMDlets enabling checks which until now could not be requested nor scripted trough Powershell. I found them rather useful during troubleshooting while trying to discern why a certain policy was not working as intended. Using CMDlets with pretty self-explanatory names is much faster than going through the menus of a newly installed application.
  • Get-SppPasswordExpiration checks for the password expiration date, returning the date and reliability of the password.
  • Get-PasswordPolicyAffectingUser – if you ever handled a multi-policy environment, you know that something simple as knowing the exact policies applied to the user can be the difference between solving an issue or entering a virtually endless troubleshooting loop. You just need to provide the username in sAMAccountName or userPrincipalName format for which the CMDlet returns GpoID, GpoName, and the password policy name.
  • Start-PasswordPolicyLeakedPasswordScanning – As evident from the name, it starts scanning for leaked passwords in your Active Directory environment. Even though this feature is present in the Domain Admin tool, this CMDlet is useful as it can be scripted and delayed, which is ideal for administrators working in large environments. After running the CMDlet, all users that are non-compliant to the policy will be notified on the next logon to change their password. Leaked passwords scanning requires the Specops Breached Password Protection license.

Specops Password Policy review

Figure 12. All available Specops Password Policy CMDlets

Looking after your passwords

Specops Software maintains a comprehensive list of leaked passwords based on numerous sources. It contains billions of passwords and is often updated.

Breached Password Protection can be configured with two settings: Breached Password Protection Complete and Breached Password Protection Express.

The Complete setting comes with a master list of leaked passwords that are stored in the cloud. If a user changes their password to one that can be found on the list, a notification is sent via email or SMS, and they are forced to change their password the next time they log in. For this, you’ll need .Net 4.7.1 and Windows Server 2012 R2 or later, with an installation of Specops Arbiter and an API key.

Breached Password Protection Express downloads a subset of the list of leaked passwords, updated usually every 6 months. This also means administrators will need to manually check for updates and initiate a download of the updated list. Users are also immediately prevented from changing their password to a password found in the leaked list.

Length based password expiration

Specops has found a way to reward security-conscious users by extending the timeframe for mandated password change.

Specops Password Policy review

Figure 13. The longer the password, the later it expires

Users can be notified of their upcoming mandated password change. As the timeframe for mandated password change is dictated by password length, notifying users is of great importance as it can help user to prepare in advance. The notification can be shown to the users using regular Active Directory resources, on the logon screen or via email. For both methods you can define the number of days before a mandated password change notification is shown or sent.

Password Auditor

This is a security scanner for Active Directory, and it’s such a simple yet invaluable tool. It is included in Specops Password Policy and is available as standalone freeware. It groups all possible password security issues found inside your Active Directory. This at-a-glance overview essentially points out all the things you need to worry about, and it’s the place to discover quickly if there’s a problem you might not be aware of like a password being on a leaked list.

Specops has chosen smart way of aggregating important areas around password security and polices, showing the most relevant issues and offering quick insight of potential issues.

Specops Password Policy review

Figure 14. A closer look at expiring passwords

Once you’re aware of all the issues, you can quickly focus on what’s critical. I find this to be an easy way to audit your Active Directory environment for a variety of issues at the same time.

Conclusion

After testing Specops Password Policy for a week in a variety of scenarios, I can definitely say we’re talking about a formidable solution. Not only does it make the process of strengthening the password policies better while being simple to use, but it can detect and resolve issues you might not be aware of in the first place.

I can highly recommend Specops Password Policy for any Active Directory environment, and I would go as far as to say it’s a necessity for complex environments dealing with compliance regulations, as well as specific password policy requirements. This solution can raise security level on any Active Directory environment, and you can’t argue about the benefits of better security, can you?

Moving past the madness of manually updated X.509 certificates

Microsoft’s Active Directory (AD) is by far the most widely used enterprise repository for digital identities. Microsoft Active Directory Certificate Services (ADCS) is an integrated, optional component of Windows Server designed to issue digital certificates.

Since it’s a built-in and “free” option, it’s no surprise that ADCS has been widely embraced by enterprises around the world. An on-premises or cloud/hybrid public key infrastructure (PKI) has proven to be more secure and easier to use than passwords, and is far easier to deal with when automated certificate management is integrated into AD.

For organizations operating an AD environment, the ability to leverage the certificate template information already included in Microsoft certificate services can make running a Microsoft CA extremely appealing. Since AD and Microsoft certificate services are connected, you can seamlessly register and provision certificates to all domain-connected objects based on group policies. Auto enrollment and silent installation make certificate enrollment and renewal easy for IT administrators and end users alike.

One of the greatest advantages of the Microsoft CA is automation, but that advantage does not extend to endpoints outside the Windows environment. Unfortunately, there are no free or open source Linux, UNIX or Mac tools available today that provide auto-enrollment or integrate with the Microsoft CA. The only “free” option is to manually create and renew certificates from a Microsoft CA using complicated and error-prone commands.

Within enterprise networks, Linux is often used for critical services that require X.509 trusted certificates. One typical need is for an SSL/TLS Server Authentication certificate, or web server certificate, on Red Hat Enterprise Linux (RHEL), Ubuntu server, or other Linux distributions. Certificates are also often needed on many other endpoints, including macOS-based systems, and to provide trusted security for enterprise applications.

The traditional process of creating a X.509 certificate on Linux, UNIX or macOS manually requires a working level of PKI knowledge and can take three to six hours to complete. You have to generate a key pair, create a Certificate Signing Request (CSR), submit it to a Certificate Authority (CA), wait for a PKI administrator to issue a certificate, download the certificate, configure and update the application using the service, and finally verify that it’s active. An example of what’s involved in creating a CSR using Open SSL is shown in Figure 1.

OPIS

Figure 1. Using OpenSSL to create a CSR requires knowledge of enterprise PKI policies for keys and certificates and filling in lots of details by hand.

A few years ago, when multi-year certificate lifespans were the norm and certificate volumes were lower, a few manually issued certificates weren’t seen as a big problem. When exceptions like a Linux or Mac system came up, they were handled on a one-off basis. This in turn led to the creation of manual processes. Such processes were easily justified by saying that the certificates could be easily tracked using a spreadsheet, and since the numbers were small and certificate renewals were years apart, it wasn’t worth the effort to get a product to solve the problem when the existing solution was sufficient.

Now, however, that has most definitely changed. Apple, Google and Mozilla have implemented policies that went to effect on Sept. 1, 2020 and that say that any new website certificate valid for more than 398 days will not be trusted by their respective browsers and instead will be rejected. Adding to the certificate management problem is the dramatic increase in the number of device and applications that require certificates, often numbering into the thousands or more.

Looking across the industry landscape, there are third-party certificate management systems (CMS) that can automate enterprise certificate processes more broadly, but such systems have require large-scale “rip and replace”. You have to deeply integrate each Linux system with Active Directory, including switching your system user authentication over as well.

This requires extensive changes to existing Linux and Microsoft infrastructure, staff re-training, and additional software licensing costs. The “rip and replace” approach also requires implementation time frames ranging from a few months to a few years for complex PKIs.

The advantage of such an approach – once you’ve worked through the implementation process – is end-to-end automation. When a CMS is used to create a certificate, it has all the data it needs to not only monitor the certificate for expiration but automatically provision a replacement certificate without human intervention.

While some CMS solutions can be incredibly complex, expensive, and time-consuming to install, there is a new generation of CMS offerings designed to simply extend the Microsoft-based PKI to encompass certificates on systems and applications outside the purview of Active Directory.

Such systems install into an existing Microsoft ADCS environment and mirror Windows certificate auto enrollment onto Linux, Unix or macOS systems. Certificates can be automatically created by registered computers from a central management console. Alternatively, as shown in Figure 2, the administrator of an end-node can request a certificate using one simple command without knowing how to create a keypair, generate a certificate request or know how to translate difficult to understand enrollment templates, formats and attribute requirements.

OPIS

Figure 2. Creating a CSR is greatly simplified through automation and requires no PKI expertise.

Once issued, this command will automatically create a CSR, submit it to the enterprise Microsoft CA, and install the certificate after it has been issued. This is done using pre-configured PKI policies stored on the enterprise CA. The policies are set up based on the role or purpose of the certificate. Because these policies are pre-defined, the system admin doesn’t need to know anything beyond the role or purpose of the system they are setting up.

Once the certificate has been installed, the admin can move on to other tasks with the knowledge that the enterprise CA will automatically renew the certificate without further intervention. And because the certificate was created by the enterprise CA and not self-signed, the certificate is automatically verifiable by any application in the enterprise.

With the certificate lifetimes already getting shorter, and likely to continue getting shorter, the need for automated certificate management has never been greater. While the Microsoft CA addresses the automation challenge within the Active Directory environment, far too many enterprises are still relying on manual processes for non-Microsoft systems and applications. Rather than abandon the Microsoft CA at considerable expense and disruption, it may be time to consider a certificate management option that bring the benefits of ADCS to the entire enterprise.

Securing Active Directory accounts against password-based attacks

Traditional password-based security might be headed for extinction, but that moment is still far off.

In the meantime, most of us need something to prevent our worst instincts when it comes to choosing passwords: using personal information, predictable (e.g., sequential) keystroke patterns, password variations, well-known substitutions, single words from a dictionary and – above all – reusing the same password for many different private and enterprise accounts.

What does a modern password policy look like?

While using unique passwords for every account is a piece of advice that has withstood the test of time (though not the test of widespread compliance), people also used to be told that they should use a mix of letters, numbers and symbols and to change it every 90 days – recommendations that the evolving threat landscape has made obsolete and even somewhat harmful.

In the past decade, academic research on the topic of password practices and insights gleaned from passwords compromised in breaches have revealed what people were actually doing when they were creating passwords. This helped unseat some of the prevailing password policies that were in place for so long, Josh Horwitz, Chief Operations Officer of Enzoic, told Help Net Security.

The latest NIST-sanctioned advice regarding enterprise password policies (as delineated in NIST Special Publication 800-63B) includes, among other things, the removal of the requirement for character composition rules and for mandatory periodic password changes. Those are recommendations that are also being promulgated by Microsoft.

As data breaches now happen every single day and attackers are trying out the revealed passwords on different accounts in the hope that the user has reused them, NIST also advises companies to verify that passwords are not compromised before they are activated and check their status on an ongoing basis, against a dynamic database comprised of known compromised credentials.

The need for modern tools

But the thing is, most older password policy tools don’t provide a method to check if a password is strong and not compromised once the password is chosen/set.

There’s really only one that both checks the passwords at creation and continuously monitors their resilience to credential stuffing attacks, by checking them against a massive (7+ billion) database of compromised credentials that is updated every single day.

OPIS

“Some organizations will gather this information from the dark web and other places where you can get lists of compromised passwords, but most tools aren’t designed to incorporate it and it’s still a very manual process to try to keep that information up to date. It’s effectively really hard to maintain the breadth and frequency of data updates that are required for this approach to work as it should,” Horwitz noted.

But for Enzoic, this is practically one of its core missions.

“We have people whose full-time job is to go out and gather threat intelligence, databases of compromised passwords, and cracking dictionaries. We’ve also invested substantially in proprietary technology to automate that process of collection, cleansing and indexing of that information,” he explained.

“Our database is updated multiple times each day, and we’re really getting the breadth of data out there, by integrating both large and small compromised databases in our list – because hackers will use any database they can get their hands on, not just those stolen in well-publicized data breaches.”

Enzoic for Active Directory

This constantly updated list/database is what powers Enzoic for Active Directory, a tool (plug-in) that integrates into Active Directory and enforces additional password rules to prevent users from using compromised credentials.

The solution checks the password both when it’s created and when it’s reset and checks it daily against this real-time compromised password database. Furthermore, it does so automatically, without the IT team having to do anything except set it up once.

OPIS

Enzoic for AD is able to detect and prevent the use of:

  • Fuzzy variations of compromised passwords
  • Unsafe passwords consisting of an often-used root word and a few trailing symbols and numbers
  • New passwords that are too similar to the one the user previously used
  • Passwords that employees at specific organizations are expected to choose (this is accomplished by using a custom dictionary that can be tailored to each organization)

The tool uses a standard password filter object to create a new password policy that works anywhere that defers to Active Directory, including Azure AD and third-party password reset tools.

Can multi-factor authentication save us?

Many will wonder whether such a tool is really crucial for keeping AD accounts safe. “What if we also use multi-factor authentication? Doesn’t that solve our authentication problems and keeps us safe from attacks?”

In reality, password remain part in every environment, and not every authentication event includes multi-factor authentication (MFA).

“You can offer MFA, but until you actually require its use and get rid of the password, there’s always going to be doors in that the attackers can use,” Horwitz pointed out.

“NIST also makes it very clear that authentication security should include multiple layers, and that each of these layers – including the password layer – need to be hardened.”

Do you really need Enzoic for Active Directory?

Enzoic has made it easy for enterprises to check whether some of the AD passwords used by their employees are weak or have been compromised: they can deploy a free password auditing tool (Enzoic for Active Directory Lite) to take a quick snapshot of their domain’s password security state.

OPIS

“Some password auditing tools take long time to try to brute-force passwords, but attackers are much more likely to start their efforts with compromised passwords,” Horwitz added.

“Our tool takes just minutes to perform the audit, it’s simple to run, and allows IT and IT security leaders and professionals to realize the extent of the problem and to easily communicate the issue to the business side.”

Enzoic for Active Directory is likewise simple to install and use, and is built for easy implementation and automatic maintenance of the modern password policy.

“It’s a low complexity tool, but this is where it really shines: it allows you to screen passwords against a massive database of compromised passwords that gets updated every day – and allows you to do this at lightning speed, so that it can be done at the time that the password is being created without any friction or interruption to the user – and it rechecks that password each day, to detect when a password is no longer secure and trigger/mandate a password change.“

Aside from checking the passwords against this constantly updated list, it also prevents users from using:

  • Common dictionary words or words that are often used for passwords (e.g., names of sports teams)
  • Expected passwords and those that are too similar to users’ old password
  • Context-specific passwords and variations (e.g., words that are specific to the business the enterprise is in, or words that employees living in a specific town or region might use)
  • User-specific passwords and variations (e.g., their first name, last name, username, email address – based on those field values in Active Directory)

Conclusion

Time and time again, it has been proven that if left to their own devices, users will employ predictable patterns when choosing a password and will reuse one password over multiple accounts.

When the compromised account doesn’t hold sensitive information or allows access to sensitive assets, these practices might not lead to catastrophic results for the user. But the stakes are much higher when it comes to enterprise accounts, and especially Active Directory accounts, as AD is most companies’ primary solution for access to network resources.

Most organizations have no Active Directory cyber disaster recovery plan

Although 97% of organizations said that Active Directory (AD) is mission-critical, more than half never actually tested their AD cyber disaster recovery process or do not have a plan in place at all, a Semperis survey of over 350 identity-centric security leaders reveals.

Active Directory recovery plan

“The expanded work-from-home environment makes organizational identity a priority and also increases the attack surface relative to Active Directory,” said Charles Kolodgy, Principal at Security Mindsets.

Key research findings

  • AD outages have a serious business impact. 97% of respondents said that AD is mission-critical to the business, and 84% said that an AD outage would be significant, severe, or catastrophic.
  • AD recovery failure rate is high. 71% of respondents were only somewhat confident, not confident, or unsure about their ability to recover AD to new servers in a timely fashion. Only a tiny portion (3%) said they were “extremely confident.”
  • AD recovery processes remain largely untested. Exactly 33% of organizations said they have an AD cyber disaster recovery plan but never tested it, while 21% have no plan in place at all. Out of the entire poll, just 15% of respondents said they had tested their AD recovery plan in the last six months.
  • Organizations expressed many concerns about AD recovery, with the lack of testing being the number one concern. This includes organizations that have not tested AD recovery at all and those who have tried but failed.

“In today’s cloud-first, mobile-first world, dependency on Active Directory is rapidly growing and so is the attack surface,” said Thomas LeDuc, VP of Marketing at Semperis. “One survey respondent even noted that a prolonged AD outage would be akin to a nuclear inferno. So, it’s clear that while organizations understand the importance of AD, they are a step behind in securely managing it, particularly as they support an expanding ecosystem of mobile workers, cloud services, and devices.”

As the gatekeeper to critical applications and data in 90% of organizations worldwide, AD has become a prime target for widespread cyberattacks that have crippled businesses and wreaked havoc on governments and non-profits.

Active Directory recovery plan

Active Directory recovery plan

  • Minimize Active Directory’s attack surface: Lock down administrative access to the Active Directory service by implementing administrative tiering and secure administrative workstations, apply recommended policies and settings, and scan regularly for misconfigurations – accidental or malicious – that potentially expose your forest to abuse or attack.
  • Monitor Active Directory for signs of compromise and roll back unauthorized changes: Enable both basic and advanced auditing and periodically review key events via a centralized console. Monitor object and attribute changes at the directory level and changes shared across domain controllers.
  • Implement a scorched-earth recovery strategy in the event of a large-scale compromise: Widespread encryption of your network, including Active Directory, requires a solid, highly automated recovery strategy that includes offline backups for all your infrastructure components as well as the ability to restore those backups without reintroducing any malware that might be on them.

Critical ManageEngine ADSelfService Plus RCE flaw patched

A critical vulnerability (CVE-2020-11552) in ManageEngine ADSelfService Plus, an Active Directory password-reset solution, could allow attackers to remotely execute commands with system level privileges on the target Windows host.

CVE-2020-11552

About ManageEngine ADSelfService Plus

ManageEngine ADSelfService Plus is developed by ManageEngine, a division of Zoho Corporation, a software development company that focuses on web-based business tools and information technology.

“ADSelfService Plus supports self-service password reset for WFH and remote users by enabling users to reset Windows password from their own machines and updating the cached credentials through a VPN client,” the company touts.

It also supports sending password expiration notifications to remote users through email, SMS, and push notifications; provides admins with a way to force 2-factor authentication for Windows logons; and provides users with secure access to all SAML-supported enterprise applications (e.g., Office 365, G Suite, Salesforce) through AD-based single sign-on.

About the vulnerability (CVE-2020-11552)

Unearthed and flagged by Bhadresh Patel, CVE-2020-11552 stems from the solution not properly enforcing user privileges associated with Windows Certificate Dialog.

The ManageEngineADSelfService Plus thick client software enables users to perform a password reset or an account unlock action by using self-service option on the Windows login screen. When one of these options is selected, the client software is launched and connects to a remote ADSelfServicePlus server to facilitate the self-service operations.

“A security alert can/will be triggered when ‘an unauthenticated attacker having physical access to the host issues a self-signed SSLcertificate to the client’. Or, ‘a (default) self-signed SSLcertificate is configured on ADSelfService Plus server’,” he noted.

“‘ViewCertificate’ option from the security alert will allow an attacker with physical access or a remote attacker with RDP access, to export a displayed certificate to a file. This will further cascade to the standard dialog/wizard which will open file explorer as SYSTEM. By navigating file explorer through ‘C:windowssystem32’, acmd.exe can be launched as a SYSTEM.”

Patel also published a PoC exploit video (the exploitation part starts at 5:30):

[embedded content]

ManageEngine patched CVE-2020-11552 twice, because the first patch only fixed the issue partially. Admins are advised to upgrade to ADSelfService Plus build 6003, which contains the complete security fix.

New propagation module makes Trickbot more stealthy

Trickbot infections of Domain Controller (DC) servers has become more difficult to detect due to a new propagation module that makes the malware run from memory, Palo Alto Networks researchers have found.

That also means that the malware infection can’t survive a shutdown or reboot of the system, but the stealth vs persistence tradeoff is likely to work in the attackers’ favor since servers are rarely shut down or rebooted.

Trickbot’s evolution

Trickbot started as a banking Trojan / information stealer. It was first detected in late 2016 and it’s believed to be the work of the same developers that created the Dyre (aka Dyreza) credential stealer malware.

As predicted at the time, the malware has become a serious threat. Thanks to its modular architecture, the malicious developers have steadily equipped it with additional capabilities, including the ability to disable Microsoft’s built-in antivirus Windows Defender, gather system and account information, send out spam, and spread to other computers on the same network by exploiting SMB vulnerabilities.

Trickbot is also often dropped by Emotet as a secondary payload or is delivered via booby-trapped email attachments, but its lateral propagation mechanism is a big reason why it’s become the bane of many a company’s existence.

A more stealthy mechanism for infecting Domain Controllers

“Trickbot uses modules to perform different functions, and one key function is propagating from an infected Windows client to a vulnerable Domain Controller (DC),” the researchers explained.

Up until April 2020, the malware used three modules for propagation: mshare, tab and mworm:

Trickbot propagation

Since then, the mworm module has been swapped with the nworm module, which:

  • Retrieves an encrypted or encoded malware binary via HTTP traffic (mworm retrieved an unencrypted/unencoded binary)
  • Decodes the binary and runs it in the victim system’s RAM, leaving no discoverable artifacts on an infected DC

Trickbot propagation

As noted before, the in-memory-malware can’t survive a system reboot or shutdown, but the creators are betting on DCs being continuously operational for a long while.

The importance of preventing Trickbot infections

We already know that Trickbot developers are constantly working on improving the malware. This is just the latest improvement and evolution step to stay one step ahead of the defenders.

The best way to keep Trickbot infections at bay is to constantly and promptly update and patch Microsoft clients and servers. Patching the SMB vulnerabilities exploited by Trickbot to propagate laterally on the network is essential to preventing constant reinfections.

The malware, on its own, is definitely bad new for enterprises, but Trickbot infections are also likely to be just one small part of a larger attack that will end with ransomware being deployed on many company systems and an even bigger headache to the victim organizations.

Microsoft Buys Corp.com So Bad Guys Can’t

In February, KrebsOnSecurity told the story of a private citizen auctioning off the dangerous domain corp.com for the starting price of $1.7 million. Domain experts called corp.com dangerous because years of testing showed whoever wields it would have access to an unending stream of passwords, email and other sensitive data from hundreds of thousands of Microsoft Windows PCs at major companies around the globe. This week, Microsoft Corp. agreed to buy the domain in a bid to keep it out of the hands of those who might abuse its awesome power.

Wisconsin native Mike O’Connor, who bought corp.com 26 years ago but has done very little with it since, said he hoped Microsoft would buy it because hundreds of thousands of confused Windows PCs are constantly trying to share sensitive data with corp.com. Also, early versions of Windows actually encouraged the adoption of insecure settings that made it more likely Windows computers might try to share sensitive data with corp.com.

From February’s piece:

At issue is a problem known as “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.

Windows computers on an internal corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” which is a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.

For instance, if a company runs an internal network with the name internalnetwork.example.com, and an employee on that network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; typing “drive1” alone will suffice, and Windows takes care of the rest.

But things can get far trickier with an internal Windows domain that does not map back to a second-level domain the organization actually owns and controls. And unfortunately, in early versions of Windows that supported Active Directory — Windows 2000 Server, for example — the default or example Active Directory path was given as “corp,” and many companies apparently adopted this setting without modifying it to include a domain they controlled.

Compounding things further, some companies then went on to build (and/or assimilate) vast networks of networks on top of this erroneous setting.

Now, none of this was much of a security concern back in the day when it was impractical for employees to lug their bulky desktop computers and monitors outside of the corporate network. But what happens when an employee working at a company with an Active Directory network path called “corp” takes a company laptop to the local Starbucks?

Chances are good that at least some resources on the employee’s laptop will still try to access that internal “corp” domain. And because of the way DNS name devolution works on Windows, that company laptop online via the Starbucks wireless connection is likely to then seek those same resources at “corp.com.”

In practical terms, this means that whoever controls corp.com can passively intercept private communications from hundreds of thousands of computers that end up being taken outside of a corporate environment which uses this “corp” designation for its Active Directory domain.

The story went on to describe how years of testing — some of which was subsidized by grants from the U.S. Department of Homeland Security — showed hundreds of thousands of Windows computers were constantly trying to send this domain information it had no business receiving, including attempts to log in to internal corporate networks and access specific file shares on those networks.

O’Connor told me he was selling the domain after doing basically nothing with it for 26 years because he was getting on in years and didn’t want his kids to inherit this mess. When he put the domain up for sale, I asked if he’d agree to let me know if and when he sold it.

On Monday evening, he wrote to say that Microsoft had agreed to purchase it. O’Connor said he could  not discuss the terms of the deal, nor could he offer further comment beyond acknowledging the sale of corp.com to Microsoft.

In a written statement, Microsoft said it acquired the domain to protect its customers.

“To help in keeping systems protected we encourage customers to practice safe security habits when planning for internal domain and network names,” the statement reads. “We released a security advisory in June of 2009 and a security update that helps keep customers safe. In our ongoing commitment to customer security, we also acquired the Corp.com domain.”

Over the years, Microsoft has shipped several software updates to help decrease the likelihood of namespace collisions that could create a security problem for companies that still rely on Active Directory domains that do not map to a domain they control.

However, experts say hardly any vulnerable organizations have deployed these fixes for two reasons. First, doing so requires the organization to take down its entire Active Directory network simultaneously for some period of time.

Second, according to Microsoft applying the patch(es) will likely break or at least slow down a number of applications that the affected organization relies upon for day-to-day operations. Faced with either or both of these scenarios, most affected companies probably decided the actual risk of not applying these updates was comparatively low.

It should be noted that while Microsoft’s purchase of corp.com will safeguard companies that built Active Directory infrastructures on top of “corp” or “corp.com,” any company that has tied their internal Active Directory network to a domain they do not control is opening itself to a similar potential security nightmare.

Further reading:

Mitigating the Risk of DNS Namespace Collisions (PDF)

DEFCON 21 – DNS May Be Hazardous to your Health (Robert Stucke)

Mitigating the Risk of Name Collision-Based Man-in-the-Middle Attacks (PDF)

Review: Specops Key Recovery

Mobile device use continues to grow, while an increasingly mobile and remote workforce depends heavily on laptops. To secure those devices, organizations need to implement client-side security controls.

One of the more pressing risks linked to the use of mobile devices is the possibility of device loss or theft. If a device is lost, sensitive data (e.g., documents, account passwords) might get extracted and exposed.

One solution for this problem is full disk encryption, and one of the most popular systems is Microsoft BitLocker, which is part of every Windows 10 installation.

What happens when one of your users forgets their full disk encryption passphrase, or if this hasn’t been set up, simply plugs in new hardware that triggers a BitLocker Recovery Mode? If your organization uses Microsoft Active Directory and has set up the environment to store the recovery keys in AD, a system administrator can restore that machine.

Of course, the user will still need to contact their organization’s helpdesk, which will need to verify their identity in order to share the recovery key. Common problems with this scenario are issues with verifying the identity of the user and increased workload for the system administrators/helpdesk personnel.

Introducing Specops Key Recovery

Specops Software realized these problems and offers an interesting solution: Specops Key Recovery, a self-service tool for recovering BitLocker recovery keys.

Instead of contacting the helpdesk, which needs a way to verify the identity of a person over the phone (a hard problem to solve with high confidence given the lack of physical presence), Specops Key Recovery offers a cloud centric self-service portal.

An infographic from Specops illustrates the concept:

Review Specops Key Recovery

The user’s perspective (enrollment)

The user enrolls or can be pre-enrolled into the service. Pre-enrollment is achieved when an administrator selects identity services that leverage existing Active Directory details. When a user is pre-enrolled this means that he/she does not have to enroll but rather when a lock out occurs can utilize the system to authenticate identity and retrieve a recovery key.

However, it’s best practice to extend additional identity services to users to minimize failure for example if an identity service is unavailable. Enrollment will require the user to successfully login and enroll with any combination of identity services extended to them by their system admin. The solution supports a number of identity services that can serve as multi-factor authentication options, depending on the authentication policy set by the administrator. These include:

a. SMS (mobile code)
b. Windows Identity
c. Authenticators: Google, Microsoft, Specops
d. Service logins: Google, Facebook, LinkedIn, Live, Tumblr, Twitter
e. Other: Specops Fingerprint, Secret questions, Manager Identification

Administrators can vary the enrollment policy from the authentication policy to ensure that users have additional options when authenticating. Each service can be assigned a security weight reflected by stars. This depicts the security assurance level assigned to each service for example the screenshot below depicts Mobile Code as having a weight of two stars versus Security Questions which has a weight of one. Weights ensure that users are provided with options but that the alternatives are not sacrificing security as the required authentication weight will still have to be satisfied.

This screenshot of the administration interface illustrates the choices/flexibility:

Review Specops Key Recovery

The user’s perspective (use)

In the event of an encryption lock out, users are greeted with the infamous BitLocker Recovery screen:

Review Specops Key Recovery

Specops Key Recovery makes it possible for the user to visit a self-service portal via another device (e.g., a mobile phone) and verify their identity using a number of authentication factors provided by the previously enrolled identity services.

Review Specops Key Recovery

After proving their identity, they can enter the first 8 characters from the recovery key ID, press “Continue” and get the Bitlocker recovery key:

Review Specops Key Recovery

Review Specops Key Recovery

So, in a nutshell: enrolled users can recover access to their machine without having to ask the helpdesk for assistance. This is a cost savings but at the same time does not sacrifice security as users have to verify their identity before recovering access. This is what Specops Key Recovery does very well.

The sysadmin’s perspective (installation, setup, management)

To operate Specops Key Recovery, a sysadmin needs to set up multiple elements:

1. Register an account on the Specops cloud service.
2. Install the Specops Authentication Gatekeeper Administration tool on their Domain Controller (DC).
3. Set up the group policy to store the recovery passwords and key packages in the Active Directory Domain Services (AD DS).
4. Configure the service according to their required policies.

We particularly liked the fact that during account registration Specops Key Recovery insists on enabling 2-factor authentication (2FA). It’s SMS-based 2FA, but that’s still better than no 2FA, and you can swap it with something else later on. It’s also great that the system checks for common blacklisted passwords, adds a reCAPTCHA to curb automated attacks (which can be enforced or disabled), and has a default level logging and reports.

Review Specops Key Recovery

Review Specops Key Recovery

The cloud user management component is the solutions service desk. It allows the IT helpdesk to verify users’ identities using the same MFA factors they enrolled with before performing sensitive tasks such as recovering keys or resetting passwords. The interface also presents helpdesk users with details such as enrollment and authentication information. For example:

Review Specops Key Recovery

From the AD-tooling side of things, installation is straightforward and the documentation covers the entire process in enough detail that any junior system administrator could set the system up.

If we really wanted to nitpick, we could suggest that the documentation or the tool itself could help admins set up the group policy to store the recovery passwords and key packages in the AD DS.

Review Specops Key Recovery

Final verdict

If you have a large, distributed and remote workforce, you will benefit from the increased security and convenience offered by the solution.

Although we only illustrated the key recovery option, the Specops Authentication platform also offers additional account management features like password reset, change, and account unlocking – all utilizing the same multi-factor authentication engine. One important feature that stands out for those with a global workforce is geo-blocking, which may prove to be helpful in a number of situations.

From a diagnostics standpoint, it’s easy enough to see if your Gatekeeper software is working on the DC, and the variety of supported identity services provides enough freedom/ flexibility for anyone to specify which service or method they trust and how much.

Customers will appreciate the fact that the web interface can be customized and the self-service portal can be integrated with the specific visual style of an organization.

By default, the application logs privileged events like key recovery to Windows events. Reporting is also available through a dashboard, where one can search for specific events. One thing I would love to see is the actual information about user logins to the cloud service in the event logs.

Specops Key Recovery helps system administrators and users: it removes complexity and successfully solves a common problem.

Dangerous Domain Corp.com Goes Up for Sale

As an early domain name investor, Mike O’Connor had by 1994 snatched up several choice online destinations, including bar.com, cafes.com, grill.com, place.com, pub.com and television.com. Some he sold over the years, but for the past 26 years O’Connor refused to auction perhaps the most sensitive domain in his stable — corp.com. It is sensitive because years of testing shows whoever wields it would have access to an unending stream of passwords, email and other proprietary data belonging to hundreds of thousands of systems at major companies around the globe.

Now, facing 70 and seeking to simplify his estate, O’Connor is finally selling corp.com. The asking price — $1.7 million — is hardly outlandish for a 4-letter domain with such strong commercial appeal. O’Connor said he hopes Microsoft Corp. will buy it, but fears they won’t and instead it will get snatched up by someone working with organized cybercriminals or state-funded hacking groups bent on undermining the interests of Western corporations.

One reason O’Connor hopes Microsoft will buy it is that by virtue of the unique way Windows handles resolving domain names on a local network, virtually all of the computers trying to share sensitive data with corp.com are somewhat confused Windows PCs. More importantly, early versions of Windows actually encouraged the adoption of insecure settings that made it more likely Windows computers might try to share sensitive data with corp.com.

At issue is a problem known as “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.

Windows computers on an internal corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” which is a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.

For instance, if a company runs an internal network with the name internalnetwork.example.com, and an employee on that network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; typing “drive1” alone will suffice, and Windows takes care of the rest.

But things can get far trickier with an internal Windows domain that does not map back to a second-level domain the organization actually owns and controls. And unfortunately, in early versions of Windows that supported Active Directory — Windows 2000 Server, for example — the default or example Active Directory path was given as “corp,” and many companies apparently adopted this setting without modifying it to include a domain they controlled.

Compounding things further, some companies then went on to build (and/or assimilate) vast networks of networks on top of this erroneous setting.

Now, none of this was much of a security concern back in the day when it was impractical for employees to lug their bulky desktop computers and monitors outside of the corporate network. But what happens when an employee working at a company with an Active Directory network path called “corp” takes a company laptop to the local Starbucks?

Chances are good that at least some resources on the employee’s laptop will still try to access that internal “corp” domain. And because of the way DNS name devolution works on Windows, that company laptop online via the Starbucks wireless connection is likely to then seek those same resources at “corp.com.”

In practical terms, this means that whoever controls corp.com can passively intercept private communications from hundreds of thousands of computers that end up being taken outside of a corporate environment which uses this “corp” designation for its Active Directory domain.

INSTANT CORPORATE BOTNET, ANYONE?

That’s according to Jeff Schmidt, a security expert who conducted a lengthy study on DNS namespace collisions funded in part by grants from the U.S. Department of Homeland Security. As part of that analysis, Schmidt convinced O’Connor to hold off selling corp.com so he and others could better understand and document the volume and types of traffic flowing to it each day.

During an eight month analysis of wayward internal corporate traffic destined for corp.com in 2019, Schmidt found more than 375,000 Windows PCs were trying to send this domain information it had no business receiving — including attempts to log in to internal corporate networks and access specific file shares on those networks.

For a brief period during that testing, Schmidt’s company JAS Global Advisors accepted connections at corp.com that mimicked the way local Windows networks handle logins and file-sharing attempts.

“It was terrifying,” Schmidt said. “We discontinued the experiment after 15 minutes and destroyed the data. A well-known offensive tester that consulted with JAS on this remarked that during the experiment it was ‘raining credentials’ and that he’d never seen anything like it.”

Likewise, JAS temporarily configured corp.com to accept incoming email.

“After about an hour we received in excess of 12 million emails and discontinued the experiment,” Schmidt said. “While the vast majority of the emails were of an automated nature, we found some of the emails to be sensitive and thus destroyed the entire corpus without further analysis.”

Schmidt said he and others concluded that whoever ends up controlling corp.com could have an instant botnet of well-connected enterprise machines.

“Hundreds of thousands of machines directly exploitable and countless more exploitable via lateral movement once in the enterprise,” he said. “Want an instant foothold into about 30 of the world’s largest companies according to the Forbes Global 2000? Control corp.com.”

THE EARLY ADVENTURES OF CORP.COM

Schmidt’s findings closely mirror what O’Connor discovered in the few years corp.com was live on the Internet after he initially registered it back in 1994. O’Connor said early versions of a now-defunct Web site building tool called Microsoft FrontPage suggested corporation.com (another domain registered early on by O’Connor) as an example domain in its setup wizard.

That experience, portions of which are still indexed by the indispensable Internet Archive, saw O’Connor briefly redirecting queries for the domain to the Web site of a local adult sex toy shop as a joke. He soon got angry emails from confused people who’d also CC’d Microsoft co-founder Bill Gates.

Archive.org’s index of corp.com from 1997, when its owner Mike O’Connor briefly enabled a Web site mainly to shame Microsoft for the default settings of its software.

O’Connor said he also briefly enabled an email server on corp.com, mainly out of morbid curiosity to see what would happen next.

“Right away I started getting sensitive emails, including pre-releases of corporate financial filings with The U.S. Securities and Exchange Commission, human resources reports and all kinds of scary things,” O’Connor recalled in an interview with KrebsOnSecurity. “For a while, I would try to correspond back to corporations that were making these mistakes, but most of them didn’t know what to do with that. So I finally just turned it off.”

TOXIC WASTE CLEANUP IS HARD

Microsoft declined to answer specific questions in response to Schmidt’s findings on the wayward corp.com traffic. But a spokesperson for the company shared a written statement acknowledging that “we sometimes reference ‘corp’ as a label in our naming documentation.”

“We recommend customers own second level domains to prevent being routed to the internet,” the statement reads, linking to this Microsoft Technet article on best practices for setting up domains in Active Directory.

Over the years, Microsoft has shipped several software updates to help decrease the likelihood of namespace collisions that could create a security problem for companies that still rely on Active Directory domains that do not map to a domain they control.

But both O’Connor and Schmidt say hardly any vulnerable organizations have deployed these fixes for two reasons. First, doing so requires the organization to take down its entire Active Directory network simultaneously for some period of time. Second, according to Microsoft applying the patch(es) will likely break or at least slow down a number of applications that the affected organization relies upon for day-to-day operations.

Faced with either or both of these scenarios, most affected companies probably decided the actual risk of not applying these updates was comparatively low, O’Connor said.

“The problem is that when you read the instructions for doing the repair, you realize that what they’re saying is, ‘Okay Megacorp, in order to apply this patch and for everything to work right, you have to take down all of your Active Directory services network-wide, and when you bring them back up after you applied the patch, a lot of your servers may not work properly’,” O’Connor said.

Curiously, Schmidt shared slides from a report submitted to a working group on namespace collisions suggesting that at least some of the queries corp.com received while he was monitoring it may have come from Microsoft’s own internal networks.

Image: JAS Global Advisors

“The reason I believe this is Microsoft’s issue to solve is that someone that followed Microsoft’s recommendations when establishing an active directory several years back now has a problem,” Schmidt said.

“Even if all patches are applied and updated to Windows 10,” he continued. “And the problem will persist while there are active directories named ‘corp’ – which is forever. More practically, if corp.com falls into bad hands, the impact will be on Microsoft enterprise clients – and at large scale – paying, Microsoft clients they should protect.”

Asked why he didn’t just give corp.com to Microsoft as an altruistic gesture, O’Connor said Microsoft actually offered to buy the domain several years back for $20,000. He turned them down, saying that at the time he thought it was too low and didn’t reflect the market value of the domain.

O’Connor said he believes the software giant ought to be accountable for its products and mistakes.

“It seems to me that Microsoft should stand up and shoulder the burden of the mistake they made,” he said. “But they’ve shown no real interest in doing that, and so I’ve shown no interest in giving it to them. I don’t really need the money. I’m basically auctioning off a chemical waste dump because I don’t want to pass it on to my kids and burden them with it. My frustration here is the good guys don’t care and the bad guys probably don’t know about it. But I expect the bad guys would like it.”

Further reading:

Mitigating the Risk of DNS Namespace Collisions (PDF)

DEFCON 21 – DNS May Be Hazardous to your Health (Robert Stucke)

Mitigating the Risk of Name Collision-Based Man-in-the-Middle Attacks (PDF)

Update, 6:22 p.m. ET: Added the bit at the end about the $20,000 offer a few years back from Microsoft, a detail that I somehow omitted from the original story.

Active Directory password reset best practices

Password change and password reset are terms that are often used interchangeably. However, they are not the same. A user will perform a password change when they remember their existing password, and a password reset when they have forgotten it.

The two use cases are inherently tied to an organization’s domain password policy which traditionally encompass password complexity, length, and change frequency requirements. With a sound policy in place, users will need to follow the composition requirements when changing or resetting their passwords.
But, what makes a password policy secure? There isn’t a shortage of regulatory and standard bodies that have weighed on this very topic. This article looks at what can be achieved using the native Active Directory (AD) Group Policy settings, including key capabilities that increase password security while balancing the user experience.

Active Directory password expiration

Password Expiration can be configured using the Maximum Password Age setting within the Default Domain Policy in the Group Policy Management Console. The setting is applied to all domain computers and users.

Maximum password age dictates the amount of days a password can be used before the user is forced to change it. The default value is 42 days but IT admins can adjust it, or set it to never expire, by setting the number of days to 0.

Windows password policy settings

Other Windows password policy settings include:

  • Enforce password history determines the number of old/previously used passwords stored in AD to prevent users from using a previously used password. The default and maximum value is set to the previous 24 passwords.
  • Minimum password age dictates how often a user can change their password following a password change. This prevents a user from reverting to a previously used password, circumventing the password history rule; by changing it 24 times in a row for example. The default value is set to 1 day.
  • Minimum password length enforces the character length of the password.
  • Password must meet complexity requirements utilized to ensure that the password cannot contain the user’s account name or display/full name, and must include three of the five-character types: upper-case letter, lower-case letters, numbers, special characters and Unicode.
  • Store passwords using reversible encryption allows passwords to be stored in AD almost in plain-text, which is highly insecure, but sometimes needed to grant password access to certain applications.

These settings are meant to increase password security but can have a negative effect on end users. Complex passwords result in forgotten passwords as such anytime password complexity is introduced there will be an uptick in helpdesk password reset calls. According to Gartner research firm these can account for 30-40% of support costs.

To deflect password reset calls from the helpdesk, it is recommended that organizations implement passphrases which are outside of the scope of Active Directory. Passphrases are long passwords made up of unrelated words which are harder to crack but easier for users to remember. In fact, the National Institute of Standards and Technology (NIST) recommends using them with their 64-character maximum length requirement, however they do advise to eliminate password expiration as it can lead to users making poor password construction decisions.

Eliminating password expiry can leave an organization exposed indefinitely if an attacker has gotten hold of a user’s account. A better approach is to utilize length-based password aging. This combined with passphrases can ensure that users are incentivized to create longer stronger passwords by rewarding them with less frequent changes. Forced password changes are always going to cause users some disruption but the aforementioned features can alleviate some of the frustration. Another important consideration is to ensure that password rules are displayed dynamically to users as they are changing their passwords. If there is too much guess work involved users will revert to calling the helpdesk.

Active Directory password reset

Even with user-oriented features as noted in the section above, password reset calls to the helpdesk will still occur. Active Directory password resets are most commonly performed by using Active Directory Users and Computers. With just a few clicks a user’s password can be reset. This can be accomplished using other methods; the Active Administrator Center user interface or PowerShell are two examples.

A current gap within organizations is user identity verification – most rely on insecure methods, such as employee ID or security questions. In fact, password reset user verification is not mentioned in recommendations set forth by industry, or regulatory bodies, although it is a highly exploited attack vector. This is where proactive steps are necessary.

Given that password reset calls to the service desk take a significant percentage of the support call load in order to this cost and maximize security, organizations must look to a self-service password reset solution. The solution should support secure user verification methods, that go beyond security questions, although widely utilized answers to questions are cumbersome for users to recall. Security questions are also recognized as an insecure form of authentication due to social engineering. More secure forms of authentication should be considered especially ones that are already in use to eliminate the need for users to have to enroll in the system while extending the ROI of existing assets.

Active Directory password reset and change best practices

Ultimately, there isn’t a one-size fits all approach. IT departments need to balance the user experience while maximizing security. When setting a secure password policy, consider following these password change/password reset best practices:

  • Turn on password expiration with length-based password aging to promote secure password construction behavior while reducing risk.
  • Secure all password reset scenarios at the helpdesk and self-service with more secure forms of authentication.
  • Display password rules dynamically to users changing or resetting their passwords. Frustrated users will contact the helpdesk.

You can start balancing the scale today with Specops uReset, a self-service password reset solution facilitating Active Directory password resets and changes. Through a graphic password policy rule display, the solution reduces errors and guess-work for end-users. Its robust multi-factor authentication engine includes various forms of user-verification that can extend authentication security to the helpdesk.