Re: Bitcoin update

2018-10-08 Thread John Hardin

On Mon, 8 Oct 2018, Zinski, Steve wrote:


   > The trouble with this is that you would be adding 10 point to anything
   > with a bitcoin address whether anything's obfuscated or not. If you want
   > to avoid this take a look at the FUZZY_* rules.

Well, actually, no. I sent you a snippet of my rule and inflated the score to 
10 for those of you who wanted to detect emails with obfuscated (Unicode) 
bitcoin addresses within.


The point was, __BTC4 will hit on non-obfuscated "bitcoin", so the meta 
should hit on any email with clear "bitcoin" and a bitcoin ID.


I recommend this:

  body__BTC4 
/\bb(?!itcoin)[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i

...to rule that out.


I use the following rules to block the sextortion emails that are so rampant 
right now. As you can see, it assigns a 0.1 score to the bitcoin portion, then 
the following rule uses that to test for sextortion emails (also obfuscated 
with Unicode characters). These two rules work great for me in stopping the 
vast majority of sextortion emails coming to our campus.

body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
body__BTC4  /\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
score   LOCAL_BITCOIN   0.1

body__UCporn/\b\W*p\W*o\W*r\W*n\W*\b/
body__UCpixel   /\b\W*p\W*i\W*x\W*e\W*l\W*\b/
body__UCvideos  /\b\W*v\W*i\W*d\W*(e\W*o\W*)?(s)?\W*\b/
body__UCwebcam  /\b\W*(w\W*e\W*b\W*)?c\W*a\W*m\W*(e\W*r\W*a)?\W*\b/
body__UCkeylogger   /\b\W*k\W*e\W*y\W*l\W*o\W*g\W*g\W*e\W*r\W*\b/
body__UCviruses /\b\W*v\W*i\W*r\W*u\W*s\W*(e\W*s)?\W*\b/
body__UCmalware /\b\W*m\W*a\W*l\W*w\W*a\W*r\W*e\W*\b/
body__UCtrojan  /\b\W*t\W*r\W*o\W*j\W*a\W*n\W*\b/
body__UCrecording   /\b\W*r\W*e\W*c\W*o\W*r\W*d\W*i\W*n\W*g\W*\b/
body__UChacked  /\b\W*h\W*a\W*c\W*k\W*e\W*d\W*\b/
metaLOCAL_SEXTORTION ( LOCAL_BITCOIN && ( __UCporn || __UCpixel || __UCvideos 
|| __UCwebcam) && ( __UCkeylogger || __UCviruses || __UCmalware || __UCtrojan || 
__UCrecording || __UChacked ) )
score   LOCAL_SEXTORTION20.0

The gist of the SEXTORTION rule is the email must contain a bitcoin address AND 
(porn or pixel or video/videos or webcam/camera/cam) AND (keylogger or 
virus/viruses or malware or trojan or recording or hacked). Every sextortion 
email that I've seen contains those words.

It's not pretty, but it works (until the scammers change tactics).


It's also a bit dangerous. "*" in a body rule opens you to DoS attacks.

I recommend   \W{0,10}instead of   \W*  to reduce that exposure.

Also, it's a bit more efficient to not use capturing parens if you're not 
going to do anything with the match:


   /\b\W*(?:w\W*e\W*b\W*)?c\W*a\W*m\W*(?:e\W*r\W*a)?\W*\b/


--
 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
---
  Politicians never accuse you of "greed" for wanting other people's
  money, only for wanting to keep your own money.-- Joseph Sobran
---
 557 days since the first commercial re-flight of an orbital booster (SpaceX)


Re: Bitcoin update

2018-10-07 Thread Zinski, Steve
> The trouble with this is that you would be adding 10 point to anything
> with a bitcoin address whether anything's obfuscated or not. If you want
> to avoid this take a look at the FUZZY_* rules.


Well, actually, no. I sent you a snippet of my rule and inflated the score to 
10 for those of you who wanted to detect emails with obfuscated (Unicode) 
bitcoin addresses within.

I use the following rules to block the sextortion emails that are so rampant 
right now. As you can see, it assigns a 0.1 score to the bitcoin portion, then 
the following rule uses that to test for sextortion emails (also obfuscated 
with Unicode characters). These two rules work great for me in stopping the 
vast majority of sextortion emails coming to our campus.

body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
body__BTC4  /\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
score   LOCAL_BITCOIN   0.1

body__UCporn/\b\W*p\W*o\W*r\W*n\W*\b/
body__UCpixel   /\b\W*p\W*i\W*x\W*e\W*l\W*\b/
body__UCvideos  /\b\W*v\W*i\W*d\W*(e\W*o\W*)?(s)?\W*\b/
body__UCwebcam  /\b\W*(w\W*e\W*b\W*)?c\W*a\W*m\W*(e\W*r\W*a)?\W*\b/
body__UCkeylogger   /\b\W*k\W*e\W*y\W*l\W*o\W*g\W*g\W*e\W*r\W*\b/
body__UCviruses /\b\W*v\W*i\W*r\W*u\W*s\W*(e\W*s)?\W*\b/
body__UCmalware /\b\W*m\W*a\W*l\W*w\W*a\W*r\W*e\W*\b/
body__UCtrojan  /\b\W*t\W*r\W*o\W*j\W*a\W*n\W*\b/
body__UCrecording   /\b\W*r\W*e\W*c\W*o\W*r\W*d\W*i\W*n\W*g\W*\b/
body__UChacked  /\b\W*h\W*a\W*c\W*k\W*e\W*d\W*\b/
metaLOCAL_SEXTORTION ( LOCAL_BITCOIN && ( __UCporn || __UCpixel || 
__UCvideos || __UCwebcam) && ( __UCkeylogger || __UCviruses || __UCmalware || 
__UCtrojan || __UCrecording || __UChacked ) )
score   LOCAL_SEXTORTION20.0

The gist of the SEXTORTION rule is the email must contain a bitcoin address AND 
(porn or pixel or video/videos or webcam/camera/cam) AND (keylogger or 
virus/viruses or malware or trojan or recording or hacked). Every sextortion 
email that I've seen contains those words.

It's not pretty, but it works (until the scammers change tactics).
 
 



Re: Bitcoin update

2018-10-06 Thread John Hardin

On Sat, 6 Oct 2018, Pedro David Marco wrote:


   On Saturday, October 6, 2018, 8:36:11 PM GMT+2, John Hardin 
 wrote:


The version of this in my sandbox doesn't have that weakness. I did some  
tuning compared to what Steve proposed.


John, would it be possible for you to share with us those improvments???

Thanks,


They are checked into my sandbox and are publicly visible.

https://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/jhardin/

I'd recommend against implementing them locally right now. I still have 
some more tuning changes in mind after I review the masscheck results, and 
if they perform at all well in masscheck they'd be published as part of 
the base ruleset.


--
 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
---
  If the rock of doom requires a gentle nudge away from Gaia to
  prevent a very bad day for Earthlings, NASA won’t be riding to the
  rescue. These days, NASA does dodgy weather research and outreach
  programs, not stuff in actual space with rockets piloted by
  flinty-eyed men called Buzz.   -- Daily Bayonet
---
 555 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Bitcoin update

2018-10-06 Thread Pedro David Marco
 

On Saturday, October 6, 2018, 8:36:11 PM GMT+2, John Hardin 
 wrote:  
 
>The version of this in my sandbox doesn't have that weakness. I did some  
>tuning compared to what Steve proposed.


John, would it be possible for you to share with us those improvments???

Thanks,

PedroD  

Re: Bitcoin update

2018-10-06 Thread John Hardin

On Sat, 6 Oct 2018, RW wrote:


On Fri, 5 Oct 2018 16:34:51 +
Zinski, Steve wrote:


Here's how I'm blocking bitcoin emails with Unicode characters
embedded:

body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
body
__BTC4  /\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
score   LOCAL_BITCOIN   10.0

Works like a charm in my environment.


The trouble with this is that you would be adding 10 point to anything
with a bitcoin address whether anything's obfuscated or not. If you want
to avoid this take a look at the FUZZY_* rules.


The version of this in my sandbox doesn't have that weakness. I did some 
tuning compared to what Steve proposed.


BTW, Steve, your emails appear to be going to the list multiple times (or 
is that just me?)



--
 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
---
  Show me somebody who waxes poetic about "Being at one with Nature"
  and I'll show you someone who hasn't figured out that Nature is an
  infinite stomach demanding to be fed. -- Atomic, at Wapsi forum
---
 555 days since the first commercial re-flight of an orbital booster (SpaceX)


Re: Bitcoin update

2018-10-06 Thread RW
On Fri, 5 Oct 2018 16:34:51 +
Zinski, Steve wrote:

> Here's how I'm blocking bitcoin emails with Unicode characters
> embedded:
> 
> body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
> body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
> body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
> body
> __BTC4  /\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
> metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
> score   LOCAL_BITCOIN   10.0
> 
> Works like a charm in my environment.

The trouble with this is that you would be adding 10 point to anything
with a bitcoin address whether anything's obfuscated or not. If you want
to avoid this take a look at the FUZZY_* rules. 




Re: Bitcoin update

2018-10-06 Thread Rupert Gallagher
You did well. Not perfect, but nearly there.

The key words here are: dynamic, helo, from and to. No need to use a black list.

The message was sent from a dynamic IP. No reputable email server does that.

The next reason to reject is the failure of SPF. The recipient should implement 
SPF correctly.

The third reason is the Message-ID.

RG

On Fri, Oct 5, 2018 at 23:57, David Jones  wrote:

> On 10/5/18 4:38 PM, Antony Stone wrote:
>> On Friday 05 October 2018 at 23:26:12, Rupert Gallagher wrote:
>>
 https://pastebin.com/TRD7FzRQ

 I have a sample here
>>>
>>> There are at least three reasons to reject that e-mail upfront, with no
>>> need to parse its body.
>>
>> Hints might be appreciated for the uninitiated.
>>
>>
>> Antony.
>>
>>
>> PS: Please do NOT set Reply-To to your own address on list postings.
>>
>
> Are you doing any RBLs at the MTA? This thing looks really bad and
> would never have made it past my Postfix postscreen_dnsbl_sites list.
>
> http://multirbl.valli.org/lookup/114.46.223.46.html
>
> If it had made it to SpamAssassin, here's what my rules would have scored:
>
> Content analysis details: (29.8 points, 5.0 required)
>
> pts rule name description
>  --
> --
> 5.2 BAYES_99 BODY: Bayes spam probability is 99 to 100%
> [score: 1.]
> 3.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
> [score: 1.]
> 0.5 FROM_DOMAIN_NOVOWEL From: domain has series of non-vowel letters
> 1.5 CK_HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname
> (Split IP)
> 0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or
> Generic rPTR
> 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date
> 3.2 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net)
> 0.1 FROM_EQUALS_TO From: and To: have the same username
> 0.0 KHOP_DYNAMIC Relay looks like a dynamic address
> 3.6 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr
> 2)
> 1.0 RDNS_DYNAMIC Delivered to internal network by host with
> dynamic-looking rDNS
> 2.2 ENA_RELAY_NOT_US Relayed from outside the US and not on
> whitelists
> 0.1 HDR_ORDER_FTSDMCXX_DIRECT Header order similar to spam
> (FTSDMCXX/boundary variant) + direct-to-MX
> 2.0 MIMEOLE_DIRECT_TO_MX MIMEOLE + direct-to-MX
> 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers
> 2.5 NO_FM_NAME_IP_HOSTN No From name + hostname using IP address
> 0.0 ENA_BAD_SPAM Spam hitting really bad rules.
>
> --
> David Jones

Re: Bitcoin update

2018-10-05 Thread David Jones
On 10/5/18 4:38 PM, Antony Stone wrote:
> On Friday 05 October 2018 at 23:26:12, Rupert Gallagher wrote:
> 
>>> https://pastebin.com/TRD7FzRQ
>>>
>>> I have a sample here
>>
>> There are at least three reasons to reject that e-mail upfront, with no
>> need to parse its body.
> 
> Hints might be appreciated for the uninitiated.
> 
> 
> Antony.
> 
> 
> PS: Please do NOT set Reply-To to your own address on list postings.
> 

Are you doing any RBLs at the MTA?  This thing looks really bad and 
would never have made it past my Postfix postscreen_dnsbl_sites list.

 http://multirbl.valli.org/lookup/114.46.223.46.html

If it had made it to SpamAssassin, here's what my rules would have scored:

Content analysis details:   (29.8 points, 5.0 required)

  pts rule name  description
 -- 
--
  5.2 BAYES_99   BODY: Bayes spam probability is 99 to 100%
 [score: 1.]
  3.2 BAYES_999  BODY: Bayes spam probability is 99.9 to 100%
 [score: 1.]
  0.5 FROM_DOMAIN_NOVOWELFrom: domain has series of non-vowel letters
  1.5 CK_HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname
 (Split IP)
  0.2 CK_HELO_GENERICRelay used name indicative of a Dynamic Pool or
 Generic rPTR
  1.9 DATE_IN_FUTURE_06_12   Date: is 6 to 12 hours after Received: date
  3.2 DCC_CHECK  Detected as bulk mail by DCC (dcc-servers.net)
  0.1 FROM_EQUALS_TO From: and To: have the same username
  0.0 KHOP_DYNAMIC   Relay looks like a dynamic address
  3.6 HELO_DYNAMIC_IPADDR2   Relay HELO'd using suspicious hostname (IP addr
 2)
  1.0 RDNS_DYNAMIC   Delivered to internal network by host with
 dynamic-looking rDNS
  2.2 ENA_RELAY_NOT_US   Relayed from outside the US and not on 
whitelists
  0.1 HDR_ORDER_FTSDMCXX_DIRECT Header order similar to spam
 (FTSDMCXX/boundary variant) + direct-to-MX
  2.0 MIMEOLE_DIRECT_TO_MX   MIMEOLE + direct-to-MX
  2.5 DOS_OE_TO_MX   Delivered direct to MX with OE headers
  2.5 NO_FM_NAME_IP_HOSTNNo From name + hostname using IP address
  0.0 ENA_BAD_SPAM   Spam hitting really bad rules.


-- 
David Jones


Re: Bitcoin update

2018-10-05 Thread Antony Stone
On Friday 05 October 2018 at 23:26:12, Rupert Gallagher wrote:

> > https://pastebin.com/TRD7FzRQ
> > 
> > I have a sample here
> 
> There are at least three reasons to reject that e-mail upfront, with no
> need to parse its body.

Hints might be appreciated for the uninitiated.


Antony.


PS: Please do NOT set Reply-To to your own address on list postings.

-- 
"Linux is going to be part of the future. It's going to be like Unix was."

 - Peter Moore, Asia-Pacific general manager, Microsoft

   Please reply to the list;
 please *don't* CC me.


Re: Bitcoin update

2018-10-05 Thread Rupert Gallagher
> https://pastebin.com/TRD7FzRQ

> I have a sample here

There are at least three reasons to reject that e-mail upfront, with no need to 
parse its body.

Re: Bitcoin update

2018-10-05 Thread John Hardin

On Fri, 5 Oct 2018, Zinski, Steve wrote:


Yes, absolutely.


OK, cleaned up a bit and checked in. We'll see what masscheck thinks...


On 10/5/18, 1:42 PM, "John Hardin"  wrote:

   On Fri, 5 Oct 2018, Zinski, Steve wrote:

   > Here's how I'm blocking bitcoin emails with Unicode characters embedded:
   >
   > body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
   > body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
   > body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
   > body__BTC4  
/\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
   > metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
   > score   LOCAL_BITCOIN   10.0
   >
   > Works like a charm in my environment.

   To clarify: I added a rule for general obfuscation using the zero-width
   Unicode glyph. It's not bitcoin-specific.

   With your permission I can add that to my sandbox and see how it does in
   masscheck.


--
 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
---
  Venezuela is busy reaping the benefits of Socialism:
  in one year 75% of the population has, on average, lost 19 pounds
  due to insufficient food, and 82% of households are below the
  poverty line. (2016 Venezuelan "Living Conditions Survey")
---
 554 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Bitcoin update

2018-10-05 Thread John Hardin

On Fri, 5 Oct 2018, sebast...@debianfan.de wrote:


https://pastebin.com/TRD7FzRQ

i have a sample here


There doesn't appear to be any obfuscation (apart from the email address) 
in that message...


--
 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
---
  Running away is the coward's way out of a war;
  appeasement is the coward's way into a war.   -- Thorax
---
 554 days since the first commercial re-flight of an orbital booster (SpaceX)


Re: Bitcoin update

2018-10-05 Thread sebast...@debianfan.de

https://pastebin.com/TRD7FzRQ

i have a sample here

Am 05.10.2018 um 19:50 schrieb Zinski, Steve:

Yes, absolutely.


On 10/5/18, 1:42 PM, "John Hardin"  wrote:

 On Fri, 5 Oct 2018, Zinski, Steve wrote:
 
 > Here's how I'm blocking bitcoin emails with Unicode characters embedded:

 >
 > body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
 > body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
 > body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
 > body__BTC4  
/\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
 > metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
 > score   LOCAL_BITCOIN   10.0
 >
 > Works like a charm in my environment.
 
 To clarify: I added a rule for general obfuscation using the zero-width

 Unicode glyph. It's not bitcoin-specific.
 
 With your permission I can add that to my sandbox and see how it does in

 masscheck.
 
 > On 10/5/18, 10:54 AM, "John Hardin"  wrote:

 >
 >On Fri, 5 Oct 2018, Pedro David Marco wrote:
 >
 >>   >On Thursday, October 4, 2018, 9:08:10 PM GMT+2, Kevin A. McGrail 
 wrote:
 >> >Interesting.  Any chance for an unmodified pastebin spample?
 >>
 >> Yes please Joseph... any  change for it, please?  We are hungry...
 >
 >Test rule checked into my sandbox last night...
 >
 >Initial results aren't too promising.
 
 --

   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
 ---
It is not the place of government to make right every tragedy and
woe that befalls every resident of the nation.
 ---
   554 days since the first commercial re-flight of an orbital booster 
(SpaceX)



Re: Bitcoin update

2018-10-05 Thread Zinski, Steve
Yes, absolutely.


On 10/5/18, 1:42 PM, "John Hardin"  wrote:

On Fri, 5 Oct 2018, Zinski, Steve wrote:

> Here's how I'm blocking bitcoin emails with Unicode characters embedded:
>
> body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
> body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
> body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
> body__BTC4  
/\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
> metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
> score   LOCAL_BITCOIN   10.0
>
> Works like a charm in my environment.

To clarify: I added a rule for general obfuscation using the zero-width 
Unicode glyph. It's not bitcoin-specific.

With your permission I can add that to my sandbox and see how it does in 
masscheck.

> On 10/5/18, 10:54 AM, "John Hardin"  wrote:
>
>On Fri, 5 Oct 2018, Pedro David Marco wrote:
>
>>   >On Thursday, October 4, 2018, 9:08:10 PM GMT+2, Kevin A. McGrail 
 wrote:
>> >Interesting.  Any chance for an unmodified pastebin spample?
>>
>> Yes please Joseph... any  change for it, please?  We are hungry...
>
>Test rule checked into my sandbox last night...
>
>Initial results aren't too promising.

-- 
  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
---
   It is not the place of government to make right every tragedy and
   woe that befalls every resident of the nation.
---
  554 days since the first commercial re-flight of an orbital booster 
(SpaceX)



Re: Bitcoin update

2018-10-05 Thread John Hardin

On Fri, 5 Oct 2018, Zinski, Steve wrote:


Here's how I'm blocking bitcoin emails with Unicode characters embedded:

body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
body__BTC4  /\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
score   LOCAL_BITCOIN   10.0

Works like a charm in my environment.


To clarify: I added a rule for general obfuscation using the zero-width 
Unicode glyph. It's not bitcoin-specific.


With your permission I can add that to my sandbox and see how it does in 
masscheck.



On 10/5/18, 10:54 AM, "John Hardin"  wrote:

   On Fri, 5 Oct 2018, Pedro David Marco wrote:

   >   >On Thursday, October 4, 2018, 9:08:10 PM GMT+2, Kevin A. McGrail 
 wrote:
   > >Interesting.  Any chance for an unmodified pastebin spample?
   >
   > Yes please Joseph... any  change for it, please?  We are hungry...

   Test rule checked into my sandbox last night...

   Initial results aren't too promising.


--
 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
---
  It is not the place of government to make right every tragedy and
  woe that befalls every resident of the nation.
---
 554 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Bitcoin update

2018-10-05 Thread Zinski, Steve
Here's how I'm blocking bitcoin emails with Unicode characters embedded:

body__BTC1  /\b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b/
body__BTC2  /\b\W*b\W*i\W*t\W*c\W*o\W*i\W*n\W*\b/i
body__BTC3  /\b\W*b\W*t\W*c\W*\b/i
body__BTC4  /\bb[i\x{0456}]t[c\x{0441}][o\x{043E}][i\x{0456}]n\b/i
metaLOCAL_BITCOIN   ( __BTC1 && ( __BTC2 || __BTC3 || __BTC4 ) )
score   LOCAL_BITCOIN   10.0

Works like a charm in my environment.



On 10/5/18, 10:54 AM, "John Hardin"  wrote:

On Fri, 5 Oct 2018, Pedro David Marco wrote:

>   >On Thursday, October 4, 2018, 9:08:10 PM GMT+2, Kevin A. McGrail 
 wrote:
> >Interesting.  Any chance for an unmodified pastebin spample?
>
> Yes please Joseph... any  change for it, please?  We are hungry... 

Test rule checked into my sandbox last night...

Initial results aren't too promising.

-- 
  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
---
  554 days since the first commercial re-flight of an orbital booster 
(SpaceX)



Re: Bitcoin update

2018-10-05 Thread John Hardin

On Fri, 5 Oct 2018, Pedro David Marco wrote:


  >On Thursday, October 4, 2018, 9:08:10 PM GMT+2, Kevin A. McGrail 
 wrote:
>Interesting.  Any chance for an unmodified pastebin spample?

Yes please Joseph... any  change for it, please?  We are hungry... 


Test rule checked into my sandbox last night...

Initial results aren't too promising.

--
 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
---
 554 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Bitcoin update

2018-10-05 Thread Pedro David Marco
 

   >On Thursday, October 4, 2018, 9:08:10 PM GMT+2, Kevin A. McGrail 
 wrote:  
 >Interesting.  Any chance for an unmodified pastebin spample?

Yes please Joseph... any  change for it, please?  We are hungry... 

---PedroD  

Re: Bitcoin update

2018-10-04 Thread Kevin A. McGrail
Interesting.  Any chance for an unmodified pastebin spample?

On Thu, Oct 4, 2018, 12:07 Joseph Brennan  wrote:

>
> Two days ago the Bitcoin threats from Outlook.com started arriving in the
> Windows-1256 charset, which is Arabic, but including Latin characters. The
> text has Arabic character 9D all over the place. 9D is "ZERO WIDTH
> NON-JOINER" so it takes up no space and the English language text looks
> normal. But it breaks pattern matching.
>
> That ALL of the Bitcoin threats from outlook.com changed the evening of
> October 1 means they are all from one source.
>
> Sample of the mime part header and a raw paragraph:
>
> --_000_AM0PR04MB488298EB0071C1677D7C5BA9BAE90AM0PR04MB4882eurp_
> Content-Type: text/plain; charset="windows-1256"
> Content-Transfer-Encoding: quoted-printable
>
> Yo=9Du wi=9Dll ha=9Dv=9De two diff=9Derent so=9Dluti=9Do=9Dns. Why dont w=
> =9De check o=9Dut =9Dea=9Dch on=9De o=9Df thes=9De o=9Dpti=9Dons in
> deta=9D=
> i=9Dls:
>
>
> Joseph Brennan
> Columbia U I T
>
>