Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Magnitude Exploit Kit Backend Infrastructure Insight - Part III

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 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:

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:

  • Date
  • Customer ID
  • Victim IP
  • The filtering result for that victim
  • User-Agent
  • Referer
  • 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.

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:

Figure 6. Malware distribution server exploits delivery logic

An example for such requests:

  • http://#MD-Server-Domain#/5c50b1ffc10f4111d0bc47d655ddd08e/03dea545f17ef8919ee268b53a1c6b48
  • http://#MD-Server-Domain#/5c50b1ffc10f4111d0bc47d655ddd08e/89d1ae2740a5673bdc48edee513359b8

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).

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:

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.

Stay safe.

If you haven't already, check out the first, second, and third posts in this series.

Latest SpiderLabs Blogs

Important Security Defenses to Help Your CISO Sleep at Night

This is Part 13 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More