Mailing List Archive

Amazon, dhl, fedex, etc. phishing
We are regularly getting phishes from dhl, fedex, usps, amazon, netflix,
spotify that fakes the from (eg. amazon <pepe@biggung1892301.com> wants
to send me a amadon-legit.pdf). Usually these are previously unknown to
pyzor, dcc, rbls, and domain reputation doesn't really exist[0].

I'm wondering if anyone has made a rule that looks to see if the From
contains amazon, but it is not amazon.com/.ca/.jp (all their TLDs), then
score them up, if it wants to also drop a psd, or a tar.xz, or a png, or
a pdf or whatever, then light them on fire.

thanks!

--
micah

0. this rule does fire, and is helpful, but not always:
FROM_FMBLA_NEWDOM From domain was registered in last 7 days
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 2020-08-24 at 12:00 -0400, micah anderson wrote:
> We are regularly getting phishes from dhl, fedex, usps, amazon,
> netflix, spotify that fakes the from (eg. amazon <
> pepe@biggung1892301.com> wants to send me a amadon-legit.pdf).
>
> I'm wondering if anyone has made a rule that looks to see if the From
> contains amazon, but it is not amazon.com/.ca/.jp (all their TLDs),
>
Try it yourself: something like this:

header SUBRULE13a From:name =~ /Amazon/
header SUBRULE13b From:addr =~ /amazon/
meta SUBRULE13 (SUBRULE13a != SUBRULE13b)
score SUBRULE13 10

should work though the text in the regex will probably need tweaking to
match actual spam. You'll need to collect examples of spam from all
these sources to test your rules against. Also:

- the regexes may need alternates if, say, you see variations in the
name text or if you want the addr regex to include more than just
the bare domain name

- of course you'll need a separate rule for each spam source

- another spam warning is emaile where the domain name
in the Message-id doesn't match the one in the From address.

I'm not seeing anything that looks like the spam you're getting, but if
I did, that's the type of rule I'd be writing to trap the garbage.

Martin
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 24 Aug 2020, Martin Gregorie wrote:

> On Mon, 2020-08-24 at 12:00 -0400, micah anderson wrote:
>> We are regularly getting phishes from dhl, fedex, usps, amazon,
>> netflix, spotify that fakes the from (eg. amazon <
>> pepe@biggung1892301.com> wants to send me a amadon-legit.pdf).
>>
>> I'm wondering if anyone has made a rule that looks to see if the From
>> contains amazon, but it is not amazon.com/.ca/.jp (all their TLDs),
>>
> Try it yourself: something like this:
>
> header SUBRULE13a From:name =~ /Amazon/
> header SUBRULE13b From:addr =~ /amazon/

Might want some \b in there, just to be safe. The from check would also
hit domains like "amazon-river.org". Perhaps:

header SUBRULE13a From:name =~ /\bAmazon\b/
header SUBRULE13b From:addr =~ /\bamazon\.com$/


> meta SUBRULE13 (SUBRULE13a != SUBRULE13b)

That seems too broad, you're assuming mail from amazon.com always has
"amazon" in the sender name. Perhaps:

meta SUBRULE13 SUBRULE13a && !SUBRULE13b

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org 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?"
-----------------------------------------------------------------------
Today: the 1941st anniversary of the destruction of Pompeii
RE: Amazon, dhl, fedex, etc. phishing [ In reply to ]
You should use spf for this. Except for the fact that at dhl they are to
dumb to know what servers they are using.



-----Original Message-----
From: Martin Gregorie [mailto:martin@gregorie.org]
Sent: maandag 24 augustus 2020 20:25
To: micah anderson; users@spamassassin.apache.org
Subject: Re: Amazon, dhl, fedex, etc. phishing

On Mon, 2020-08-24 at 12:00 -0400, micah anderson wrote:
> We are regularly getting phishes from dhl, fedex, usps, amazon,
> netflix, spotify that fakes the from (eg. amazon <
> pepe@biggung1892301.com> wants to send me a amadon-legit.pdf).
>
> I'm wondering if anyone has made a rule that looks to see if the From
> contains amazon, but it is not amazon.com/.ca/.jp (all their TLDs),
>
Try it yourself: something like this:

header SUBRULE13a From:name =~ /Amazon/
header SUBRULE13b From:addr =~ /amazon/
meta SUBRULE13 (SUBRULE13a != SUBRULE13b)
score SUBRULE13 10

should work though the text in the regex will probably need tweaking to
match actual spam. You'll need to collect examples of spam from all
these sources to test your rules against. Also:

- the regexes may need alternates if, say, you see variations in the
name text or if you want the addr regex to include more than just
the bare domain name

- of course you'll need a separate rule for each spam source

- another spam warning is emaile where the domain name
in the Message-id doesn't match the one in the From address.

I'm not seeing anything that looks like the spam you're getting, but if
I did, that's the type of rule I'd be writing to trap the garbage.

Martin
RE: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 24 Aug 2020, Marc Roos wrote:

> You should use spf for this.

Duh.

+1

whitelist_auth *@amazon.com
blacklist_from *@amazon.com
whitelist_auth *@*.amazon.com
blacklist_from *@*.amazon.com


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org 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?"
-----------------------------------------------------------------------
Today: the 1941st anniversary of the destruction of Pompeii
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On 24 Aug 2020, at 14:53, Marc Roos wrote:

> You should use spf for this. Except for the fact that at dhl they are
> to
> dumb to know what servers they are using.

SPF does no good with addresses as described in the original post.

The overwhelming majority of phish spam makes no attempt to fake the
envelope sender address or the From header domain. Modern MUAs have
mostly adopted the practice of showing only the display name/comment
portion(s) of the From header, making it a counter-productive waste of
effort to fake any part of the actual email address.



> -----Original Message-----
> From: Martin Gregorie [mailto:martin@gregorie.org]
> Sent: maandag 24 augustus 2020 20:25
> To: micah anderson; users@spamassassin.apache.org
> Subject: Re: Amazon, dhl, fedex, etc. phishing
>
> On Mon, 2020-08-24 at 12:00 -0400, micah anderson wrote:
>> We are regularly getting phishes from dhl, fedex, usps, amazon,
>> netflix, spotify that fakes the from (eg. amazon <
>> pepe@biggung1892301.com> wants to send me a amadon-legit.pdf).
>>
>> I'm wondering if anyone has made a rule that looks to see if the From
>> contains amazon, but it is not amazon.com/.ca/.jp (all their TLDs),
>>
> Try it yourself: something like this:
>
> header SUBRULE13a From:name =~ /Amazon/
> header SUBRULE13b From:addr =~ /amazon/
> meta SUBRULE13 (SUBRULE13a != SUBRULE13b)
> score SUBRULE13 10
>
> should work though the text in the regex will probably need tweaking
> to
> match actual spam. You'll need to collect examples of spam from all
> these sources to test your rules against. Also:
>
> - the regexes may need alternates if, say, you see variations in the
> name text or if you want the addr regex to include more than just
> the bare domain name
>
> - of course you'll need a separate rule for each spam source
>
> - another spam warning is emaile where the domain name
> in the Message-id doesn't match the one in the From address.
>
> I'm not seeing anything that looks like the spam you're getting, but
> if
> I did, that's the type of rule I'd be writing to trap the garbage.
>
> Martin


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 2020-08-24 at 11:51 -0700, John Hardin wrote:
> Might want some \b in there, just to be safe. The from check would
> also
> hit domains like "amazon-river.org". Perhaps:
>
> header SUBRULE13a From:name =~ /\bAmazon\b/
> header SUBRULE13b From:addr =~ /\bamazon\.com$/
>
Indeed
>
> > meta SUBRULE13 (SUBRULE13a != SUBRULE13b)
>
> That seems too broad, you're assuming mail from amazon.com always has
> "amazon" in the sender name. Perhaps:
>
> meta SUBRULE13 SUBRULE13a && !SUBRULE13b
>
Also true.

What I *thought* I was doing was:

* firstly, to show the OP how to write a rule that examined a From
header and would only fire if there was a match on the name part and no
match on the address part - a very common spam feature (as is the From
Address not containing the same domain as the Message-ID).

* to give some guidance that testing is essential (i.e. keep some known
spam to be looked at when writing the rules and for testing the new
rules) AND to remind the OP that the significant parts of name and
address strings may differ, should be copied from known spam, and may
need further tweaks as the rules are tested

* trying to explain that this type of rule cannot and will only work
reliably if its written against a single spamming domain.


Martin
RE: Amazon, dhl, fedex, etc. phishing [ In reply to ]
John Hardin <jhardin@impsec.org> writes:

> On Mon, 24 Aug 2020, Marc Roos wrote:
>
>> You should use spf for this.
>
> Duh.
>
> +1
>
> whitelist_auth *@amazon.com
> blacklist_from *@amazon.com
> whitelist_auth *@*.amazon.com
> blacklist_from *@*.amazon.com

I do not understand this, how does this work?

--
micah
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 24 Aug 2020, Martin Gregorie wrote:

> On Mon, 2020-08-24 at 11:51 -0700, John Hardin wrote:
>> Might want some \b in there, just to be safe. The from check would
>> also
>> hit domains like "amazon-river.org". Perhaps:
>>
>> header SUBRULE13a From:name =~ /\bAmazon\b/
>> header SUBRULE13b From:addr =~ /\bamazon\.com$/
>>
> Indeed
>>
>>> meta SUBRULE13 (SUBRULE13a != SUBRULE13b)
>>
>> That seems too broad, you're assuming mail from amazon.com always has
>> "amazon" in the sender name. Perhaps:
>>
>> meta SUBRULE13 SUBRULE13a && !SUBRULE13b
>>
> Also true.
>
> What I *thought* I was doing was:

Sorry, I can't help doing that. :)


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Our politicians should bear in mind the fact that
the American Revolution was touched off by the then-current
government attempting to confiscate firearms from the people.
-----------------------------------------------------------------------
Today: the 1941st anniversary of the destruction of Pompeii
RE: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 24 Aug 2020, micah anderson wrote:

> John Hardin <jhardin@impsec.org> writes:
>
>> On Mon, 24 Aug 2020, Marc Roos wrote:
>>
>>> You should use spf for this.
>>
>> Duh.
>>
>> +1
>>
>> whitelist_auth *@amazon.com
>> blacklist_from *@amazon.com
>> whitelist_auth *@*.amazon.com
>> blacklist_from *@*.amazon.com
>
> I do not understand this, how does this work?

It's a little clearer if the order is reversed...

blacklist_from *@amazon.com

If a mail claims to be from an amazon.com address, add a large score (I
disremember what it is offhand; 50 points?)

whitelist_auth *@amazon.com

If a mail claims to be from an amazon.com address, and it passas SPF or
has a valig signature for that domain, then add -100 to the score.

The net result is, any mail claiming to be from amazon.com is blacklisted,
unless it *actually comes from* amazon.com.


But, as Bill noted, it doesn't help with this case, as it doesn't
claim to be from amazon.com:

From: Amazon <pepe@biggung1892301.com>

Sorry, I lost track of that nuance.

That could be captured by the above whitelist_auth, plus a "from name"
rule:

header FM_NAME_AMAZON From:name =~ /^amazon(?:.com\b|$)/i
score FM_NAME_AMAZON 10

That's a poison pill by itself, but the whitelist_auth entry would
override it for genuine Amazon emails.

Note, poison pill rules are generally a bad idea.


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Our politicians should bear in mind the fact that
the American Revolution was touched off by the then-current
government attempting to confiscate firearms from the people.
-----------------------------------------------------------------------
Today: the 1941st anniversary of the destruction of Pompeii
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
> We are regularly getting phishes from dhl, fedex, usps, amazon, netflix,
> spotify that fakes the from (eg. amazon <pepe@biggung1892301.com> wants
> to send me a amadon-legit.pdf). Usually these are previously unknown to
> pyzor, dcc, rbls, and domain reputation doesn't really exist[0].
>
> I'm wondering if anyone has made a rule that looks to see if the From
> contains amazon, but it is not amazon.com/.ca/.jp (all their TLDs), then
> score them up, if it wants to also drop a psd, or a tar.xz, or a png, or
> a pdf or whatever, then light them on fire.

I have rules similar to that to catch other things. I just made one for you to catch a spam that claims to be from USPS but is not. Simple modifications will catch other putative senders.

#-----------------------------------------------------------------------------------
# 08/24/2020

# Someone on the SA mailing list is upset about spams that claim to be from some
# reputable company, usually a package transfer company, but actually aren't.
# I have an example in today's spam, though it is caught by lots of other rules:
#
# From: USPS <store-news@amazon.com>

header NOT_FROM_USPS From =~ /\bUSPS\b[^<]*<[\w\-.]+\@[\w\-.]*\b(?!usps\.com)\s{0,3}>/
score NOT_FROM_USPS 1
describe NOT_FROM_USPS Claims to be from USPS, but isn't



I'm also including two general rules that catch this sort of stuff most of the time.

#-----------------------------------------------------------------------------------
# 01/21/08

# Return-Path: <bradshaw_nq@laposte.net>
# Message-Id: <20080121072522.16582.qmail@comp2>
# From: <fred@ferd.com>
#
# The from and the return-path should match
# The from host and the message-id host should match

header __FROM_SENDER ALL =~ m'Return-Path:\s+<([^\n>]+)>.*\nFrom:(?:[^<\n]+<\1>|\s+\1$)'si
header __NULL_SENDER Return-Path =~ /<>/
meta NOT_FROM_SENDER !__FROM_SENDER && !__NULL_SENDER
score NOT_FROM_SENDER 1
describe NOT_FROM_SENDER Not from putative sender

# Return-Path: <jqvfd@fsuimail.ferris.edu>
# Message-ID: <7a9a01c85ca2$0fcbc910$c0a80102@Ricky>

header __SENDER_MSGID ALL =~ m'Return-Path:[^\@\n]+\@([^>.]+).*\nMessage-Id:[^\@\n]+\@[\w.]{0,30}\1'si
meta NOT_SENDER_MSGID !__SENDER_MSGID && !__NULL_SENDER
score NOT_SENDER_MSGID 0.5
describe NOT_SENDER_MSGID Sender host doesn't match message-id host
Re: Amazon, dhl, fedex, etc. phishing [ In reply to ]
On Mon, 24 Aug 2020 19:22:27 -0700 (PDT)
John Hardin wrote:


> That could be captured by the above whitelist_auth, plus a "from
> name" rule:
>
> header FM_NAME_AMAZON From:name =~ /^amazon(?:.com\b|$)/i
> score FM_NAME_AMAZON 10
>
> That's a poison pill by itself, but the whitelist_auth entry would
> override it for genuine Amazon emails.

I do it something like this:


meta WHITELIST_SPOOFED __SHOULD_BE_WHITELISTED && !ANY_WHITELIST

This allowed the default whitelists to cancel the rule without giving
them a huge negative score.