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:

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.

One might hope that Microsoft would provide straightforward and coherent file activity events in the Windows event log. The file event log is important for all the usual reasons –  compliance, forensics, monitoring privileged users, and detecting ransomware and other malware attacks while they’re happening.  A log of file activities seems so simple and easy, right? All that’s needed is a timestamp, user name, file name, operation (create, read, modify, rename, delete, etc.), and a result (success or failure).

But this is Microsoft. And they never, ever do anything that’s nice and easy.

The Case of “Delete”

Let’s start with delete, the simplest scenario. Google “Windows file delete event” and the first answer, as usual, will be from Randy Franklin Smith’s Windows Event Encyclopedia: “4660: An object was deleted”.

To a Windows event newbie, it would appear that our research effort is complete. Unfortunately, this delete event is missing one critical piece of information: the file name. Why? If you’re detecting ransomware, one would want to know which files are being encrypted. Likewise, when being alerted on privileged user access to sensitive files, one would expect to know exactly which files were accessed.

The hard part is: how do you determine the file name associated with an event? Even identifying something as simple as a file name isn’t easy because Windows event information is spread out across multiple log entries. For example, you’d have to correlate the delete event 4660 with the “access object” event 4663. In practice, you’d create a search for matching 4660 and 4663 events, and then combine information from both events to derive a more user-friendly log entry.

Let’s continue discussing the correlations needed to implement file activity monitoring using the Windows event log. The actual implementation depends on the tools used to collect the event: a database query, a program, or a dedicated correlation engine – a program tailored for such activity.

The Windows File Activity Audit Flow

Windows does not log file activity in a way that you’d expect. Instead, it logs granular file operations that require further processing. So let’s deep dive into how Windows logs file operations.

The diagram below outlines how Windows logs each file operation using multiple micro-operations logs:The delete operation is a unique case in that there is a fourth event, 4660, mentioned above. The sequence is identified by the “Handle ID” event property which is unique to this sequence (at least until a reboot).

The event that provides the most information is 4663, identifying that an attempt was made to access an object. However, the name is misleading because Windows only issues the event when the operation is complete. In reality, there might be multiple 4663 events for a single handle, logging smaller operations that make up the overall action. For example, a rename involves a read, delete, and a write operation. Also, one 4663 event might include multiple values in the “Accesses” property which lists access rights exercised to perform the operation. Those “Accesses” serve as our guideline for the operations themselves. More on that later.

The following table provides more information about each event:

Event ID	Name	Description	Data It Provides
4656	A handle to an object was requested	Logs the start of every file activity but does not guarantee that it succeeded	The name of the file
4663	An attempt was made to access an object	Logs the specific micro operations performed as part of the activity	What exactly was done
4660	An object was deleted	Logs a delete operation	The only way to verify an activity is actually a delete
4658	The handle to an object was closed	Logs the end of a file activity	How much time it took

One step you would not want to skip is setting Windows to log those events, which is not the default. You’ll find a good tutorial on how to do that here.

You get the idea: you’re dealing with lots of different low-level events related to a higher-level file actions. Let’s take up the problem of correlating them to produce user-friendly information.

Interpreting “Accesses”

To identify the actual action, we need to decode the exercised permissions as reported in the “Accesses” event property. Unfortunately, this is not a one-to-one mapping. Each file action is made up of many smaller operations that Windows performs and those smaller operations are the ones logged.

The more important “Accesses” property values are:

• “WriteData” implies that a file was created or modified unless a “delete” access was recorded for the same handle.
• “ReadData” will be logged as part of practically any action. It implies “Access” if no “Delete” or “WriteData” were encountered for the same handle and for the same file name around the same time.
• “Delete” may signify many things: delete, rename (same folder), move (to a different folder) or recycled, which is essentially a move to the recycle bin. Event 4660 with the same handle differentiate between delete or recycled for which a 4660 event is issued and a rename or move for which it is not.

Complex?

Consider this only as a starting point. The analysis above is somewhat simplified, and real-world implementation will require more research. Some areas for further research are:

• Differentiating delete from recycle and move from rename.
• Analyzing attributes access (with or without other access operations).
• Handling event 4659 which is similar to 4660 but is logged on a request to delete a locked file on the next reboot rather than deleting them now.
• Researching reports that events come out of order and the “request handle event” (4656) may not be the first in the sequence.

You may want to review this PowerShell Script which reads Windows events and generates from them meaningful file activity report to get a somewhat less simplified analysis. A word of warning: it is not for the faint-hearted!

Windows Event Log Limitations for File Access Monitoring

While the Windows file activity events seem comprehensive, there are things that cannot be determined using only the event log. A few examples are:

• Create vs. modify: the only way to know if this is a new file or a modified file is to have knowledge of the prior state, i.e. whether the file existed before.
• Missing information on failures: in a case of an operation that was rejected due to insufficient permissions, the only event issued is 4656. Without a sequence, most of the processing described in this article is not possible.
• Cut & paste: while one would assume “cut and paste” would be similar to a move operation, in practice, the behavior seems to be similar to a delete operation followed by a create operation with no relations whatsoever between the two operations.

Scalability Considerations

Collecting Windows file activity is a massive event flow and the Microsoft event structure, generating many events for a single file action, does not help. Such collection will require more network bandwidth to transfer events and more storage to keep them. Furthermore, the sophisticated logic required may need a powerful processing unit and a lot of memory.

To reduce the overhead, you may want to:

• Carefully select which files you monitor based on the scenario you plan to implement. For example, you may want to track only system files or shares that include sensitive data.
• Limit collection of unneeded events at the source. If your collection infrastructure uses Microsoft Event Forwarding, you can build sophisticated filters based on event IDs and event properties. In our case, filter only events 4656, 4660, 4663 and optionally 4658 and only for the “Accesses” values needed.
• Limit event storage and event sizes as raw Windows events are sizable.

An Alternative Approach

Real world experience shows that there are not many organizations that succeed in utilizing Windows Event Log for file activity monitoring. An alternative approach for implementing this important security and compliance measure would be to use a lightweight agent on each monitored Windows system, with a focus on file servers.

Such an agent, similar to the Varonis agent alongside the Data Security Platform, would record file activity with a minimal server and network overhead, enabling better threat detection and forensics.

To see how this would work on your network, request a 1-on-1 Demo today.