Breaching the Perimeter - Bypassing Lockout Policies

One of the things that always gets organizations into trouble in penetration tests is the lack of two-factor authentication. This issue is especially dangerous when it affects services, such as Outlook Web Access, that directly integrate with the organization's directory service (Active Directory). Why? Let's go through a hypothetical scenario that I've come across many times in the field.

The Victim: Contoso Ltd.

Contoso Ltd. is a fictional medium-sized enterprise with 300 employees that runs its business using Microsoft enterprise software. Like many companies, Contoso uses Active Directory to manage its users, Exchange Server to manage email, and has an externally accessible SSL VPN for employees to access their documents or desktops remotely. Employees can also access their email through their mobile phones (ActiveSync) or web browsers using Outlook Web Access (OWA).

Internally, Contoso has set a complex password policy requiring users to enter passwords that are at least 8 characters in length and contain at least three out of the four character classes (number, upper case, lower case, special character). Users are also forced to change their passwords every 90 days and cannot repeat their last 15 passwords. Finally, users cannot enter a wrong password more than 5 times within a span of 20 minutes without being locked out.

The one thing Contoso hasn't implemented is two-factor authentication (2FA) for their remotely accessible services (i.e. OWA, ActiveSync, and VPN).

Sounds familiar? It should since this typically represents the majority of organizations relying on the Internet to power their business activities. Most think 2FA is unnecessary because they have a strong password and account lockout policy in place. After all "it would take years for an attacker to brute force credentials if they could only do five logon attempts every 20 minutes for one user", right?

Cracking the Lockout Policy

Yes, it might take years for an attacker to crack one user account, if and only if they were targeting one user - but that's rarely the case if you're a medium to large enterprise. As you know, medium to large enterprises are comprised of 10s, 100s, even 1000s of employees. Why target only one user when you can target all of them? After all, an attacker often only needs one compromised user account in order to start breaching an organization's perimeter.

But how can they target all my users? It's not like they have our internal staff list, right? They may not have your entire staff listing but they can certainly pull down a significant part of it from sites like LinkedIn and JigSaw. Even Facebook recently made it easier to search for people who work for a particular employer.

JigSaw or Connect, in particular, has one of the richest datasets as it not only includes the names and positions of employees, but also their emails, phone numbers, office addresses and more! A free account allows you to view full contact information for two employees. However, browsing through the list of employees for a particular organization does not appear to be limited.

An attacker would only need one contact card to get the general gist of how one user's email and most likely their username is constructed (i.e. john.doe, doej, or jdoe).

Armed with this information an attacker could simply generate an extensive user list from the various social networking sites and begin the next step of their attack - brute forcing user accounts.

The Four Seasons

This is where human predictability undoubtably fails an organization and where 2FA could have saved the day. A great trick in any penetration test is to test for seasonal passwords (Summer2015, Fall2014, Spring15) and variations of the word password (i.e. Passw0rd, Password1, etc.).

Knowing that Contoso is not using 2FA for its OWA and VPN deployments, the attacker uses their extensive user list in conjunction with their list of seasonal/common passwords. The approach is simple: attempt to login to OWA with each user in the list using the same password, at a rate of three password attempts every 20 minutes. In other words, our brute-force loops would look like this:

  1. First loop with Password1: jdoe:Password1, jsmith:Password1, etc.
  2. Second loop with Password2: jdoe:Password2, jsmith:Password2, etc.
  3. etc.

For an organization that has 1000 employees, that's a minimum of 3000 login attempts every 20 minutes. Within 1-3 iterations and some good luck, an attacker will most likely manage to compromise numerous user accounts. At this point, the game is over, and our attacker can login via the Contoso VPN, mine staffer's emails, or send a trojaned office document to your staff distribution list.


Organizations need to start taking the 2FA security requirement for their remotely accessible services seriously. As we've demonstrated in this post, it is quite trivial for attackers to collect actionable intelligence from open sources of information, like social networking sites and message boards, and use it to breach an organization's perimeter. Password and account lockout policies are incredibly useful for protecting a single user account from being compromised if targeted by a brute-force attack. However, these controls are not effective against company-wide brute-force attacks like the one I've described above.