I wrote some Perl years back to take the fight to phishers. You would provide my script with the field names and POST URL of the HTML form within the phishing email, along with some generic types for each form field. There were types for firstnames, lastnames, email, addresses, usernames, passwords, social security numbers, and credit card numbers. The script would generate fake but real-looking values for each of these things--the credit card numbers would even pass a checksum test--and then post to the URL. It would do this as fast as the remote end would accept them with the aim of filling out their database (typically a text file on some compromised server) with bullshit data, making it hard to pick out the legit data from victims.
It worked wonderfully. I used it through proxies when I could and watched the phishers try to block me or even attack me back.
I work in security at a large Fortune 500 company. I know at first it sounds like phishing your employees will give you good insight, but you realize quickly that the data you get is not very useful. Here are the roadblocks I've hit with these kinds of simulation phishing services:
1. They rely on e-mail while phishing attacks come from multiple sources like Facebook and LinkedIn. Sadly, using those services to simulate phishing attacks violates their ToS.
2. Simulation phishing only provides pass or fail data meaning you cannot determine your weakest links in the organization. At best you get an "average" snapshot.
3. The data isn't very accurate or precise because there are too many confounding variables involved. Time of day, subject matter, type of phishing (attachment, social engineering, etc). Normally we ran our campaigns once a month but this wasn't enough to produce stable results.
4. Clicking doesn't mean they fell victim to the attack -- lot's of people click to investigate then report the links. Ideally, I'd like to specifically know WHY the employee clicked the link and HOW MUCH was actually at stake.
4. It pisses people off. There is enough animosity against us security folks that tricking your employees really hurts that relationship. People feel taken advantage of.
5. It doesn't actually improve security in any meaningful way. I found that it didn't actually improve people's ability to spot and report phishing attempts. They either became paranoid to the point where they were no longer productive in legitimate emails, or they had no improvements over time.
With that being said, our company has tried about a dozen of these kinds of services and the best one so far has been one called Apozy that is rather new. It's a different approach but the data and insight you get back is actually very useful.
I get these (contracting at a Fortune 500) pretty regularly (last week for example). They are pretty easy to spot and probably have some worthwhile training value, but Incan see that teasing out any useful data might be hard - I suspect you will need a huge corpus of templates and a lot of employees.
Sadly I thought of setting up a company like this to do just this job. But Apozy's gasification approach seems a good idea
There are many sites like this and I love what they are doing for raising awareness. As one of the first people to ever fight phishing (I worked at eBay and PayPal fighting phishing before there was a word for it), I'm keenly aware that awareness is the only way to really stop it.
That being said, I don't like these reports, because any time I get a phishing email I immediately load it up in a protected VM to see what it does, so it would count me as a victim. Since the page you go to isn't a real looking login page, you can't differentiate between those who fall for it and those who just clicked to see what it was.
You need to actually set up the fake page and see who puts in valid credentials to get a true report.
Not to dismiss your experience (perhaps you had not heard the term yet) but the term 'phishing' has been around longer (mid 90s at least) than ebay and paypal have been big enough to be phishing targets.
I was deeply involved in the fledgling anti-spam industry in the early 2000s, by way of the anti-virus industry, and it was not a common term then. Wikipedia gives the first recorded use as '95, and that refers to it as "fishing", and as being AOL-specific.
I definitely remember old AOL "progz" referring to "fishing"/"phishing". "Phreaking" was a very popular term before that, which is where I'm guessing the f/ph replacement came from.
Most people won't think twice about the link in the email. They'll usually stop at the login screen because it doesn't look right, has a wrong URL, etc. Having done a lot of work in this area I can tell you that I'm definitely not in the minority.
Clicking the link from a secure VM sure puts me in the minority, but just clicking the link? Lots of people do that and then get suspicious.
That's why you need two steps to truly know how bad it is.
I'd received an email on my corporate email address from some courier service claiming that they weren't able to deliver a package to me. The email also contained a link which upon clicking took me to a page which displayed the message "congratulations! You've fallen prey to a phishing attack".
Later we realized that this was a test conducted by the firm (a large investment bank) that I work for!
The courier service vector is an effective way to trick people.
You can ring an intercom in any big apartments block and ask to be opened the door to deliver whatever, most of the time you'll find a resident to open. No reason for it to not work in emails :)
That one is a classic, although the text is incorrect as you didn't fall prey to the attack by simply clicking the link (if you work computer is vulnerable that is ITs problem, if it is a zero-day then nobody is safe).
Not related to mail fishing as javascript is filtered (disabled) for emails, but more with browsers ...
I'm a nitpicker but that's one of the reason why i dislike safari browser.
You need the status bar enabled in order to see the links destination url and I don't like the 7 pixels height taken by this bar.
But as I am browsing with javascript enabled, I can't be sure that the url showed by the link is the destination I'll be sent to. That's something quite hard to explain to non technical people (like my parents). I'm not even trying to be honest.
I'm not sure what to think about this behavior and generally with link shortener, it's an easy way to phish people in forum, comments, ...
Love it! My recommendation would be to offer an option for allowing the target to be tricked through the whole process. (Even if credentials are discarded completely.) The idea here is nothing is left to the imagination. What you have is great, but it requires them to read and be observant, which is not the type of person who falls for phishing emails. Clicking the link is "No-No" #1, don't exclude "No-No" #2 from your process.
Thanks and thanks for the suggestion! One thought I'd had was longer/more in depth campaigns. It's good to know other people would be interested in that as well.
One thing I was concerned about was that people might not trust some random guy on the internet to properly discard those credentials.
I think you are completely correct in your second sentence there - there's no way I'd use this if there was any chance of my colleagues actually disclosing real credentials to a third party.
(Suspicious me is wondering if you're evil - 'cause if evil-me was in your position, I'd be selectively showing your "you've been phished, ha ha!" landing page to most people, but mining LinkedIn/Rapportive/Google for key contacts at any domains that sign up, and displaying genuinely evil credential-collecting-login pages if I got a hit from senior sysadmins or a CTO/CIO/CSO...)
The phishing page could be set up to have a fake form that sends no data, and says "you've been phished" when someone tries to submit information to it.
At that level, though, the pen-tester really ought to have control over the phishing landing page.
Do something like Google's new authentication process - rather than asking for the username and password on a single page, ask for the username only with a "continue logging in" button. There's no need to actually ask for a password.
Throwing up a javascript alert as soon as one character is typed in the password field could allow you to see who was about to actually type something in there. Of course some people troll phishers with fake passwords, but this narrows down your false positives without you actually collecting credentials.
Totally legit concern. Seems like it would be an option that a customer might want after they've used the service for a bit and built up a level of trust. Overall, great idea.
One option that might do something to ensure trust would be to have the javascript on the page that accepts the credentials be unminified and readable.
Or provide a self-hosting option; JavaScript can be changed at any moment. Request A might look fine, but request B for the same file 5 minutes later could be malicious.
I think that'd be the best way to go. Or, half-way between hosted and self-hosted: in exchange for payment, provide a button that lets them launch a CuttlePhish instance on Heroku. (I'm not sure if this can be automated to the point that regular non-developers would understand it, though.)
That is an excellent idea! In fact, we've just implemented the billing service, so please go to http://cuttIeph1sh.com/account/billing, log in to your account and provide your payment information to continue receiving our phishing reports!
Out of interest, do the Firefox team and the Chromium team compare notes on decisions like this?
Purely in this one area (IDN homograph attacks), it might be an idea to look at the Chromium Unicode vetting rules (Which characters and combos get "punycoded") as they seem to be more conservative from a "Latin" perspective.
I'm not sure if a "blacklist" (mentioned in the bug report) is the best way of handling this. Perhaps only direct-encoding the "exemplar characters" for the language setting, and punycoding everything else? I'm pretty sure it would have eliminated the mid-dot issue, but perhaps this "whitelist" is too prohibitive.
You might be right--that would definitely help people get further into the flow before the high-friction "payment" step. (If I went the "pay to view report" route I'd obviously have to be super upfront about it; wouldn't want there to be an unpleasant surprise for people at the end of the flow).
One other thing I thought about was maybe making the service free for phishing up to N people.
I often intentionally click links to phishing sites, and sometimes enter in fake usernames and passwords. (I even wrote several bots to auto enter thousands of random usernames and passwords.)
Sometimes phishing links may be tracked, and if you click on one of them, you may be added into a list of "potentially highly vulnerable targets" and therefore receive more of such emails in the future.
If they have a 0 day for my browser, then they likely have an enormous budget with tons of ways of getting it to me besides phishing. I click so many links per day via reddit, HN, and other sites that the security gained by not clicking a phishing like is likely less than the education value of clicking it.
I think the actual danger for me of clicking a phishing link is opening a phishing tab, then moving on to another tab, then a while later coming back to the phishing tab but forgetting it was phishing and entering my password. 95% of the time I remember to check the url before entering my stuff, but everyone makes mistakes.
Me too. I often intentionally click on phishing links to see how well the page is done and where it's hosted.
OP should probably consider adding login pages etc (discarding the credentials) to actually find people who would fall for it, as someone here suggested. Many people click the links just out of curiosity.
Quick question - are you concerned about trademarks (Amazon and such) being included as the phishing templates? Reason I ask is that I'm working on a hosted project [1] similar to this and have considered including default templates. I've held off for this exact reason.
Edit - another question, your screenshot in the intro page shows an email (in the Gmail client) coming from "support@github.com". Github has spf records setup so I would be interested to know how you manage to spoof the actual email address itself without getting flagged as spam.
> Quick question - are you concerned about trademarks (Amazon and such) being included as the phishing templates?
I'm honestly not 100% sure, but I think in the context of a phishing site using trademarks like that falls under fair use. But IANAL.
> Github has spf records setup so I would be interested to know how you manage to spoof the actual email address itself without getting flagged as spam.
I don't know much about spf records, honestly--for every site I had to try multiple "From" and "Reply-To" addresses to get the emails past gmail's spam filter. Some of them didn't even arrive in my spam folder, (apparently they just got killed on some intermediate hop). support@github.com definitely works, at least for me--you should try it yourself and see how it goes.
The root of trademark law is preventing consumers from being confused or deceived about brand affiliations. I believe using a trademark to refer to the product/service symbolized by the mark is a protected case, so long as you are clear that no endorsement exists. Looking at your language, this is abundantly (and amusingly) clear.
You might have something to worry about with your insinuations about Dropbox though. I'm quite sure they are strongly pro-cephalopod.
Might be worth reaching out to the relevant companies once you reach a certain size, as they presumably will patch any holes in their spf records that you bring to their attention.
Consider changing pricing to $/click (pay per victim), so that companies are paying for the value you provide (detection security holes), and the CTO can "bet" the CEO that employees need better training/protection.
The problem there is that the person/group conducting the test (presumably security team of a 500 person org) doesn't know if it will cost 500 x PerClickRate, or 5 x PerClickRate.. They don't yet know the stupidity of their users. Variable pricing like that can be a deal breaker for a small company.
You could address that by creating a control on the price. "I want to run this campaign against 500 users. But my budget is $100." The service sends out e-mails up to the $100 cost if they all clicked through, then deducts the actual expenses from the budget. In a few days, it sends the next batch of e-mails targeting the rest of the budget. Continue until either the e-mails are all sent, or the budget is expired.
I suspect explaining that pricing model is a sales risk. flat fee or price per contact is far more intuitive I suspect.
Even reading your explanation, I'm not clear on what it will cost me -- this sounds more like pre-paying? how long should it wait between batches? how effective will batching be? Rumors of phishing/testing could move quick in the organisation making the report outcome misleading.
What if this site occasionally sends out real phishing mails? If a lot of sites are using it, they would have interesting stats one could use to target the right audience.
Not saying they would, but they could get hacked of course...
Another service which does a similar thing that's been around some time, I used them but the spam filter ate all my fake mail, as it should :-) https://phish5.com/
If your customer is using google domains, microsoft 365 or what else, and the employees do not fall in your phishing attempt and report your mail as spam, you may be heading for some trouble with delivery afterward.
I'm sending the emails directly from my server with the unix "mail" utility.
Ending up in spam is actually what most concerns me about this idea, and in fact this concern was what led me to choose the "you don't pay unless someone clicks on a link" pricing--I was worried that some of the emails might eventually start ending up in spam after a few customers and wanted to make sure I wouldn't be charging people if that happened.
I'm planning to see what works once/if the phishing emails actually start ending up in spam.
I was doing exactly the same project probably 8 years ago when I was still a high school student. I used to have a lot of websites, too but I never launched as I thought phishing is probably illegal and unethical.
It worked wonderfully. I used it through proxies when I could and watched the phishers try to block me or even attack me back.