Low Hanging Fruits

5.2. Low Hanging Fruits

Too many Penetration Testers do not pay attention to Low Hanging Fruits (LHF), which could cut down their assessment timeframes and help them in immediate gaining access to a remote system with little effort.

When we talk about low hanging fruits, we mean:

  • Misconfigured servers

  • Unimplemented or badly implemented ACLs (Access Control List)

  • Default or weak passwords

  • Open SMB shares / Null sessions

  • Broadcast Request

  • Vulnerabilities related to public exploits

  • and so on

You should already be familiar with some of these techniques. In the previous modules you not only learned how to verify the presence of vulnerable SMB/NetBIOS shares (open shares with NBTstat and null sessions with Winfo / other tools), but also publically available exploits (with Nessus). Also we looked at sniffing and unpacking broadcast messages (with Wireshark and sniffing tools).

In the next sections we will shelve these skills and focus primarily on how to test systems for weak and default passwords

5.2.1. Weak Passwords

After many years of information security and billions of dollars spent in this field, passwords are still one of the weakest links. This should be your top priority in this phase. We will cover some tools that will allow us to find and test:

  • Weak passwords

  • Default passwords

We will use them on common services like SMB, RDP, FTP, SQL, and so on.

5.2.1.1. Ncrack

Ncrack is a high-seed network authentication cracking tool that allows the testing of hosts and their services for poor password.

Although it is not currently maintained and it has been replaced by Nmap NSE scripts, it is still a valid and effective tool. You can find its manual here. In the next sections, we will move on to more modern/updated tools.

You can read the help manual with the ncrack -h

The first thing to note when starting to use Ncrack is how to specify targets. Assuming the target network is 10.10.10.0/24, we can specify that in many ways, see below:

|         Command          | Description                                         |
|--------------------------|-----------------------------------------------------|
| `ncrack 10.10.10.0/24`   | Uses the entire network, 10.10.10.0 to 10.10.10.255 |
| `ncrack add.els.com`     | Uses the IP address of add.els.com                  |
| `ncrack 10.10.1,2.1-200` | Sends the probes to all ip address within the range 1-200 in the subnets 10.10.1 and 10.10.2                                         |
| `ncrack 10.10.10.56`     |  Sends probes only to the 10.10.10.56 IP address    |

The next options that we will see are used to specify the services we wish to target. Ncrack supports the following services:

  • FTP

  • SSH

  • Telnet

  • HTTP(S)

  • POP3(S)

  • SMB

  • RDP

  • VNC

The standard notation is :

<service_name>://target:<port_number>

Suppose we both want to target the Telnet service on the target machine with the IP address 10.10.10.130. Our command will look like the following:

ncrack telnet:/10.10.10.130:25

The options <service_name> and <port_number> are optional, therefore, if we know that there is an SSH service on a default port we can user the following command: ncrack ssh://10.10.10.130

This will probe the IP 10.10.10.130 on port 22. We also have the freedom that if we know the service is not running on its default port (say it is on port 120), we can set it as follows:
  ```
  ncrack ssh://10.10.10.130:120
  ```

Notice that we can also set specific services for specific targets. Let's say we wish to probe the 10.10.10.130 for the SSH service (on port 22) and 10.10.10.60 for Telnet service (on port 218), we can use the following command:

ncrack ssh://10.10.10.130 telnet://10.10.10.60:218

The last item to note about the service specification is that we can specify them globally. Service specified in this way are applied to all the hosts that have not been associated with the previous (per-host) specification format.

To do this, we can use the -p parameter, followed by the list of services (comma separated). For example: Let us suppose we want to crack the two IPs on 10.10.10.10 and 10.10.10.15 for SSH on port 50 and telnet on its default port. The command to run this attack will look like the following: ncrack 10.10.10.10,15 -p ssh:50,telnet

Now that we know how to specify hosts and services, let us see how to set username and password. Ncrack already has lists of common usernames and passwords that we can use during our tests.

You can find these in the Ncrack default folder: stduser@els: $ ls -l /user/share/ncrack total 944 -rw-r--r-- 1 root root 6564 Jan 12 2014 common.usr -rw-r--r-- 1 root root 47049 Jan 12 2014 default.pwd -rw-r--r-- 1 root root 3489 Jan 12 2014 default.usr -rw-r--r-- 1 root root 22414 Jan 12 2014 jtr.usr ...

We can specify the wordlist to use with the -U and -P options: - -U <path_to_username_file_wordlist> - -P <path_to_password_file_wordlist>

If we want to try custom usernames and passwords, without using dictionaries, we can provide them as follows: - -u username1, username2, ... - -p pwd1, pwd2, ...

Notice, by default, Ncrack iterates usernames for a fixed password. If you want to do the opposite you can use the option --password-first

Other useful options that we can use are:

  • -v for verbosity

  • -d[0-10] for debugging level

  • -f to exit once it finds valid credentials

  • --resume <path> to continue previously saved sessions

It is important to know that Ncrack can be used in conjunction with Nmap. Indeed we can:

  • perform any kind of scan with NMap

  • export the results (-o[N/X/L] option)

  • feed Ncrak with Nmap results with the option -i[N/X/L]

This will avoid setting IP addresses and services since they are already set in the Nmap output file. You only need to set the service options, usernames, and passwords lists.

5.2.1.2. Medusa

Another valid tool that we can use to exploit weak and default password is Medusa.

Medusa works similarly to Ncrack, but it offers more options and supports more services. You can see a comparison of the 2 tools features, Git repo and user manual.

In order to see its options and arguments, we can run medusa in your terminal windows (without options).

As we can see from the help manual, the main options that we can use to specify our targets and passwords/username combinations are: - -h [TARGET] : Target hostname or IP address - -H [FILE] : File containing target hostnames or IP addresses - -u [TARGET] : Username to test - -U [FILE] : File containing usernames to test - -p [TARGET] : Password to test - -P [FILE] : File containing passwords to test

In order to list all the available modules (service that Medusa can target), we can use the -d option.

If we want to know more about a specific module, we can use the -q option to display the module usage information. For example : medusa -M telnet -q

If we want to target the telnet service running on the host the host 192.168.102.149, we can run:

medusa -h 192.168.102.149 -M telnet -U username.lst -P password.lst

If medusa finds valid credentials, it prints out the message ACCOUNT FOUND. If you want more information about Medusa tasks, you can set the verbosity level with the -v option.

5.2.1.3. Patator

The last tool we are going to inspect is called Patator. It differs from other similar tools since it is very flexible and modular but, also allows you to avoid false negative results.

It may seem a bit cumbersome to use at first, but once you understand its syntax, you'll love it.

In contrast to almost all the other tools, Patator does not really offer a help manual. In order to see how its works and its usage, you have to inspect the patator.py file. It is here,, before the actual source code, you will find the USAGE section which contains some examples for the different modules and options.

The alternative way to understand how to use it, is by running patator in you terminal window, followed by the module name you want to use and then the --help option. For example, if we want to obtain the module usage of ssh_login: patator ssh_login --help

Moreover, notice that we can retrieve the entire list of modules by running Patator with no arguments.

The best way to learn how to use Patator is to inspect some of the examples it provides in conjunction with inspecting their arguments. Let's start with some basic commands: patator ssh_login host=10.0.0.1 user=root password=FILE0 0=passwords.txt -x ignore:mesg='Authentication failed.' As we can see, this command will try to bruteforce the SSH service (ssh_login module) running on the host 10.0.0.1 (host parameter)

Of course, we have to specify the usernames and passwords to use. We do this with the user and password parameters: - With user=root we specify one single username to test - With password=FILE0 we are using what Patator calls placeholders. FILE is a keyword that tells Patator we want to use a file containing the actual words to test (a list of passwords in our case).

    The `0` at the end of the placeholder is used to both match the corresponding wordlist (`0=passwords.txt`) and indicate what order to iterate over all the wordlists.

    So if we have additional placeholders (`FILE0` and `FILE1`), Patator uses the first entry in `FILE0` and iterates through all the entries in `FILE1`. Then it takes the second entry in `FILE0` and iterates through all the words contained in `FILE1`, and so on.

    Example:
      ```
      patator [module] host=FILE0 user=FILE1 password=FILE2 0=hosts.txt 1=logins.txt 2=pwd.txt
      ```
- `-x` : Allows us to specify what to do (action) upon receiving the expected results.
    In our case, we are telling Patator to `ignore` the results obtained, if they contain the message (`mesg`) `Authentication Falied`.

    This option highly customizable in order to describe any type of situation

Now that we have a basic idea of how to configure Patator, let's try to run it against an actual service and see how it reacts. The target of our tests is 192.168.102.155 and the wordlists for the usernames and passwords are username.lst and password.lst, respectively.

In order to better understand how Patator works, we will not specify any action and condition in our first test.

Our first command will be the following (see image): patator ssh_login host=192.168.102.155 user=FILE0 password=FILE1 0=username.lst 1=password.lst Patator will return a large amount of information. We can not only see the time and credentials used but also the message returned by the service. Indeed, we can see that if the credentials are not valid, we get "Authentication failed". If the credentials work however, we get the SSH service version "SSH-2.0-OpenSSH_6.6.1"

Let now use the `-x` option in order to ignore all the responses with the "Authentication failed" message.

Our command will look like the following:

patator ssh_login host=192.168.102.155 user=FILE0 password=FILE1 0=username.lst 1=password.lst -x ignore:mesg='Authentication failed'

As we can see, this time Patator returns only working credentials and ignores all the other responses with the "Authentication failed" string.

5.2.1.4. EyeWitness

An excellent tool we can use to help us identify low-hanging fruits as it applies to web applications and networking devices that may be using default credentials is a tool known as EyeWitness.

Designed to run on Kali Linux, EyeWitness can grab screenshots of web applications, networking devices, and mostly any other device that has HTTP or HTTPS enabled on a port, and can also quickly determine whether or not default credentials are being used for any of those devices.

It is an excellent tool to quickly identify low-hanging fruit that can be used as an initial foothold. You can download the tool here

Another great thing a bout EyeWitness, is that it will create a report in HTML that we can use to quickly review our results.

Getting up and running with EyeWitness is straightforward. Once we have downloaded the tool from the github repository, we can run setup.sh script from within the setup directory. This will install everything needed to run the tool. root@tester:~/tools/EyeWitness/setup# ./setup.sh

Once installed, a typical command line we can use to kick-off a scan is like so, where urls.txt is a file containing a list of URLs or IP addresses: # python EyeWitness.py --headless --prepend-https -f urls.txt

It then will generate an HTML report (see image).

Important: EyeWitness also contains an --active-scan option which will actively attempt to log into any and all devices found using known default credentials.

Keep in mind that using this option however, can results in account lockouts and will likely generate IDS or HDS alerts. Use --active-scan option with caution.

5.2.1.5. Rsmangler

At this point, we're used to using pre-compiled password dictionary wordlists or list containing default credentials as a starting point for mounting password brute-force attacks, but we should also become familiar with several tools we can use to generate more targeted wordlists.

One of those tools, Rsmangler by DigiNinja can be used to help us generate targeted wordlists we can use for our dictionary attacks.

Rsmangler, will take an existing wordlist and perform various manipulations resulting in more targeted wordlist which will include permutations and variations or words we can in our wordlist.

With Rsmangler and other wordlist generator tools, we'll typically want to start with a small list of several words since just supplying a few words to start, can quickly generate a very large file.

As an example, let's take a fictitious organization "Robot Industries LLC", and from the name, we'll create a list (words.txt) of three words:

  • Robot

  • Industries

  • LLC

Using the following command line, we can generate a list containing variations and permutations of the above:

cat words.txt | rsmangler --file - > words_new.txt

Using our initial 3-word wordlist, and running it with Rsmangler defaults, we've ended up with a list of 7,780 permutations, some of which can be seen below.

We can see how this can be useful from the standpoint of creating a list that's specific to the target organization.

5.2.1.6. CeWL

Another excellent wordlist generation tool from the same author is CeWL

CeWL takes our wordlist generation a step further and will scrape a target organization's website for keywords, and in turn, will generate a list of words we can use for our wordlist.

A typical command line for using CeWL would be something like the following where the -m flag with a value of 8 will create a list of words with a minimum of 8 characters:

cewl -m 8 http://www.google.com

We could then, of course further improve our wordlist using Rsmangler to create permutations of the keywords identified with CeWL.

5.2.1.7. MentalList

In addition to command-line tools, we can use to help us generate customized wordlists, the Mentalist tool provides us with a GUI front-end we can use to generate comprehensive wordlists well.

Mentalist can also generate files that can be used with Hashcat and John the Ripper.

You can learn more about this tool here.

Pre-compiled Mentalist executables for both Windows and Linux can be downloaded from here as well.

PreviousVulnerability AssessmentNextExploitation

Last updated