You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by AJ Weber <aw...@comcast.net> on 2019/12/17 21:15:37 UTC

phishing by deceptive From address detection

Just looking at a phishing email I received and at first glance I wasn't 
sure how SA (or more-specifically my SA install/configuration) didn't 
score this as spam.

Looks like I have a whitelist setup for alerts from comcast (probably a 
bad idea, but let's address that separately).

The following header is the FROM in the message envelope.

From: =?utf-8?Q?B=CC=B7B=CC=B7&T?= <on...@alerts.comcast.net>

And the email is supposedly one telling me my credit card has been 
compromised, click here to restore access, yada, yada, yada. (I do not 
bank with BB&T at all.)

I am using the KAM and many of the other rules recommended by those on 
this list.  Besides the whitelist mistake, would this "disguised From" 
be detected by some of the other rulesets (I also use KAM)?  I thought I 
read a post or announcement that this type of disguise was detected 
pretty-well?

Thanks for any help.

-AJ



Re: phishing by deceptive From address detection

Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 18 Dec 2019, at 8:35, AJ Weber wrote:

>>> The 'B' characters have been overlaid with a clearly visible slash,
>>> which isn't very clever in a phishing email.
>
>
> Interesting, Thunderbird does not show any visible slash.  Just 
> "BB&T" - though the font looks different.

The  "=CC=B7" sequence in the quoted-printable part is a UTF-8 
"Combining Short Solidus Overlay" which is a diacritical mark that puts 
a solidus (slash) through the preceeding character. In some fonts at 
some sizes, adding that to a 'B' makes very little difference in which 
pixels are which color on-screen.


-- 
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Re: phishing by deceptive From address detection

Posted by AJ Weber <aw...@comcast.net>.
>> The following header is the FROM in the message envelope.
>>
>> From: =?utf-8?Q?B=CC=B7B=CC=B7&T?=
>> <on...@alerts.comcast.net>
>>
>>
>> I'm not sure what you mean by disguise, and what you expect should have
>> been done.

I suppose you're right.  I wonder if there's a rule I could develop that 
goes like, [if the descriptive From is entirely different to the name 
(not domain) part of the smtp address - give it some moderate score].

In this particular case, there is nothing close to "BB&T" in the smtp 
address, which could be an attempt to deceive the user and the spam 
filters.  Not always, I entirely agree, but maybe something I can "play 
with" for my setup.

>> The 'B' characters have been overlaid with a clearly visible slash,
>> which isn't very clever in a phishing email.
Interesting, Thunderbird does not show any visible slash.  Just "BB&T" - 
though the font looks different.


Re: phishing by deceptive From address detection

Posted by RW <rw...@googlemail.com>.
On Tue, 17 Dec 2019 16:15:37 -0500
AJ Weber wrote:

> Just looking at a phishing email I received and at first glance I
> wasn't sure how SA (or more-specifically my SA install/configuration)
> didn't score this as spam.
> 
> Looks like I have a whitelist setup for alerts from comcast (probably
> a bad idea, but let's address that separately).
> 
> The following header is the FROM in the message envelope.
> 
> From: =?utf-8?Q?B=CC=B7B=CC=B7&T?=
> <on...@alerts.comcast.net>
> 
> And the email is supposedly one telling me my credit card has been 
> compromised, click here to restore access, yada, yada, yada. (I do
> not bank with BB&T at all.)
> 
> I am using the KAM and many of the other rules recommended by those
> on this list.  Besides the whitelist mistake, would this "disguised
> From" be detected by some of the other rulesets (I also use KAM)?  I
> thought I read a post or announcement that this type of disguise was
> detected pretty-well?

I'm not sure what you mean by disguise, and what you expect should have
been done. 

The MIME encoding is legitimate and normal for a header with a non-ascii
character, and SA decodes it for header and body rules. 

The 'B' characters have been overlaid with a clearly visible slash,
which isn't very clever in a phishing email.