Mailing List Archive

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?= <online.communications@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 [ In reply to ]
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?=
> <online.communications@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.
Re: phishing by deceptive From address detection [ In reply to ]
>> The following header is the FROM in the message envelope.
>>
>> From: =?utf-8?Q?B=CC=B7B=CC=B7&T?=
>> <online.communications@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 [ In reply to ]
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)