Perimeter
3/8/2010
09:42 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Facebook As A Spear-Phishing Tool

My company Secure Network has been performing a variety of penetration tests that leverage information derived from sites such as MySpace and Facebook.

My company Secure Network has been performing a variety of penetration tests that leverage information derived from sites such as MySpace and Facebook.Some of our assignments have been to gather intelligence from these sites, which allowed us to steal the identities of employees, gain physical access to the workplace, and even get connected to internal networks. Numerous clients have asked us to see whether social networking sites used by their employees can lead to successful phishing attacks against their company and personnel. The results from the tests have been incredibly successful -- yet, at the same time, frightening.

It works like this: To prepare for a phishing attack, we start by focusing on the company Facebook group sites that were established by the employees of our client. Using a bogus identity, we join the company Facebook site and start mining the names and email addresses of individuals who identify themselves as employees. In the event they don't provide a company email address, we use the Internet to learn and use the email naming convention of our client, and then build our list based on that.

As we collect a database of names for our phish, our next step is to prepare the components needed to retrieve the bounty of our scam. We secure a domain name similar to that of our client, but include something of common importance to all employees. This domain name usually takes on the appearance of a human resources or benefits portal. When we email the employees as "human resources," they are redirected to a Web page ,such as https://www.xyzcompany-benefits.com. Since the tests we perform collect real user names and passwords, we also secure a certificate so no data is obtained in clear text.

The appearance of the page takes on the look and feel of the company Website with similar banners, logos, and navigation structure. Our clients frequently ask we "dumb down" the page to provide a sporting chance for their employees to realize the page is a forgery. In most cases, we fill the page with misspelled words, irregular shaped logos, and a fine-print disclaimer that says the page is completely fictitious and has nothing to do with the human resources department.

The phishing email itself has the appearance of coming from the human resources department of the company. The content of the letter usually has a message that indicates a new benefits portal is being launched, and that the employee should follow the enclosed link. When directed to our bogus page, our phishing target is requested to enter their user names and passwords as they do each day when they log onto the company network. When they enter in the requested user name and password, we direct them to an "Under Construction" or "Come Back Soon" page.

The appearance of the email is typically formatted in HTML and follows the appearance of the page they are being directed to. As with the phony Web page, we give the employees a chance to spot that the message is a fake by sending the email from a Hotmail account, writing the message with poor grammar and numerous misspellings.

The day of delivering the payload is very important: We prefer Sunday night. Having mail stack up from Friday evening and during the weekend allows our message to be interwoven into a mix of email messages.

The results of our Facebook phishing tests have provided some amazing results. Although the size of the company makes a difference, on average we have been able to accumulate 300 to 500 phishing targets from Facebook and other social networking sites. When we launch our Facebook spear-phishing attack, we usually get an average response rate of 45 to 50 percent. So nearly half of the employees respond to our email with the logins and passwords they use on their employers' network.

When launching these directed phishing tests, we also found that in most cases, the tests have to be stopped by the middle or end of the first day after our email was sent. The reason is the phish usually becomes forwarded on by our targets to other company employees and entire departments: This exponentially increases our audience and creates mayhem in the company when somebody in HR finally realizes a phish is running rampant in the organization.

Another interesting finding is that targeted users will often provide more than one login and password when a displayed page indicates "Under Construction." Frequently, a respondent will enter a relatively hard password, but with a numerical sequence like Summer1, Summer2, and so on.

When we present the findings to our clients, it becomes clear that wealth of information collected from an unofficial company Website on Facebook could lead to a significant breach in their company network.

So what should you do to minimize the risk of company information being leaked or gathered via social networks? Here are a few tips:

-- Officially sponsor the social networking site and assign an administrator who is responsible for permitting employees to join. This will help control somebody infiltrating the site for devious purposes.

-- Establish a social networking policy. If your employees are participating in social networking sites (company sponsored or not) makes sure company policies dictate what is and is not permissible. For example, divulging your corporate email account on social networking sites should not be permitted.

-- Last but not least, if employees feel the need to gather and converse about their day-to-day work, personal lives, and hobbies, consider a corporate intranet. Maybe someday social networking vendors will launch a product that will provide the same features and benefits, but with the security tools needed to keeps employees and company secrets safe. But in the meantime, it's up to you. Steve Stasiukonis is vice president and founder of Secure Network Technologies Inc.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: LOL.
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-3154
Published: 2014-04-17
DistUpgrade/DistUpgradeViewKDE.py in Update Manager before 1:0.87.31.1, 1:0.134.x before 1:0.134.11.1, 1:0.142.x before 1:0.142.23.1, 1:0.150.x before 1:0.150.5.1, and 1:0.152.x before 1:0.152.25.5 does not properly create temporary files, which allows local users to obtain the XAUTHORITY file conte...

CVE-2013-2143
Published: 2014-04-17
The users controller in Katello 1.5.0-14 and earlier, and Red Hat Satellite, does not check authorization for the update_roles action, which allows remote authenticated users to gain privileges by setting a user account to an administrator account.

CVE-2014-0036
Published: 2014-04-17
The rbovirt gem before 0.0.24 for Ruby uses the rest-client gem with SSL verification disabled, which allows remote attackers to conduct man-in-the-middle attacks via unspecified vectors.

CVE-2014-0054
Published: 2014-04-17
The Jaxb2RootElementHttpMessageConverter in Spring MVC in Spring Framework before 3.2.8 and 4.0.0 before 4.0.2 does not disable external entity resolution, which allows remote attackers to read arbitrary files, cause a denial of service, and conduct CSRF attacks via crafted XML, aka an XML External ...

CVE-2014-0071
Published: 2014-04-17
PackStack in Red Hat OpenStack 4.0 does not enforce the default security groups when deployed to Neutron, which allows remote attackers to bypass intended access restrictions and make unauthorized connections.

Best of the Web