
Phishing Is the Internet’s Most Successful Con - marmot777
https://www.theatlantic.com/technology/archive/2018/09/phishing-is-the-internets-most-successful-con/569920/?single_page=true
======
dmbaggett
A couple years ago at Inky we pivoted away from general improvements to email
to focus on phishing prevention using ML and computer vision, and this has
been tremendously successful. (This pivot was motivated primarily by Google
Inbox, which of course just got shuttered -- but that's another post.)

One challenge with phishing is that virtually all the "best practice" pieces
written by the press still follow this Atlantic article's "blame the user"
approach to phishing prevention. I.e., train your end users to not click on
stuff in bad emails.

Unfortunately, what we've seen over the last year or so is exactly what you'd
expect: now that many companies are running simulated phishing training
campaigns -- sending fake phishing emails to end users to try to train them to
not click on "bad links" \-- attackers are now sending brand forgery emails
that are _essentially perfect looking._ The key insight here is that the
attacker actually has a _labor-saving technique_ that is _also_ completely
devastating to the approach of training users: "Save As HTML".

It's obvious in retrospect, but all the attacker has to do is take the exact
HTML from a real transactional email (say, a DocuSign request), edit it to
change one link, and resend it. (In security parlance this is a kind of
"replay attack".) By definition, the body of this email will look identical to
the original transactional mail, so you're left with training users to see the
invisible. The hapless end user logs in "to DocuSign" and thereby gives the
attacker his/her credentials.

In contrast, a machine learning system that is trained to recognize brand-
indicative clues from emails can trivially verify DKIM, etc. on the mail to
determine whether the mail really is from DocuSign or not. (It's actually not
really trivial, because DocuSign might send mail through MailChimp or some
random domain they never told you about, but that's a detail...) Software 1,
Humans 0.

This leads me to personally believe that while phishing awareness training is
important and a good practice, the future must be one where the machines do
the vast majority of phishing email identification, blocking these emails
before they reach end users. And it's a hard problem.

Of course, attackers can't precisely control the headers -- e.g., they can't
easily send DKIM-signed mail from a domain named docusign.com -- so they can't
literally replay a real DocuSign mail. But here again they use lots of clever
tricks. One of my favorite (i.e., most evil) real-world phishing emails was a
clone of an American Express "confirm card activity" email sent from domain
aexp-ib.com. Most recipients would plausibly believe that that domain was some
kind of internal Amex mail server or something, so it doesn't look at all
weird. Even more devastatingly, this email came DKIM-signed -- with SPF and
DMARC "alignment" \-- by a very high reputation sender (Google), so it sailed
right through mail protection systems based around traditional "good mail /
bad mail" signals.

Why was it signed by Google? Because the attacker set up a G Suite account and
sent the emails from there. This is another challenging phenomenon we're
seeing: it's trivial for attackers to "inherit" the good reputation of a
shared service like G Suite in this manner. Similarly, instead of hosting
phishing sites on sketchy-looking URLs that can be detected with simple
Bayesian models (good vs bad URL detection), attackers now host their stuff on
Google Sites and on compromised web sites with high Alexa rankings. You can
use simple heuristics like "don't trust mail from a domain set up in the last
3 days" but that's problematic too, because attackers can simply bank domains.
(And, for that matter, real senders create new domains and send legitimate
mail from them.)

According to the FBI, email-based phishing attacks have cost companies over
$12B since 2013. If there's any silver lining to this scourge, it's that it
makes for a really interesting technical challenge for the white hats that
pretty much everyone understands the need for. (A completely different set of
techniques is required to block impersonations of people -- "spear phishing"
\-- but I'll leave that for another day.)

~~~
avn2109
When you find a phishing email, do you have a program that spams their
"docusign" login with vast quantities of plausible-looking but fake
credentials?

IMHO active countermeasures are always the best approach to stuff like this.
Attack, attack, attack.

Also I could imagine giving them special fake usernames, such that when they
try to login via that special fake username, it turns on extra metrology and
slowbanning/cpu intensive operations etc.

~~~
brightball
The 2nd option you mention, submitting honeypot credentials and then watching
for login attempts, is helpful with a comprehensive defense.

------
nykolasz
And no amount of phishing training will solve it - I don't think. People will
still click on links, they will click on buttons and do what they think it is
expected for them to do.

On the bright side, Google Safe Browsing is pretty good at catching new
untargetted phishing campaigns, so most people get a good level of protection
from that. I am also a big proponent of using a DNS firewall* layer to help
minimize the exposure to phishing domains.

*I blogged about it here, comparing a few free DNS resolvers, if anyone is interested:

[https://medium.com/@nykolas.z/phishing-protection-
comparing-...](https://medium.com/@nykolas.z/phishing-protection-comparing-
dns-security-filters-9d5a09849b91)

~~~
badrabbit
Training helps a _lot_ ,but they typically treat users like toddlers and
punish or reward them for getting it right. Training is also either too
targeted or too untargeted compared to IRL phish

~~~
marmot777
Treating users like toddlers is a techie attitude that drives me crazy. Most
people have their own profession and responsibilities to think about. We'd
appear to have toddler level sophistication to, say, an accountant,
electrician, or doctor, and we'd rightly expect to be treated like an adult
discussing things about which we know almost nothing.

What do you mean by too targeted or too untargeted? Either focused on a
specific threat (tree) or too general to be useful (all forest no trees)?

~~~
badrabbit
Too targeted would for example be something too relevant to their job. They'd
know what the typical emails and logins are so they won't fall for it easily.
If the training is for spearphishing, it should contain extensive detail about
the user. I mean really, you can't train someone who combats phishing as their
day job against spearphishing.

The only real threat training combats against is untargeted dragnet attacks
which typically use generic content or attacks that target organizions(not
individuals).

In other words,you want them to be trained for the technology threat not the
content threat. You want them know the difference between mail.company.com and
mail.company.com.seemslegit.site . Currently,training seems to focus on "email
looks suspiciois,why did you click on the link" not "what about the link made
you think it was legitimate? and this is why you were wrong."

Also,training is done as a campaign at most places.a few users fall for it and
suddenly everyone knows about it before opening their inbox. Mostly theatrics.
It shouldn't be "send phishme emails to a 1000 users today",it should be more
like "pick 50 users out of 1000 at random and send them a new campaign
everyday for the next 20 business days quarterly"

~~~
marmot777
This idea of targeted phishing drills sounds cool. And I’m guesssing at least
most users kind of dig the game?

------
badrabbit
There are 3 types of phishing emails:

1) information harvesting

2) malware delivery

3) trust abuse social engineering

For 1), don't use passwords other than to protect private keys,in-browser dlp
protection can help leakage of other PII. Alternatively,invest heavily in MFA.

For 2), there already strong mitigations like attachment whitelisting but my
idea is to allow email attachments to ne saved to,written to and read from an
execution restricted file path(even temp files. noexec on *nix and SRP on
windows). Of course app whitelisting is ideal solution which mitigates drive-
by download/web phish infections as well.

For 3), don't use email for communicating trust or authorization of change.
Plenty of other alternatives (mostly e2e messaging and call apps) but it is
more important to have an established protocol(e.g.: call back using listed
number X and confirm with another call to Y before changing banking info or
transfering money).

~~~
marmot777
How does attachment whitelisting work? That sounds promising.

~~~
badrabbit
That's typically done by mime type and extension. For example,outlook/exchange
won't let you send/receive windows executables as attachments at most
companies.

~~~
marmot777
I've never worked for a large company but it sounds like a sound policy across
the board for businesses and organizations large and small, and perhaps even
the major mailbox providers (e.g., gmail)?

------
erpellan
Dusting off my usual response: mutual TLS (aka client side certs) could
practically eliminate phishing. It would be simply impossible to give your
credentials to a phishing site as they never leave your device. There's 2
things missing that browser / device vendors need to do:

1\. Improve the UI of client certs. 2\. Figure out a way to manage credentials
across multiple devices.

~~~
dmbaggett
2FA would also help, but people don't want to mandate it. And even if you
require 2FA for your own employees, the third party "pay this invoice" request
may not be gated on 2FA -- because that's up to the third party to enforce 2FA
for (and they probably don't.)

Neither of these solutions helps with spear phishing emails, either. If you
get an email that says "please wire money" from a sender you think you trust,
the attacker's goal isn't credential harvesting, so protecting logins won't
help.

Similarly we're seeing people fall for scams where a "trusted person" asks
them to buy a bunch of iTunes gift cards and provide the codes on them in a
reply email. Yes, people actually comply with this request when they think the
requester is their CEO, etc.

~~~
kibwen
Does 2FA help? It might keep the account itself from being taken over entirely
(assuming that another 2FA step also guards the ability to change the
account's credentials), but a phishing site could transparently relay both
factors to the real site to grant it access for a single session, which is
enough time to do plenty of damage. And if the phishing email is of the form
"you need to change your password now", the site could easily trick a user
into handing over the additional second factor that guards the primary
credentials.

~~~
dmbaggett
Yes, you're absolutely right: 2FA makes things harder for the attacker but
doesn't really solve the problem. But in practice, at least circa 2018, most
phishing sites are very primitive. Attackers do OK victimizing people without
2FA, so they don't generally do what you describe ("transparently relay both
factors").

------
bks
If you are looking for a straightforward way to protect users from phishing,
consider rewriting the URLS in their messages and check their clicks in real
time against databases of phishing feeds.

You can check against - Google Safe Browser, Phishtank and other free phishing
feeds if you don't have the money for real-time databases or proactive site
scrapers.

This is one of the ways that we protect the end user from Phishing at
[https://www.phishprotection.com](https://www.phishprotection.com) \- part of
the magic is to do a bunch of sanitization before accepting the message
including strict SPF, DKIM, DMARC validation / virus protection at the edge /
and watching the registration of SSL certificates for commonly exploited
domains [https://blog.0day.rocks/catching-phishing-using-
certstream-9...](https://blog.0day.rocks/catching-phishing-using-
certstream-97177f0d499a)

If anyone is interested we rewrite URLs to match your domain name - something
like linkcheck.yourdomain.com (protected by LetsEncrypt) and if you ever
decide to leave you can export out the re-written URLs and redirect your
domain to your own servers.

If you'd like to give it a try, feel free to let me know.

~~~
dmbaggett
Like phishing awareness training, this is a good practice. We actually offer
URL rewriting to our customers, but there are some UX downsides to it so not
everyone wants it.

One big issue with GSB, Phishtank, OpenPhish, etc. as "the solution" is that,
again, it's trivial for attackers to thwart these threat feeds. Using the same
approach spammers have been implementing for 20 years now, the attacker just
needs to randomize the URL in each sent email. Then when you report the
phishing link in your copy, it helps no one else.

One could imagine a system that reverses the patterns used by the URL
generation scripts -- we actually do this for DGAs ("domain generation
algorithms") -- but even trying to be clever like this just puts you back in
an arms race with the attackers.

So I don't think URL "whack-a-mole" is the right answer either. I believe you
need the software to straight-up identify fraudulent emails from first
principles. (Not saying it's easy.)

~~~
marmot777
Yes, spammers learned to switch IP addresses very quickly. The email filters
became more sophisticated ways of identifying your spam from a different IP
addresss and even from a different domain name. Spammers could run but not
hide.

I think I see a LOT less spam that actually gets to my inbox than in years
past. Hats off to those who worked hard on making an incredible amount of
progress on hard provlems, and continue to plow ahead.

------
k_vi
I use localbitcoins.com and recently was fooled into giving away credentials
even with 2fa enabled. Their ingenious method almost got me.

 _New message from LocalBitcoins support ticket #570241.

\---

Your most recent attempt to access your private support ticket was rejected
due to: INVALID AND/OR EXPIRED CREDENTIALS.

Please try again, you have (2) attempts remaining.

\---

This account has been flagged as high-risk after receiving a support ticket
submitted by another user regarding the following ad:

ONLINE_SELL #2322 - Bank Transfer Please review and reply to this ticket as
soon as possible to help us further investigate this matter. Failure to access
this ticket may result in the suspension and/or revocation of your account
until contact is made.

\---

Best regards,

LocalBitcoins

\---

To access this ticket, visit:

[https://localbitcoins.help/support/reply/570241/](https://localbitcoins.help/support/reply/570241/)
For security and privacy reasons this ticket may not be accessible without
proper authentication due to the sensitive information involved._

------
throwawaylalala
The solution is simple technically but complicated socially.

Simply, never send a customer a link for them to click. Instead, tell them to
go to your site and to log in; then ensure anything important is easily found.

~~~
alexhutcheson
This would work if everyone did it, but one website doing it in isolation
seems unlikely to have much impact. Even if you have a very clearly spelled
out "We will never send links" policy, your customers interact with dozens of
websites and are unlikely to specifically remember your policy when they read
the email.

~~~
throwawaylalala
Which is why it's easy technically, hard socially.

------
00N8
'Con' comes from the phrase 'confidence scheme'. Phishing is simply the most
up to date version of the confidence scheme, using modern communication tech
to achieve the same end - subverting the mark's context & communication
expectations so they'll unwittingly give up secrets or money

------
qrbLPHiKpiux
It’s because it doesn’t rely on tech. It only needs an unwilling, naive
participant. Humans are the weakest link, and phishing just exploits this.

~~~
marmot777
Yes, even a normally alert, somewhat savvy human's not on the ball all the
time. People get tired, careless, mindless, drunk, you name it. We are flawed.

------
marmot777
How helpful do you think full implementation of email authentication: SPF,
DKIM, and DKMARC (p=reject)?

I know it does not help against close mispellings, but it at least prevents
spoofing the actual domain name. Is email authentication an important part of
mitigating phishing?

------
carapace
We're just too damn lazy to use encryption and authentication. It's that
simple, and that brutal.

