Wandering Thoughts

2017-03-24

An odd and persistent year old phish spammer

We have a number of more or less internal mailing lists for things like mailing all of the technical staff. They have at least somewhat unusual names and don't appear in things like email directories or most users' address books. Back almost a year ago (21st April 2016), one of them got a phish spam:

From codewizard@approject.com [...]
Received: from [177.47.160.250] (helo=approject.com) [...]
From: "Capital One 360" <codewizard@approject.com>
Subject: Your Capital one 360 Account Urgent Login Reminder

LOOK FOR THE ATTACHED FILE AND OPEN

(With an attached PDF.)

Slightly over a month later, the same address got another one:

From codewizard@approject.com [...]
Received: from [95.213.155.178] (helo=approject.com) [...]
From: "USAA SECURITY" <codewizard@approject.com>
Subject: Your Account Log-on Reminder

A week later it got a third one, with the same MAIL FROM (and EHLO), but from a different IP address yet again. Then a fourth two weeks later.

At this point I'd had enough, so I threw the MAIL FROM of codewizard@approject.com into the per-address server side email blocks for this particular address. You can probably guess what has happened periodically ever since then:

2017-03-23 18:11:31 H=(approject.com) [46.39.225.151] F=<codewizard@approject.com> rejected RCPT <redacted>: blocked by personal senders blacklist.

(As I write this, that IP address is on the Spamhaus CSS.)

It's clear that whatever is doing this spamming is widely dispersed, very persistent, and is using a basically unique address list that it has a death grip on (this internal mailing list of ours hasn't started getting other sorts of spam, just this one phish spammer). Maybe this is wandering malware that is now operating more or less autonomously (like some do), or maybe this is someone running a long-term campaign who cannot be bothered to disguise the distinctive signatures here (those being the envelope sender and the EHLO).

(This isn't the first time I've seen spammer persistence illustrated, but I think it's the first time it's clearly a single spammer or spam agent instead of address lists being shared and reshared endlessly.)

PS: Since various aspects of this phish spam have apparently mutated over time, it's probably not autonomous malware in action but instead someone running a long-term campaign. I don't know why they're so fixated on using this very distinctive MAIL FROM, but it's certainly handy so please don't change, whoever you are.

PersistentPhishSpammer written at 22:25:02; Add Comment

2017-03-10

Malware is sometimes sent through organized, purchased infrastructure

Every so often, I wonder where malware comes from. Well, in a mechanical sense; does it come from infected machines, or from rented botnets, or what? Today we got a malware attack campaign that gave us a very clear answer: it came from dedicated, custom-built infrastructure.

Between 12:17 and 12:28 today, a cluster of four IP addresses tried to send us 376 email messages. All of them had a HELO and verified host name of confidentialdocumentdelivery.com, and the MAIL FROM was 'service-<tagged-address>@confidentialdocumentdelivery.com'. All of them that did not get rejected for other reasons had a .doc file that Sophos identifies as CXmail/OleDl-V. To make things look more tempting, they all had some common mail headers:

To: <whoever>
Subject: Confidential Documents Delivery
From: "Document Delivery" <service@confidentialdocumentdelivery.com>

(They also appear to have had valid DKIM signatures, just in case you think DKIM signatures on email are any sign of trust.)

At the time, confidentialdocumentdelivery.com was (and is) in the Spamhaus DBL, and all four IPs involved were in the Spamhaus CSS, probably among other blocklists. The four IPs in question are all in AS202053 (or), 'UpCloud Cloud Servers' according to RIPE information. Their DNS PTR records at the time were all 'confidentialdocumentdelivery.com', but they've since been recycled to other PTRs. The domain itself seems to have been registered only today, assuming I believe the whois data.

All of this makes it clear that these weren't infected machines, hijacked machines, or a rented botnet. This was a whole set of carefully built infrastructure; someone figured out and bought a good domain name, rented some VPSes, assigned DNS, configured a whole set of mail sending infrastructure (complete with VERP), and used all of this to deliberately send out malware, probably in large bulk. This was an entire organized campaign on dedicated infrastructure that was put together for this specific purpose.

(The infrastructure may or may not have been custom built. For all I know, there are people who sell spammers the service of 'I will set up your sending infrastructure; you provide the domain name and some VPSes and so on'. And if it was custom built, I suspect that the malware gang responsible for this will reuse much of the software configurations and so on for another malware barrage.)

The thing that puzzles me is why you would go through all of the effort to plan and develop this, execute the plan at good speed and with solid organization (if the domain was only registered today), and yet use malware that Sophos and presumably other could already recognize. According to Sophos's page, recognized versions of this have been around since January, which I suspect is an eternity in terms of malware recognition.

(For the curious, the four IPs are 94.237.24.77, 94.237.30.162, 94.237.30.163, and 94.237.30.164. Out of those two /24s, 94.237.30.112 and 94.237.30.153 are also currently on the Spamhaus CSS.)

MalwareFromPurchasedInfrastructure written at 01:32:21; Add Comment

2017-02-25

A single email message with quite a lot of different malware

This is the kind of thing where it's easier to show you the log messages first and discuss them later:

1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .rels .xml[3] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .rels .xml[3] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .bin .png .rels .xml[10] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .eps .gif .rels .xml[10] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc
rejected 1chbMp-0007UF-Jw from 59.120.21.181/nie0461@gmail.com to <redacted>: identified virus: CXmail/OleDl-L2, Troj/20152545-E, Troj/DocDrop-RK
detail 1chbMp-0007UF-Jw Subject: [PMX:SPAM] [PMX:VIRUS] Urgent Order..

That one incoming email message had five different attachments and between them they had at least three different forms of malware. It's possible that all five attachments were bad but with some duplication of malware types, so the report we got only identified the unique malware, especially since the first two attachments have the exact same file extensions.

The origin IP address is in HINET (AS3462, hinet.net), which was a big source of issues back in the days when I actively tracked who was the source of issues. It's not currently listed in the Spamhaus ZEN, but it is on Barracuda's blocklist and psky.me (at their 'defer but don't reject' blocking level). Our logs say it HELO'd as 'mail.synclink.com.tw' and to be relaying the email from 85.114.138.127 (which is on the CBL, as well as psky.me at the 'reject during SMTP' level).

Troj/20152545-E is apparently normally a PostScript file, so I suspect that it was found in the .eps file in the fourth attachment. CXmail/OleDl-L2 is claimed to show up in 'OpenDocument' and Microsoft Office files (see also). Troj/DocDrop-RK is apparently normally seen in RTF files, so who knows where it lurks in this set of MIME attachments.

SingleEmailMuchMalware written at 18:26:47; Add Comment

2017-02-13

What file types we see inside singleton nested zipfiles in email

Earlier, I wrote about how email attachments of a single .zip inside another zip are suspicious. Given that the .doc malware using them has come back, today I feel like reporting on what file types we've seen in such cases over the past nine weeks.

(I'm picking nine weeks because we rotate this particular logfile once a week and it's thus easy to grep through just nine weeks worth.)

So here are the raw numbers:

  2292 inner zip exts: .js
  1261 inner zip exts: .doc
   606 inner zip exts: .lnk
   361 inner zip exts: .wsf
    15 inner zip exts: .jse
     5 inner zip exts: .exe
     1 inner zip exts: .txt
     1 inner zip exts: .scr

Of these 4542 emails, 3760 came from IP addresses that were listed in zen.spamhaus.org. In fact, here is the breakdown of how many of each different type were listed there:

  2051 inner zip exts: .js    (89%)
  1101 inner zip exts: .doc   (87%)
   386 inner zip exts: .lnk   (64%)
   214 inner zip exts: .wsf   (59%)
     4 inner zip exts: .jse   (27%)
     3 inner zip exts: .exe   (60%)
     1 inner zip exts: .scr  (100%)

The .jse extension is Javascript (.js) under another name. .wsf is a Windows Script File. .lnk files are Windows shortcuts, but get abused in malware as covered eg here (or the interesting live scam covered here). And .scr is a Windows screensaver, which can also contain all sorts of executable code.

There's nothing really surprising here; it's basically a greatest hits collection of ways to run your own code on reasonably modern Windows machines (apparently .bat and .com are now too old for most things). Since the .lnk files are not with other files, they're probably being used in the way mentioned here, where they run Powershell or some other capable tool with a bunch of command line arguments that pull down and run a nasty thing.

I don't know what to make of the variance in Zen listings between the various file extensions. I suspect that it has something to do with how big and broad a malware campaign is; if a campaign is prolific, its sending IPs are probably more likely to trip the detection for DNS blocklists. It seems at least reasonable that campaigns using .doc and .js malware are more prolific than the others; they certainly send us much more stuff.

NestedZipfileTypes-2017-02 written at 01:56:05; Add Comment

2017-02-09

Malware strains may go away sometimes, but they generally come back

I have a little confession. Last Tuesday I wrote about how we'd started rejecting .doc files in nested zipfiles. Although I didn't mention it in the entry, we did this because we'd seen them dominate our detected malware attempts over the weekend (with everything being identified by Sophos PureMessage as 'Mal/DrodZp-A'). Well, guess what? The moment we added that new rejection rule, all of those .docs in .zips in zipfiles vanished, with not one to be seen for our new rule to reject.

On the one hand, in theory this didn't matter; as I wrote, singleton nested zipfiles are suspicious in general and we had definitely not seen any legitimate cases of this sort of email. On the other hand, in practice we don't want to have rejection rules for everything we've seen once, because every rejection rule is a little bit of complexity added to our mail system and we want to keep the complexity down to only the things that are really worthwhile. With malware, there are always more things we could be looking for and rejecting on, so we have to draw the line somewhere; otherwise we could be playing whack-a-mole against obscure malware for months and building up a towering mass of complexity in the process. So it wasn't a good feeling to think that I might have written in a useless rejection rule and maybe I should go back in and take it out.

I won't say that I shouldn't have worried about it, but I can say that I don't have to any more. Starting on February 6th, whatever malware was sending this stuff our way came roaring back (well, roaring for our traffic volume); we had 30 rejections on the 6th, 59 on the 7th, and 38 on the 8th. Just over 93% of these were from IPs listed in the Spamhaus ZEN aggregate DNSBL, which suggests that we probably rejected a bunch more that were sent to people who had opted in to DNSBL based rejection (which happens at RCPT TO time, before we receive the message and start scanning MIME attachments). Whatever strain of malware is responsible for sending these things out may have temporarily turned its attention away from us for a while, but it's back now, at least for a while.

I suppose this really shouldn't surprise me. We've seen that MyDoom is still around and there's no particular reason why a malware attack vector should stop being used as long as it's even vaguely working. Spam (malware included) comes and goes based on where the sending attention is focused today, but it's very likely to come back sooner or later. And even if a particular strain of malware is wiped out totally (by taking over its command & control infrastructure or arresting the people behind it or the like), I expect that any respite is only temporary. Sooner or later someone will come along to pick up the pieces and revive the attack techniques and address lists for their own benefit, and we'll get hit again by something that looks very much like the same old thing.

MalwareComesBack written at 02:20:23; Add Comment

2017-01-31

Email attachments of singleton nested zipfiles are suspicious

Today I tweeted:

Our most commonly detected inbound email virus is now a .doc in a .zip inside another .zip. It's tempting to reject all such emails.

All of the recent ones of these have been what Sophos identifies as 'Mal/DrodZp-A' (which means that they're malware, not viruses as such). The good news is that after discussing the issue, we now reject such emails. One reason we could make this decision easily and with confidence is that we couldn't find legitimate examples in a month's worth of logs, which once again shows us the worth of setting up a system so that we know what types of attachments our users are getting.

But this is just one instance of a broader pattern we've been seeing for a while. Malware seems to like wrapping its payload up in two levels of archives, commonly as a single .zip inside another .zip (there are variants with RAR archives, but zip-in-zip is what we see almost all the time). It appears that every single instance of this pattern we've seen in the past month has been bad; besides .doc files, we've seen .lnk, .js, .wsf, and a couple of .exe and .scr. At this point I'm definitely going to keep an eye out for any new file extensions that show up in such matryoshka zipfiles; whether or not our commercial antispam system detects them as malware, they're probably bad news.

At the same time, you don't want to unconditionally block any zipfile that contains another zipfile. We've seen plenty of legitimate cases where people bundle up a bunch of stuff in a zipfile and part of what they bundled up is one or more other zipfiles. The suspicious case only is when it's just a single .zip file inside the first zipfile; it's hard to see a legitimate use for this, since you could just as well send the inner .zip directly.

(Well, apart from using an encrypted zipfile to pack up an unencrypted one, but I'm not sure if we can even see filenames inside encrypted zipfiles so I don't think we'd notice this.)

SuspiciousNestedZipfiles written at 19:25:07; Add Comment

2017-01-20

Spam and virus filtering on email is a risk (although likely not a big one)

If you have a decent-sized email system, you're probably running incoming email through some sort of anti-virus and anti-spam system. It may be a commercial product such as the one we use, or it may be a free one such as SpamAssassin or ClamAV. There are ways around needing such a system while still allowing a reasonable amount of incoming email, but they let some spam through and they require aggressively blocking attachments in order to try to exclude viruses.

These systems, commercial or free, are a potential security risk. We know that desktop anti-virus scanners have vulnerabilities (both in the engines and in things like their update mechanisms), so it's only prudent to assume that server-based systems do as well, especially for anti-virus systems. Modern AV systems are trying to parse and understand complicated file formats, almost certainly using code written in C and not aggressively hardened; it would be a miracle if they didn't have exploitable vulnerabilities somewhere.

(At least one commercial system definitely had vulnerabilities, although they may or may not have been exploitable.)

At one level, this is really quite alarming; your email AV system is completely exposed to inbound email from the outside world, since automatically checking that email is its entire job. An attacker who knows and can exploit a vulnerability in it can send you a malicious message and your system will be owned without any action on your part. It's not too much different from your web server having a remotely exploitable vulnerability. Yes, it's likely that coming up with a reliable attack against your AV system will be harder, but it's very likely it can still be done.

So should you abandon use of an AV system, and in fact of all content-scanning systems that look at your inbound email? As usual, this is a balance of risks question. In particular I think it's a question of how easily AV systems can be exploited generically and have something useful done with them.

The reality of life is that if an attacker is targeting you specifically, they're probably going to get in somehow. It's worth making sure that your AV system is not exceptionally vulnerable, but at the same time it is probably not the sole weak point in your environment, and not having an AV system or other content filtering has its own set of risks. For most sites, you are probably better off overall having an email AV system even if it provides an additional attack point for someone who is targeting you specifically.

But specific attackers aren't the only attackers we have to worry about; there are also mass attackers, people who find some broadly spread vulnerability and attack everyone they can find with it in order to do various sorts of nastiness (sending out spam, holding your files to ransom, selling access to other people, whatever). If a mass attack is possible at all, it is really the biggest risk, simply because mass attackers spray their attack widely in order to reach as many targets as possible.

(As a corollary, there probably will never be a mass attack against your custom local filtering, although there may be a mass attack against some common sub-component you're using in it, such as a MIME parsing library or a compression library.)

I'm wary of saying that there can't be a successful mass attack against an email AV or anti-spam scanner, but I think that the odds are against it. These systems are deployed on varied systems, in very varied environments, often in varied versions of the software itself, and there are a fair number of different software packages that mail systems use. Barring a glaring, trivial vulnerability, a would be mass attacker probably can't develop a truly broad single exploit even for a broadly spread vulnerability; they might need a different one for different Linux releases, for example. Then they'd have to find enough mail systems on the Internet that were running the specific AV/anti-spam system on Debian X or CentOS Y in order to make a mass attack worth it. It just seems unlikely to me.

(Things like web servers are more exposed to mass attacks because they are easier to mass scan and assess.)

SpamAndVirusFilteringRisk written at 01:25:39; Add Comment

2016-12-22

Malware is definitely out there and it's targeting us specifically

A few years ago I did a count of 'viruses' that our email system had seen in incoming traffic and found that we'd seen a relatively low volume. This left me with the impression that things had died down, an impression not changed by occasional surges early in 2015.

Well, let me update that. Ever since I started actively looking at the attachment types we've been getting in email and actively blocking some of them, I've noticed what I think of as a real volume of malware and periodic surges in it. Some quick numbers suggest that this is indeed the case and we seem to be running at more than twice the rejection volume we were at the start of 2015.

With rare exceptions, what we seem to get is mostly malware, which I suspect is all ransomware. More notably, lately it's clear that there is a real wave of it that is specifically targeting the university in volume. I can tell this because a great deal of the malware we're rejecting at the moment is actually relayed to us from the university's central email system (many of our users forward their central email address to us). The current burst seems to be coming from random outside envelope origin addresses, but earlier runs were actually forged from dangerously plausible university email addresses like copier@<our-domain>.ca (and with Subject: headers to match it).

(The malware that I've looked at appears to mostly be Office documents with embedded macros. At the moment we don't feel that we can reject all of these outright, although it's getting tempting, and anyways I'm not sure we can reliably detect them. Some macro-enabled attachments seem to use specific extensions, like .docm, but it appears that some don't. Presumably you have to sniff inside .doc files to be sure and I'm dubious about going that far in our own local code.)

I knew malware was out there and sending email spam, of course. But I didn't realize that it was quite as active as it seems to be.

(And I expect it to only get worse from here, partly because ransomware seems to be a pretty reliable way to make money. Reliable ways to make money feed spam activity for the obvious reasons.)

MalwareIsOutThere-2016-12 written at 01:32:14; Add Comment

2016-12-17

Some conference spammers mutate to show they're definitely spammers

Years ago, I wrote about the peculiar case of people who spam us with conference announcements. This hasn't stopped in the time since then, of course, but the behavior of various clusters of these people have mutated since then as they move around network areas and spam methods and so on. Lately, one particular group has adopted some habits that make it absolutely, totally clear that they are active spammers and they know it.

For at least the past few months, these people have been sending their message from a constantly changing flux of domains with a consistent naming scheme of:

<user>@mail[0-9]+.<word1>-<word2>.com

The <user> portion is often but not always a letters-then-digits pattern like qhwtsh642 or lvjing348. The two words in the domain are randomly chosen dictionary words, so you get domains like dress-drop.com, proceed-wife.com, seed-rose.com, fashion-opening.com, include-sated.com, and so on. The hostnames all resolve (otherwise we wouldn't accept the messages, since they use this as their MAIL FROM), but the DNS-listed IP addresses for the hosts doesn't respond, resulting in various sorts of messages sitting in our queues trying to go there.

Sadly the spam they send is not recognized as spam by our commercial anti-spam package, so various things get triggered. It is recognized as spam by other people's mail systems, so we do a certain amount of accept-then-bounce of it. At least we're not delivering it to innocent third parties as far as I know, just winding up with it camped out in our queues until it times out.

(Turning off bounces to external addresses is not an option for us in general at the moment; if we think a message is good and we can't deliver it, we've got to send a bounce for it or our users would almost certainly object.)

I haven't extensively checked the source IPs of this or the IPs that the various hosts resolve to, but the ones I've done spot checks on are all in China. I'm not terribly surprised; for as long as I've been getting conference spam and looking into it, China has been a very active source of it (and often for 'conferences' that were to be held in China).

DefiniteConferenceSpammers written at 00:57:43; Add Comment

2016-11-11

My view on accepting bounces and replies to your email

This topic came up in comments on yesterday's entry about Yahoo Groups not accepting bounces of their email, so I'm going to make it an entry and elaborate on my views here.

My views on accepting bounces are pretty simple: if you send out email using anything but the SMTP null sender, you have a responsibility to accept bounces of it back. In fact, not just bounces alone; bounces and replies, because some of the recipients will have out-of-office and other auto-responders (whether implemented on the server or in their IMAP client, and yes I've seen both). Since you have to accept replies and replies may be in arbitrary formats and come from random addresses that are the result of forwarding and other things, in practice you must accept all email to any address that has recently sent out email.

(We can have a rousing debate over whether you 'must' accept email merely to the MAIL FROM of outgoing email or also to the From: or Reply-To: of the email. My pragmatic answer is that there exist systems that will send replies to the latter, so yes, you should.)

By 'accept' I mean merely that your SMTP receiver must accept the message during a SMTP transaction. Technically you may immediately drop the message in /dev/null if you want; your obligation is merely to insure that the mail systems generating bounces and replies are not stuck with either the bounces (as they would be if you don't accept or reject them outright) or bounces-of-replies (as they would be if you rejected replies).

(Throwing bounces away locally is a sign of a spam operation, since you're ignoring delivery failures and will therefor continue grimly trying to email addresses that are simply not working. But that's different from irritating other mail system operators.)

You have no obligation to accept bounces, replies, or even general email from the null sender address to addresses that have not sent email, or that do not send email that will ever leave your domain. In particular, people with sender address verification systems that assume that all addresses will accept email from the null sender are doing it wrong.

(Not that sender address verification is a good idea in general, but there are more worse and less worse ways of implementing it.)

Since modern mailing list systems individualize the MAIL FROM of every outgoing message to every recipient, they have a built in way of knowing what local email addresses have recently sent email and thus should accept it back. Or they can just accept everything if they're going to throw it all away anyways.

When receiving replies I feel that it is legitimate to respect the DMARC policies of the MAIL FROM, even if this causes you to reject some incoming messages. I will wave my hands about rejecting things at SMTP time that are properly identified as spam. In the specific case of mailing list software and VERP, I think you should accept everything since it's just going to automation.

On a purely pragmatic level, I've written before about how not accepting bounces make you look bad and how broken bounce addresses don't fool anyone any more. The pragmatics are pretty clear: if a random new sending domain doesn't accept bounces and (auto-)replies to their email, the odds are very good that they're a spammer. It's not a sure thing, but it is a strong smell and you can expect people to react to it.

(And it's not as if it's particularly difficult or expensive to set up a simple email server that just throws away everything it receives. I even have something that can do this sitting around and I'm pretty sure you could run a high-capacity install of it on the smallest, cheapest instance AWS offers.)

AcceptingBouncesAndRepliesView written at 22:12:23; Add Comment

Yahoo Groups slides further down the spam source slope

I've written about Yahoo Groups' spam problem before and the situation has not gotten any better since 2014. Instead it's gotten worse, as I tweeted:

Yahoo Groups is now refusing to accept bounce messages for their messages, if you had any remaining doubt that it was a spam operation now.

You can pretend to be a legitimate mailing list operation even if you spew tons of spam with individualized MAIL FROM origin addresses (which real mailing list software does too). But this pretense falls apart when your theoretical legitimate mailing list operation stops accepting bounces, because the entire reason to individualize your MAIL FROM addresses is so that you can automatically track bounces of your messages and do sensible mailing list things like automatically remove addresses that don't work any more.

(This particular bounce only exists because for some reason this Yahoo Groups email wasn't scored as spam by our commercial anti-spam system. It was recognized as spam by the place the local recipient forwards their email to, so now we have a bad bounce we have to sit on.)

Of course I'm not so cynical (yet) that I think Yahoo is deliberately turning Groups into a spam operation, or at least I don't think that outside of angry moods when I'm especially grumpy. Instead I expect that it is a combination of two factors. First, Yahoo is just not bothering to spend resources on keeping 'unimportant' bits of Yahoo Groups in operation, and that includes the systems that do or don't accept return bounces. Second, I rather expect that Yahoo has no interest in reducing nominal usage of Yahoo Groups by throwing people off of it. Spammers are probably a very major source of remaining Yahoo Groups volume, which means that throwing them off would cause usage to shrink drastically very fast. That doesn't look good. So Yahoo looks the other way; users are users, right? Never mind what they're sending.

(I believe that Yahoo also attaches ads to every Yahoo Groups email message. More email volume, more ads attached, more revenue coming in, the better that Groups and Yahoo looks, and so on. An aggressive indifference to the consequences of revenue-generating activity is not exactly new, in Yahoo or elsewhere.)

There are parts of Yahoo that I will genuinely miss when the whole thing eventually collapses, like Flickr. But I loath Yahoo Groups with a dull passion these days and will be quite happy to see it die, whenever that comes to pass. Hopefully soon. When it happens, it will be good riddance to bad rubbish.

YahooGroupsSpamII written at 00:08:54; Add Comment

(Previous 11 or go back to October 2016 at 2016/10/24)

Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.