This past week, we posted some of Cutwail’s recent spamming activity. As we were digging into the elevated levels of Cutwail activity, the researchers over at Shadowserver posted on the unusual SSL traffic originating from infected hosts. Dark Reading picked up the story and came up with question marks, “what is Pushdo up to?”:
“It’s unclear thus far whether this is a test-run for phony SSL connections gone amuck that ended up exposing this Pushdo [Cutwail] traffic, or something else. Stewart says it’s possible there could be more to the latest activity, such as the botnet’s rotating its target lists. “It’s hard to say,” he says.”
Having recently researched the downloader, we took a second look. The answer to the question “what is Pushdo [Cutwail] up to?”…the heavy SSL traffic Cutwail is sending to these new sites is a result of coding error. The Cutwail writers wanted to cloak their connections to their own payload sites listed in our previous post, and released an implementation that failed to meet that delicate goal. Instead, they killed a fly with a sledgehammer. While they could have implemented a few minor tweaks to make the SSL connections to decoy sites appear more “web browser like” to a network monitor, they failed to do so and wrote unnecessary unreliable dependencies into their SSL connection rate limiter. Also, the rate limiting code is implemented in such a way that it simply would not used to evade DDoS tracking. We observed two sets of routines in the code that form the basis of that conclusion…
As described in our previous post, 1. downloader code is injected into a spawned SVCHOST.exe.
2. Within this thread, the delimited list of payload serving hard-coded addresses are split into individual strings:
75.126.159.19:443;75.126.159.19:443;89.149.254.213;
89.149.244.141;94.75.233.173:443;94.75.233.174:443;
94.75.233.171;94.75.233.172;89.149.244.23;
aaa.oduvanchic.com;aaa.news2days.ru;firea*seye.com;
f*ckbriankrebs.com;antisgetout.cn;
3. The SSL “camoflauge thread” (the one that connects to the cia, google, and legitimate site) is started
4. An RC4 encryption key is generated based on the value returned in the “lowpart” value returned from a QueryPerformanceCounter call
5. An attempt is made every 20 seconds to download the spam bot payload from the above list of addresses using the generated RC4 key
6. When a payload has been downloaded, it is decrypted using the above key, and executed directly or injected into another SVCHOST.exe process
7. After succesful execution, the mutex “00012-1010212-12012012-1211″ is created
In the background the camoflauge thread is busy doing the following actions:
1. Attempts to open the mutex “00012-1010212-12012012-1211″
2. If the mutex is not found, it will spawn a thread to perform a fake ssl transaction with a random hostname from the embedded list (of legitimate sites or “decoys”) every 5 seconds
3. If the mutex *is* found, the thread will stop launching fake ssl transactions and exit
What this means in plainer terms is that a flurry of fake SSL connections are continuously launched until the payload is succesfully downloaded, after the mutex to stop making new connections is created and accessed. What happens if the payload servers are taken down (as we saw in our research lab), and a payload is never downloaded from these sites? It means no ’stop’ mutex will be created by the initial Cutwail thread on the infected host and then found by the SSL camoflage thread, and the half baked SSL connections will continue to bombard the decoy sites!
