I’ve been talking with LOTS of folks recently who have been experiencing password spray and brute force attacks. Typically this is against existing ADFS environments.
In this article, I’m going to identify some common ways you can defend against this using Microsoft technologies.
What is a password attack?
As organizations increase adoption of cloud-based applications like Office 365, authentication becomes a challenge. Often these different services require separate logins and separate passwords which adds complexity for end users and increases security risks and administration for organizations.
Single sign-on solutions like Active Directory Federation Services (ADFS) help to simplify this both for users and organizations, but having this internet facing service also attracts bad actors who will attempt to use them to try and breach your organization’s security. One such attack that is becoming more common is called a password attack.
There are 2 types of common password attacks. Password spray attack & brute force password attack.
Password Spray Attack
In a password spray attack, bad actors will try the most common passwords across many different accounts to try and gain access. For example, an attacker will use a commonly available toolkit to enumerate all of the users and then try “P@$$w0rd” and “Password1” against all of those accounts. To give you the idea, an attack might look like:
|Target User||Target Password|
This attack pattern evades most detection techniques because the attack just looks like an isolated failed login.
For attackers, it’s a numbers game: they know that there are some passwords out there that are very common. The attacker will get a few successes for every thousand attempts, and that’s enough to be effective. 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—just that they have some success that they can leverage.
Brute Force Password Attack
In this type of attack, a bad actor will attempt multiple password attempts against a targeted set of accounts. These could be executives within the organization, admins who manage critical infrastructure or even regular users.
This type of attack is often noticed because it causes a Denial Of Service by locking users out of their accounts. This can also cause interruption on the AD FS endpoints as they are unable to process the large number of requests
Option 1 : Use Cloud Based Authentication
Microsoft sees billions of sign-ins to Microsoft systems every day. Their security detection algorithms allow them 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).
Option 2 : Securing AD FS against password attacks
By taking a few steps to configure your AD FS and network correctly, AD FS endpoints can be secured against these types of attacks.
This article covers 3 areas that need to be configured properly to help secure against these attacks.
- Baseline: These are the basic settings that must be configured on an AD FS server to ensure that bad actors cannot brute force attack federated users.
- Protecting the extranet: These are the settings that must be configured to ensure the extranet access is configured to use secure protocols, authentication policies and appropriate applications.
- Move to password-less for extranet access: These are advanced settings and guidelines to enable access to federated resources with more secure credentials rather than passwords which are prone to attack.
- In ADFS 2016, implement extranet smart lockout Extranet smart lockout tracks familiar locations and will allow a valid user to come through if they have previously logged in successfully from that location. By using extranet smart lockout, you can ensure that bad actors will not be able to brute force attack the users and at the same time will let legitimate user be productive.
- If you are not on AD FS 2016, I recommend you upgrade. It is a simple upgrade path from AD FS 2012 R2.
- If you are on AD FS 2012 R2, implement extranet lockout. One disadvantage of this approach is that valid users may be blocked from extranet access if you are in a brute force pattern. AD FS on Server 2016 does not have this disadvantage.
- Monitor & Block suspicious IP addresses
- If you have Azure AD Premium, implement Connect Health for ADFS and use the Risky IP report notifications that it provides.
- Licensing is not for all users and requires 25 licenses/ADFS/WAP server which may be easy for a customer.
- You can now investigate IP’s that are generating large # of failed logins
- This will require you to enable auditing on your ADFS servers.
- Block suspicious IP’s. This potentially blocks DOS attacks.
- If on 2016, use the Extranet Banned IP addresses feature to block any requests from IP’s identified from the report above.
- If you are on AD FS 2012 R2 or lower, block the IP address directly at Exchange Online and optionally on your firewall.
- If you have Azure AD Premium, use Azure AD Password Protection to prevent guessable passwords from getting into Azure AD
Protect your extranet
- Move to modern authentication for any clients accessing from the extranet. Mail clients are a big part of this.
- You will need to use Outlook Mobile for mobile devices.
- You will need to use Outlook 2013 (with the latest CU patches) or Outlook 2016.
- Enable MFA for all extranet access. This gives you added protection for any extranet access.
- If you have Azure AD premium, use Azure AD Conditional Access policies to control this. This is better than implementing the rules at AD FS. This is because modern client apps are enforced on a more frequent basis. This occurs, at Azure AD, when requesting a new access token (typically every hour) using a refresh token.
- If you don’t have Azure AD premium or have additional apps on AD FS that you allow internet based access, implement MFA (Can be Azure MFA as well on AD FS 2016) and do a global MFA policy for all extranet access.
- If not all users have access to mobile devices for MFA, you can use hardware tokens such as those sold by SafeID