110

Chapter 8

to targeted users will present your best chance of success. You harvest email 
accounts, names, and phone numbers; browse social-networking sites; and 
create a list of known employees. Your malicious email instructs the email 
recipients that payroll information needs to be updated; they need to click 
a link (a malicious link) in the email to do this. However, as soon as the user 
clicks the link, the machine is compromised, and you can access the organi-
zation’s internal network.

This scenario is a common technique regularly leveraged in both pene-

tration tests and actual malicious attacks. It is often easier to attack via users 
than it is to exploit Internet-facing resources. Most organizations spend a sig-
nificant amount of money protecting their Internet-facing systems with tools 
such as intrusion prevention systems (IPSs) and web application firewalls, 
while not investing nearly as much in educating their users about social-
engineering attacks.

In March 2011, RSA, a well-known security company, was compromised 

by an attacker leveraging this same process. A malicious attacker sent an 
extremely targeted (spear-phishing) email that was crafted specifically for an 
Adobe Flash zero-day vulnerability. (

Spear-phishing

 is an attack whereby users 

are heavily researched and targeted rather than randomly chosen from a 
company address book.) In RSA’s case, the email targeted a small group of 
users and was able to compromise RSA’s internally connected systems and 
further penetrate its network.

Browser-Based Exploits

We’ll focus on browser-based exploits within Metasploit in this chapter. 

Browser-based exploits

 are important techniques, because in many organiza-

tions, users spend more time using their web browsers than using any other 
applications on their computers.

Consider another scenario: We send an email to a small group at an 

organization with a link that each user will click. The users click the link, and 
their browsers open to our website, which has been specially crafted to exploit 
a vulnerability in a certain version of Internet Explorer. The users’ browser 
application is susceptible to this exploit and is now compromised simply by 
users visiting our malicious website. On our end, access would be gained via a 
payload (Meterpreter, for example) running within the context of the user 
who visited the site.

Note one important element in this example: If the target user were run-

ning as an administrator, the attacker (we) would do the same. Client-side 
exploits traditionally run with the same permissions and rights as the target 
they exploit. Often this is a regular user without administrative privileges, 
so we would need to perform a 

privilege-escalation attack

 to obtain additional 

access, and an additional exploit would be necessary to elevate privileges. We 
could also potentially attack other systems on the network in hopes of gain-
ing administrative-level access. In other cases, however, the current user’s 
permission levels are enough to achieve the infiltration. Consider your network 
situation: Is your important data accessible via user accounts? Or is it accessible 
only to the administrator account?