New botnet spammed malware – Peals.F!plock

This is a big one, coming from hitherto unlisted botnet addresses – and it’s coming right now. I’m cross referencing the blacklisted addresses now to see if I can see who’s had an expansion lately. Spamassassin isn’t that great at picking it up, with about 10% getting straight through and about 90% failing to reach five points.

It’s a Microsoft Word document, apparently containing controversial malware Peals.F!plock. Little is known about this, other than Security Essentials flagging it but others say it’s a false positive. Well someone’s gone to a lot of trouble to sent it a “false positive”.

The messages all claim to come from “Stephanie Greaves”, sgreaves at btros.co.uk, with a fixed subject of COS007202, which is unusual. You’d have thought that if you’re using a clean botnet you’d randomise things a bit. This is a genuine domain name (with no SPF – come on guys!) and for all I know, Stephanie Greaves is the name of a genuine victim. Their MX is a virtual server and they’re probably wondering why it’s been heavily loaded since 9am.

Whoever’s doing this has a pretty comprehensive spamming list, containing nearly all of my honeypots.

Update:

This same malware is now being sent out claiming to be from customerservices@ocado.com with the subject “Your receipt for today’s Ocado delivery”, and an HTML message looking like an Ocado receipt (as far as I can tell – I shop for my own groceries!) Again, Ocado doesn’t seem to have SPF set up.

The message text is:


 

HERE’S YOUR RECEIPT

Hello

Your receipt for today’s delivery is attached to this email. I’ll be delivering your 12:00-14:00 order and, so you’ll know it’s me, I’ll be driving the Lemon van.

Your order doesn’t have any substitutions, everything’s there.

See you later,

Paul

Please generate and paste your ad code here. If left empty, the ad location will be highlighted on your blog pages with a reminder to enter your code. Mid-Post

 


The fake bombardier one reads:

Good morning,
Please see attached purchase order.
Kind regards,
Stephanie Greaves
cid:image002.jpg@01D01077.BAC48BA0
Administration Apprentice
Bombardier Transportation (Rolling Stock) UK Ltd
Electronics, Cabling, & Interior Division
Litchurch Lane, Derby, DE24 8AD

 

Update: 20-Oct-15 11:22

The malware spam now looks like this:

From: Shaun Buzzard <shaunb@hubbardproducts.com>
To: <to_addr}}>  <-- Note error
Subject: Order

Hi ,

Please find attached order.

 

Kind regards.

Shaun Buzzard

 

 

Spam From Amazon SES

Spam has always been a problem with Amazon’s email service (SES). They make an effort to filter the outgoing missives transmitted by their customers, but it’s not perfect. And Amazon is no respecter of laws outside the good ‘ol US of A, where the right to free speech is a license to spam any kind of junk you like; whether the recipient asked for it or not.

Here’s a case in point:

Received: from a8-55.smtp-out.amazonses.com (a8-55.smtp-out.amazonses.com [54.240.8.55])
	by xxx.xxx.xxx.uk (8.14.4/8.14.4) with ESMTP id t5NHpefn075543
	for <spambait@xxx.xxx.uk>; Tue, 23 Jun 2015 18:51:40 +0100 (BST)
	(envelope-from 0000014e218bf8a9-07659756-debc-452c-9a9f-1b0ecedf709d-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1435081898;
	h=From:Date:To:MIME-Version:Message-ID:Reply-to:Subject:Content-Type:Feedback-ID;
	bh=jCdtb+gUf4FAvUudtcIKxlX0IOnQHEd/YxIGxHXLcQ4=;
	b=cNIs7cNe5LzyxYvGWw/LdIeA7epknAFAoeQYjiyf9b5mTKRYLAW9KLvUTSGtlsr7
	WWy52wd3Tz9o9vQryvK/Q5l5okAFxgZCZa5uSbXMor7sa/1dU02kwjCyACnb7viR1np
	BlEytfbGEBUlAfBBrrJueagmdzwa+IXNZsBo4w2Y=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=lfgclj2zbjygv5i5rirpal2v2zj3dquy; d=uebaps.com; t=1435081898;
	h=From:Date:To:MIME-Version:Message-ID:Reply-to:Subject:Content-Type;
	bh=jCdtb+gUf4FAvUudtcIKxlX0IOnQHEd/YxIGxHXLcQ4=;
	b=bZZSEICBkHU8HkdFtiYg9fp+qxzmxJlfNj6UclS3B4dtaKBMTf1oSCSQR5jm0XXE
	0JxmIdNWKsgumLUcf8XnZGZFVfwe2f7cVOCiA1EcHX7oHn0weHQjoce+nxwVClgCQYz
	m0OlXn/YvNBE1MwSvpQR3PfoSCyTVQQpBWjgD8dQ=
From: Ray-Ban Sale <enews@uebaps.com>
Date: Tue, 23 Jun 2015 17:51:38 +0000
To: "spambait@xxx.xx.uk" <spambait@xxx.xx.uk>
X-MessageID: OXx8fHwxMzY3MXx8fHxmcmFuazJAZmpsLmNvLnVrfHx8fDEwfHx8fDF8fHx8MA%3D%3D MIME-Version: 1.0
Message-ID: <0000014e218bf8a9-07659756-debc-452c-9a9f-1b0ecedf709d-000000@email.amazonses.com>
X-Priority: 3
Reply-to: Ray-Ban Sale <enews@uebaps.com>
Subject: Spambait: Keep Calm and Get 80% Off Ray-Ban!
Content-Type: multipart/alternative; boundary="b1_b18fea4f74280e521923210f4d5c61eb"
X-SES-Outgoing: 2015.06.23-54.240.8.55
Feedback-ID: 1.us-east-1.E00ipiLUCdDBKP1kTeYjtCc2E2c3DbfGjCtoi1emL2E=:AmazonSES 
--b1_b18fea4f74280e521923210f4d5c61eb
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: base64
SGksRnJhbmsgTGVvbmhhcmR0OiAjUl9Ub3BfVGl0bGUjLg0KQm9ybiBmcm9tIGEgbWVzaCBiZXR3
ZWVuIHR3byBvZiBSYXktQmFuJ3MgbW9zdCBpY29uaWMgYW5kIHBvcHVsYXIgc3VuZ2xhc3NlcyAt
IHRoZSBDbHVibWFzdGVyIGFuZCBXYXlmYXJlciAtIFJheS1CYW5DbHVibWFzdGVyIE92ZXJzaXpl

As you can see (if you’re used to reading email headers), this looks very legitimate – send from a correctly configured server. However. these characters are as guilty has hell. The email body, once decoded, claims that the spambait email address belonged to a past customer of theirs, and was used for placing an order (in the USA). This is, of course, physically impossible.

If this had been sent in Europe they’d have been breaking the local law that implemented  the EU Privacy and Electronic Communications Directive, 2002.  But they’re sending it from the USA. Other text in the email suggests it’s not from an English-speaking country (not even the USA), and it’s probably a scam. But Amazon doesn’t t seem to mind – they don’t even have an abuse reporting system for ISPs plagued by this stuff.

It’s tempting to simply block all Amazon SES IP addresses, but this will cause collateral damage. Spam filtering isn’t likely to detect it any other way, as the sending server is set up correctly, with SPF records and so on, so the Bayesian filter in a spam classifier will be over-ruled. However, this correctness can be used against it…

Let’s be clear here – it’s easy enough to block the whole of SES. You can get its address range just by looking at it’s SPF records:

%nslookup
> set type=TXT
> amazonses.com
Server: 127.0.0.1
Address: 127.0.0.1#53
amazonses.com text = "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 -all"

I suspect this may cover more than SES, but SES is certainly covered by it. However, blocking it will, as I mentioned earlier, block some innocent stuff that you do want. This is a job for Spamassassin.

I’m experimenting by adding the following to SA’s local.cf file:

header AMAZON_SES Received =~ /amazonses.com/
score AMAZON_SES 3.5
describe AMAZON_SES Sent from Amazon SES - often used by spammers

The the appropriate score to weight it by is an interesting question. By default good SPF records are ignored anyway; if they were not then it would obviously be a good idea to negate a positive score here. So I’ve picked 3.5 as this matches a clear Bayesian score rather than for any good statistical reason. Check back later to see how well it works.

Spamassassin, spamd, FreeBSD and “autolearn: unavailable”

I recently built a mail server using FreeBSD 8.2 and compiled spamassassin from the current ports collection, to run globally. spamd looked okay and it was adding headers, but after a while I noticed the Baysian filtering didn’t seem to be working in spite of it having had enough samples through.

A closer look at the added headers showed “autolearn: no”, or “autolearn: unavailable” but never “autolearn: ham/spam”.

What was going on? RTFM and you’ll see spamassassin 3.0 and onwards has added three new autolearn return codes: disabled, failed and unavailable. The first two are pretty self-explanatory: either you’d set bayes_auto_learn 0 in the config file or there was some kind of error thrown up by the script. But I was getting the last one:

unavailable: autolearning not completed for any reason not covered above. It could be the message was already learned.

I knew perfectly well that the messages hadn’t already been learned, so was left with “any reason not covered by the above”. Unfortunately “the above” seemed to cover all bases already. There wasn’t any clue in /var/maillog or anywhere else likely.

I don’t much care for perl scripts, especially those that don’t work, so after an unpleasant rummage I discovered the problem. Simply put, it couldn’t access its database due to file permissions.

The files you need to sort are at /root/.spamassassin/bayes_* – only root will be able to write to them, not spamd – so a chmod is in order.

A better solution is to move the Bayesian database out of /root – /var would probably be more appropriate. You can achieve this by adding something like this to /etc/spamd.cf (which should link to /usr/local/etc/mail/spamassassin/local.cf):

bayes_path /var/spamassassin/bayes/bayes
bayes_file_mode 0666

I suspect that the lower-security Linux implementation avoids these problems by setting group-write-access as default, but FreeBSD, being a server OS, doesn’t. It’s also a bug in the error handling for the milter – it should clearly report as a “failed” and write something to the log file to tell you why.

You should be able to restart spamd after the edit with /usr/local/sbin/spamdreload, but to be on the safe side I use the following after shutting down Sendmail first.

/usr/local/etc/rc.d/spamass-milter restart
/usr/local/etc/rc.d/sa-spamd/restart

I don’t know if Sendmail can cope well with having spamass-milter unavailable, but why take the risk?