myNetWatchman   KnowledgeBase

Pooling knowledge to
secure the internet.

Nabbing a Spammer

The initial products which deliver Messenger Spam weren't very smart. Some used the equivalent of 'net send' which utilized a TCP connection. Others were RPC based, but their RPC calls were transported using connectionless UDP that still required an RPC-level acknowledgement before the message would be actually displayed to the user. In either case, two way communication was required, making address spoofing nearly impossible.

Sometime in Q1 of 2003, Messenger Spam products began enabling the 'broadcast' and 'Idempotent' flags in their RPC calls (the myNetWatchman PopUP tester utilized this approach from day one). Setting these flags enables delivery of Messenger Spam with a single, uni-directional packet. This is significant because this enables the spammer to send a message without needing to receive any communication from the target making for much faster delivery, and more importantly, enabling message delivery using a forged source address!

In September 2003, I identified capture a source IP that was apparently sending over 1500 messages/second or over 4.5Mbps traffic from what appeared to be a dialup IP of a major US provider. After speaking with with a security contact at the ISP he confirmed that he was receiving about 400 complaints a month regarding that IP, but had verified that the IP definitely was not actually sending such traffic...evidently a case of spoofed Messenger SPAM.

What we have here is Spammers nirvana, a spam technique which requires almost no startup costs, no mailing lists, an ability to reach millions of eyeballs, and (if sent correctly) virtually untraceable.

While compiling my research on sources of Messenger Spam, I noticed a significant percentage of it originating from the source IP 202.131.221.61. This would signify that the spam is originating in China. But analysis of this traffic revealed an ending TTL (time-to-live) of the packets of 48 and 53. Assuming a starting TTL of 64, that would mean the spammer is only 16 and 11 hops away from me. Thus, my conclusion that this traffic is NOT actually coming from China, but a much more local source, probably somewhere in the US or Canada.

This is a good opportunity to test an idea that I've had for backtracing the source of spoofed traffic... I call it "TTL Triangulation"; it works much like a GPS receiver — by collecting spam packets from various locations and comparing the TTLs we should be able to hone in on the actual source of this traffic. Details of this on-going investigation are posted in the security forum of DSLReports and can be read here. Findings will be posted here.