The media coverage of NotPetya has hidden what might have been a more significant attack: a brute force attack on the UK Parliament. While for many it was simply fertile ground for Twitter Brexit jokes, an attack like this that targets a significant government body is a reminder that brute force remains a common threat to be addressed.
It also raises important questions as to how such an attack could have happened in the first place:
Get the Free Pentesting Active
Directory Environments E-Book
These issues do suggest that we need to look deeper into this important, but often misunderstood type of attack.
Brute force defined
At the end of the day, there are two methods used to infiltrate an organization: exploit human errors or guesswork. Exploiting human errors has many attack variants: phishing (a user mistake), taking advantage of flawed configuration (an administrator mistake) or abusing a zero-day vulnerability (a developer mistake). Guesswork, on the other hand, is encompassed in one type of attack: brute force.
Most commonly, a brute force attack is used to guess credentials, though it may be used to guess other things such as URLs.
A classic brute force attack is an attempt to guess passwords at the attacker home base, once that attacker got hold of encrypted passwords. This enables the attacker to use powerful computers to test a large number of passwords without risking detection. On the other hand, such a brute force attack can’t be the first step of an attack, since the attacker should already have a copy of the victim’s encrypted passwords.
The online, real-time variant of the attack tries to pound a login function of a system or an application to guess credentials. Since it avoids the need to get encrypted passwords in the first place, attackers can use this technique when attempting to penetrate a system on which they have no prior foothold.
Do online brute force attacks happen?
Trying to guess both a user name and a password is ultimately very hard. Since most systems don’t report whether the username or the password was wrong on failed login, the first shortcut that an attacker takes is to try to attack known users. The attacker can find usernames using open source intelligence: in many organizations, for instance, user names have a predictable structure based on the employee name – and a simple LinkedIn search will reveal a large number of usernames.
That said, this type of classic online brute force attack (at least towards well-established systems) is more myth than a reality. The reason is simple – most modern systems and applications have a built-in countermeasure: lockout. If a user fails to log in more than a few times, the account is locked and requires an administrator intervention to unlock. Today, it’s the lockouts that create a headache to IT departments rather than brute force, making lockout monitoring more essential than brute force detection.
The exception to this is custom-built applications. While the traditional Windows login may not be exploitable, a new web application developed specifically for an upcoming holidays marketing campaign may very well be.
In comes credential stuffing
While classic online brute force attacks seem to be diminishing, credential stuffing is making its way to the central stage. Credential stuffing is an attack in which attackers use credentials – username/password pairs – stolen from public internet sites to break into a target system. The number of successful attacks against public websites is increasing, and the attackers publish the credential databases or sell them on underground exchanges. The assumption, which too often holds true, is that people will use the same username and password across sites.
Credential stuffing bypasses lockout protections since each username is used only once. By using known username/password pairs, credential stuffing also increases the likelihood of success with a lower number of tries.
Since lockout is not effective as a countermeasure, organizations incorporate two-factor authentication mechanisms to try to avoid credential stuffing – and the use of stolen credentials in general. Two-factor authentication requires a user to have something else besides a password to authenticate: for example, a particular cell phone on which the user can receive a text message. Since two-factor authentication is cumbersome, a successful authentication usually approves any “similar” access. “Similar” may imply the use of the same device or the same geographical location. Most of us have experienced public websites requiring two-factor authentication when we accessed them from a new device, a public computer, or when traveling.
While Two-factor authentication is a robust solution, it has significant downsides: it alters the user experience and requires an interactive login. Nothing is more frustrating than being asked for two-factor authentication on your phone just when landing in a foreign airport after a long flight. As a result, it and is often left as an option for the user. And so, this calls for a detection system, often utilizing analytics, to recognize brute force attacks in action.
Detecting brute force attacks
The most commonly prescribed detection method for brute force seems to address the classic but impractical variant of the attack: detecting multiple failed login attempts for a single user over a short span of time. Many beginner exercises in creating SIEM (Security Information and Event Management) correlation rules focus on detecting brute force attacks by identifying exactly such a scenario. While elegant and straightforward as an exercise, it addresses a practically non-existent attack vector – and we need much more to detect a real world brute force attacks.
The factor that will hold true for any authentication brute force attack is a large number of failed authentication attempts. However, since the user cannot be the key for detection, a detection system has to focus on another key to connect the thread of events making up the attack.
One method will be to track failed authentications from a single source: often the source IP address. However, with public IP addresses becoming scarcer and more expensive, more and more users end up sharing the same source IP.
To overcome this, a detection mechanism can learn the normal rate of connections or of failures from a source IP to determine what would be an abnormal rate, thus taking into account the fact that multiple users might be connecting from the same source IP. The detector might also use a device fingerprint – a combination of properties in the authentication event that are typical to a device – to identify a particular source from those using the same IP address. This cannot be a primary factor, however, and can only help verify detection as most of the fingerprinting properties are under the control of the attacker and can be forged.
Distributed attacks – for example by utilizing a botnet or by rerouting attempts through a network of privacy proxies such as TOR – further complicate the challenge since source monitoring becomes irrelevant. Device fingerprinting may work to an extent, especially if the attack is still carried out by a single source but through multiple routes. An additional approach is to use threat intelligence, which would help to identify access from known botnet nodes or privacy proxies.
The Practicalities of Detection
So far, we’ve assumed that the events used for analysis are neat and tidy: any failed login event is clearly labeled as a “login,” the result is clearly identified as success or failure, and the username is always in the same field and format.
In reality, processing an event stream to make it ready for brute force detection analysis is an additional challenge to consider.
Let’s take Windows, the most ubiquitous source of them all, as an example. The windows successful login event (event ID 4624) and Windows failed login event (event ID 4625) are logged locally on each computer. This makes it more challenging (though not impossible) to collect them. It also means that the attacker – who may own the computer – can prevent them from ever being received. The domain controller registers an authentication event, which can be used as a proxy for a login event. This one comes in a Kerberos (event ID 4768) and NTLM (event ID 4776) variants for Windows 2008 and above and yet another set of event IDs for previous Windows versions.
Once we know which events to track, we still need to know how to identify success and failure correctly. Local login success and failure are separate events, while for the domain controller authentication events, success and failure are flagged within the event.
The following Splunk search (from the GoSplunk search repository), which I’ve used to identify failed vs. successful Windows logins, demonstrates the level of knowledge needed to extract such information from events – and it doesn’t even support the domain controller authentication alternative.
source="WinEventLog:security" (Logon_Type=2 OR Logon_Type=7 OR Logon_Type=10) (EventCode=528 OR EventCode=540 OR EventCode=4624 OR EventCode=4625 OR EventCode=529 OR EventCode=530 OR EventCode=531 OR EventCode=532 OR EventCode=533 OR EventCode=534 OR EventCode=535 OR EventCode=536 OR EventCode=537 OR EventCode=539) | eval status=case(EventCode=528, "Successful Logon", EventCode=540, "Successful Logon", EventCode=4624, "Successful Logon", EventCode=4625, "Failed Logon", EventCode=529, "Failed Logon", EventCode=530, "Failed Logon", EventCode=531, "Failed Logon", EventCode=532, "Failed Logon", EventCode=533, "Failed Logon", EventCode=534, "Failed Logon", EventCode=535, "Failed Logon", EventCode=536, "Failed Logon", EventCode=537, "Failed Logon", EventCode=539, "Failed Logon") | stats count by status | sort - count
Detection through the Cyber Kill-Chain
The brute force example makes it clear that attack detection is not trivial. None of the detection methods described above are bullet proof, and attackers are continually enhancing their detection avoidance methods.
Detection requires expertise in both attack techniques and the behavior of the monitored systems. It also requires ongoing updates and enhancements. It’s therefore critical that any system used for detecting brute force attacks must include out of the box algorithms and updates to those detection algorithms. It’s not enough to simply provide the means to collect events and write the rules or algorithms, which leaves the user with the task of implementing the actual detection logic. It also suggests that it might be worthwhile to understand how a system detects brute force – rather than just relying on a general promise for detecting brute force. There’s just so much more to it than a textbook example will provide.
It is also yet another great example of why a layered detection system that will capture attackers past the infiltration point is critical: and why the cyber kill-chain is a good place to start.
