2012-09-30
A new anti-spam precaution after our local spam incident
When we had out local spam incident, I of course immediately started thinking about mail configuration changes we'd want to make to lessen the impact of another such incident. One of them was to arrange it so that another IP address was used when sending out user email that did not come from a local address.
Our mail submission machine (which handles almost all outgoing email) is one of our most important mail machines to keep off blocklists and to maintain with a good reputation, because it's the machine that local human-written email goes out through. This email is the most important email to get through. It's kind of a pain if (say) forwarded email or user-run mailing lists can't get delivered; it's a crisis if professors and staff can't email other universities, GMail, or whatever.
As it happens, all of the spam email sent in the incident had non-local (and forged) origin addresses. The obvious thing to do would be to fix our webmail systems so they don't allow that any more and you have to send with your authenticated local user address (or it just forces that address all the time). I briefly thought about trying to do that and then realized that this would actually make our problem worse. It's not as if this would block the phish spammers from spamming; instead it would just force them to send their spam with one of our email addresses as the origin address. If my goal was to keep our reputation as nice as possible, this would be a step backwards.
The cheap hack is then to use this marker that the spammers have given us to segregate their outgoing email so that it comes out from a different IP address. Then if (or when) there's another spam run due to a compromised local account, it's highly likely that there will be little or no drop in the reputation of our IP address for normal outgoing email. Some of our users routinely send email with non-local addresses and they'd still be affected, but that's a lot better than everyone's email being hit.
(My impression is that forging origin addresses is the common spammer behavior when they exploit compromised systems like ours and that they do it whenever possible. This may change over time.)
PS: this is real concern, not a theoretical worry. A number of systems temporarily blacklisted our outgoing mail machine in the immediate aftermath of the spam run, and did it for long enough that some of our users ran into the blocks with real mail they were sending.
2012-09-29
A recent spam oddity that I've been mulling over
One of my habits is that I don't directly subscribe to mailing lists;
instead, I subscribe aliases to them and forward the aliases to me.
These aliases are generally purely collection points that are almost
never used as the From: address or explicitly copied on messages. As
a result of all of this, these aliases should never get spam and almost
always don't. All of this is background.
A couple of weeks after our phish compromise incident, one of those aliases received a distinct burst of spam, hitting it on Thursday, Friday, and then the next Tuesday and Wednesday. All of the spam messages were various sorts of phish attempts but not for banking credentials; they targeted business services (efax.com, adp.com, American Express, and the Better Business Bureau). Most of the phish attempts were your standard fake website things, but one of them was trying to get you to run a zipped Windows executable (some online analysis sites say that as expected, this is an already-seen trojan). Based on evidence in the message headers all of these phish attempts had multiple recipients here, not just my little alias.
So in short, a couple of weeks after a phish compromise we were spammed with a significant phish spam run that hit even a normally invisible address. This makes me wonder two questions.
First, did our initial phish compromise somehow read out a significant portion of our local addresses and then pass them on to other spammers? On the one hand, this would explain why this spam hit my alias. On the other hand, it's hard to see how it would have happened. I don't think that our webmail systems support this, it's far from obvious how to do this on our machines, and there wasn't any evidence that the spammer accessed our systems apart from webmail.
(I was going to say that this alias had never appeared anywhere and had never been spammed before, but both turn out to be wrong. It's appeared in a place or two and it did receive an advance fee fraud spam back at the start of July.)
Second, did the initially successful phish spam cause the followup? I can certainly construct a story where spammers find it useful to target further phish spam at places where some phish spam has already worked; after all, suckers are suckers. On the other hand it certainly could be a coincidence. The compromise phish spam was specifically targeted against us (with specific organization names and so on), but the followup phish spam is very definitely not; it's targeting generic business services, not services that a university department would plausibly use or care about. At a minimum it suggests that the spammers behind the targeted phish spam were a different group than the people behind the followup.
2012-09-22
Speculation about what comment spammers think they're doing here
To summarize briefly, comment spam attempts here show some odd behavior; when I add sources to IP blocks, I see significant hits on those blocks but the level of non-blocked comment spam attempts stays more or less the same (but comes from new IPs). It's as if the comment spammers keep trying from the old IPs but also add new IPs. I'm a firm believer that spammers are generally not stupid. Whatever strange things they're doing are being done for reasons that make sense to the spammers. So the real question I'm left with is what the comment spammers are targeting here. What is their actual goal, which their software presumably thinks it's dutifully achieving?
What their software actually does almost all of the time is fill in all
of the text fields on the 'add a comment' page (including my honeypot
field that you are not supposed to touch), submit it for previewing, and
then not do anything more. In particular the spammers seem to basically
never attempt to resubmit the spam to actually post it; one POST and
they're done.
I've come up with two speculations on what they're doing so far. First, the spammer software could think that it's actually succeeding in posting spam comments and it could be targeting 'so many comments posted successfully'. This is a bit of a stretch but the raw text of a comment is (re)displayed on the preview page (although the HTML version is not shown if the honeypot field was touched). Software that simply searched for its submitted spam text might be satisfied and conclude that the comment had been successfully posted.
Second, the spammer software could be trying to flood a (presumed) moderation queue with a high volume of spam submissions in the hopes that something would get through by mistake. The software would then be targeting 'so many comments submitted into the queue' and it would continue to pound away even if nothing seemed to be getting through; after all, the people behind the moderation queue only have to make a mistake once.
(I feel that one of the principles of the modern Internet spam game is 'automated work is cheap'. If the spammer can just leave software running to do something, they might as well keep it banging away; the cost of leaving it running is probably low enough that even a single success pays for it. In an environment where you have to rent botnets by the 15 minutes and so on, this may not be quite as true as I've been assuming.)