Lately, I have been feeling like a bit of a broken record, each week singing nearly the same tune. Well, this week is no exception. Neosploit has updated again. Starting on May 2, our honeypots again picked up an update to the omnipresent exploit kit.
This time, the update includes a new packer, apparently designed to restrict the unlicensed deployment of the exploit toolkit. The Neosploit packer has always been (dare I say it) innovative. In addition to scrambling variables and ensuring that the exploit delivered is different each time a victim is iframed to an infectious site, Neosploit also uses itself as the key to decode itself. This means that clumsy attempts to modify the decoder in attempt to decode it will result in gibberish, rather then the properly decoded exploits. In addition to this, the new version adds a check to ensure that the exploit is hosted on the intended site. Essentially, what the authors of Neosploit did was append the URL to the exploit kit in the key that is used to decode the exploit.
I am not sure if the intention of this URL-in-key scheme was to slow offline analysis, or if the creators of Neosploit are attempting to restrict unlicensed copies being deployed on other domains, but if I had to guess, it would be the latter. The new version also includes a couple of surprises. It now includes an exploit for the Microsoft Works 7 'WkImgSrv.dll' ActiveX vulnerability. In itself, this speaks about how well the Neosploit kit is maintained. The first public exploit for this vulnerability was also released on the second of May. I am not sure who beat whom—the exploit in Neosploit, or the one that was posted publicly.
In any case, this new exploit is stopped by the HTTP MS Works 7 WkImgSrv ActiveX Code Execution signature on NIS 2008, NAV 2008, and N360 v2. It is also likely that the HTTP Malicious Toolkit Download Activity signature may be triggered.