Re: Amazon, dhl, fedex, etc. phishing
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.
Re: Amazon, dhl, fedex, etc. phishing
> We are regularly getting phishes from dhl, fedex, usps, amazon, netflix,
> spotify that fakes the from (eg. amazon 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
header NOT_FROM_USPS From =~
/\bUSPS\b[^<]*<[\w\-.]+\@[\w\-.]*\b(?!usps\.com)\s{0,3}>/
score NOT_FROM_USPS 1
describeNOT_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:
# Message-Id: <20080121072522.16582.qmail@comp2>
# From:
#
# 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 =~ /<>/
metaNOT_FROM_SENDER !__FROM_SENDER && !__NULL_SENDER
score NOT_FROM_SENDER 1
describeNOT_FROM_SENDER Not from putative sender
# Return-Path:
# 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
On Mon, 24 Aug 2020, micah anderson wrote: John Hardin 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 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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@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
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@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
John Hardin 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
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
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:mar...@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 < p...@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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently)
RE: Amazon, dhl, fedex, etc. phishing
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@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
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:mar...@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 < > p...@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
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 < p...@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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@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
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 < > p...@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
Amazon, dhl, fedex, etc. phishing
We are regularly getting phishes from dhl, fedex, usps, amazon, netflix, spotify that fakes the from (eg. amazon 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
