Brute force attacks are those attacks that rely purely on exhaustive effort rather than sophisticated techniques to perform. They are used by attackers in several cybersecurity spheres including against encryption and authentication systems. Frequently characterised as somewhat crude, brute force attacks nevertheless represent a significant threat to organisations who fail to take specific measures to protect against them. Recent developments such as the spread of global botnets of increasing sophistication and size present new challenges to organisations in resisting such attacks.
In this blog post, we look at what brute force attacks consist of, how they are typically performed, what systems and services they can be used to target, and how organisations can best protect against them.
The term “brute” is thought by etymologists to be derived from the Latin brutus meaning dull or stupid, via the French brut, which means coarse or crude. When something is described as a brute or brutish, we instinctively picture something that is not just coarse but strong or at least massively physical – a brute might not work by applied reason or intelligence but offsets this by bringing an animalistic or bestial strength to make up for their lack of human intellect.
A brute force approach to a problem leverages those qualities of a brute (strength and power) whilst being bound by its limitations (a lack of intelligence or advanced reasoning). Generally speaking, a brute force approach is therefore simplistic and exhaustive – it does not make use of a sophisticated “shortcut” to solve a problem but simply combines the application of brute strength to the least sophisticated approach to solving the task.
There’s a twenty-year-old meme based around the tongue-in-cheek question originally published in the Metro newspaper asking “Would you rather fight a horse-sized duck or 100 duck-sized horses?” – when we think of “brutes” we tend to think of “horse-sized ducks”, but in a computing context, brute force normally relies rather on “many duck-sized horses”. That is, “strength” as it applies to brute force in a computing context requires power in terms of work rate (number of operations) as opposed to the power of any one individual operation. Similarly, brute force approaches to computing problems typically rely on massive parallelisation – performing lots of small, discrete operations spread across many agents, cores, systems, or processes.
In mathematics, the term proof by exhaustion is used to describe brute force approaches, where a solution is found by simply checking each possible case in turn, one after another, and is described by mathematicians as being inelegant. Likewise, many fields apply brute force to search problems, in which the approach consists of systematically enumerating all possible candidates for the solution and checking one by one whether each candidate satisfies the problem’s statement. Other applications for brute force in recent years include Bitcoin mining and distributed computing initiatives such as distributed.net, BOINC, and the discontinued SETI@Home initiative.
Brute-force has the advantage that is generally simple to implement within a given problem space, and will always find a solution if it exists, albeit potentially after a very prolonged time. Brute-force approaches are well suited to be conducted by computers, which excel at performing a large number of operations at a high rate – it is not uncommon for recent Central and Graphical Processing Units (CPUs/GPUs) in consumer PCs to be able (in theory) to perform at between 1-50 Teraflops or 1-50 trillion floating-point calculations per second, with esoteric supercomputer systems performing orders of magnitude faster than this still.
Within cybersecurity, brute force approaches are used in a similar manner as in legitimate efforts such as mathematical analysis or distributed computing. That is, they apply an exhaustive approach to performing an attack against a system, service, or data set. They are almost always automated and performed via a script or executable that performs a simple operation, or sequence of operations, in a repeating loop, either running indefinitely (if being used to attempt a simple denial of service – in which the brute force actions are themselves the “payload”) or halting only when a solution (or solutions) has been found, or the problem space exhausted.
Brute force attacks as we shall see a little further on, can be performed either “online” across a network against a target system, or “offline” against a data set that the attacker has already gained access to a copy of.
Brute force attacks contrast explicitly to attacks that apply some kind of “shortcut” to provide a more optimal attack pattern – these may include discovering inherent (algorithmic) or applied (implementational) weaknesses in systems or algorithms, in discovering and exploiting built-in “backdoors”, in performing unexpected analysis such as “side-channel” attacks, or using advanced solutions often involving mathematical analysis, such as the use of heuristic or genetic algorithms, or the use of cryptanalytic attacks against encryption.
Brute force attacks can be applied to a number of different system types. The most generic form of brute force attack is a simple volumetric attack aimed at performing a denial of service. There is no solution being sought for or meaningful work or calculation being performed – the payload of the attack is the simple conduct of the attack itself. A volumetric attack such as this is often referred to as a denial of service attack since it aims to consume all the resources of the host system, making it unable to service requests from other (legitimate) customers.
However, when the term “brute force” is normally used, it most commonly relates to the application of a high work rate and exhaustive approach aimed at finding a solution to a problem, such that the solution once it is found can be further exploited – that is, the attack itself is not the exploit, but rather it enables an exploit by discovering (typically) some hidden secret. Once an attack has found this hidden secret, they are able to access a system or data set using it, undermining the confidentiality and potentially integrity and availability of the system, service, or data.
The two most common applications for brute force attacks in this second sense are therefore those system types that depend upon shared secrets – cryptography (encryption) and passwords (authentication). Less commonly, the term can also be seen applied to exhaustive approaches in areas such as target reconnaissance, in which an attacker may use an exhaustive (or volumetric) series of requests to varying paths or ports on a network target in order to discover accessible yet non-advertised services or application endpoints.
There are a number of types of brute force attacks, and some apply only to certain target types. The below is not an exhaustive list, but rather a shortlist of some of the more common types seen:
Basic – A basic brute force attack is one that attempts every single potential solution, and it is either extremely prolonged or potentially even open-ended/infinite (assuming no solution is found). In the case of a password guessing attack, a basic brute force attack could attempt to guess valid usernames and passwords. Using a truly basic brute force approach, nothing is assumed about the target system, and hence every possible combination of username and password must be attempted. Without knowledge of potential usernames in use, of the password scheme and policy in use, or ever the supported character set, the potential username/password combinations are near infinite. Basic brute force attacks are the purest form of brute force attack and almost guaranteed to find a solution (ultimately) but there is often no limit on their potential execution time.
Dictionary – In a dictionary-based attack, a brute force approach is taken, but it is tempered by a reduction of the valid problem space using what is known as a dictionary – a finite (yet potentially extremely large) reference list of strings or other data to be used in attempts against the target system or data set. Dictionary attacks may literally use an English-language dictionary, but more broadly can be any data set that is used to provide a list of candidate solutions that can be used in an attempt. The reason this approach might be taken is if it is considered likely or inferred by the attacker that the person responsible for setting the solution that is being sought may have used a word or string that is drawn from or based upon such a source.
Informed – One step more specific than a dictionary attack is an informed brute force attack, in which an attacker is more confident (beyond supposition) that the solution may exist within a finite set to which they have access. In brute force attacks against authentication systems, this is most commonly seen when an attacker has access to a list of valid username/password combinations that have been exfiltrated from some other system in a hack or data breach previously. Since humans are known to reuse passwords on multiple systems, there is a chance that those same credentials are valid against the system the attacker is now targeting. In these instances, this attack type is known as a “credential stuffing attack” or “credential recycling attack”. In a second variant, an attacker may have solved part of the problem space earlier via some other means – a common example might be having discovered a valid list of usernames via a username enumeration weakness on an endpoint, and hence only need to solve the password half of the credential set.
Reverse – In a reverse brute force attack, the typical problem space for the target system or service is reversed. For example, if an authentication system is being targeted, then an attacker might typically assume that there is an “admin” user on that system and attempt various passwords in combination with this username. In a reverse brute force attack, by contrast, an attacker might not have any knowledge of valid usernames (and hence this is the element that is subject to brute force) but be confident that at least one user (if the user base is large enough) will have the password of “password123” (hence the password element is, in contrast, fixed for each attempt.
Rainbow Table – In a rainbow table attack, an attacker performs an attack typically offline against an acquired data set such as a hashed list of passwords gained during a data breach. When passwords are stored on a system, it is best practice to hash the password using a one-way transformation function and store this value rather than the password itself (e.g., if the password “password12345” is hashed using a given algorithm, the hash “25d55ad283aa400af464c76d713c07ad” might be calculated and stored – it is this value the attacker has gained in a data breach and is trying to calculate the password for. Since hashes are one-way, they cannot be reversed in order to determine the password, making them a strong method of password storage. However, using a rainbow table brute force attack, an attacker can calculate the hashes or various passwords (or use a pre-generated table of hashes for common passwords) until they find a match, correlating to the valid credentials.
The impact of a brute force attack can vary massively since the attack type is so broad and has so many potential applications. In the case of a denial-of-service attack, the availability of one or more systems can be disrupted, denying the usage of the service to legitimate users. In the case of a brute force attack against an encryption key, an attacker may gain access to confidential data encrypted using the key. But perhaps most seriously, if an authentication system is targeted then an attacker may gain access to the system in question. Depending on what service or tier the account that is hacked in such a way relates, this can in the event of total host compromise impact all three elements of the so-called “CIA Triad” of security – the Availability of the target system, and the Confidentiality and Integrity of any and all data that it hosts, processes, or transmits.
Primarily, brute force attacks require a significant amount of time. In order to be practicably effective – and especially in the case of disruptive or volumetric DoS attacks – they also require significant computing resources. Specifically, the resources required for a brute-force attack grow exponentially rather than linearly with the increasing size of the problem space (e.g. key size in cryptography, or valid password set size in authentication attacks). Attacks can choose to approach this problem using either a prolonged attack time and a lot of patience or by distributed methods.
In July 2002, for instance, a group announced that it had broken a symmetric 64-bit encryption key via brute force attack, but the effort took the computing power contributed by more than 300,000 people in a massively distributed effort more than four and a half years of continuous work. Within the cybercriminal community, a distributed approach is often undertaken by making use of a botnet – a pool of previously-compromised host systems belonging to legitimate users and organisations, which are subverted by the attacker using “C&C” (command and control) software to instruct them to act on the attacker’s behalf and assist them in conducting attacks.
Since there are so many forms of brute-force attack, and against so many system types, we cannot provide an exhaustive list of remediations here, and not all remediations will apply to all attacks against all systems – but the below is a good shortlist of “best practices” to avoid or reduce the effectiveness of brute force attacks in a number of areas:
Since brute force attacks cannot be completely avoided in all instances, one of the best measures against brute force attacks is the use of robust detective controls to detect a brute-force attack if it is underway, and trigger either automated defenses or – more typically – human reaction to the issue. This will typically be based upon the use of a strong logging and monitoring configuration in which events that may signify that a brute force attack is underway are logged, correlated, and analysed automatically, raising alerts to human agents that may trigger incident response. Basic triggers or logic can be based upon the number or rate of certain event types (such as authentication attempts/failures) but more sophisticated variants could be based upon heuristic-based analysis looking for unusual patterns of user behaviour against a known typical baseline.
Another common mitigation is to attempt to apply some form of rate-limiting to actions of a certain type. Since brute force attacks address a typically large problem space, they rely on a high work rate in order to make the attack plausibly likely to succeed in a finite time period. Applying rate limiting can thwart the effectiveness of brute force attacks.
Passwords are known as a “single factor” of authentication (something that is “known”). In a single-factor system, gaining that one factor (e.g. by brute force guessing the password) is sufficient to authenticate (prove claimed identity). A multi-factor authentication system in contrast requires multiple factors to be supplied by a client before identity is confirmed – other factors can include “something you own” (such as a hardware token or key) and “something you are” (such as a biometric). Since an attacker is unlikely to have gained access to these, guessing the password via a brute force attack will not in itself permit them to gain compromised access to an account. If a multi-factor authentication system is set up correctly, multiple factors will be requested in a single submission (rather than waiting on and confirming the correct “solve” of the first factor before asking for the second), meaning that the brute force attack is completely useless since it cannot even be determined when and if the correct credential is guessed.
Also known as “Reverse Turing tests”, challenge-response systems (such as “CAPTCHA”) are a proof of work variant that aims to provide a task that must be performed during the submission of each potential solution, and which are relatively trivial for humans to solve yet difficult or time consuming for computers to solve. Examples might include selecting only those images that contain chimneys from a larger set of images given. Since brute force attacks rely on computer automation for their high submission rate of potential solutions, these tests can thwart effective brute forcing of systems, although they have their limitations and drawbacks.
Implementing policies and technical measures to prevent password reuse between systems can prevent credential stuffing attacks, though are limited in that corporate systems cannot know the passwords used by employees in non-corporate or off-network accounts.
Brute force attacks rely on the fact that they are addressing a finite and searchable problem space: that is, that there is a finite list of possible “correct answers” and that by examining each potential solution in turn that the correct one will eventuality be found. This assumption can be undermined by “moving the goalposts” periodically, meaning that the problem space can never be exhaustively searched or that, even if a solution is found, it is no longer valid when an attacker eventually discovers it since it has since been changed for another value.
In network-based access a common issue for Internet based services is that they are open to a potentially unrestricted audience and number of attackers. It is often possible for services such as Application Programming Interfaces (APIs) or administrative endpoints to restrict the permitted list of clients authorised to access the service via IP address, in addition to the authentication requirements. This can be done using a blacklist or deny list (potentially added to dynamically based on failed authentication attempts) but a stronger form is the whitelist in cases where the authorised users for the service are known and access the service from a registered and static gateway or endpoint.
In cryptographic systems, there is a trade-off between algorithmic complexity, key size, and speed of operation. When designing cryptographic systems, designers have to ensure that an algorithm and key size are sufficiently strong to protect against brute force attacks, yet not so computationally expensive that legitimate cryptographic operations using them are unworkable. An example of this might be TLS security (Transport Layer Security) used to encrypt HTTP (web) traffic among others – clients may connect to a website from relatively low-powered devices, so cryptographic algorithms cannot be massively expensive computationally for legitimate users. However, there is a constant “arms race” in that as CPUs get faster, algorithms become relatively weaker, key sizes relatively weaker, and attackers able to feasibly brute force their way through them more quickly. It is therefore necessary to make sure that you review cryptographic algorithms and keys in use periodically and update them where necessary.
As we described above, passwords are commonly hashed before being stored. However even hashed passwords are vulnerable to rainbow table attacks – this can be partially mitigated (or an attacker’s job at least made orders of magnitude more complex) by applying per-user salts when calculating their password hash.
The use of brute force attacks from distributed endpoints can be somewhat mitigated using CDNs (Content Delivery Networks) and DDoS mitigation platforms. These perform checks against clients close to origin (close to the client’s point of presence) rather than on or close to the screened service – that is, rather than a brute force attack being concentrated on a target system before being detected and potentially mitigated, they are thwarted in a distributed fashion at network edge, meaning that the attack potentially never gets off the ground, and saving network bandwidth and meaning the target system is less likely to exhaust its resources in mitigating the threat.
Similar to rate limiting, authentication systems can be partially protected against brute force authentication attacks by implementing either account lockout or limiting the number of failed login attempts before some other action is taken. Rather than having an unlimited number of attempts at authenticating against a given account, an attacker may only get say three attempts before all other attempts are rejected. Care should be taken if implementing this approach however that all legitimate users are not locked out in a self-inflicted denial of service during a brute force attack.
Many brute force attacks against authentication endpoints have their task made a lot easier for the attacker if a list of valid usernames is known to them and they only need to guess the password half of the credential set. Many endpoints on web applications (notoriously registration and password reset URLs) may inadvertently allow the enumeration of valid usernames by providing error messages that are too specific. For example, the message “you cannot register that email address, it is already in use” reveals that the email address supplied relates to an existing, valid user account that can then be targeted in a brute force authentication attack.
Lastly, it is advisable to perform a vulnerability scan of your services and endpoints to detect potential brute force weaknesses using a vulnerability scanning tool such as AppCheck. AppCheck can detect Denial of Service (DoS) vulnerabilities such as SlowLoris, without actually exploiting them or causing a denial of service on the endpoint being scanned.
AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities – including brute force weaknesses – from first principle to detect vulnerabilities in in-house application code.
The AppCheck web application vulnerability scanner has a full native understanding of web application logic, including Single Page Applications (SPAs), and renders and evaluates them in the exact same way as a user web browser does.The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, networks, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorized by te Common Vulnerabilities and Exposures (CVE) Program aas a CVE Numbering Authority (CNA)
