Essentials of meterpreter scripting

As far as we have seen, we have used meterpreter in situations where we needed to perform some additional tasks on the system. However, now we will look at some of the advanced situations that may arise during a penetration test, where the scripts already present in meterpreter seem to be of no help to us. Most likely, in this kind of situation, we may want to add our custom functionalities to meterpreter and perform the required tasks. However, before we proceed to add custom scripts in meterpreter, let's perform some of the advanced features of meterpreter first and understand its power.

Pivoting the target network

Pivoting refers to accessing the restricted system from the attacker's system through the compromised system. Consider a scenario where the restricted web server is only available to Alice's system. In this case, we will need to compromise Alice's system first and then use it to connect to the restricted web server. This means that we will pivot all our requests through Alice's system to make a connection to the restricted web server. The following diagram will make things clear:

Considering the preceding diagram, we have three systems. We have Mallory (Attacker), Alice's System, and the restricted Charlie's Web Server. The restricted web server contains a directory named restrict, but it is only accessible to Alice's system, which has the IP address 192.168.75.130. However, when the attacker tries to make a connection to the restricted web server, the following error generates:

We know that Alice, being an authoritative person, will have access to the web server. Therefore, we need to have some mechanism that can pass our request to access the web server through Alice's system. This required mechanism is pivoting.

Therefore, the first step is to break into Alice's system and gain the meterpreter shell access to the system. Next, we need to add a route to the web server. This will allow our requests to reach the restricted web server through Alice's system. Let's see how we can do that:

Running the autoroute script with the parameter as the IP address of the restricted server using the –s switch will add a route to Charlie's restricted server from Alice's compromised system. However, we can do this manually as well. Refer to http://www.howtogeek.com/howto/windows/adding-a-tcpip-route-to-the-windows-routing-table/ for more information on manually adding a route to Windows operating systems.

Next, we need to set up a proxy server that will pass our requests through the meterpreter session to the web server.

Being Mallory, we need to launch an auxiliary module for passing requests via a meterpreter to the target using auxiliary/server/socks4a. Let's see how we can do that:

In order to launch the socks server, we set SRVHOST to 127.0.0.1 and SRVPORT to 1080 and run the module.

Next, we need to reconfigure the settings in the etc/proxychains.conf file by adding the auxiliary server's address to it, that is, 127.0.0.1 on port 1080, as shown in the following screenshot:

We are now all set to use the proxy in any tool, for example, Firefox, Chrome, and so on. Let's configure the proxy settings in the browser as follows:

Let's open the restricted directory of the target web server again:

Success! We have accessed the restricted area with ease. We have an IP logger script running at the target web server in the directory named restrict. Let's see what it returns:

Success again! We are browsing the web server with the IP of our compromised system, which is Alice's system. Whatever we browse goes through the compromised system and the target web server thinks that it is Alice who is accessing the system. However, our actual IP address is 192.168.75.10.

Let's revise what we did because it may have been a bit confusing:

Setting up persistent access

After gaining access to the target system, it is mandatory to retain that access forever. Meterpreter permits us to install backdoors on the target using two different approaches: MetSVC and Persistence.

Persistence is not new to us, as we discussed it in the previous chapter while maintaining access to the target system. Let's see how MetSVC works.

The MetSVC service is installed in the compromised system as a service. Moreover, it opens a port permanently for the attacker to connect whenever he or she wants.

Installing MetSVC at the target is easy. Let's see how we can do this:

We can clearly see that the MetSVC service creates a service at port 31337 and uploads the malicious files as well.

Later, whenever access is required to this service, we need to use the metsvc_bind_tcp payload with an exploit handler script, which will allow us to connect to the service again as shown in the following screenshot:

The effect of MetSVC remains even after a reboot of the target machine. This is handy when we need permanent access to the target system, as it also saves time that is needed for re-exploitation.

API calls and mixins

We just saw how we could perform advanced tasks with meterpreter. This indeed makes the life of a penetration tester easier.

Now, let's dig deep into the working of meterpreter and uncover the basic building process of meterpreter's modules and scripts. This is because sometimes it might happen that meterpreter alone is not good enough to perform all the required tasks. In that case, we need to build our custom meterpreter modules and can perform or automate various tasks required at the time of exploitation.

Let's first understand the basics of meterpreter scripting. The base for coding with meterpreter is the Application Programming Interface (API) calls and mixins. These are required to perform specific tasks using a specific Windows-based Dynamic Link Library (DLL) and some common tasks using a variety of built in Ruby-based modules.

Mixins are Ruby-programming-based classes that contain methods from various other classes. Mixins are extremely helpful when we perform a variety of tasks at the target system. In addition to this, mixins are not exactly part of IRB, but they can be very helpful to write specific and advanced meterpreter scripts with ease. However, for more information on mixins, refer to http://www.offensive-security.com/metasploit-unleashed/Mixins_and_Plugins.

I recommend that you all have a look at the /lib/rex/post/meterpreter and /lib/msf/scripts/meterpreter directories to check out various libraries used by meterpreter.

API calls are Windows-specific calls used to call out specific functions from a Windows DLL file. We will learn about API calls shortly in the Working with RailGun section.

Fabricating custom meterpreter scripts

Let's work out a simple example meterpreter script, which will check whether we are the admin user, whether we have system-level access, and whether the UAC is enabled or not:

isadd= is_admin?
  if(isadd)
  print_line("Current User Is an Admin User")
  else
  print_line("Current User Is Not an Admin User")
  end
issys= is_system?
  if(issys)
        print_line("Running With System Privileges")
        else
        print_line("Not a System Level Access")
        end
isu =  is_uac_enabled?
  if(isu)
        print_line("UAC Enabled")
        else
        print_line("UAC Not Enabled")
        end

The script starts by calling the is_admin method from the /lib/msf/core/post/windows/priv.rb file and storing the Boolean result in a variable named isadd. Next, we simply check whether the value in the isadd variable is true or not. However, if it is true, it prints out a statement indicating that the current user is the admin. Next, we perform the same for the is_system and is_uac_enabled methods from the same file in our script.

This is one of the simplest scripts. This script will perform basic functions as its function name suggests. However, a question that arises here is that /lib/msf/scripts/meterpreter contains only five files with no function defined in them, so from where did meterpreter execute these functions? However, we can see these five files as shown in the following screenshot:

When we open these five files, we will find that these scripts have included all the necessary library files from a variety of sources within Metasploit. Therefore, we do not need to additionally include these functions' library files into it. After analyzing the /lib/msf/scripts/meterpreter.rb file, we find that it includes all these five files as seen in the preceding screenshot. These five files further include all the required files from various places in Metasploit.

Let's save this code in the /scripts/meterpreter/myscript1.rb directory and launch this script from meterpreter. This will give you an output similar to the following screenshot:

We can clearly see how easy it was to create meterpreter scripts and perform a variety of tasks and task automations as well. I recommend you examine all the included files within these five files discussed previously.