Brute Force Attack in Windows System - Detection

Brute force attack is defined as the type of attack where user tries to authenticate into the system with different possible passwords. This type of attack is also known as Trial and Error attack or Exhaustive Search attack. We can detect such attack using available SIEM tool, however, we first need to define scope of detection.

What do we call Successful Brute Force Attack?

Multiple failed login events followed by successful login. So we need to write an alert rules that generates notification whenever such events happen. There are two possible scenarios for our rule

1. Multiple failed login followed by successful login for same user accounts
2. Multiple failed login followed by successful login for same source IP address

NOTE: we need to define what multiple means. Is it 3, 4, 5, 6 or more failed followed by successful? Another thing to ponder upon is the time duration. What should be the duration within which if such events happen is brute force attack? is it 1, 2, 3, 4 or 5 minutes?

What is the difference between these two?

First condition checks for user whose account is being exploited with different password variation. This does not take into account how many different workstation is being used for the exploit.

Query for this case will be something like below:

[5 Failed Login] followed by [Successful Login] on same user

While second condition checks for source address from where multiple user accounts are being tried.

[5 Failed Login] followed by [Successful Login] on same source IP address

How to use this in Windows environment?

We know event id 4625 is for failed user logins and 4624 is for successful user logins. So these two events will be used to detect possible brute force attack.

1. [5 event_id=4625 user=*] followed by [event_id=4624 user=*] on same user within 1 minute
2. [5 event_id=4625 source_address=* ] followed by [event_id=4624 source_address=*] on same source_address within 1 minute | distinct_count(user) as distinctUser by source_address | search distinctUser>1 

What should you do after this alert is fired?

When this event is triggered the following action should be done

• Investigate the source IP address and/or username

Brute Force Attack

Brute-force attack: Simple yet difficult 

Understanding what Brute Force Attack is fairly simple, but protecting against it is quite difficult.

Brute Force Attack

A brute force attack is a trial-and-error method used to obtain information such as a user password or personal identification number (PIN). In cryptography, a brute-force attack, or exhaustive key search, is a cryptanalytic attack that can, in theory, be used against any encrypted data (with some exception). Such an attack might be used when it is not possible to take advantage of other weaknesses in an encryption system (if any exist) that would make the task easier. In a brute force attack, automated software is used to generate a large number of consecutive guesses as to the value of the desired data.

For example, a form of brute force attack known as a dictionary attack might try all the words in a dictionary. Other forms of brute force attack might try commonly-used passwords or combinations of letters and numbers.

An attack of this nature can be time- and resource-consuming. Hence the name "brute force attack" success is usually based on computing power and the number of combinations tried rather than an ingenious algorithm. However, Encryption is math, and as computers become faster at math, they become faster at trying all the solutions and seeing which one fits.

Defend against Brute Force Attack

• Restrict the use of default usernames and passwords
• Requiring users to have complex passwords
• Limiting the number of times a user can attempt to log in
• Temporarily locking out users who exceed the specified maximum number of login attempts

Detection of Brute Force Attack

With the evolution of faster and more efficient password cracking tools, brute force attacks are on a high against the services of an organization. As a best practice, every organization should configure logging practices for security events so that any possible attack underway will get noticed and treated before the attack succeeds.

To check for brute force pattern, enable auditing on logon events in the Local Security Policy and then feed Windows Security Event log to the SIEM product used.

Below are the correlation search that is created in Splunk and LogPoint against Win:Security logs to monitor real time login attempts. In this search, brute force criteria gets matched with two failure attempts.

Splunk:

sourcetype="WinEventLog:Security" (EventCode=4625 AND "Audit Failure") NOT (User_Name="*$" OR Account_Name="*$") NOT Failure_Code=0x19 | stats count by Account_Name | where count > 2

LogPoint:

MSWinEventLog event_id=4625 -target_user=*$ -caller_user=*$ -failure_code=0x19 | rename target_user as Account, caller_user as user | chart count() as Event by Account | search Event > 2

Network Security: Passwords and Human Error

A past IBM cyber security intelligence index report concluded that 95% of security breaches are caused by human error. Human error definitely includes password choices by users. It also includes password requirements and password storage by systems administrators. Passwords are a large part of network security. Hackers can use a technique called "password guessing" in which they manually enter passwords at a log-in prompt to gain access to an account when they have a valid user name. There are tools to automate this guessing process, known as an online attack, including Medusa, Ncrack, and Hydra.

These tools were built to help companies secure their networks as security specialists can test hosts and networking devices for poor passwords. These tools are used to audit devices as well. Online attacks can also be used to check that your firewalls, IDSs, and IPSs detect when a server gets bombarded with unsuccessful log-in attempts and that accounts lock in a short period when this happens. Password guessing through manual or automated means is obviously very noisy, so hackers need a better way to do it. Passwords should never be stored in plain text in databases. Storing passwords in plain text allows them to be used immediately after they're stolen. Passwords should be stored in a strong hash format since hashing is a one-way function. 

In many of the data breaches of recent years, stolen password databases contain passwords that were either stored in plain text or hashed with weak algorithms like MD5 or SHA-1. The current standards of hashing include SHA-256 and SHA-512, both forms of SHA-2.

On Linux systems, password hashes are stored in the etc/shadow file. Most Linux distros use SHA-512 with something called "SALT".

On Windows systems, password hashes are stored in the SAM file located at C:windows\system32\config\SAM. Some Microsoft documentation expands SAM to Security Account Manager while other Microsoft documentation expands SAM to Security Accounts Manager. On Windows domain controllers running Active Directory, password hashes are stored in the NTDS.dit file located at C:windows\NTDS\NTDS.dit. The Windows NTLM, Lan Manager Protocol Suite, actually uses MD4 without SALT for storing Windows hashes.

Websites that we log into store passwords in a backend database likely using the MySQL relational database management system. If a hacker enters the stolen hash into the password field, the hash itself would be hashed, so the attacker won't do that. What happens when a database containing hashed passwords are stolen? The hackers have three attack options after they steal the hashed password database. The first is called a "brute force attack" which uses a tool that generates a file containing all possibilities of letters, numbers, and symbols given a minimum and maximum length. The second is a dictionary attack which uses common words and their variations instead of trying all possibilities like a brute force attack does. The third is a rainbow table attack which requires more processing but less storage than a dictionary attack.

Cryptography: Why do we Attack an Encryption System? What are its Approaches?

• 
  
  Typically, the objective of attacking an encryption system is to recover the key in use rather than simply to recover the plaintext of a single ciphertext. There are two general approaches to attacking a conventional encryption scheme: 
  •Cryptanalysis: Cryptanalytic attacks rely on the nature of the algorithm plus perhaps some knowledge of the general characteristics of the plaintext or even some sample plaintext–ciphertext pairs.
  •This type of attack exploits the characteristics of the algorithm to attempt to deduce a specific plaintext or to deduce the key being used.
  •Brute-force attack: The attacker tries every possible key on a piece of ciphertext until an intelligible translation into plaintext is obtained.
  On average, half of all possible keys must be tried to achieve success.
  
  

Introduction to Cyber Security - Attacking passwords

The obvious ways that attackers can find or steal passwords, such as looking over your shoulder when you’re using an ATM or credit card machine or trying obvious passwords such as ‘abc123’ and ‘password’, are familiar to us.

Almost as long as there have been passwords there have been people attempting to break passwords. One of the oldest methods of automatically breaking into computers is to perform a dictionary attack. As its name suggests, a computer will attempt to log into an account by working its way through one or more dictionaries – each entry in the dictionary is one possible password and if it doesn’t work, the computer moves on to the next.



Dictionaries need not be the familiar A–Z references that we are familiar with: a concerted dictionary attack will also include more specialised reference works such as atlases, lists of astronomical bodies and characters from literature, as well as lists of the most commonly used passwords and lists of stolen passwords that are in widespread circulation.

Dictionary attacks can also be performed on the hashed values of words; they may take a little longer, but they will work. Some system administrators might set up dictionary attacks on their own users’ passwords to try to identify weak passwords that should be changed.

An alternative, simple attack is a brute force attack where a computer will methodically work through all possible passwords (so beginning with ‘A’, then ‘AA’, ‘AB’ and so on …) trying each in turn until it stumbles upon an actual password.

Dictionary and brute force attacks can be foiled by having computers watch for unsuccessful attempts to log in to accounts. Almost all computer systems restrict the number of unsuccessful log-ins after which the account is locked and can only be accessed after the intervention of an administrator.

Another type of attack on passwords is based on the incorrect configuration of the hashing technique used to store the passwords on the server, which is discussed in the next step.

 

Salt to protect
The security of stored passwords can be increased by a process known as salting – in which a random value (called the salt) is added to the plaintext password before the hashing process.

This greatly increases the number of possible hash values for the password and means that even if two people choose identical passwords, their hashed passwords have completely different values.

The hashed password and the relevant salt are stored by the password server. When the user attempts to log in to the computer, their password and the salt are added together, hashed and compared to the stored, hashed value.

Salting is only effective if:

• truly random salts are used for each password (some systems have either used a single salt for all passwords, or have only changed the salt when the computer is restarted)
• the salt is long enough that, when added to a password, it will create enough possible hashed values that an attacker cannot generate a table containing all possible hashes from a salted dictionary. For instance, the passwords used by UNIX in the early 1970s were restricted to eight characters and used a 12-bit salt. When released this was secure enough – it was not feasible to generate the hashes for every possible password each of which had been salted with all 4096 possible salts. However, the rapid advance in computer power and storage capacity meant that longer salts are required. A typical piece of advice is that the salt should be the same length as the output of the hashing function – so if your hashing function generates 256-bit hashes, a 256-bit salt should be used.

 

Case study: LinkedIn
In the middle of 2012, the hugely successful social networking site LinkedIn was attacked by Russian hackers. The passwords to some 6.5 million accounts were stolen, but although they were stored as hashed values, the passwords had not been salted.

The hashing had been performed using the relatively old SHA-1 hashing algorithm which can be performed at very high speed (a desktop computer can calculate several tens of millions of SHA-1 hashes per second).

It was therefore not surprising that within a day, decrypted passwords were being published on the internet and LinkedIn was forced to ask all users to change their passwords.

Preventing the attacks described above depends on the online service taking steps to encrypt the transmission and storage of passwords. As users, we can help in this protection by choosing passwords that are difficult to attack.