Post Infection Impact

Recall that upon visiting a malicious URL, the browser downloads the initial exploit. The exploit (in most cases, javascript) targets a vulnerability in the browser or one of its plugins and takes control of the infected system, after which it retrieves and runs the malware executable(s) downloaded from the malware distribution site. Rather than inspecting the behavior of each phase in isolation, our goal is to give an overview of the collective changes that happen to the system state after visiting a malicious URL . Figure 14 shows the distribution of the number of Windows executables downloaded after visiting a malicious URL as observed from monitoring the interaction between the browser and the malware distribution site. As the graph shows, visiting malicious URLs can lead to a large number of downloads (8 on average, but as large as 60 in the extreme case).

Figure 14: CDF of the number of downloaded executables as a result of visiting a malicious URL  

Another noticeable outcome is the increase in the number of running processes on the virtual machine. This increase is associated with the automatic execution of binaries. For each landing URL , we collected the number of processes that were started on the guest operating system after being infected with malware. Figure 15 shows the CDF of the number of processes launched after the system is infected. As the graph shows visiting malicious URLs produces a noticeable increase in the number of processes, in some cases, inducing so much overhead that they ``crashed'' the virtual machine.

Figure 15: CDF of the number of processes started after visiting a malicious URL 

Additionally, we examine the type of registry changes that occur when the malware executes. Overall, we detected registry changes after visiting $57.5\%$ of the landing pages. We divide these changes into the following categories: BHO indicates that the malware installed a Browser Helper Object that can access privileged state in the browser; Preferences means that the browser home page, default search engine or name server where changed by the malware; Security indicates that malware changed firewall settings or even disabled automatic software updates; Startup indicates that the malware is trying to persist across reboots. Notice that these categories are not mutually exclusive ( i.e., a single malicious URL may cause changes in multiple categories). Table 4 summarizes the percentage of registry changes per category. Notice that ``Startup'' changes are more prevalent indicating that malware tries to persist even after the machine is rebooted.

Table 4: Registry changes from drive-by downloads.

Category	BHO	Preferences	Security	Startup
URLs %	6.99%	23.5%	36.18%	51.27%

In addition to the registry changes, we analyzed the network activity of the virtual machine post infection. In our system, the virtual machines are allowed to perform only DNS and HTTP connections. Table 5 shows the percentage of connection attempts per destination port. Even though we omit the HTTP connections originating from the browser, HTTP is still the most prevalent port for malicious activity post-infection. This is due to ``downloader'' binaries that fetch, in some cases, up to $60$ binaries over HTTP. We also observe a significant percentage of connection attempts to typical IRC ports, accounting for more than $50\%$ of all non-HTTP connections. As a number of earlier studies have already shown (e.g., [6,19,8,21,22,12]), the IRC connection attempts are most likely for unwillingly (to the owner) adding the compromised machine to an IRC botnet, confirming the earlier conjecture by Provos et al. [20] regarding the connection between web malware and botnets. More detailed examples of malware's behavior can be found in Polychronakis et al. [18].

Table 5: Most frequently contacted ports directly by the downloaded malware.

Protocol/Port	Connections %
HTTP (80, 8080)	87%
IRC (6660-7001)	8.3%
FTP (21)	0.9%
UPnP (1900)	0.8%
Mail (25)	0.75%
Other	2.25%