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.


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
Newest First  |  Oldest First  |  Threaded View
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-12-13
The FTP client in AceaXe Plus 1.0 allows a buffer overflow via a long EHLO response from an FTP server.
PUBLISHED: 2019-12-13
stb_image.h (aka the stb image loader) 2.23, as used in libsixel and other products, has a heap-based buffer over-read in stbi__load_main.
PUBLISHED: 2019-12-13
An issue was discovered in libsixel 1.8.2. There is a heap-based buffer over-read in the function load_sixel at loader.c.
PUBLISHED: 2019-12-13
Versions of the npm CLI prior to 6.13.4 are vulnerable to an Arbitrary File Overwrite. It fails to prevent existing globally-installed binaries to be overwritten by other package installations. For example, if a package was installed globally and created a serve binary, any subsequent installs of pa...
PUBLISHED: 2019-12-13
Versions of the npm CLI prior to 6.13.3 are vulnerable to an Arbitrary File Write. It is possible for packages to create symlinks to files outside of thenode_modules folder through the bin field upon installation. A properly constructed entry in the package.json bin field would allow a package publi...