This is the fourth post in a four-part series about Magnitude (if you like, read the first, second, and third parts too).
This post will continue where the third post left off discussing the infection flow and cybercriminals redirecting victims to the gateway servers. Here's the next step in that flow:
The victim is redirected to the current Magnitude malware distribution server. When a victim is redirected to the distribution server, the Magnitude landing page is served first:
The checkidbyhost() function returns the Magnitude customer ID from the URL of the current malware distribution server as explained above. The getparams() function returns an array with the victim's Referer header and numeric values that represent the victim's OS and the browser vendor. In Magnitude, the plugin detection mechanism used by many exploit kits is done server-side unlike most of the exploit kits which use JavaScript code to enumerate the victim's plug-in versions.
The start() function is responsible for returning the Magnitude landing page. First, it filters victims based on similar parameters as the gateway server. Here's a snippet of the filtering code:
The Magnitude malware distribution server also filters non-Windows, non-IE victims and victims from forbidden countries.
Just before serving the landing page, the MD server inserts the victim's details in the "exploits" database table. This table includes the following details:
Now, for the Magnitude landing page logic:
First, it fetches the index file whose content is shown in the image below. This file serves as a template for the landing page and it may occasionally change:
The code above processes this HTML page and replaces the placeholders ("%host%", "%javapath%" etc.) with values that will be used to determine which exploits to serve. E.g. for the path "http://%host%/%javapath%/%javaexp%":
After these values have been added to the landing page, it is served to the victim.
The victim's browser processes the HTML and JavaScript code and requests resources that are referenced in the landing page: two applets, a JNLP file and one iframe. When the browser makes requests to these resources, the malware distribution server uses the following code to differentiate between them:
An example for such requests:
Using this technique, the malware distribution server determines which exploit was requested by the browser and calls the corresponding function. For example, the printvml() function is used for serving the VML exploit and looks as follows:
First, the proverka() function returns an array of the current victim's details that were stored in the "exploits" database table. A description of what this table includes was provided above.
Next, the printvml() function returns an empty page for victims who run 64-bit Internet Explorer on 64-bit Windows, or don't use Internet Explorer version 8, 9 or 10. Otherwise, the function loads the VML exploit template. This file is periodically changed and regenerated (more details in the Magnitude Backend Infrastructure Part I post).
The printvml() function processes the VML exploit template and slightly adjusts it based on the victim's IE version and the "WOW64" token in the User-Agent. Presence of "WOW64" indicates that the victim runs a 32-bit version of Internet Explorer on a 64-bit system. Most of the adjustments are made in the Shellcode and the JavaScript code and once they are complete, the VML exploit is served.
Upon a successful exploitation, the Shellcode downloads the malicious payloads. It makes six different requests using the same logic we've seen before. They include the hash value of the malware distribution server IP address concatenated with "ieexp?" where "?" is any value between 0 and 5. Check out this blog post for examples of Magnitude URL and URI structure.
The server-side code that handles those requests can be seen below:
Each request calls the repexe() function, which is responsible for determining what payload to serve. This function is also used also with the other exploits, not only for VML.
This function filters requests that have headers that include the string "HTTP_X" which normally is used by reverse proxies. Then it updates the victim's record in the "exploits" table with the ID of the exploit that was used. Next, the function handles the Magnitude admin "payment" for all of his hard work:
Magnitude serves the customer's payload ~82% of the time except when it serves its own malware of choice. When $exenum is zero, meaning that repexe() is called for the first time, if a random number between 0 and 10 is less than 2, the payload is going to "a1.exe". This is the Cryptowall ransomware that the Magnitude admin distributes. That's where the Magnitude admin's revenue comes from. For subsequent calls of repexe(), only payloads from Magnitude customers are served. Finally, the payload is served to the victim. The "repexe" function is called 6 times resulting in up to six different malware files being delivered to each victim as mentioned.
So folks, that's a wrap of our story about Magnitude. As can be seen in our blogs, exploit kit admins use multiple servers for different roles and provide their customers with advanced capabilities. We hope we have shed some new light on how exploit kits operate internally, and that this information will help in the ongoing battle against malware.
Stay safe.
If you haven't already, check out the first, second, and third posts in this series.
