Mastering Kali Penetration Testing: Hands-on Web Application Attack Methods with BeEF

 

1. Course Description

 

This course is a hands-on lab tutorial focused on Kali penetration testing. To clearly explain certain operations during experiments, theoretical content will be included. You’ll also find recommendations for the most worthwhile articles to read. You’ll solidify your theoretical foundation while engaging in practical exercises.

Note: Due to the high configuration cost of the cloud host used in the experiments, the number of attempts is limited to no more than 6 per experiment.

2. Study Methods

 

The Kali series courses by Experiment Building include five training camps, with this one focusing on web application attack methods. The course contains 20 labs, each providing detailed steps and screenshots. It is suitable for students with some Linux system foundation who wish to quickly get started with Kali penetration testing.

The study method involves a lot of practice and asking questions. Start the lab and follow the steps step-by-step, while understanding the detailed content of each step.

If there is recommended reading material at the beginning of the lab, be sure to read it first before proceeding with the experiment, as theoretical knowledge is a necessary foundation for practice.

3. Content Overview

 

In this experiment, we will initially engage with BeEF and complete a penetration practice using BeEF. The principle is not difficult, but it is important and requires the completion of the following tasks:

• The general implementation structure of BeEF
• The type of attack to which BeEF belongs
• BeEF webpage source code theft
• BeEF popup prompts
• Implementation of phishing login with BeEF

4. Recommended Reading

 

Recommended reading for this lab session includes:

1. BeEF GitHub Wiki:

5. Introduction to BeEF

 

5.1 BeEF Structure

 

BeEF is currently the most popular web framework attack platform, focused on exploiting browser vulnerabilities. Its full name is The Browser Exploitation Framework.

BeEF is an open-source framework written in Ruby, and you can find it on GitHub. If you’re willing, you can also contribute your code to them.

Here’s how BeEF works:

(This image is from beef_wiki)

BeEF provides a web interface for operations. Once a browser visits a page embedding hook.js or loads the hook.js file, it continuously sends its message to the BeEF server using GET requests, providing detailed information about the other party, allowing attackers to search for vulnerabilities or use the browser as a zombie to launch attacks on other devices.

Just like fishing, as long as the fish bites the bait, it will get hooked, and we can control and catch the fish through the hook. The attack target is the fish, and the hook is the hook.js, which aptly named.

(This image is from beef_wiki)

Once BeEF is up and running, two components are crucial:

• User Interface
• Communication Server

The User Interface provides the web interface for operations, whereas the Communication Server receives information from browsers that have been “hooked” via HTTP, making it the most critical component of BeEF.

Other functionalities come through extensions and module additions, which can be seen in the BeEF directory:

On the lab desktop, double-click the Xfce terminal to open it:

Then use the sudo virsh start Kali command to boot the virtual machine. Note the case sensitivity, as the virtual machine’s name starts with a capital letter:

Next, connect to Kali using SSH. Note that the username root and password toor are not displayed. Use the command ssh root@kali as the IP address and hostname pairings have already been entered into the /etc/hosts file to avoid inputting difficult-to-remember IP addresses:

Then navigate to BeEF’s main directory using the command cd /usr/share/beef-xss/:

The file purposes within are:

• arerules: Features in this directory are preloaded before BeEF starts and triggered when a target gets hooked
• beef: An executable file used to launch all functionalities of BeEF
• beef_cert.pem: Certificate for HTTPS
• beef_key.pem: Key used for HTTPS
• config.yaml: Configures parameters loaded during BeEF startup
• Gemfile: Configures Ruby dependencies
• core: The core directory of BeEF, responsible for primary function implementation and loading extensions (expansion modules) and modules (attack modules)
• extensions: Depository for extension modules
• modules: Repository for various attack modules, consisting of three main files:
  • command.js: Command file;
  • config.yaml: Configuration file for the module;
  • module.rb: Defines classes used within the module and handles some functionalities.

The most important ones are the three directories of core, extensions, and modules.

5.2 Categories of BeEF

 

BeEF’s attack methods fall under XSS, as described earlier.

So, what exactly is XSS?

Cross-Site Scripting (XSS) is not to be confused with Cascading Style Sheets (CSS), hence the acronym XSS is used for cross-site scripting. Malicious attackers insert malicious JavaScript code into web pages. When a user browses the page, the embedded JavaScript code is executed, thereby achieving the goal of maliciously attacking the user. (Source: Baidu Encyclopedia)

The malicious code is capable of execution because when we access a page, the browser downloads the page from the server, then parses the HTML from top to bottom. When it encounters a script tag, it calls the JavaScript interpreter to execute the script. After execution, it continues parsing the HTML, allowing the attacker’s code to be executed.

Such attacks can lead to theft of user cookies, account hijacking, DDOS, etc.

XSS attacks can be categorized into:

• Reflected XSS: The server does not store the user’s submitted data and directly outputs it, such as through a GET request or other actions to obtain variables, which are directly output and executed via the URL.
• Stored XSS: The submitted malicious code is stored on the server, affecting all users who visit the site. If the malicious code is not removed, the attack will not stop, hence stored XSS is also called persistent XSS.
• DOM-based XSS: Modifies DOM nodes on the web page, resulting from web script parsing, similar to reflected XSS.

In BeEF, hook.js is used to establish a connection between the attacker and the victim, allowing the attacker to gather detailed information from the victim. It also enables the attacker to transfer local attack scripts to the victim’s host for execution. BeEF can perform simple XSS attacks and collaborate with Metasploit for more advanced attacks, even allowing remote control of the victim’s device.

Importantly, hook.js is not a static JS file; it is dynamically generated by BeEF. Those interested can find how it is created and defined around line 50 in core/main/handlers/hookedbrowsers.rb and around line 16 in core/main/handlers/modules/beefjs.rb.

The primary purpose of hook.js is to impersonate the user and gather related information.

6 Basics of BeEF

 

6.1 Starting BeEF

 

From the above, we have a basic understanding of what BeEF can do. Now, let’s try some simple actions.

Enter BeEF’s main directory with this command:

 cd /usr/share/beef-xss

View BeEF’s configuration information through less config.yaml:

In the configuration file, examining the HTTP-related information, we learn that BeEF runs on port 3000:

Upon searching for the keyword “user,” we can view the database BeEF uses, including the database name, username, password, and the admin username and password:

After exiting the configuration file with q, execute the startup script for the program in the main directory:

 ./beef

Then, we will see information about the program startup appearing in the terminal interface. Starting BeEF can be a bit slow, so patience is needed. When this line of information appears, BeEF has fully started, and we can access the admin page through the browser.

We can use Firefox on the desktop to visit the URL we obtained earlier. The login page will require a username and password, which both default to: beef.

After accessing the admin page, we observe several sections:

Then, we open a new page to visit a URL like this:

http://192.168.122.101:3000/demos/butcher/index.html

After visiting this page, we return to the admin page and notice an additional host appears in the `Online Browsers` section. This is because the page we visited embedded `hook.js`. Our browser downloaded the page’s HTML from the server, parsed, and executed it. When `hook.js` was encountered, it was executed indiscriminately, thus connecting the browser to the BeEF backend and maintaining communication, which is why a new host appears under `Online Browsers`.

Returning to the phishing page, we can use F12 to view related page info, switching to the Network tab to see that `hook.js` continuously sends out GET and POST information.

We can also view a random message to understand its content.

Additionally, we can use Wireshark to capture packets on the virbr0 network card to see more detailed content.

As long as the page remains open and `hook.js` continues running, messages will be sent continuously.

Back in the admin management page, clicking the host icon reveals detailed information about the host’s browser:

After obtaining related platform information, I believe everyone is most concerned about how to attack the target. Switching to the Commands tab, we can see all the attack modules that have been loaded.

Upon casually opening a folder, we can see that each attack module is preceded by a light of a different color. Different colors have different meanings, which those who have thoroughly read the Getting Started page will understand:

6.2 Trying Out BeEF

After understanding the general framework structure of BeEF, we can give it a try. Expand Browser –> Hooked Domain, then click the Get Page HTML module. This allows us to retrieve the source code of a page a user is visiting without their knowledge:

After executing the command, we will see an additional task in the Module Results History. Clicking this task will reveal the source code of the page the user is currently viewing:

Implementing this is not difficult. By examining the source code, we find that the Get Page HTML command source code is located at /usr/share/beef-xss/modules/browser/hooked_domain/get_page_html/command.js. We can use the less command to view it:

 less /usr/share/beef-xss/modules/browser/hooked_domain/get_page_html/command.js

Investigating the related command:

What do these two invoked functions do? We can use less to examine the file /usr/share/beef-xss/core/main/client/browser.js and search for the function names used (by simply typing /getPage and pressing Enter):

The principle is quite simple. These commands are sent to the remote browser, which uses JavaScript’s interpreter to parse and execute them, thus obtaining the desired information,

The prerequisite for all this is that hook.js is receiving our data on the client side.

Anyone with some basic JavaScript knowledge would know that if you can do that, you can also prompt a window on the target host’s browser. Indeed, that’s the case:

After execution, we view the previously hooked page, and we can see:

By using less /usr/share/beef-xss/modules/browser/hooked_domain/alert_dialog/command.js, we can see that the implementation is quite simple, involving a remote call to the alert function.

We can also redirect the page:

After execution, we notice the page redirects to the localhost page:

Don’t assume all the attack modules in BeEF are this trivial. They’re not. We can use another module:

This module will pop up a window identical to the Facebook login window, tricking you into thinking you’ve been logged out and need to log back in. If you enter your username and password here, the attacker will indeed capture your login credentials.

The result after execution:

If you enter a username and password:

Returning to our backend page, we can see how easily we’ve obtained the target user’s login name and password.

Similarly, we can inspect the source code less /usr/share/beef-xss/modules/social_engineering/pretty_theft/command.js, with no particularly sophisticated principles:

Executing some HTML statements via DOM to create the login interface:

Then wait for the user to submit their username and password before returning the result:

This is the phishing site scam, creating an interface that is identical to the official website, making you mistakenly think it’s the official site to deceive login information, etc. The principle is not complicated, and the code is not much; the lengthy part here is due to simulating seven login interfaces and performing some decision-making inside.

6.3 BeEF Integration

As we learned from the previous introduction, Metasploit is an extremely powerful tool, so Kali includes it. BeEF is also a significant tool for XSS attacks. If these two strong tools can join forces, it becomes even more effective, greatly expanding the attack surface and enabling a wider range of actions.

This section will guide everyone to load Metasploit-related modules in BeEF. However, due to environmental limitations, while BeEF can load Metasploit’s attack modules correctly, the Command loading part often freezes. Enthusiasts can try it out in a local environment. By integrating Metasploit, you can even breach the shell of a target user who has loaded hook.js, allowing remote login control.

We need to configure the following:

1. Modify BeEF Configuration to Enable Metasploit

The BeEF configuration is located in the config.yaml file in its main directory:

 vim /usr/share/beef-xss/config.yaml

We only need to modify the following content:

# Original text

metasploit:
    enable: false

# After modification

metasploit:
    enable: true

Enable Metasploit-related module loading when BeEF starts

2. Modify Metasploit Extension Module Configuration

Updates are needed in the configuration of the Metasploit module within the extensions:

 vim /usr/share/beef-xss/extensions/metasploit/config.yaml

Make the following changes:

# Original text

{os: 'custom', path: ''}

# After modification

{os: 'custom', path: '/usr/share/metasploit-framework/'}

Additionally, you will find user and pass configurations in the file, which establish authentication when BeEF connects to Metasploit. It is recommended not to change these.

Once modifications are complete, save and exit, then restart PostgreSQL (service postgresql restart), and then start Metasploit (msfconsole). After the Metasploit console page is up, load modules connecting to BeEF:

 msf > load msgrpc ServerHost=127.0.0.1 Pass=abc123

Once you restart BeEF, Metasploit-related modules will be loaded, as indicated in the load messages:

This way, we achieve the powerful integration of BeEF and Metasploit. We can therefore use XSS to perform more in-depth and automated penetration. However, due to our environment, when loading Metasploit-related Commands in the BeEF backend, connections might not establish. Try it locally if interested.

7. Summary

In this session, we learned about the following. For any unclear parts, feel free to participate in discussions at Shiyanlou Q&A:

• Overall structural implementation of BeEF
• Attack types associated with BeEF
• Web page source code extraction via BeEF
• Popup alerts with BeEF
• Phishing login information theft with BeEF

Please ensure you can complete the entire experiment by yourself. Simply reading the text is easy, but real operation brings various challenges, and solving these issues is the true process of gaining knowledge.

8. Assignments

1. Attempt to integrate BeEF and Metasploit locally.