You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ram <ra...@netcore.co.in> on 2016/06/27 13:11:04 UTC
Catching well directed spear phishing messages
I am seeing messages that appear to come from the MD or the CEO of the
company to the accounts department asking people to transfer money to
some fake account
These messages were initially few and I ignored. But now this has become
a problem.
I know these are not spam messages so catching them will be out of scope
for a spam filter.
These messages have different envelope ids so SPF checks always pass.
The header from is properly formatted exactly how it will be in a normal
mail
What measures do you take for such spear phishing
Thanks
Ram
Re: Catching well directed spear phishing messages
Posted by Alex <my...@gmail.com>.
Hi,
>>> These messages have different envelope ids so SPF checks always pass.
>>> The header from is properly formatted exactly how it will be in a normal
>>> mail
>>>
>>> What measures do you take for such spear phishing
- look for little anomalies that are unique to these messages and
something your CEO would not do (webmail? user-agent?)
- implement DKIM if possible to sign messages actually sent by your CEO
- compare your sample against an actual message from the CEO and
identify the differences
- create body rules to look for signs of "ACH" and other "bank
transfer" conversations
Build meta's combining all these factors together.
Also, if it wasn't then, the "originating IP" is now blacklisted.
Re: Catching well directed spear phishing messages
Posted by Sidney Markowitz <si...@sidney.com>.
Ram wrote on 28/06/16 3:10 AM:
>
> Here is the sample
>
>
> I just redacted the actual recpient email id and name
>
>
> Return-Path: <c-...@cognitorex.com>
This isn't a SpamAssassin problem, but it is a problem that you can use
SpamAssassin as a tool to help solve.
If your company's accounting department can send an arbitrary payment to an
arbitrary bank account based on only an email from the CEO or Managing
Director with no accompanying paperwork or reference to internal accounting
documents, then your company has worse security problems than SpamAssassin can
fix. Your company's procedures should at least require a written form be
filled out with two signatures and a checklist that contains a step that
includes verifying that the request is valid.
I suggest that you set up your company email and set up the mail clients that
company employees use to send company email so that all mail sent from the
company domain is sent through a proper mail server for that domain. There is
no excuse for that Return-Path to be valid for an email that has a From
address with your company domain. Yes, your CEO may want to be able to send
company mail from his phone. Your IT people can set up email on his phone so
it is configured to use authenticated access to a specific mail server. You
can then have local rules in SpamAssassin so that any mail that says it is
from the company domain that does not have the right headers is blocked.
It is a convenience that if you have example.com domain you can put From:
me@example.com in an email that you send any way you want. That particular
convenience is not necessary in a business. It is reasonable to require that
official company email be sent using a mail client that has properly been set
up by the company IT department or properly set up according to their
guidelines. If you do that then SpamAssassin is a great tool for blocking any
spoofed emails that pretend to be from your company domain.
Sidney
Re: Catching well directed spear phishing messages
Posted by John Hardin <jh...@impsec.org>.
On Mon, 27 Jun 2016, Reindl Harald wrote:
>> > Am 27.06.2016 um 15:11 schrieb Ram:
>> > > I am seeing messages that appear to come from the MD or the CEO of the
>> > > company to the accounts department asking people to transfer money to
>> > > some fake account
>> >
>> > > These messages have different envelope ids so SPF checks always
>> > > pass. The header from is properly formatted exactly how it will be
>> > > in a normal mail
>> > >
>> > > What measures do you take for such spear phishing
>> >
>> > without a sample or a crystal ball hard to say
>>
>> Here is the sample
> 1.5 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s)
This, too.
A meta on "(x-sender not in our domain OR reply-to not in our domain) AND
FILL_THIS_FORM_FRAUD_PHISH" is what I'd recommend as a local rule.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The yardstick you should use when considering whether to support a
given piece of legislation is "what if my worst enemy is chosen to
administer this law?"
-----------------------------------------------------------------------
7 days until the 240th anniversary of the Declaration of Independence
Re: Catching well directed spear phishing messages
Posted by Reindl Harald <h....@thelounge.net>.
Am 27.06.2016 um 17:10 schrieb Ram:
> On Monday 27 June 2016 06:50 PM, Reindl Harald wrote:
>>
>>
>> Am 27.06.2016 um 15:11 schrieb Ram:
>>> I am seeing messages that appear to come from the MD or the CEO of the
>>> company to the accounts department asking people to transfer money to
>>> some fake account
>>
>> happens all day long
>>
>>> I know these are not spam messages so catching them will be out of scope
>>> for a spam filter.
>>
>> "appear to come from" is by definition a spam message and most of that
>> crap *in fact* is trainable and catchable with a combination of
>> clamav-signatures (sanesecurity) and bayes
>>
>>> These messages have different envelope ids so SPF checks always pass.
>>> The header from is properly formatted exactly how it will be in a normal
>>> mail
>>>
>>> What measures do you take for such spear phishing
>>
>> without a sample or a crystal ball hard to say
>
> Here is the sample
>
>
> I just redacted the actual recpient email id and name
looks by far not untrainable, see second sa-report after learn it to
bayes - and if you think you can't train such messages you did not
realize how bayes works
and FREEMAIL_FORGED_REPLYTO is a big indicator
i don't get what you want to tell us with "I know these are not spam
messages" when *it is* spam
________________________________
Content analysis details: (7.5 points, 5.5 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.0 TVD_RCVD_SPACE_BRACKET No description available.
0.1 HK_RANDOM_FROM From username looks random
-0.1 CUST_DNSWL_5_ORG_NT RBL: list.dnswl.org (No Trust)
[173.201.193.64 listed in list.dnswl.org]
-0.1 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[173.201.193.64 listed in wl.mailspike.net]
0.0 HTML_MESSAGE BODY: HTML included in message
1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
-0.1 CUST_DNSWL_2_SENDERSC_LOW RBL: score.senderscore.com (Low Trust)
[173.201.193.64 listed in
score.senderscore.com]
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
1.2 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
3.0 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information
1.5 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s)
________________________________
Content analysis details: (13.9 points, 5.5 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-0.1 CUST_DNSWL_5_ORG_NT RBL: list.dnswl.org (No Trust)
[173.201.193.64 listed in list.dnswl.org]
7.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
[score: 1.0000]
0.0 TVD_RCVD_SPACE_BRACKET No description available.
0.1 HK_RANDOM_FROM From username looks random
-0.1 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[173.201.193.64 listed in wl.mailspike.net]
-0.1 CUST_DNSWL_2_SENDERSC_LOW RBL: score.senderscore.com (Low Trust)
[173.201.193.64 listed in
score.senderscore.com]
0.0 HTML_MESSAGE BODY: HTML included in message
0.4 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
[score: 1.0000]
0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
1.2 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
3.0 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information
1.5 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s)
Re: Catching well directed spear phishing messages
Posted by Ram <ra...@netcore.co.in>.
On Monday 27 June 2016 06:50 PM, Reindl Harald wrote:
>
>
> Am 27.06.2016 um 15:11 schrieb Ram:
>> I am seeing messages that appear to come from the MD or the CEO of the
>> company to the accounts department asking people to transfer money to
>> some fake account
>
> happens all day long
>
>> I know these are not spam messages so catching them will be out of scope
>> for a spam filter.
>
> "appear to come from" is by definition a spam message and most of that
> crap *in fact* is trainable and catchable with a combination of
> clamav-signatures (sanesecurity) and bayes
>
>> These messages have different envelope ids so SPF checks always pass.
>> The header from is properly formatted exactly how it will be in a normal
>> mail
>>
>> What measures do you take for such spear phishing
>
> without a sample or a crystal ball hard to say
>
Here is the sample
I just redacted the actual recpient email id and name
Return-Path: <c-...@cognitorex.com>
Received: from ho.targeteddomain.com ([unix socket])
by ho.targeteddomain.com with LMTPA;
Thu, 23 Jun 2016 15:12:30 +0530
X-Sieve: CMU Sieve 2.4
X-Envelope-From: <c-...@cognitorex.com>
Received: from p3plwbeout16-06.prod.phx3.secureserver.net
(p3plsmtp16-06-2.prod.phx3.secureserver.net [173.201.193.64])
by mta3p4r.targeteddomain.com (Postfix) with ESMTP id CCF881284F
for <vi...@targeteddomain.com>; Thu, 23 Jun 2016 15:11:43
+0530 (IST)
Received: from localhost ([173.201.193.27])
by p3plwbeout16-06.prod.phx3.secureserver.net with bizsmtp
id A9hj1t0010bvwv9019hjyn; Thu, 23 Jun 2016 02:41:43 -0700
X-SID: A9hj1t0010bvwv901
Received: (qmail 7400 invoked by uid 99); 23 Jun 2016 09:41:43 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
X-Originating-IP: 41.144.23.225
User-Agent: Workspace Webmail 6.3.7
Message-Id:
<20...@email16.godaddy.com>
From: "YYYYYY Jain" <YY...@targeteddomain.com>
X-Sender: c-level@cognitorex.com
Reply-To: "YYYYYY Jain" <ex...@execs.com>
To: YYYYYYY@targeteddomain.com
Subject: RE: SV/PI- Ref - 909020AX
Date: Thu, 23 Jun 2016 02:41:42 -0700
Mime-Version: 1.0
X-NetcoreISpam11-ECMScanner-Information: Please contact Netcore Support
for more information
X-NetcoreISpam11-MailScanner-ID: E7ADE5F.A055E
X-NetcoreISpam11-ECMScanner: Found to be clean
X-NetcoreISpam11-ECMScanner-SpamCheck: not spam,
CTSCORE : 0
str=0001.0A160205.576BAEE5.013C:SCFMA16949757, ss=1,
re=-1.900, recu=0.000, reip=0.000, cl=1, cld=1,
fgs=0,
SpamAssassin (not cached, score=0.701, required 5,
autolearn=disabled, ECM_HDR_MISMATCH1 0.10,
ECM_PHISH 0.50,
HTML_MESSAGE 0.00, MIME_HTML_ONLY 0.10)
X-NetcoreISpam11-ECMScanner-From: c-level@cognitorex.com
X-MailServ-MailFilter-MailScanner-Information: Please contact the ISP
for more information
X-MailServ-MailFilter-MailScanner-ID: EF7C66C466.AB237
X-MailServ-MailFilter-MailScanner: Found to be clean
X-MailScanner-From: c-level@cognitorex.com
YYYY - Process Rtgs Tf to this below account -
BANK NAME : UNJAB NATIONAL BANK
BENEFICIARY NAME : KARAN SHYAM SINGH
ACCOUNT NO : 0386006900002824
IFSC CODE : UNB0038600
BRANCH : CAMP
PAN NO: GAHPS7812F
AMOUNT - 3.1 Lacs
I will provide the Invoice later in the day as i am busy now, and please
make sure they receive in their account before 3pm
Thanks,
YYYYYY
Re: Catching well directed spear phishing messages
Posted by Reindl Harald <h....@thelounge.net>.
Am 27.06.2016 um 15:11 schrieb Ram:
> I am seeing messages that appear to come from the MD or the CEO of the
> company to the accounts department asking people to transfer money to
> some fake account
happens all day long
> I know these are not spam messages so catching them will be out of scope
> for a spam filter.
"appear to come from" is by definition a spam message and most of that
crap *in fact* is trainable and catchable with a combination of
clamav-signatures (sanesecurity) and bayes
> These messages have different envelope ids so SPF checks always pass.
> The header from is properly formatted exactly how it will be in a normal
> mail
>
> What measures do you take for such spear phishing
without a sample or a crystal ball hard to say
Re: Catching well directed spear phishing messages
Posted by Jari Fredriksson <ja...@bitwell.biz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ram kirjoitti 27.6.2016 16:11:
> I am seeing messages that appear to come from the MD or the CEO of the
> company to the accounts department asking people to transfer money to
> some fake account
>
> These messages were initially few and I ignored. But now this has
> become a problem.
> I know these are not spam messages so catching them will be out of
> scope for a spam filter.
>
> These messages have different envelope ids so SPF checks always pass.
> The header from is properly formatted exactly how it will be in a normal mail
>
> What measures do you take for such spear phishing
>
> Thanks
> Ram
DKIM & DMARC does not help?
- --
Jari Fredriksson
Bitwell Oy
+358 400 779 440
jarif@bitwell.biz
https://www.bitwell.biz - cost effective hosting and security for
ecommerce
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAldxcT0ACgkQKL4IzOyjSrYxHwCgra5F0dHG2ZC/JjQn5Ld6wQN3
iAEAoJ+ITumf2eNmxmLJpNh44RNVPJwC
=6v3y
-----END PGP SIGNATURE-----
Re: Catching well directed spear phishing messages
Posted by Reindl Harald <h....@thelounge.net>.
Am 28.06.2016 um 15:30 schrieb Sidney Markowitz:
> You are right that social engineering can't be stopped by technology. The
> company should have procedures in place that provide the flexibility that CEO
> seems to need but will still prevent the fraud even in the face of successful
> social engineering. But there is no reason the mail setup has to allow spoofed
> headers From the company domain
if things only would be that easy
____________________________
blacklist_from *@your-bank.tld
whitelist_auth *@your-bank.tld
in theory that would stop any forgery, in real life i had to revert this
after a big payment service using proper SPF then sent their newsletters
with a external service, envelope of the external service but From
header matching the blacklist_from preventing hit whitelist_auth
____________________________
in fact to make such things working without breaking mailing-lists and
what not else one would be required to use a dedicated subdomain for
business-email which never is used outside the own network and *then*
you can easily block any message with envelope or from-header touching
your MX
but that would also require that the users understand "THIS address MUST
NOT be used for anything then submission mail and use THIS email adress
for mailing-lists and other things"
one can now come with "DKIM exists" - then look how often the DKIM check
failed in the past up to become T_DKIM_INVALID as a testing rule because
of too much false positives
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6462
Re: Catching well directed spear phishing messages
Posted by Alex <my...@gmail.com>.
Hi,
>> It's easy to write a CUSTOM set of rules just for actual/likely
>> targeted senders (CEO/etc).
>> For each person/target, create a rule that tests an explicit
>> list of that person's normal Realname(s) (including reasonable
>> variations), against the Realname part of the From header, and
>> if there's a match, test whether the From Address is in a list
>> of allowed addresses. Score only if it's a probable phish
>> Realname from an unknown/unallowed address.
>
> I've also been battling this for a long time. Those unknown/unallowed
> addresses are basically the list of permissible domains, I would
> think, correct?
Oops, I meant the inverse of a list of permissible domains, correct?
As in !MY_AUTH_ADDR.
I'm really more interested in ideas on how to handle From:addr
spoofing and whether they should just be outright blocked if not on my
own SPF list.
Thanks,
Alex
Re: Catching well directed spear phishing messages
Posted by Alex <my...@gmail.com>.
Hi,
On Wed, Jun 29, 2016 at 12:58 AM, Chip M. <sa...@iowahoneypot.com> wrote:
> On Tue, 28 Jun 2016 14:13:57 +0000 David Jones wrote:
>>If I search the Internet for the CEO/CIO/CTO/etc of a company
>>and send and email from my domain but make the displayed name
>>in the visible From: be that CEO/CIO/CTO/etc's full name that
>>the recipient is used to seeing in the mail client, then I have
>>spoofed nothing detectable in advance by SA or any mail filter
>>technology.
>
> Excellent summary!
> The key is that the number of spoofed people is extremely SMALL,
> and we _CAN_ anticipate who they are.
>
> It's easy to write a CUSTOM set of rules just for actual/likely
> targeted senders (CEO/etc).
> For each person/target, create a rule that tests an explicit
> list of that person's normal Realname(s) (including reasonable
> variations), against the Realname part of the From header, and
> if there's a match, test whether the From Address is in a list
> of allowed addresses. Score only if it's a probable phish
> Realname from an unknown/unallowed address.
I've also been battling this for a long time. Those unknown/unallowed
addresses are basically the list of permissible domains, I would
think, correct?
How about the case where the From: is spoofed (both real name and
email) to be a CXO and SPF passes for another domain? Do you rely on
DKIM/DMARC, or do you have rules that block those? I would then think
you'd also need rules that exclude the cases where SPF passes for your
own domain.
> I have not yet noticed any fuzzing "in the wild", however all of
> my targets have extremely "anglo" names. I recommend looking at
> tools that create fuzzy variations.
Does such a tool exist for domains? Perhaps you have some example tools?
Thanks,
Alex
Re: Catching well directed spear phishing messages
Posted by Sidney Markowitz <si...@sidney.com>.
David Jones wrote on 29/06/16 2:13 AM:
>> From: RW <rw...@googlemail.com>
>> That wont work in this example because nothing has actually been
>> spoofed.
>
> Exactly. If I search the Internet for the CEO/CIO/CTO/etc of a company
> and send and email from my domain but make the displayed name in
> the visible From: be that CEO/CIO/CTO/etc's full name
Oh, that's right. I misunderstood the situation described in the initial post
in this thread. SpamAssassin is not the right tool for a spear fishing attack
that is a perfectly innocent email that claims nothing wrong from a technical
perspective might have no spam signals and relies on the recipient being
technically naive and not looking behind the displayed From name.
As Dianne Skoll pointed out the proper defense against this type of attack is
to have proper financial processes in place. That can include technical
measures that would require the CEO to have entered the request in a secure
web form instead of by email. But even that is subject to social engineering
as ultimately somebody with authority can receive a spear phishing email
apparently from someone who can ask them to use that authority. The right
thing to do is to actually put in place the measures that people have spent
time working out over the years as "proper financial processes" to help
prevent not only social engineering hacks but internal fraud and simple
mistakes. Bottom line is that the CEO should not be able to initiate a bank
transfer with even a legitimate phone call to accounting and a promise to send
the details "later".
Sidney
Re: Catching well directed spear phishing messages
Posted by David Jones <dj...@ena.com>.
>Am I missing something here:
Respectfully, you are.
>An email comes in from the CEO of the business - seemingly from the company, and has a Spam score of 7.5
I am talking about legit emails from trusted senders that won't
hit FREEMAIL_FORGED, RBLs, DBLs or any high scoring rules so
they are below the SA block threshold. This would be common
from compromised accounts that the bad guy can use in a stealth
manner by deleting the message in the Sent folder and quickly
remove the inbound email from the reply. The average user would
never notice their account is being used by a second person.
>Content analysis details: (7.5 points, 5.5 required)
>pts rule name description
>---- ---------------------- --------------------------------------------------
> 0.0 TVD_RCVD_SPACE_BRACKET No description available.
> 0.1 HK_RANDOM_FROM From username looks random
>-0.1 CUST_DNSWL_5_ORG_NT RBL: list.dnswl.org (No Trust)
> [173.201.193.64 listed in list.dnswl.org]
>-0.1 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
> [173.201.193.64 listed in wl.mailspike.net]
> 0.0 HTML_MESSAGE BODY: HTML included in message
> 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60%
> [score: 0.5000]
> 0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
> 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
>-0.1 CUST_DNSWL_2_SENDERSC_LOW RBL: score.senderscore.com (Low Trust)
> [173.201.193.64 listed in score.senderscore.com]
>-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
> 1.2 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
> 3.0 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
> 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information
> 1.5 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s)
>________________________________
>Content analysis details: (13.9 points, 5.5 required)
>How many INTERNAL EMAILS will have a score of 7.5??? Or even 3? Or 1?
You are correct. Internal emails (i.e. within Office 365 that don't get scanned)
would not be scored but this scenario I am talking about is from the outside
but the recipient would not notice. The average user only looks at the visible
"Display Name <ba...@somedomain.com>" and never looks closely at the
actual email address inside the < >.
>In fact, if it came in through the INTERNAL_NETWORK ip range then it wouldnt even be scanned (seen as trusted). So any email coming "from the CEO" that has a SPAM score is definitely dodgy!
It only takes a couple of external emails to get to the right person to get
thousands of dollars wired to you account to make this worth it. Some may
get blocked by Reindl Harald's super duper trained Bayesian or meta rules
that he has put thousands of hours into creating with complex scripts that
the rest of us don't have time to setup since mail filtering is only part of our
job and we have a life outside of work.
>How hard can it be to say "if FROM = 'a company address' and a SPAM SCORE EXISTS then treat with rubber gloves.
>So ensure all company emails are pupt through the company email servers and set the INTERNAL_NETWORK parameters.
>Whats wrong with this?
Compromised accounts and other trusted senders can get through good SA setups.
Bottom line, If the accounting department doesn't have proper procedures
then they can be easily tricked into wiring money to bad guys.
If they can get one person a day to wire thousands of US dollars to them,
then that's a pretty nice income with very little effort once they have
control of a compromised account. They don't have to blast out tons of
spam like traditionally seen which gets them listed on RBLs and DBLs.
Re: Catching well directed spear phishing messages
Posted by Joe Quinn <jq...@pccc.com>.
On 6/29/2016 11:12 AM, Dianne Skoll wrote:
> On Wed, 29 Jun 2016 15:04:04 +0000
> David Jones <dj...@ena.com> wrote:
>> If everyone (really Microsoft) had some sense, they will start
>> showing the full display name with the email address to help users
>> see the incorrect domain and possibly help users notice the wrong
>> address. It's only going to get worse.
> Yep.
Especially after going through all the bother of extending SPF to test
against that information to begin with.
Re: Catching well directed spear phishing messages
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Wed, 29 Jun 2016 15:04:04 +0000
David Jones <dj...@ena.com> wrote:
> Mainly Microsoft Outlook and Exchange webmail? Most webmail
> interfaces will show the full From: display name with email address.
Oh sure, if you open the message, you'll see it. I meant to qualify
my post by saying most MUAs don't show the address in the message list
view... just the name And in my experience, most people pay no
attention at all to the headers once they open an email.
> If everyone (really Microsoft) had some sense, they will start
> showing the full display name with the email address to help users
> see the incorrect domain and possibly help users notice the wrong
> address. It's only going to get worse.
Yep.
Regards,
Dianne.
Re: Catching well directed spear phishing messages
Posted by John Hardin <jh...@impsec.org>.
On Wed, 29 Jun 2016, David Jones wrote:
>> Almost all MUAs I've ever used hide the From: address in favour of
>> the full name if it is present. And most of them have no option for
>> revealing the address, either.
>
> Mainly Microsoft Outlook and Exchange webmail? Most webmail
> interfaces will show the full From: display name with email address.
>
> Many years ago when I had to use Outlook, I had to put my email address
> in my signature because Outlook would only put "David Jones" in the
> reply text. If and email was forwarded later, that recipient wouldn't be
> able to reply back to me since djones@ena.com was no where in the email
> thread. Pretty dumb if you ask me.
Gotta keep from scaring the users with all that complex technical computer
language stuff...
{rolleyes}
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
One difference between a liberal and a pickpocket is that
if you demand your money back from a pickpocket
he will not question your motives. -- William Rusher
-----------------------------------------------------------------------
5 days until the Juno probe arrives at Jupiter
Re: Catching well directed spear phishing messages
Posted by David Jones <dj...@ena.com>.
>From: Dianne Skoll <df...@roaringpenguin.com>
>Sent: Wednesday, June 29, 2016 9:50 AM
>To: users@spamassassin.apache.org
>Subject: Re: Catching well directed spear phishing messages
>On Wed, 29 Jun 2016 10:31:47 -0400
>"Bill Cole" <sa...@billmail.scconsult.com> wrote:
>> On 28 Jun 2016, at 10:31, Jari Fredriksson wrote:
>> > Sure, but the case now is that the FROM != 'company adress' as this
>> > info is not even show to the user. What is shown is the CEO Name
>> > only. I could't even find a setting for this behaviour in my MUA!
>> That's a broken-by-design MUA.
>Almost all MUAs I've ever used hide the From: address in favour of
>the full name if it is present. And most of them have no option for
>revealing the address, either.
Mainly Microsoft Outlook and Exchange webmail? Most webmail
interfaces will show the full From: display name with email address.
>My alter ego complained about this back in 2012 on the DMARC list, but
>was given a lot of pushback... which makes DMARC essentially useless for
>preventing spoofing. Great. Another half-assed protocol that doesn't
>solve the problem it's supposed to solve.
Wouldn't DMARC still protect the From: header domain even though the
MUA doesn't display it?
If everyone (really Microsoft) had some sense, they will start showing the
full display name with the email address to help users see the incorrect
domain and possibly help users notice the wrong address. It's only going
to get worse.
Many years ago when I had to use Outlook, I had to put my email address
in my signature because Outlook would only put "David Jones" in the
reply text. If and email was forwarded later, that recipient wouldn't be
able to reply back to me since djones@ena.com was no where in the email
thread. Pretty dumb if you ask me.
>http://lists.dmarc.org/pipermail/dmarc-discuss/2012-February/000189.html
>Regards,
>Dianne.
Re: Catching well directed spear phishing messages
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Wed, 29 Jun 2016 10:31:47 -0400
"Bill Cole" <sa...@billmail.scconsult.com> wrote:
> On 28 Jun 2016, at 10:31, Jari Fredriksson wrote:
> > Sure, but the case now is that the FROM != 'company adress' as this
> > info is not even show to the user. What is shown is the CEO Name
> > only. I could't even find a setting for this behaviour in my MUA!
> That's a broken-by-design MUA.
Almost all MUAs I've ever used hide the From: address in favour of
the full name if it is present. And most of them have no option for
revealing the address, either.
My alter ego complained about this back in 2012 on the DMARC list, but
was given a lot of pushback... which makes DMARC essentially useless for
preventing spoofing. Great. Another half-assed protocol that doesn't
solve the problem it's supposed to solve.
http://lists.dmarc.org/pipermail/dmarc-discuss/2012-February/000189.html
Regards,
Dianne.
Re: Catching well directed spear phishing messages
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 28 Jun 2016, at 10:31, Jari Fredriksson wrote:
> Sure, but the case now is that the FROM != 'company adress' as this info
> is not even show to the user. What is shown is the CEO Name only. I
> could't even find a setting for this behaviour in my MUA!
That's a broken-by-design MUA.
Re: Catching well directed spear phishing messages
Posted by Jari Fredriksson <ja...@bitwell.biz>.
Groach kirjoitti 28.6.2016 17:24:
> On 28/06/2016 16:13, David Jones wrote:
>
> David Jones wrote on 29/06/16 12:46 AM:
>
> No, technology can help. The IT department sets up the mail client
> that the CEO uses when out of the office so that it sends mail using
> the company mail server with SSL/TLS and user authentication. Or it
> uses the company's ISP's mail server. Or send domain mail using GMail
> for business. There are a number of choices that are as easy for the
> CEO to use as any personal email method is, but will restrict email
> sent from the company domain to being sent through one of a known set
> of mail servers. Then the company's receiving mail server blocks any
> mail that pretends to be from a company domain sender address that
> was not sent through one of the known valid mail servers. That can be
> a local SpamAssassin rule or something run even earlier in the
> process.
>
> You are right that social engineering can't be stopped by technology.
> The company should have procedures in place that provide the
> flexibility that CEO seems to need but will still prevent the fraud
> even in the face of successful social engineering. But there is no
> reason the mail setup has to allow spoofed headers From the company
> domain.
Am I missing something here:
An email comes in from the CEO of the business - seemingly from the
company, and has a Spam score of 7.5
Content analysis details: (7.5 points, 5.5 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.0 TVD_RCVD_SPACE_BRACKET No description available.
0.1 HK_RANDOM_FROM From username looks random
-0.1 CUST_DNSWL_5_ORG_NT RBL: list.dnswl.org (No Trust)
[173.201.193.64 listed in list.dnswl.org]
-0.1 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[173.201.193.64 listed in wl.mailspike.net]
0.0 HTML_MESSAGE BODY: HTML included in message
1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76
chars
-0.1 CUST_DNSWL_2_SENDERSC_LOW RBL: score.senderscore.com (Low Trust)
[173.201.193.64 listed in
score.senderscore.com]
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
1.2 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
3.0 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
1.5 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s)
________________________________
Content analysis details: (13.9 points, 5.5 required)
How many INTERNAL EMAILS will have a score of 7.5??? Or even 3? Or 1?
In fact, if it came in through the INTERNAL_NETWORK ip range then it
wouldnt even be scanned (seen as trusted). So any email coming "from
the CEO" that has a SPAM score is definitely dodgy!
How hard can it be to say "if FROM = 'a company address' and a SPAM
SCORE EXISTS then treat with rubber gloves.
> So ensure all company emails are pupt through the company email servers and set the INTERNAL_NETWORK parameters.
>
> Whats wrong with this?
Sure, but the case now is that the FROM != 'company adress' as this info
is not even show to the user. What is shown is the CEO Name only. I
could't even find a setting for this behaviour in my MUA!
The FROM address can be anything, as long as the CEO's real name is
there before the address part.
--
Jari Fredriksson
Bitwell Oy
+358 400 779 440
jarif@bitwell.biz
https://www.bitwell.biz - cost effective hosting and security for
ecommerce
Re: Catching well directed spear phishing messages
Posted by Groach <gr...@yahoo.com>.
On 28/06/2016 16:13, David Jones wrote:
>>> David Jones wrote on 29/06/16 12:46 AM:
>>>
>>> No, technology can help. The IT department sets up the mail client
>>> that the CEO uses when out of the office so that it sends mail using
>>> the company mail server with SSL/TLS and user authentication. Or it
>>> uses the company's ISP's mail server. Or send domain mail using GMail
>>> for business. There are a number of choices that are as easy for the
>>> CEO to use as any personal email method is, but will restrict email
>>> sent from the company domain to being sent through one of a known set
>>> of mail servers. Then the company's receiving mail server blocks any
>>> mail that pretends to be from a company domain sender address that
>>> was not sent through one of the known valid mail servers. That can be
>>> a local SpamAssassin rule or something run even earlier in the
>>> process.
>>>
>>> You are right that social engineering can't be stopped by technology.
>>> The company should have procedures in place that provide the
>>> flexibility that CEO seems to need but will still prevent the fraud
>>> even in the face of successful social engineering. But there is no
>>> reason the mail setup has to allow spoofed headers From the company
>>> domain.
Am I missing something here:
An email comes in from the CEO of the business - seemingly from the
company, and has a Spam score of 7.5
Content analysis details: (7.5 points, 5.5 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.0 TVD_RCVD_SPACE_BRACKET No description available.
0.1 HK_RANDOM_FROM From username looks random
-0.1 CUST_DNSWL_5_ORG_NT RBL: list.dnswl.org (No Trust)
[173.201.193.64 listed in list.dnswl.org]
-0.1 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[173.201.193.64 listed in wl.mailspike.net]
0.0 HTML_MESSAGE BODY: HTML included in message
1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76
chars
-0.1 CUST_DNSWL_2_SENDERSC_LOW RBL: score.senderscore.com (Low Trust)
[173.201.193.64 listed in
score.senderscore.com]
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
1.2 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
3.0 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information
1.5 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s)
________________________________
Content analysis details: (13.9 points, 5.5 required)
How many INTERNAL EMAILS will have a score of 7.5??? Or even 3? Or 1?
In fact, if it came in through the INTERNAL_NETWORK ip range then it
wouldnt even be scanned (seen as trusted). So any email coming "from
the CEO" that has a SPAM score is definitely dodgy!
How hard can it be to say "if FROM = 'a company address' and a SPAM
SCORE EXISTS then treat with rubber gloves.
So ensure all company emails are pupt through the company email servers
and set the INTERNAL_NETWORK parameters.
Whats wrong with this?
Re: Catching well directed spear phishing messages
Posted by Dianne Skoll <df...@roaringpenguin.com>.
About the only way to combat these sorts of things is to have proper
financial processes in place. In other words, have checks to ensure
that no-one can initiate a wire transfer without a vendor invoice,
etc. Common sense stuff... but it's so easy to slip and you only have
to slip once. :(
Regards,
Dianne.
Re: Catching well directed spear phishing messages
Posted by Olivier Coutu <ol...@zerospam.ca>.
No, I have not used it, although it is a good idea. Could probably be
used for comparing From:names too, running after each new version of
"Pay-pal, paupal, etc." is a pain. If I make any progress on that I will
keep the list posted.
My plugin is written in Perl with a home-made implementation of
Levenshtein's algorithm, but Paul Stead's version is probably simpler
and more appropriate for general use.
Olivier Coutu
On 2016-09-15 10:22, Chip M. wrote:
> Have you used that technique to generate tokens for regular
> Phish prevention (e.g. all the myriad variations on Paypal)?
Re: Catching well directed spear phishing messages
Posted by Alex <my...@gmail.com>.
Hi all,
On Mon, Sep 19, 2016 at 5:46 AM, Paul Stead
<pa...@zeninternet.co.uk> wrote:
> On 15/09/16 20:54, RW wrote:
>>
>> On Thu, 15 Sep 2016 15:37:42 +0100
>> Paul Stead wrote:
>>
>>> https://github.com/fmbla/spamassassin-levenshtein
>>>
>>> An implementation I made for SA - feedback welcome
>>
>> A couple of things
>>
>>
>> 1. Instead of having a with/without tld option you could compute
>> the distance without the tld and then add 1 if the tlds differ.
>>
>> 2. The distance between two strings is at least the difference in their
>> length, so you can skip almost all the calls to distance().
>
>
> Thanks for everyone's comments. I have updated with these and other
> suggestions.
I haven't been able to follow all the ideas from this thread, one that
goes back many months and pertained to many of the problems we've been
having with CEO-directed phish attempts.
Is there something now that can be implemented from this discussion,
or is it all still being developed?
Re: Catching well directed spear phishing messages
Posted by Paul Stead <pa...@zeninternet.co.uk>.
On 15/09/16 20:54, RW wrote:
> On Thu, 15 Sep 2016 15:37:42 +0100
> Paul Stead wrote:
>
>> https://github.com/fmbla/spamassassin-levenshtein
>>
>> An implementation I made for SA - feedback welcome
> A couple of things
>
>
> 1. Instead of having a with/without tld option you could compute
> the distance without the tld and then add 1 if the tlds differ.
>
> 2. The distance between two strings is at least the difference in their
> length, so you can skip almost all the calls to distance().
Thanks for everyone's comments. I have updated with these and other
suggestions.
Paul
--
Paul Stead
Systems Engineer
Zen Internet
Re: Catching well directed spear phishing messages
Posted by RW <rw...@googlemail.com>.
On Thu, 15 Sep 2016 15:37:42 +0100
Paul Stead wrote:
>
> https://github.com/fmbla/spamassassin-levenshtein
>
> An implementation I made for SA - feedback welcome
A couple of things
1. Instead of having a with/without tld option you could compute
the distance without the tld and then add 1 if the tlds differ.
2. The distance between two strings is at least the difference in their
length, so you can skip almost all the calls to distance().
Re: Catching well directed spear phishing messages
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Thu, 15 Sep 2016 15:37:42 +0100
Paul Stead <pa...@zeninternet.co.uk> wrote:
> https://github.com/fmbla/spamassassin-levenshtein
Cool! Not sure what the performance implications are... there are XS
implementations of the Levenshtein distance... for example:
http://search.cpan.org/~ugexe/Text-Levenshtein-XS-0.503/
Regards,
Dianne.
Re: Catching well directed spear phishing messages
Posted by Paul Stead <pa...@zeninternet.co.uk>.
On 15/09/16 15:22, Chip M. wrote:
The other way to fix that is to detect the lexical distance between the
>sender's domain and your organisation's domains, e.g. by building a
>plugin that uses https://en.wikipedia.org/wiki/Levenshtein_distance.
>That could be done for a small number of domains within a few hours. In
>my experience results are impressive and it's really awesome to block
>such a personalized attack, although this spoofing method is not used
>that often due to its cost. Mail me if you want the core of the code to
>do those checks.
That sounds VERY interesting, Olivier! :)
https://github.com/fmbla/spamassassin-levenshtein
An implementation I made for SA - feedback welcome
--
Paul Stead
Systems Engineer
Zen Internet
Re: Catching well directed spear phishing messages
Posted by "Chip M." <sa...@IowaHoneypot.com>.
On Thu, 30 Jun 2016, Olivier Coutu wrote:
>The other way to fix that is to detect the lexical distance between the
>sender's domain and your organisation's domains, e.g. by building a
>plugin that uses https://en.wikipedia.org/wiki/Levenshtein_distance.
>That could be done for a small number of domains within a few hours. In
>my experience results are impressive and it's really awesome to block
>such a personalized attack, although this spoofing method is not used
>that often due to its cost. Mail me if you want the core of the code to
>do those checks.
That sounds VERY interesting, Olivier! :)
What language is it written in?
I'll be contacting you off-list. :)
Have you used that technique to generate tokens for regular
Phish prevention (e.g. all the myriad variations on Paypal)?
>You can keep a list of the executive names in your SA configuration,
>but good luck on catching all variations.
That got me thinking...
Catching variations can NEVER be perfect, however,
performing EXACT matches is easy and reliable.
In most email systems, it's close to trivial to rewrite headers,
in particular the Subject header.
Given that (at each domain) the number of spear-phish-relevant
senders & recipients is very small, and we know whether they're
authenticated and sending from the "correct" IP(s), we can do
exact matching just on email "From" the pool of money-authorizers
and "To" the pool of money-movers, then modify the Subject at the
SYSTEM level with a "magic token" only known to the money-movers.
All other emails would remain unmodified.
Nobody else should know the current "magic token".
It took me about an hour of Coding to add that to my post-SA
filter and has been in use at one of my domains (a charity) for
over a month. They're not at high risk, however they have been
receiving a steady trickle of well-targeted scams/malware and
have been worried, so were enthusiastic volunteers when I
explained what I wanted to experiment with. They're not Techies,
however they're attentive, cautious, and awesome at
asking questions & giving feedback. :)
I set it up on just one sending account (which has been regularly
spoofed), and three recipients.
I felt it would be easier (for the endusers) if we used a
two-part "magic token", with one part being human-readable &
"friendly", and one part being random (e.g. "[banana-38DYIT]"),
so the recipients could first screen on the easy to recognize &
remember part, then look up the random part on a printed list.
I asked the recipients to create their own list of "friendly"
tokens (and encouraged them to have fun with the task), then
generated a random token to pair with each, and set things up so
the two-part token automatically changes each weekend. They keep
the printed list (tokens&dates) in a drawer.
So far, there's been no technical issues.
Satisfaction is high and none of the three has expressed any
discomfort with seeing the extra token in their email clients.
After a couple of weeks, I sent a few RealName spoofs, and they
immediately spotted & reported all of them. Disclaimer: they did
know I'd be testing them (and were enthusiastic about it).
One feature I'm considering adding, is removal of the token when
they reply to the Money-Authorizer/sender. That would keep the
token private to the only people who need to see it.
** Can anyone think of any flaws in that, other than a cracked
Money-Authorizer account?
It's NOT idiot-proof, however it does give attentive non-techies
a simple & easy to see "code", and puts zero burden on the
Money-Authorizers, who tend to be the ones resisting change.
It's a lot easier on sysadmins than using a desktop addon. :)
*** Yet Another Idea (not yet implemented):
Many companies have a helpdesk email address that endusers are
told to forward questionable email to.
Great in theory, but the problem is that there's a human in that
loop, and most endusers are deeply reluctant to appear ignorant
or risk being chastised for "wasting time".
What if there was a mailbox that ran software that performed a
detailed technical analysis, then sent back a human friendly
report?
For example, with the "drive-by malware" campaign that I posted
last week, almost all travelled thru two IPs located in "unusual"
Nations, and the URL redirected to a 2nd URL at a newly
registered domain, that contained pure javascript.
The report might look something like:
You have previously received email from "James Kirk",
but <b>never</b> from the email address in this email.
It was sent from <b>India</b>, thru Great Britain.
It contained a link that was redirected to a brand
new domain, which looks like <b>drive by malware</b>.
Rating: DANGER! DANGER! DANGER!
Blocking stuff like that campaign takes significant extra lookups
(particularly WHOIS) at gateway time, but time wouldn't be an
issue with a small batch of human selected "uncertain" emails.
Endusers should be told up front that the only time a human
Techie would see anything sent to it, is if it raised an alarm...
in which case, they'd get a prize & thanks. ;)
They could even be encouraged to send at least one per day, just
for "practice".
*** Does such software exist?
I suspect it may already exist, in which case someone here _WILL_
know of it. :)
It would have to be smart enough to look up the original complete
email just from a (worst case) Outlook/etc forwarded email (only
core headers), so may have to be platform specific (unless IMAP
is sufficient?).
Obligatory disclaimer: I'm a programmer, not a sysadmin.
...though XKCD 705 is among my top 10 favorite Geek webcomics. :)
- "Chip"
Re: Catching well directed spear phishing messages
Posted by Olivier Coutu <ol...@zerospam.ca>.
On 2016-06-28 10:48, John Wilcock wrote:
>
> Or, if your company is a worthwhile target, it is equally easy for the
> scammer to setup a lookalike domain and configure it with proper SPF,
> DKIM and the like. Who's going to notice that the message came from
> examp1e.com instead of example.com?
>
> Theoretically, of course, custom SA rules could be written to detect
> such lookalikes, but even then, all it takes is for a scammer to have
> a slightly better imagination than the person writing the rules!
>
The other way to fix that is to detect the lexical distance between the
sender's domain and your organisation's domains, e.g. by building a
plugin that uses https://en.wikipedia.org/wiki/Levenshtein_distance.
That could be done for a small number of domains within a few hours. In
my experience results are impressive and it's really awesome to block
such a personalized attack, although this spoofing method is not used
that often due to its cost. Mail me if you want the core of the code to
do those checks.
In general, the problem that the scammer is trying to solve is how to
make the end user believe that he is the CEO/CFO while making sure that
the reply actually goes back to the scammer. In my experience,
Levenshtein-type domain spoofing is just one way to do it, here are
others that I have seen:
-Spoofing the content-from domain and using a different reply-to. This
may be done by using a different envelope-from domain or using the same
one if you do not have an SPF.
-Inserting the from-address in the from-name. With enough spacing, this
can be believable on certain MUAs.
-Spoofing the from name and using a bogus e-mail
(ceo_exec@freemailer.com). It's crude, but I have seen quite a few. You
can keep a list of the executive names in your SA configuration, but
good luck on catching all variations.
Of course, blocking on this basis only might create false-positives say
with web forms, so IMO some fraud-related language and exemptions must
be integrated in any custom rule. I would suggest using such a rule in
test and weeding out false-positives.
Olivier
Re: Catching well directed spear phishing messages
Posted by John Wilcock <jo...@tradoc.fr>.
Le 28/06/2016 16:13, David Jones a crit :
>> From: RW <rw...@googlemail.com>
>> That wont work in this example because nothing has actually been
>> spoofed.
...
> All it takes is a compromised account on a trusted mail server (happens
> all of the time) to provide a conduit for this type of phishing email. Very
> easy to do which is why we are going to see more and more of this.
Or, if your company is a worthwhile target, it is equally easy for the
scammer to setup a lookalike domain and configure it with proper SPF,
DKIM and the like. Who's going to notice that the message came from
examp1e.com instead of example.com?
Theoretically, of course, custom SA rules could be written to detect
such lookalikes, but even then, all it takes is for a scammer to have a
slightly better imagination than the person writing the rules!
--
John
Re: Catching well directed spear phishing messages
Posted by "Chip M." <sa...@IowaHoneypot.com>.
On Tue, 28 Jun 2016 14:13:57 +0000 David Jones wrote:
>If I search the Internet for the CEO/CIO/CTO/etc of a company
>and send and email from my domain but make the displayed name
>in the visible From: be that CEO/CIO/CTO/etc's full name that
>the recipient is used to seeing in the mail client, then I have
>spoofed nothing detectable in advance by SA or any mail filter
>technology.
Excellent summary!
The key is that the number of spoofed people is extremely SMALL,
and we _CAN_ anticipate who they are.
It's easy to write a CUSTOM set of rules just for actual/likely
targeted senders (CEO/etc).
For each person/target, create a rule that tests an explicit
list of that person's normal Realname(s) (including reasonable
variations), against the Realname part of the From header, and
if there's a match, test whether the From Address is in a list
of allowed addresses. Score only if it's a probable phish
Realname from an unknown/unallowed address.
There's lots of potential metas for even a low-scoring rule
(e.g John Hardin's tip).
I've been doing this since 2009, both on a generic basis
(built into my "phishy tokens in headers" anti-phish system),
and on a custom domain level as we notice/anticipate targeted
individuals (all in my post-SA filter - sorry, I have no
examples of SA rules, and am ASSuming they'll be easy to write).
It works extremely well and is easy to maintain. :)
*** Implementation issues:
1. There's potential for name collision, however these would be
manually generated rules, so the maintainer would use his/her
judgement to assign scores. For example, "Mark Sheppard" is
more likely to have a collision than "Chiwetel Ejiofor". :)
It would be straight forward to add an explicit list of (sender
verified) email addresses to exclude from testing.
In the seven years I've been doing this, I have had zero
collisions, however I have had an occasional FP when a targeted
sender starts sending stuff from himself using a new personal
email address, and does not notify the email admin. In those
cases, even without a quarantine, the sender should notice it.
A smart quarantine always makes life better.
2. Ideally, one should remove chaff (including potentially
obfuscatory middle initials) and excess whitespace from each
email's From Realname before doing the comparisons.
3. A big issue is fuzzing of Realnames, which is name dependant.
For most Westerners, most spelling variations in "Mark Sheppard"
are much easier to notice than in "Chiwetel Ejiofor". Leaving
out one of the double-ps in "Sheppard" would be a sensible
variation to add to his (hypothetical) list.
I have not yet noticed any fuzzing "in the wild", however all of
my targets have extremely "anglo" names. I recommend looking at
tools that create fuzzy variations.
I have seen MANY fuzzes of big non-spear phish targets
(e.g. "paypa1" "paypa"), and have been adding them as they occur.
I plan to add a fuzzy algorithm during my next dev cycle.
4. As John Wilcock mentions, fuzzy domains are an issue.
If you're a target, it's worth generating a list of most likely
variations, then score/block the un-registered ones, and make an
informed decision on the rest.
5. I STRONGLY recommend scoring all "ACE prefix" domains, to
reduce/eliminate all the subtle and/or invisible variations.
We've been doing that for two years, and so far have had
zero "skip" domain requests. Note that all our domains are
"Western" centric, though we have a few accounts who do have
regular contact with Unicode-type nations.
You all know your own email ecologies. :)
+1 to all the sensible remarks about good authorization policies.
The best defense has as many layers as practical. :)
- "Chip"
Re: Catching well directed spear phishing messages
Posted by David Jones <dj...@ena.com>.
>From: RW <rw...@googlemail.com>
>Sent: Tuesday, June 28, 2016 8:50 AM
>To: users@spamassassin.apache.org
>Subject: Re: Catching well directed spear phishing messages
>On Wed, 29 Jun 2016 01:30:55 +1200
>Sidney Markowitz wrote:
>> David Jones wrote on 29/06/16 12:46 AM:
>> > This is pure social engineering that can't be stopped by
>> > technology. The AP dept has to have proper safeguards and out of
>> > band validation (i.e. phone call to the "Recognized Name").
>>
>> No, technology can help. The IT department sets up the mail client
>> that the CEO uses when out of the office so that it sends mail using
>> the company mail server with SSL/TLS and user authentication. Or it
>> uses the company's ISP's mail server. Or send domain mail using GMail
>> for business. There are a number of choices that are as easy for the
>> CEO to use as any personal email method is, but will restrict email
>> sent from the company domain to being sent through one of a known set
>> of mail servers. Then the company's receiving mail server blocks any
>> mail that pretends to be from a company domain sender address that
>> was not sent through one of the known valid mail servers. That can be
>> a local SpamAssassin rule or something run even earlier in the
>> process.
>>
>> You are right that social engineering can't be stopped by technology.
>> The company should have procedures in place that provide the
>> flexibility that CEO seems to need but will still prevent the fraud
>> even in the face of successful social engineering. But there is no
>> reason the mail setup has to allow spoofed headers From the company
>> domain.
>That wont work in this example because nothing has actually been
>spoofed.
Exactly. If I search the Internet for the CEO/CIO/CTO/etc of a company
and send and email from my domain but make the displayed name in
the visible From: be that CEO/CIO/CTO/etc's full name that the recipient
is used to seeing in the mail client, then I have spoofed nothing detectable
in advance by SA or any mail filter technology. The sender could be anyone
and as long as that sending domain is not on any DBLs and the sending IP
is not on any RBLs (yet), then the email would pass through.
Envelope-from = ena.com
Header From: = ena.com
Visible/Displayed From: = "Recognized Name <re...@ena.com>"
That email would pass SPF and strict DMARC (p=reject) checking. If the
recipient just looked at "Recognized Name" and ignored the "ena.com",
then they wire the money and don't think twice about it until they follow
up with the C-level person later which wouldn't know anything about it.
All it takes is a compromised account on a trusted mail server (happens
all of the time) to provide a conduit for this type of phishing email. Very
easy to do which is why we are going to see more and more of this.
Re: Catching well directed spear phishing messages
Posted by RW <rw...@googlemail.com>.
On Wed, 29 Jun 2016 01:30:55 +1200
Sidney Markowitz wrote:
> David Jones wrote on 29/06/16 12:46 AM:
> > This is pure social engineering that can't be stopped by
> > technology. The AP dept has to have proper safeguards and out of
> > band validation (i.e. phone call to the "Recognized Name").
>
> No, technology can help. The IT department sets up the mail client
> that the CEO uses when out of the office so that it sends mail using
> the company mail server with SSL/TLS and user authentication. Or it
> uses the company's ISP's mail server. Or send domain mail using GMail
> for business. There are a number of choices that are as easy for the
> CEO to use as any personal email method is, but will restrict email
> sent from the company domain to being sent through one of a known set
> of mail servers. Then the company's receiving mail server blocks any
> mail that pretends to be from a company domain sender address that
> was not sent through one of the known valid mail servers. That can be
> a local SpamAssassin rule or something run even earlier in the
> process.
>
> You are right that social engineering can't be stopped by technology.
> The company should have procedures in place that provide the
> flexibility that CEO seems to need but will still prevent the fraud
> even in the face of successful social engineering. But there is no
> reason the mail setup has to allow spoofed headers From the company
> domain.
That wont work in this example because nothing has actually been
spoofed.
Re: Catching well directed spear phishing messages
Posted by Sidney Markowitz <si...@sidney.com>.
David Jones wrote on 29/06/16 12:46 AM:
> This is pure social engineering that can't be stopped by technology. The AP
> dept has to have proper safeguards and out of band validation (i.e. phone
> call to the "Recognized Name").
No, technology can help. The IT department sets up the mail client that the
CEO uses when out of the office so that it sends mail using the company mail
server with SSL/TLS and user authentication. Or it uses the company's ISP's
mail server. Or send domain mail using GMail for business. There are a number
of choices that are as easy for the CEO to use as any personal email method
is, but will restrict email sent from the company domain to being sent through
one of a known set of mail servers. Then the company's receiving mail server
blocks any mail that pretends to be from a company domain sender address that
was not sent through one of the known valid mail servers. That can be a local
SpamAssassin rule or something run even earlier in the process.
You are right that social engineering can't be stopped by technology. The
company should have procedures in place that provide the flexibility that CEO
seems to need but will still prevent the fraud even in the face of successful
social engineering. But there is no reason the mail setup has to allow spoofed
headers From the company domain.
Sidney
Re: Catching well directed spear phishing messages
Posted by Reindl Harald <h....@thelounge.net>.
Am 28.06.2016 um 14:52 schrieb Jari Fredriksson:
> I just refuse the believe that the technology has to trust to the
> From:.*xxx in the smtp payload and not reject this at once. Does the
> customer use some dmarc-implementation in their mail chain at all?
well, when none of your users are supposed to use maling lists like this
you can reject with http://www.postfix.org/header_checks.5.html and a
simple regex-rule
that depends on a sane setup where your MX server is *never* used to
handle internal email by have a dedicated inbound and a dedicated
submission server
Re: Catching well directed spear phishing messages
Posted by Reindl Harald <h....@thelounge.net>.
Am 28.06.2016 um 16:08 schrieb Jari Fredriksson:
> Reindl Harald kirjoitti 28.6.2016 16:56:
>> Am 28.06.2016 um 15:25 schrieb Jari Fredriksson:
>>>> Almost all the phishes I've received in the last few years have done
>>>> this - except that they have something like "paypal support" rather
>>>> than an individual's name.
>>>
>>> Ah, so true
>
>> you should look at that - enters my junk folder even with a
>> whitelist_auth because of the domain-blacklist
>
>> URIBL_BLACK
>> Contains an URL listed in the URIBL blacklist
>> [URIs: bitwell.biz]
>
> I don't see that happening in my SA, nor at
> https://admin.uribl.com/?section=lookup
dunno - but all your mails including my own to the list pointing it out
are ending in the junk folder
X-Spam-Report: Flag: No, * 6.5 URIBL_BLACK Contains an URL listed in the
URIBL blacklist * [URIs: bitwell.biz] * -0.1
CUST_DNSWL_2_SENDERSC_LOW
RBL: score.senderscore.com (Low Trust) * [140.211.11.3 listed in
score.senderscore.com] * -0.5 CUST_DNSWL_11_ORG_HIGH RBL: list.dnswl.org
(High Trust) * [140.211.11.3 listed in list.dnswl.org] * -0.2
CUST_DNSWL_8_TL_NT RBL: dnswl-aggregate.thelounge.net (No Trust) *
[140.211.11.3 listed in dnswl-aggregate.thelounge.net] * -0.1
CUST_DNSWL_3_JEF_LOW RBL: hostkarma.junkemailfilter.com (Low Trust) *
[140.211.11.3 listed in hostkarma.junkemailfilter.com] * -0.1
RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) * [140.211.11.3 listed in
wl.mailspike.net] * -100 USER_IN_SPF_WHITELIST From: address is in the
user's SPF whitelist * 0.0 SHORTCIRCUIT Not all rules were run, due to a
shortcircuited rule * 0.0 CUST_SHORTCIRCUIT Skip tests based on
whitelists/blacklists and * local relays
Return-Path:
users-return-112640-h.reindl=thelounge.net@spamassassin.apache.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Re: Catching well directed spear phishing messages
Posted by Jari Fredriksson <ja...@bitwell.biz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reindl Harald kirjoitti 28.6.2016 16:56:
> Am 28.06.2016 um 15:25 schrieb Jari Fredriksson:
>>> Almost all the phishes I've received in the last few years have done
>>> this - except that they have something like "paypal support" rather
>>> than an individual's name.
>>
>> Ah, so true
>
> you should look at that - enters my junk folder even with a
> whitelist_auth because of the domain-blacklist
>
> URIBL_BLACK
> Contains an URL listed in the URIBL blacklist
> [URIs: bitwell.biz]
I don't see that happening in my SA, nor at
https://admin.uribl.com/?section=lookup;
X-Spam-Report:
* -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,
high
* trust
* [140.211.11.3 listed in list.dnswl.org]
* -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
* [140.211.11.3 listed in wl.mailspike.net]
* 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
mail
* domains are different
* -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
* -0.0 DKIM_VERIFIED No description available.
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's
* domain
* 0.8 KAM_INFOUSMEBIZ Prevalent use of .info|.us|.me|.me.uk|.biz
domains
* in spam/malware
* -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
- --
Jari Fredriksson
Bitwell Oy
+358 400 779 440
jarif@bitwell.biz
https://www.bitwell.biz - cost effective hosting and security for
ecommerce
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAldyhMwACgkQKL4IzOyjSrbYBwCg5zgAMJeY84myBgJgV1cq6ahF
JDwAn0D7emcEdi5uHSpcbSHKHTJi3lwP
=ZK0P
-----END PGP SIGNATURE-----
Re: Catching well directed spear phishing messages
Posted by Jari Fredriksson <ja...@bitwell.biz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reindl Harald kirjoitti 28.6.2016 16:56:
> Am 28.06.2016 um 15:25 schrieb Jari Fredriksson:
>>> Almost all the phishes I've received in the last few years have done
>>> this - except that they have something like "paypal support" rather
>>> than an individual's name.
>>
>> Ah, so true
>
> you should look at that - enters my junk folder even with a
> whitelist_auth because of the domain-blacklist
>
> URIBL_BLACK
> Contains an URL listed in the URIBL blacklist
> [URIs: bitwell.biz]
Thanks for the heads up!
- --
Jari Fredriksson
Bitwell Oy
+358 400 779 440
jarif@bitwell.biz
https://www.bitwell.biz - cost effective hosting and security for
ecommerce
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAldygwgACgkQKL4IzOyjSrYjJwCg583oP4MHMYYZ45c+U52zTOCr
1lAAoPmF+3VwFoITyIdXgv1kLotRTHE3
=k/Yb
-----END PGP SIGNATURE-----
Re: Catching well directed spear phishing messages
Posted by Reindl Harald <h....@thelounge.net>.
Am 28.06.2016 um 15:25 schrieb Jari Fredriksson:
>> Almost all the phishes I've received in the last few years have done
>> this - except that they have something like "paypal support" rather
>> than an individual's name.
>
> Ah, so true
you should look at that - enters my junk folder even with a
whitelist_auth because of the domain-blacklist
URIBL_BLACK
Contains an URL listed in the URIBL blacklist
[URIs: bitwell.biz]
Re: Catching well directed spear phishing messages
Posted by Jari Fredriksson <ja...@bitwell.biz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
RW kirjoitti 28.6.2016 16:10:
> On Tue, 28 Jun 2016 15:52:10 +0300
> Jari Fredriksson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> David Jones kirjoitti 28.6.2016 15:46:
>
>> > One of my customers has been hit by at least one of these emails
>> > even with good RBLs in use and properly trained Bayes. The emails
>> > themselves are perfectly formed and score very low. They use an
>> > envelope-from of their own domain to pass all SPF checks but they
>> > use a visible From: of "Recognized Name
>> > <re...@otherdomain.com>". Even DMARC checks would pass for the
>> > otherdomain.com. The issue is the finance person sees the
>> > "Recognized Name" and doesn't look closely at the otherdomain.com.
>> > This is pure social engineering that can't be stopped by
>> > technology. The AP dept has to have proper safeguards and out of
>> > band validation (i.e. phone call to the "Recognized Name").
>
>> I just refuse the believe that the technology has to trust to the
>> From:.*xxx in the smtp payload and not reject this at once. Does the
>> customer use some dmarc-implementation in their mail chain at all?
>
> There's actually nothing to link it to the recipient's domain. The
> envelope address and header from domain are whatever the sender wants
> to use. It's all down to the displayed first name and surname which is
> all most email clients display.
>
> Almost all the phishes I've received in the last few years have done
> this - except that they have something like "paypal support" rather
> than an individual's name.
Ah, so true.
- --
Jari Fredriksson
Bitwell Oy
+358 400 779 440
jarif@bitwell.biz
https://www.bitwell.biz - cost effective hosting and security for
ecommerce
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAldyeuEACgkQKL4IzOyjSrZMlQCgsgwpMrayXJO7kVotYnBpF2xO
HucAnRICLQhEqEu65mVMWuBQIA08JWHe
=Npc6
-----END PGP SIGNATURE-----
Re: Catching well directed spear phishing messages
Posted by RW <rw...@googlemail.com>.
On Tue, 28 Jun 2016 15:52:10 +0300
Jari Fredriksson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Jones kirjoitti 28.6.2016 15:46:
> > One of my customers has been hit by at least one of these emails
> > even with good RBLs in use and properly trained Bayes. The emails
> > themselves are perfectly formed and score very low. They use an
> > envelope-from of their own domain to pass all SPF checks but they
> > use a visible From: of "Recognized Name
> > <re...@otherdomain.com>". Even DMARC checks would pass for the
> > otherdomain.com. The issue is the finance person sees the
> > "Recognized Name" and doesn't look closely at the otherdomain.com.
> > This is pure social engineering that can't be stopped by
> > technology. The AP dept has to have proper safeguards and out of
> > band validation (i.e. phone call to the "Recognized Name").
> I just refuse the believe that the technology has to trust to the
> From:.*xxx in the smtp payload and not reject this at once. Does the
> customer use some dmarc-implementation in their mail chain at all?
There's actually nothing to link it to the recipient's domain. The
envelope address and header from domain are whatever the sender wants
to use. It's all down to the displayed first name and surname which is
all most email clients display.
Almost all the phishes I've received in the last few years have done
this - except that they have something like "paypal support" rather
than an individual's name.
Re: Catching well directed spear phishing messages
Posted by Jari Fredriksson <ja...@bitwell.biz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Jones kirjoitti 28.6.2016 15:46:
>> From: Sidney Markowitz <si...@sidney.com>
>> Sent: Tuesday, June 28, 2016 3:15 AM
>> To: Ram; users@spamassassin.apache.org
>> Subject: Re: Catching well directed spear phishing messages
>
>> Ram wrote on 28/06/16 7:19 PM:
>>>
>>>
>>> On Tuesday 28 June 2016 12:03 PM, Raymond Dijkxhoorn wrote:
>>>> Hai!
>>>>
>>>> I dont understand why they would match your spf record either. Are they sended out by a IP adres you 'approved' ??
>>> SPF does not fail , because they use a different envelope address..
>>> which may pass SPF
>>> The end recipient does not check the envelope anyway
>
>> You should have local SpamAssassin rules that do check the envelope sender.
>> This is about official company mail from the company domain. You can require
>> that all employees use mail clients that are properly configured by the
>> company IT to send all official company mail. SpamAssassin can be configured
>> with local rules that stop anything that has a company domain header sender
>> address that does not also have a matching envelope sender address and passes
>> SPF. There is no reason to allow the CEO to send company mail without using a
>> proper mail server that appears on the SPF record.
>
>> The end recipient can't be expected to check all the headers, but SpamAssassin
>> can do that before the end recipient receives the mail.
>
>> Sidney
>
> One of my customers has been hit by at least one of these emails even with
> good RBLs in use and properly trained Bayes. The emails themselves are
> perfectly formed and score very low. They use an envelope-from of their
> own domain to pass all SPF checks but they use a visible From: of
> "Recognized Name <re...@otherdomain.com>". Even DMARC checks
> would pass for the otherdomain.com. The issue is the finance person sees
> the "Recognized Name" and doesn't look closely at the otherdomain.com.
> This is pure social engineering that can't be stopped by technology. The AP
> dept has to have proper safeguards and out of band validation (i.e. phone
> call to the "Recognized Name").
>
> In my instance, the finance person was told to wire thousands of dollars
> and the bad guy changed the banking information twice and the person
> still wasn't suspicious enough to stop and validate the request. The real
> problem is this is a very common practice for high-level people to request
> wire transfers for legitimate projects while out on the road so the AP dept
> lets down their guard.
I just refuse the believe that the technology has to trust to the
From:.*xxx in the smtp payload and not reject this at once. Does the
customer use some dmarc-implementation in their mail chain at all?
- --
Jari Fredriksson
Bitwell Oy
+358 400 779 440
jarif@bitwell.biz
https://www.bitwell.biz - cost effective hosting and security for
ecommerce
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAldycvsACgkQKL4IzOyjSrZFcQCgo28pdB9piIMlt9lktMpTnxgw
9IEAnibpGKGmR2geqgpQ2IpMGwqb+7aA
=kBlj
-----END PGP SIGNATURE-----
Re: Catching well directed spear phishing messages
Posted by David Jones <dj...@ena.com>.
>From: Sidney Markowitz <si...@sidney.com>
>Sent: Tuesday, June 28, 2016 3:15 AM
>To: Ram; users@spamassassin.apache.org
>Subject: Re: Catching well directed spear phishing messages
>Ram wrote on 28/06/16 7:19 PM:
>>
>>
>> On Tuesday 28 June 2016 12:03 PM, Raymond Dijkxhoorn wrote:
>>> Hai!
>>>
>>> I dont understand why they would match your spf record either. Are they sended out by a IP adres you 'approved' ??
>> SPF does not fail , because they use a different envelope address..
>> which may pass SPF
>> The end recipient does not check the envelope anyway
>You should have local SpamAssassin rules that do check the envelope sender.
>This is about official company mail from the company domain. You can require
>that all employees use mail clients that are properly configured by the
>company IT to send all official company mail. SpamAssassin can be configured
>with local rules that stop anything that has a company domain header sender
>address that does not also have a matching envelope sender address and passes
>SPF. There is no reason to allow the CEO to send company mail without using a
>proper mail server that appears on the SPF record.
>The end recipient can't be expected to check all the headers, but SpamAssassin
>can do that before the end recipient receives the mail.
> Sidney
One of my customers has been hit by at least one of these emails even with
good RBLs in use and properly trained Bayes. The emails themselves are
perfectly formed and score very low. They use an envelope-from of their
own domain to pass all SPF checks but they use a visible From: of
"Recognized Name <re...@otherdomain.com>". Even DMARC checks
would pass for the otherdomain.com. The issue is the finance person sees
the "Recognized Name" and doesn't look closely at the otherdomain.com.
This is pure social engineering that can't be stopped by technology. The AP
dept has to have proper safeguards and out of band validation (i.e. phone
call to the "Recognized Name").
In my instance, the finance person was told to wire thousands of dollars
and the bad guy changed the banking information twice and the person
still wasn't suspicious enough to stop and validate the request. The real
problem is this is a very common practice for high-level people to request
wire transfers for legitimate projects while out on the road so the AP dept
lets down their guard.
Re: Catching well directed spear phishing messages
Posted by Sidney Markowitz <si...@sidney.com>.
Ram wrote on 28/06/16 7:19 PM:
>
>
> On Tuesday 28 June 2016 12:03 PM, Raymond Dijkxhoorn wrote:
>> Hai!
>>
>> I dont understand why they would match your spf record either. Are they sended out by a IP adres you 'approved' ??
> SPF does not fail , because they use a different envelope address..
> which may pass SPF
> The end recipient does not check the envelope anyway
You should have local SpamAssassin rules that do check the envelope sender.
This is about official company mail from the company domain. You can require
that all employees use mail clients that are properly configured by the
company IT to send all official company mail. SpamAssassin can be configured
with local rules that stop anything that has a company domain header sender
address that does not also have a matching envelope sender address and passes
SPF. There is no reason to allow the CEO to send company mail without using a
proper mail server that appears on the SPF record.
The end recipient can't be expected to check all the headers, but SpamAssassin
can do that before the end recipient receives the mail.
Sidney
Re: Catching well directed spear phishing messages
Posted by Ram <ra...@netcore.co.in>.
On Tuesday 28 June 2016 12:03 PM, Raymond Dijkxhoorn wrote:
> Hai!
>
> I dont understand why they would match your spf record either. Are they sended out by a IP adres you 'approved' ??
SPF does not fail , because they use a different envelope address..
which may pass SPF
The end recipient does not check the envelope anyway
> Thanks,
> Raymond Dijkxhoorn
>
>> Op 28 jun. 2016 om 03:27 heeft jdebert <jd...@garlic.com> het volgende geschreven:
>>
>> On Mon, 27 Jun 2016 18:41:04 +0530
>> Ram <ra...@netcore.co.in> wrote:
>>
>>> I am seeing messages that appear to come from the MD or the CEO of
>>> the company to the accounts department asking people to transfer
>>> money to some fake account
>>>
>>> These messages were initially few and I ignored. But now this has
>>> become a problem.
>>> I know these are not spam messages so catching them will be out of
>>> scope for a spam filter.
>>>
>>> These messages have different envelope ids so SPF checks always pass.
>>> The header from is properly formatted exactly how it will be in a
>>> normal mail
>>>
>>> What measures do you take for such spear phishing
>>>
>>> Thanks
>>> Ram
>> You're not using the proper tools. you cannot expect spamassassin to
>> magically prevent all such messages. Just because spamassassin or any
>> other filter passes such a message does not mean it is valid. To use
>> spamassassin and filters to block such messages gives a false sense
>> of security and leads to false assumptions of authenticity. Your company
>> must enforce strict AP controls to prevent payouts based on such
>> messages and the controls must apply to everyone, including the CEO. Those are the proper tools.
>>
>> Given that these messages are appearing more frequently, it may be that
>> some have already been successful. I suggest you consider an AP audit
>> to ensure that this is not the case
>>
Re: Catching well directed spear phishing messages
Posted by Raymond Dijkxhoorn <ra...@prolocation.net>.
Hai!
I dont understand why they would match your spf record either. Are they sended out by a IP adres you 'approved' ??
Thanks,
Raymond Dijkxhoorn
> Op 28 jun. 2016 om 03:27 heeft jdebert <jd...@garlic.com> het volgende geschreven:
>
> On Mon, 27 Jun 2016 18:41:04 +0530
> Ram <ra...@netcore.co.in> wrote:
>
>> I am seeing messages that appear to come from the MD or the CEO of
>> the company to the accounts department asking people to transfer
>> money to some fake account
>>
>> These messages were initially few and I ignored. But now this has
>> become a problem.
>> I know these are not spam messages so catching them will be out of
>> scope for a spam filter.
>>
>> These messages have different envelope ids so SPF checks always pass.
>> The header from is properly formatted exactly how it will be in a
>> normal mail
>>
>> What measures do you take for such spear phishing
>>
>> Thanks
>> Ram
>
> You're not using the proper tools. you cannot expect spamassassin to
> magically prevent all such messages. Just because spamassassin or any
> other filter passes such a message does not mean it is valid. To use
> spamassassin and filters to block such messages gives a false sense
> of security and leads to false assumptions of authenticity. Your company
> must enforce strict AP controls to prevent payouts based on such
> messages and the controls must apply to everyone, including the CEO. Those are the proper tools.
>
> Given that these messages are appearing more frequently, it may be that
> some have already been successful. I suggest you consider an AP audit
> to ensure that this is not the case
>
Re: Catching well directed spear phishing messages
Posted by jdebert <jd...@garlic.com>.
On Mon, 27 Jun 2016 18:41:04 +0530
Ram <ra...@netcore.co.in> wrote:
> I am seeing messages that appear to come from the MD or the CEO of
> the company to the accounts department asking people to transfer
> money to some fake account
>
> These messages were initially few and I ignored. But now this has
> become a problem.
> I know these are not spam messages so catching them will be out of
> scope for a spam filter.
>
> These messages have different envelope ids so SPF checks always pass.
> The header from is properly formatted exactly how it will be in a
> normal mail
>
> What measures do you take for such spear phishing
>
> Thanks
> Ram
>
You're not using the proper tools. you cannot expect spamassassin to
magically prevent all such messages. Just because spamassassin or any
other filter passes such a message does not mean it is valid. To use
spamassassin and filters to block such messages gives a false sense
of security and leads to false assumptions of authenticity. Your company
must enforce strict AP controls to prevent payouts based on such
messages and the controls must apply to everyone, including the CEO. Those are the proper tools.
Given that these messages are appearing more frequently, it may be that
some have already been successful. I suggest you consider an AP audit
to ensure that this is not the case