Wandering Thoughts archives

2015-04-29

The 'EHLO ylmf-pc' plague of SMTP authentication guessers

If you run a mail server on the Internet and look at your logs, you may have noticed a lot of connections from machines that EHLO with the name ylmf-pc. There are many pages about this on the web, and the general consensus is that this is some sort of long standing brute force SMTP authentication guessing botnet or piece of software. Whatever it is, it's quite annoying and may also be unevenly distributed in action.

(I've mentioned them before in passing.)

I can't say with any confidence what it is, because it also seems to be pretty dumb and limited. Our new authenticated SMTP server doesn't offer authentication before you STARTTLS, but it will afterwards. This can't be an uncommon configuration, yet I see a whole plague of ylmf-pc machines connecting to it and then immediately disconnecting without trying anything more (and in particular without STARTTLS). It's as if they connect, examine the EHLO response, see no authentication advertised, and then immediately disconnect.

Of course, that's when the real annoyance comes in; these machines aren't content with doing this just once. Oh no. A ylmf-pc machine will do this same connect, EHLO, then disconnect cycle over and over and over again, very fast. Our logs typically show multiple connects and disconnects a second. We have firewall connection limiters that cut in to temporarily block these IPs, but otherwise a ylmf-pc machine will also keep doing this for quite a while. This creates quite a bunch of log spam, even with the firewall blocking IPs for us.

I was going to confidently say that the ylmf-pc plague hits some of our machines much more than other ones and speculate about why, but it turns out that I can't; our inbound MX gateway doesn't even log machines that do this connect then disconnect game, so I can't tell whether or not the ylmf-pc brigade is ignoring them. They do seem to do at least a little bit of scanning of the Internet in general, but they also seem much more concentrated on machines with MX entries and machines with suggestive DNS names (such names seem to cause spammers to show up fast, although I haven't tried a scientific test of this).

(This is apparently the signature of a botnet called 'PushDo' or 'Cutwail', per this stackoverflow question and answer (also). The oldest mention I can find in my own logs is November of 2013, but it looks like this pattern may go back to 2012 and possibly earlier.)

YlmfPcPlague written at 01:37:19; Add Comment

2015-04-12

Spam victims don't care what business unit is responsible for the spam

So what happened is that the other day I got some spam that our MTA received from one of the outbound.protection.outlook.com machines. Since sometimes I'm stubborn, I actually tried reporting this to abuse@outlook.com. After some go-arounds (apparently the Outlook abuse staff don't notice email messages if they're MIME attachments), I got the following reply:

Thank you for your report. Based on the message header information you have provided, this email appears to have originated from an Office 365 or Exchange Online tenant account. To report junk mail from Office 365 tenants, please send an email to junk@office365.microsoft.com and include the junk mail as an attachment.

Ha ha, no. As I put it on Twitter, your spam victims don't care about what exact business unit is responsible for the specific systems or customers or whatever that sent spam. Sorting that out is your business, not theirs. Telling people complaining about spam to report it to someone else is a classic 'see figure one' response. What it actually means, as everyone who gets this understands, is that Microsoft doesn't actually want to get spam reports and doesn't actually want to stop spam.

Oh, sure, there's probably some internal bureaucratic excuse here. Maybe the abuse@outlook.com team is being scored on metrics like 'spam incidents processed per unit time' and 'amount of spam per unit time', and not having to count this as 'their' spam or spend time forwarding the message to other business units helps the numbers out. But this doesn't let Microsoft off the hook, because Microsoft set these metrics and allows them to stand despite predictable crappy results. If Microsoft really cared, outlook.com would not be the massive spam emitter that it is. Instead Microsoft is thoroughly in the 'see figure one' and 'we're too big for you to block' business, just like a lot of other big email providers.

(For people who do not already know this, 'see figure one' refers to a certain sort of grim humour from the early days of Usenet and possibly before then, as covered here and here. The first one may be more original, but the 'we don't care, we don't have to, we're the phone company' attitude is also authentic for how people read this sort of situation. Application to various modern organizations in your life is left as an exercise to the reader.)

BusinessUnitIndifference written at 02:03:08; Add Comment


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.