Maintaining access is a very important phase of penetration testing. Let's assume that our target has run our shell and all things are going fine. Then suddenly, the target just turned off the computer. So, in this case, we'll lose everything. So, the key point here is that we need to survive after a reboot or a shutdown by the target machine. Now, before proceeding any further, some customers prohibit any modification to the target machine, so you've got to make sure you set the right expectations with your customer before proceeding any further.
If the modification is allowed, then we have three phases of execution as given here:
- First, we'll copy ourselves in a different location and we are doing that just in case our target deletes the shell file; so this copy is a backup. In this phase, two parameters should be identified. First, the source path, which is the directory where our shell exists or, in other words, the current working directory. The second parameter is the destination path; here it is the Documents folder.
- In the second phase, after copying our shell into the Documents folder or Documents directory, we need to add a registry key and point it out to the copied file in the Documents folder. Keep in mind that the first and second phases should only run once after our backdoor gets installed on the target machine for the first time.
- The third phase is to start our reverse shell without repeating the preceding 2 phases.
Since we don't know the current working directory or user profile, we've got to figure it out in the first place. This will happen in the system reconnaissance phase.
Now, to break down the workflow for our persistence shell, take a look at this simple flowchart:
Logically, we'll start with the system reconnaissance, Sys Reconn, phase and the output of this phase will include two things. First, we will discover the current working directory of our shell, and find out the user profile. The second output should be the destination path. Next, we need to determine whether we are running for the first time on the target machine. Now, you probably are wondering how can we do that. Well, thanks should go to the OS library for simplifying the task for us. To achieve this, we will simply check whether our script exists in the destination path or not. If it exists, then this is not the first time we are on the target side since we have already done the first two phases. So, we will skip phases 1 and 2, and fire up our shell.
However, if this is the first time we have run on the target side, we will copy ourselves to the destination path, which is what we do in phase 1. Then, we add a new registry key pointing to this location, which is phase 2 here. Finally, we need to make sure that we get our connection back to the Kali server. In two upcoming sections, you'll see everything in action to provide more clarity on this concept. For ease of understanding, we'll break the coding part into two parts. In the first part, we will make putty.exe persistent, and in the second part we will wrap up and integrate the persistent script with our previous HTTP reverse shell.