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
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web