Trojan.Peacomm Part 2 – The Botnet Evolves
Since I posted my blog last Friday, the Trojan.Peacomm threat has (not surprisingly) evolved. The attachments have new filenames, some dropped files have changed, and the subject lines of the spam email are also changing. Please have a look at the full details in our updated write-up here.
The bot machines are now communicating over UDP port 7871, instead of port 4000. Symantec’s Threat Management System confirms this change:
Figure 1. IPs originating activity - UDP port 7871
More interestingly, the new version of the threat has fully fledged rootkit capabilities, albeit not very sophisticated. It would appear that the malware writers were in a rush to get the new version out as quickly as possible and some functionality of the rootkit has not been implemented correctly.
It is now capable of hiding several files and registry keys by hooking several kernel functions and patching the tcpip.sys system driver to hide its ports from commands, such as netstat -o or netstat -b. However, due to some mistakes in the rootkit code, running netstat -an lets you see ports 7871 or 4000 open and waiting for connections. It is also important to note that a personal firewall will also notify you of the process services.exe trying to make connections on these ports. Furthermore, the rootkit service can be stopped by running a simple command: net stop wincom32. All files, registry keys, and ports will appear again.
There is also code in the threat that will prevent it from executing if it detects the machine is running Windows 2003. We presume the malware writers didn’t have time to test it on this operating system. The rootkit driver is not free of bugs either, and in some cases it causes the system to crash and reboot.
So, what is the purpose of all this renewed activity, you ask? The primary goal is to create a botnet that sends tons and tons of penny stock spam (but because the botnet can be controlled by its owners, we may see changes in functionality). During our tests we saw an infected machine sending a burst of almost 1,800 emails in a five-minute period and then it just stopped. We are speculating that the task of sending the junk email is then passed on to another member of the botnet. My colleagues in the antispam team are seeing greater activity, too. Of course, users of Symantec’s Brightmail are also protected from this latest spam run.
The good news is that, just the same as yesterday, Symantec customers remain protected by our detection and remediation technology present in the latest, up-to-date versions of our products.