You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Mark London <mr...@psfc.mit.edu> on 2019/01/27 04:43:32 UTC
Another form of obfuscation email.
Does anyone have any rules that can catch this type of obfuscated spam?
https://pastebin.com/qi8dsREW
Thanks. - Mark
Re: Another form of obfuscation email.
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 26 Jan 2019, at 23:43, Mark London wrote:
> Does anyone have any rules that can catch this type of obfuscated
> spam?
>
> https://pastebin.com/qi8dsREW
>
> Thanks. - Mark
I've been playing with a suite of rules around a concept that hits this
example for a while, but haven't gotten around to doing a solid analysis
of how well the latest rev is working. Caveat Emptor: This rule suite is
worth at most what you've paid for it!
rawbody __SCC_HTML_LOCKTITLE /<title>[^<]*(ID|account|service)\s*(is|has
been|was)\s*(locked|disabled|suspended)[^<]*<\/title>/
describe __SCC_HTML_LOCKTITLE An Important Title.
rawbody __SCC_HTML_LOCKBODY /<body>.*(ID|account|service)\s*(is|has
been|was)\s*(locked|disabled|suspended)/ms
describe __SCC_HTML_LOCKBODY An Important Message
meta T_SCC_WARN_TITLE_ONLY __SCC_HTML_LOCKTITLE && !__SCC_HTML_LOCKBODY
describe T_SCC_WARN_TITLE_ONLY HTML Title warning not in body
meta T_SCC_WARN_BODY_ONLY !__SCC_HTML_LOCKTITLE && __SCC_HTML_LOCKBODY
describe T_SCC_WARN_BODY_ONLY Body warning not in HTML Title
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Re: Another form of obfuscation email.
Posted by RALPH HAUSER <be...@aol.com>.
PLEASE UNSUBSCRIBE ME TO THESE EMAILS! I NEVER SIGNED UP FOR THIS AND I DONT UNDERSTAND ANY OF THIS! PLEASE!
> On Jan 26, 2019, at 9:55 PM, Rupert Gallagher <ru...@protonmail.com> wrote:
>
> I would focus on the headers: they have plenty for a spam flag. On the body, SA should already mark the text/code ratio, and the number of links.
>
>> On Sun, Jan 27, 2019 at 05:43, Mark London <mr...@psfc.mit.edu> wrote:
>> Does anyone have any rules that can catch this type of obfuscated spam?
>>
>> https://pastebin.com/qi8dsREW
>>
>> Thanks. - Mark
>>
>
>
Re: Another form of obfuscation email.
Posted by Rupert Gallagher <ru...@protonmail.com>.
I would focus on the headers: they have plenty for a spam flag. On the body, SA should already mark the text/code ratio, and the number of links.
On Sun, Jan 27, 2019 at 05:43, Mark London <mr...@psfc.mit.edu> wrote:
> Does anyone have any rules that can catch this type of obfuscated spam?
>
> https://pastebin.com/qi8dsREW
>
> Thanks. - Mark
Re: Another form of obfuscation email.
Posted by John Hardin <jh...@impsec.org>.
On Sat, 26 Jan 2019, John Hardin wrote:
> On Sat, 26 Jan 2019, Mark London wrote:
>
>> Does anyone have any rules that can catch this type of obfuscated spam?
>>
>> https://pastebin.com/qi8dsREW
>
> There's some "invisible font" subrules in my sandbox that this hits
> (__STY_INVIS_MANY, __FONT_INVIS_MANY) but scored versions aren't currently
> exposed. I think when I was testing them I was amazed by the poor S/O - why
> would legitimate emails include invisible text?
>
> It may be that there is something they can be combined with to catch this.
>
> I'll take a look at the masscheck results soon and see if anything suggests
> itself.
Invisible styles seem to be really popular in ham for some reason. I've
added a meta with some no-ham hits, we'll see how it does.
Explicit multiple invisible fonts, on the other hand, are very rare in the
masscheck corpus, and are only spam. I've put this into my sandbox for
evaluation:
meta HTML_TEXT_INVISIBLE_FONT __FONT_INVIS_MANY
...but there may not be enough total corpus hits for masscheck to feel
worthy of publishing it, so you might want to make that a local rule with
whatever score you feel is appropriate.
--
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
-----------------------------------------------------------------------
...every time I sit down in front of a Windows machine I feel as
if the computer is just a place for the manufacturers to put their
advertising. -- fwadling on Y! SCOX
-----------------------------------------------------------------------
Today: Wolfgang Amadeus Mozart's 263rd Birthday
Re: Another form of obfuscation email.
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 27 Jan 2019, at 0:46, John Hardin wrote:
> why would legitimate emails include invisible text?
Probably the same reason legitimate emails for an almost exclusively US
audience (from "America's Text Kitchen") contain "Zero Width
Non-Joiners" both in plain text parts as UTF-8 characters and as named
entities in HTML parts, which makes no sense in any Latin-* script.
Email marketing technical experts are often ex-spammers who have brought
filter-evasion tricks with them into legit operations.
Re: Another form of obfuscation email.
Posted by John Hardin <jh...@impsec.org>.
On Sat, 26 Jan 2019, Mark London wrote:
> Does anyone have any rules that can catch this type of obfuscated spam?
>
> https://pastebin.com/qi8dsREW
There's some "invisible font" subrules in my sandbox that this hits
(__STY_INVIS_MANY, __FONT_INVIS_MANY) but scored versions aren't currently
exposed. I think when I was testing them I was amazed by the poor S/O -
why would legitimate emails include invisible text?
It may be that there is something they can be combined with to catch this.
I'll take a look at the masscheck results soon and see if anything
suggests itself.
If they do well against your Bayes but that's not sufficient to block
them, you could define local booster metas like:
meta LCL_SPAM_BOOST_123 BAYES_99 && __STY_INVIS_MANY
meta LCL_SPAM_BOOST_124 BAYES_99 && __FONT_INVIS_MANY
--
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
-----------------------------------------------------------------------
Tomorrow: the 52nd anniversary of the loss of Apollo 1