[Mimedefang] Spammer zombie group behaviour

[Chris Myers]

----- Original Message ----- 
From: <Matthew.van.Eerde at hbinc.com>
To: <mimedefang at lists.roaringpenguin.com>
Sent: Thursday, April 22, 2004 5:19 PM
Subject: RE: [Mimedefang] Spammer zombie group behaviour


> > From: Chris Myers [mailto:chris at by-design.net]
> >
> >     There are groups of spam zombie systems THAT ARE COMMUNICATING
> >     WITH EACH OTHER to retry failed deliveries.  If System A fails
> >     to deliver the message, then System B tries, and then System C
tries, and
> >     so on.
>
> Indeed.  If this were in fact the case, it would be a tremendous feat of
> distributed application programming.  My estimation of the programmer
would
> bump up tremendously (from "scum" to "lowlife".)
>
> On the other hand, perhaps something much less complicated is going on.  I
> suggest there's a zombiemaster with a template and a huge list of
> recipients.  It parcels the list of recipients out to the zombies and the
> zombies report back every once in a while.  The zombiemaster marks the
"OK"s
> off of his master list, and increments a "Reject" counter for every
Reject.
> After every email has been tried at least once, the zombiemaster will send
> the "Reject: 1"'s out to his zombies in what becomes a random
reassignment.
> Repeat until every email is "Reject: 5" or more, or until someone comes
> along with another template/recipient list/$$$.

It is likely something along those lines, and I'm not suggesting that there
is ... yet ... any stronger form of collaboration that reporting delivery
status to a master.  But I am absolutely positive that there is some form of
coordination.  Comparing the mail traffic for a single user "before" and
"after" greylisting the retry patterns are just TOO obvious for there not to
be coordination.  The "before" data sample does not show long strings of
similar-Subject (and Message-Id and sender) messages going to a single
recipient in a short period of time.  The "after" data shows exactly that.

If there were no coordination, I would see these patterns in the "before"
data as well.  If I didn't mind the end-users wanting to kill me, I'm
positive that I would stop seeing those patterns if I turned greylisting
back off.

If you look at this technique in the context of a spammer wanting to get
around DNS blacklists, it's a perfect match.  If System A is blacklisted,
maybe System B isn't, and probably System C isn't, and so on.  As an attack
against greylisting it's utterly useless and actually leaves good enough
fingerprints that you can come up with an automated tool for reporting those
zombies to the appropriate blacklists before they get around to trying you
again.

<rant mode=on />
Keep in mind, when we talk about these things as "state of the art" (or
whatever), that "state of the art" is a moving target.  Message hashing,
e.g. DCC and Razor,  was once very effective.  Now that spammers have access
to enough bandwidth and CPU power to customize messages, hashing is heading
towards the "much less useful tools" category.  Greylisting undoubtedly will
also move in that direction some day.  Every time we come up with a better
defense, "they" come up with a better attack.  If you think any single
technique can survive thoughtful attack, see
http://www.roaringpenguin.com/dastardly.html (referenced in
http://lists.roaringpenguin.com/pipermail/mimedefang/2003-May/014728.html)
and actually read some of the spam that IS making it past SpamAssassin
(HINT! Use notepad or vi to read the mail, NOT Lookout Express).  There's
ALWAYS a way.

Even though we may think that this attack is simple, it can be extended
rather easily to bypass greylisting.  All you have to do is have the master
track messages there were refused to all members of the cluster and then
send them to one of the cluster members again ... after a delay of N minutes
(where N is chosen to get around most peoples greylisting timers).  Since
the communication path is already there, this would be a fairly simple
coding change.  Know what the counter to THAT one is?

Collaborative computing for spammers *IS* coming.  As long as there is an
incentive for spam, spam will exist.  There is no grand solution.  I look at
some of the techniques being proposed right now for "getting rid of spam",
like crypto signing mail along with certificate authorities, e-mail postage,
SPF and so-on and I just go "yeah right, and IPv6 is going to sweep the
whole Internet like wildfire next week"  We can't change the infrastructure
in any sort of grand way, the legal system is basically useless, and we're
up against people who get paid real money to find ingenius ways around spam
defenses.  What do we do?  Well, we actually outnumber the bastards and
we're pretty bright too ... so keep on thinking, folks.

<rant mode=off />

Chris Myers
Networks By Design