Yes, its ethically acceptable to "trap them," as long as you don't do it for your own win. If you send them to an informative page, it's fine.
If you send them to the real company login, but include like ?phish=true
in the URL and then have logic on the server side to disable the account and then schedule the user for more education about phishing, then it's fine too.
What's unethical is if you send them to your own login page, even if you don't store or do anything with the details.
There is actually a business that engages in this, called "PhishMe". The company works this way:
- First, they will set up a reporting address for you, like
fraud@yourcompany.com
.
- Then, you will need to educate your users to report any suspected phishing to that address.
Then PhishMe will send out fake phishing mail to your employees. If the employees click the link, then it will be registered that they didn't react correctly on phishing. They also have forms and such to see if the user enter sensitive data (but of course they discard it immediately).
If they do nothing, it will be accepted as a good solution.
If they report it to fraud@yourcompany.com
, PhishMe will filter away the report (as they can identify that the phish mail was actually a fake educative phish) and then register that the user did a good thing of reporting it. They still forward all reports for genuine phishing mail sent by fraudsters to your real fraud reporting address.
Another thing you need to be aware of, especially if you use an external mail server, is that your fake phish could end up getting company servers blacklisted for phishing/spamming. Ensure the servers are set up to ignore such fake phish, and ensure you don't use any external contractors for running the mail servers. Also make sure the users do not forward the email to their Gmail account or such, by simply disabling the possibility to forward mail on the server side, and only allow IMAP/POP3 from internal network/VPN, to prevent fetching email from like Gmail. This prevents users from "reporting as spam" at such providers.
About legality, it wouldn't be illegal since its really not fake email actually, because "fake email" is email not written by the company, and mail written by a company is really not fake. It's the same thing as you cannot "fake your own signature", because then you are not faking it. And it could be shown that you have no malicious intent as you are redirecting them to an informative page about phishing.
Another important thing to consider is, obtain clear and written permission from company managers and such, that you have the company's full permission to do this, in case the company decides to do this to "get rid of you" by telling you to do things they then can report as crimes to the local authorities. It's the same effectively as someone giving an item to you for free, like "here, have it, its for free," and then going to the police and report you for theft, and you can't prove you got it for free. That's why papers are important.
However, when implementing such programs, it's important to allow the user to use his own signals to react on phishing. That's why you should preferably tell your mail server to insert a fake SPF validation header saying that SPF validation failed, for those fake phishing messages (and suppress the real SPF "passed" validation). Else the phishing mails will show up as genuine.
And you should also make sure other signs of the mail make it a phishing, so if the user uses tools to deduce if its phishing, it's important that these tools can react correctly and alert like it was a real phishing.