Anonymity About Brute Force and its Reincarnations.

[Fixxx]

We all know well that passwords can be guessed or intercepted in other ways. In this article, we will specifically discuss password guessing. We will assume that our attacker doesn't have physical access to the machine from which authentication is performed and therefore cannot install a trojan or keylogger. Additionally, the hacker cannot control communication channels; all traffic between the client and server is encrypted and the attacker has no way to implement a Man in the Middle attack. However, the hacker does have access to the interface of the targeted application, where they can enter their credentials.

Let's start with usernames...​

In the authentication form, we are usually presented with fields for a username and password. In theory, the username part is relatively straightforward. First and foremost, any attacker will be interested in administrative accounts: Administrator, admin, root... However, if the targeted application or operating system meets at least some of the requirements (recommendations, policies) of information security, then administrative accounts will be locked and attempts to access them will be monitored, for example, in a SIEM system. In many applications, usernames can be email addresses, tax identification numbers or even phone numbers. In the latter case, either a regular password or a one-time password from an SMS can be used. If the attacker knows the email address of any user in the system, they can confidently move on to the next part, which involves directly guessing the password.

But let's consider the more complex scenario where the attacker also doesn't know the username. In this case, they can try using the resource https://github.com/insidetrust/statistically-likely-usernames. This resource contains lists of words for creating statistically likely usernames for use in counting usernames, modeling password-based attacks and other security testing tasks. As the author of this repository writes: "When there are many users in an application or network, I usually approach password attacks by guessing likely usernames (instead of focusing on guessing too many passwords). This has several advantages (for example, it helps avoid account lockouts) and almost always leads to success (usually several users have either 'Password1', 'password' or something equally trivial)". The repository has ready-made dictionaries, but if (rather when) this is insufficient, the basic lists can be manipulated and combined in various ways. For example, if a pentester knows that the organization's username format is j_smith and wants to generate 10,000 guesses (to try 'Password1' or something else), the basic lists can be modified as follows:

head -n 10000 j.smith-x100000 | tr "." "_" > usernames.txt

If we refer to best practices in information security, the application should not indicate what exactly is incorrect when a username and/or password is entered incorrectly. However, many applications may inform that such a user doesn't exist when an incorrect username is provided. As a result, the attacker can draw conclusions about which accounts exist. Once they find a few valid usernames, they can try using the most common passwords for each of the discovered users.

​

Old-fashioned Brute Force​

I believe everyone has heard that brute force is one of the most common hacking methods. No matter what security professionals come up with in their password policies, P@ssw0rd, Paw0rd,Passw0rd1 and their various, widely used relatives continue to inhabit user accounts. Therefore, dictionary attacks also have their place. According to the conditions of the exercises, we agreed that the attacker can only guess passwords online; no dumps, hashes or other offline activities for guessing are allowed. A simple brute force attack using specialized utilities, scripts or even manually is likely to lead to the locking of the targeted account. This may be useful for a DoS attack, but we are specifically discussing password guessing here. To find out under what conditions and how much an account will be locked in Active Directory, one can use the command:

net accounts

But there is one small problem: to execute this command, you need to have an account in that domain. If, for example, Kali Linux is used, one can utilize one of the following commands:

crackmapexec <IP> -u 'user' -p 'password' --pass-pol

enum4linux -u 'username' -p 'password' -P <IP>

rpcclient -U "" -N 10.10.10.10;

rpcclient $>querydominfo

ldapsearch -h 10.10.10.10 -x -b "DC=DOMAIN_NAME,DC=LOCAL" -s sub "*" | grep -m 1 -B 10 pwdHistoryLength

However, these commands don't eliminate the need for a domain account. Even knowing the domain lockout rules, the attacker should not relax too soon. It's quite possible that the organization has a SIEM system that has rules analyzing all successful and unsuccessful authentication events. As a result, you may create a script that makes requests based on the domain policies, but in reality, the SIEM has already created an incident and the information security team is taking appropriate measures. Let’s look at an example. Crackmapexec will try each password from the passwords.txt file for each entry in the users.txt file. For the policy mentioned above, we need to make no more than two attempts no more frequently than once per hour.

crackmapexec smb <IP> -u users.txt -p passwords.txt –t 1 --jitter 1201-1800

Here, –t 1 indicates one thread (attempt), and --jitter 1201-1800 specifies a range in seconds from which a random time interval will be generated for the pause before the next attempt. Thus, within each hour, we will have no more than two attempts and we will not lock the account. Yes, a speed of 24 attempts per day is not very fast, but it is safe at least from the perspective of lockouts. By the way, not every SIEM will detect such activity, as correlation rules are usually set for shorter time intervals to avoid false positives.

Password Spraying​

Password guessing attacks can be spread out (password spraying). For example, if we have several usernames and a dictionary of passwords, we can change the username instead of the password during the guessing process. This will appear as unsuccessful login attempts for different users, which (when used wisely) will not only help bypass lockout policies but also deceive the infamous SIEM. For this, we can use the spray utility:

spray -smb <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes> <Domain>

Here, we also specify the number of attempts, the lockout period and the domain. Depending on the number of usernames, we can adjust the number of attempts. In the example below, we still have one attempt every 21 minutes.

spray -smb 192.168.0.1 users.txt passwords.txt 1 21 CORPORATION

Kali Linux includes many different tools for password guessing that can be used for web resources, file shares, databases, etc.

What to do?​

In fact, the answer to this rhetorical question is quite simple in this case: use two-factor authentication. Always try to use either a one-time password sent via SMS or an application on the user's phone that confirms their login to the application. Many cloud providers literally require the use of certificates instead of (or better yet, in addition to) passwords for accessing virtual machines via SSH.