Re: FYI: Another round of spear Phishing

[Curt Wilson <curtw () SIU EDU>]

My $.02 is that a significant awareness campaign needs to be put forth
to educate users as much as possible, and then supplement with some type
of testing of the control. Despite awareness raising attempts, it's
likely that some users will fall for it anyway (as many .edu's have
seen). Spoofing the attackers and asking for username and passwords in
email is an outright bad idea - plain text transmission, storage of
plaintext password in outbox, destination mail server and & eventual
recipient host (page file, browser cache, mail client, etc). Way too
many leak points to be an effective strategy (it reduces security), let
alone the ethical implications. That being said, there may still be room
for some assessment & testing to help raise awareness.

We as a community are familiar with using various tools such as Nessus
and other tools (Core, metasploit, webapp inspection tools, brain, etc)
to perform authorized vulnerability assessments and penetration testing
where appropriate, but the ethical and organizational considerations of
IT/security staff preying upon the users perception vulnerabilities (aka
"social engineering") may create a scenario where the attackers (who
have no such scruples) may have an advantage if we can't find effective
prevention countermeasures. I once heard someone say that the attackers
should not be the first ones to test your defenses. I agree with this
philosophy, and while system development and design should always
include security from inception, we all know this doesn't always happen.
How can we apply thIS principle here in the current wave of attacks, and
for attacks that haven't yet been invented? The number of attack vectors
is staggering. There are proponents and opponents of penetration
testing, but as long as universities with their unique culture offer a
soft underbelly to the attackers we have work to do. Finding helpful
ways to supplement awareness training with testing and assessment for
user perception vulnerabilities should be considered, imho, and the
topic should be explored further.

One practical approach that I'm sure many of you already do is reject
the bogus "reply-to" email addresses at the mail server(s). This assumes
you know all of the "reply-to" email addresses. This at least stops the
message from being sent, but it doesn't directly educate the user. Not
to mention this is not effective when someone is using gmail or other
off-campus webmail that you don't control. IPS rules could also be
useful, but less practical in the event of SSL/TLS webmail.

Targeted education for those people who fall for the real attacks is a
good idea and I'll bet they won't fall for a similar trick again (fool
me once...) But this depends upon security staff being aware of all the
attackers "reply to" addresses, which is easy when you have many
messages from the same sources but what about a highly targeted spear
phish? In that case, you'd better hope that the user is fully patched
and aware.

How can we best be proactive against these types of attacks instead of
just reacting?

Bob Bayn wrote:
> Dean Halter wrote:
> > I certainly agree that no one wants to look the fool.  It's just that the
> > folks that are going to fall for the test would probably also fall for a
> > scam.  I am curious to hear what others think of using "deception" to
> > educate.
>
> My educational experience is replete with "trick questions" on
> exams I took.  The ones that tricked me are the ones I remember
> best.
>
> I am beginning the discussions here about constructing a phake
> phish as an awareness device.  We'll see who we get on board with
> the idea and how we might deploy it.  I'm thinking of a limited
> phish spam at some of our employees, and a little followup in
> the student paper (which will probably get picked up by the news-
> starved local paper) and then maybe a followup phish spam to some
> students in the fall, with more publicity followup.
>
> One question is which kind of "phish" to use as a model: 1) the
> one that asks for an email password by return email or 2) one
> that directs the user to a look-alike website at a clearly bogus
> URL.  We've been getting a LOT of the email reply variety lately.
>
> --
> Bob Bayn  ride-a-bike (435)797-2396
> Network Security Team coordinator
> Office of Information Techology
> Utah State University


--
Curt Wilson
SIUC IT Security Officer & Security Engineer