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:
Figure 1. Exploitation flow second stage
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:
Figure 2. Malware distribution server calls the function that handles the landing page logic
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:
Figure 3. Malware distribution server bots and proxies filtering code block
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:
- Customer ID
- Victim IP
- The filtering result for that victim
- Victim's OS
- Browser version
- Victim's country and language
Now, for the Magnitude landing page logic:
Figure 4. The landing page generation code block
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:
Figure 5. The landing page template
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%":
- The "%host%" string is being replaced by the current hostname of the malware distribution server.
- The "%javapath%" string is being replaced by the MD5 hash result value of the current malware distribution server hostname concatenated with the client IP address.
- Finally, the "%javaexp%" string is replaced by the hash result value of the current MD server hostname concatenated with the string "javaexp".
After these values have been added to the landing page, it is served to the victim.
Figure 6. Malware distribution server exploits delivery logic
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:
Figure 7. The VML exploit generation function
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).
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:
Figure 8. The payloads delivery logic
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.
Figure 9. Final filter before serving the payload
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:
Figure 10. The code block that determines whether to inject the Magnitude admin's private payload
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.
If you haven't already, check out the first, second, and third posts in this series.