I recently wrote about how a misbehaving SMTP sender fooled me about some malware volume because it kept retrying the same message over and over despite getting permanent SMTP rejections. This made me interested in getting some numbers on how our malware rejections break down in terms of how many repeats, how many sources, and so on. All of the following figures are for roughly the past four and a half weeks.

The starting figure is that over this time we've done 2,729 rejections for malware and viruses. About 175 of these are have the same sending IP, sender address, destination address, and detected malware as other entries, making it very likely that they're resends. The most active resent message was rejected 97 times (that was the one with an ISO); after that we had one rejected 10 times (with 'CXmail/OleDl-AG'), one 8 times (with 'CXmail/OleDl-AL'), four that were rejected 3 times, and a whole fifty five that were rejected twice.

The resends came from 15 different IPs, including two other mail servers at the university; since these mail servers work properly, the 'resent' messages were actually more or less duplicated messages. It's possible that they originally came from different source IPs. Overall it seems that bad SMTP servers that resend in the face of permanent SMTP rejections are pretty uncommon.

(Since I'm blindly looking at messages across a very wide time range, it's possible that a number of the other 'resends' are really duplicate messages created by long-lived malware with insufficient variety in its sender addresses. Over four weeks, it's certainly possible that such malware would revolve around to targeting some of our addresses a second time.)

These 2,729 rejections came from only 124 different IP addresses (including a number of other mail systems at the university), with much of the volume coming from some very active sources:

   649 115.59.74.248
   443 115.59.74.242
   227 27.50.138.69
   210 115.59.74.243
   196 115.59.74.249
    97 103.4.122.16
 [...]
    41 27.50.138.100

115.59.74.0/24 is SBL387172 and 27.50.138.0/24 is SBL387171, both listed as 'suspected snowshoe spam' ranges. A few other less active IPs are in the CSS, SBL388761, and SBL383008. Somewhat to my surprise, only 24 of the IPs are currently in the XBL, although many of the earlier senders may have aged out.

(The true volume of malware from these SBL listed IPs is likely to be clearly higher than this, since some of their email will have been rejected at the RCPT TO phase.)

Only eight of the IPs sent us more than one type of malware, and a number of them are other mail systems that are forwarding email to some of our users and thus are aggregating a number of different real sources together. The 115.59.74.0/24 block sent us 'Mal/Phish-A' and 'Troj/Phish-BPZ'; the 27.50.138.0/24 block sent us 'Mal/Phish-A'.

(Since these were detected as malware, they were almost certainly HTML files as attachments, which is the pattern we've seen.)

However, many of the active sources tried to send email to quite a lot of different addresses here, as shown by a top five count:

   140 115.59.74.242
    99 27.50.138.69
    74 115.59.74.243
    64 115.59.74.248
    61 115.59.74.249

This is basically the pattern I would expect from spam sending operations, which is what these are. Aggregated together, 115.59.74.0/24 tried to send to 203 different addresses and 27.50.138.0/24 tried to send to 110. A lot of the destination addresses were targeted repeatedly in both cases.

With one exception, the most popular sender addresses were random GMail addresses like 'thivisid08@gmail.com'. The exception is 'quickbooks-email@notificationsystem.org', which was used for 27 messages from 21 different IPs, all trying to deliver a 'CXmail/OleDl-V' malware payload. Overall there were 1,610 different sender addresses, but 1,559 of them were GMail addresses.

(I was going to say that none of these would pass GMail's DMARC policy, but apparently Google blinked on their plans for a strict one. Right now GMail still publishes a 'p=none' DMARC policy that doesn't ask people to reject email that fails to pass DKIM and/or SPF tests.)