This was done on a winxp, sp2, fully patched box, no A/V, no host ids, no tinkering with internet settings in IE, and has firefox installed. No restrictions on outbound traffic.
Following the link (in IE) I received from some random person I don't know, telling me about some account I never signed up for, and a link that isn't even hidden (it's just plain http://xxx.xxx.xxx.xxx) in the mail, took quite a considerable effort to click past all the warnings to try and get the binary to download and everything to "run" right. I actually had better luck via FireFox in getting the binary. Once I double-click on the downloaded binary, and click past numerous errors and warnings... the trojan runs finally.
Now you owe my 2 year old a word of thanks, because daddy had to trojan her laptop to get all this to work.
The binary being downloaded seems to mutate rapidly, so looking for that isn't a great idea. It's also further obfuscated by being gzipped and chunked. What you could do, is write a custom signature using the string-tcp engine, *from* #WEBPORTS, regex string = "Server[:]\x20nginx" without the quotes to identify hosts attempting to download the trojan, but if the server type changes or there's a legitimate server of that type, then you either miss the download attempts or drop legitimate traffic. Really good chance of either a false negative or false positive here, resulting in a not so great fidelity signature. (to note, earlier version of this, the binary was mailed and not downloaded from the web)
Once you get the trojaned binary, and click past all the errors to get it to run, now starts the UDP p2p attempts. Unlike some previous versions I've seen, this one hits any number of hosts on random destination ports, but all comes from the same source port (and this may change in some future version). If enabled, signature 4002 will trigger, and the infected host will show up as the "victim", provided the UDP traffic is all allowed to pass in/out. So, depending on what's allowed out past your firewall, and what can come back in, your mileage may vary with this signature.
The following custom signature can be used to identify infected hosts, attempting to connect to the p2p network:
engine = atomic-ip
specify layer 4 protocol = yes
layer 4 protocol = UDP
specify payload inspection = yes
regex string = \xe3[\x0a-\x0f]
specify exact match offset = yes
exact match offset = 1
event count = 50
specify alert interval = yes
alert interval = 10
The p2p connects seem to be somewhat consistent in the traffic from different versions we've seen. It's also rather noisy. This signature will catch the connect attempts, and identify an infected host, but it comes with a price. The sensor has to analyze every UDP packet as we don't specify any source or destination port, so this can be cpu intensive to the sensor.
**WARNING** This custom signature above could affect sensor performance **WARNING**
We're still evaluating releasing the above signature, that detects the p2p attempts and identifies infected hosts, into a signature update.
If we can establish the p2p connections, now we start sending out emails to all sorts of places, providing them links to click and hopefully trojan themselves in a similar fashion. In this case (this variant), signature 3030 fires because of the numerous smtp connections attempted. Hopefully, the only outbound smtp allowed past the firewall is from the mail servers, so here a simple acl or firewall rule will at least help stop the spread and provide a further point to locate infected hosts.
