Opened 22 months ago

Last modified 22 months ago

#17855 new defect

flashproxy-reg-email detected as Kelihos botnet spam by the CBL (Composite Blocking List)

Reported by: dcf Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Since about 2015-12-01, the email that flashproxy-reg-email sends triggers a false-positive detection in the CBL (Composite Blocking List) which causes other email sent from the same IP address to be rejected by some recipients (including Shortly after flashproxy-reg-email running, the lookup page says something along the lines of:

IP Address x.x.x.x is listed in the CBL. It shows signs of being infected with a spam sending trojan, malicious link or some other form of botnet.
It was last detected at 2015-12-07 03:00 GMT (+/- 30 minutes), approximately 3 hours, 30 minutes ago.
This IP is infected (or NATting for a computer that is infected) with the kelihos spambot. In other words, it's participating in a botnet.

Everything about Kelihos and botnets is false; through experiments and interaction with a CBL operator we isolated the cause to flashproxy-reg-email's messages.

An example of a bounce message caused by this error is:

SMTP error from remote mail server after RCPT TO:<...@…>:
host []: 550 5.7.1 Service unavailable; client [x.x.x.x] blocked using

We should do something to avoid these false detections if possible.

Child Tickets

Change History (2)

comment:1 Changed 22 months ago by dcf

Someone called Andy at the CBL says:

Fix the EHLO to be something that matches the rest of the infrastructure and you shouldn't have any further listings from us.

Here's an SMTP transcript of a flashproxy-reg-email session. The reason we use [] is we don't know our own IP address until we receive one of the "at your service" lines. We could easily modify the second EHLO line (after STARTTLS) but not so easily the first. If you don't force an IP address, Python smtplib will do something stupid like guess the local hostname with socket.getfqdn.

⇒  EHLO []
 ⇐ at your service, []
 ⇐ 250-SIZE 35882577
 ⇐ 250-8BITMIME
 ⇐ 250 SMTPUTF8
 ⇐ 220 2.0.0 Ready to start TLS
⇒  ehlo []
 ⇐ at your service, []
 ⇐ 250-SIZE 35882577
 ⇐ 250-8BITMIME
 ⇐ 250 SMTPUTF8
⇒  mail FROM:<> size=439
 ⇐ 250 2.1.0 OK xp4si3037295pab.1 - gsmtp
⇒  rcpt TO:<>
 ⇐ 250 2.1.5 OK xp4si3037295pab.1 - gsmtp
⇒  data
 ⇐ 354  Go ahead xp4si3037295pab.1 - gsmtp
⇒  To:
⇒  From: nobody@localhost
⇒  Subject: client reg d60094a2a9
⇒  CaNRg3izH9hQttn8w+1ud2I4eJRas32izai/fgWWKkLSU4eYk8nOdZcXMxtqNfFRn+4JftiHQanl
⇒  qbS6b2yxJ2ygpGasldKm+m3suJx0+0Dm8EOKAZZMkjqTb048a/iSZyxyiuBFa1oaLig8Y+AO9KE4
⇒  UI2Mniq4rQL1QeUEOl35L3TqFvEPe/5e2tHUKbVP8mSclCKqEzcgNvYxgOj2zPUnNRdmhHEBJ85w
⇒  Ryrwim83tFGUcjSDFeYpNwNWvIH5ZigeY31O46iuT0cQV9EYa68Ldo/ZYUsscyRs+AMJJsFzBBhx
⇒  nEPsQTgGoy8Pk+IjxEVCJdA8Htp81n/IeXyNDQ==
⇒  .
 ⇐ 250 2.0.0 OK 1449981129 xp4si3037295pab.1 - gsmtp
⇒  quit
 ⇐ 221 2.0.0 closing connection xp4si3037295pab.1 - gsmtp

comment:2 Changed 22 months ago by dcf

Incidentally, the false detections seem to have started shortly after an incident on 2015-11-24 when the CBL had many Kelihos false positives. The notice is now gone from their home page, but it is archived on a blog page:

November 24, 2015 Widespread false positives
Earlier today, a very large scale Kelihos botnet event occured – by large scale, many email installations will be seeing in excess of 20% kelihos spam, and some will see their inbound email volume jump by a volume of as much as 500%. This isn’t an unusual thing normally, the CBL/XBL has been successfully dealing with large scale Kelihos spam spikes like this, often daily, for years.
The email was allegedly from the US Federal Reserve, saying something about restrictions in “U.S. Federal Wire and ACH online payments.” Not only was the notice itself fraudulent, the attached Excel spreadsheet (.xls) contained macro instructions (a downloader) to download a Windows executable virus, most likely Dyreza or Dridex malware.
The detection rules initially deployed by the CBL unfortunately were insufficiently detailed, and listed a number of IP addresses in error.
As per our policy, all entries of this type were purged (by about 19:05 UTC), and the detection heuristic removed.
If you were listed up to around 19:00 UTC, and the CBL lookup page appears to indicate that the IP is no longer listed, this is likely the explanation, and no further action is required on your part.

I unlisted my server after they adjusted the detection rules and it got relisted again, so whatever they changed did not fix this particular false positive.

I found out this was happening because I run hourly flashproxy test scripts from a host that I also send email from. The flashproxy test scripts usually use flashproxy-reg-appspot, but when that fails (which is less than once a day), it falls back to flashproxy-reg-email. So unlisting would get the server unblocked until the next time flashproxy-reg-email ran.

Note: See TracTickets for help on using tickets.