You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Daniel McDonald <da...@austinenergy.com> on 2011/03/29 00:44:45 UTC

Obfuscating advanced fee scams with html attachements?

I just got a spam that scored relatively low (mostly due to DNSWL_MED).  But
it also contained an html attachment that would have scored significantly
more had it been part of the main message.

I put it at http://pastebin.com/vXF0vGVS

When I run the complete message, I only get a few hits, mostly relating to
the headers:
X-Spam-Status: Yes, score=5.534 tagged_above=-99 required=4.5
    tests=[BOTNET_SOHO=-0.1, DEAR_FRIEND=2.604, FORGED_MUA_OUTLOOK=2.785,
    L_P0F_Linux=1, NSL_RCVD_FROM_USER=1.226, RCVD_IN_DNSWL_MED=-2.3,
    RCVD_IN_LBBL_RELAY=0.3, RELAY_US=0.01, SPF_PASS=-0.001,
    T_OBFU_HTML_ATTACH=0.01] autolearn=disabled

When I run just the attachment through spamassassin, I get the usual
advanced fee hits (and the ³no headers² hits, since it isn¹t an email at
that point...):
X-Spam-Report: 
    *  0.0 HK_SCAM_N2 BODY: HK_SCAM_N2
    *  0.2 FH_FROMEML_NOTLD E-mail address doesn't have TLD (.com, etc.)
    * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
    *  1.2 MISSING_HEADERS Missing To: header
    *  0.1 MISSING_MID Missing Message-Id: header
    *  1.8 MISSING_SUBJECT Missing Subject: header
    *  0.0 LOTS_OF_MONEY Huge... sums of money
    *  0.0 T_HK_NAME_MR_MRS T_HK_NAME_MR_MRS
    * -0.0 NO_RECEIVED Informational: message has no Received headers
    *  1.4 MISSING_DATE Missing Date: header
    *  3.1 RISK_FREE No risk
    *  0.4 TO_NO_BRKTS_PCNT To: misformatted + percentage
    *  1.5 ADVANCE_FEE_4_NEW Appears to be advance fee fraud (Nigerian 419)
    *  2.4 ADVANCE_FEE_5_NEW Appears to be advance fee fraud (Nigerian 419)
    *  0.0 NO_HEADERS_MESSAGE Message appears to be missing most RFC-822
    *      headers
    *  0.5 ADVANCE_FEE_3_NEW Appears to be advance fee fraud (Nigerian 419)
    *  0.0 T_MONEY_PERCENT X% of a lot of money for you
    *  0.5 ADVANCE_FEE_2_NEW_MONEY Advance Fee fraud and lots of money
    *  1.0 ADVANCE_FEE_3_NEW_MONEY Advance Fee fraud and lots of money
    *  1.0 MONEY_FRAUD_5 Lots of money and many fraud phrases
    *  1.5 MONEY_FRAUD_8 Lots of money and very many fraud phrases
    *  0.5 MONEY_FRAUD_3 Lots of money and several fraud phrases

Any suggestions for improving the detection of this new variant?  I¹ll toss
it in my nightly MC directory as well...


-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281


Re: Obfuscating advanced fee scams with html attachements?

Posted by da...@chaosreigns.com.
On 03/28, Daniel McDonald wrote:
>    I just got a spam that scored relatively low (mostly due to DNSWL_MED).

Was that because you don't have trusted_networks properly configured?

What was the IP address that got looked up in DNSWL?

>    I put it at [1]http://pastebin.com/vXF0vGVS

Was it 216.82.242.115 (mail132.messagelabs.com)?  Are you getting your
email relayed through messagelabs?  That IP has a rank of MED.  And if
you're getting your mail relayed through them, that IP should be listed in
your trusted_networks, which would result in 216.166.12.31
(out001.collaborationhost.net) being looked up in DNSWL, which has a rank
of NONE.


Also... if that's the case, why are you using both messagelabs and
spamassassin?

-- 
"...extremism in the defense of liberty is no vice"
- Barry Morris Goldwater
http://www.ChaosReigns.com

Re: Obfuscating advanced fee scams with html attachements?

Posted by John Hardin <jh...@impsec.org>.
On Mon, 28 Mar 2011, David B Funk wrote:

> A while back I tried creating some rules that explicitly looked for messages 
> with that perverted mime labeling but they FP'ed all over the place as there 
> are multiple ham sources that make the same faux-pas.

There are several subrules in that vein in my sandbox. They can be useful 
in metas.

Dan, take a look at the textcat plugin. Spammers do the same thing with 
RTF, .doc and PDF attachments.

-- 
  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
-----------------------------------------------------------------------
   A well educated Electorate, being necessary to the liberty of a
   free State, the Right of the People to Keep and Read Books,
   shall not be infringed.
-----------------------------------------------------------------------
  Tomorrow: the M1911 is 100 years old - and still going strong!

Re: Obfuscating advanced fee scams with html attachements?

Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 28 Mar 2011, Daniel McDonald wrote:

> I just got a spam that scored relatively low (mostly due to DNSWL_MED).  But
> it also contained an html attachment that would have scored significantly
> more had it been part of the main message.
>
> I put it at http://pastebin.com/vXF0vGVS
>
> When I run the complete message, I only get a few hits, mostly relating to
> the headers:
> X-Spam-Status: Yes, score=5.534 tagged_above=-99 required=4.5
>    tests=[BOTNET_SOHO=-0.1, DEAR_FRIEND=2.604, FORGED_MUA_OUTLOOK=2.785,
>    L_P0F_Linux=1, NSL_RCVD_FROM_USER=1.226, RCVD_IN_DNSWL_MED=-2.3,
>    RCVD_IN_LBBL_RELAY=0.3, RELAY_US=0.01, SPF_PASS=-0.001,
>    T_OBFU_HTML_ATTACH=0.01] autolearn=disabled
>
> When I run just the attachment through spamassassin, I get the usual
> advanced fee hits (and the ³no headers² hits, since it isn¹t an email at
> that point...):
> X-Spam-Report:
[snip..]
>

problem with that critter is that "payload" attachment is mime-typed
"application/octet-stream" and by default the Spamassassin engine only
auto-magically parses attachments that it recognises as textural.
So SA just completely ignores that attachment, considers it binary.

That spam depends upon common MUAs doing the windows trick of keying
off the extension of the file name for type recognition.
(IE: filname="blah.htlm")

So do we modify SA to do as the devil does and assume that:
  'Content-Type: application/octet-stream; name="Details.html"'

should be processed in the same way as the proper mime label:
  'Content-Type: text/html; name="Details.html"'

A while back I tried creating some rules that explicitly looked for 
messages with that perverted mime labeling but they FP'ed all over the 
place as there are multiple ham sources that make the same faux-pas.

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

MessageLabs outbound mail (was Re: Obfuscating advanced fee scams with html attachements?)

Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Tue, 29 Mar 2011 10:26:15 -0400
Jason Bertoch <ja...@i6ix.com> wrote:

> Apparently, messagelabs has something broken and/or the DNSWL
> listing needs adjustment.

Yes, some of MessageLabs' customers seem to be spamming or (more
likely) compromised:

$ reputation-check 216.82.242.115
216.82.242.115: mail132.messagelabs.com
        Mixed
        hs=403 hh=32 as=2353 ah=5394 vr=7828 ir=3922

Our reputation system has reports of 403 hand-marked spam messages
from that machine and 32 hand-marked ham.  Also, 2353 auto-spam and
5394 auto-ham as well as 3922 invalid recipients.  So it's on our
"Mixed" reputation list.

Regards,

David.

Re: Obfuscating advanced fee scams with html attachements?

Posted by Jason Bertoch <ja...@i6ix.com>.
On 2011/03/29 1:41 AM, Ned Slider wrote:
> On 28/03/11 23:44, Daniel McDonald wrote:
>> I just got a spam that scored relatively low (mostly due to
>> DNSWL_MED).

It looks like I've been getting these as well, with all being relayed 
through messagelabs.  Apparently, messagelabs has something broken 
and/or the DNSWL listing needs adjustment.  However, they are being 
caught here by SaneSecurity sigs in clamav.

>
>>      NSL_RCVD_FROM_USER=1.226,
>
>
> Personally I score this rule way up and would have no hesitation with
> outright blocking at smtp level - it's as good an indication of spam as
> I've ever seen. Scoring at 6pts here and never seen a FP.

My logs agree.  The only messages this rule hit on which were under my 
reject threshold of 10 have been this series and is due to the DNSWL 
listing.  I'll be bumping up the score to avoid the DNSWL/messagelabs 
error and ensure a Bayes autolearn.  Thanks for pointing it out!

-- 
/Jason

Re: Obfuscating advanced fee scams with html attachements?

Posted by da...@chaosreigns.com.
On 03/29, Ned Slider wrote:
> >This is a good illustration of our corpus not being strong enough; the

This means we need more people participating in mass-checks.

> Quickly grepping one of my corpus of 1307 spam I see 379 hits
> (~29%). I've never seen it hit a ham. This is on a corpus of
> confirmed spam collected after the easy stuff (bots etc) has been
> pre-filtered (greylisting, spamhaus, RBLs etc). FORGED_MUA_OUTLOOK

http://wiki.apache.org/spamassassin/NightlyMassCheck

-- 
"Democracy is the theory that the common people know what they want,
and deserve to get it good and hard." - H. L. Mencken
http://www.ChaosReigns.com

Re: Obfuscating advanced fee scams with html attachements?

Posted by Ned Slider <ne...@unixmail.co.uk>.
On 29/03/11 16:38, Adam Katz wrote:
> On 03/28/2011 10:41 PM, Ned Slider wrote:
>>> NSL_RCVD_FROM_USER=1.226,
>>
>> Personally I score this rule way up and would have no hesitation
>> with outright blocking at smtp level - it's as good an indication of
>> spam as I've ever seen. Scoring at 6pts here and never seen a FP.
>
> This is a good illustration of our corpus not being strong enough; the
> current stats make that rule look useless since its lowest-scoring match
> is seven points and it hits 0.0278% of all spam<  10 points.
> Furthermore, it has 99% overlap with FORGED_MUA_OUTLOOK, which hits far
> more spam while maintaining a very low ham hit rate.
>
> http://ruleqa.spamassassin.org/20110321/NSL_RCVD_FROM_USER/detail
>

Quickly grepping one of my corpus of 1307 spam I see 379 hits (~29%). 
I've never seen it hit a ham. This is on a corpus of confirmed spam 
collected after the easy stuff (bots etc) has been pre-filtered 
(greylisting, spamhaus, RBLs etc). FORGED_MUA_OUTLOOK hits 39% on the 
same corpus.

I've watched the scoring over time and it does seem to fluctuate 
significantly (~ 1.2 to 3.5), I guess as old spam gets removed from the 
auto-scoring corpus and new spam enters, so the score fluctuates with 
the type of spam being seen. That said, it's still a hugely reliable rule.



Re: Obfuscating advanced fee scams with html attachements?

Posted by Adam Katz <an...@khopis.com>.
On 03/28/2011 10:41 PM, Ned Slider wrote:
>> NSL_RCVD_FROM_USER=1.226,
> 
> Personally I score this rule way up and would have no hesitation
> with outright blocking at smtp level - it's as good an indication of
> spam as I've ever seen. Scoring at 6pts here and never seen a FP.

This is a good illustration of our corpus not being strong enough; the
current stats make that rule look useless since its lowest-scoring match
is seven points and it hits 0.0278% of all spam < 10 points.
Furthermore, it has 99% overlap with FORGED_MUA_OUTLOOK, which hits far
more spam while maintaining a very low ham hit rate.

http://ruleqa.spamassassin.org/20110321/NSL_RCVD_FROM_USER/detail


Re: Obfuscating advanced fee scams with html attachements?

Posted by Ned Slider <ne...@unixmail.co.uk>.
On 28/03/11 23:44, Daniel McDonald wrote:
> I just got a spam that scored relatively low (mostly due to DNSWL_MED).  But
> it also contained an html attachment that would have scored significantly
> more had it been part of the main message.
>
> I put it at http://pastebin.com/vXF0vGVS
>
> When I run the complete message, I only get a few hits, mostly relating to
> the headers:
> X-Spam-Status: Yes, score=5.534 tagged_above=-99 required=4.5

<snip>

>      NSL_RCVD_FROM_USER=1.226,


Personally I score this rule way up and would have no hesitation with 
outright blocking at smtp level - it's as good an indication of spam as 
I've ever seen. Scoring at 6pts here and never seen a FP.