{"id":945,"date":"2018-03-05T09:00:17","date_gmt":"2018-03-05T17:00:17","guid":{"rendered":"https:\/\/www.microsoft.com\/en-za\/2018\/03\/05\/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks\/"},"modified":"2022-06-28T10:51:59","modified_gmt":"2022-06-28T17:51:59","slug":"azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-za\/microsoft-365\/blog\/2018\/03\/05\/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks\/","title":{"rendered":"Azure AD and ADFS best practices: Defending against password spray attacks"},"content":{"rendered":"

Howdy folks,<\/p>\n

As long as we’ve had passwords, people have tried to guess them. In this blog, we’re going to talk about a common attack which has become MUCH more frequent recently and some best practices for defending against it. This attack is commonly called password spray.<\/strong><\/p>\n

In a password spray attack, the bad guys try the most common passwords across many <\/em>different accounts and services to gain access to any password protected assets they can find. Usually these span many different organizations and identity providers. For example, an attacker will use a commonly available toolkit like Mailsniper<\/a> to enumerate all of the users in several organizations and then try “P@$$w0rd” and “Password1” against all of those accounts. To give you the idea, an attack might look like:<\/p>\n

\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n
Target User<\/strong><\/td>\nTarget Password<\/strong><\/td>\n<\/tr>\n
User1@org1.com<\/td>\nPassword1<\/td>\n<\/tr>\n
User2@org1.com<\/td>\nPassword1<\/td>\n<\/tr>\n
User1@org2.com<\/td>\nPassword1<\/td>\n<\/tr>\n
User2@org2.com<\/td>\nPassword1<\/td>\n<\/tr>\n
\u2026<\/td>\n\u2026<\/td>\n<\/tr>\n
User1@org1.com<\/td>\nP@$$w0rd<\/td>\n<\/tr>\n
User2@org1.com<\/td>\nP@$$w0rd<\/td>\n<\/tr>\n
User1@org2.com<\/td>\nP@$$w0rd<\/td>\n<\/tr>\n
User2@org2.com<\/td>\nP@$$w0rd<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

This attack pattern evades most detection techniques because from the vantage point of an individual user or company, the attack just looks like an isolated failed login.<\/p>\n

For attackers, it’s a numbers game: they know that there are some passwords out there that are very<\/em> common. Even though these most common passwords account for only 0.5-1.0% of accounts, the attacker will get a few successes for every thousand accounts attacked, and that’s enough to be effective.<\/p>\n

They use the accounts to get data from emails, harvest contact info, and send phishing links or just expand the password spray target group. The attackers don’t care much about who those initial targets are\u2014just that they have some success that they can leverage.<\/p>\n

The good news is that Microsoft has many tools already implemented and available to blunt these attacks, and more are coming soon. Read on to see what you can do now and in the coming months to stop password spray attacks.<\/p>\n

Four easy steps to disrupt password spray attacks<\/h3>\n

Step 1: Use cloud authentication<\/h3>\n

In the cloud, we see billions of sign-ins to Microsoft systems every day. Our security detection algorithms allow us to detect and block attacks as they’re happening. Because these are real time detection and protection systems driven from the cloud, they are available only when doing Azure AD authentication in the cloud (including Pass-Through Authentication<\/a>).<\/p>\n

Smart Lockout<\/h3>\n

In the cloud, we use Smart Lockout to differentiate between sign-in attempts that look like they’re from the valid user and sign-ins from what may be an attacker. We can lock out the attacker while letting the valid user continue using the account. This prevents denial-of-service on the user and <\/em>stops overzealous password spray attacks. This applies to all Azure AD sign-ins regardless of license level and to all Microsoft account sign-ins.<\/p>\n

Tenants using Active Directory Federation Services (ADFS) will be able to use Smart Lockout natively in ADFS in Windows Server 2016 starting in March 2018\u2014look for this ability to come via Windows Update.<\/p>\n

IP Lockout<\/h3>\n

IP lockout works by analyzing those billions of sign-ins to assess the quality of traffic from each IP address hitting Microsoft’s systems. With that analysis, IP lockout finds IP addresses acting maliciously and blocks those sign-ins in real-time<\/em>.<\/p>\n

Attack Simulations<\/h3>\n

Now available in public preview<\/a>, Attack Simulator as part of Office 365 Threat Intelligence enables customers to launch simulated attacks on their own end users, determine how their users behave in the event of an attack, and update policies and ensure that appropriate security tools are in place to protect your organization from threats like password spray attacks.<\/p>\n

\"\"<\/p>\n

Things we recommend you do ASAP:<\/h3>\n
    \n
  1. If you’re using cloud authentication, you’re covered<\/li>\n
  2. If you’re using ADFS or another hybrid scenario, look for an ADFS upgrade in March 2018 for Smart Lockout<\/li>\n
  3. Use Attack Simulator<\/a> to proactively evaluate your security posture and make adjustments<\/li>\n<\/ol>\n

    Step 2: Use multi-factor authentication<\/h3>\n

    A password is the key to accessing an account, but in a successful password spray attack, the attacker has guessed the correct password. To stop them, we need to use something more than just a password to distinguish between the account owner and the attacker. The three ways to do this are below.<\/p>\n

    Risk-based multi-factor authentication<\/h3>\n

    Azure AD Identity Protection uses the sign-in data mentioned above and adds on advanced machine learning and algorithmic detection to risk score every sign-in that comes in to the system. This enables enterprise customers to create policies in Identity Protection that prompt a user to authenticate with a second factor if and only if there’s risk detected for the user or for the session. This lessens the burden on your users and puts blocks in the way of the bad guys. Learn more about Azure AD Identity Protection here<\/a>.<\/p>\n

    \"\"<\/p>\n

    Always-on multi-factor authentication<\/h3>\n

    For even more security, you can use Azure MFA to require multi-factor authentication for your users all the time, <\/em>both in cloud authentication and ADFS. While this requires end users to always have their devices and to more frequently perform multi-factor authentication, it provides the most security for your enterprise. This should be enabled for every admin in an organization. Learn more about Azure Multi-Factor Authentication here<\/a>, and how to configure Azure MFA for ADFS<\/a>.<\/p>\n

    Azure MFA as primary authentication<\/h3>\n

    In ADFS 2016, you have the ability use Azure MFA as primary authentication for passwordless authentication<\/a>. This is a great tool to guard against password spray and password theft attacks: if there’s no password, it can’t be guessed. This works great for all types of devices with various form factors. Additionally, you can now use password as the second factor only after your OTP has been validated with Azure MFA. Learn more about using password as the second factor here.<\/a><\/p>\n

    Things we recommend you do ASAP:<\/h3>\n
      \n
    1. We strongly recommend<\/em> enabling always-on multi-factor authentication for all admins <\/em>in your organization, especially <\/em>subscription owners and tenant admins. Seriously, go do this right now.<\/li>\n
    2. For the best experience for the rest of your users, we recommend risk-based multi-factor authentication, which is available with Azure AD Premium P2 licenses.<\/li>\n
    3. Otherwise, use Azure MFA for cloud authentication and ADFS.<\/li>\n
    4. In ADFS, upgrade to ADFS on Windows Server 2016 to use Azure MFA as primary authentication, especially for all your extranet access.<\/li>\n<\/ol>\n

      Step 3: Better passwords for everyone<\/h3>\n

      Even with all the above, a key component of password spray defense is for all<\/em> users to have passwords that are hard to guess. It’s often difficult for users to know how to create hard-to-guess passwords. Microsoft helps you make this happen with these tools.<\/p>\n

      Banned passwords<\/h3>\n

      In Azure AD, every<\/em> password change and reset runs through a banned password checker. When a new password is submitted, it’s fuzzy-matched against a list of words that no one, ever, should have in their password (and l33t-sp3@k spelling doesn’t help). If it matches, it’s rejected, and the user is asked to choose a password that’s harder to guess. We build the list of the most commonly attacked passwords and update it frequently.<\/p>\n

      \"\"<\/p>\n

      Custom banned passwords<\/h3>\n

      To make banned passwords even better, we’re going to allow tenants to customize their banned password lists<\/strong>. Admins can choose words common to their organization\u2014famous employees and founders, products, locations, regional icons, etc.\u2014and prevent them from being used in their users’ passwords. This list will be enforced in addition to the global list, so you don’t have to choose one or the other. It’s in limited preview now and will be rolling out this year.<\/p>\n

      Banned passwords for on-premises changes<\/h3>\n

      This spring, we’re launching a tool to let enterprise admins ban passwords in hybrid Azure AD-Active Directory environments<\/strong>. Banned password lists will be synchronized from the cloud to your on-premises environments and enforced on every domain controller with the agent. This helps admins ensure users’ passwords are harder to guess no matter where\u2014cloud or on-premises\u2014the user changes her password. This launched to limited private preview in February 2018 and will go to GA this year.<\/p>\n

      Change how you think about passwords<\/h3>\n

      A lot of common conceptions about what makes a good password are wrong. Usually something that should help mathematically actually results in predictable user behavior: for example, requiring certain character types and periodic password changes both result in specific password patterns. Read our password guidance whitepaper<\/a> for way more detail. If you’re using Active Directory with PTA or ADFS, update your password policies<\/a>. If you’re using cloud managed accounts, consider setting your passwords to never expire<\/a>.<\/p>\n

      Things we recommend you do ASAP:<\/h3>\n
        \n
      1. When it’s released, install the Microsoft banned password tool on-premises to help your users create better passwords.<\/li>\n
      2. Review your password policies and consider setting them to never expire<\/a> so your users don’t use seasonal patterns to create their passwords.<\/li>\n<\/ol>\n

        Step 4: More awesome features in ADFS and Active Directory<\/h3>\n

        If you’re using hybrid authentication with ADFS and Active Directory, there are more steps you can take to secure your environment against password spray attacks.<\/p>\n

        The first step: for organizations running ADFS 2.0 or Windows Server 2012, plan to move to ADFS in Windows Server 2016 as soon as possible. The latest version will be updated more quickly with a richer set of capabilities such as extranet lockout. And remember: we’ve made it really easy to upgrade from Windows Server 2012R2 to 2016.<\/p>\n

        Block legacy authentication from the Extranet<\/h3>\n

        Legacy authentication protocols don’t have the ability to enforce MFA, so the best approach is to block them from the extranet<\/a>. This will prevent password spray attackers from exploiting the lack of MFA on those protocols.<\/p>\n

        Enable ADFS Web Application Proxy Extranet Lockout<\/h3>\n

        If you do not have extranet lockout in place at the ADFS Web Application proxy, you should enable it as soon as possible<\/a> to protect your users from potential password brute force compromise.<\/p>\n

        Deploy Azure AD Connect Health for ADFS<\/h3>\n

        Azure AD Connect Health captures IP addresses recorded in the ADFS logs for bad username\/password requests, gives you additional reporting on an array of scenarios, and provides additional insight to support engineers when opening assisted support cases.<\/p>\n

        To deploy, download the latest version of the Azure AD Connect Health Agent for ADFS<\/a> on all ADFS Servers (2.6.491.0). ADFS servers must run Windows Server 2012 R2 with KB 3134222 <\/a>installed or Windows Server 2016.<\/p>\n

        Use non-password-based access methods<\/h3>\n

        Without a password, a password can’t be guessed. These non-password-based authentication methods are available for ADFS and the Web Application Proxy:<\/p>\n

          \n
        1. Certificate based authentication allows username\/password endpoints to be blocked completely at the firewall. Learn more about certificate based authentication in ADFS<\/a><\/li>\n
        2. Azure MFA, as mentioned above, can be used to as a second factor in cloud authentication and ADFS 2012 R2 and 2016. But, it also can be used as a primary factor in ADFS 2016 to completely stop the possibility of password spray. Learn how to configure Azure MFA with ADFS here<\/a><\/li>\n
        3. Windows Hello for Business, available in Windows 10 and supported by ADFS in Windows Server 2016, enables completely password-free access, including from the extranet, based on strong cryptographic keys tied to both the user and the device. This is available for corporate-managed devices that are Azure AD joined or Hybrid Azure AD joined as well as personal devices via “Add Work or School Account” from the Settings app. Get more information about Hello for Business<\/a>.<\/li>\n<\/ol>\n

          Things we recommend you do ASAP:<\/h3>\n
            \n
          1. Upgrade to ADFS 2016 for faster updates<\/li>\n
          2. Block legacy authentication from the extranet<\/a>.<\/li>\n
          3. Deploy Azure AD Connect Health agents for ADFS on all your ADFS servers.<\/li>\n
          4. Consider using a password-less primary authentication method such as Azure MFA, certificates, or Windows Hello for Business.<\/li>\n<\/ol>\n

            Bonus: Protecting your Microsoft accounts<\/h3>\n

            If you’re a Microsoft account user:<\/p>\n