New(?) URL obfuscation technique

[Kelson <ke...@speed.net>]

Spotted this one in a message that only scored about 2.5.  It was 
image-only spam with word salad below, and the link was...unorthodox, to 
say the least:

<A href="h
t
tp:/
/pfzxrwamqed.org&zunrs7d3ebsqfla9okv%2Egua
cofk
nhb%2Ecom/">

This is the first time I've noticed the protocol broken up by line breaks!

If I'm reading it correctly, guacofknhb<MUNGED>.com is the actual domain 
name.  That name is currently in ws.surbl.org, sc.surbl.org, and 
ob.surbl.org, but none of the rules fire on this message.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>

Re: New(?) URL obfuscation technique

[Kelson <ke...@speed.net>]

Kelson wrote:
> This is the first time I've noticed the protocol broken up by line breaks!

Forgot to mention: SA 3.0.2.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>

Re: New(?) URL obfuscation technique

[Loren Wilton <lw...@earthlink.net>]

> This is the first time I've noticed the protocol broken up by line breaks!

Standard hack, been around for a month or two now.  I think we may have a
SARE rule for this, if not we will soon.  The trick is that breaking http up
with cr characters (not actually newlines) causes SA to not spot it, but it
still works for everyone else for some reason.  I'm also including the
double-at catcher, since on 2.6x (and possibly 3.x) the double-at causes it
to fail to match as a URI.

For ME, these hit only spam.  SARE mass-checks show that the double-at rule
can hit a small amount of ham.  You may want to score accordingly.

        Loren

#test for @@ in internal image id link
# can't do this with a uri test, it stops on the second @ sign!

rawbody  LW_DOUBLE_AT /IMG SRC="cid:part1\.\d{8}.\d{8}\@[a-z]+\@[\w\.]+"/i
score  LW_DOUBLE_AT 1
describe LW_DOUBLE_AT strange internal image link

#test for carriage return in a uri
# this will fail in a uri test as the uri terminates on the cr (or a second
@ for that matter!)

rawbody  __LW_URI_CR1 /href=\"[^"]*\r[^\n]/is
full  __LW_URI_CR2 /href=\"[^"]*\r[^\n]/is
meta  LW_URI_CR  __LW_URI_CR1 || __LW_URI_CR2
score  LW_URI_CR  2
describe LW_URI_CR  unescaped cr in uri

full  LW_URI_CR2  /href=\"[^"]*\r[^\n]\w+\r[^\n]/is
score  LW_URI_CR2  2
describe LW_URI_CR2  unescapred crs in uri

Re: New(?) URL obfuscation technique

[Kelson <ke...@speed.net>]

Loren Wilton wrote:
> Standard hack, been around for a month or two now.  I think we may
> have a SARE rule for this, if not we will soon.  The trick is that
> breaking http up with cr characters (not actually newlines) causes SA
> to not spot it, but it still works for everyone else for some reason.
> I'm also including the double-at catcher, since on 2.6x (and possibly
> 3.x) the double-at causes it to fail to match as a URI.
> 
> For ME, these hit only spam.  SARE mass-checks show that the
> double-at rule can hit a small amount of ham.  You may want to score
> accordingly.

Robert Menschel wrote:
> The rule I've tested which seems to hit the most spam is
...

Thanks.  I'll try boths sets of rules and see what works best here.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>

Re: New(?) URL obfuscation technique

[Robert Menschel <Ro...@Menschel.net>]

Hello Kelson,

Tuesday, April 19, 2005, 11:13:57 AM, you wrote:

K> Spotted this one in a message that only scored about 2.5.  It was 
K> image-only spam with word salad below, and the link was...unorthodox, to
K> say the least: ...

The rule I've tested which seems to hit the most spam is

rawbody   SARE_HTML_MLINE_HTTP     m'(?!https?: ?//)h[^a-z:>]{0,4}t[^a-z>]{0,4}t[^a-z>]{0,4}p[^s:>]{0,4}:[^/>]{0,4}/[^/]{0,4}/'is
describe  SARE_HTML_MLINE_HTTP     MULTI-line http
score     SARE_HTML_MLINE_HTTP     0.500
#hist     SARE_HTML_MLINE_HTTP     Bob Menschel, Apr 11 2005
#counts   SARE_HTML_MLINE_HTTP     30s/26h of 300658 corpus (126413s/174245h RM) 04/17/05

but as you can see from that counts line, it hits a lot of ham as
well.  I'm working on improving its performance.

Bob Menschel