Melanie Rieback - The Good, the Bad, and the Ugly Radically Open Security Holland Strikes Back 2016 www.hollandstrikesback.nl

1. Dr. Melanie Rieback, John Sinteur, Niko Schmidt,
Marcus Bointon, Boi Sletterink, Frouke van Ommeren,
Rob Wiegertjes, & Peter Mosmans
Oct 4, 2016 melanie@radical.sexy
Adventures in
Spearphishing: the Good,
the Bad, and the Ugly

2. Oct 4, 2016
Introduction
● A customer asked us to
conduct their spearphish
test for 2016.
● Objectives:
– Spearphish the entire
organization (~150
people)
● “Low and slow” phishing
attack

3. Oct 4, 2016
Setting the Stage
● We registered an
innocuous sounding
domain:
clickanalytics.amsterdam
● Malware is out of scope.
Click tracking only.
● We setup a landing page
that says 'insert malicious
code here', and then
redirects the victim to what
he expects to see.

4. Oct 4, 2016
Our first experiment...
● We started our targeting
slowly and patiently...
● We know via-via that our
PoC likes running
● So let's send him a
RUNNING newsletter!

5. Oct 4, 2016
We shoot...
● We grabbed a Dutch
running newsletter, and
instrumented the URLs to
direct to our landing page.
● It took us a day to put
together a good looking
pretext
● Excited and hopeful, we
sent off the email...

6. Oct 4, 2016
We miss.
● We waited...
● And waited...
● He didn't click.
● Hmmmm.. maybe this is
going to be harder than
we thought.
● Especially if we need to
sent 'targeted' emails to
~150 people

7. Oct 4, 2016
Okay. Time for Plan B.
● The realization slowly
dawns on us that it will be
impossible to individually
target 150 people within
time and budget.
● So we need to take a
broader approach.
● Automation is going to be
needed...

8. Oct 4, 2016
Coming up with a new idea..
● How about using spam as a
phishing vector?
● People are used to receiving
it. (Also at work).
● Spam causes annoyance
rather than suspicion
● It's easy to harvest, rip
instrument, and send in an
automated fashion (crucial
for targeting 150 people).

9. Oct 4, 2016
Targeted vs. Generic
●
Less targeted "spam" (i.e. fake
LinkedIn invites, obviously
commercial advertisements,
etc..) is, ironically enough, far
more effective in getting clicks
●
It is also far less risky (in terms
of getting caught) than phishing
emails that are more targeted to
their audience

10. Oct 4, 2016
Example: Phishing “Spam”

11. Oct 4, 2016
Example: Targeted Phishing

12. Oct 4, 2016
Our Spearphishing Toolkit

13. Oct 4, 2016
This gave us some knobs to turn
●
We could adjust the
batch sizes and the
degree of "targeting"
(tailoring the pretext
towards the organization)
●
This gave us some
surprising results....

14. Oct 4, 2016
The Most Clicked Pretext
Yes, seriously..

15. Oct 4, 2016
Detailed Breakdown
●
Total target addresses: 145
●
Total mailings: 14
●
Total messages: 528
●
Total opened: 261
●
Total clicks: 46
●
Unique click IP addresses: 29
●
Most clicked pretext was
LinkedIn: 8

16. Oct 4, 2016
Arch Nemesis: The Spamfilter
●
Our largest hindrance with the
"spam-based" phishing approach
was the spam filter.
●
We started researching SPF
values, to get through the spam
filter.
●
We found that the optimum batch
size of "phishing spam" seems to
be: batches large enough to hit *as
many targets as possible*, without
getting marked by the spam filter.

17. Oct 4, 2016
The gig is up!
●
As we got closer to the
deadline, we got increasingly
aggressive with our targeting
and batch sizes.
●
In short.. we wanted to know
how much we could “push it”
before we got caught.
●
A Bridge Too Far: fake Mozilla
security update to the CSIRT
●
6 clicks (presumably from a
sandboxed environment) ;-)

18. Oct 4, 2016
The Excrement Hits the Fan
●
Things really exploded when
our SETUP pretext escaped the
customer environment
●
Some staff members posted
angry tweets about SETUP for
“spamming” them
●
SETUP thought they had a data
breach, and launched a full
investigation
●
Angry folks. Damage control.

19. Oct 4, 2016
Ethical Issues in Spearphishing
●
This leads to some interesting
ethical issues, actually..
●
It's industry standard to use 3rd
parties as pretexts for phishing
tests. But is that okay?
●
If not, how can we do that
properly?
●
Can we put together a pool of
organizations that give
permission for this?

20. Oct 4, 2016
Technical Lessons Learned
●
Check SPF and DKIM on
inbound email
●
Disable default image loading in
email clients
●
Flag newly registered domains
as suspicious
●
Security awareness training
●
Monitor network traffic (useful
for incident response later)

21. Oct 4, 2016 melanie@radical.sexy
Questions?