Some malware that sends interesting fake mailing list messages

August 3, 2016

Now that we're logging MIME attachment type information, we've also started to reject messages at SMTP time if they contain certain stuff that we don't like, such as a ZIP archive with a single .js file in it. One of Exim's little features is that when you reject a message at DATA time, Exim logs the message headers to its rejectlog (or at least a certain amount of them; Exim won't write too much data here). This has let me observe some interesting things.

One of the most striking things I've seen is malware (sending .wsf files in ZIP archives) that seems to be determinedly faking mailing list headers in the messages that it sends. It's actually a really distinct pattern, so let me show you a sample that very clearly illustrates it:

Received: from 8ta-146-52-116.telkomadsl.co.za (8ta-146-52-116.telkomadsl.co.za [41.146.52.116])
   by [... us ...]
Received: from root by co.za with local (Exim 4.80)
   (envelope-from <bounce-59932273-439628-6414464-0286055@co.za>)
   id QJhwNw-OgPFpd-lZ
   for [user redacted]; Mon, 01 Aug 2016 15:41:08 +0200
To: <user redacted>
Subject: Corrected report
X-PHP-Originating-Script: 0:class.phpmailer.php
Date: Mon, 01 Aug 2016 15:41:08 +0200
From: "Michale Mcdowell" <Mcdowell.625@co.za>
Reply-to: "Michale Mcdowell" <Mcdowell.625@co.za>
X-Priority: 3
Sender:       <user-5CB@co.za>
X-Mailer: Email Sending System
X-Complaints-To: m@co.za
List-Unsubscribe: <https://www.co.za/app/unsubscribe.php?p=[hex garble]>
List-Id: 35830
X-Postmaster-Msgtype: 91601
X-Report-Abuse: <https://www.co.za/app/report_abuse.php?mid=[different hex garble]>
[...]

There's all sorts of interesting made up things here. The final Received: header always claims that the message was received locally via Exim from a bounce-* address, for example, and there's the various list related X-* headers. It's almost always the case that the claimed domain name for the website and the sender email address and so on is related to the actual hostname of the sending IP, but as we see here it seems to be obtained by stripping parts off and sometimes gets wild results.

(Not always; we have another such email from iburst-41-56-16-166.iburst.co.za that used 'www.iburst.co.za' as the website domain, instead of co.za. Maybe the difference is because both co.za and iburst.co.za have A records, but telkomadsl.co.za doesn't. The software involved here might be using that as a cue for how to look plausible. It's not that 'www.<whatever>' exists, because www.co.za doesn't.)

Naturally these URLs don't exist on the sites I've checked, and often the sites don't even respond to HTTPS. And everything I've looked at has this consistent pattern of headers and naming. I'm assuming that it's some malware sending software that is trying to make its messages look more legitimate. Since humans almost never look at this sort of header, I assume that the malware's trying to fool automated scanning systems.

Written on 03 August 2016.
« Containerization as the necessary end point of deployment automation
It's likely worth re-detecting your system's sensor chips every so often »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Aug 3 23:04:50 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.