Thursday, October 23, 2014

Where does all the spam come from?

This is part 3 in a series investigating a particular piece of malware.
  • Part 1 looks at how the malware is delivered. It and part 2 were originally a single post, later separated since they look at distinct phases in the attack.
  • Part 2 analyzes the bot - the agent which turns your computer into a remotely-controlled robot doing the attacker's bidding.
  • Part 3 dives into the first payload: code to test 30,000 addresses at 5,000 domains, to see if they could be used to send additional spam.
Ever wondered how spam ends up in your inbox, or how spammers come up with the email addresses from which to send spam? The spammer needs a few things in order to send messages: obviously he needs a list of target email addresses to send messages to; those can be bought on the dark market at very little cost. Unless he wants to send email from his own server though, he also needs an abuseable email relay server and spoofed source address. Why? Two reasons – not every Internet provider would turn a blind eye to a spammer sending millions of malicious email; and he can gain far more capacity by sending mail through thousands of open relays.

In part one of this series, I took a look at an email message carrying a malicious link, and discussed some of the tactics used to trick you into following that link. Part two dove into the malware delivered via that link, which turned out to be a botnet client – software that turns my computer into a remote-controlled agent of the attacker’s botnet, standing by for orders from the bot master to do anything the attacker wishes. In part three, my bot has now received instructions.

At the end of my previous post, the botnet agent was making an HTTP POST request to two IP addresses in Russia every 9 minutes; one request always resulted in a server error response, while the other resulted in an empty “OK” response. Essentially my computer was awaiting orders. Today I resumed the virtual machine that I had infected, and found quite different results.

The bot still reaches out to hxxp://, POSTing a form value that I assume is a unique identifier for this bot, and still gets the same HTTP 500 internal error response. It still repeats the request with hxxp://, but here is where things change. Instead of getting an empty reply, the response includes a 69 byte attachment of type “application/octet-stream.” This indicates some sort of a binary attachment, possibly a document format or an executable file, but given the lack of any filename I think it more likely that the bot master simply encodes instructions in this MIME type.

The bot next makes a DNS lookup for, again using Google’s public instead of the DNS provider I configured on my DHCP server (clever, because it avoids the DNS-based malware block I use). It then makes a request for and downloads hxxp:// Once that file is downloaded, a new process appears on my PC: KB115576390.exe. At this point I conjecture that rttt.exe was saved locally as KB[random number].exe and then launched. This is clever, because Microsoft update patches often are named KB########, so it is not at all unusual to see such a program running … when your PC is performing Microsoft updates. My computer is not doing so right now.

With the new process running, the next thing I see in Wireshark is a DNS query for (this time using my DHCP-provided DNS service; apparently the bot agent uses Google’s public DNS, but this particular payload goes with whatever is available on the client). It then makes a POST request for hxxp://, to which I get an empty OK response. However, it is followed by a GET request for the same, to which the response is as follows:



Oh, and surprise: the domain is hosted on the same Russian ISP as the previous IP addresses.

What do you think happens next? It downloads hxxp://
, which is a list of 5,000 domain names, many beginning with mail or smtp (reprinted below). It follows that by requesting hxxp:// That’s not suspicious at all, is it? I suspect each bot agent is instructed to retrieve a different list of domains from the pass_bot_pull folder, so the attacker can farm out the next probing activity to thousands of bots and in aggregate test millions of domains.

[login.txt contents]


With both files downloaded, my computer sends a POST request to hxxp:// with one value: “status=1.” My guess is this is a message back to the bot master saying “I successfully downloaded the data and will carry out the instructions.”

That's all fine and dandy, but what is this payload actually doing? For each domain in the list, the bot opens an SMTP (Simple Mail Transport Protocol, i.e. the foundation to Internet email) connection, then tries to authenticate using email address info@[domain] and password "welcome." "welcome" was one of the values seen earlier.

What does this mean? Since I did not allow the malware to continue, I cannot see the final state, but I can make an educated guess.

It appears that the bot master has collected a vast list of domain names, and is enlisting bots to systematically connect to each one and see if it will allow sending email from an address one would expect to exist on the domain ([email protected] is pretty standard). Since the value used as a password was part of the instructions from the C&C server, I would bet many different bot agents were given the same list of domains with different passwords to try. Presumably, the bot is supposed to collect a list of any that are successful and return it to the master, who then has a list of SMTP relays and authenticated accounts through which to send new spam.

Lessons? First, don't click the link. More in keeping with today's post though, if you run an SMTP server, make sure it requires authentication, and that authentication is via a strong password, and monitor for failed logins, even logins from different sources. If feasible, also monitor for successful logins from unexpected places.

As a side note, this post covers one of the ways spammers carry our their spam campaigns; security researcher and former Washington Post reporter Brian Krebs wrote a book to be released this November, that goes deep into the organizations behind these campaigns. I am looking forward to reading this book myself. If you are interested in the topic, consider purchasing it via the link at the right - I do not get paid to blog but earn a small commission on purchases made through this link.

Below is the list of 5,000 domains probed in this particular attack:

Do you have something to add? A question you'd like answered? Think I'm out of my mind? Join the conversation below, reach out by email at david (at), or hit me up on Twitter at @dnlongen