Over the last few years, we’ve witnessed dozens of Exploit Kits such as the Phoenix Exploit Kit, Eleonore Exploit Kit, Yes Exploit Kit and even some old Exploit Kits such as IcePack and MPack. We’ve observed that most of Exploit Kits don’t last more than one year, except for one…
NeoSploit Administration Login Panel.
Background: The Old NeoSploit
Neosploit Exploit Kit was first seen by M86 Labs in 2007. It was one of the first exploit kits that was developed in order to exploit browser vulnerabilities such as MDAC RDS and ActiveX vulnerabilities. The NeoSploit Exploit kit then evolved to spread the attack vector via the Adobe Reader Collab CollectEmailInfo vulnerability.
In April 2008, the NeoSploit team released Version 3 which included improved statistics and configuration control as well as a stabilized and sophisticated exploit package. However, in July the team announced it would stop supporting and updating the Neosploit project due to financial problems. This lead to a rapid decline in Neosploit’s prominence in the wild until it disappeared. Rumors began to spring up that the source code of Neosploit had been leaked.
The Return of Neosploit
At the end of 2009, we noticed a new trend of obfuscation techniques that were pretty similar to what we have seen before from the notorious NeoSploit Exploit Kit. Since seeing the first occurrence of this new version of NeoSploit, the concept has stayed the same.
Snippet Obfuscated Code from November 2009.
Snippet Obfuscation Technique from a New Version.
The obfuscated scripts above, both versions generate a decryption algorithm function and a unique key that is sent back to the server, which includes the software applications installed on the victims’ machine such as browsers and Adobe versions.
The URL that was Generated Including the Secret Key and Details on the Victim Browser.
In the second phase of the exploitation, the client retrieves the encrypted exploit page with the relevant exploits targeting the vulnerable applications on the victims’ machine. Although we have already seen this encryption technique used by Luckysploit Toolkit more than a year ago, this dynamic obfuscation still makes it much harder for security vendors to block this type of attack.
Low Detection by the Anti-Virus Companies 3/42
Shedding Light on the Architecture of Neosploit
Not only has the Neosploit team upgraded their obfuscation techniques, they’ve also put a lot of thought into the architecture of the toolkits backend. Unlike other exploit kits, where the authors sell the toolkit itself (in some cases the source code is encrypted and could work only under a certain domain) , the users of the Neosploit Exploit Kit don’t need to have the source code or even the compiled version of the tool. The Neosploit backend is activated only by the team itself and the users just receive access to use it, effectively establishing a business model of Malware-as-a-Service.
The URL pattern of the infection page is exactly the same on each attack:
| be—[REMOVED]–we.info/XXXX/shop.php |
XXXX – in the sample above, the request is caught by the apache/nginx configuration and sent to the backend server, as described in the sample below.
| location /XXXX/ { proxy_pass http://–[REMOED IP ADDRESS]–:8333/XXXX/; proxy_redirect http://–[REMOVED]–/ http://$ host/; proxy_set_header Host –[REMOVED]–; proxy_set_header Client-Host $ host; proxy_set_header Client-IP $ remote_addr; } location ~ \.(php|inc)$ { try_files $ uri =404; root html; fastcgi_pass 127.0.0.1:8888; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/local/nginx/html$ fastcgi_script_name; include fastcgi_params; } } |
The above code was taken from a Neosploit nginx configuration file. It redirects every request that includes a certain pattern to the backend server and adds a certain key to the header request.
The architecture that is being used by Neosploit team is very effective by several layers:
- It simplifies the installation of the toolkit on the server, while the users don’t need to install the toolkit itself, just redirecting the request to the backend server
- It is much harder to expose the team behind the toolkit
- It simplifies the toolkit update procedure
Neosploit 4 Control Panel
Just as we mentioned above, the attacker does not need to have any interaction directly with the backend server; the attacker could monitor and manage the progress of his attack via a proxy that connects to the backend server.
The control panel of the Neosploit has not changed much:
Administration Panel of Neosploit 4 – Daily Stats
Pay attention to the amount of incoming traffic redirected to the toolkit, in addition the high infection rate of the toolkit – above 20 percent.
The control panel of the toolkit includes the version of the toolkit: Version 4.2 (build 4281). As described above, the Neosploit team is capable of updating the toolkit, thus simplifying the process for their customers.
Neosploit 4 Configuration Rules of the Payload
The customer doesn’t host the payload on their own server; they upload it via the Neosploit control panel, which allows them to define a payload for each operation system, country and browser:
Neosploit 4, Country Statistics of a Certain Attack Day
Neosploit 4, Browser Statistics.
The fact is that almost four years after the first version of the Neosploit project was published, the project continues to thrive and remain active. This showcases the fact that a good product can survive over time, so long as it is being maintained and adjusted to keep up with security trends to allow it to stay ahead of the curve.
Full story: M86 Security Labs Blog
