[LINK] RFI: Spambot Architecture

[Glen Turner]

> OTOH, a couple of people have claimed to me that they've had email in 
> their Outbox that they hadn't created.


The spam-bot designer has a Hobson's Choice.

1) Use its own SMTP implementation
2) Use the user's mail client or its API

(1) is attractive for the reasons you notice, but most corporate
mail clients can't mail to the outside world directly -- they go
via a corporate mail server and direct use of SMTP with the
outside world is blocked by the firewall.

Generally, the spambot doesn't know enough to work out where the
corporate mail relay is, what type it is (MAPI v SMTP v Submission)
or have enough info to authenticate.  Users themselves have enough
trouble working all this out.

So (2) starts to look attractive.

So what is an Outbox?  It's a file on the user's PC.  Hmmm.
We could append our spam to that and the next time the user
connects and authenticates to their mail server it will be
sent.  [This is really a good case showing the value of
Mandatory Access Controls (such as SELinux) for all programs,
not just Internet-exposed servers.]

There's a small risk of this being seen, but it is effective
as it works even behind a well set up network.

There's a variant on (2). We could find the user's mail password
(either because it has been saved in a insecure file because the
mail client is trying to save the user from typing or by running
a keylogger) and call the mail API ourselves.  That's getting
very complicated and spambots need to work across a large range
of software installations.

Cheers, Glen