Re:: 9D character used in words to avoid detection

[John Hardin]

On Sat, 17 Nov 2018, Mark London wrote:


 Forwarded Message 
Subject:[OFF-list] 9D character used in words to avoid detection
Date:   Sat, 17 Nov 2018 15:42:08 -0600
To: Mark London 


Mark, could you post a full spample to the SA list?


Erm, thanks, but it's much preferable to upload the raw spample to 
someplace like pastebin and just post the link here. That way (1) the 
spample doesn't get quarantined or discarded from content scanning, and 
(2) the spample doesn't get modified in transit.



Thanks in advance!
"Chip" M.

---


{snip}


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  There is no doubt in my mind that millions of lives could have been
  saved if the people were not "brainwashed" about gun ownership and
  had been well armed. ... Gun haters always want to forget the Warsaw
  Ghetto uprising, which is a perfect example of how a ragtag,
  half-starved group of Jews took 10 handguns and made asses out of
  the Nazis.-- Theodore Haas, Dachau survivor
---
 597 days since the first commercial re-flight of an orbital booster (SpaceX)

Re:: 9D character used in words to avoid detection

[Mark London]

 Forwarded Message 
Subject:[OFF-list] 9D character used in words to avoid detection
Date:   Sat, 17 Nov 2018 15:42:08 -0600
From:   Chip M. 
To: Mark London 


Mark, could you post a full spample to the SA list?
Thanks in advance!
"Chip" M.

---

Received: from NAM03-DM3-obe.outbound.protection.outlook.com 
(mail-oln040092008054.outbound.protection.outlook.com [40.92.8.54])
by PSFCMAIL.MIT.EDU (8.14.7/8.14.7) with ESMTP id wAGJEjso151029
(version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT)
for ; Fri, 16 Nov 2018 14:14:45 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Kceh3OoQuqn81EZa8vu4iMVNv3cq+/11xZqOTWGejmA=;
 
b=SmqjOWOZhH0WPpxl0tW8hR8y/iinBa5jpTYudap6390QzWXLc4TU0iPuaChiq3kivXtpxSBJAnVrDi1HCJm1ifFGvmIqITyB4am/vUuwDDtm+e8hLy1ONvsEa8O9tLdmzs10x6T/6nsWadsB9QCiJ39ugpj4V5sBvb5vGaaRNjQCwqO+GcqYmnZbMzR2Sp1U2Ah63P9bHiK2jiBf/g1T5aOsrLpfypPTdltzTbYLs3E76Nt4swZwDlMond9FJITY574G/HBghrql3nZEKlGGPGI2J8qUiiVPn5/cMCyOLrR0qqd217oU82Cuner5kPWE9iEcprvXxJIAt6gOYPKzDg==
Received: from BY2NAM03FT047.eop-NAM03.prod.protection.outlook.com
 (10.152.84.58) by BY2NAM03HT089.eop-NAM03.prod.protection.outlook.com
 (10.152.84.169) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10; Fri, 16 Nov
 2018 19:14:44 +
Received: from MWHPR14MB1327.namprd14.prod.outlook.com (10.152.84.53) by
 BY2NAM03FT047.mail.protection.outlook.com (10.152.85.103) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
 15.20.1339.10 via Frontend Transport; Fri, 16 Nov 2018 19:14:44 +
Received: from MWHPR14MB1327.namprd14.prod.outlook.com
 ([fe80::f4ae:395a:3f6b:67a3]) by MWHPR14MB1327.namprd14.prod.outlook.com
 ([fe80::f4ae:395a:3f6b:67a3%8]) with mapi id 15.20.1339.021; Fri, 16 Nov 2018
 19:14:44 +
From: Kenton Chmura 
To: "m...@psfc.mit.edu" 
Subject: mrl
Date: Fri, 16 Nov 2018 19:14:44 +
Message-ID: 


--_000_MWHPR14MB13279093501A88B114707EE3B0DD0MWHPR14MB1327namp_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

Hi=9D the=9Dre

I'm the=9D ha=9Dcke=9Dr who=9D bro=9Dke=9D yo=9Du=9Dr ema=9Di=9Dl a=9Dddre=
=9Dss a=9Dnd de=9Dvi=9Dce=9D a=9D se=9Dve=9Dra=9Dl we=9De=9Dks ba=9Dck.

Yo=9Du=9D type=9Dd i=9Dn yo=9Du=9Dr pwd o=9Dn one of the si=9Dte=9Ds yo=9Du=
=9D vi=9Dsite=9Dd, a=9Dnd I inte=9Drce=9Dpted it.

He=9Dre=9D i=9Ds the=9D se=9Dcu=9Dri=9Dty pa=9Dsswo=9Drd o=9Df m...@psfc.mit=
.edu upo=9Dn mo=9Dme=9Dnt of ha=9Dck: xxx

Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt, o=9Dr a=9Dlready c=
hange=9Dd it.

The=9Dn again thi=9Ds wo=9Dn't really ma=9Dke a=9D di=9Dffe=9Drence=9D, my =
ma=9Dli=9Dcio=9Du=9Ds so=9Dftwa=9Dre=9D u=9Dpda=9Dte=9Dd i=9Dt e=9Da=9Dch a=
=9Dnd e=9Dvery ti=9Dme.

Do=9D no=9Dt co=9Dnsi=9Dder to=9D ma=9Dke=9D co=9Dntact with me=9D pe=9Drso=
nally o=9Dr fi=9Dnd me=9D.

Via=9D yo=9Du=9Dr e=9D-ma=9Di=9Dl, I uplo=9Da=9Dde=9Dd malwa=9Dre=9D co=9Dm=
pute=9Dr co=9Dde to yo=9Dur Ope=9Dra=9Dtion Syste=9Dm.

I sa=9Dved all yo=9Du=9Dr co=9Dnta=9Dcts wi=9Dth bu=9Dddie=9Ds, fello=9Dw w=
o=9Drke=9Drs, fa=9Dmi=9Dly me=9Dmbers and a fu=9Dll hi=9Dsto=9Dry of vi=9Ds=
i=9Dts to the=9D Online re=9Dso=9Du=9Drce=9Ds.

As well I i=9Dnsta=9Dlle=9Dd a=9D Vi=9Dru=9Ds o=9Dn yo=9Du=9Dr de=9Dvi=9Dce=
=9D.

You=9D aren't my only victim, I typi=9Dca=9Dlly lo=9Dck pcs and a=9Dsk fo=
=9Dr the=9D ra=9Dnso=9Dm.

No=9Dne=9Dthe=9Dle=9Dss I wa=9Ds stru=9Dck thro=9Du=9Dgh the=9D si=9Dtes o=
=9Df pa=9Dssi=9Do=9Dna=9Dte co=9Dnte=9Dnt ma=9Dte=9Dri=9Da=9Dl tha=9Dt you=
=9D o=9Dften ta=9Dke a lo=9Dok at.

I am i=9Dn i=9Dmpa=9Dct of you=9Dr cu=9Drre=9Dnt fantasi=9De=9Ds! I've neve=
r seen a=9Dnythi=9Dng li=9Dke=9D this!

The=9Drefore=9D, whe=9Dn yo=9Du=9D ha=9Dd e=9Dnjo=9Dyme=9Dnt o=9Dn piquant =
websi=9Dtes (yo=9Du know wha=9Dt I a=9Dm talki=9Dng abo=9Du=9Dt!) I ma=9Dde=
 scre=9De=9Dnsho=9Dt wi=9Dth u=9Dsi=9Dng my pro=9Dgra=9Dm via=9D yo=9Dur ca=
me=9Dra=9D o=9Df yo=9Du=9Drs de=9Dvi=9Dce=9D.

And the=9Dn, I pu=9Dt toge=9Dthe=9Dr the=9Dm to=9D the=9D conte=9Dnt of the=
=9D cu=9Drre=9Dntly se=9De=9Dn we=9Dbsi=9Dte.

No=9Dw there=9D is go=9Di=9Dng to=9D be=9D giggli=9Dng whe=9Dn I se=9Dnd th=
e=9Dse=9D pi=9Dctu=9Dres to yo=9Du=9Dr co=9Dnnecti=9Do=9Dns!

Ho=9Dweve=9Dr I am su=9Dre yo=9Du do=9Dn't ne=9De=9Dd i=9Dt.

Thus, I e=9Dxpe=9Dct pa=9Dyme=9Dnt fro=9Dm yo=9Du=9D wi=9Dth re=9Dga=9Drd t=
o=9D my qu=9Di=9De=9Dt.

I co=9Dnside=9Dr $40=9D0=9D0=9D (fou=9Dr tho=9Du=9Dsa=9Dnd dolla=9Drs) i=9D=
s a=9Dn a=9Dppro=9Dpri=9Da=9Dte=9D co=9Dst fo=9Dr it!

Pay wi=9Dth Bi=9Dtcoi=9Dn.

My BT=9DC wallet i=9Ds 1GJJ5fsfLVMJiSqTh6nWAd5riDg8xmizB2

In ca=9Dse=9D you=9D do=9D no=9Dt know ho=9Dw to do=9D thi=9Ds - e=9Dnte=9D=
r in to Goo=9Dgle=9D 'ho=9Dw to=9D tra=9Dnsfe=9Dr mo=9Dne=9Dy to=9D the bi=

Re: 9D character used in words to avoid detection.

[Mark London]

John & Kevin - Thanks for the rules!   This tactic was used in a porn 
blackmail spam.   Considering that we are currently are receiving a 
large amount of those types of spams, it might be possible that this 
tactic might catch on.   Or not!   We'll see. - Mark


On 11/17/2018 8:23 AM, users-digest-h...@spamassassin.apache.org wrote:

To:
John Hardin 
CC:
SA Mailing list 


Yeah, there is a SCC SHORT WORDS rule and a KAM_ZWNJ in KAM.cf.  
Please let me know if those help.

--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Fri, Nov 16, 2018 at 7:37 PM John Hardin > wrote:


On Fri, 16 Nov 2018, Mark London wrote:

> I just received a spam email with the 9D character placed inside
of words,
> that prevented my custom BODY rules from being hit. I.e.:
>
> Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt, o=9Dr
a=9Dlready
> change=9Dd it.
>
> Is there a way to define BODY rules, so that they will be
triggered?
> Thanks.

No, that would be way too much work; take a look at
__UNICODE_OBFU_ZW in
my sandbox. It isn't performing well in masschecks so I expect
this tactic
isn't widespread (yet?)

I suppose I should expose it as scored in case it becomes popular...

Re: Forgery with SPF/DKIM/DMARC

[John Hardin]

On Sat, 17 Nov 2018, David Jones wrote:


On 11/17/18 9:52 AM, John Hardin wrote:

From: John D. Smith  
To: kdeu...@vianet.ca
Message-ID: <35706717752563516902.8f4660866aa84...@vianet.ca>

Couple of things:
1. Recent discussions on this mailing list showed me that the Message-ID
should never have the recipient's domain in it


That's not 100% true.

There is no requirement that the sender put a Message-ID on the message.
It is valid for your MTA to add a Message-ID onto a message that was
received without one. That is likely going to be done using your domain.



Sure.  Real MTA/MUA's should be setting a Message-ID header else it will
look very spammy.  Copiers, scanners, and other basic SMTP-enabled
devices often don't put all of the "standard" headers in their messages
so they have to be whitelisted safely.

My Postfix MTA doesn't add the Message-ID header and even if it did, it
would be something like "ena.net" that is not going to match the dozens
of domains that I filter.


Yeah, in your case it's probably safe to do in SA.


This strategy seems to have helped stop this type of spam so far without
over blocking.


I'd suggest a filter on Message-ID domain would be more appropriate at
the MTA level than in SA - if a message is received from outside with a
Message-ID having a domain that you control, reject it at that point,
before the possibility of adding a local one because it's missing
becomes a source of ambiguity.


I am using MailScanner so that is a drawback not being able to reject
during the SMTP conversation.


I don't consider MailScanner to be "at the MTA level". I'm not familiar 
with PostScript but I'm sure there's a way to configure it to do a check 
like that during the SMTP conversation before any external 
message-processing tools are called.



I do try to reject as much as I can at
the MTA so MailScanner and SA only have to block the tough ones.  Most
spam scores above 30 which is not going to be missed by anyone (not
something they are expecting to receive).


I do something similar with HELO. You might want to look into that too -
check your logs for the HELOs that spammers are using, there are
low-hanging fruit there (that I'm reluctant to discuss publicly).


Interesting.  I may have to make some time over the holidays to research
this a bit more in my logs.  My mail filtering is pretty spot on right
now but if anything gets through I will check the HELO details.  Most of
the things that get through now are zero-hour messages from compromised
accounts so those HELO's are going to be good and everything else
(FCrDNS, SPF, DKIM, DMARC) will be legit and pass.  I am thinking of
increasing the time on greylisting to give DCC and RBLs time to catch up
with compromise accounts.


2. Seems like there should be easy rules to detect more than one pair of
angle brackets and more than on at sign to add points to non-standard
display names.


There probably are. A big question is: does that appear enough in the
masscheck corpora to be promoted as a useful rule?


I think my ena-week[0-4] (past 5 weeks) masscheckers are still the
majority of the overall masscheck corpora.  I need some help planting
email addresses out there that will attract more spam of differing types
or something.  I definitely need to get more non-English spam in there.


Heh. Rather than (or in addition to) reject at the MTA level you should be 
dumping them into your spam corpora (if you're not already doing that).


We also badly need non-English *ham*.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Usually Microsoft doesn't develop products, we buy products.
  -- Arno Edelmann, Microsoft product manager
---
 597 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Forgery with SPF/DKIM/DMARC

[David Jones]

On 11/17/18 9:52 AM, John Hardin wrote:
>> From: John D. Smith  
>> To: kdeu...@vianet.ca
>> Message-ID: <35706717752563516902.8f4660866aa84...@vianet.ca>
>>
>> Couple of things:
>> 1. Recent discussions on this mailing list showed me that the Message-ID
>> should never have the recipient's domain in it
> 
> That's not 100% true.
> 
> There is no requirement that the sender put a Message-ID on the message. 
> It is valid for your MTA to add a Message-ID onto a message that was 
> received without one. That is likely going to be done using your domain.
> 

Sure.  Real MTA/MUA's should be setting a Message-ID header else it will 
look very spammy.  Copiers, scanners, and other basic SMTP-enabled 
devices often don't put all of the "standard" headers in their messages 
so they have to be whitelisted safely.

My Postfix MTA doesn't add the Message-ID header and even if it did, it 
would be something like "ena.net" that is not going to match the dozens 
of domains that I filter.

This strategy seems to have helped stop this type of spam so far without 
over blocking.

> I'd suggest a filter on Message-ID domain would be more appropriate at 
> the MTA level than in SA - if a message is received from outside with a 
> Message-ID having a domain that you control, reject it at that point, 
> before the possibility of adding a local one because it's missing 
> becomes a source of ambiguity.
>
I am using MailScanner so that is a drawback not being able to reject 
during the SMTP conversation.  I do try to reject as much as I can at 
the MTA so MailScanner and SA only have to block the tough ones.  Most 
spam scores above 30 which is not going to be missed by anyone (not 
something they are expecting to receive).

> I do something similar with HELO. You might want to look into that too - 
> check your logs for the HELOs that spammers are using, there are 
> low-hanging fruit there (that I'm reluctant to discuss publicly).
> 

Interesting.  I may have to make some time over the holidays to research 
this a bit more in my logs.  My mail filtering is pretty spot on right 
now but if anything gets through I will check the HELO details.  Most of 
the things that get through now are zero-hour messages from compromised 
accounts so those HELO's are going to be good and everything else 
(FCrDNS, SPF, DKIM, DMARC) will be legit and pass.  I am thinking of 
increasing the time on greylisting to give DCC and RBLs time to catch up 
with compromise accounts.

>> 2. Seems like there should be easy rules to detect more than one pair of
>> angle brackets and more than on at sign to add points to non-standard
>> display names.
> 
> There probably are. A big question is: does that appear enough in the 
> masscheck corpora to be promoted as a useful rule?
> 

I think my ena-week[0-4] (past 5 weeks) masscheckers are still the 
majority of the overall masscheck corpora.  I need some help planting 
email addresses out there that will attract more spam of differing types 
or something.  I definitely need to get more non-English spam in there.

-- 
David Jones

Re: Forgery with SPF/DKIM/DMARC

[John Hardin]

On Sat, 17 Nov 2018, David Jones wrote:


On 11/16/18 7:44 AM, Robert Fitzpatrick wrote:

We're having an issue with spam coming from the same company even though
SPF and DKIM is setup with DMARC to reject. Take this forwarded email
for instances


 Original message  From: User  Date:
11/15/18 10:42 AM (GMT-07:00) To: Other User 
Subject: OVERDUE INVOICE
Sorry for the delay…. This is an invoice reminder. The total for your
item is $1,879.17.
THX,
-
User T 123.456.7890 | O 123.456.7891 EMail:u...@company.com


However, the raw headers show as this...


Date: Thu, 15 Nov 2018 18:35:35 +0100
From: User 

To: other.u...@company.com
Message-ID: <860909106225419267.2007038e08376...@company.com>
Subject: OVERDUE INVOICE


Could someone suggest a rule to match the signature with the last From
email or envelope from? Or another suggestion how this could be resolved.

Thanks!




From: John D. Smith  
To: kdeu...@vianet.ca
Message-ID: <35706717752563516902.8f4660866aa84...@vianet.ca>

Couple of things:
1. Recent discussions on this mailing list showed me that the Message-ID
should never have the recipient's domain in it


That's not 100% true.

There is no requirement that the sender put a Message-ID on the message. 
It is valid for your MTA to add a Message-ID onto a message that was 
received without one. That is likely going to be done using your domain.


I'd suggest a filter on Message-ID domain would be more appropriate at the 
MTA level than in SA - if a message is received from outside with a 
Message-ID having a domain that you control, reject it at that point, 
before the possibility of adding a local one because it's missing becomes 
a source of ambiguity.


I do something similar with HELO. You might want to look into that too - 
check your logs for the HELOs that spammers are using, there are 
low-hanging fruit there (that I'm reluctant to discuss publicly).



2. Seems like there should be easy rules to detect more than one pair of
angle brackets and more than on at sign to add points to non-standard
display names.


There probably are. A big question is: does that appear enough in the 
masscheck corpora to be promoted as a useful rule?



3. I add a point or two for invoice-related subjects just because I want
to lower the bar for them being caught.  Legit invoice senders should
have other good rules hit that will offset this.  I try to make legit
invoice senders score just below the block threshold so anything
suspicious like that From: or Message-ID: header will push it over the
limit.
You can setup logwatch or grep your mail logs often from cron to alert
you when your invoice-related rules are hit so you don't cause a problem
blocking a real invoice in the first month or two as you are tuning your
rules and scores.


Good suggestions.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
 Windows and its users got mentioned at home today, after my wife the
 psych major brought up Seligman's theory of "learned helplessness."
 -- Dan Birchall in a.s.r
---
 597 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Forgery with SPF/DKIM/DMARC

[David Jones]

On 11/16/18 7:44 AM, Robert Fitzpatrick wrote:
> We're having an issue with spam coming from the same company even though 
> SPF and DKIM is setup with DMARC to reject. Take this forwarded email 
> for instances
> 
>>  Original message  From: User  Date: 
>> 11/15/18 10:42 AM (GMT-07:00) To: Other User  
>> Subject: OVERDUE INVOICE
>> Sorry for the delay…. This is an invoice reminder. The total for your 
>> item is $1,879.17.
>> THX,
>> -
>> User T 123.456.7890 | O 123.456.7891 EMail:u...@company.com
> 
> However, the raw headers show as this...
> 
>> Date: Thu, 15 Nov 2018 18:35:35 +0100
>> From: User 
>> 
>> To: other.u...@company.com
>> Message-ID: <860909106225419267.2007038e08376...@company.com>
>> Subject: OVERDUE INVOICE
> 
> Could someone suggest a rule to match the signature with the last From 
> email or envelope from? Or another suggestion how this could be resolved.
> 
> Thanks!
> 


From: John D. Smith  
To: kdeu...@vianet.ca
Message-ID: <35706717752563516902.8f4660866aa84...@vianet.ca>

Couple of things:
1. Recent discussions on this mailing list showed me that the Message-ID 
should never have the recipient's domain in it so I setup a local meta 
rule to match all of my customer domains that I filter for with an 
inbound rule (like ALL_TRUSTED) to add a bunch of points.
2. Seems like there should be easy rules to detect more than one pair of 
angle brackets and more than on at sign to add points to non-standard 
display names.
3. I add a point or two for invoice-related subjects just because I want 
to lower the bar for them being caught.  Legit invoice senders should 
have other good rules hit that will offset this.  I try to make legit 
invoice senders score just below the block threshold so anything 
suspicious like that From: or Message-ID: header will push it over the 
limit.
You can setup logwatch or grep your mail logs often from cron to alert 
you when your invoice-related rules are hit so you don't cause a problem 
blocking a real invoice in the first month or two as you are tuning your 
rules and scores.

-- 
David Jones

Re: Forgery with SPF/DKIM/DMARC

[Matus UHLAR - fantomas]

On 16.11.18 08:44, Robert Fitzpatrick wrote:
We're having an issue with spam coming from the same company even 
though SPF and DKIM is setup with DMARC to reject. Take this forwarded 
email for instances


does the mail pass or fail SPF and DKIM?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete

Re: unexpected FN, how to improve/tune to catch

[Matus UHLAR - fantomas]

On 15.11.18 09:42, Ian Zimmerman wrote:
>  # This one disables Bayes.  ...
> tiny detail. use_learner 0



On Fri, 16 Nov 2018 09:52:05 +0100 Matus UHLAR - fantomas wrote:

1. this description is invalid. use_bayes disables bayes.


On 16.11.18 14:13, RW wrote:

use_learner 0, in theory, disables all machine learning plug-ins.


I would prefer a more thorough explanation, can you please provide it?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
LSD will make your ECS screen display 16.7 million colors