What follows explains the stages of a drive-by attack carried out from a legitimate UK Website. It demonstrates how PC users become infected with malware by visiting a Website, even if their antivirus is up to date. I used a virtual machine pointing at our WebGateway proxy to demonstrate the attack.

First, I visited the Website of a UK bank. I took a screen shot, Image-1, of the login page, saving it for later reference. Next, I visited the UK website of a Christian organisation, House on the Rock. A legitimate organisation not associated with malware creators. The page loaded normally, giving me no reason for suspicion.

The User Temp folder is a vulnerable area of Windows for drive-by attacks. Opening this allowed me to monitor for files placed into the folder during my site visit. I also opened up the Windows process monitor, allowing me to see if anything started running in the background during my visit.

After refreshing the web page, I minimised it, keeping an eye on the processes and temp files.The first thing that happed was that, 'Java (TM) Platform Standard Edition' popped up on the bottom right of my screen, indicating that something was trying to exploit the Java client on my computer. I could also see in the Windows Process monitor that Adobe Reader was starting up and an executable file appeared in my Temp folder. I took a copy of the executable file for later analysis. Drive-by attackers often use transient files that only appear in the Temp User folder during malware installation and then disappear.

I later submitted the file to www.virustotal.com which runs samples through the most common AV engines. From 43 of the most popular AV products, only one, Comodo, identified the executable as malware.

Next I cleared my cache and retyped the bank's URL into the browser. This time the bank's website appeared with an altered logon screen, shown in Image-2. As you can see, the new logon screen was replete with additional boxes, requesting the name of my first school, my place of birth, my secondary school, my father's middle name, my mother's middle name, my maternal grandfather's first name and my personal ID or card number. Compare this to the legitimate site which only asked me to provide my personal ID or card number. The attack was underway.

This illustrates a fairly common man-inthe- browser phishing attack. The thing to note is that the URL and the SSL connections were both correct, so a genuine online session had been initiated with the bank. Additional information request fields had been injected into the HTML code as it loaded into my browser.

Returning to the Secure Web Gateway logs, I saw that 7 items of code had been picked up and blocked, based on analysis of how the code was trying to behave. This included file system, registry, and network operations. Among the items were a Java applet and three pieces of code ending in e=1, e=5, e=7. These were different exploits being served to my computer, based on an initial examination of workstation configuration. Code is often hidden within an iFrame on a website, so it is not visible, but it is nevertheless harbouring malware, without the knowledge of the hosting organisation.

The legitimate website was infected with malware by cybercriminals perpetrating a man-in-the-browser attack on unsuspecting visitors. It is worth noting that cybercriminals often host malicious code on legitimate Websites only for brief periods of time before moving on to fresh sites. Obviously, this is done to avoid detection by reputationbased security products. NC