Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

Flying Phish Hooks Schools of Employees

Penetration test proves many workers can still be easily fooled

My company, Secure Network Technologies, makes its living by testing the physical security of corporate networks. We use all sorts of social engineering attacks to show our clients their vulnerabilities, frequently disguising ourselves as copier repairmen or air conditioning technicians. Recently, however, my partner, Doug Shields, suggested we should try to “phish” our way into a client's network.

We proposed the phishing idea to some of our customers, and two of them accepted the penetration challenge. The goal was to see how many users would respond to a bogus email by clicking on a link. Permission for the pen test was granted by our clients, and the appropriate agreements were put into place.

The two customers were from very different industries with numerous users of varying computer skills, so we weren't sure how many people would read our phishing email, much less respond to it. We also were concerned that many of our messages would be caught by spam filters, which were employed by both clients.

Like many phishing scams, our plan involved crafting an email to the employees, requesting them to respond by clicking on something. We tasked our summer intern, Karl Bitz, with putting something together.

Within an hour, Karl came back with an elaborate email, crafted in HTML, that approached the employees as one of their company's benefit providers. A link in the email brought the users to a counterfeit site that requested a username and password via an online form. If they filled out the form, the employees were promised a $50 gift credit from a well known online retailer (bogus, of course).

After reviewing the proposed phish, we realized it was too good. We spoke with legal counsel at both companies and decided that its realistic appearance was an unfair advantage and that we needed to dumb it down. We were also concerned about objections that might be raised by the benefits provider. We decided to make some changes to make the phish less dicey – but it's worth noting that a real criminal wouldn't have been concerned about any of these issues.

In an effort to make the phish a bit less convincing, we decided not to register a domain name that looked close to the company’s real one (sometimes called typosquatting). We didn't use a very official looking address as the source address – we used a free email service as the sender. We debated about purchasing an SSL key, but abandoned the idea when we decided not to collect any user information.

Instead of fooling the users, we decided to teach them a lesson. If they clicked on the dangerous link, we wouldn't collect their data – we'd simply route them to a Wikipedia page that explained what phishing was. As a kicker, we added a note the bottom of the email:

    Please note that clicking embedded links can often lead to stolen information via phishing scams. Feel free to navigate to our login page by typing the address into your browser window. The link is provided merely for your convenience. User information will never be shared with anyone outside of XYZ [the user/client's company name] or any third-party customers and providers. (C) 2008 XYZ Company.

In both of our phishing attacks, we gathered email addresses from public sources – this was more realistic than if we had used the client's own email lists. The day we launched the phish, we anticipated minimal response, if anything at all. We were wrong.

Of approximately 350 emails we sent to employees at Client A, 55 received a response. We believe the actual number of respondents might have been even higher, but the client's IT department informs us that several employees can receive mail but have no access to the Internet.

Client B's attack results were even more interesting. We sent approximately 600 emails, 450 of which were delivered (150 were rejected). Of the 450 delivered emails, 185 people clicked on the link. Six people wrote back and requested additional assistance because they kept being routed to a Wikipedia page on “phishing,” and not to the online retailer's gift card page.

The most amusing result was the email we received the following day. One of our "phish" sent a note to our free email account – apparently assuming that we were the IT department – and not only complained about the misdirected link, but also asked us to come to his location to install a common software application.

We tried to reply back to confirm, but the organization's IT department had caught on to our phishing scam and blocked our email. Not willing to give up, we phoned our desperate user and scheduled an appointment with one of our people. The next day Secure Network rookie employee Griffin Reid went into the client's building and showed up to do the software installation.

When Griffin left for our client's location, I waited nervously for the phone to ring with news he had been detained by security and that our plan had been foiled. But later that morning, I was pleased to see him walk into our office.

Within minutes of his introduction, Griffin had been left alone to resolve the laundry list of problems our user was encountering. After spending a considerable amount of time on the client’s computer and internal network – during which he could have accessed any number of files or other data – Griffin called it quits and headed back to our office.

Our simple phishing attack had turned into a potential security disaster for our client. The thought of end-users responding to questionable emails or clicking on forbidden links is pretty pale in comparison to a physical attack by someone pretending to be from the company's own IT department. It appears that our client's security people have a lot of work to do.

— Steve Stasiukonis is VP and founder of Secure Network Technologies Inc. Special to Dark Reading

Steve serves as president of Secure Network, focusing on penetration testing, information security risk assessments, incident response and digital investigations. Steve has worked in the field of information security since 1997. As a part of that experience, Steve is an ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
7 SMB Security Tips That Will Keep Your Company Safe
Steve Zurier, Contributing Writer,  10/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: The old using of sock puppets for Shoulder Surfing technique. 
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8216
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure .
CVE-2019-8217
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-8218
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure .
CVE-2019-8219
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-8220
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions, 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .