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:

101.99.3.172	x1	static.cmcti.vn
103.48.119.113	x1	frash.storonitor.net
103.48.119.118	x1	sbesos.bodybuildids.com

103.94.27.152	x4	rainboterprises.com
103.94.27.153	x1	redi.rainboterprises.com

108.171.245.162	x1	unassigned.psychz.net
108.171.245.163	x1	unassigned.psychz.net
108.171.245.164	x1	unassigned.psychz.net
108.171.245.165	x1	unassigned.psychz.net
108.171.245.169	x1	unassigned.psychz.net
108.171.245.170	x1	unassigned.psychz.net
108.171.245.172	x1	unassigned.psychz.net
108.171.245.174	x1	unassigned.psychz.net

109.169.40.42	x20	ohost.harmoketing.com
109.169.40.43	x22	piber.harmoketing.com

162.144.53.204	x2	trell.sitecords.net
162.144.76.171	x1	smpx.sitecords.net

162.211.122.124	x3	ohsaki.liohinery.com
162.211.122.125	x4	tauton.liohinery.com

162.251.61.129	x1	clouare.net
162.251.61.52	x1	blez.clouare.net

185.79.250.144	x3	iclnm.tipsray.net
185.79.250.146	x2	picnet.tipsray.net
185.79.250.150	x4	ohocn.ticketare.net
185.79.250.153	x3	zemal.finanouth.com
185.79.250.154	x2	donela.finanouth.com
185.79.250.155	x3	yoyita.finanouth.com

185.79.251.32	x4	tipsray.net

188.212.121.31	x1	khabhi.precioement.com
188.212.121.33	x1	redi.precioement.com
188.212.121.34	x1	febric.precioement.com

52.144.46.102	x1	sarv.powworks.net
52.144.46.108	x1	midpc.beacsultants.com

54.39.35.1	x3	atl21.genesitwork.com
54.39.35.10	x3	midpc.genesitwork.com
54.39.35.11	x1	carum.genesitwork.com
54.39.35.2	x4	fortuompany.net
54.39.35.5	x5	wbc.fortuompany.net
54.39.35.6	x2	midnigales.net
54.39.35.8	x2	majela.midnigales.net
54.39.35.9	x5	uznews.midnigales.net

70.36.114.212	x6	gcnext.mayfairroup.com
70.36.114.213	x1	ohsaki.mayfairroup.com

89.37.227.150	x4	picao.greenfup.net
89.37.227.151	x4	vedla.greenfup.net
89.37.227.152	x5	ohours.portrated.com
89.37.227.153	x1	starz.portrated.com
89.37.227.154	x4	sourlthcare.net
89.37.227.155	x3	pop3.sourlthcare.net
89.37.227.156	x6	ohotka.sourlthcare.net

95.211.102.171	x1	raik.boosnture.com
95.211.102.176	x1	prope.boosnture.com
95.211.102.188	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.