Normally, spammers tend to rely on very small spam messages because their goal is to get as many spam messages out as cheaply as possible. They also save on bandwidth costs this way. But with more and more hosting companies offering ‘unlimited’ bandwidth, spammers have started using ‘large size’ spam files.
Why would they do that? Well, the simple answer is that many spam filtering devices and software intentionally only scan smaller messages. The larger the message, the more overhead and processing power needed; rather than let their systems get overloaded, they ‘assume’ that larger messages are less likely to be spam.
Many of the most popular free spam filtering software by default are set to only scan messages up to a certain size, typically 500kb to 1 MG in size (eg. SpamAssassin). So the spammers are taking advantage of this by creating a small message and filling the rest of the email with garbage specially designed to create more overhead, often to confuse other techniques such as ‘Bayesian’ filter.
For those filters which do scan larger emails, if they happen to utilize Bayesian learning anti-spam methods, the content of these large emails can easily ‘poison’ the learning system.
Where is this large size spam coming from? This particular method seems to come mainly from cheap hosting IP space, accompanied with cheap, newly registered domain names. Here is an example list of some of the IPs that we’ve seen sending such spam in the last 24 hours:
22.214.171.124 x1 static.cmcti.vn 126.96.36.199 x1 frash.storonitor.net 188.8.131.52 x1 sbesos.bodybuildids.com 184.108.40.206 x4 rainboterprises.com 220.127.116.11 x1 redi.rainboterprises.com 18.104.22.168 x1 unassigned.psychz.net 22.214.171.124 x1 unassigned.psychz.net 126.96.36.199 x1 unassigned.psychz.net 188.8.131.52 x1 unassigned.psychz.net 184.108.40.206 x1 unassigned.psychz.net 220.127.116.11 x1 unassigned.psychz.net 18.104.22.168 x1 unassigned.psychz.net 22.214.171.124 x1 unassigned.psychz.net 126.96.36.199 x20 ohost.harmoketing.com 188.8.131.52 x22 piber.harmoketing.com 184.108.40.206 x2 trell.sitecords.net 220.127.116.11 x1 smpx.sitecords.net 18.104.22.168 x3 ohsaki.liohinery.com 22.214.171.124 x4 tauton.liohinery.com 126.96.36.199 x1 clouare.net 188.8.131.52 x1 blez.clouare.net 184.108.40.206 x3 iclnm.tipsray.net 220.127.116.11 x2 picnet.tipsray.net 18.104.22.168 x4 ohocn.ticketare.net 22.214.171.124 x3 zemal.finanouth.com 126.96.36.199 x2 donela.finanouth.com 188.8.131.52 x3 yoyita.finanouth.com 184.108.40.206 x4 tipsray.net 220.127.116.11 x1 khabhi.precioement.com 18.104.22.168 x1 redi.precioement.com 22.214.171.124 x1 febric.precioement.com 126.96.36.199 x1 sarv.powworks.net 188.8.131.52 x1 midpc.beacsultants.com 184.108.40.206 x3 atl21.genesitwork.com 220.127.116.11 x3 midpc.genesitwork.com 18.104.22.168 x1 carum.genesitwork.com 22.214.171.124 x4 fortuompany.net 126.96.36.199 x5 wbc.fortuompany.net 188.8.131.52 x2 midnigales.net 184.108.40.206 x2 majela.midnigales.net 220.127.116.11 x5 uznews.midnigales.net 18.104.22.168 x6 gcnext.mayfairroup.com 22.214.171.124 x1 ohsaki.mayfairroup.com 126.96.36.199 x4 picao.greenfup.net 188.8.131.52 x4 vedla.greenfup.net 184.108.40.206 x5 ohours.portrated.com 220.127.116.11 x1 starz.portrated.com 18.104.22.168 x4 sourlthcare.net 22.214.171.124 x3 pop3.sourlthcare.net 126.96.36.199 x6 ohotka.sourlthcare.net 188.8.131.52 x1 raik.boosnture.com 184.108.40.206 x1 prope.boosnture.com 220.127.116.11 x1 ohrs.boosnture.com
As you can see, virtually all of these domains were recently registered. Some didn’t even bother to update the PTR/reverse DNS record. Some domains are present in different subnets, while others are neatly sequential. You can bet that if you looked up some of these subnets, there will be more of these IPs waiting for their trigger to be pulled.
So what exactly can be done to defend against this? As always, the onus is on the network providers allowing this type of activity to happen on their IP space. They should have systems in place to detect such a spike in bandwidth, especially considering this behavior is both bulk email on top of the large file size. Too many providers turn a blind eye towards such activity when suspicious PTR records and utilization of multiple mail servers should be enough of a hint.
Technically it is quite simple for hosting providers to detect large bandwidth increase of SMTP traffic. This type of attacker SHOULD be stopped at the source.
On the defending side, RBLs and distributed systems can mitigate this type of spam hitting inboxes. RBLs with the technology to detect such activity are a boon to those mail servers who do not have the means.
There are also ‘Distributed’ feeds available. They can detect those servers engaged in such activity, and report it to the very same RBL’s instantaneously to help others.