Over the last few years, Symantec has observed a substantial rise in the use of exploit kits. There are several kits that have come and gone, but a few of them have survived the competition—Neosploit being among them. This blog will discuss the Neosploit toolkit's specific functionality of employing JAR files to deliver malicious files.
Neosploit was first seen by Symantec in March 2007. Since then, the kit has evolved to be one of the "finest" exploit kits to date. Malicious users have never stopped using this kit, despite the fact that there is news that this infamous toolkit’s development has been shut down.
Neosploit exploits various client-side browser vulnerabilities. By and large, Neosploit's malicious users will plant obfuscated JavaScript on legitimate sites. When an innocent user visits a compromised website, he or she is unknowingly infected.
Neosploit uses a variety of techniques for obfuscation. Among these techniques, the most prevalent one (which is still found today) is the “Twitter trends” URL-generation trick. During runtime, the obfuscated script de-obfuscates itself and obtains Twitter trends results. It subsequently uses the data to build a dynamic URL that is used to reach the Neosploit server. The script first uses the data from Twitter to form a variable ‘ShiftIndex’. It later uses the same variable to build the URL. In Figure 1.1, below, we can see how the script uses Twitter trends to form the 'shiftIndex' variable:
Fig 1.1: De-obfuscated script that makes use of Twitter trends
When the ‘shiftIndex’ variable is evaluated to be greater than “0”, it goes into a loop that builds the URL using a set of predefined ARRAYS and certain mathematical calculations. The final URL for the Neosploit server is in the variable “r”, as shown in Figure 1.2.
Fig 1.2: De-obfuscated script that builds the URL
The browser then reaches out to the Neosploit server that serves the exploits. Exploits are primarily in the form of PDF or JAR files. The subsequent trick is in the JAR file, which hides the source from which it downloads the malware. The malicious URL is hidden under the ‘Specification-Vendor’ attribute of the MANIFEST file of the JAR archive. Figure 1.3 shows the ‘Specification-Vendor’ attribute’s data.
Fig 1.3: MANIFEST file
When the JAR file is executed, it fetches the ‘Specification-Vendor’ attribute from the MANIFEST file using the ‘getResources’ and ‘getvalue’ functions. A legitimate ‘Specification-Vendor’ attribute is a string that identifies the organization that maintains the extension specification. In this case, Neosploit evidently abuses the use of this attribute. Figure 1.4 shows the Java code that fetches the ’Specification-Vendor’ attribute’s value from the MANIFEST file.
Fig 1.4: Code fetching data from MANIFEST file
When decoded, the extracted string from the MANIFEST file gives the URL, which is downloaded to a file under the ‘%temp%’ directory. Figure 1.5 shows the decoded URL:
Fig 1.5: Decoded URL
The file that is downloaded into the ’%temp’% directory is identified as “msitcm.cpl.” Figure 1.6 shows the Java code that saves the file into the ‘%temp%’ directory:
Fig 1.6: Java code
Java later registers the ‘.CPL’ with ‘regsvr32.exe’. Figure 1.7 shows the Java code that registers the downloaded ‘.CPL’ file through regsvr32.exe:
Fig 1.7: Java executing msitcm.cpl
msitcm.cpl downloads other malicious files onto the machine, which generally results in the installation of a fake antivirus application.
Fig 1.8: Fake antivirus application
The good news is that Symantec customers are protected from this attack. Both Symantec IPS and AV engines have generic detections for the requests that are sent and the files that are downloaded.
For more information, see our recent Attack Toolkits report.