Powershell reverse shell with Social-Engineering-Toolkit
In the realm of cybersecurity, a backdoor alludes to any strategy by which approved and unapproved clients can get around ordinary safety efforts and gain high-level user access (otherwise known as root access) on a PC framework, network, or programming application. When they’re in, cyber-criminals can utilize indirect access to take individual and financial information, introduce additional malware, and hijack devices.
In this article, we will explain to you how to create a reverse shell backdoor using a social engineering toolkit. The idea behind this attack is to set up a payload listener that receives incoming connections from Windows-based systems. Then run the payload handler and wait for incoming connections after the PowerShell code has been delivered to the target user.
When the target user executes that file, a remote session will be opened. There are many ways to deliver the PowerShell code to the target user, but we won’t be getting into that. Keep in mind that you will need to be on the same network as your target user.
First, we have to boot up Kali Linux and from “Applications” choose “Social Engineering Tools” and afterward “Social Engineering Toolkit.”
At the point when the Social Engineering Toolkit opens up in the terminal, we should choose “Social Engineering Attacks” by selecting option “1.”
From the next menu, we need to select “Powershell Attack Vectors,” so type “9” and hit “Enter.”
Then select the 2nd option for “Powershell Reverse Shell” and specify your IP address and the port number you want to listen on. Once everything is set, SEToolkit will generate a PowerShell code and store it in the following location “/root/.set/reports/powershell.” Lastly, this program will ask you whether you want to start the listener now. If you type “yes” it will start listening for incoming connections.
Now let’s move the PowerShell code to our web server so we can quickly deliver it to our target machine.
Ex: (root@kali:~# mv /root/.set/reports/powershell /var/www/html/Evil-Files/).
Since our code is saved as a “.txt” file, we will not be able to run it, so we need to convert it to an executable file.
Copy the raw code of the PowerShell backdoor and paste it in the newly opened NotePad file, then save it as “anything.ps1” file.
Next, we need to edit this code in “PowerGUI Script Editor.” Open up the tool and past the code in the script editor.
Then select the “Tools” tab and click on the “Compile Script…” option.
In the “Compile Script” window, click on the “Dependencies” button.
Next, under the PowerShell file bar browse for the “.ps1” file that we saved before and click the “OK” button.
To save all changes, click the “OK” button in the “Compile Script” window, and our PowerShell executable file will be ready and saved on the desktop of the computer.
When this “powershell.exe” file is executed in the victim’s computer, it will send a reverse shell connection to an attacker’s computer, as it is shown in the screenshot.
If you think that using SEToolkit’s shell command is a little bit complicated, don’t worry, you may also listen for incoming connections through netcat.
Ex: (root@kali:~# nc -l -p 443 –v)
Once introduced, backdoors are challenging to get rid of. Customarily, detection includes utilizing programming scanners to look for known malware marks in a server file framework. This procedure is mistake inclined, be that as it may. Backdoor shells are quite often covered using alias names and code obfuscation. Identification is additionally confounded since numerous applications are based on external systems that utilize outsider modules; these are some of the time weighed down with vulnerabilities or inherent indirect accesses.
Scanners that depend on heuristic and mark-based principles won’t have the option to identify concealed code in such systems. Regardless of whether a backdoor is distinguished, standard alleviation techniques (or even a framework reinstallation) are probably not going to expel it from an application. It is especially valid for backdoors having a persistent presence in rewritable memory.